ILLUSTRATIVE USE CASE · LABORATORY INTEGRATION
HealthTech Use Case: Connecting LIS Results to a Digital Health Platform
Illustrative architecture scenario, not a claim of a delivered client project or measured outcomes. A hospital wants a clinician-facing digital health application to display laboratory results without manual re-entry. The LIS remains responsible for result authorization, and the hospital identity system remains the identity authority.
Scope and constraints
Start with one laboratory workflow, one consuming application and a defined set of result types. Include patient and encounter context, order and specimen correlation, authorized results and amendments. Exclude autonomous diagnosis, treatment recommendations and AI-generated interpretation from this pilot.
Assume the source systems expose supported interfaces and the hospital has approved the access purpose. Confirm vendor capabilities, clinical release rules and operating responsibilities during discovery. These are prerequisites, not facts established about a specific hospital.
Proposed end-to-end flow
The hospital system supplies patient and encounter context. The LIS emits a result event through its supported interface. An integration service validates identifiers, codes, units and status, persists processing state, and delivers a mapped representation through an authorized API to the application.
Where the receiving contract uses FHIR, assess Patient, Encounter, ServiceRequest, Specimen, Observation and DiagnosticReport against the agreed version and profiles. They are candidate resources, not a mandatory mapping for every installation. Preserve source identifiers and provenance so each displayed result can be reconciled with the LIS.
Mapping and ownership
A jointly approved mapping register records the source field, target field, transformation, allowed values, version and approving owner. Laboratory representatives approve clinical meaning and release status. Integration engineers own transformation and delivery behavior. The application owner proves that the intended data is visible to the correct authorized user.
Do not silently convert units or map an unknown test code to a similar name. Route unresolved mappings to an exception queue. Store only the data necessary for the workflow and apply the access and retention decisions approved for the implementation.
Pilot, cutover and recovery
Use synthetic records to establish a reproducible test set. Rehearse duplicate events, patient corrections, unavailable downstream services and amended laboratory results. Reconcile source and target records after recovery rather than treating an empty queue as sufficient evidence.
Define the stop criteria, escalation contacts, rollback trigger and handling of events accumulated during downtime. During a limited pilot, review exceptions daily and expand only after agreed acceptance criteria are evidenced. No clinical or operational benefit is claimed before measurement.
Acceptance evidence and metrics
Measure latency from the LIS-authorized result event to verified availability in the target application. Track median and 95th percentile latency, unresolved identity mismatches, duplicate clinical records, exceptions by reason, and reconciliation completeness within a defined time window.
Record a baseline and agree thresholds with the hospital team. The handover should include the approved mappings, test evidence, access review, monitoring dashboard, replay procedure and signed ownership matrix. The expected value is less manual transfer and better traceability; actual improvement must be established during the pilot.
Exception and validation matrix
| Scenario | Required behavior | Test evidence |
|---|---|---|
| Repeated event | Do not create a second clinical result | Replay the same event and reconcile target records |
| Unknown patient or code | Quarantine and assign an owner | Show the exception without assigning it to another patient |
| Corrected result | Update the correlated record with version controls | Verify the latest authorized value and audit history |
| Application downtime | Durable pending state with bounded retries | Restore service, replay safely and reconcile both sides |
| Out-of-order result | Protect the newer accepted version | Send an older event after a correction and verify final state |
Frequently asked questions
Why keep the LIS as the result authority?
It preserves the agreed laboratory release and amendment workflow. The consuming application displays an authorized representation rather than creating a competing source of truth.
How should corrected results behave?
Apply the agreed source version and status rules to the existing correlated record, preserve the audit trail, and verify the corrected result in the consuming application.
Sources and context
The news source provides context. The implementation guidance and use case are proposed architecture, not an endorsement by MCIT or an affiliation with participating teams.