This article provides a thorough discussion of LIS-SIMRS integration, from basic concepts to technical implementation. Learn how to improve data accuracy, speed up workflows, and meet interoperability standards such as HL7 and FHIR.
Hospital laboratories often operate with manual systems or standalone LIS, causing duplicate data entry, potential transcription errors of up to 10%, and delays in delivering results to doctors and patients. Examination result data must be printed, then re-entered into the SIMRS, or at least uploaded manually. This not only wastes time and resources but also increases the risk of fatal errors in diagnosis and patient care. In the context of modern healthcare that demands speed and accuracy, integration between the Laboratory Information System (LIS) and the Hospital Management Information System (SIMRS) is no longer an option, but a strategic necessity. Effective integration can cut patient waiting times, increase laboratory operational efficiency by up to 30%, and ensure consistent and accurate patient data across the hospital ecosystem. This article will guide you in depth through various technical and managerial aspects of the LIS-SIMRS integration process, from the basic concepts of interoperability, implementation details using standards such as HL7 and FHIR, to sample code that you can apply.
Interoperability is the ability of two or more systems to exchange information and use it effectively. In the hospital context, LIS (Laboratory Information System) is a system specifically designed to manage all aspects of laboratory operations, from patient registration, test orders, sample management, quality control, to result reporting. Meanwhile, SIMRS (Hospital Management Information System) is a broader system, covering patient data management, registration, electronic medical records, billing, pharmacy, and other modules. Without adequate integration, the LIS will become a data silo, forcing staff to perform duplicate data entry or manual data transfer, which is prone to errors and inefficiency.
The main benefits of LIS-SIMRS integration are very significant. First, the elimination of duplicate data entry drastically reduces the risk of transcription errors that can be fatal to patient diagnosis. Second, it speeds up the turnaround time (TAT) for laboratory results, which means doctors can make clinical decisions faster and patients receive treatment more quickly as well. Third, it improves overall operational efficiency, freeing staff from repetitive administrative tasks so they can focus on patient care. Fourth, it ensures consistency and accuracy of patient data across the system, supporting comprehensive electronic medical records and better data-driven decision-making.
Nevertheless, this integration project is not without challenges. The complexity of healthcare data, differences in data formats between systems from different vendors, and the not insignificant initial implementation costs are often obstacles. Resistance to change from staff accustomed to old workflows also needs to be managed. Choosing the right interoperability standard is key to overcoming these challenges. Without agreed-upon standards, every integration will become a costly and difficult-to-maintain custom project.
This is where the role of interoperability standards such as HL7 (Health Level Seven) and FHIR (Fast Healthcare Interoperability Resources) becomes crucial. HL7 version 2.x (for example v2.5.1 or v2.6) has been the de facto standard for clinical data exchange for decades, especially in laboratory and radiology environments. HL7 v2.x messages are delimited, text-based, and use the MLLP (Minimal Lower Layer Protocol) over TCP/IP. On the other hand, FHIR R4 (Release 4) is a more modern standard, based on RESTful API, using JSON or XML format, and designed for broader interoperability in the web and mobile era. Although DICOM is used for medical imaging, our focus for lab data is HL7 and FHIR.
In designing the integration architecture, there are several approaches. Point-to-point integration, where each system communicates directly with one another, may seem simple at first but becomes unscalable and difficult to manage as the number of systems grows. The recommended approach is to use an Integration Engine or Enterprise Service Bus (ESB). The integration engine acts as a central middleware that can receive, transform, route, and monitor messages between various systems, making it a more robust, flexible, and scalable solution for complex hospital environments.
The choice of communication standards is a fundamental step in LIS-SIMRS integration. The majority of long-operating LIS tend to support HL7 v2.x, with versions such as v2.5.1 or v2.6 being the most common. HL7 v2.x messages are sent over the TCP/IP protocol using MLLP, which adds header and terminator bytes around the HL7 message itself. Meanwhile, modern SIMRS and national health platforms such as SatuSehat in Indonesia are increasingly adopting FHIR R4. FHIR utilizes the HTTPS protocol and RESTful API, with data payloads in JSON or XML format. Therefore, a bridge or transformation layer is often needed to translate messages between these two standards.
Communication protocols also play an important role. For HL7 v2.x, communication usually occurs through a persistent TCP/IP connection, with the LIS sending messages to a specific port on the integration engine or SIMRS, and vice versa. For FHIR R4, communication is done through HTTP(S) POST/GET requests to the API endpoint. The use of HTTPS is highly recommended to ensure the security and encryption of data in transit, especially for sensitive patient data. Make sure SSL/TLS certificates are properly managed and use secure protocol versions (at least TLS 1.2).
Another crucial aspect is data mapping. Every data element to be exchanged must be accurately mapped from one system to another. This includes patient demographic data (for example, Medical Record Number/MRN from SIMRS to PID-3 in HL7, patient name to PID-5), laboratory orders (for example, Order ID from SIMRS to ORC-2 in HL7, test codes using the LOINC standard), and laboratory results (for example, result values to OBX-5, units to OBX-6, as well as the SNOMED CT standard for result terminology if needed). Errors in data mapping can lead to inconsistent data or even incorrect results, so validation by clinical and IT experts is essential.
For integration technology, there are several options. Integration Engines such as Mirth Connect (now known as NextGen Connect) version 4.4.0, or Apache Camel, are highly recommended solutions. Integration engines provide a visual interface for building integration workflows, performing data transformation (HL7 to FHIR or vice versa), message routing, and monitoring. Another alternative is Custom API Development using modern frameworks such as Laravel 11.x (with PHP 8.2+), Node.js (v20 LTS), or Spring Boot (with Java 17+). This allows full flexibility in building bridge APIs, but requires more development and maintenance effort. Relational databases such as PostgreSQL 16.x or MySQL 8.x are often used to store transaction logs or temporary data.
The LIS-SIMRS integration workflow generally follows this pattern: 1. When a doctor creates a lab order in SIMRS, SIMRS will send an order message (HL7 ORM^O01 or FHIR ServiceRequest) to the LIS. 2. The LIS will confirm receipt of the order and may send status updates back to SIMRS. 3. After the test is completed and the results are validated in the LIS, the LIS will send the results (HL7 ORU^R01 or FHIR DiagnosticReport) to SIMRS. 4. Sometimes, patient data updates from SIMRS (HL7 ADT^A08 or FHIR Patient) also need to be sent to the LIS to ensure demographic data is always in sync. Each of these steps requires careful data validation and error handling.
Understanding how HL7 messages are parsed and how to interact with the FHIR API is at the core of integration implementation. In this section, we will look at two code examples: one for parsing an HL7 ORU^R01 message (laboratory results) using Node.js, and another for creating a laboratory order (ServiceRequest) to a FHIR server using Python.
The first example shows how we can extract important information from an HL7 ORU^R01 message. We will use the node-hl7 library (version 1.0.0-beta.10) in a Node.js environment (version 20 LTS). HL7 messages, although text-based, have a specific structure of segments and fields. This library makes it easy for us to access those values with intuitive syntax, such as retrieving the patient's MRN from the PID.3.1 segment or the test result value from OBX.5.1. This is very important for processing lab results that come into SIMRS.
// Node.js (v20 LTS) with 'node-hl7' library (v1.0.0-beta.10)
// npm install node-hl7
const HL7 = require('node-hl7');
const fs = require('fs');
const hl7Message = `MSH|^~&|LIS_APP|LAB_FAC|SIMRS_APP|HOSP_FAC|20231027103000||ORU^R01|MSGID123|P|2.5.1
PID|||12345678^^^MRN^MRN||DOE^JOHN^A||19800101|M|||123 MAIN ST^^ANYTOWN^CA^90000^USA||(555)123-4567|||S|||1234567890
ORC|RE|ORD123|REQ123||CM|||||20231027100000|LABDOCTOR^DR
OBR|1|ORD123|REQ123|GLUCOSE^Glucose Test^L|||20231027090000|||||||||LABTECH^TECHNICIAN|||20231027102000|||||||F
OBX|1|NM|GLUCOSE^Glucose Level^L|1|95|mg/dL|70-100|N|||F|||20231027102500|LABTECH^TECHNICIAN`;
try {
const parser = new HL7.Parser();
const message = parser.parse(hl7Message);
console.log("Parsed HL7 Message:");
console.log(`Message Type: ${message.get('MSH.9.1')}^${message.get('MSH.9.2')}`);
console.log(`Patient MRN: ${message.get('PID.3.1')}`);
console.log(`Patient Name: ${message.get('PID.5.2')} ${message.get('PID.5.1')}`);
console.log(`Order ID: ${message.get('ORC.2.1')}`);
console.log(`Test Name: ${message.get('OBR.4.2')}`);
console.log(`Result Value: ${message.get('OBX.5.1')} ${message.get('OBX.6.1')}`);
console.log(`Result Status: ${message.get('OBX.11.1')}`);
// Example: Convert to JSON (simplified)
const resultJson = {
patientMRN: message.get('PID.3.1'),
patientName: `${message.get('PID.5.2')} ${message.get('PID.5.1')}`,
orderId: message.get('ORC.2.1'),
testName: message.get('OBR.4.2'),
result: {
value: parseFloat(message.get('OBX.5.1')),
unit: message.get('OBX.6.1'),
range: message.get('OBX.7.1'),
status: message.get('OBX.11.1')
}
};
console.log("\nConverted to JSON:");
console.log(JSON.stringify(resultJson, null, 2));
} catch (err) {
console.error("Error parsing HL7 message:", err);
}
The code above shows how an HL7 message can be parsed into more easily accessible objects. Once parsed, the data can be easily converted into JSON format or stored in the SIMRS database. This is vital for automating the process of receiving lab results, reducing manual intervention, and ensuring consistent data. Fields such as PID.3.1 (Patient ID) and OBX.5.1 (Result Value) are examples of keys that must be extracted and correctly mapped to the SIMRS data structure.
The second example is how to send a laboratory order to a FHIR server using the fhirclient library (version 4.0.0) in Python (version 3.9+). This simulates how a modern SIMRS can create a FHIR ServiceRequest to request tests from a LIS or another system that supports FHIR. We need to specify the patient reference, test code (using the LOINC standard), and other related information. FHIR Resources such as ServiceRequest, Patient, and Practitioner are interconnected through references, creating a rich and structured data ecosystem.
# Python (v3.9+) with 'fhirclient' library (v4.0.0)
# pip install fhirclient requests
from fhirclient import client
from fhirclient.models.servicerequest import ServiceRequest
from fhirclient.models.reference import Reference
from fhirclient.models.codeableconcept import CodeableConcept
from fhirclient.models.coding import Coding
import requests
import json
# FHIR server settings
settings = {
'app_id': 'my_simrs_app',
'api_base': 'http://localhost:8080/fhir' # Example HAPI FHIR server base URL
}
smart = client.FHIRClient(settings=settings)
# Patient reference (assuming patient with ID 'patient-123' exists in FHIR server)
patient_ref = Reference()
patient_ref.reference = "Patient/patient-123"
patient_ref.display = "John Doe"
# Code for Glucose Test (LOINC code example)
glucose_code = Coding()
glucose_code.system = "http://loinc.org"
glucose_code.code = "15074-8"
glucose_code.display = "Glucose [Moles/volume] in Blood"
glucose_concept = CodeableConcept()
glucose_concept.coding = [glucose_code]
glucose_concept.text = "Glucose Test"
# Create ServiceRequest
sr = ServiceRequest()
sr.status = "active" # active, draft, completed, entered-in-error, etc.
sr.intent = "order" # proposal, plan, order, etc.
sr.category = [CodeableConcept(coding=[Coding(system="http://terminology.hl7.org/CodeSystem/servicerequest-category", code="laboratory", display="Laboratory")])]
sr.code = glucose_concept
sr.subject = patient_ref
sr.authoredOn = "2023-10-27T10:00:00+07:00" # ISO 8601 format
sr.requester = Reference(reference="Practitioner/dr-smith", display="Dr. Smith") # Ordering practitioner
# Convert to JSON and send to FHIR server
try:
sr_json = sr.as_json()
print("Generated FHIR ServiceRequest JSON:");
print(json.dumps(sr_json, indent=2))
# Make a POST request to the FHIR server
headers = {'Content-Type': 'application/fhir+json'}
response = requests.post(f"{settings['api_base']}/ServiceRequest", data=json.dumps(sr_json), headers=headers)
response.raise_for_status() # Raise an exception for HTTP errors
print(f"\nServiceRequest created successfully. Status: {response.status_code}")
print(f"Response: {response.json()}")
except requests.exceptions.RequestException as e:
print(f"Error sending FHIR ServiceRequest: {e}")
except Exception as e:
print(f"An unexpected error occurred: {e}")
This Python code demonstrates the process of constructing a ServiceRequest object that conforms to the FHIR R4 specification. This object is then converted into JSON format and sent to the FHIR server endpoint. The use of the fhirclient library helps with automatic validation of the FHIR structure before sending, reducing the possibility of errors. The FHIR server endpoint can be an implementation such as HAPI FHIR (version 6.8.x) running locally or in the cloud. It is important to ensure that the reference (for example, Patient/patient-123) actually exists on the FHIR server to avoid validation errors.
Data validation is the foundation of any successful integration. Every message entering or leaving the integration system must pass a series of strict validations. For example, ensuring that the received Medical Record Number (MRN) has the correct format and matches the SIMRS pattern, the LOINC or SNOMED CT codes used for tests and lab results comply with the agreed terminology standards, and the lab result values are within a logical range or match the expected data type. For FHIR messages, schema validation is often already built into the FHIR server (for example, HAPI FHIR automatically validates resource structures). For HL7, custom validators or transformation rules on the integration engine need to be developed to ensure data integrity.
The following is an example of a realistic HL7 ORU^R01 payload, including several OBX segments to show different test results, such as glucose and cholesterol. This structure illustrates how lab result information is encapsulated and sent from the LIS to the SIMRS.
MSH|^~&|LIS_APP|LAB_FAC|SIMRS_APP|HOSP_FAC|20231027143000||ORU^R01^ORU_R01|MSGID456|P|2.5.1
PID|||98765432^^^MRN^MRN||WIDODO^BUDI^S||19750515|M|||JL. MERDEKA 10^^JAKARTA^DKI^10120^ID||(62)812-3456-7890|||M|||9876543210
PV1||I|INPATIENT_WARD^ICU||||REFER_DR^DR. ANITA|||||||||LAB_ADMIT^ADMISSION|||REG_NUM_8765
ORC|RE|ORD456|REQ456||CM|||||20231027140000|DR. ANITA^ANITA
OBR|1|ORD456|REQ456|GLUCOSE^Glucose Plasma^L|||20231027130000|||||||||LABTECH1^RUDI|||20231027141500|||||||F
OBX|1|NM|GLUCOSE^Glucose Level^L|1|125|mg/dL|70-100|H|||F|||20231027141000|LABTECH1^RUDI
OBR|2|ORD457|REQ457|CHOLESTEROL^Total Cholesterol^L|||20231027130000|||||||||LABTECH1^RUDI|||20231027142000|||||||F
OBX|1|NM|CHOLESTEROL^Total Cholesterol^L|1|210|mg/dL|0-200|H|||F|||20231027141500|LABTECH1^RUDI
The HL7 payload above consists of several key segments: MSH (Message Header) for general message information, PID (Patient Identification) for patient details, PV1 (Patient Visit) for visit information, ORC (Common Order) for general order details, OBR (Observation Request) for specific observation request details (for example, glucose or cholesterol tests), and OBX (Observation Result) for the results of those observations. Note how each test has its own OBR and OBX segments. Fields such as OBX.5.1 (result value) and OBX.6.1 (unit) are very important to parse correctly.
Error handling is another vital aspect. Every failed transaction must be logged in detail, including the error message, timestamp, and the message context that caused the failure. A robust logging system is key, often integrated with monitoring systems such as Prometheus/Grafana or the ELK Stack (Elasticsearch, Logstash, Kibana). Errors can be categorized into retriable errors (for example, temporary network connection issues) and non-retriable errors (for example, persistent data validation errors).
Example Error Message and Its Handling:
ACK|AR|200|Required field missing: PID-3AR - Application Reject) because the required Patient ID field (PID-3) is not filled in or its format is incorrect. Handling: The integration system must log this error with message details and timestamp. Automatic notifications must be sent to the IT/operations team. If the cause is formatting, the system may attempt to reformat, but if the data is indeed empty or invalid, the message must be marked as failed and require manual intervention. Automatic resending without modification is not recommended for this type of error.{"resourceType":"OperationOutcome","issue":[{"severity":"error","code":"invalid","details":{"text":"Patient reference 'Patient/non-existent-id' not found"}}]}Patient/non-existent-id) used in the ServiceRequest was not found on the FHIR server. Handling: The integration system must log this error and send a notification. Before creating a ServiceRequest, SIMRS must verify the existence of the corresponding Patient resource on the FHIR server. If the patient is not yet registered, SIMRS must create the Patient resource first or identify an input error on the SIMRS side. For temporary network errors, a retry with back-off strategy can be applied, but for persistent data validation errors, manual intervention or correction of the source data is a must.LIS and SIMRS integration is a complex project that requires careful planning and precise execution. Following best practices can minimize risks, reduce costs, and ensure long-term success. By investing in these steps, hospitals can build a robust system and support superior healthcare services.
Integrating LIS with SIMRS is an essential step toward an efficient and patient-centered digital hospital. Despite its high technical complexity, the benefits it offers—from improved data accuracy, accelerated workflows, to compliance with interoperability standards such as HL7 and FHIR—far outweigh the initial investment. With careful planning, selection of the right technologies such as NextGen Connect 4.4.0 and HAPI FHIR 6.8.x, and commitment to best practices in security and testing, your hospital can achieve an integrated and resilient information system. Do not let data silos hinder your healthcare service potential. Take a proactive step today to evaluate your infrastructure and begin your integration journey. If you need further consultation or implementation assistance for SIMRS, BPJS/SatuSehat bridging integration, or other healthcare IT solutions, our team is ready to help you realize the vision of a fully integrated future hospital.
Related solutions by PT Pilar Inovasi Informatika (Pilar Inovasi IT products): SIMRS (Hospital Information System) BPJS & SatuSehat Integration. Need a free consultation?
Belum ada komentar. Jadilah yang pertama!
Baca juga artikel lainnya
