Laboratory Service — Service Overview
Status: populated Owner: TBD Last updated: 2026-04-18 Companion: Service Template · 03 platform-services · 02 DDD
1. Purpose
The laboratory-service is the national eHealth platform's bounded context for end-to-end laboratory diagnostic operations. It unifies two previously separate modules — laboratory-lis (LIS workflow) and results (clinical result filing and acknowledgment) — into one service owning the complete laboratory lifecycle: order receipt, specimen tracking, result production, verification, chart filing, and clinician acknowledgment.
2. Bounded Context
| Attribute | Value |
|---|---|
| DDD context name | laboratory |
| Source module IDs | CLIN-LIS, CLIN-RESULTS |
| Licensing category | Optional add-on (diag.laboratory) |
| FHIR resource owners | Specimen, Observation (lab), DiagnosticReport (lab) |
| ServiceRequest reader | Consumes from orders-service |
3. Responsibilities
| Responsibility | Detail |
|---|---|
| Test catalog management | LOINC-mapped panels, components, specimen requirements, reference ranges |
| Lab order receipt | Consumes ServiceRequest from orders-service; creates accession |
| Accessioning | Accession number generation, label printing, chain-of-custody |
| Specimen lifecycle | State machine: ordered → collected → received → in-process → resulted → verified → released → canceled |
| Result entry | Manual entry and analyzer-import: value, unit, reference range, flags, comments |
| Verification & authorization | Role-based (technologist verify → pathologist sign-off); versioned corrections |
| Critical value alerting | Configurable thresholds; acknowledgment enforcement; escalation via communication-service |
| Worklist management | Bench/analyzer/priority-filtered views; TAT tracking |
| Result filing | Publishes Observation + DiagnosticReport to FHIR after release |
| Result acknowledgment | Clinician inbox/queue, ack actions (reviewed, forwarded, plan-documented), escalation |
| HL7 v2 adapter | ORM/ORU exchange routed through interop-service |
4. Non-Responsibilities
- Imaging studies (radiology-service)
- Alert delivery channel (communication-service)
- Patient portal display (patient-portal-service)
- Clinical chart context (patient-chart-service)
- Order placement UI (orders-service)
5. Upstream Dependencies
| Service | Type | Detail |
|---|---|---|
| orders-service | Event consumer + FHIR read | clinical.orders.placed → ServiceRequest |
| registration-service | FHIR read | Patient, Encounter resolution |
| provider-directory-service | FHIR read | Performing lab Organization |
| terminology-service | Sync REST | LOINC validation, reference range lookup |
| interop-service | HL7 v2 passthrough | ORM/ORU with external LIS platforms |
6. Downstream Consumers
| Service | What it consumes |
|---|---|
| patient-chart-service | diag.laboratory.result.released events; DiagnosticReport + Observation FHIR reads |
| patient-portal-service | Released results (policy-filtered) via FHIR gateway |
| communication-service | diag.laboratory.critical.triggered → critical alert dispatch |
| audit-service | All state-transition and data-access events |
| population-health-service | Aggregate result data for HMIS indicator export |
7. Slice Involvement
| Slice | Scope |
|---|---|
| S0 | Catalog, accessioning, specimen lifecycle, manual result entry |
| S1 | Verification, critical alert hooks, worklist, result acknowledgment |
| S2 | Analyzer adapter (HL7 v2 ORU), external LIS coexistence |
| S3 | TAT reporting, trending queries, HMIS export |
8. Key Architectural Decisions
| Decision | Rationale |
|---|---|
| Merged LIS + Results into one service | Eliminates cross-service handoff; single transaction for verify → file |
| FHIR-native persistence | Observation + DiagnosticReport stored as FHIR JSON with indexed columns |
| Verified result immutability | Corrections create a new version; prior version preserved per ISO 15189 |
| Critical alerts via event bus | Decouples alert channel from lab workflow |
| HL7 v2 via interop-service | Service never parses raw MLLP; receives canonical FHIR/REST |
9. Context Diagram
10. Source Reconciliation
| Legacy module | Key contributions | Merge decision |
|---|---|---|
laboratory-lis | Accession, specimen lifecycle, result entry/verification, worklist, HL7 ORM/ORU adapter | Core LIS domain retained verbatim |
results | Chart filing, FHIR persistence, acknowledgment queues, critical alerting, trending | Integrated as post-verification release phase within same service boundary |
Boundary rule: LIS sub-domain handles operational workflow through verification. Results sub-domain handles chart filing, acknowledgment, and downstream events. Both share one PostgreSQL schema and one NestJS process.