LIS–SIMRS Integration Tutorial: HL7 v2.5.1 Architecture and MLLP Code Examples

Imagine a type C hospital with 180 beds, 6 clinical chemistry analyzers, and 3 laboratory administrative staff who every morning retype 250–400 test results from the analyzer screen into the SIMRS. One order takes an average of 90 seconds to type manually, with an entry error rate of 1.5–3%. That figure is enough for one patient to receive another patient's potassium value — an incident that falls into the category of sentinel event. On the other hand, doctors at the outpatient clinic wait for results that should be completed in 45 minutes to become 2.5 hours because the bottleneck is in the entry process, not the instrument. LIS (Laboratory Information System) integration with SIMRS is not a “nice to have” project; it is an operational intervention that directly cuts turnaround time (TAT), eliminates retyping, and provides an audit trail for accreditation. This article discusses architecture, implementation steps, and code you can run immediately.

Integration Map: Three Data Paths That Must Be Mapped

Before touching code, the key to the project lies in mapping three data paths. The first path is inbound order: SIMRS sends test orders (patient, ordering doctor, test code, priority, diagnosis) to LIS. The second path is outbound result: the analyzer produces raw results, LIS normalizes them, then sends them to SIMRS as verified results. The third path is master data: test catalog, normal reference ranges, units, and methods.

The most common mistake is ignoring the third path. From experience in several projects, about 60% of UAT failures do not come from the protocol, but from test codes that do not match between SIMRS and LIS. A real example: SIMRS uses code GLU for random glucose, while the analyzer sends GLU2 for fasting glucose. Without explicit mapping, results go into the wrong parameter and pass validation because the data types are both numeric.

For the protocol, use the standard actually provided by the vendor. The majority of medium-to-new analyzers support HL7 v2.5.1 over MLLP (default port 6661, frame 0x0B … 0x1C 0x0D). Older analyzers generally only output ASTM E1381/E1392 via RS-232 at 9600 baud, 8N1. For reporting to SatuSehat, the final conversion is to FHIR R4 (Observation, DiagnosticReport, ServiceRequest).

At minimum these four fields must be accurate before go-live: PID-3 (Medical Record No.), OBR-4 (test code, ideally LOINC), OBX-5 (result value), and OBX-6 (unit, use UCUM such as mmol/L, not “mmol”). Add OBR-7 (sample collection time) because many clinical disputes stem from this time difference, not the result. For acknowledgment, agree from the start whether to use original acknowledgment (MSA-1 value AA/AE/AR) or enhanced acknowledgment with an ERR segment.

Implementation Steps: From Analyzer Audit to Go-Live

Phase 0 — inventory (1–2 weeks). Sit with the head of laboratory and make a complete list: brand, type, firmware, communication port, and whether a manual interface is available. For analyzers with old firmware, the interface manual is often only a 40-page PDF containing ASTM character position tables. This is boring work that determines 70% of project success.

Phase 1 — catalog mapping (1 week). Of the 600 parameters available on the analyzer, usually only 180–220 are actually used routinely. Create a mapping table in the database with columns simrs_code, lis_code, loinc_code, unit, conversion_factor, and is_active. Store the conversion factor explicitly because many analyzers send mg/dL while SIMRS displays mmol/L (glucose: factor 0.0555).

Phase 2 — build integrator (2–4 weeks). Proven stack choices: Node.js 20 LTS with the simple-hl7 0.8.x library for high throughput, or Python 3.12 with hl7apy 1.3.4 for parsing that is more tolerant of messy messages. Use PostgreSQL 16 for raw message logs and Redis 7 for queueing, so messages are not lost when SIMRS restarts. Every message must be stored as-is (raw) before parsing — this is a lifesaver during troubleshooting three months later.

Phase 3 — UAT and parallel run (2 weeks). Run the integration alongside manual entry. Measure four daily metrics: TAT per order, percentage of failed messages, number of orders without results within 24 hours, and number of duplicates. Realistic targets: error rate below 0.5% and TAT reduction of 40–60%. Do not go live before there is a daily reconciliation mechanism that matches the number of SIMRS orders with the number of results in LIS.

Facing Field Constraints: Legacy Analyzers and Missing Orders

Older analyzers with RS-232 output can still be integrated without replacing the instrument. Install a serial-to-TCP converter such as Moxa NPort 5110, set 9600 baud 8N1, then your parser reads the ASTM frame: ENQ character (0x05), records starting with H, P, O, R, L, and a two-digit checksum at the end of the line. Checksum validation is mandatory; long cables in a laboratory room full of centrifuges often produce corrupted characters.

The second problem that almost always arises: SIMRS downtime or the hospital network being disconnected right when the analyzer sends results. The solution is not naive retry, but the outbox pattern — the message enters a persistent queue first, then is processed. The following code is a minimal MLLP listener that you can run today to receive ORM^O01 orders from SIMRS and reply with an acknowledgment.

# Python 3.12 + hl7apy 1.3.4 — MLLP listener minimal
import socketserver
from hl7apy.parser import parse_message

class MLLPHandler(socketserver.BaseRequestHandler):
    def handle(self):
        raw = self.request.recv(8192).strip(b"\x0b\x1c\x0d")
        msg = parse_message(raw.decode("utf-8"), find_groups=False)
        rm  = msg.PID.PID_3.PID_3_1.value   # No. Rekam Medis
        acc = msg.ORC.ORC_2.ORC_2_1.value   # Accession number
        print("order masuk:", rm, acc)
        self.request.sendall(b"\x0bMSA|AA|" + acc.encode() + b"\x1c\x0d")

socketserver.ThreadingTCPServer(("0.0.0.0", 6661), MLLPHandler).serve_forever()

In production, add three things on top of the above code: idempotency based on accession_number so that resent orders do not create duplicate examinations, retry with exponential backoff (1s, 2s, 4s, maximum 5 attempts), and a dead-letter queue for permanently failed messages so the laboratory team can follow up manually without waiting for the IT team.

Best Practices

1. Store the raw message before parsing. Table hl7_inbox with columns raw_text, received_at, status. Without this, incident investigation can take days.
2. Use the accession number as the idempotency key. Reject or ignore messages with an accession that has been processed in the last 24 hours.
3. Validate units and value ranges before sending to SIMRS. Reject results with values outside physical limits (e.g., potassium 45 mmol/L) and mark them as OBX-11 = X for review.
4. Build a minimal monitoring dashboard. Four panels: incoming messages per hour, failed messages, orders pending for more than 2 hours, and end-to-end latency.
5. Agree on SLAs and written escalation. Example: failed messages are handled by the IT team within 30 minutes during working hours; orders without results for 4 hours are escalated to the head of the laboratory.

FAQ

Do old analyzers need to be replaced for integration?

No. As long as the analyzer produces structured output via RS-232 (ASTM) or TCP/IP (HL7), integration can be done with a serial-to-TCP converter costing 1.5–3 million rupiah per unit. Replacing equipment becomes relevant if the device's throughput is already the bottleneck, not because of communication limitations.

How long is a realistic implementation time?

For one hospital with 4–8 analyzers, 6–10 weeks from audit to go-live is realistic, with 2 of those weeks for parallel run. Projects that drag on are usually because the catalog mapping phase is underestimated, not because of protocol technical issues.

What if SIMRS and LIS come from different vendors?

This is actually the most common scenario and not an obstacle. What is needed is a data contract agreement: HL7 version, which fields are mandatory, accession number format, and who is responsible when a message fails. Create an Interface Control Document (ICD) of at most 10 pages and have both vendors sign it.

Does this integration automatically meet SatuSehat requirements?

Not automatically. LIS–SIMRS integration handles the internal flow, whereas SatuSehat reporting requires additional mapping to FHIR R4 resources (Observation, DiagnosticReport) along with LOINC and UCUM terminology validation. Ideally, it is built as a separate layer so regulatory changes do not disrupt the daily laboratory flow.

A mature LIS–SIMRS integration is not about who has the most sophisticated protocol, but about discipline in three things: clean master data mapping, complete raw message storage, and a daily reconciliation mechanism that is run consistently. When all three are in place, a 40–60% TAT reduction and the elimination of retyping are not projections, but results you can measure within weeks. If you are preparing this project and need a second opinion on the architecture, protocol selection, or building the integrator, our team has experience building bridging for SIMRS, LIS, BPJS, and SatuSehat/FHIR for hospitals and clinics. Please schedule a technical consultation session to map your laboratory needs.

Related solutions by PT Pilar Inovasi Informatika (Pilar Inovasi IT products): SIMRS (Hospital Information System) BPJS & SatuSehat Integration. Need a free consultation?