-
Notifications
You must be signed in to change notification settings - Fork 79
Result Reporting
Result reporting currently occurs between OpenELIS and the iSantéPlus module for OpenMRS, we are developing a module with only the Lab interface for OpenMRS and this documentation will be updated with links when it's available for download.
Result reporting must be switched on and a sending address must be provided at ResultReportingConfiguration.do for the functionality to be activated.
- Navigate to http://localhost:8080/OpenElis/SampleEntryConfigMenu.do as an admin user
- Edit value "external orders" to be set to true
- Navigate to http://localhost:8080/OpenElis/ResultReportingConfiguration.do, this is also available under the admin menu when logged in as an administrator, under the heading "Result Reporting COnfiguration"
- Under "Result Reporting" set value to enable, and provide the url where responses should be sent to (including http://)
- Save the new result reporting configuration
- OpenELIS is now ready to send and receive orders (see workflow)
- Order request is received (http://localhost:8080/{OEcontext}/OrderRequest)
- Order request id is entered into order entry page as referring order number (http://localhost:8080/OpenElis/SamplePatientEntry.do). This value can be found in Electronic Orders (http://localhost:8080/OpenElis/ElectronicOrders.do)
- OE fetches info about the order, requests any missing information be entered manually.
- OE uses LOINC codes to match the test between the requesting system and the OpenELIS Test Catalog.
- Order exists in regular order workflow.
- Updates to order trigger information to be sent back to the requesting system at whatever address has been provided in "Result Reporting".
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.