Laboratory Workflows
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.
- Identify the minimum data set to be exchanged between the systems.
- Use a universally unique identification system (coding) for identifying and mapping lab tests for both systems.
- Extract or create a laboratory test catalog from both the EMR and LIS.
- Crosswalk the listing of lab tests between the EMR and LIS to map those lab tests to the unique ID system (coding).
- Map all other relevant concepts and identifiers needed between EMR and LIS
- Identify the data exchange method between the systems based on your HIE and infrastructure context.
- Build out the technological approach for the workflow within and between the EMR and LIS.
- Identify and develop mechanisms for handling potential issues and caveats.
Step #1: Identify a minimum dataset
Working with stakeholders, key partners, and system users, your team will need to identify the minimum data set to be exchanged between the systems. Resources to inform the minimum data set could be paper forms that are used by providers for clinical orders, lab order and test result forms used by the laboratory, data sets from the EMR and LIS, and input from relevant technical working groups/steering committees, clinical partners and laboratory partners, and system users. It is critical that the technical stewards / teams of the systems participate in this definition of the minimum data set to help determine what data is available in the systems, identify gaps in data or system abilities in capturing/providing that data, and feasibility in the system utilizing that data from the other system.
Resources
Step #2: Identify a standard coding terminology
Successful communication of laboratory orders can only happen if each system involved is using a
common language for key concepts like Lab test types. Aa common terminology is critical to correctly
understand and process the messages sent and recieved. Many EMR and LIS systems have not been built
using the same terminology for the laboratory orders and results, and therefore, must be mapped to
an agreed upon common terminology for that exchange. To do this, your team will need to work with
stakeholders and key partners to either create a local set of shared terminology that uses unique IDs
for each term, or your team can utilize an international standard coding system to create this shared terminology set.
We recommend using the LOINC international standard for that shared terminology set of orders and results needed for your context.
Resources - LOINC specification
Step #3: Identify the relevant concepts from each system
Each EMR, LIS, or other system that is partificating in the Laboratory Workflows will have a set of concepts key for this communication. Some systems use standard terminologies like Loinc, and others have custom concepts unique to that system. In both cases, we need identify and catalog the relevant concepts in each system.
This exercise can be done manually, using a spreadsheet or similar tool to create a line listing of the supported laboratory test types, result types, panels, units, and other key concepts from each system. For example, we might end up with two lists, one from the EMR and one from the LIS. This test catalog will be used to map between the systems in step 4.
Note: Alternatively, we can use a terminology management service such as Open Concept Lab for cataloging, mapping, and managing our concepts. A tutorial for this approach is coming soon!
Resources - Example: Haiti OpenELIS Lab System Test Catalog
Step #4: Create Mappings between the concept catalogs
We need to crosswalk the listing of lab tests between the EMR and LIS to map those lab tests to the unique ID system (coding)
In step #2, your team identified the shared terminology set that would stand as the source of truth for all terminologies that are exchanged in your HIE and provide unique identifiers for that terminology. Using your laboratory test catalogs created in step #3, you will need to now map your lab tests and results from both the EMR and the LIS to the shared terminology set. We recommend the use of LOINC codes as the mapping identifier.
Problem Solving: In some cases, the EMR may allow ordering tests by panel. If the order only provides the panel and does not include individual tests, you will need to map panels to individual tests for the order and develop an additional mechanism to handle the translation for the proper exchange to the LIS.
Resources - Example: Botswana EMR-LIS Terminology Mapping - Example: Haiti iSantePlus Terminology Mapping to LOINC
Step 5: Map all other relevant concepts and identifiers needed between EMR and LIS
Many times in systems that are not based on standards, the technical architectural decisions means the requirements for data fields may be different than the requirements in other systems for those data elements. In these cases, when messages are exchanged between systems, those data elements that fit the requirements for the sending system do not meet the requirements for that data in the receiving system and will cause an error, and ultimately the transaction fails and the message and its data is not accepted into the receiving system. To minimize errors of this type, ensure there is mapping of all other relevant concepts between EMR and LIS. Some of the most common concepts/data that might have issues do to requirements and algorithms tied to that data include (but are not limited to):
- Patient Identifiers
- Facility Identifiers
- System Identifiers
Problem Solving: Frequently, the EMR and LIS have different required formats, lengths, or algorithms for identifiers that can cause errors and mismatches when messaging between systems. There may be negotiating and workarounds that will need to be discussed and a mechanism for handling developed. An example of this was in the Haiti iSantePlus (OpenMRS) exchange with a proprietary lab system that had specific algorithms attached to the patient identifiers fields in their database that caused a mismatch with the data sent. In addition, there were other data elements that needed “massaging” due to character limits that don’t accommodate the full length of the data sent. These types of issues needed extensive negotiation and custom development of how the data in the message would be constructed, formatted, and consumed in order to reliably exchange data between these systems.*
Step #6: Identify data exchange patterns based on your HIE and infrastructure context
There are multiple ways to approach the exchange of data, and will be decided by understanding the context in which your exchange will operate, and the requirements for data availability from the exchange. You will use either a push of data from a system, or a pull of data from a system, or a mixed method approach depending on the implementation, system availability and connectivity, components available in the HIE, and requirements for timeliness and data availability from the exchange. For example, you can set up your exchange of orders to use any of the following approaches:
- Push data from EMR to central repository (i.e. SHR), the central repository alerts the LIS, and subsequently the data is pulled by the LIS
- The LIS can periodically check for data to be pulled from an EMR or a central repository system (i.e. SHR), conducting the pull with all data with an order status of ordered
- An order is pushed by an EMR automatically to the LIS. In this case, there is no way to know if the order reached the LIS or not. We do not recommend this approach when using FHIR due to the lack of any receipt acknowledge messaging in the FHIR workflow standard.
Step #7: Build out the technological approach for the workflow within and between the EMR and LIS
Use the technical artifacts in the Implementation Guide and the detailed technical sections in this SOP to develop and configure the EMR and LIS exchange. Every EMR-LIS exchange is somewhat unique, and will require customization of these artifacts and approaches to meet the needs of the context you are working in. For additional support during your build phase, engage with other developers and implementers in the relevant global goods communities of practice, such as OpenHIE LIS COP, OpenMRS FHIR Squad, and LIS software forums (i.e. OpenELIS). Many folks are eager to share their experience and provide answers for how to use these technical artifacts and tools to achieve this exchange. In addition, our team is happy to answer questions you may have when setting up your exchange following this guide.
Resources - OpenMRS FHIR Squad, FHIR Squad Bi-Weekly Calls, and Talk FHIR Forum OpenHIE LIS COP and Slack OpenELIS Forum
Step #8: Identify and develop mechanisms for handling potential issues and caveats
Exchanges between EMR and LIS are not an easy thing to accomplish due to the many nuances to the workflows and the data collected and exchanged in the process. Your team will need to identify additional potential issues for the exchange specific to the workflows you are addressing, and develop mechanisms to handle those. Other problem areas to look for are, but no limited to: - Canceled and Rejected lab orders - Corrected Results after report out - Specialized and interim/intermediate results (e.g., Microbiology) - Ordering of test panels rather than individual lab tests - Intermittent connectivity and infrastructure issues
Communication Overview
Lab Orders
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 rejected or accepted. A FHIR R4 ServiceRequest Resource (example) is created for order processing with a reference to the associated task. EMR test requests and LIS orders are matched based on LOINC codes. |
|
| 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.
Data Model
Task
The Task resource is created along with the corresponding ServiceRequest resource when a clinician creates a TestOrder and decides to send it to OpenELIS.
This resource is used to track the status of the lab order request from initiation to completion, and as a container for all other resources related to the given order.
Example Task:
{
"resourceType": "Task",
"id": "88ffa7fb-0419-4097-8b45-24f0d843c5ea",
"identifier": [
{
"system": "http://isanteplus.org/ext/task/identifier",
"value": "88ffa7fb-0419-4097-8b45-24f0d843c5ea"
}
],
"basedOn": [
{
"reference": "ServiceRequest/ebf83ba0-9d3c-497f-9aa0-d839ec506202",
"type": "ServiceRequest"
},
{
"reference": "ServiceRequest/73e96ecb-a78d-41c8-a55f-d9b90f759e5f",
"type": "ServiceRequest"
}
],
"status": "requested",
"intent": "order",
"for": {
"reference": "Patient/e14e9bda-d273-4c74-8509-5732a4ebaf19",
"type": "Patient"
},
"encounter": {
"reference": "Encounter/7f5aabd9-6375-47c8-a8d6-30f219b6e2f1",
"type": "Encounter"
},
"authoredOn": "2020-04-28T17:33:19+00:00",
"owner": {
"reference": "Practitioner/f9badd80-ab76-11e2-9e96-0800200c9a66",
"type": "Practitioner"
}
}
ServiceRequest
The ServiceRequest resource represents the TestOrder placed in OpenMRS. It is referenced from the Task with the Task.basedOn element, and sent to OpenELIS with the Task to initiate the processing of the order.
Example Service Request:
{
"resourceType": "ServiceRequest",
"id": "73e96ecb-a78d-41c8-a55f-d9b90f759e5f",
"status": "active",
"intent": "order",
"code": {
"coding": [
{
"code": "790AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
},
{
"system": "http://loinc.org",
"code": "14682-9"
},
{
"system": "urn:oid:2.16.840.1.113883.3.7201",
"code": "790"
}
]
},
"subject": {
"reference": "Patient/e14e9bda-d273-4c74-8509-5732a4ebaf19",
"type": "Patient"
},
"encounter": {
"reference": "Encounter/7f5aabd9-6375-47c8-a8d6-30f219b6e2f1",
"type": "Encounter"
}
}
DiagnosticReport
The DiagnosticReport resource is the container for the results of an Order, and holds these results in the DiagnosticReport.result element as references to Observation resources.
Example Diagnostic Report
{
"resourceType": "DiagnosticReport",
"id": "93",
"meta": {
"versionId": "1",
"lastUpdated": "2020-04-28T17:33:36.163+00:00",
"source": "#55t4lpDZF4q3TCZ0"
},
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><div class=\"hapiHeaderText\"> Untitled Diagnostic Report </div><table class=\"hapiPropertyTable\"><tbody><tr><td>Status</td><td>FINAL</td></tr></tbody></table></div>"
},
"identifier": [
{
"system": "https://isanteplusdemo.com/openmrs/ws/fhir2/",
"value": "ebf83ba0-9d3c-497f-9aa0-d839ec506202"
}
],
"status": "final",
"code": {
"coding": [
{
"code": "1008AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
},
{
"system": "http://loinc.org",
"code": "22748-8"
},
{
"system": "urn:oid:2.16.840.1.113883.3.7201",
"code": "1008"
}
]
},
"subject": {
"reference": "Patient/2"
},
"result": [
{
"reference": "Observation/92",
"type": "Observation"
}
]
}
Observation
The Observation resource contains the results of the Lab Order request.
Example Observation:
{
"resourceType": "Observation",
"id": "92",
"meta": {
"versionId": "1",
"lastUpdated": "2020-04-28T17:33:36.124+00:00",
"source": "#xAVz0uUE6c3l42Za"
},
"identifier": [
{
"system": "https://isanteplusdemo.com/openmrs/ws/fhir2/",
"value": "ebf83ba0-9d3c-497f-9aa0-d839ec506202"
}
],
"status": "final",
"code": {
"coding": [
{
"code": "1008AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
},
{
"system": "http://loinc.org",
"code": "22748-8"
},
{
"system": "urn:oid:2.16.840.1.113883.3.7201",
"code": "1008"
}
]
},
"subject": {
"reference": "Patient/2"
},
"valueQuantity": {
"value": 55,
"unit": "UI/L"
}
}
Patient
The Patient resource contains vital information for OpenELIS to fullfill the lab order request, and is referenced by the Task.
Example Patient:
{
"resourceType": "Patient",
"id": "e14e9bda-d273-4c74-8509-5732a4ebaf19",
"identifier": [
{
"id": "5981a256-d60c-44b1-beae-9bdd2cf572f8",
"use": "official",
"system": "iSantePlus ID",
"value": "10012R"
},
{
"id": "75a67d54-6fff-44d1-9c3e-2116c967b475",
"use": "usual",
"system": "Code National",
"value": "100000"
},
{
"id": "29447d21-3cd6-42a9-9ab2-79ebfa710a01",
"use": "usual",
"system": "ECID",
"value": "04d759e0-5d02-11e8-b899-0242ac12000b"
}
],
"active": true,
"name": [
{
"id": "511275de-e301-44a3-95d2-28d0d3b35387",
"family": "Mankowski",
"given": [
"Piotr"
]
}
],
"gender": "male",
"birthDate": "1987-01-01",
"deceasedBoolean": false,
"address": [
{
"id": "d4f7c809-3d01-4032-b64d-4c22e8eccbbc",
"use": "home",
"country": "Haiti"
}
]
}
Useful Links
Relevant FHIR Docs * Using Tasks in a RESTful Context * Workflow Module * Diagnostic Module * Example: Workflow states for a lab order for a blood test * Option G: POST of Task to fulfiller's system
Relevant OpenMRS Talk Posts The handling and mapping of lab order status for the lab workflow
Openmrs 3.x
-
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
- Order Entry Ui Module
- Order Entry Owa
-
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 MedicationWidget.
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→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
NB. The Patient Must have an active vist -
Start up the OpenELIS Update Task in order to poll for Completed Results from OpenELIS
System Administration→Advanced Administration→Scheduler→Manage Scheduler -
To View The results ,Go to
Laboratory Historyon 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 OPenELIS -
org.openelisglobal.remote.source.uri=<remoreFhirServerUr>. This is the Fhir server that the Lab on FHIR module points to ie via thelabonfhir.openElisUrl org.openelisglobal.remote.source.updateStatus=trueorg.openelisglobal.remote.source.identifier=Practitioner/<userUuuid>.This is the UUID of the user who created the Order ielabonfhir.openElisUserUuid-
org.openelisglobal.task.useBasedOn=true -
org.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 the
Admin page→Test Management→Add Tests
-
Configure OpenELIS to accept electronic orders.
Admin→Order Entry Configuration→external orders
-
Search for the Electronic Orders ie
Order→Electronic Ordersand 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