-
Notifications
You must be signed in to change notification settings - Fork 79
Result Reporting
Result reporting currently occurs between OpenELIS and iSantéPlus.
Result reporting must be switched on and a sending address must be provided at ResultReportingConfiguration.do for the functionality to be activated.
- Order request is received.
- Order request id is entered into order entry page.
- OE fetches info about order, requests any missing information be entered manually.
- Order exists in regular order workflow.
- Updates to order trigger information to be sent back to requesting system.
HL7 v2.5.1 in pipe mode is being used to communicate information both ways.
We use Hapi for parsing and creating our hl7 messages
The LOINC library is being used to identify which test is being requested for the sample.
Queuing failed messages and automatic retry is supported.
Automatic patient entry is supported.
Viewing received messages is supported.
OML O21 is the expected format for incoming order requests. Patient info is extracted, and if well formed, a patient is automatically created in the OpenELIS system. If the patient has already been sent before, a new patient shall not be created (provided PID 2.1 is the same value). Incomplete patient data will require patient info to be entered upon the order entry screen.
MSH|^!\&|SendingApplication||ReceivingApplication||MessageTimestamp||OML^O21^OML_O21|MessageID|D|2.5.1
PID||PatientID^^^^^LocationID|||LastName^FirstName^MiddleName|Mother'sName||Sex|||Address|||||^CivilStatus|^Religion||||||BirthCity
ORC|RequestType(NW or CA)|PROVIDER_ID|||||||||||||||||||||||||||TestLOINCCode
OBR||||EncounterType;EncounterUUID||OrderDateScheduled
The ORL O22 message format is used to communicate acknowledgment of a received order. It includes the values of the original order request.
MSH|^~\&|||||MessageTimestamp||ORL^O22^ORL_O22|1|P|2.5.1
MSA|AA|OriginalMessageID
PID||PatientID^^^^^LocationID|||LastName^FirstName^MiddleName|Mother'sName||Sex|||Address|||||^CivilStatus|^Religion||||||BirthCity
ORC|RequestType(NW or CA)|PROVIDER_ID|||||||||||||||||||||||||||TestLOINCCode
OBR||||EncounterType;EncounterUUID||OrderDateScheduled
The ORU R01 format is used for sending updates to the requesting system. It communicates the kind of result or status update it is it is (preliminary, final, reception, etc) by placing a value in the OBR-25 segment (ObservationResultStatus). If a result is present, it is returned in the OBX segment.
MSH|^~\&|^SendingApplication||^ReceivingApplication||20180420150004.917-0600||MessageType|MessageID|P|2.5.1
PID||PatientId^^^^^LocationId|||PatientName|MotherName||Sex|||PatientAddress|||||^CivilStatus|^Religion||||||BirthPlace
ORC|OrderControl|ProviderID|FillerOrderNumber||||||||||||||||||||||||||OrderType(testrequest)
OBR||||EncounterType;EncounterUUID||OrderDateScheduled|||||||||||||||||||ObservationResultStatus
OBX|1|DataType|Code^CodeTestName^CodeType||DataValue|DataUnits(opt)
NTE(opt segment)|||notes
Message Ids are generated by taking the current time and appending a 5 digit auto-incrementing value at the end for a 19 digit identifier (ie 2018042015005600001). Once the 5 digits reach 99999 it should loop back to 00001 (on our end, 00000 is reserved for when an error occurs in generating the next in the sequence)
Messages come into the OrderServlet.java where they are parsed and partially entered into the system as an ElectronicOrder. They are then tied to a real order on the regular order entry page. Outbound messages are saved to as an HL7MessageOut.
Start using cryptographic message signing to provide greater message security. See here.