| Table of Contents | ||
|---|---|---|
|
Overview
...
You can view a video demo of the LIS-EMR exchange between OpenMRS(EMR) and OpenELIS here
A critical workflow for high quality care is the timely and accurate exchange of laboratory orders and test results between the clinic and laboratories. To digitize this workflow, you need an electronic medical record (EMR) capable of capturing orders, and a laboratory information system (LIS/LIMS) capable of order entry and capturing of test results associated with that order. Using the most recent informatics standards, this digitized Lab Order and Results workflow SOP focuses on the use of FHIR and the OpenHIE architectural pattern for implementation, and includes several implementation approaches depending on context (i.e. direct bridge, older messaging standards only in the local systems). This Lab Order and Results workflow utilizes the FHIR Workflow Module and suggested Communication Patterns to implement the ordering of lab tests from an EMR to an LIS and resulting from LIS to EMR.
Implementer Guide
...
Getting Started
To get started in implementing the EMR-LIS workflow between electronic systems, it is best to understand the full scope of high level steps that will possibly need to be done, depending on your situation in the environment you are implementing in. In general, these high-level steps may need to be taken. Details about each of these steps and the possible caveats will follow.
...
The lab order workflow follows the OpenHIE specification for standard lab ordering between an EMR and LIS. The workflow is detailed in the following sequence diagram:
...
Interaction | Data | Transaction Options | |
|---|---|---|---|
1 | Create Lab Order | Order Save generates a new FHIR Task Bundled Order by creating a Task FHIR R4 Task Resource with a reference to a Service Request with order information | |
2 | Send Lab Order | FHIR Task bundled order is sent to the IOL. Task status is aligned with the FHIR workflow communication pattern found here | |
3,4 | Send New Lab Order | Bundled order is routed through the IOL to both the SHR and the LIS | |
5 | Save Order and Update Order Status | FHIR R4 Task Resource Status is updated locally to either | |
6 | Send New Lab Order | Bundled order is routed through the IOL to both the SHR and the LIS | |
7,8 | Send Order Update | IOL routes the updated FHIR R4 Tasks to the SHR and the EMR | |
9 | Update FHIR Task Status | FHIR task status updated locally |
Lab Results
...
Interaction | Data | Transaction Options | |
|---|---|---|---|
1 | Results Saved and FHIR Task Updated | The results save generates a FHIR R4 DiagnosticReport Resource () with referenced FHIR R4 Observation resources () to store the results, and a reference to the associated Patient and Task Resource. | |
2 | Search for Updated FHIR Tasks | FHIR R4 Search for Tasks based on tasks for which the owner is the EMR, and which have a status ‘completed’ | |
3 | Return FHIR Updated Tasks | FHIR R4 Task Resource with status ‘completed’ and reference to FHIR R4 DiagnosticReport | FHIR R4 bundle search response () |
4 | Search for Associated Diagnostic Reports | FHIR R4 Search for DiagnosticReports by UUID | |
5 | Return Associated Diagnostic Reports | FHIR R4 DiagnosticReport Resource with | |
6 | Update FHIR Task Status, Store DiagnosticReports and Save Results |
Developer Guide
...
Tutorial: Lab Order Communication between OpenMRS and OpenELIS
In this tutorial, we will use the resources from this documentation - with support from the Laboratory Workflow Implementation Guide and OpenHIE Architecture Specifications - to determine create a pilot implementation of Lab Test Order and Result Communication between an Electronic Medical Record (EMR) and a Lab Information System. We will use validated open-source solutions for each component of our pilot setup, and will use the OpenHIE specifications to guide our approach, the selection and roles of different components, and the language we use for disucssing the various concepts.
To get a better idea about the concepts and data elements were using, visit the Laboratory Workflows IG to a look at: 1. Our list of key concepts 2. Our logical model
We will focus on the following target architecture for our setup, which you can check out in the IG:
...
This architecture is based on the OpenHIE Specifications for Health Information Exchange components. For this tutorial, we will focus on using OpenMRS the reference implementation of an OpenHIE EMR, and OpenELIS, the reference implementation of an OpenHIE LIS.
...
Setup OpenRMS 3.x on top an instance of the Reference Application click here for more infromation
Install the Following Modules
FHIR2 module version >= 1.5.0
Lab on FHIR module
Configure the required settings
labonfhir.openElisUrl,The URL for the FHIR server where OpenELIS polls the Orders From.labonfhir.openElisUserUuid,UUID for the service user that represents OpenELIS
see more on Configuring the above Modules.
Note: The Lab test Concept should be of classTest,and should be mapped to aLoinc codethat matches a theTest Loinc Codein OpenELIS
Go to the Reff App (2.x) Patient Dashbord Prescribed Dashbord Prescribed Medication Widget. see
see more on Creating Orders using the Order Entry Owa.If the Lab on FHIR module is rightly configured ,it will generate the lab FHIR Bundle and push to the remote Fhir Server for OpenELIS to poll the orders
Start up the OpenELIS Update Task In order to be able to poll OpenELIS for available results, we need to turn on the following task in the OpenMRS scheduler: System Administration → Advanced Administration→ Advanced Administration → Scheduler → Manage Scheduler
Enable the patient-test-results-app for the 3.x Frontenx. Go to the Patient DashBoard in 3.x ui and click Test Results.
...
iSantéPlus
Install iSantePlus using one of these approaches.
Install the Following Modules
FHIR2 module version >= 1.5.0
Lab on FHIR module
IsantePlus FHIR Module
Note : The above modules are installed by default by the docker setup
Configure the required settings .
labonfhir.openElisUrl,The URL for the FHIR server where OpenELIS polls the Orders From.labonfhir.openElisUserUuid,UUID for the service user that represents OpenELIS
see more on Configuring the Lab On FHIR Modules.
To place Lab Orders ,Fill the Laboratory Analysis Form , select OPenELIS as destination Lab and Save.
Find Patient → Patient DashBord → Forms → Laboratory Analysis NBAnalysis NB. The Patient Must have an active vistStart up the OpenELIS Update Task in order to poll for Completed Results from OpenELISSystem OpenELIS
System Administration → Advanced Administration → Scheduler → Manage SchedulerTo View The results ,Go to Laboratory History on the Patient DashBoard under General Actions.
Find Patient → Patient DashBord → Laboratory History
...
OpenELIS Global 2.6.x
The FHIR based Lab Workflow is supported in OpenELIS 2.6 .
Start an instance of OpenELIS with the following configuration properties set in the properties file.
org.openelisglobal.fhirstore.uri=<localFhirServerUrl>. This is the Fhir Server that runs paralel with OPenELISorg.openelisglobal.remote.source.uri=<remoreFhirServerUr>. This is the Fhir server that the Lab on FHIR module points to ie via thelabonfhir.openElisUrlorg.openelisglobal.remote.source.updateStatus=trueorg.openelisglobal.remote.source.identifier=Practitioner/<userUuuid>.This is the UUID of the user who created the Order ielabonfhir.openElisUserUuidorg.openelisglobal.task.useBasedOn=trueorg.openelisglobal.fhir.subscriber=h<remoreFhirServerUrl>.org.openelisglobal.fhir.subscriber.resources=Task,Patient,ServiceRequest,DiagnosticReport,Observation,Specimen,Practitioner,Encounter
Ensure OpenELIS has the test that maps to the same LOINC code as the test Concept in OpenMRS. This can be added via theAdmin the
Admin page → Test Management → Add TestsConfigure OpenELIS to accept electronic orders.
Admin → Order Entry Configuration → external ordersSearch for the Electronic Orders ie Order → Electronic Orders and then Complete the Order Note that the user should have the right Lab Unit Priviledges to complete the Order
After Results are captured and Validated , OpenELIS sends back the results to OpenMRS as a Diagnostic Report with an Observation
...
Zimbabwe HIE
From the point of care, clinicians record lab request details, including sample type, test type, patient details and referral facility.
The record is stored in the local Impilo Mysql database.
A cron job is run periodically to check if there are any new changes.
The Kafka producer listens for changes and pushes new records to OpenHIM through an OpenHIM channel. Each facility has its own channel.
From the LIMS side, the sent records are pulled from OpenHIM and processed accordingly by the system.
On completion, the results are sent to the OpenHIM channel.
Impilo EHR fetches results from the OpenHIM channel through its Kafka consumer.
The results are saved in EHR Impilo’s mysql database.
LNSP Workflow
...
OpenHIM: serves as the Interoperability Layer for SEDISH. Through definition of routing channels it enables requests to be forwarded to the intended recipient systems. Through extensions that can be added to it, called mediators, OpenHIM can provide more complex orchestration of requests, such as handling of the XDS.b profile. OpenHIM mediators also enable compatibility with new messaging standards, such as FHIR or CDA version 3, if the need arises.
All transactions that go through the Interoperability Layer are audited and can be inspected. Transaction that fail can be retried from within the admin interface. The IL also provides a centralized point for managing client access to SEDISH.
ISantePlus EMR: Sends patient resource bundle is sent to SHR endpoint and the client registry
The EMR sends lab request to OpenELIS.
OpenELIS: A lab FHIR bundle is sent from from the laboratory information system to the SHR endpoint.
SHR saves the patient and lab bundle : The SHR endpoint accepts the lab bundle and immediately saves it to the HAPI FHIR server. If the save is successful, the request is considered successful, and a success response is returned.
Client Registry: The client compares and matches the patient as received.
SHR Processes the Lab Bundle: The save operation triggers asynchronous workers synchronized via Kafka topics. These workers modify and enhance the lab bundle through several tasks:
Service Request Translation: Codes for service requests are translated to CIEL/standard libraries/IPMS codes through communication with OCL (Open Concept Lab) for proper translation into IPMS HL7 messages.
Location Mapping: Location information is mapped to IPMS locations with associated metadata for later translation into HL7 messages.
Validation: The lab bundle is validated to ensure all required information is present.
HL7 Translation: The enhanced lab bundle is sent to an HL7 translator to be translated into an ADT (Admit, Discharge, Transfer) message for patient registration.
SHR Sends ORM Order Message to IPMS: The ORM message is sent to IPMS (Information Processing Management System) using a MLLP (Minimal Lower Layer Protocol) HL7 client built into the SHR.
SHR Handles Message Results: IPMS processes the order and sends back an ORU (Lab Result) message with the results. These results are handled similarly to the previous steps, ensuring the right patient, task, and service requests are updated with diagnostic requests and observations.
EMR Retrieves Results The ISante Plus EMR queries the HIE for owned tasks that have a status indicating the results are available.
Kafka workflows: analytics are pushed to the data warehouse.