Simple HL7 Interface for orders

[GreySeaWolf]

The use case would be, simple HL7 Order Messages being sent by legacy systems. For example, an order can tell the imaging study as well as the AI algorithm that needed to be executed (on the study).

Hence, an order-based workflow to run AI algorithms could be connected to Legacy systems that might lack FHIR capabilities.

[mocsharp]

Options for receiving & storing HL7 messages:

1. Store the messages as raw text
2. Convert HL7 messages to FHIR and store

[mocsharp]

Meeting (2022/02/08: @GreySeaWolf , @dbericat , @gigony , @joshliberty , @slbryson , @mocsharp ):

The following workflows are to be supported in 0.2.0 of HL7 service/listener:

1. IG to listen and receive HL7 order and retrieve DICOM dataset. The output from the AI model may include:
   • DICOM Series
   • HL7 messages ⛔ Blockers: DICOM C-FIND/C-MOVE
2. IG received DICOM, runs AI workflow, and produces HL7 notification/alert + SR + DICOM series that need to notify physicians.

Similar to the DICOM server/client of IG, IG stores any received messages as is and assumes the application developers need to decode and compose any stored messages.

[MMelQin]

Just want to put things in context with regard to HL7.

1. Which version to use, 2.7 or 3.x? Most systems still uses 2.7 for good reasons.
2. What HL7 message, ADT, OBR?
3. HL7 ORM message only gives you the placer order, filler order, the patient info, requested observation (coded), etc. which requires an integration engine to map/translate that message into consumable Radiology Informatics specific information. DO NOT assume the IG can perform this, and storing the raw HL7 message does no good as nothing else in the MONAI workflow are to be designed to consume it.
4. HL7 messages has no direct relationship to DICOM Query/Retrieve using DICOM DIMSE or DICOMWeb.
5. HL7 uses MLLP, kind of a "publish"/"broadcast" protocol. As such, there is not necessarily designated application endpoints to notify or alert. For clinical, security and other good reasons, not any service can be allowed to publish.
6. The IHE AIW does not list HL7 as the trigger for AI workload, for good reasons. Similar to a DICOM modality, procedure step is used to drive the workflow, and device can query DICOM Modality Worklist for assigned work.

[GreySeaWolf]

We will be returning HL7 ORU Messages, The Order ID and Ascension Number can be found from the DICOM Header. The results (or observations, findings, etc.) produced for a given order will be returned in an ORU.

[MMelQin]

For sure, ORU with its OBR and OBX and other segments are parsed by HL7 integration engine, and stored in RIS. My concern about reporting AI results from IG is more on if it can be allowed to report, for clinical and security reasons. That is why we have preferred to send the AI results to PACS and let the clinicians to decide/modify (seg, contour, or classification).

At least for the Rad "PACS" system I worked on, new image arrival notification to the clinician/viewer is triggered by the "PACS" on receiving new series of a study (already read or not). Granted, the "PACS" is more a Rad workflow engine which includes a PACS.

Sorry, I even mixed the message types (it's been a long while), and ORM was I meant to say about order. For most systems, HL7 integration is typically done using commercial OTS software, and the applications just need to take care of message mapping from the segments to application's own defined entities, some of which translate to DICOM IOD instances.

[GreySeaWolf]

In the case where the reading worklist is within HIS (e.x. Epic Radiant), sending a complete message to PACS won't' be enough. Imagine an ED case where you want to alert the reader by prioritizing the exam by flagging it (to be sorted on top). You want to alert a reader, your 2 options are 1) send the results to an emergent cases worklist, etc. 2) re-prioritize the existing worklist by sending an "ai result found" message. In either case, you can send an HL7. Or you can try to convince the HIS to accept DICOM-SR, etc. Yes, your original finding can be in the form of SR, SEG, RT-Struct, Secondary Capture, etc. But if we want it looked at earlier (for an emergency), you need to alert the Worklist.

[MMelQin]

Another thing is, this statement IG to listen and receive HL7 order and retrieve DICOM dataset may have made some wrong assumptions and needs to be revisited,

• HL7 ORM does not have Rad or DICOM information, e.g. no accession number, and the order typically have the request observation start time in the future.
• The IG cannot know or derive the accession number, nor assume any observation (DICOM study) has been done and is ready.
• IG will then have to query the RIS/PACS based on patient info, but that is another set of complexity, e.g mapping the issuer ID, order to accession, to study, etc.

[MMelQin]

@GreySeaWolf I agree there is definitely a need to send notification to the clinical workflow engine (be it PACS/RIS or HIS), and I need to learn how it is realized in your system. Advanced workflow and worklist management have been a tough feature to implement well in RIS/PACS, just within Rad, without considering other clinical data sources.

[mocsharp]

@GreySeaWolf what is the expected workflow? From the first comment👆, I assume it's an HL7 message to trigger an AI workflow, is that correct?

If so, we can do the following:

Implement an HL7 receiver that simply stores received messages on disk and passes the messages to this special MAP for "processing". Within the MAP, the application can parse the HL7 messages, identify which DICOM studies are needed and for which application(s). Then, issue an ACR call to IG (provided as a python lib in the app sdk) to retrieve the data and then trigger the correct models.

As for ORU (results generated by applications/models), the application would generate the message and request IG to send it to the destination via HL7/FHIR.

[mocsharp]

Meeting @ Feb 15, 2022 [@MMelQin , @dbericat , @MMelQin, @slbryson, @jonanswer, @gigony, @GreySeaWolf, @aharouni]:

We have 2 workflows mentioned by @GreySeaWolf :

1. DICOM dataset comes into the system, WM determines the AI workflows to execute based on exam description, DICOM headers. At the end of the execution, the results can be generated in SR that is sent back to PACS. An HL7 message is also to be sent to update the worklist notifying the doctors there is an updated result. Assumes the HL7 order ID is in the DICOM header.
2. Order is placed to run some imaging algorithm; in this workflow, an incoming HL7 message needs to be associated with an existing DICOM dataset that is to be retrieved by IG for processing. However, there needs to be an external service that does the association given that the HL7 order does not include any reference to the DICOM dataset. The association step can be achieved by writing a WM plugin that queries an external service or a MAP that does the work. This 2nd workflow requires the 1st so the HL7 message is sent back to the reading worklist.

Given that the 1st workflow can be done via SR, we can postpone until there are more needs from the community.

For the 2nd workflow, IG can be updated to accept HL7 and export HL7 but the association is all dependent on the plugin and the external service. Therefore, we may postpone this issue for later.

Please thumb up if you need this feature to be done. Cast your votes: 👍 for 1st workflow and ❤️ for the 2nd. (yes, you may vote for both)

[MMelQin]

2. Order is placed to run some imaging algorithm; in this workflow, an incoming HL7 message needs to be associated with an existing DICOM dataset that is to be retrieved by IG for processing.

This is incorrectly captured, as a HL7 order comes to RIS, so that a exam can be SCHEDULED and and assigned to the modalities, in a typical workflow.

I spent much time drilling down what pieces of data is available at what stage, what processing is required by what service, and how everything can be correlated in the HIS/RIS/PACS systems and the reading worklist. General workflows, with or without HL7 order are well understood and supported by many PACS/RIS systems. There seems to be a understanding that the HL7 directly drives the rad workflow without the RIS in between to bridge the HL7 and DICOM concerns, though we'd want to see some concrete examples, especially data details to see if it is the HIS/EHR (the Epics, the Cerner's) expanding and providing the RIS functionality.