Jengu-Lab

Why this matters

A critical lab result — dangerously low haemoglobin, a flagrantly abnormal potassium, an INR out of safe range — has clinical consequence in minutes. A platform that delivers it via the same channel as routine results, hoping the clinician will notice, fails in exactly the situations where failure is most expensive.

Hospital quality teams routinely investigate "delayed clinical response to critical lab values" as a category of incident. The common pattern: result was finalised on time, but the ordering clinician was in a different system, in a meeting, or off shift, and nobody routed the value to the right destination quickly enough.

Escalation closes this gap. A finalised result is evaluated against the reference range, against the patient's context, and against configured criticality thresholds. If the result warrants escalation, the platform notifies — and keeps notifying through a defined chain — until the result is acknowledged. The clinical response time becomes a function of the chain, not of luck.

What's in the box

• Per-test criticality thresholds. Each test has thresholds (low-critical, low-warn, normal, high-warn, high-critical) derived from the zone's reference data and refined by the tenant. Thresholds are configuration in the git config repo.

• Patient-context-aware evaluation. A "low" haemoglobin in a paediatric patient differs from a "low" haemoglobin in an adult; the threshold evaluation uses the same patient context the reference range does.

• Escalation chain per tenant, per test category. Tenants declare a chain: ordering clinician → department on-call → shift supervisor, with timeouts between steps. The chain triggers automatically when the result warrants.

• Notifications cross modules. The ordering clinician receives the notification regardless of which module they are working in (Lab, Visit Assistant). Cross-module notification is a platform feature the module consumes.

• Acknowledgement closes the chain. When the receiving clinician acknowledges the result (via UI or via clicking through to the order), the chain stops. Unacknowledged results continue escalating through configured timeouts.

• Escalation events are audited. Every notification, every acknowledgement, every chain step is an audit event. The full timeline is queryable.

Standards we lean on

• ISO 15189 — clinical-laboratory quality requirements including timely communication of critical results.
• CLSI GP47 — best-practice guideline for critical-value reporting.
• HL7 FHIR R4 Communication — the standard shape for notification events that participate in the audit trail.

What customers and operators experience

• An ordering clinician receives a notification the moment a critical or unexpected value finalises. The notification surfaces wherever they are working — Visit Assistant, Lab UI, cross-module inbox.
• A clinician on shift sees critical results as a separate, visually-distinct stream from routine ones. The triage is built in.
• An ordering clinician unavailable has the result escalate to the configured backup — a department's on-call, a colleague — per the tenant's escalation chain.
• A laboratory director can review escalation history per test type, per clinician, per shift. "Did the escalation reach a clinician within target time?" is a queryable property.
• A quality team investigating a delayed response sees a precise timeline: result finalised at T, notification sent at T+0, acknowledged at T+N.
• A compliance officer reviewing the platform sees that critical-value handling is structurally enforced, not relying on per-clinician memory.

Limits and trade-offs

• Threshold quality bounds escalation quality. Wrong thresholds produce wrong escalations: too aggressive (notification fatigue) or too lax (missed criticals). Threshold curation is the lab's responsibility.
• The platform does not replace clinical judgement. A result that is technically within range can still warrant attention; a result that is technically critical may be expected for a particular patient. Escalation is a safety net, not the whole clinical workflow.
• Chain effectiveness depends on tenant configuration. A tenant that configures all chains to "ordering clinician only, no backup" gets exactly that. The platform gives the mechanism; the tenant defines the response posture.
• Cross-tenant escalation is not supported. If an ordering clinician's tenant differs from the lab's tenant (e.g., external referral), escalation crosses an integration boundary and is not handled inside the platform.

Related features

• Lab order lifecycle — escalation triggers from the lifecycle's result-finalisation step.
• Per-zone reference ranges — the reference data drives what counts as critical.
• Platform: Cross-module clinical workflow — notifications find the clinician across module boundaries.
• Platform: Regulatory audit trail — every escalation event lives in the same audit trail.

Why this matters

Most lab results are routine; a small fraction are not. The non-routine fraction is where lab interpretation matters most — unusual combinations of values, subtle drift over time, results that don't fit the clinical picture, results that suggest interference or pre-analytical errors. A clinician scanning a busy worklist can miss these in the rush; a specialist clinical biochemist would catch them but cannot review every result.

AI-assisted interpretation makes a clinical-biochemist-style review available on every result without requiring one biochemist per result. It surfaces what a careful reviewer would notice: this combination of values is unusual, this trend is drifting toward a known threshold, this result is consistent with sample mishandling, this pattern matches a clinical syndrome worth considering.

The principle: the AI is clinical decision support, not a replacement. It surfaces patterns; the clinician decides what to do. Every suggestion is offered with its reasoning and its uncertainty.

What's in the box

• AI runs on anonymised inputs. The platform's anonymisation pipeline runs before any LLM call — patient identifiers, ID numbers, contextual identifiers all removed. The AI receives clinical content sufficient to reason about; it does not receive identity.

• Multiple AI tasks, right-sized. Different interpretation tasks use different models per the platform's right-sized AI pipeline: anomaly detection on a fast model for inline use; pattern-matching against clinical syndromes on a stronger model for asynchronous review.

• Suggestions carry their reasoning. A suggestion shows why it was made — which values combined, which thresholds triggered, which clinical knowledge was matched. The clinician sees the chain.

• Per-zone provider choice. Which AI provider runs each task is determined by the tenant's compliance zone — a jurisdiction with strict data-residency requirements routes to a local provider; another zone may use a hosted one. The clinician's experience is the same.

• Acceptance feedback improves the model. Clinicians' accept/reject signals on suggestions feed (anonymised) back into the platform's product-improvement programme — only for tenants that have consented to anonymised data use.

Standards we lean on

• GDPR Article 22 — automated decision-making constraints; the AI is decision support, not autonomous decision.
• HIPAA 45 CFR 164.514(b) — Safe Harbor / Expert Determination define the de-identification bar input must clear before reaching any AI provider.
• EU AI Act (Annex III, healthcare risk class) — clinical decision-support classification informs how suggestions are presented and audited.
• ISO/IEC 23894 — AI risk management framework; suggestion classification consistent across jurisdictions.

What customers and operators experience

• A clinician reviewing a result sees suggestions inline: "this combination of low sodium + high creatinine + recent diuretic prescription is consistent with X; consider Y as a follow-up". The suggestion appears alongside the raw values, not in place of them.
• A clinician dismissing a suggestion does so with one click; the suggestion is logged as reviewed-and-dismissed. No nag, no pile-up of unread suggestions.
• A laboratory director can review aggregate suggestion-acceptance rates per test, per clinician, per shift. Suggestions consistently dismissed indicate either AI quality issues or a clinical context the AI is missing.
• A clinical biochemist can curate the AI's suggestion rules per zone, contributing to the zone's clinical interpretation knowledge.
• A patient asking "did AI look at my lab results?" receives an honest answer: yes, an AI surfaced suggestions for the clinician's review; the clinician made the decisions; the patient's identifying data was anonymised before reaching the AI provider.

Limits and trade-offs

• AI quality is bounded by the underlying provider. Routing optimises which model handles each task; it does not improve any individual model's clinical accuracy.
• Suggestion fatigue is real. Too many suggestions, even good ones, train clinicians to dismiss them. Per-tenant tuning of suggestion thresholds is necessary.
• AI cannot replace specialist review. For genuinely unusual results — rare metabolic patterns, novel drug interferences, complex haematology — a clinical biochemist's review remains the right answer.
• Re-identification through AI is structurally prevented. Anonymisation runs first; the AI provider never sees identifying content alongside another customer's identifying content.

Related features

• Lab order lifecycle — suggestions surface during the result-review step.
• Abnormal-result escalation — distinct concern: escalation is rule-based on reference ranges; AI suggestions are pattern-based on context.
• Platform: Right-sized AI pipeline — Lab's AI tasks are routed through the platform's per-zone, per-task-kind AI router.
• Platform: Patient data anonymisation — anonymisation is the boundary that protects the AI input.
• Platform: Consented data use — accept/reject feedback flows only for consenting tenants.

Why this matters

A laboratory of any size has tests that go to specific devices, tests that get sent out to partner labs (because the lab doesn't run them itself), tests that are inherently manual (microbiology bench work, histology, send-out specialty assays), and tests where the choice depends on volume, time of day, or device availability. Without explicit routing rules, the routing decision happens implicitly — usually in someone's head, occasionally in a paper binder, sometimes in the LIS as a hard-coded mapping nobody remembers writing.

The right shape: the routing rule lives on the catalogue offering, not in code or in tribal knowledge. Adding a new device, switching a test to a different partner, deciding that a previously device-handled test now goes to manual review — all are catalogue edits, not engineering changes.

What's in the box

• Routing rule per lab catalogue offering. Each offering declares one of: device:<deviceId>, partner:<partnerLabId> (delivered via Medipost-out), manual:<workbenchId>. The routing rule is mandatory at the lab catalogue layer.

• Routing dispatcher service. When a ServiceRequest materialises, the dispatcher reads the catalogue offering for the test, applies the routing rule, and (depending on rule) updates the ServiceRequest with performer, dispatches to a partner adapter, or queues a manual-entry Task.

• Conditional routing for future scenarios. The rule schema accommodates conditions ("device unavailable → fall back to partner", "specimen volume below threshold → reroute to manual") in later iterations; v1 supports the unconditional form.

• Visible routing on the dashboard. A card carries its routing target as part of its display state; supervisors can see at a glance which tests are queued for which device, partner, or workbench.

• Routing changes audited. A catalogue edit that changes a routing rule is recorded as a Provenance entry on the lab catalogue offering.

Standards we lean on

• HL7 FHIR R4 — ServiceRequest.performer for device routing; FHIR Task workflow for manual queueing; integration adapter framework for partner dispatch.

What customers and operators experience

• A laboratory director changing how a test is performed edits the catalogue offering's routing rule; subsequent orders use the new rule.

• A bench technician sees orders arriving at the right device or in the right manual queue without per-order decision making.

• A partner-lab manager receives orders for tests their lab is configured to handle, via Medipost-out.

Limits and trade-offs

• One rule per offering. v1 does not handle dynamic load-balancing across multiple devices for the same test; that's a later feature.

• Routing-rule errors propagate quickly. A misconfigured routing rule sends every subsequent order to the wrong destination; catalogue editing should be reviewed.

Related features

• Standardized service catalogue — routing rule lives on the lab catalogue offering.
• Multi-channel order intake — routing applies to every materialised order.
• Integration adapter framework — partner-lab routing dispatches via partner-dispatcher adapter species.
• Lab order lifecycle — routing is a transition between order placement and execution.
• Lab operations dashboard — routing target is part of the card's display state.

Why this matters

Clinical chemistry is the high-volume backbone of laboratory medicine. A lab running comprehensive metabolic panels on a few hundred specimens a day cannot afford friction in the routine path: in-range results should release with minimal touch; abnormal results need attention but not heavy ceremony; only critical or clinically significant outliers warrant sign-off review. The workflow species here is what makes throughput possible without sacrificing safety.

What's in the box

• Numeric-result workflow definition. A PlanDefinition declaring stages: accession → device-dispatch → device-run → validation (auto-released if in range; bench tech if abnormal; validating tech if critical) → sign-off (only when required by catalogue or zone policy) → release.

• Auto-release for in-range results. When the catalogue's reference range and validation policy permit, validated in-range results auto-release without explicit sign-off Task — under audit and with supervisor visibility into auto-release rate.

• Bench-friendly numeric validation UI. Compact list view per panel, reference range overlay (visual green/yellow/red), one-click validation for the routine, expanded inspection for abnormal.

• Reflex testing. Catalogue rules can spawn additional orders based on result values (e.g. abnormal TSH triggers free T4); workflow accommodates the additional results.

• Panel-level signoff option. Per-zone policy can require signoff at the panel level rather than per observation when panels carry clinical narrative.

Standards we lean on

• HL7 FHIR R4 — Observation for numeric results, DiagnosticReport for panels.
• IHE LAW — analyzer integration.
• CLSI / IFCC — laboratory practice norms for numeric result interpretation.

What customers and operators experience

• A bench technician validates an entire batch of in-range results in one pass; the dashboard surfaces only the abnormals for closer review.
• A validating technician opens an abnormal result, reviews reference range and clinical context, validates or amends.
• A clinician ordering a comprehensive metabolic panel receives the panel report; in-range members auto-released, abnormal members reviewed.

Limits and trade-offs

• Auto-release rate calibration is a lab-leadership decision. Aggressive auto-release saves time but reduces safety net; strict review of every result preserves safety but burdens validation staff.
• Reflex rules per catalogue need maintenance. Out-of-date reflex rules either miss appropriate follow-up tests or trigger unnecessary ones.

Related features

• Task-driven workflow engine — workflow definition is a PlanDefinition.
• Result validation and release — validation/amendment lifecycle.
• Standardized service catalogue — reference ranges drive interpretation.
• Lab operations dashboard — the workflow's lanes match the dashboard's chemistry view.
• Microbiology workflow — the contrasting species; clinical chemistry is the default, microbiology the differentiated.

Why this matters

An individual Observation is a measurement; a DiagnosticReport is a clinical artefact. The orderer requested a panel; they expect back a coherent panel report, not eight standalone observations. The regulator reviewing an incident wants the released report, not the underlying data points. The patient timeline shows reports as events; observations are the substructure inside.

The right shape: assemble validated observations into reports per the panel template (PlanDefinition); release preliminary versions where workflow demands (microbiology staged reporting); supersede with the final on signoff. Reports carry their own status, sign-off authority, and references to constituent observations.

What's in the box

• Per-order or per-panel DiagnosticReport. A simple order produces one report; a panel order produces one report grouping the panel members.

• Preliminary release lifecycle. Where the observation type's workflow declares it (microbiology staged reporting, reflex testing), the report releases preliminarily and supersedes on subsequent stages.

• Sign-off as a workflow Task. Final release is a sign-off Task; the role permitted depends on observation type (chemistry tech / microbiology lead / pathologist).

• Critical-result hold. Reports containing critical observations are held until clinician notification completes (per result-validation-and-release).

• Report content presentation. Per-zone formatting (PDF or structured FHIR) for the orderer and the patient.

Standards we lean on

• HL7 FHIR R4 — DiagnosticReport, DiagnosticReport.status (registered, partial, preliminary, final, amended, corrected, appended, cancelled, entered-in-error).
• IHE LTW (Laboratory Testing Workflow) — report-delivery semantics.
• Per-zone reporting formats — PDF templates, structured-data conventions per zone.

What customers and operators experience

• An orderer receives the released report through their preferred channel; for panels they see a coherent panel report rather than observations one at a time.

• A microbiology technician sees preliminary reports releasing per stage; the final report assembles when AST completes for all organisms.

• A senior tech / pathologist signs off the report as a workflow Task; the report transitions to final.

• A regulator reviews released reports through the FHIR surface or zone-specific delivery channels.

Limits and trade-offs

• Panel composition is the catalogue's responsibility. The catalogue's PlanDefinition declares the panel; assembly follows the definition.

• Preliminary releases multiply audit volume. Each release is an audited transition; reports with many stages produce more audit records than single-final reports.

Related features

• Lab order lifecycle — assembly is a transition on the FHIR chain.
• Result validation and release — validation precedes assembly; sign-off transitions the report.
• Standardized service catalogue — panels are PlanDefinition resources.
• Microbiology workflow — staged-report releases are characteristic of this species.
• Multi-channel result delivery — released reports go to delivery.

Why this matters

A laboratory cannot pause patient processing because the cloud is unreachable. Samples continue to arrive, instruments continue to process, results continue to be needed by clinicians on shift. A lab that depends on cloud connectivity for routine processing becomes a clinical liability the moment the link is degraded.

The edge-cloud split — described in detail in the platform's hybrid edge–cloud feature — applies directly to Lab. Instruments are on-premise; their codecs run on the edge; their results land in the edge's local data store; the order lifecycle progresses without needing cloud. When cloud returns, the local results reconcile.

The lab gains two things at once: resilience (survive cloud outages) and locality (analyzer-to-result latency drops because the network round-trip to cloud is gone). The cost is the operational discipline of running edges, which is shared across all modules the customer enables.

What's in the box

• Codecs run on the edge by default. Instruments are on-premise; their codecs are loaded by the edge assembly. Cloud-only codec deployments exist for hosted analyzers but are the exception.

• Order lifecycle progresses locally. Edge holds enough state to advance an order through specimen, processing, and result-finalisation without consulting cloud.

• Results land in the edge's FHIR store. The platform's per-tenant FHIR project exists at both edge and cloud; the edge holds its tenant's working set. Results written at the edge sync to cloud during reconciliation.

• QC continues at the edge. Internal QC runs and their pass/fail evaluation happen edge-side. External QC scheme submission depends on cloud; it queues during outages.

• Audit follows the edge audit pattern. Each edge keeps its own audit log of every locally-taken action, online or offline, and forwards to the cloud audit trail as part of normal reconciliation. Audit continuity does not depend on connectivity.

Practices we lean on

• GDPR Article 32 — security of processing. Resilience is a security measure in its own right.
• HIPAA Contingency Plan (45 CFR 164.308(a)(7)). Required feature to access ePHI during an emergency.
• ISO 15189 — clinical lab continuity expectations.

What customers and operators experience

• A laboratory under cloud outage continues processing samples normally. Orders received before the outage continue through the lifecycle; new orders placed via the LIS bridge queue at the edge until the bridge can resume.
• A clinician requesting results during an outage receives them from the edge — assuming they are on the same site or connected via the local network. Cross-site result delivery is paused; local result delivery is not.
• A laboratory technician sees no operational change during an outage. The analyzer codecs are running locally; the worklist updates locally; QC continues to run.
• A laboratory director knows in advance which features degrade during a cloud outage (cross-site reporting, AI interpretation against cloud models, LIS bridge, external QC submission) and which do not.
• An on-call IT team during an outage does not need to intervene to keep lab running; reconciliation when cloud returns is automatic.

Limits and trade-offs

• Some Lab features are cloud-only. Cross-site reporting, AI features that route to cloud-only providers, external QC submission, and LIS bridge traffic require cloud and degrade gracefully when offline.
• Reconciliation costs bandwidth. Long offline periods produce a backlog that takes bandwidth to reconcile. Plan offline budgets to fit available bandwidth.
• Edge data minimisation applies. Once a result has reconciled to cloud, the edge holds only what ongoing critical operation requires; older records are visible only when reconnected.
• Codec installation must reach the edge. Codec rollouts need a connectivity window; an edge that has been offline for weeks will not have the latest codecs.

Related features

• Device integration framework — codecs are the edge-side component that makes lab resilience real.
• Lab order lifecycle — lifecycle progresses locally during outages.
• Quality-control workflow — internal QC runs edge-side during outages.
• Platform: Hybrid edge–cloud operation — the underlying pattern Lab consumes.
• Platform: Edge fleet management — the operational story for managing the edges Lab runs on.

Why this matters

A clinical laboratory runs many instruments from many vendors, each speaking its own protocol — bidirectional ASTM, HL7 v2.5 LIS-A2, raw serial, vendor TCP, modern REST or FTP-XML. A laboratory information system that hard-codes support for a fixed set of instruments either becomes obsolete the moment a hospital procures something new, or grows into a sprawl of conditional code that nobody dares change.

The cost of ad-hoc instrument integration is real. Hospital lab directors routinely report integration projects that take months, require vendor escalation, and never quite finish — because every new instrument is a one-off engineering task. The lab cannot grow its analyzer fleet at the pace that procurement allows.

Jengu Lab's promise is the inverse: when the lab procures a new analyzer, integration is a configuration change plus a typed driver. The business question for the lab director becomes "is there a driver?", not "how many engineering weeks?". When a driver does not yet exist, authoring one is scoped finite work with a clear contract — same shape regardless of vendor.

The strategic value: the lab's instrument fleet grows on the lab's schedule, not on engineering's.

What's in the box

• Pluggable analyzer drivers. Each clinical analyzer model is represented as a LabClinicalAnalyzer device type with a typed Java driver — produced by Jengu, by the analyzer vendor, or by a specialty group that needs niche support. Drivers translate the instrument's protocol into standard FHIR resources; lab workflow is unaware of the protocol.

• Broad transport coverage. Network analyzers (TCP/MLLP), serial-cabled analyzers (RS-232, USB-serial, serial-over-LAN), FTP-XML analyzers (VIDAS family), modern REST analyzers — all share one driver framework. A driver written for a TCP analyzer runs identically on serial when the underlying protocol is the same.

• Configuration in the lab's tenant. Adding an analyzer is declaring a Device resource in the tenant's configuration: vendor, model, location, transport, driver. The platform's device admin UI surfaces a vendor-specific configuration popup contributed by the driver.

• Edge-resident execution. Analyzers physically connect to on-premise edges; their drivers run on the same edges through the platform's device-management framework. The edge becomes the analyzer's gateway into the platform — physical proximity for low-latency protocol handling, FHIR sync to cloud for centralised storage and reporting.

• Independent driver release cadence. Drivers publish to the platform's bundle repository as versioned artefacts. A vendor protocol revision, a fixed parsing edge case, a new model variant — each releases without a coordinated lab cloud release. Rolling out a driver update to one site does not affect other sites.

• Documented driver contract. A clear authoring contract with a Gradle template, descriptor annotation, the driver SPI, and the FHIR-output expectations. New-analyzer support is scoped finite work with a clear "done" definition.

Standards we lean on

• HL7 v2.5 LIS-A2 (ASTM E1394) — the standard analyzer protocol most clinical instruments speak.
• HL7 FHIR R4 — Observation, Specimen, DiagnosticReport, Device are the canonical output shapes.
• IHE LAW (Laboratory Analytical Workflow) — analyzer manager / analyzer integration profile.
• IVDR (EU 2017/746) — In-vitro diagnostic device regulation classification informs which drivers require additional conformance evidence.

What customers and operators experience

• A laboratory director procuring a new analyzer asks one question: is there a driver? If yes, integration is a configuration change. If no, driver development is scoped finite work with clear boundaries — the same boundary regardless of vendor.

• A laboratory technician sees the new instrument's results appearing in the same worklist as everything else, in the same shape, with the same audit trail.

• A platform operator rolling out a driver update to one customer's edge does not need to coordinate with other customers' edges; driver updates are independent of platform updates.

• A specialty group that builds its own driver for a niche instrument can run it alongside the standard ones — and the platform does not require them to fork.

• An analyzer vendor authoring official support uses the same driver SPI and toolchain as Jengu's in-house authors; same documentation, same packaging, same audit guarantees.

Limits and trade-offs

• A driver is real engineering for protocols nobody else has written. When an instrument's protocol is novel, driver development is finite work but not zero. The framework makes the shape of the work clear; it does not make the work disappear.

• Driver quality bounds clinical accuracy. A driver that mis-parses a lab analyzer's result format produces wrong FHIR resources downstream. Driver validation is a quality responsibility the lab carries; the framework does not substitute for it.

• Vendor protocol changes break drivers. When an instrument vendor updates their protocol, drivers need updating. The framework localises this work to one bundle, but does not eliminate the maintenance burden.

• Analyzer integration depends on edge-resident execution. Analyzers physically connect to on-premise edges; this is the right architecture for clinical safety (operates through cloud outages) but means edge presence at the lab site is a prerequisite. Cloud-only analyzer integration (for hosted or cloud-connected instruments) is supported but is the exception rather than the rule.

Related features

• Lab order lifecycle — analyzer drivers feed observations into the order chain.
• Standardized service catalogue — drivers map result outputs to catalogue codes.
• Working alongside existing LIS systems — a different species of integration: same framework underneath, different external counterpart.
• Partner lab network — another integration species: send-out testing to external labs.
• Edge-resilient lab operation — analyzer drivers run at the edge by design.
• Quality-control workflow — analyzer QC runs through the same drivers; calibration records carry through the FHIR chain.
• Platform: Device management framework — the platform substrate this feature uses; documents the unified cross-module device primitive.
• Platform: Open standards data portability — drivers produce FHIR; the resulting data is portable like everything else.

Why this matters

A laboratory is a coordinated mix of automated and human work: analysers run continuously, technicians validate results, the microbiology bench enters Gram stains and AST results, supervisors handle specimens that arrive spoiled or instruments that drift out of QC. Most LIS systems give a status page. What a lab actually needs is a working surface — a place where the next thing to do is visible, the right person can claim it, deadlines are tracked, and the exceptions that break the happy path are first-class citizens, not buried in logs.

A status page treats the lab as a thing being observed; a working dashboard treats it as a thing being run. The difference is whether the supervisor finds out about a drifting analyzer when the biochemist mentions it at the morning handover, or the moment the trend crosses a Westgard rule and a card appears in the exceptions lane. The difference is whether a stuck order needs someone to look for it, or whether the order announces itself by failing its SLA.

The strategic value: the dashboard is the primary work environment for bench technicians, validating staff, and the lab supervisor whose job is to keep the flow healthy and intervene when things drift.

What's in the box

• Observation-keyed cards. Each card represents one in-progress unit of work — an order awaiting accessioning, a specimen running on a device, a result awaiting validation, a report awaiting sign-off, an organism culture awaiting AST entry. The unit of attention is the observation, the same primitive everyone refers to when they discuss "this glucose result" or "this culture".

• Tasks attach to cards as actions. Each card carries the active tasks for its observation: validate, amend, override, sign off, enter manual reading, escalate. Action buttons surface in context; specialised entry surfaces (numeric-result form, antibiotic-susceptibility grid, microbiology bench form) open from the card.

• Kanban lanes follow workflow state. Pending → Accessioned → In Progress → Awaiting Validation → Awaiting Sign-off → Released. Cards move automatically as machines complete their work; humans move them by completing tasks. The lanes vary per observation type — chemistry has different lanes than microbiology — but the column-of-cards mental model is uniform.

• Exceptions lane, not buried. QC drifts (Levey-Jennings, Westgard rules), device errors, specimen rejections, SLA breaches, partner-lab delivery failures, Medipost-out failures — all surface in a dedicated lane the supervisor watches. Critical results (positive blood culture, multi-drug resistant organism) appear here too, with notify-clinician tasks attached.

• Role-filtered views. A chemistry tech sees chemistry work; a microbiology tech sees cultures; the supervisor sees everything plus exceptions. Filters compose with priority, age, and lab section.

• Panel grouping toggle. When validating panel results (basic metabolic, comprehensive metabolic, blood gas), the technician can toggle from individual-observation view to grouped-by-order view to see the whole panel as one card with expandable observation children.

• Live updates. When a device reports a result, the card moves itself; no refresh needed. When a Medipost result arrives, a card appears. WebSocket-driven; degrades gracefully on connectivity loss.

Standards we lean on

• HL7 FHIR R4 — Task, Observation, the order chain, and RequestGroup are the data primitives.
• Workflow definitions are FHIR PlanDefinition — per observation type; data, not code.

What customers and operators experience

• A bench technician opens the dashboard filtered to their section, picks the next card by priority, completes the task in the specialised UI that the card opens, and the card moves to the next lane.

• A validating technician sees a queue of results awaiting validation, with reference ranges and abnormal flags surfaced; they can validate, amend with a reason, or escalate.

• A microbiology technician working a positive culture sees the staged-reporting view: Day 1 prelim entry, Day 2 ID entry, Day 3 AST entry, each as its own task on the same culture's card. Critical results raise notify-clinician tasks on the same card with their own SLA.

• A lab supervisor has the exceptions lane as their primary view, intervenes on QC drifts and instrument errors, reassigns work, sees the overall flow health.

• A new section's workflow lands by configuring its PlanDefinition and registering its specialised Task-type UI handlers — the dashboard absorbs the new species without code changes in the dashboard itself.

Limits and trade-offs

• The dashboard does not author results. Specialised entry surfaces handle data entry; the dashboard is the discovery and routing surface above them.

• Workflow per observation type is configured, not coded. A new workflow species (a new test family) requires a workflow definition, not a UI rewrite. Authoring workflow definitions is its own skill.

• Real-time updates require connectivity. During cloud-to-edge network breaks the dashboard pauses live updates; cards reconcile on reconnect (see edge-resilient lab operation).

• Card density and filter discipline matter. A dashboard with thousands of stale cards is harder to use than one whose filters and SLA-based aging keep the active set comprehensible. Lab supervisors curate filters; the platform provides defaults.

• Specialised UIs are sub-module concerns. The dashboard owns the card display and task-routing; the form for entering an AST result is provided by the microbiology sub-module. The dashboard does not become a place for sub-module-specific business logic.

Related features

• Task-driven workflow engine — the engine the dashboard reads from.
• Result validation and release — the workflow stage most cards spend time in.
• Microbiology workflow — the specialised cards and entry surfaces for cultures.
• Clinical chemistry workflow — the default numeric-result workflow.
• Abnormal-result escalation — feeds tasks into the exceptions lane.
• Quality-control workflow — QC drifts and calibration tasks surface in the exceptions lane.
• Platform: Multi-tenant FHIR isolation — dashboard reads tenant-scoped Task/Observation projections.
• Platform: WebSocket fire-and-forget — live update plumbing.

Why this matters

A lab order that travels through multiple unconnected systems is the classic source of clinical errors: orders lost between booking and collection, samples mislabelled or mis-routed, results returning without the clinical context that motivated the test, abnormal results going to the wrong inbox. Each handoff between systems is a place the chain can break.

A laboratory information system's core value is precisely keeping this chain intact. Lab takes that responsibility seriously: the order placed by a clinician at 09:14 on Monday and the result that appears at 14:32 on Tuesday are linked through one set of FHIR references. Every step records who, when, where, and under what authorisation. The chain is queryable end-to-end — given an order, find every observation that references it; given an observation, find the order that motivated it.

The strategic value: when a clinician asks "where is my result?", the answer is precise. When a regulator asks "show me what happened between order and result", the chain is the answer. When a quality team investigates a delayed result, every step has a timestamp and a recorded actor.

What's in the box

• FHIR-modelled chain. The order is a ServiceRequest; the sample is a Specimen referencing the order; each result is an Observation referencing both the order (basedOn) and the specimen; the report is a DiagnosticReport grouping the observations and referencing the order. The chain is FHIR- native, queryable in either direction, and exportable.

• Each transition is an audit event. Order placed, specimen collected, specimen received in lab, processing started, observation produced, observation validated, report assembled, report released, result delivered — each is a discrete audited transition in the platform's regulatory audit trail. Status is derivable from the audit log; the platform does not maintain parallel status fields that can drift.

• Status visible to the orderer in real time. The clinician who placed the order sees its current status without intermediation. The status they see is the same data the lab team is acting on, not a copy.

• Clinical context travels with the order. Symptoms, suspected diagnosis, urgency, fasting status, current medications — all part of the order at placement, all preserved through the chain to the released report and the result inbox.

• Result delivery routes by ordering clinician. The result reaches the inbox of the ordering clinician (or their configured backup), regardless of which module they are working in at the time the result arrives.

• Catalogue context snapshotted at the right moments. Codes carry forward from order to observation to report; the reference range used for interpretation is captured on the observation at result time so historical reports stay reproducible even when the catalogue evolves.

Standards we lean on

• HL7 FHIR R4 — ServiceRequest, Specimen, Observation, DiagnosticReport, RequestGroup are the standard shape for the chain.
• IHE Laboratory Testing Workflow (LTW) — the recognised integration profile for lab order/result flow between HIS and laboratory.
• LOINC — every test code in the chain is a LOINC code from the standardised service catalogue.
• HL7 Provenance / FHIR AuditEvent — every transition is an audited event with a clear actor.

What customers and operators experience

• A clinician placing an order picks tests from the catalogue, attaches clinical context, and the order is registered as a ServiceRequest (or RequestGroup if it expands a panel) immediately visible to the lab.

• A phlebotomist or sampling team member collects the sample, labels it, and registers it as a Specimen referencing the order; the chain is now closed back to the order through the specimen.

• A laboratory technician sees orders and specimens linked, knows which sample relates to which order without manual cross-referencing.

• A clinician waiting for a result sees the order's current status — placed, collected, received, in progress, validated, released — without having to call the lab.

• A clinician receiving a result sees the observations linked back to the original order, its clinical context, the specimen details, and the report that grouped the results. The result and the question it answers are connected.

• A regulator asking for traceability queries the chain and receives the complete trail from order placement to result delivery, every step with timestamp and actor.

Limits and trade-offs

• The chain models what happens; it does not enforce what ought to happen. The chain captures specimen-collected events with timestamps, but if a specimen is collected and the collection is not registered, the chain has a gap. Process discipline is needed alongside the model.

• Order-context completeness is the orderer's responsibility. A test ordered without clinical context is still ordered; quality is encouraged via UX, not enforced by validation.

• Cross-tenant orders are not supported. A clinician can only place orders within their tenant; cross-organisation ordering between separate tenants requires a separate contractual arrangement.

• The chain is the spine, not the workflow. The ordered states (placed → collected → … → released) describe the FHIR data evolution. The actual operational workflow (who is responsible at each step, what tasks spawn, what deadlines apply) lives in the task-driven workflow engine feature — see that feature for the orchestration view.

Related features

• Standardized service catalogue — orders are picks from the catalogue; observations carry catalogue codes.
• Multi-channel order intake — every channel materialises orders into the chain.
• Task-driven workflow engine — the operational orchestration over the chain; spawns tasks per transition.
• Result validation and release — the validation and release transitions on the chain are defined here.
• Diagnostic report assembly — groups observations into the report node of the chain.
• Multi-channel result delivery — the chain ends with delivery to the orderer.
• Abnormal-result escalation — the result-production transition triggers escalation when warranted.
• Platform: Unified patient timeline — chain entries appear on the patient's timeline alongside other modules' events.
• Platform: Regulatory audit trail — every chain transition is an audit event.

Why this matters

Many hospitals already run a laboratory information system — Roche, Sysmex, Cerner, vendor-bundled LIS systems with decades of investment. They are not going to rip and replace because a new platform arrived. Procurement reviews start with the question "does this fit with what we run?", and a platform that requires displacement of the existing LIS rarely passes that question.

At the same time, those existing LIS systems often lack modern features — AI-assisted result interpretation, multi-tenant operation, cross-zone deployments, structured anonymisation. A lab director wants the modern features without losing the systems their hospital is already certified on.

The LIS bridge is the answer: Lab connects to the existing LIS through standard healthcare integration protocols. Orders the LIS produces flow into Lab; results Lab produces flow back to the LIS. The LIS continues to be the system of record for billing, reporting, and historical archive; Lab adds the modern layer on top.

What's in the box

• Standard healthcare integration protocols. The bridge speaks HL7 v2 (ORM/ORU messages), FHIR R4 (ServiceRequest / DiagnosticReport via REST), and IHE laboratory profiles (LTW — Laboratory Testing Workflow, LCSD — Laboratory Code Set Distribution) where the LIS supports them.

• Bidirectional by design. Inbound: orders from the LIS become FHIR ServiceRequest resources in the tenant's project. Outbound: results produced by Lab become FHIR DiagnosticReport / Observation back to the LIS in the protocol it accepts.

• Per-(module, organization) configuration. The LIS connection details (endpoint, protocol, message profile, credentials) live in the tenant's git config repo, scoped to a specific module-and-organization binding. A tenant with multiple lab departments — each with its own LIS — configures one bridge per department.

• Bridge runs as integration-adapter species. The LIS lives on the hospital's own network alongside the edge; the bridge is an input-adapter species (and a paired output-adapter species) hosted by the integration adapter framework. Same runtime, same audit obligations, same descriptor mechanism as device codecs and other adapter species — distinguished only by the protocol it speaks. The edge speaks to the LIS directly without routing through cloud.

• Mapping is configurable per LIS. Code-set mappings (test catalogues, units, reference ranges) between the LIS's coding system and the platform's are configuration, not code, so a new LIS does not require platform changes.

Standards we lean on

• HL7 v2.5/v2.7 (ORM, ORU messages) — the established protocol most LIS systems speak.
• HL7 FHIR R4 — modern REST integration alternative for capable LISes.
• IHE LTW (Laboratory Testing Workflow) — recognised integration profile for lab order/result flow.
• IHE LCSD (Laboratory Code Set Distribution) — code-set exchange between labs and integrating systems.

What customers and operators experience

• A hospital with an established LIS integrates Lab as an additional feature, not a replacement. Existing LIS workflows continue; new Lab workflows complement them.
• A laboratory technician sees orders coming in from the LIS on their worklist alongside any orders placed directly in Lab. The source is visible but the worklist is unified.
• A clinician sees results in their EHR (which the LIS feeds) with the same clinical content that appears in Lab's UI. Reporting and billing flow back to the LIS unchanged.
• A compliance officer can demonstrate that the hospital's existing LIS retains its system-of-record role; Lab's contribution is auditable and bidirectional.
• A hospital with no LIS runs Lab standalone. The bridge is optional — it activates only when an organization with a Lab module configures one.
• A hospital with multiple lab departments can run a separate LIS bridge per department; each lab department's Lab-module binding configures its own LIS connection.

Limits and trade-offs

• Transitional, not strategic. The bridge is the right answer for deployments alongside an incumbent LIS, but the long-term Jengu Lab proposition is the multi-channel order intake
  • multi-channel result delivery pattern feeding the lab order lifecycle directly. The bridge is for the bridge era.
• One LIS per (module, organization). Each module-and-organization binding declares its LIS connection. A tenant with several lab departments running their own LISes is modelled with several bridges — one per department.
• Mapping requires LIS-side knowledge. Translating one LIS's test catalogue to the platform's requires either the hospital's LIS expertise or vendor consultation. The bridge reduces engineering effort; it does not eliminate clinical taxonomy work.
• Some LIS systems do not support modern integration protocols. A LIS limited to flat-file exports requires a more involved setup.
• Bridge availability follows on-premise network availability. The bridge runs at the edge and the LIS lives on the hospital's own network, so the bridge operates through cloud outages. It stops only if the hospital's internal network is down.

Related features

• Integration adapter framework — the bridge is one species of input/output adapter in the framework.
• Multi-channel order intake — the long-term direction; the LIS bridge is one of several intake channels during the bridge era.
• Multi-channel result delivery — symmetric; LIS-out is one of several delivery channels.
• Lab order lifecycle — orders arriving via the bridge enter the same lifecycle as orders placed directly.
• Standardized service catalogue — code mappings exchanged via IHE LCSD where the LIS supports it.
• Platform: Hybrid edge–cloud operation — bridge runs at the edge alongside instrument codecs.
• Platform: Organizational structure — LIS connections bind per (module, organization).
• Platform: Tenant data isolation — each tenant's LIS configuration, traffic, and audit live inside its own boundary.

Why this matters

Clinical microbiology answers a different question than chemistry. A glucose result is a number against a reference range; a blood culture result is a story that unfolds over days — Day 1 detection, Day 2 Gram stain, Day 3 organism identification, Day 4 antibiotic susceptibility — with each stage potentially clinically actionable on its own. The infrastructure that handles a chemistry result poorly handles microbiology by default: there is no place for the staged story, no understanding of organism-specific reasoning, no infection-control view across specimens.

Most LIS vendors leave microbiology to specialty point solutions because the bench workflow looks different from chemistry. The result is that microbiology technicians use one tool for analyzer integration, another for AST entry, a third for cumulative antibiogram reporting, paper or spreadsheets for outbreak detection. Each integration is bespoke; each report is hand-assembled; each infection-control conversation starts with "let me get the data together first".

Jengu Lab's bet: by building microbiology on the same primitives as the rest of the lab — the catalogue, the workflow engine, the dashboard, the unified Observation/DiagnosticReport chain — the specialised needs (staged reporting, AST grid, breakpoints, antibiograms) become focused additions rather than parallel infrastructure. The same infection-control team that needs same-day outbreak signals gets them as a query against the same data the clinician queries for an individual patient's culture.

The strategic value: microbiology becomes a positioning advantage, not an afterthought.

What's in the box

• Staged reporting. A culture's lifecycle is multiple preliminary releases plus a final release. Day 1: "growth observed" or "no growth". Day 2: Gram-stain result. Day 3: organism identification. Day 4: AST per organism. Each stage is a workflow Task in the operations dashboard; each releases a preliminary DiagnosticReport; the final report supersedes when AST is complete.

• EUCAST and CLSI breakpoint engine. Antibiotic susceptibility interpretation (S/I/R) is computed from MIC values plus organism + drug combination, against the configured standard. Estonia uses EUCAST; other zones may use CLSI. The breakpoint dataset is part of the zone catalogue, versioned and updated on standard release cadences.

• Bench-friendly AST entry. A grid view of organisms by antibiotics: the technician enters the MIC; the breakpoint engine computes interpretation; intrinsic resistances are pre-filled per organism (E. coli is intrinsically resistant to vancomycin; Enterococcus to cephalosporins; etc.). Manual override of computed interpretation is permitted with reason capture.

• Multiple organisms per specimen. A polymicrobial culture carries several organisms; each has its own AST sub-result. The Observation model uses hasMember to group organism observations under the parent culture observation.

• Specimen-type-aware workflows. Blood culture, urine, wound, stool, sputum, CSF — each has its own significance thresholds, expected workup, and interpretive comments. The catalogue entry encodes the workflow per specimen type.

• Critical-result handling. Positive blood culture, MRSA, ESBL, carbapenem-resistant Gram-negatives, Mycobacterium tuberculosis — flagged automatically, raising notify-clinician Tasks with SLA escalation. The notification is audited as a Provenance entry on the report.

• Cumulative antibiograms. Live, queryable, drillable surface aggregating susceptibility data across the lab over rolling time windows (typically 12 months), grouped by organism, specimen type, ward, age group. Replaces the quarterly Excel export.

• Outbreak / cluster signals. Same organism with same susceptibility pattern appearing across N specimens within a time window raises an infection-control alert in the exceptions lane.

• Contamination flagging. Observations can be flagged as contamination with reason; the workflow re-routes (no release; supervisor decision; specimen-rejection cascade). Contamination flags feed quality metrics for the bench.

• WHONET surveillance export. Periodic export of microbiology data in WHONET file format for international surveillance partnerships and regional antimicrobial stewardship programmes.

Standards we lean on

• EUCAST (Europe-default; Estonia) and CLSI (US-default and some other zones) — antimicrobial susceptibility breakpoints.
• WHONET 5 — international microbiology surveillance file format.
• HL7 FHIR R4 — Observation (with hasMember grouping, component substructure for organism/AST), Specimen, DiagnosticReport.
• LOINC — culture and susceptibility test codes.
• SNOMED CT — organism identification codes.

What customers and operators experience

• A microbiology bench technician sees positive cultures appearing in the dashboard with the appropriate Day-N task on each card; opens the bench-form for Gram stain entry, identification entry, or AST entry; the breakpoint engine pre-computes interpretations they can accept or override.

• An infection-control practitioner opens the cumulative antibiogram view, drills into MRSA in the ICU over the last 12 months, sees outbreak signals raised when clusters appear, and receives notifications when a critical multi-drug-resistant organism is identified.

• A clinician treating a septic patient sees the staged reports as they release: Day 1 "growth detected" within hours of incubation; Day 2 "Gram-positive cocci" enabling early empirical therapy refinement; Day 3 "S. aureus" plus AST guiding definitive therapy. Each is a real preliminary report in the FHIR chain, not a phone call.

• A surveillance partner (WHO, ECDC equivalent, regional AMR programme) receives WHONET-format exports on schedule with no manual handling.

• A laboratory director reviews quality dashboards showing contamination rates, AST entry-time SLA compliance, critical-result notification times — data the lab can act on operationally.

Limits and trade-offs

• Microbiology workflow definitions are non-trivial. Per specimen type, the workflow varies — blood culture has more stages than urine; CSF has different significance thresholds than wound. Authoring these workflow definitions is real work the lab director and platform team share.

• Breakpoint dataset maintenance is a regulatory function. EUCAST publishes annual breakpoint updates; the zone administrator is responsible for catalogue updates. Stale breakpoints produce wrong S/I/R interpretations.

• Manual interpretation override carries risk. The breakpoint engine computes from data; the technician can override with reason. Bad overrides produce wrong clinical guidance. Audit trail and reason capture surface concerns for QC review but do not prevent error in the moment.

• Cumulative antibiogram aggregation is sensitive to inclusion rules. Excluding duplicate isolates, defining "first isolate per patient per period", scoping by ward — these are calibration decisions that materially affect the report. The platform offers CLSI M39-aligned defaults; lab leadership can refine.

• Outbreak signals can produce false positives. A cluster detection fires from data; the infection-control team evaluates and resolves. The platform supports investigation workflow but does not replace human judgement.

• WHONET export interoperability depends on field conventions. WHONET is widely used but not strictly enforced; per-recipient quirks are real and the lab may need per-partner export profiles.

Related features

• Standardized service catalogue — microbiology test entries, EUCAST/CLSI breakpoint datasets, organism reference data live in the zone catalogue.
• Lab order lifecycle — microbiology orders flow through the same chain; observations carry organism substructure.
• Task-driven workflow engine — staged-reporting workflow definition is a PlanDefinition.
• Lab operations dashboard — microbiology cards surface staged tasks; AST entry opens the specialised grid UI.
• Result validation and release — microbiology results validate per stage; final report releases on signoff after AST.
• Diagnostic report assembly — preliminary reports release per stage; final supersedes.
• Abnormal-result escalation — critical organisms / resistance patterns escalate as notify-clinician Tasks.
• Quality-control workflow — microbiology QC includes contamination rate metrics.
• Per-zone reference ranges — breakpoint datasets are zone-canonical.

Why this matters

A laboratory typically receives orders from several channels. A hospital that already runs an HIS sends orders from there; a clinic without HIS uses the in-platform UI; a partner referrer uses the national e-direction service; a research-cohort investigator submits orders via FHIR REST. A platform that handles each channel as a separate code path produces inconsistent behaviour — orders from one channel might carry richer clinical context than from another, status updates flow back to some sources but not others, audit trails differ.

The right shape is one canonical gate: every order, from every source, becomes the same ServiceRequest shape, going through the same lifecycle. Channel-specific work happens inside an input adapter; once the order is materialised in FHIR, it is indistinguishable from any other order.

What's in the box

• One canonical FHIR shape regardless of source. Every intake produces a ServiceRequest (or RequestGroup for panel expansion) referencing catalogue entries by canonical URL.

• Channel-specific input adapters. Medipost-in adapter, Lab UI adapter, FHIR REST receiver, HIS-bridge adapters (one per HIS family). Each is one species of the integration adapter framework.

• Acknowledgement back to the source. Where the source expects acknowledgement (Medipost, HIS), the adapter sends the appropriate response after successful materialisation.

• Source identity preserved. The original placer order number, source system identifier, and any source-specific context ride on the ServiceRequest as identifiers and extensions, so result delivery can route back correctly.

• Catalogue resolution at intake. The adapter resolves the source's test code to the lab's catalogue offering before materialising the order; mismatches surface as exception Tasks, not silent ingestion failures.

Standards we lean on

• HL7 FHIR R4 — ServiceRequest, RequestGroup.
• IHE LTW (Laboratory Testing Workflow) — placer-order semantics from HIS sources.
• HL7 v2 ORM (placer order) — for legacy HL7v2 sources.
• National e-direction protocols (Medipost equivalents) — per zone.

What customers and operators experience

• A clinician using their HIS places an order in their familiar tool; the order arrives in Lab through the HIS-bridge adapter without any re-keying.

• A clinician without HIS uses the in-platform Lab UI to pick the patient, pick tests from the catalogue, attach context, and submit; the order materialises identically.

• A partner clinic referring through Medipost places the order in their own system; Medipost delivers it to Lab; Lab acknowledges back to Medipost.

• A research investigator posts a ServiceRequest directly via FHIR REST.

Limits and trade-offs

• Source code mappings need maintenance. Each HIS-family adapter carries a code-mapping table from HIS-specific test codes to LOINC; the table needs updating as the HIS catalogue evolves.

• Cross-channel deduplication is the orderer's responsibility. If the same clinical order is sent through two channels, the platform receives two FHIR orders.

• Acknowledgement timing varies by channel. Real-time on pure FHIR; HL7 ACK on MLLP; per-Medipost-spec on Medipost.

Related features

• Lab order lifecycle — orders from intake enter the FHIR chain.
• Integration adapter framework — input adapters are one species in the framework.
• Catalog-driven routing — intake resolves catalogue codes; routing decides where each test goes.
• External LIS bridge — one species of HIS-bridge input adapter for legacy LIS sources.
• Multi-channel result delivery — symmetric feature on the output side.

Why this matters

Orderers expect results in their workflow, not in yet another inbox. A clinician using their HIS expects results inside their HIS; a referrer using Medipost expects them via Medipost; a partner integration expects FHIR; an individual practitioner might prefer email. A platform that picks one delivery channel and forces everyone into it loses adoption; a platform that hand-codes each delivery integration produces the same drift the input side suffered.

The right shape: the orderer (or their organisation) declares a delivery preference; the released DiagnosticReport is handed to the right output adapter; the adapter handles channel-specific encoding, retries, and acknowledgement.

What's in the box

• Output adapters per channel. Medipost-out, FHIR push, email, HIS-API push, in-platform inbox notification. Each is one species in the integration adapter framework.

• Delivery preference per orderer or organisation. Configurable per practitioner / per requesting organisation; default per zone or per tenant.

• Retry and acknowledgement. Adapters track delivery status; failures retry per the channel's policy; un-deliverable reports raise exception Tasks for the lab supervisor.

• Critical-result delivery escalation. Critical reports follow a faster path with phone-call escalation if the primary channel does not acknowledge within the SLA.

• Delivery audited. Each delivery attempt and outcome is a Provenance entry on the report.

Standards we lean on

• HL7 FHIR R4 — DiagnosticReport is the canonical shape for all output channels.
• IHE LTW LAB-3 — laboratory-to-orderer delivery.
• HL7 v2 ORU — for legacy HL7v2 endpoints.
• National e-direction protocols (Medipost equivalents) — per zone.

What customers and operators experience

• A clinician using their HIS receives results in their HIS inbox.
• A referrer using Medipost receives results back through Medipost.
• A partner integration receives results as FHIR push to the configured webhook.
• A small practice with no integration receives an email notification with a secure link.

Limits and trade-offs

• Channel preference is a per-orderer setup cost. Default zone/tenant settings cover the common case; per-orderer configuration is for the long tail.

• Acknowledgement semantics vary by channel. Real-time on FHIR; HL7 ACK on MLLP; per-Medipost on Medipost; email lacks reliable delivery confirmation (the platform records send, not receipt).

Related features

• Lab order lifecycle — delivery is the chain's terminal transition.
• Diagnostic report assembly — released reports go to delivery.
• Integration adapter framework — output adapters are one species in the framework.
• Multi-channel order intake — symmetric feature on the input side.
• Abnormal-result escalation — critical-result delivery uses faster paths.

Why this matters

Most laboratories run a subset of the tests they offer in-house and send the rest to partner labs — speciality assays, reference- laboratory genetic tests, send-out microbiology, regional reference panels. Without unified handling, send-out testing becomes operationally awkward: a paper requisition courier-shipped, a fax result returned, a manual transcription back into the lab's system. The orderer experiences delay, the lab carries error risk, and the chain of custody breaks.

Most LIS systems treat send-out testing as out-of-scope: "that's a courier and paper problem, not a system problem". The result is that send-out volume runs on a parallel manual track with its own reconciliation overhead.

Jengu Lab's promise: send-out testing is a routing decision in the catalogue, not an out-of-band process. A test cataloged as partner:<partnerLabId> dispatches to that partner via Medipost on order materialisation; the partner's result returns through Medipost-in and lands in the same FHIR chain as in-house results; the orderer sees one report. The lab director can re-route a test from in-house to partner (or vice versa) as a catalogue edit.

The strategic value: send-out testing stops being a parallel operational track and becomes a routing rule like any other.

What's in the box

• PartnerLab device type. Each partner laboratory the lab works with is registered as a PartnerLab device, configured with the partner's identifier in the e-direction network (Medipost equivalent), the tests the partner handles for this lab, and the negotiated turnaround SLA.

• Catalogue routing to partners. A lab catalogue offering declares a routing rule of partner:<partnerLabId> for tests the partner runs. Catalog-driven routing dispatches matching orders to the right partner.

• Order dispatch via partner-network protocol. When an order routes to a partner, a partner-dispatcher operator emits the order via Medipost (or the equivalent partner-network protocol for the zone). The original ServiceRequest records the partner reference; status updates from the partner reflect on the original order.

• Partner result ingestion. Partner results return through the same channel; the platform's input adapter for the partner-network protocol materialises them as Observation resources referencing the original ServiceRequest. The result enters the same validation, assembly, and delivery flow as in-house results.

• Turnaround tracking. The partner's negotiated SLA appears on the order's restriction.period.end; the workflow engine tracks deadline; SLA breaches raise exception Tasks for the lab supervisor (or trigger automatic escalation per partner configuration).

• Partner-specific catalogue mapping. Where the partner uses different test codes, the partner's Device configuration carries a code-mapping table from the lab's catalogue codes to the partner's codes. The dispatcher applies the mapping at order time; the inverse on result return.

Standards we lean on

• HL7 FHIR R4 — Device (type=PartnerLab), ServiceRequest, Observation, DiagnosticReport. The partner is also typically represented as an Organization.
• National e-direction protocols — Medipost (Estonia) and zone equivalents.
• HL7 v2 ORM/ORU — for partners that integrate via classic HL7 messaging.
• IHE LTW (Laboratory Testing Workflow) — the lab is the Order Placer when sending to a partner; the partner is the Order Filler.

What customers and operators experience

• A laboratory director decides which tests run in-house and which go to partners as a catalogue configuration; switching a test between in-house and partner is a catalogue edit.

• A lab technician sees partner-routed orders on the dashboard with their partner-routing status (sent, in progress at partner, result returned); no separate send-out tracking system.

• A clinician ordering a panel where one constituent is send-out receives one panel report at the end; the in-house results may release earlier (as preliminary) and the send-out result appends when it returns. The clinician does not need to chase the send-out separately.

• A partner laboratory receives orders for tests they handle for this lab via their normal e-direction interface; return results the same way; their interface to Jengu Lab is no different from their interface to any other lab in the network.

• A lab supervisor sees partner SLA breaches in the exceptions lane; intervenes when an external lab is consistently late.

Limits and trade-offs

• Partner relationships are out-of-band. The platform models the integration; the lab's contractual arrangement with each partner is a real-world relationship the platform does not manage.

• Partner protocol coverage depends on adapters. Medipost is the Estonian-zone path; other zones need their equivalent partner-network adapter authored against the integration framework. A partner that doesn't speak any standard protocol (custom XML, vendor-private API) requires a per-partner adapter.

• Partner result quality is the partner's responsibility. The platform receives what the partner sends; format errors, unit mismatches, or coding inconsistencies surface as exception Tasks but the partner has to fix them at source.

• Send-out billing flows through the lab. The lab is typically billed by the partner and charges the orderer; ChargeItem flow follows in-house testing semantics, with the partner cost as a billable input. Detailed handling lives in the billing module.

Related features

• Catalog-driven routing — routing rule partner:<id> dispatches to a PartnerLab device.
• Multi-channel order intake — partner result ingestion uses the same input adapter framework.
• Multi-channel result delivery — partner-routed results flow through the same delivery path as in-house results.
• Lab order lifecycle — partner orders enter the same FHIR chain.
• Standardized service catalogue — catalogue offering's routing rule selects a partner.
• Lab device integration — the in-house counterpart; partner network and in-house analyzers are the two routing destinations for non-manual testing.
• Working alongside existing LIS systems — related but distinct: legacy LIS bridge is for orchestrating the lab alongside an incumbent system; partner lab network is for outsourcing tests the lab does not run.
• Platform: Device management framework — PartnerLab is another device type registered with the platform framework.
• Module: jengu-billing — partner cost handling integrates via ChargeItem flow.

Why this matters

Reference ranges look universal — "normal sodium is 135-145 mmol/L". They are not. National laboratories standardise on slightly different ranges, instrument vendors quote different ranges, paediatric patients have different ranges than adults, pregnant patients differ from non-pregnant, dialysis patients differ from baseline, and specific clinical contexts (post-operative, oncology, intensive care) adjust further.

A platform that presents one reference range for everyone produces two failure modes at once. Clinicians in jurisdictions whose national standard differs from the platform's default see results flagged as "abnormal" when the result is actually normal for their jurisdiction's standard. Clinicians treating non-baseline patients see "normal" results that are actually abnormal for the patient in front of them. Both undermine clinical trust in the lab.

The strategic value of getting this right: a single platform serves multiple jurisdictions and multiple patient populations honestly. Reference values are a property of the (zone, patient context, test, analyzer) tuple, not a global constant.

What's in the box

• Reference data is per-zone configuration. The compliance zone chain (zone-eu → zone-ee → ...) carries reference value bundles. Each zone declares a default reference table per test code; child zones override or extend.

• Patient context modifies the lookup. At result-display time, Lab evaluates the patient's age, sex, life stage (pregnancy, paediatric), and any clinical context flags carried on the patient record. The applicable reference range is the most-specific match.

• Per-instrument refinement. Where an instrument's results systematically differ from a method-based reference (e.g., vendor-specific calibration), the codec contributes per-instrument adjustments documented in the codec's configuration.

• Tenant override is possible but audited. A hospital with internally-validated ranges can override the zone defaults for specific tests. Each override is a configuration change in the git config repo with a reviewer and a rationale.

• Reference data updates flow through the zone. A jurisdiction updating its reference standards updates the zone's reference bundle; tenants in that zone pick up the change without per-tenant configuration.

Standards we lean on

• HL7 FHIR R4 ObservationDefinition — the standard shape for reference data, including qualifiedInterval for context-specific ranges.
• IFCC — International Federation of Clinical Chemistry reference-interval methodology informs zone defaults.
• CLSI EP28-A3c — best-practice guideline for establishing and verifying reference intervals.

What customers and operators experience

• A clinician in zone-ee (Estonia) sees reference values recognised by the Estonian laboratory medicine community. A clinician in zone-de (when delivered) sees German ones — same software, different reference data, all correct.
• A clinician treating a paediatric patient sees age- and weight-adjusted reference values automatically.
• A clinician treating a pregnant patient sees pregnancy-adjusted ranges. Pregnancy state is from the patient context; the adjustment is applied automatically.
• A laboratory director onboarding a tenant does not configure reference ranges from scratch; the zone chain brings the jurisdiction's standard. Customisation is allowed on top.
• A regulator reviewing the platform sees that reference values trace back to a documented source for each zone. The source is reviewable, not hidden inside the platform.

Limits and trade-offs

• Patient context completeness bounds correctness. If a patient's age is missing or pregnancy status is unrecorded, the platform falls back to the most-defensive (adult, non-pregnant) reference rather than guessing.
• Reference standards are not universal even within a zone. Two Estonian hospitals may use different laboratory-medicine guidelines. The zone provides a default; tenants override where their internal practice differs.
• Edge cases require explicit configuration. Dialysis patients, oncology patients, transplant recipients — each may need clinical-context flags the platform recognises.
• Reference data evolves. Maintaining per-zone reference bundles is ongoing work; they go out of date if not curated.

Related features

• Standardized service catalogue — reference ranges hang off catalogue entries.
• Lab order lifecycle — reference ranges are applied at result-finalisation time.
• Abnormal-result escalation — the reference range determines what counts as abnormal.
• Platform: Compliance zones — reference data inherits the zone chain.
• Platform: Open standards data portability — reference ranges flow as FHIR ObservationDefinition resources.

Why this matters

Laboratory accreditation — ISO 15189, country-specific accreditation schemes — requires documented quality control. Inspectors expect to see calibration records for every instrument, internal QC results for every analytical run, external QC participation with documented performance, and corrective actions for every QC failure. A lab without this evidence loses accreditation; a lab with disorganised evidence spends weeks before each inspection assembling it.

Many labs handle QC in spreadsheets, separate QC software, or the analyzer vendor's own QC tooling. None of those flow into the lab's clinical record system; none of them produce a unified narrative for an inspector. The lab director knows where the evidence is — in several places — and reassembles it for each audit.

The strategic value of building QC into the platform: the QC narrative is always assembled, always current, always tied to the same patient-result records the lab produces clinically. The lab director shows the inspector one system; the inspector reviews one trail. Inspections become routine.

What's in the box

• QC is an extension of the order lifecycle. Internal QC runs are ServiceRequest resources flagged as QC, producing Observation results stored in the same store as patient results. The same chain of custody, audit, and result evaluation applies.

• Calibration as an audited transition. Each calibration is a discrete event in the instrument's history: who performed it, when, with which calibrator lot, with what result. The instrument's Device resource carries its calibration history.

• QC rules per analyzer per zone. Internal QC rules (Westgard rules, custom thresholds) are configured per instrument; the zone provides defaults aligned with the jurisdiction's accreditation expectations.

• External QC integration. Standard formats (RfB, EQAS, RIQAS, others) are supported as configuration; sample results are exported in the scheme's expected shape; results returned by the scheme are imported and reconciled.

• Corrective-action tracking. When QC fails, an action item is created with a defined response chain. Items remain open until acknowledged with an explanation; inspectors see the closure history.

Standards we lean on

• ISO 15189 — quality management for medical laboratories; the dominant accreditation standard.
• CLSI C24 — statistical quality-control methodology; Westgard rules used as default.
• HL7 FHIR R4 Device, Observation — calibration history and QC results carried on standard resources.

What customers and operators experience

• A laboratory director sees a unified QC dashboard per instrument: latest calibration, latest internal QC runs, external QC scheme participation status, any open corrective-action items.
• A laboratory technician runs internal QC on schedule; results enter the same system as patient results, flagged as QC. Out-of-acceptance QC triggers a defined response chain (re-run, recalibrate, escalate to supervisor).
• An external QC scheme participant receives external QC samples, processes them like normal patient samples, and the platform formats the results for submission to the scheme. Submission is a one-click step.
• A laboratory accreditation inspector is shown a single trail: instrument X, calibration history, internal QC history, external QC participation, deviations and corrective actions.
• A regulator following an incident can see the QC posture of the instrument at the time of the incident — was it in-control, out-of-control, recently-calibrated, overdue.

Limits and trade-offs

• QC scheme support is finite. The platform supports common European external QC schemes; a lab participating in a niche scheme may need configuration work for that scheme's submission format.
• Calibration policy is the lab's responsibility. The platform tracks what was done; it does not decide what should be done. Calibration cadence, acceptance criteria, and recalibration triggers are tenant configuration.
• Out-of-acceptance handling is policy-driven. The platform supports configurable response chains; whether a specific QC failure pauses processing or merely flags depends on tenant policy. Defaults err toward safety.
• The platform is not an accreditation consultancy. Building the right QC posture for a given accreditation scheme remains the lab's expertise; the platform makes that posture loggable, not designable.

Related features

• Device integration framework — codecs feed both patient results and QC results into the same chain.
• Lab order lifecycle — QC runs use the same lifecycle and audit machinery as patient orders.
• Platform: Regulatory audit trail — every QC event, calibration, corrective-action item lives in the same audit trail.
• Platform: Compliance zones — accreditation expectations vary by jurisdiction; zone defaults reflect that.

Why this matters

A laboratory result is not just data — it is a clinical artefact that drives diagnostic and treatment decisions. The release of an unverified abnormal result can lead to harmful clinical action; the silent overwrite of a flawed result without an audit trail makes incident review impossible. Every regulator and every accreditation body requires the lab to demonstrate that:

• Each released result was reviewed by a qualified person before release.
• Amendments and overrides to released results are explicit, not silent rewrites.
• Every change carries who, when, and why.
• Historical reports remain reproducible — the result the orderer saw at the time of clinical action can be reconstructed.

The validation and release transitions are where this discipline lives. The right shape is explicit FHIR Observation status transitions (preliminary → final → amended / corrected / entered-in-error), each transition gated by role, each carrying a Provenance record that names actor, reason, and prior state. The released DiagnosticReport references the authoritative version; the FHIR resource history retains every prior version.

The strategic value: regulator-ready quality controls become a property of the data model rather than an audit-time scramble.

What's in the box

• Four transitions, four discrete acts. Validate confirms a result is reasonable and clinically interpretable; the observation moves preliminary → final. Amend corrects a released result with a small change (typo, unit error, partner-lab numerical correction); the observation moves final → amended with a Provenance trail. Override asserts a different value with a reason (sample contamination discovered, repeat measurement supersedes); the observation is superseded by a new version with derivedFrom reference. Sign off releases a DiagnosticReport to the orderer; the report moves preliminary → final.

• Role-gated by observation type. Chemistry validation is bench-tech-permitted; abnormal-flag validation requires validating-tech role; sign-off on any report requires senior tech or pathologist; override of a released result requires validating-tech with audit reason. Roles are configurable per zone and per tenant.

• Reference range snapshot at result time. When the observation is produced, the catalogue's current reference range is captured onto the observation. Validation reads the snapshotted range, not the current catalogue. Re-rendering a historical report uses the original range and produces the original interpretation flag.

• Reason capture is mandatory on amendment and override. The technician is required to record a reason; the reason is stored on Provenance.reason. Free-form text is permitted but the platform offers a curated reason taxonomy by zone for consistency.

• Critical-result holds gate release. When an observation carries a critical-result interpretation, sign-off is held until a notify-clinician Task confirms the clinician was reached; the platform records the notification act as a Provenance entry on the report.

• Released results remain immutable in display. Subsequent amendments or overrides produce new versions; the original released version is queryable forever. The orderer sees the current authoritative version; the audit trail shows every prior version with rationale.

Standards we lean on

• HL7 FHIR R4 — Observation.status, DiagnosticReport.status, Provenance for change records, FHIR resource history.
• CLSI / EP / IFCC — laboratory practice norms for validation and amendment.
• @Audited REQ-traced obligations — every transition carries an audit obligation.

What customers and operators experience

• A bench technician reviewing a batch of automated results sees them in the dashboard's awaiting-validation lane; validates the in-range ones with a single action; flags the abnormal ones for the validating-tech queue.

• A validating technician opens an abnormal result, reviews reference range and clinical context, validates with a brief comment, or amends with a correction reason if the value is wrong (e.g. partner lab transmitted value with comma instead of period).

• A senior technician or pathologist signing off a microbiology report reviews the panel result set, the staged history, and the critical-result acknowledgement before signing.

• A regulator reviewing an incident queries the audit log + Provenance trail and reconstructs every actor, every change, every rationale across the release lifecycle.

• An orderer who received a result that was later amended sees a notification carrying the amendment and the reason; the original released result remains in the audit history.

Limits and trade-offs

• Role gates and reason capture add friction. A lab that imposes excessive validation overhead for routine work loses technician time. The platform offers per-observation-type workflow definitions tuning where validation is required vs auto-released; lab leadership owns the calibration.

• Override governance is intentionally heavy. Asserting a different value than the device produced is a compliance- significant act; the platform requires a reason and records Provenance. If overrides are common, the upstream cause (device drift, sample handling) is the real problem to fix.

• Critical-result hold blocks release. A clinician who is unreachable delays release. The platform escalates after the configured SLA; the lab supervisor owns the path forward.

• Reproducibility is per-snapshot, not point-in-time across the catalogue. Reference range on the observation is what the platform produces; if the lab references external reference data not snapshotted (older clinical guidelines, external decision tools), reproducibility is the lab's responsibility for those external dimensions.

Related features

• Task-driven workflow engine — validation, amendment, sign-off are workflow Tasks per the observation type's PlanDefinition.
• Diagnostic report assembly — sign-off transitions the report; assembly groups validated observations.
• Lab order lifecycle — validation and release are transitions on the FHIR chain.
• Lab operations dashboard — validation Tasks surface as cards in the awaiting-validation lane.
• Standardized service catalogue — reference range snapshotting reads from the resolved catalogue at result time.
• Abnormal-result escalation — critical-result handling defers sign-off until clinician is notified.
• Microbiology workflow — staged-reporting validation differs from chemistry numeric-result validation.
• Platform: Audit annotations and traceability — every transition is REQ-traced.

Why this matters

A laboratory's test catalogue is the foundation everything else references — orders, results, reference ranges, QC rules, billing codes, registry submissions. A lab without a managed catalogue runs on improvisation; a lab whose catalogue lives in a spreadsheet maintained by the senior biochemist cannot survive their retirement.

But catalogue content is not laboratory-specific work. A glucose test has the same LOINC code, the same Tervisekassa code, the same broad reference range whether it is performed in Tartu or Tallinn or Pärnu. Each lab maintaining its own copy of that content produces exactly the failure mode the catalogue is supposed to prevent: a multi-site organisation has N catalogues that drift apart; a code update is a per-lab manual change that some labs miss; switching LIS vendors means re-keying the catalogue.

The right shape is layered. The zone owns the canonical catalogue — LOINC codes, national codes (Tervisekassa in Estonia, NABM in France, EBM in Germany), default reference ranges, sample requirements, result-template metadata — and maintains it once with regulatory oversight. Each lab points at the zone catalogue for the services it offers and adds only the things the zone cannot know: which device runs the test, what the lab charges for it, whether the lab has a methodologically-specific reason to override a default. There is no duplication, no manual merge, and zone updates appear at the lab the next time the catalogue is read.

The strategic value: catalogue maintenance is a regulatory function done once per zone, not a labour-intensive responsibility per lab. Labs focus on the parts of the catalogue that are genuinely theirs.

What's in the box

• Zone-canonical catalogue as FHIR ActivityDefinition, PlanDefinition, and ChargeItemDefinition resources living in the zone module's project (e.g. zone-ee for Estonia). Each entry has a stable canonical URL that other systems reference.

• Lab offerings as small per-tenant records pointing at zone canonical URLs. The lab record carries only what the lab itself owns: routing rule (which device, partner lab, or manual queue handles this test), price, optional turnaround SLA. Most lab records are a few fields plus a reference.

• Reference, not duplication. When the zone updates a test — new LOINC mapping, revised reference range, updated Tervisekassa code — the change is visible to every lab offering that test the next time the catalogue resolver runs. No per-lab sync action required.

• Rare audited overrides. A lab can override individual fields on a referenced entry where it has a real methodological or contractual reason — a different reference range derived from in-house validation, a non-default sample requirement. Overrides are sparse (only the changed fields), recorded with a reason, and audited. Lab admins are notified when a zone update touches a field they have overridden so they can review whether their override is still warranted.

• Reference-range snapshot at result time. When a result is produced, the resolved reference range is captured on the Observation itself. Re-rendering historical reports always reproduces the original interpretation, even if the zone updates the range later.

• Catalogue propagation to edges. Edges receive the resolved catalogue (zone fields merged with lab overrides) through IHE LCSD distribution. Edge runtime sees one effective catalogue per tenant, with no concept of layers.

• Panels and groups as PlanDefinition. A clinical-chemistry panel ("basic metabolic", "comprehensive metabolic") is a PlanDefinition referencing constituent ActivityDefinitions. Ordering against a panel expands to multiple ServiceRequest resources, each tracked individually but grouped on the released report.

Standards we lean on

• LOINC as the canonical test identifier in every entry.
• HL7 FHIR R4 — ActivityDefinition, PlanDefinition, ObservationDefinition, ChargeItemDefinition carry the data; canonical URLs (FHIR's standard cross-system reference mechanism) carry the layered references.
• IHE LCSD (Laboratory Code Set Distribution) for cloud-to-edge catalogue propagation.
• National coding standards — Tervisekassa (Estonia), NABM (France), EBM (Germany) — layered on LOINC at the zone level.

What customers and operators experience

• A zone administrator (the regulator-facing role) maintains the zone catalogue: adds new tests as national coding evolves, updates Tervisekassa-equivalent codes, revises default reference ranges. Their work happens once, in one place, and reaches every lab in the zone.

• A laboratory director picks from the zone catalogue the services their lab offers, sets routing (which device or partner lab handles each test), and prices each service. They almost never edit reference ranges or codes — those come from the zone by default. When they do override, the system asks why and keeps the audit trail.

• A clinician ordering a test searches a unified catalogue showing only what their lab offers; the LOINC and national codes are correct because they came from the zone; the reference range is correct because it came from the zone or from the lab's validated override.

• An LIS bridge mapping incoming external orders matches the external system's codes to LOINC and resolves through the lab's offerings — the LIS does not need to know about the layered structure.

• A national registry consuming results sees standard LOINC codes plus the zone's national-code variant; the result is recognisable across labs in the same zone because the codes come from a shared source.

• A multi-site organisation sees aligned catalogues across its labs by construction, because each lab references the same zone catalogue. Drift happens only at the lab-specific override layer, which is small and audited.

Limits and trade-offs

• Zone catalogue maintenance is the zone administrator's responsibility. Labs benefit from a curated source of truth but depend on it being kept current. Stale zone catalogues affect all labs in the zone.

• Override governance is intentionally heavy. Sparse overrides with required reasons and audit trails are deliberately more work than freely editing per-lab values. The friction is the point — override should be a considered decision, not a casual edit.

• Reference-range methodology is sometimes a real reason to override. Some methods produce systematically different ranges; those overrides are legitimate and the system supports them, but the lab carries the burden of validating and documenting the rationale.

• Cross-zone catalogue alignment is not enforced. A test in zone-ee and zone-fi share the LOINC code but have different national-code variants and possibly different default reference ranges. Multi-zone reporting needs to cross zones at the LOINC level, not at national codes.

• Zone update timing affects in-flight work. A zone change to a reference range applies to new results. Historical observations retain the range that was in force when they were produced — the catalogue update does not retroactively re-interpret old results.

Related features

• Lab order lifecycle — orders are picks from the catalogue.
• Multi-channel order intake — every intake channel resolves test codes through the catalogue.
• Catalog-driven routing — the routing decision is encoded in the lab's catalogue offering.
• Per-zone reference ranges — reference ranges live in the zone catalogue with optional lab overrides.
• Result validation and release — reference range used for interpretation is snapshotted on the Observation from the catalogue at result time.
• Diagnostic report assembly — panels (PlanDefinition) drive the report grouping.
• Microbiology workflow — a microbiology test is a catalogue entry whose result template declares the staged-reporting workflow.
• Platform: Compliance zones — zone-specific catalogue lives in the zone module.
• Platform: Declarative tenant configuration — the lab's offerings and overrides live in the tenant's configuration source of truth.
• Module: jengu-billing — ChargeItemDefinition references in catalogue entries drive billing.
• Module: jengu-insurance — coverage and pre-authorization rules reference catalogue entries.

Why this matters

A laboratory's operational quality is precisely whether the right work happens at the right time, by the right person, before the deadline. Without an engine, that coordination is a mix of spreadsheets, mental models, and morning handover meetings — fine when staffing is full and volume is steady, fragile when staff are sick or volume spikes.

The right shape is durable, declarative, queryable workflow. Each unit of work is a FHIR Task with a status, an owner (a person, a device, or unassigned-in-a-queue), a focus (the observation or specimen the task is about), and a deadline. State transitions are explicit; dependencies are explicit; reassignments are explicit and audited. The engine spawns the next Task when its predecessor completes. SLA-violation events fire automatically when deadlines pass without completion.

What this gives the lab: every unit of work is visible, every deadline is tracked, every reassignment is recorded, and the operational coordination becomes data — queryable for management reporting, replayable for incident review, observable through the dashboard.

The strategic value: the workflow engine is the operational nervous system of the lab. Once present, every other feature (dashboard, validation, microbiology staged reporting, exception escalation) is implementable as workflow definitions over the same primitive.

What's in the box

• FHIR Task as the durable state primitive. Each task has status (requested, accepted, in-progress, completed, cancelled, failed), owner (a Practitioner or Device), focus (the resource being acted on), priority, restriction.period.end for deadlines, and partOf links for parent-child relationships.

• Workflow definitions as data. Each observation type has a PlanDefinition declaring its workflow: which Tasks spawn at which transitions, role gates per Task, default deadlines, and the lane set for the dashboard. Adding a new test species is authoring a new PlanDefinition, not changing engine code.

• Temporal-orchestrated. The platform's existing Temporal workflows host the orchestration logic. Per-tenant Temporal namespaces ensure isolation; durable timers handle SLA countdowns; signals handle human reassignments and cancellations.

• Three task species, one engine. Machine tasks (run on device, dispatch via Medipost), human tasks (validate, amend, sign off, enter manual reading), and exception tasks (QC drift, device error, critical result, SLA breach). Same Task resource shape, different sources, different routing.

• Role-gated transitions. A Task declares the role(s) permitted to claim it; the engine refuses claim attempts from outside the role. Lab supervisor can override with audit trail.

• Reassignment, escalation, and drift detection. Tasks can be reassigned (to another person, to a queue) and escalated (priority bumped, supervisor notified). QC drift detection raises Tasks based on accumulated control runs against Levey-Jennings/Westgard rules.

Standards we lean on

• HL7 FHIR R4 — Task, PlanDefinition, Provenance.
• Temporal for durable workflow orchestration (already in the platform stack).
• @Audited/REQ-AUD-* — every Task transition is REQ-traced.

What customers and operators experience

• A bench technician sees their queue of pending Tasks (own Tasks + claimable from the section queue), claims one, completes it through the dashboard's specialised UI, and the engine spawns the next task in the chain.

• A lab supervisor reviews the SLA-aging view to see Tasks approaching or past deadline; reassigns work; escalates problem cases.

• A lab director introducing a new test family authors a workflow definition (PlanDefinition) declaring the lifecycle; a sub-module contributes the Task-type UI handlers; the engine begins running the new workflow on next tenant config reload.

• A regulator reviewing operational compliance queries the audit log + Task history to reconstruct exactly what happened to any specific order, who handled each step, and when.

Limits and trade-offs

• Workflow authoring is a real skill. A bad workflow definition produces bad operational behaviour — wrong roles, wrong deadlines, missing transitions, or stuck states. Lab directors and the platform team own this together; the platform provides workflow templates and validators.

• Temporal adds operational surface. Per-tenant namespaces, worker pods, workflow versioning are all operational concerns the platform team carries. The benefit (durable timers, signal-cancellable workflows, replayable history) earns the surface, but it is not free.

• Per-task durability has a cost. Persisting every Task transition is heavier than tracking implicit status on resources. The audit and operational benefits more than pay for the cost in laboratory contexts; in latency-sensitive contexts they might not.

• Exception classes need calibration. Too many exception-lane cards and the supervisor stops reading them; too few and real exceptions slip through. The platform provides default thresholds; per-zone and per-tenant overrides are expected.

• The engine does not author lab work. It tracks, gates, and routes. The actual numeric validation, AST entry, sign-off decisions happen in specialised UIs contributed by sub-modules.

Related features

• Lab operations dashboard — the human-facing surface above the engine.
• Result validation and release — defines validation/amendment/override Tasks and their transitions.
• Diagnostic report assembly — sign-off Tasks gate report release.
• Microbiology workflow — staged-reporting workflow definition (Day 1 prelim → ID → AST → signoff).
• Clinical chemistry workflow — numeric-result workflow definition.
• Quality-control workflow — QC drift detection raises Tasks into the exceptions lane.
• Abnormal-result escalation — critical-result detection raises notify-clinician Tasks.
• Platform: Temporal workflows — the orchestration runtime.
• Platform: Audit annotations and traceability — every Task-transition method is @Audited(req = "REQ-AUD-NNN").