Module

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.