HL7 - ORU results support

[JoeBatt1989]

Summary

AI Applications offer the ability to be able to send HL7 messages back to clinical systems to support worklist prioritisation. This is done through https://hl7-definition.caristix.com/v2/HL7v2.8/Fields/OBR.5

Proposal is to enhance the workflow manager and informatics gateway to be able to send these artifacts to a known destination.

• Build onto the existing HL7 work done in the MIG to receive, save and transmit HL7 messages
• The re-identification of PII data in the HL7 message
• Update to configuration to specify the transfer modality on export destination

Workflow Manager changes

HL7 Export Task

Creation of a new Task "Export-HL7" which will pick up named artifacts or artifacts within a directory that are extension .hl7 and generate a new message to inform the MIG to send those files to a destination.

New export task

{
    "id": "export-hl7",
    "description": "export hl7 message",
    "type": "export-hl7",
    "export_destinations": [
        {
            "name": "RIS"
        }
    ],
    "artifacts": {
        "input": [
            {
                "name": "hl7",
                "value": "{{ context.executions.remote.artifacts.hl7 }}",
                "mandatory": true
            }
        ]
    }
}

This will generate a new export event, using existing export request event (https://github.com/Project-MONAI/monai-deploy-messaging/blob/develop/src/Messaging/Events/ExportRequestEvent.cs) to a new queue md.export.request.hl7

Informatics Gateway changes

HL7 server to receive results (remote app execution)

There is a HL7 sever in MIG but this needs extending to allow remote applications to send their results to MONAI which will trigger an ArtifactsReceivedEvent (https://github.com/Project-MONAI/monai-deploy-messaging/blob/develop/src/Messaging/Events/ArtifactsReceivedEvent.cs) to the Workflow Manager

Re-identify PII data (remote app execution)

HL7 ORU messages contain PII and study information which will need to be reapplied to the message before being saved to MinIO. This will be done in a similar way that DICOM results are re-identified by using a plugin architecture.

Mappings will be custom per remote application. Configuration will held which will be used by the HL7 re-id plugin to ensure the correct fields from dicom metadata is mapped and replaces the correct fields in the HL7 message before saving.

Proposed structure of configuration

{
    "_id": "",
    "sender_identifier": {
        "key": "",
        "value": ""
    },
    "data_link": {
        "key": "",
        "value": ""
    },
    "hl7_version": "",
    "data_mapping":[
        {"key": "value"}
    ]
}

Example HL7 from AZMed can be seen below:

# In {} are variables, the rest is fixed
MSH|^~\&|Rayvolve|AZMED|RIS|{InstitutionName}|{YYYYMMDDHHMMSS}||ORU^R01|{UniqueIdentifier}|P|2.5
PID|{StudyInstanceUID}
OBR|||{AccessionNumber}|Rayvolve^{AlgorithmUsed}||||||||||||{AccessionNumber}|||||||F||{PriorityValues, ex: A^ASAP^HL70078}
TQ1|||||||||{PriorityValues, ex: A^ASAP^HL70078}
# DICOM Study Instance UID
OBX|1|ST|113014^DICOM Study^DCM||{StudyInstanceUID}||||||O
# Finding 
OBX|2|TX|59776-5^Procedure Findings^LN||{Textual findingsm, ex:"Fracture detected")}|||{Abnormal flag, ex : A^Abnormal^HL70078}|||F||||{ACR flag, ex : RID49482^Category 3 Non critical Actionable Finding^RadLex}

Export Destination supported modality

When specifying an export destination, the user should be asked to provide what data transfer protocol the export detsination is for i.e DICOM, HL7, FHIR. This information will allow the Workflow Manager to validate that users only add correct destnations for the correct task type and for MIG to do some pre-validation to handle mismatching artifacts and destination protocols.

Additonal considerations

• Workflow Manager logic to be updated to dispatch tasks conditionally based on artifacts that be received to fully integerate multi-modality support. Not part of this scope.
• https://github.com/Efferent-Health/HL7-dotnetcore is used as the HL7 library, a lightweight mapper will sit along side this to re-identify PII data.
• The support of different HL7 versions will be catered for by the HL7 library. MONAI will not be responsible for version conversion, uplift or downgrade based on the receiving system. This will sit with Organization who want to integrate the HL7 message into their clinical systems.

[JoeBatt1989]

Hi @mocsharp @dbericat @MMelQin, I have converted the #143 to a discussion. Would this be something that we could add to one of the upcoming agenda's please?

[neildsouth]

The export message currently used could be expanded with a DataOrigin object (object currently used in md.workflow.request, this details the Type eg. HL7 Dicom and some other details)
this would allow the current export request queue to be used rather than introduce lots of new message queues. the same object could be used in the exportComplete message to allow proper processing on its return.

The new HL7 export Task type (WorkflowManager) could contain mapping pairs, to enable custom remapping of the HL7 message eg [{ "OBR.3" , "0008,0018" }] allowing support of differing HL7 versions without
adding these into Monai.Deploy logic.