DICOM

Key Images are… well, key!

dondennison Healthcare IT , , , , , , ,

As I discuss key images with vendor and healthcare provider staff, I have come to the realization that they are not well understood. Let’s see if we can correct that.

What are key images?

In most contexts, they are images within a medical imaging exams that the Radiologist reviewing the exam wishes to indicate for others, such as the referring physician and clinicians, that they are important in understanding the diagnosis.

In other context, they may represent important images for teaching purposes, quality control, surgical planning or other purposes.

In any case, they serve some importance over other images in the exam and the user wishes to communicate this. That’s why they are ‘key’.

Who creates key images and how?

In the digital world, any authorized user can mark an image as a key image on any system that supports this function. Typically, this function is restricted to authorized users like Radiologists on systems like PACS; however, they may also be created by Technologists/Radiographers on modality workstations or clinical imaging systems, like an Enterprise Viewer in an EMR.

Key images are normally created in one of two ways:

  • Manually by selecting an image and choosing a key image method
  • Automatically by creating some other form of markup or measurement on the image (implying that it has some importance)

The latter capability is important as getting Radiologists to take the time to mark images as key is often difficult. And if they are not created, the consumer does not benefit from them.

Special case: In systems that allow the user to create spine labels, these should not result in automatic key image creation.

Pages: 1 2 3

Review of Stage 2 Meaningful Use Test Procedure for Image Results …and other MU tests

dondennison Healthcare IT , , , , , ,

I was just checking out the draft test procedure (PDF) for access of image results under Meaningful Use stage 2, §170.314 (a)(12).

This is the test that vendors seeking certification of their EHR products must complete and provide evidence of passing.

Often, EHR vendors get imaging wrong, but I think the authors of the test procedure got it mostly right. At least in terms of the requirements.

Essentially, the EHR must allow an authenticated and authorized user to be able to discover that exam images for a patient are available, and access the images (and associated “narrative”) in the EHR, or integrated systems, without requiring the user to re-authenticate, or search for the patient or exam.

Said another way, the system must have some form of Single Sign On (SSO) with the imaging system (or subsystem, if part of the EHR), and share the existing patient and exam context from the EHR to the imaging system.

A couple of comments…

  • I have seen SSO done well and poorly (read as: insecurely) between EHRs and imaging systems. When done poorly, it if often due to technical limitations in the EHR and/or imaging systems. Or, it is simply because the integration and/or IT staff lack the knowledge or effort to do it right (read as: securely). I have found that HIE and portal vendors and enterprise viewers are generally better equipped to properly handle SSO than EHR and PACS products (probably because they are generally based on newer technology and are often deployed in multi-facility environments that demand interoperability).
  • Integration from the EHR to a patient folder or specific exam has been around since PACS was first launched from an EHR well over a decade ago. What often gets lost is that users often want to compare exams side-by-side (e.g. pre-op and post-op). So, the imaging system may need to expand the context beyond a specific exam to allow this. As long as EHRs keep behaving like filing cabinets, the imaging viewer vendors will have to solve this.
  • The typical method of having an EHR be aware that an exam’s images are available for viewing is to push a modified HL7 ORU message, containing info about the exam, from the image manager to the EHR. The EHR then normally parses the info and uses it, along with a URL (or similar) string template, to create a context-sensitive link that can launch the viewer and present the desired exam. Some EHR can provide multiple exam identifiers, when the imaging viewer supports it, to show more than one exam in a single view. More modern methods for an EHR to discover the availability of an exam’s images is to use a REST-based query method, much like defined in DICOM‘s QIDO-RS (Query based on ID for DICOM Objects by RESTful Services) standard (in development).
  • An additional note on the URL to launch the viewer in context mentioned above: check out IHE’s work on the new integration profile Invoke Image Display (IID).

Some other test procedures that could be related to imaging…

  • Here (PDF) is the test procedure on authentication, access control, and authorization. And here is one on automatic log-off. I would have liked to see some requirements for SSO, like Kerberos or OAuth.
  • This test procedure on integrity requires a hash to be calculated and validated. This may (should) also be required for image exchange.
  • For the requirement for emergency access, if the imaging system does not allow the EHR to securely manage this (this can be done, by the way), the imaging system may have to also provide an emergency access override function (which means that the unique identity of the user had better have been passed securely to the imaging system, or it will have no idea to whom it is granting access).

Article: Healthcare Imaging Strategies Not Exactly a Snap

dondennison Healthcare IT , , ,

An article on enterprise imaging and image sharing that is worth a read.

Some thoughts…

  • Informatics at the time of capture is (very) important, but this doesn’t mean we are back to typing data in–most of what is needed can easily be discovered on demand by a Web service
  • VNA’s are still being considered a component distinct from PACS and the EMR–they should be considered an EMR component, enabling the management of imaging records within the EMR
  • You can question the ROI of including images in the EMR or assess the clinical relevance (both noble goals), but one thing I have learned: EMR users want them there (and you should want to make them happy)
  • People still think we need to move a full copy of the DICOM images around to share; when I share a video on YouTube, I share just a link. The state-of-the-art of medical imaging is at the same level. Only make a copy of the full data if you need to incorporate it into your systems as a new record.
  • Something I have recently observed: regardless of whether including images in an EMR is an optional menu or required core item in MU, if the people interpreting these rules believe they need image access display for referring physicians inside and outside the hospital, they are going expect to be able to put them there.

The Future of Image Sharing

dondennison Healthcare IT , , ,

I have been keeping tabs on some of the work in standards groups; most notably HL7’s FHIR and DICOM WG-27’s DICOMweb™ APIs: WADO-RS, QIDO-RS and STOW-RS. I think the ‘awakening’ to REST based Web APIs and the willingness to accept the use of data in new forms (e.g. metadata in JSON vs. traditional DICOM C-FIND RSP), marks a watershed moment in the healthcare IT industry. I spent some time looking at a project focused on image sharing and tried to see what impact these changes might have on how it manages data. Check it out.

The Power of REST in Healthcare IT

dondennison Healthcare IT , ,

The beauty and power of REST is in its conceptual and syntax simplicity, ease of use for consumers, and freely available technology stack.

For example, if I have a URL that says…

https://server_name/patient/?patientName=DENNISON

…you can probably guess what will be returned without reading any documentation (answer: info on patients with the Dennison in the name). Another example…

https://server_name/study/?patientId=123&accessionNumber=456&view=epr

…would return a specific study with some form of defined application setting called “epr”.

REST is always stateless, can use any accepted authentication method used with URLs (e.g. Kerberos, OAuth, OpenID, etc.), and perhaps most importantly can be used by Web browsers (and any other consumer) without any added client technology. Other Web service methods, like SOAP, are effective for machine to machine communication (which is why they are popular in large-scale enterprises for transactions), but are not possible to consumer from a Web browser without some for of added download. IHE went heavy into SOAP due to the influence of the preferences of the large companies involved–and, to be fair, most of the integration profiles were dealing with machine to machine transactions, and SOAP was more defined/accepted than REST, at the time. Now they are rapidly turning to REST as innovators, eager to unlock the power of REST proven by companies like Google, Facebook, and Twitter, are involved in the integration profiles.

Pages: 1 2 3 4