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.