How Jengu works

Everyone involved in one patient's care takes part in a single process — the visit, the order, the result, the answer about coverage — and that process stays visible from beginning to end.

A patient's care is one process, and the process is the record. A visit opens it; a referral, a specimen, a result and a claim are steps inside it. At any moment the process says what has happened, what is waiting, and who it is waiting on.
Every step is a FHIR resource — the object each step reads and writes, not a FHIR façade built for the integration. That skips an entire layer of translation, which is both expensive and where things go wrong. It is also what lets an organisation take part without an integration project first, and the format Europe is standardising on.
Participants join the process itself. The laboratory sees the order that concerns it, the pharmacy sees the prescription with the intent behind it, the insurer answers coverage while the patient is still there.
What happened can be traced, and who did it can be proved. Every meaningful action is audit-logged, sensitive records open only with every owner's agreement, and identifying detail is removed before anything is processed downstream.
Work does not stop when the connection does. If the outside world becomes unreachable, the critical work carries on where it is happening; when the connection comes back, so does the exchange of data, on its own, without anyone having to do anything.

The areas below are what the platform delivers. Our principles explain the decisions underneath them, and user stories tell the same thing through real situations.

Care Visits

Visit Recording with Audited Consent — Clinicians record consultations with patient consent captured in-flow. Every recording action — start, pause, raw access, retention deletion — is audited. Recordings are encrypted at rest and never leave the tenant boundary unless an explicit, audited raw-access path is invoked.
Live Clinical Assists — Real-time during-encounter prompts: lab order suggestions, drug interaction warnings, role labelling, action detection. Anonymised before any LLM call. Sub-second latency so the clinician sees assists in conversation, not after the fact.
Smart Action Detection — A small, deliberate set of actions that have to be completed during the visit while the patient is present — slot bookings, on-the-spot referral pickups, follow-ups arranged in dialogue. Triggered either when the conversation calls for one, or when the clinician types into the always-available smart-action box. A focused form opens alongside the live recording; the clinician confirms with the patient; the booking is made, the referral is filed, the appointment exists from that moment. Most things a clinician says do not trigger a smart action — they're handled by note generation or routine detection. Smart actions exist for the few that genuinely need the patient's agreement now, not later.
Authoring Queue — Every recorded visit is a task in the doctor's queue until reviewed — across sessions and devices, nothing lost.
Inpatient Rounds Capture — A nurse walking inpatient rounds dictates observations bed-by-bed. Each observation knows which patient it concerns (from the patient context selected at that bed) and who is speaking (the nurse, derived from their login). The recording produces structured per-patient observations without manual transcription afterwards.
Visit Note Generation — A structured, FHIR-shaped clinical note is drafted from the recording's transcript. The clinician reviews, edits, and signs; the signed note appears on the patient's unified timeline immediately. The clinician's documentation time falls; documentation quality and consistency rise.
Patient-Facing Visit Summary — A lay-language take-home note in the patient's language, generated from the clinician's signed visit note. Includes structured follow-up actions: medications to take, appointments to keep, things to watch for, when to call the doctor. Reduces the gap between what the clinician said and what the patient remembers.
Televisit — Remote consultations between clinicians and patients (and between clinicians) over a LiveKit-based video and audio channel. Televisit composes the platform's Speech Anonymisation membrane (for the audio + transcript safety) with LiveKit room management (for video + remote multi-participant) and a patient-facing portal flow (for join links, identity verification, remote consent). The clinical surface — live assists, smart actions, signed note, patient timeline — is identical to in-person visits because both consume the same safe-transcript segment stream from the membrane.
MDT Meeting Capture — Multidisciplinary team meetings — case reviews, tumour boards, complex case discussions — captured with per-participant identity from the recording context. Each participant's contribution is identified at source; the resulting structured meeting note attributes decisions and rationales to the right speaker.

Clinical AI

Clinical Reasoning — One engine reasons from what is known about a patient — the coded observations, the earlier findings, the conditions still on the table — and returns two ranked lists: what this could be if we stopped looking now, and what would narrow it down fastest, whether that is a question to ask, an investigation to order or a test to run. It draws on the Medical Knowledge Base and runs on the right-sized AI pipeline . Every clinical AI feature that weighs evidence uses this same engine. Audience: clinical leadership, IT leadership, DPO, AI Act reviewers, compliance officers reviewing AI-decision support evidence chains.
Medical Knowledge Base — A shared body of clinical knowledge, drawn from international sources — which symptoms point to which conditions, which traits are typical of which diseases, which codes name the same thing in different systems . Every AI feature that reasons about possible conditions, useful questions or next investigations draws on it. Updates from the international sources reach every feature at once, while each region's own picture of what is common locally stays under the customer's control. Audience: clinical leadership, IT leadership, DPO, ISO 15189 reviewers, compliance officers reviewing AI-feature evidence chains.
Right-Sized AI Pipeline — Each kind of AI work runs on the model best suited to it — a fast, cheap one for real-time clinical assists; a powerful, slower one for nuanced summaries — and every customer's zone can choose its own providers.

Connected Devices

Device Hub — Device Hub is the module through which an organisation defines, grades, operates, and debugs every connector at its boundary — bench analysers, bridges to hospital and laboratory systems, ordering channels, partner networks. It is the product face of the Order Hub and the device management framework : a department-bindable module, enabled where the connectors physically are, that gathers the whole device-operations surface — the fleet, the edges, the wire traces, the specimen ranges — into one place with one access model. Sales label: Jengu Devices Integration . Audience: hospital IT leadership, lab managers, integration engineers (first-party and external), procurement.
Lab Device Integration — Clinical analyzers from any vendor — VIDAS, Cobas, Sysmex, Mindray, the model that ships next year — connect to Jengu Lab the same way: a driver plus its configuration. The lab core does not change when a new analyzer model arrives, and a driver written by one team is swappable for another implementation against the same published contract. The customer-visible promise: "your analyzers just work, without an integration project per instrument".
Device Management Framework — Every external system Jengu talks to — laboratory analysers, partner labs, insurer connections, accounting systems, the on-site appliances themselves — is configured, monitored, and audited in one place. One inventory, one configuration screen, one fleet view, one audit trail. Adding a new kind of external integration means adding a connector to the inventory, not building a separate operational story for it.

Connected Healthcare

Order Hub — Every clinical order the organisation receives, fulfils, or delegates passes through one component: the Order Hub. Orders arrive from clinics, hospital systems and ordering channels, land in one place, and go out to analysers, partner labs and external systems. The hub carries and stores orders; it deliberately does not decide how the work is done, so the customer's existing laboratory system, or a Jengu module, can sit on top of the same store. Each direction can be switched on alone, so the same component can act as a way of connecting devices, a way of receiving orders, or both at once. And because the analysers exist once while laboratory systems come in test and live versions, one hub serves both in parallel — same devices, same partners, same routes. Audience: hospital leadership, IT leadership, lab managers, laboratory-system vendors and integration partners, procurement.
Cross-Organisation Messaging — Staff messages cross organisations through the same privacy boundary as everything else.
Embedded Appliances — Jengu screens run inside the hospital's existing system — launched from their patient record, no separate login.
Open Healthcare API — Everything jengu does for clinical actors is reachable through one open, documented healthcare API, in the standard the industry already speaks.

Identity & Access

Delegated Sign-In — Clinics sign in with the identity provider they already trust — national eID, hospital single sign-on — through certified connectors.
User Session — A clinician signs in once, the platform binds the resulting session to exactly one user, one customer organisation, and (eventually) one set of trusted devices. Every transition — sign-in, sign-out, expiry, device pairing — is visible in the audit trail. Convenience never overrides the rule that a session belongs to a single, identifiable user.

On-Site Operation

Edge Fleet Management — Edges are enrolled, approved, monitored, updated, and retired through a single managed lifecycle. A CIO running thirty edges across five sites manages them from one cloud console — without per-device console access, without on-site engineer visits for routine work, and without manual tracking of who has what.
Hybrid Edge–Cloud Operation — Critical clinical work runs on-premise so a hospital keeps operating through disruptions beyond its control — internet, power, internal networking, supply chain. The cloud handles convenience features, central management, and integrations with external systems.

The Patient Record

Master Patient Index — One component in the platform holds patient identity. Every other part of it — every feature, every workflow, every screen a clinician sees during care — works from a reference that does not name anyone, and could in principle be run by someone else entirely. The Master Patient Index is the only way between the two: the only place a reference becomes a name, the only place personal data is exchanged with the outside world, and the only place a GDPR access or erasure request has to reach. Audience: hospital leadership, DPO, legal counsel, ISO 27001 reviewers, procurement.
Unified Patient Timeline — Across every module the customer enables — Lab, Visit Assistant, future specialty modules — each clinical action appears in one chronological per-patient view. No module keeps its own private copy of the record: every module reads from and writes to the same shared clinical record for each patient.
Open Standards Data Portability — Clinical data is stored in FHIR — the European-standard healthcare interoperability format — from the moment it is captured. Customers leaving the platform take their data in a vendor-neutral form; integrations with external systems use the same open shape; regulators read the same structure they already audit.

Platform Foundation

Modular Clinical Capabilities — Specialty features plug in and inherit everything the platform already provides. A module brings the knowledge of one specialty — lab orders, visit recordings, imaging studies — and the platform supplies the rest. An organisation adds a specialty by adding a module, and the platform settles it inside the same customer boundary, the same audit trail and the same consent rules. Audience: hospital leadership, procurement, IT leadership, module developers inside and outside Jengu.
Declarative Customer Configuration — Customer organisations, practitioners, modules, and enrollment keys are defined in a git repository the platform reads from. Onboarding a new customer organisation is a reviewed, merged, auditable change — not a click-path through an admin UI nobody trusts. The git history is the configuration audit trail.
Customer Lifecycle — A clinic is born from reviewed files, suspended without losing a record, and deleted with a grace period that ends in cryptographic erasure — every transition governed, durable, and audited twice.
Management API — Operating jengu is itself an API: customer organisations, roles and lifecycle are managed through the same kind of open, documented door jengu gives everyone else.
Data Versioning — Healthcare data outlives every version of the software that wrote it. As the platform evolves, the shape of stored data evolves with it — deliberately, audibly, and without stranding a single record on an old shape or taking a hospital offline to catch up.
Cross-Module Clinical Workflow — Clinical work flows across modules as durable processes — results find the clinician who asked, and nothing is lost between the seams.
Organizational Structure — One customer organisation can be many places at once. Inside it the platform holds a tree — departments, sites, units, satellites — each able to switch on its own clinical features. One feature can serve several of them; one of them can run several features. The menu, permissions, and clinical work follow this structure.
Cross-Module Governance — Every module answers to one governance: who may do what, where, under which rules — decided once, enforced everywhere.

Privacy & Anonymisation

Privacy Boundary — The boundary between data that names a patient and the clinical work that does not need to. Three services sit on it, each owning one way across: the Master Patient Index for identity, Patient Data Anonymisation for written text, and Speech Anonymisation for audio. Anything carrying personal data crosses through one of them, and everything beyond works on references and text that no longer name anyone. Audience: hospital leadership, DPO, ISO 27001 reviewers, legal counsel, procurement.
Speech Anonymisation — One shared service captures clinical audio, transcribes it automatically, anonymises the transcript before any of it leaves the boundary, and exposes only safe text + structured annotations to the rest of the platform. Speaker identity arrives as metadata from the recording context — the service does not infer it, and no LLM call sits between the audio and the safe-text output. Every action is audit-logged. Raw audio and raw transcripts live behind a sealed boundary.
Identity Pseudonymization — Personal identity is held in a separate, broker-only store and never appears on the clinical record. By default, doctors and the platform see medical context labelled with an opaque reference — never a name. Revealing a name is a deliberate, purpose-stated, logged act.
Secure Recording Service — Recordings exist only under consent, sealed at rest, and opened only by a deliberate, audited act.
Patient Data Anonymisation — Personal data is replaced with stable placeholders before any clinical text reaches AI processing, analytics, or downstream features. The original text stays behind a sealed boundary, accessed only with cause and audit.
Consented Data Use — Data is used only for what was consented to — one switch, one catalogue, and withdrawal that stops everything at once.

Security & Audit

Customer Data Isolation — Each customer organisation operates inside its own sealed boundary. No clinical data crosses between customers, and the platform operator cannot read inside any of them.
Co-Owned Encryption — Sensitive data is encrypted so that every co-owner holds a veto — destroy your part of the key, and the data is gone everywhere, backups included.
Regulatory Audit Trail — Every meaningful action — clinical record access, AI processing, lifecycle change, raw-data access — produces a queryable, tamper-evident record. "Who did what, when, to whose record" is always answerable.

Trust & Compliance

Compliance Zones — Customers are grouped by the country whose rules they work under, so the same platform honours each country's regulations, clinical vocabulary and technical expectations.
Insurance gateway — At the point of care and after it, three questions decide the financial side of healthcare: is this patient covered for this service, and to what limit — may we proceed — pay the provider for what was delivered . The insurance gateway answers all three through one standards-based exchange between healthcare providers and every payer — statutory (Tervisekassa) and private alike. Providers integrate once and reach every insurer; insurers author their products once and reach every provider; the patient's identity stays behind the privacy boundary and every crossing is consented and audited. Jengu relays claims and remittance data — never money. Audience: insurer leadership, hospital and clinic leadership, pharmacy and laboratory partners, compliance officers.
Verifiable Delivery Evidence — The platform can always show which of its commitments are proven, and by what evidence.