Jengu-Lab
Laboratory module — pluggable device codecs, LIS bridge, lab order lifecycle, per-zone reference ranges, AI-assisted result interpretation, QC workflow, edge-resilient operation, standardized service catalogue.
Jengu Lab is the laboratory module of the Jengu platform: a full-scope LIS that takes orders from anywhere, drives analyzers on-premise, organises workflow as live operational kanban, and delivers signed results back to the requester through the channel they prefer. It treats microbiology as a first-class discipline, not a chemistry afterthought, and it leans on the open zone-canonical service catalogue rather than asking each lab to maintain its own master file.
What Jengu Lab gives a laboratory
A working LIS, in customer terms:
- One screen for the running lab. An observation-keyed kanban shows every test moving through the lab in real time — accessioned, on-instrument, awaiting validation, ready to release, delivered. Supervisors steer the exception lane; analysts pick up the next thing. No tab-hunting across modules.
- Analyzers plug in, they don't get integrated. A new instrument — Cobas, Sysmex, Mindray, VIDAS, the model that ships next year — is a configuration entry plus a driver, both managed through the platform's device management framework. No bespoke integration project per analyzer.
- Orders arrive from wherever they live. Medipost, FHIR REST, the lab UI, HIS-bridge adapters all converge on the same ServiceRequest gate. The lab does not care which channel an order came in on; the orderer does not care how the lab handles it internally.
- Microbiology, done properly. Staged preliminary → final reporting, AST entry on a grid (not free-text), EUCAST/CLSI breakpoints applied automatically, cumulative antibiograms live, outbreak signals from your own data, critical-result handling, WHONET export for surveillance.
- Results delivered the way the requester wants them. Medipost to a partner network, FHIR push to a HIS, email to a GP, in-platform inbox for an internal clinician, TIS export to a national registry. One result-finalisation step; many delivery surfaces.
- Catalogue you don't have to maintain alone. The zone-canonical catalogue (LOINC, national codes, sample requirements, reference ranges, prices) is published by the zone — Estonia today, more jurisdictions later. Your lab picks which services to offer and sets your prices; you don't re-author what the zone already publishes.
- Quality and compliance built in. Internal QC, external QC, calibration tracking, audit-grade Provenance on every validation step, regulator-ready records — not bolted on as a separate product.
- Edge-resilient. Analyzers connect to an on-site appliance, not the cloud. A cloud outage doesn't stop your samples being run; reconciliation drains accumulated work when connectivity returns.
The full inventory of testable capabilities is on the Capabilities page.
How Jengu Lab fits a laboratory that already has a system
Most laboratories already run something — an incumbent LIS, a mix of analyzer-attached PCs, or both. We designed Jengu Lab to slot in alongside what's there before replacing it, so the cutover is staged rather than a flag day.
Stage 1 — Analyzers under management. Jengu Lab manages your analyzers through its device-integration layer; results write back to your existing LIS through the LIS bridge. The lab's operational workflow is unchanged; what changes is that adding a new analyzer is now configuration, not engineering. The bridge is bidirectional: orders come in from the incumbent LIS, results return to it; Jengu Lab is the device-driving layer underneath.
Stage 2 — Order intake and result delivery widen. Channels incumbent systems don't support cleanly — FHIR REST, partner-lab send-outs, multi-channel delivery — start flowing through Jengu Lab while the legacy LIS still owns the operational workflow. The lab gains capability without retiring the system its staff knows.
Stage 3 — Operational surface migrates. The observation-keyed kanban becomes the primary workplace. Validation, release, and reporting move into Jengu Lab. The legacy system shrinks to a historical record. Specialty workflows (microbiology in particular) move first, because the legacy system was probably weakest there.
Stage 4 — Legacy system retires. Jengu Lab owns the full LIS surface. Historical data exports in standard FHIR; no shadow parallel system left to maintain.
Each stage delivers value on its own. Customers can stop at stage 1, 2, or 3 indefinitely if that's what makes operational sense; we're not selling a forced migration.
What changes for the lab once Jengu Lab is fully in place
- Adding a test service is hours, not weeks. Pick it from the zone catalogue, set your price, pick the analyzer that runs it. No re-authoring LOINC codes, no fighting reference-range databases.
- Adding a new analyzer is configuration plus a driver. Not a procurement-blocking integration project.
- Microbiology stops being the painful module. Staged reports, AST grids, antibiograms come out of the same primitives that serve chemistry. Quality-of-life improvement that's hard to overstate.
- The compliance story is queryable. Every observation, validation, override, and release is on a single audit trail the lab can query, not a hunt across vendor logs.
- Cloud outages are inconvenient, not catastrophic. The on-site appliance keeps the samples running.
- The lab is no longer the vendor's deployment unit. A new Jengu release rolls out across labs without each one being the vendor's deployment project.
Where Jengu Lab fits in the broader Jengu platform
Jengu Lab is a module on the Jengu platform. The platform underneath provides multi-tenant isolation, audit trail, edge resilience, encryption, compliance zones, AI routing, recordings, and the device-management framework that all module-contributed external integrations register with. Reading the platform principles and the platform features explains the substrate Lab is built on.
Other modules built on the same platform — Visit Assistant for clinical visit capture, future Insurance and Billing modules — share that substrate. When a Lab order originates from a Visit Assistant encounter, both modules see the same clinical record without integration code between them; they're plugged into the same shared foundation.
Talk to us
For a demo or to discuss a pilot, write to jengu@jengu.cloud.