Today I continued my exploration of building a Radiology Report Repository using HL7 FHIR. As you may recall from my earlier post, my goal is to display a radiology report received via HL7 v2.x ORU to a user along side the corresponding images. The first challenge you run into is how to connect HL7 messages to DICOM studies. HL7 and DICOM are different standards and the data for them often comes from different systems which leads to interoperability issues - specifically around identifiers. In radiology, the main identifier used to connect HL7 ORU to DICOM Studies is the accession number. The accession number comes from DICOM Tag 0080,0050 and from HL7 in OBR-3 (aka filler order number). Ideally these would exactly match making it easy to connect the two, but that isn't always the case:
1) There may be leading or trailing whitespace on these values. DICOM values in particular must be even lengths so an extra space is often tacked on the end of the accession number if it has an odd length.
2) There may be leading zeros on one identifier but not the other. For example, one could be 0001000 and the other could be 1000
3) There may be leading letters on one identifier but not the other. For example, one could be A1000 and the other could be 1000
These variabilities are often discovered during the implementation phase of an interface and often require transformation of the data to get things to match. Transformations such as whitespace removal, substring operations, string to number conversions and pattern matching substitutions (e.g regex) take care of most cases but more complex are sometimes needed that require conditional logic. Mirth Connect supports transformations like this using JavaScript. Some DICOM Systems will support transformations through what is commonly referred to as "tag morphing". Tag morphing is a fairly common feature and selling point of VNA products.
In larger more complex enterprises, you may actually have multiple RIS and PACS systems which complicates the accession number matching. Accession numbers are not globally unique and it is quite possible to have two or more different reports (for different patients!) with the exact same accession number. It is easy to see how this can happen when you have two or more RIS systems (which typically generate the accession number) as they may have been implemented independently of each other. I have also heard of cases where a RIS would re-use an accession number although I am not sure why that would happen. Accession number alone may not be enough so additional matching criteria may be needed. Here are some additional fields that could be used for the matching criteria:
1) Date or date/time. In DICOM this could be Study Date 0008,0020 and in HL7 this could be observation date time OBR-7
2) Issuer. In DICOM this could be 0008,0051 and in HL7 this could be the Universal ID OBR 3.3
3) Patient Identifier. In DICOM this could be 0010,0020 and in HL7 this could be PID-2, PID-3, PID-4.
The data transformation needs listed for accession number above may also be needed for the other matching fields. Given the above issues with connecting the HL7 v2.x world to DICOM, one might ask how this HL7 FHIR handles this. Based on my understanding so far, FHIR is aware of DICOM in two ways:
1) It has a resource naming ImagingStudy which has many DICOM Attributes including the DICOM Study Instance UID
2) It has a collection of links to specific images in the DiagnosticReport resource. Presumably these links would be to JPEGs of key images in the study rendered using WADO-URI.
With this base understanding, the next step is to figure out how to populate a FHIR system from incoming HL7 v2.x messages and DICOM instances.
No comments:
Post a Comment