How to embed #DICOM medical imaging studies in your #EHR with #FHIR and #IHE IID

Have you ever wanted to embed medical images into your healthcare application but don’t know where to start? Today’s snippet shows you how to do just that in two easy steps. With the interoperable healthcare technology available today, you can perform some very powerful integrations, essentially out-of-the-box. I will describe how you can harness the discovery prowess of FHIR‘s ImagingStudy, and couple it with the IHE Radiology profile, called Invoke Image Display (IID), to do some awesome.

Step 1 : FHIR the ImagingStudy query to discover studies for your patient

Construct a FHIR query, as follows :

GET http://<FHIR server>/fhir/ImagingStudy?_format=application/json&subject=<Patient ID>

Replace the FHIR server with an actual FHIR server, and the patient ID as the subject. This query will return back a response containing the list of all imaging studies available for the patient ID passed in. In the example above, I’ve asked for JSON, but XML is also available.

In the response, in the “entry” section, you will note an array of all imaging studies, with each object containing metadata and references to each study. This contains many useful attributes, such as the following:

 "resourceType": "ImagingStudy",
 "dateTime": "2011-01-01T11:01:20",
 "uid": "urn:oid:",
 "accessionNo": "1234",
 "modality": "CR",
 "description": "CHEST 2 VIEWS",
 "numberOfSeries": 1,
 "numberOfInstances": 2

While some of this information will be helpful to determine which study someone would like to display, the key to integrating this with your image viewer is the “uid” attribute. Lop off the “urn:oid:” and you’ll have a bona fide Study Instance UID, to use in the next step.

Step 2 : Invoke the Image Display to display a study for your patient

Construct an IID URL, as follows :

http://<IID server>/IHEInvokeImageDisplay?requestType=STUDY&studyUID=<Study Instance UID>&viewerType=IHE_BIR

Replace the IID server and the Study Instance UID placeholders with appropriate values (study instance UID is obtained from the previous step. This will launch a viewer showing the study requested – simple as that. You can take this URL, and launch this inside an Iframe, as an example.

Two easy steps is all it took, to image enable your EMR. Just like that.

Side Note:

  • You will have to consider how you will secure this integration. Both FHIR and IID use industry standard security mechanisms described in their respective specifications.
dicom, healthcare API, interoperability

DICOMweb QIDO-RS vs FHIR ImagingStudy

Over the last year or two, there has been fantastic synergy between the DICOM and HL7 working groups, to harmonize the RESTful services being developed out of both standards organizations. DICOM has the DICOMweb services (of WADO-RS, QIDO-RS, and STOW-RS), and HL7 has FHIR. They both have representations of the diagnostic imaging study. They have been harmonized – but remain un-unified and distinct. To some, this may seem like a peculiar concept – why not just have one standard that works for everybody? Why not develop one interface, one method, one response, one object type?

To me, this approach of objects in both standards – is logical and perfectly justifiable. My personal, perhaps biased take comes down to one main thing – target audience. Following are the two extremes.
For the Electronic Medical Record (EMR) system, their bread and butter interoperability method is HL7. They are interested in “events”, and “observations” – i.e., patient is admitted, or patient had a diagnostic test. They know about available lab work, and happily render that information (procedure + value + unit + abnormal flag). They know about and happily render reports (straight text). They know orders. But what they don’t do, is imaging. Peering into DICOM is an entirely different beast compared to other clinical data object types. Knowing how to hang images within a study is a science (and art) all its own. EMRs want to know what studies are available, and then they can have a dedicated buddy (an image display application, such as an enterprise viewer or PACS) to render for them. EMRs may want to show thumbnails, but that’s likely about as deep as they want to go. FHIR ImagingStudy is for them – they get a high level overview in a standard they know, and let someone else dig deeper if necessary.

For the PACS Radiology system, their bread and butter interoperability method is DICOM. They work at the instance level, and build up from there. They break apart and digest DICOM headers, and render complicated multi-frame instances with thousands of parts, without even breaking a sweat. They may have knowledge about orders, but that information is tertiary and linked, at best. They have massive repositories filled with DICOM, the standard that has worked for decades. Knowing the basic metadata about the instances is simply not enough for all of the use cases – depending on the modality, the specialty, the vendor, the task – the full header information and the complete instances are needed. DICOMweb is for them – querying headers of choice via QIDO-RS and retrieving via WADO-RS – they get in-depth detail in a standard they already speak. Modalities, who typically only deal with classic DICOM, can even leverage DICOMweb with the benefit of a helping go-between service that can map their classic queries onto DICOMweb ones (i.e., via a proxy).

So those are the black and white cases. There’s a vast middle-ground, where either standard (or both) is entirely appropriate. It depends a lot on their “imaging use maturity”; software that already has an established imaging connection might choose to stick to DICOM and augment themselves with DICOMweb services. Software that is ready to be image-enabled (nurse call, patient portals, rounds) might choose FHIR. To a large extent, this is an undecided, under-discussion, case-by-case type of thing.

It is important to keep in mind – both QIDO-RS and FHIR’s ImagingStudy resource both point to WADO-RS (DICOMweb’s retrieval service) to retrieve the images or a specific rendering of them. So, for the “provider”, they will either need to implement the necessary DICOMweb services anyway, or have a buddy that already has this available to talk to. It is also important that, since both standards are built on top of technologies such as JSON and XML, can gracefully be augmented with additional data outside the standards (just add new tags; existing systems will gracefully ignore them).

Whether it is top-to-bottom or bottom-to-top, there’s value having both available for the necessary constituents. Making a PACS or VNA implement the breadth and depth of FHIR is quite heavy-handed and provides little benefit in the near future; for example, the FHIR Patient sub-resource requires information that is not available in DICOM headers and so makes it more complicated to obtain. If the information is truly needed, systems can ask the appropriate source of truth for this. Similarly, finding EMR systems that speak DICOM has historically been quite challenging and other solutions to this problem (i.e., having a image viewing application buddy) have already taken hold.

It is hard for me to say what the future will hold – I’d check out Don Dennison’s article, entitled PACS 2018: An Autopsy, as a start. If one will eventually “win”, it surely won’t happen anytime soon. What I can say, though – the very fact that we can have these conversations – it truly is an exciting time for the integrator, and a transformative one for healthcare.