Radiology Report Repository Spike Update #1

Yesterday I started working on the spike for the Radiology Report Repository.  The first thing I did was create a sample ORU message to work with.  I decided to make the most basic and simple ORU message possible and this is what I came up with:

MSH|^~\&||ABC|||201503231355||ORM^O01|1000|D|2.4|||AL|NE
PID|1|2000^^^^MR|||DUCK^DONALD||19340609|M|||1113 QUACK STREET^^DUCKBURG^CALISOTA^^^^^|||||||
PV1|1|I||EL||||||SURG||||PHY||||IN|||||||||||||||||||||ABC||ADM|||201503231330||||||||
OBR|1||3000|RAD^CARM^RAD C-ARM|||201503233154||||||||||||||||||F|||||||||
OBX|1|TX|L.RADREA2^Reason for Exam:||Report text

The key things in this message are:

Patient Name: DUCK^DONALD
Patient MRN: 2000
Accession Number: 3000
Report Date: March 23, 2015
Report Text: Report Text
Exam Code: CARM

I also need to send this message to my HL7 listener, so I downloaded and install HL7 Inspector for this.  After installing HL7 Inspector, copy the above test ORU message above into your clipboard, then right click the background of HL7 Inspector and choose "Import from Clipboard", click OK on the "Import Options" dialog and you should see the message displayed like this:

Next I need an HL7 listener.  I initially started with Mirth Connect but quickly abandoned it as I realized I would need to write quite a bit of logic and it would be very hard to develop/debug/test that logic using Mirth.  I decided to try building the prototype using Node.js and google helped me find the following code to receive HL7 Messages.  I created a new project using WebStorm, pasted that code in there, started up the Node.js process, configured HL7 Inspector to send to port 6020 and sent the message to it from HL7 Inspector:

Success!  Next up is parsing the HL7 message and implement the following pseudo code logic:

parse the HL7 message
search for Patient resource given the MRN
if Patient resource does not exist
  create Patient resource javascript object
  POST Patient resource javascript object
Create DiagnosticReport javascript object with reference to Patient resource
POST DiagnosticReport javascript object

Given this pseudo code, the first step is to parse the HL7 message.   A google search points me to the L7 library.  A bit of code later and I have parsed the fields I need to create a Patient resource:

Next up we need to start implementing the pseudo code.

The HL7 FHIR ImagingStudy Resource

Continuing on with the exploration of using HL7 FHIR as a Radiology Report Repository I want to take a look at the ImagingStudy resource.  The first thing to take notice of is that there is a 0 to many relationship between the DiagnosticReport resource and the ImagingStudy resource.  The optionality of the ImagingStudy is needed for two reasons:
1) DiagnosticReport can be used for non radiology reports than don't have any images
2) Some Radiology Reports may not have a corresponding ImagingStudy.  There may in fact be a DICOM study for a report but the PACS isn't hooked up to the FHIR server yet so it doesn't know about it.  Another possibility is that there is no DICOM Study for this report - this could be the case if the study is a film.

The real question is why would there be more than one ImagingStudy for a Radiology Diagnostic Report?  A few reasons come to mind:
1) In some cases there may be multiple DICOM Studies acquired for one report.  I believe this is uncommon but it is certainly possible.  One example of where this might happen is when you have a mixed modality procedure (e.g. PET/CT) and have to use two different scanners to complete it.  Each scanner would produce a unique DICOM Study Instance UID so there would have to be one ImagingStudy for each DICOM Study that is associated with the DiagnosticReport.  Another example is where a site wants to add scanned documents to the PACS.  The system that scans the documents may generate a new DICOM Study Instance UID for the scanned documents, but they need to be viewable within the PACS with the actual radiology images.
2) DICOM has a feature called "Key Object Selection Document" which is a DICOM SOP Instance which has pointers to one or more SOP Instances.  In many cases, there are a few images in a DICOM Study which can be used to illustrate the radiologists findings.  Displaying just these "key images" to physicians and patients helps them understand the findings as they don't have to navigate through the rest of the study to find the images of interest.

Interestingly enough, the documentation for the ImagingStudy resource specifically calls out the key image use case.  It refers to the ImagingStudy as a "manifest of a set of images".  You will also notice that it implements this manifest by mimicking the DICOM Study/Series/Instance hierarchy with one to many relationships between each.  The manifest concept is very exciting because it means that a client can obtain a list of all DICOM UID's for a study with a single REST call.  This may in fact be preferable to the DICOMWeb WADO-RS Retreieve Metadata but more compact as WADO-RS includes all metadata tags and ImagingStudy just has a subset.  Of specific note is the more "user friendly" json schema of the ImagingStudy resource compared to DICOMWeb's JSON Mapping:

HL7 FHIR Instance:
{
  number: 0,
  uid: "1.2.3.4.5.6",
  sopclass: "1.2.840.10008.5.1.4.1.1.2",
  type : "IMAGE"
}

Equivalent DICOM JSON Mapping:
[
  {
    "00200013" : {
      "vr" : "IS",
      "Value": "0"
    }
  },
  {
    "00080018" : {
      "vr" : "UI",
      "Value": "1.2.3.4.5.6"
    }
  },

  {
    "00080016" : {
      "vr" : "UI",
      "Value": "1.2.840.10008.5.1.4.1.1.2"
    }
  },

  {
    "00041430" : {
      "vr" : "CS",
      "Value": "IMAGE"
    }
  }
]


Clearly the DICOM JSON mapping is larger and more difficult to work with.  I blogged about this before and look forward to a day when DICOM has a more compact JSON Mapping, preferably with normalization.  Fortunately FHIR solves a problem not yet solved by DICOM (summary of images) and is far easier to work with - this alone makes me want to immediately embrace it as a way to get a high level description of a study.

Moving on we find that the ImagingStudy has a link to the following resources:
1. Patient (subject) - Patient demographics such as name, gender, date of birth, etc
2. DiagnosticOrder (order) - Information provided by the ordering physician (perhaps signs and symptoms, etc)
3. Practitioner (referrer) - The physician who ordered the exam
4. Practitioner (Interpreter) -  The radiologist who read the exam

You will also notice that there are other important properties such as accessionNo (the accession number) and uid (the DICOM Study Instance UID) which are critical for matching and lookup purposes.

Next up will be a look at how we can create ImagingStudy resources as a DICOM CSTORE SCP.

Implementing a QIDO-RS Service

Having previously implemented a basic QIDO-RS worklist using JavaScript, I figured it would be useful to implement a QIDO-RS service to improve my understanding of the standard. For those unfamiliar with QIDO-RS, it allows web based queries for studies, series and instances - similar to C-FIND. This weekend I implemented a simple service implementation using C#, Visual Studio 2013 and ASP.NET MVC 5 WebApi. You can find the source code for this project on my github here.  

Overall I found the implementation to be fairly straightforward and it took me about 16 hours total. About 2/3 of this time was related to a) understanding the standard and b) working through various issues with Visual Studio 2013 and ASP.NET MVC 5 WebApi (neither of which I had used before).  

Here are some of my thoughts after getting this implemented:

1. I found several errors in the DICOM standard:

• Modality has incorrect tag in Table 6.7.1-2a
• Missing Study Description tag in Table 6.7.1-2
• Misspelled StudyInstanceUid on line 641
• JSON Example in F.2.1.1.2 is Invalid JSON (missing a comma between array entries)

2. The standard was difficult to understand

• It makes several references to concepts documented elsewhere (e.g. fuzzymatching,)
• It seems to be designed as a web wrapper around CFIND which therefore requires fully understanding CFIND

3. It isn't clear what functionality is required and what is optional. This may be due to it being designed as a wrapper around C-FIND and I don't have expert level knowledge of C-FIND.

4. The JSON mapping was not designed for ease of use by JavaScript developers.  From F.2 in the standard "The DICOM JSON Model follows the Native DICOM Model for XML very closely, so that systems can take 790 advantage of both formats without much retooling".  Here are some specific issues

• The attribute tag (group/element) is used as the property name in the JSON object. JavaScript code cannot use dot notation to access these properties since it is not supported for property names that do not begin with a letter. This could have easily been solved by putting a letter like x in front of the group/element.
• The inclusion of the VR field seems unnecessary since the native JavaScript type system is used.
• Putting all values in an array is awkward. It would have been better to only use an array for attributes with multiplicity > 1
• The use of Alphabetic, Ideographic and Phonetic in the PN mapping is unclear. I am sure these are documented somewhere else in the standard - but where? Having a PN value be an object instead of string is also a bit awkward.
• The casing for property names is not consistent. vr starts with lowercase letter while the others start with an uppercase letter. The most common naming convention in JSON/JavaScript is the first letter lowercase.

Overall this is a positive step forward to bringing DICOM into the world of the web but more can be done to reduce the barriers to using DICOM by developers. The best way DICOM can reduce these barriers is to make web browser and JavaScript based consumption a top priority and make it as easy to use as possible in that environment. Efforts such as the dicomWeb online documentation are very helpful and so are open source implementations of the standard.