Uncategorized

#DICOM Education Day 2016

There’s a fantastic DICOM education event coming up in September, in Dalian City, China. From the conference website –

The 2016 DICOM Education Day in China will include lectures by international DICOM experts to promote the uniform understanding and adoption of the DICOM Standard and encourage participation in the DICOM Standard development and maintenance process. DICOM also invites local speakers to talk about local DICOM and medical imaging topics, the local healthcare system, and the use of Information Technology.

More information and registration (free of charge!) is available at http://dicomconference.org !

healthcare API, REST

#DICOMweb cheatsheet 

We just wrapped up a very successful, inspiring and fantastic #DICOMweb conference and hands-on workshop. One of the things I put together (with the help of a few others) is a cheatsheet to provide a quick reference help to the medical imaging RESTful objects that #DICOMweb provides. The link to access this cheatsheet can be found here:

http://dicomweb.org/DICOMweb-Cheatsheet.pdf

If you have any feedback on how this one-pager can be improved, please let me know. Happy RESTing!

interoperability

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:2.16.124.113543.6003.1154777499.30246.19789.3503430045",
 "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.
developers, dicom

Hacking classical DICOM : A Hello World primer

This weekend, I am at PennApps, a fantastic hackathon event in Philadelphia. It got me thinking about sharing some simple steps to hit the ground running, with classic DICOM (notwithstanding all of the amazing advances of #DICOMweb).

DISCLAIMER: This information is provided as-is, the content might be incorrect or out of date, and could harm kittens or even worse if used improperly.

I will also continue to update this post as necessary.

Step 0 : Understanding enough about DICOM to start

Skip this section and come back to it as you follow the steps below. Below you’ll find some basic explainers of DICOM concepts. These are over-simplified to the point of technical inaccuracy – but I’ve added some DICOM-geek-spoilers to help technically clarify statements. If you’re just starting out, ignore those notes in red.

  • A medical image file can be referred to as a DICOM file.
    • Technically, the fact that we have actual files is just a matter of convenience / an implementation detail – DICOM is more about specifying the file structure and the transportation layer, and leave “how you save the files to your disk” up to you. 
  • A DICOM file is very much similar to a JPG or PNG, that you take from your camera. Unlike most image files, double-clicking them won’t open up those images – there isn’t a viewer available by default on computers today.
  • A DICOM file has headers and pixel data.
    • Headers are made up of a series of “parameters” (or tags, or attributes), a “parameter type” (like string, or integer), and a value / set of values. See here for a general list of tags (easy to use browser find to look at tag names).
  • A piece of medical equipment that captures medical images is sometimes called a “modality”. In most modalities, multiple images are taken as part of a medical exam. Here are a few examples:
    • X-rays are taken when you have fractured a bone. There’s usually a few different views taken.
    • Ultrasounds are taken when looking at softer tissue. Sometimes they are a series of snapshots taken over the course of the exam; other times they are a series of images in “real-time” (like watching the heart).
    • CTs and MRIs are used to see inside the body – and they are stored as “slices”. Think of your body being cut horizontally, millimetre by millimetre – each one of these is an image. There could be 64 slices, or there could be 10,000 slices or more.
  • Individual images that were captured as a group are collected into a “series”, for example all the CT slices that make up a brain volume. A number of series can then grouped into a study, which is what a doctor orders, for example a PET series and a CT series in a combined PET/CT scan of a tumor.

Step 1 : Get some images

There are a lot of places to grab images from. Google terms like “DICOM Sample Images” to find some. Here’s a couple of places to get you started:

These sites typically package DICOM images into a ZIP file for download, containing a set of folders (which represent each series), and each of those folders containing a set of DCM files. If the ZIP is a set of studies, there might be an additional layer (directory of studies, each containing directories of series, each containing directories of DCM files).

So, let’s assume you have some DICOM. Now, we need to have a look inside. Unzip them somewhere and remember where you saved them.

Step 2: Have a look at the images

For this step, you need an image viewer. There are a number of open-source viewers out there – here’s a couple :

Once you have installed viewer software, you can open up the DCM files you have saved from the previous step. Typically, viewers allow you to open up a “directory”, which will discover all related images in a series or study.

Once you’ve opened up a study, have a look around! Medical imaging is a fascinating and beautiful thing to behold.

Okay – so, now you have the data – but how do you unlock that information?

Step 3: Getting at the header and pixel data

Now we get to the programming aspect. For this, you need a library. There are a number of libraries available, for all sorts of languages. Server-side, I’ve been brought up on Java, so I use a library called DCM4CHE (start with the BIN download). It also has command line tools, so it is worthwhile even if ultimately you don’t want to use Java.

With DCM4CHE, there are a number of tools with command line apps pre-compiled with it. Two very quick wins with these tools will allow you to get header data (in XML or JSON), and getting the image housed within it.

Getting the header data

Use the command dcm2xml. You can pass in a DICOM file and it will spit out XML of all of the DICOM tags. It works very simply:

dcm2xml <path-to-dicom-file>/<file-name>

And this will write to the console the XML file. There is a lot of very useful information that can be gleaned by exploring the header data, such as learning about the patient and about the study being performed.

Although not documented on the site, I have seen a JSON rendition of this tool as well.

Getting the image (pixel data)

Use the command dcm2jpg, you can pass in a DICOM file and it will spit out a JPG for all your viewing needs. It also works very simply:

dcm2jpg <path-to-dicom-file>/<dicom-file-name> <path-to-jpg-file>/<dicom-jpg-name>

And this will drop the file as an image. Now, depending on your version of Java, you may need a JPG library that can actually encode the out as JPG.

Other DCM4CHE notes

  • When you actually use the image library inside of Java, you can use buffers and streams to more efficiently work with the pixel data (and header data, for what it’s worth).
  • There are many other tools to explore from here, including creating DICOM files, manipulating them, and transmitting them.

Other library options

There are other libraries like DCM4CHE depending on your needs and preferences. DVTk is another example.

Step 4: Do Awesome

Now that you have the basic building blocks of a DICOM image file, you can now begin to create imaging magic. It only gets better from here. Some resources to keep you moving forward:

Uncategorized

Imaging on FHIR at Connectathon

There is an exciting event coming up at the next HL7 FHIR Connectathon, in Chicago on Sept. 13-14. One of the announced tracks is on DICOMweb and FHIR ImagingStudy. This track will explore the intersections between the two standards, elicit feedback on what we got right in aligning the two standards together, and likely create/show some stellar implementations in the process.

Given the success of this year’s hackathon at SIIM, I think this connectathon track will be very interesting. At SIIM, I witnessed magic being made, as those participating created exciting new integrations from the standards. There is so much unlocked potential when considering how the two can be integrated; the insight and feedback from September’s event will be very, very interesting.

dicom

Quick and dirty JavaScript DICOMweb UID generator

I thought I’d share this tidbit code, to create UIDs (Study Instance UID, SOP Insuance UID, etc) using Javascript, primarily for use with standards like DICOMweb STOW-RS and UPS-RS.

WARNING: This is not a proper implementation, and could result in UID collisions in your repositories. Do not use in production – you should use proper UID management procedures defined in  DICOM PS3.5 B.1.

var dicomUID = '2.25.xxxxxxxxxxxx4xxxyxxxxxxxxxxxxxxx'.replace(/[xy]/g, function(c) {
   var r = Math.random()*16|0, v = c == 'x' ? r : (r&0x3|0x8);
   return v.toString(10);
});

I put a functional example on jsFiddle.

See DICOM PS3.5 B.2 for the specification reference. The JavaScript inspiration came from an answer on StackOverflow.

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.