Features

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.

Why this matters

Healthcare organisations cannot share a database with their competitors, peers, or even sister facilities — patient privacy law (GDPR in the EU, country-specific health data acts, professional confidentiality duties) treats every patient record as the property of the treating organisation.

A SaaS platform that mixes customer data into shared tables would not pass any procurement review at a hospital, network, or ministry of health. Even when nothing technically goes wrong, the possibility of cross-customer leakage — through a faulty query, a misconfigured admin tool, or a breached support account — is a contractual non-starter.

Customer data isolation removes the possibility by construction. Each customer gets their own data boundary; the platform's own operations team sits outside it; and every request the platform serves is bound to exactly one customer organisation. When the legal department asks "could one of our customers see another customer's records?" the answer is "no, the architecture does not allow it" — not "no, we have policies against it".

What's in the box

• One customer, one boundary. Each customer organisation's clinical data lives in its own dedicated clinical data boundary. There is no shared patient table, no shared search index, no join path between customers.

• Scoped to one organisation identity. The token issued at login binds every subsequent request to exactly one customer organisation. The platform refuses to serve any clinical content if the customer organisation on the URL does not match the customer organisation on the token.

• Stateless, bound to one organisation compute. Processes that serve requests and run background work hold no persistent state of their own. Each request and each workflow execution operates inside one customer organisation's context and can reach only that customer organisation's data — no in-memory cache, shared session, or between customers background job.

• Operator structurally locked out. Platform operators (mom, the vendor's own ops staff) hold no key, no credential, and no identity that grants access to customer organisation clinical content. "Operator can read" is not a discipline question; the keys are not on their keyring.

• Background work partitioned. Long-running clinical operations (transcription pipelines, summarisation, reminders) run in per organisation lanes; one customer's queue never delays or interleaves with another's.

• Encrypted-field catalogue is regulator-readable. The list of fields the platform encrypts at rest lives in FHIR Implementation Guide profiles — readable by regulators in their own language, not buried in source code. A misconfigured customer organisation cannot weaken the platform's or the jurisdiction's declarations because the IG-load enforces monotonic-only at boot.

• Boundary travels with the customer. Export and disposal operate at project granularity. A customer leaving (or being acquired, or reorganised) takes their data with them as a discrete unit — there is nothing to disentangle from anyone else's records.

Standards we lean on

• GDPR Articles 5 and 32 — integrity and confidentiality; security of processing through structural separation.
• HIPAA 45 CFR 164.312 — technical safeguards: access control, encryption, audit, integrity.
• ISO/IEC 27018 — cloud processor obligations: customer organisation separation, no secondary use, structural operator lockout.
• HL7 FHIR — the per organisation project is itself a standard FHIR resource boundary.

What customers and operators experience

• A hospital signing on receives its own dedicated clinical data boundary on day one. Storage, search, and workflow execution are bound to one organisation — nothing persistent is pooled with another customer.
• A clinician logging in is bound to their organisation for the duration of their session. They cannot accidentally land on another hospital's URL — the platform refuses to serve content from another customer even when constructed deliberately.
• The platform's own operators can manage customer organisations (create, suspend, bill) but cannot read inside any customer organisation's clinical data. The common SaaS failure mode — a support engineer browses customer records to "help" — is simply not technically possible here.
• A regulator auditing can be shown a clean structural proof: every record carries its customer organisation label, every request carries its customer organisation claim, the two must match for the request to succeed.
• A customer leaving the platform takes their data with them as a discrete unit. There is nothing to disentangle from anyone else's records.

Limits and trade-offs

• Cost. A dedicated boundary per customer costs more than a shared database with row-level filtering. The platform accepts the overhead because regulatory clarity is worth far more than the saving.
• Cross-customer organisation analytics are deliberately not a feature. No "all our customers' data combined" report exists. Customers wanting industry benchmarks must contribute through the Consented Data Use programme, which has its own boundary.
• Internal partitioning happens inside a customer organisation. Departments, clinics, and units share the customer's boundary; finer-grained access control (who in cardiology can read psychiatry's notes) is layered on top, not delivered by it.
• Some shared compute is unavoidable. Audio capture, transcription, anonymisation, AI routing run as shared platform pipelines; each invocation processes exactly one customer organisation's data inside a stateless step. Raw content lives only for the duration of that call.
• Operator lockout has layers, not absolutes. The application tier and key-management tier each refuse operator reach. The platform's own threat model honestly documents the residual gaps — most importantly, the runtime process today still concentrates more privilege than it eventually will. See the runtime threat model (Shortcoming 3) and the privilege-separation roadmap that closes it.

Customer lifecycle

The customer boundary has a temporal dimension as well as a structural one: customers arrive, change, sometimes leave. Each transition has both an operational dimension (provisioning, suspension for billing, decommissioning) and a regulatory dimension — GDPR-style frameworks give customers and patients the right to have their data removed, but also expect data to be preserved long enough for legitimate audit and dispute resolution.

A customer organisation lifecycle handled by spreadsheets and runbooks is fragile. Steps get skipped. Suspension forgets to actually freeze access. Deletion forgets to remove a backup. Reactivation forgets to restore a configuration. Each gap is a future audit finding or a future incident.

Building customer organisation lifecycle into the same isolation boundary replaces "we have a checklist" with "the platform refuses to be in an inconsistent state". A customer's transitions become events the platform performs, audits, and can prove happened.

What's in the box (lifecycle)

• Lifecycle transitions are durable workflows. Creation, suspension, reactivation, and scheduled deletion are each a long-running process the platform manages — not a sequence of manual API calls. They survive platform restarts, are individually auditable, and complete or report failure unambiguously.
• Grace period as a managed timer. When deletion is initiated, a 30-day clock starts inside the platform's workflow engine. It survives restarts. It can be cancelled by a single reactivation signal. When it fires, the actual deletion runs as another workflow.
• Declarative provisioning. Customers and their configuration (departments, default users, module selection, zone) are described in the declarative customer organisation configuration source the platform reads. An operator describes a customer organisation; the platform enacts it. There is no hand-built customer organisation.
• Every transition is an audit event. Created, suspended, reactivated, disposal-started, disposal-cancelled, deleted — each emits a typed event into the audit trail, dual-logged to the platform's own trail and the affected customer organisation's trail.
• One customer organisation, one lifetime. A clinical record belongs to exactly one customer organisation for its lifetime. Migrating data between customer organisations are not self-service; merging or moving requires explicit operator and regulatory engagement.
• External notification, not enforcement. When a customer organisation is deleted, partners that hold derived data (insurance, registries, downstream EHRs) are notified to delete from their side. The platform produces the notification; it cannot enforce the partner's compliance.

Standards (lifecycle)

• GDPR Article 17 — right to erasure. Defined grace window, unambiguous deletion at the end.
• GDPR Article 7(3) — withdrawal as easy as giving consent. Reactivation cancels deletion in one step.
• ISO/IEC 27018 — return-or-destroy on contract end. Cloud processor obligations for end-of-relationship data handling.
• HL7 FHIR Bulk Data Export — the standard format for the customer's data export when leaving.

Lifecycle experience

• A new customer can be onboarded within hours of contract signature. The platform provisions everything they need — clinical data boundary, default users, baseline configuration — in one end-to-end workflow.
• A customer that has fallen behind on payment can be suspended cleanly: data sits frozen, users cannot log in, and the platform charges nothing for activity that no longer happens. Reactivation is a single action.
• A customer choosing to leave triggers a defined grace period — typically thirty days — during which they can pull their data, resolve disputes, or change their mind. After the grace period the data is structurally deleted.
• A customer that changed their mind during the grace period cancels deletion in one step. The countdown stops; the customer is back to normal operation.
• A platform operator sees the status of every customer organisation on one screen: active, suspended, or counting down to deletion. No customer organisation is ever in a half-deleted, half-active limbo.
• A regulator asking "when did this customer's data become inaccessible?" can be shown a precise audit trail of every lifecycle transition, with timestamps and the operator who authorised it.

Lifecycle limits and trade-offs

• Within the grace window, deletion is reversible. Outside it, it is not. The platform deliberately does not keep recoverable copies past the grace period; that would defeat the regulatory point of right-to-erasure.
• External systems must be informed separately. The platform produces the notification; partners must enact deletion on their own side.
• Migrating data between customer organisations are not self-service. A clinical record belongs to one customer organisation for its lifetime; merging or moving requires operator and regulatory engagement.
• Configuration changes are workflows too. Large changes require more than a casual edit, by design. The cost is worth the consistency.

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.

Why this matters

Healthcare is profoundly local. A clinician in Estonia, a clinician in Catalonia, and a clinician in Finland run their day under different regulatory regimes, expect different clinical terminology, send their clinical letters to different registries, and may be required by law to keep certain data within specific borders.

A jurisdiction is not always a country. Several EU member states delegate parts of healthcare regulation to subdivisions — Catalonia inside Spain, the German Länder, Belgian regional/community competences. Conversely, multinational regimes — most obviously the EU itself with GDPR and the EU MDR — set rules that apply across every member state, so a zone can also span several countries when their regimes are aligned for the work in question.

A platform that ignores this either becomes jurisdiction-specific (one fork per regulator) or compliance-soft (a single configuration that nobody fully trusts). Compliance zones let one product serve many jurisdictions simultaneously, with the differences expressed as configuration of a zone rather than a fork of the platform.

The business value is not "we support multiple countries" — it is "we can enter a new market quickly, and our existing customers are not exposed to changes intended for someone else's regulator".

What's in the box

• Zone declared at customer organisation creation. Every customer organisation is assigned to a leaf zone at creation; the zone is fixed thereafter and drives every subsequent decision the platform makes about that customer organisation's data.

• Single-parent tree. A zone has at most one parent. EU-wide rules live in zone-eu; national zones inherit from zone-eu; sub-national zones (Bavaria within Germany, Catalonia within Spain) inherit from their national zone. The customer picks the leaf; the platform resolves the chain. Single-parent inheritance matches actual constitutional structure and keeps resolution unambiguous.

• Per-function combiners. Each platform function has a defined way of combining along the chain: leaf overrides parent (LLM provider per task); leaf wins for redefined resources, parent applies otherwise (FHIR profiles); parent sets the floor, leaf may require longer (audit retention); leaf must be at least as restrictive as parent (data residency); union (anonymisation patterns). Each combiner is named and documented so a regulator can read what "delegate to parent" means.

• Compatibility check at definition time. When a sub-zone is registered, the platform rejects definitions that violate parent constraints — a Bavarian zone cannot widen federal data residency or shorten the federal audit-retention floor. Parent-incompatible children fail to register; they cannot reach runtime.

• Zone-specific services. Clinical terminology lookup, regulatory formatting, jurisdiction-specific AI rules run in components dedicated to that zone. Adding a jurisdiction adds a zone, not a code change.

• Routing follows the chain. When a piece of work has a regulatory flavour — anonymising a transcript, choosing an AI provider, applying a retention rule — the platform walks from the organisation's leaf zone up through its parents and applies the right combiner.

• Per-zone infrastructure. A jurisdiction with strict data-residency requirements can have its zone services hosted inside that jurisdiction's permitted region; another zone can run in a global cloud. The application is unaware.

Standards we lean on

• GDPR Articles 3, 44–49 — territorial scope; transfers of personal data to third countries.
• EU Medical Device Regulation (MDR) 2017/745 — multinational regime applied across member states.
• HL7 FHIR national profiles — Estonian, French, German, Spanish, Nordic and other jurisdiction-specific clinical refinements layered on the common standard.
• ISO/IEC 27018 — region/sovereignty awareness for cloud-processed personal data.

What customers and operators experience

• A hospital onboarding is assigned to its jurisdiction's zone at creation. From that point onwards, the regulatory rules, terminology, and AI providers their data sees are the ones their compliance department reviewed.
• A clinician sees medical terminology, drug catalogues, and reference ranges drawn from the authority their jurisdiction recognises — national or sub-national.
• A compliance officer can certify that their customer organisation's data is processed under the rules they reviewed, because the zone constrains what runs against it.
• A platform operator opening a new market configures a new zone — terminology source, retention policy, AI provider preferences — without changing the platform core. New zones declare a parent, inheriting EU-wide and national defaults. Existing customers are unaffected.
• A customer's compliance officer can see the zone chain for their customer organisation ("Zone: Bavaria → Germany → European Union") and read what each level contributes. The chain is transparent.
• A regulator sees zone boundaries as a clear organisational artefact: "all of jurisdiction X's customer organisations live in zone X, and zone X's services run within jurisdiction X's permitted infrastructure".

Limits and trade-offs

• One customer organisation, one leaf zone. A customer with sites in several jurisdictions is modelled as several customer organisations, not one customer organisation spanning leaves. Each clinical record stays under one regime unambiguously.
• Single-parent inheritance only. Multiple inheritance would make conflict resolution ambiguous and does not match constitutional reality. Cross-domain regimes are modelled as their own meta-zone, not as a second parent.
• Zones do not replace customer organisation isolation. A zone groups customer organisations by jurisdiction; it never opens a path between two customer organisations in the same zone.
• A new zone is not free. Each requires its own terminology source, regulatory rules, and configuration from someone with jurisdictional expertise.
• Cross-zone analytics are deliberately limited. Combining jurisdictions requires consent and explicit anonymisation.

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.

Why this matters

A hospital that runs on-premise hardware needs to manage that hardware without sending an engineer to every edge for every operation. Devices fail, get replaced, get retired; software updates have to flow safely; compromised or stolen edges have to be revocable; new sites have to come online without a custom integration project each time.

A platform that ships edges but offers no fleet story turns every edge into a manual operations problem for the customer's IT team. The first ten devices are tolerable; the hundredth is not. Without a single, declarative inventory and a managed update channel, fleets drift — some edges run last year's software, some have credentials nobody remembers issuing, and the question "is this device still part of our estate?" has no fast answer.

Edge fleet management makes the inventory a first-class citizen. Every edge has an identity the cloud knows about, a state the cloud displays, a software version the cloud chose, and a lifecycle (enrol → approve → run → update → retire) that operators follow rather than improvise.

What's in the box

• Headless enrolment. New edges read an embedded enrollment key at first boot and present themselves to cloud, along with their hardware identity. No keyboard, no monitor, no on-site console required.

• Approval before credentials. Cloud holds new edges in a pending state until an operator approves them. Approval is the moment credentials are issued; an unapproved edge has no access to anything.

• Per-edge identity, scoped to one customer organisation. Each approved edge has its own credentials, bound to exactly one customer organisation. An edge cannot serve a different customer organisation's data, even temporarily, even by configuration error.

• Explicit lifecycle states. Pending, approved, active, offline, retired — every edge is in one of a small set of states the console displays plainly. The lifecycle moves (approve, retire) are operator actions and every transition is audited; active ↔ offline is observed automatically — the live connection is alive or it isn't, with no missed-heartbeat threshold to tune.

• A rescue stick works on a real appliance. The installer medium boots its own complete system on a box whose disk still carries a bootable installation — a rescue or reinstall never silently resurrects the resident system — and it powers up on the supply the box already has. Inserting the stick and cycling power is the whole procedure.

• Edge software is bundled with the cloud release. The cloud carries its own matched edge .apk and serves only that version. Same git commit, same edge software — no version skew, no "which cloud runs against which edge" debugging. Edges keep a one-step rollback of their prior install so an upgrade that fails to come up healthy auto-reverts on the device — the safety net lives where the failure happens, not as a cloud-side archive.

• Retirement seals data. Retiring an edge revokes its credentials and instructs it to seal local data on next contact. Edges that never reconnect remain locked out of the platform indefinitely.

• Real-time connection over an outbound-only secure channel. Each edge holds a live secure connection back to cloud — outbound HTTPS only, never inbound, so the customer's firewall needs no inbound rules for Jengu. Cloud knows within seconds whether an edge is online, what its current software version is, and whether its work is flowing. A site losing connectivity shows up on the console at the moment it happens, not at the next heartbeat window. Long-disconnected edges are flagged automatically; the console never silently presumes a quiet edge is healthy. Trouble with an edge itself — a service crash, an OTA failure, a credential problem — reaches the dashboard within about a second of happening on the device.

• Re-enrolment is safe to repeat by hardware identity. An edge that re-posts its enrolment with the same hardware id (same Pi after a reboot, replacement edge picking up its predecessor's role, edge OS reinstall) re-binds to the same Device entry — no duplicate pending records pile up, the operator's prior approval still applies. The reverse — the same hardware id presenting a different customer organisation's enrolment key — is rejected, not silently re-tenanted, so a moved-or-stolen Pi cannot be re-bound to someone else's data without an operator's explicit action.

• Edges are devices in the platform device framework. An edge is Device(type=Edge) — the platform-provided device type registered with the device management framework. Other devices (lab analysers, bridged LIS systems) reference an edge as their location to indicate they run on that edge's hosting plane. Edge-fleet-management is the specific operational lifecycle (headless enrolment, approval gating, OTA upgrades, retirement) that the Edge device type carries beyond what other device types need; the framework owns cross-cutting concerns (configuration shell, audit, operator dispatch).

Practices we follow

• Zero-trust device enrolment. Hardware identity + approval gate before any credentials are issued.
• ISO/IEC 27001 Annex A.8 — asset management. Inventory, ownership, lifecycle, secure disposal.
• HIPAA 45 CFR 164.310(d) — device and media controls. Accountability for receipt, movement, and disposal of devices holding ePHI.

What customers and operators experience

• A new edge arriving at a site is plugged into power and network. It auto-enrols with cloud using a pre-issued enrollment key — no console access, no on-site engineer required.
• A vendor or customer operator approves the new edge in the cloud admin console after a quick identity check. Approval releases credentials; the edge starts working.
• A customer's IT team sees every edge across every site in one console: identity, last-seen, software version, current health. Filtering by site or status answers the "do we have a problem somewhere" question in one screen.
• An edge that misbehaves or is stolen can be retired remotely. Its credentials are revoked, its access to customer organisation data is severed, and any local data still on it is sealed — even if offline at the time of retirement.
• A software update rides the cloud's release. The cloud ships with a matching edge .apk baked in; edges pick it up through the same apk-tools mechanism a Pi uses. A bad release is reverted by the edge itself (one-step snapshot) without cloud-side intervention.
• A spare edge kept on the shelf can replace a failing one in minutes — the new device enrols and re-provisions automatically once approved.
• A new site coming online is a hardware shipment plus a configuration change — not an engineering project.

Limits and trade-offs

• Hardware is physical. Someone still has to plug edges in. The platform reduces every other operation to remote work, but installation, swap, and disposal happen on site. This is the operational floor.
• Lost or stolen edges leak whatever they last held. Edge data minimisation bounds this risk, but a device taken offline permanently keeps whatever was on it at that moment until storage encryption ages it out.
• Approval is a deliberate human step. Auto-approval is not offered; an attacker with a stolen enrollment key cannot silently add a rogue edge to the fleet. Operators must process legitimate approvals promptly to keep onboarding fluid.
• OTA failures need recovery paths. A failed update must auto-revert on the edge before the service times out. Worst-case failure modes (snapshot itself corrupted, kernel-level breakage) still require physical access for re-imaging.
• Stale values for long-disconnected edges. An edge that has not contacted cloud for days shows its last known values — the moment of disconnection is logged immediately (the live connection drops, the console reflects it), but the pre-disconnect values (last analyser status, last disk-free reading) don't update while the edge is offline. Operators should treat long-offline entries as last-known, not current.

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.

Why this matters

A hospital laboratory sits between two crowds. On one side, everyone who orders work: its own wards, outside clinics, ordering networks, the hospital's own system. On the other, everyone who performs it: every model of analyser on the bench, every partner laboratory it sends work to. Connected one pair at a time, that is every orderer wired to every performer — each connection costing thousands to build and committing someone to maintain it forever, and each one tying the laboratory system's release cycle to device firmware and partner message formats.

The Order Hub replaces every pair with a single connection each. Every orderer connects once, to one standard surface. Every performer connects once, as a driver on the device management framework. The hub carries orders one way and results the other. The laboratory system — whichever one the hospital runs — also connects once, and stops being the place where connection code piles up.

The hub takes no side on which laboratory system a hospital runs, and that is deliberate. Hospitals replace that system rarely and painfully; they replace analysers and partners constantly. Keeping the connections in something that outlives it means replacing the laboratory system never touches the bench, and changing the bench never waits on a laboratory-system release.

The hub in one picture

Reading the picture: the teal ring is the device management framework — every byte in or out of the system crosses it, and every crossing is a privacy boundary gate with a declared policy (red). Inside the ring, the Order Hub is one store with a way in and a way out. The service tree sits outside the ring, in configuration, and decides where each order goes. The laboratory system is a seat rather than a fixture: it connects to the store through the same gate as any other outside participant — and that seat may equally be filled by a Jengu module, or left empty.

How it works — one store, a way in and a way out

The store is the platform ordering surface

The hub's centre is not a store of its own — it is the platform's Orders surface seen at the organisation boundary: FHIR ServiceRequest for orders and Observation for results, held in the organisation's FHIR storage. Every participant — ordering channel, analyser, partner laboratory, laboratory system — reads and writes these same resources. There is no hub-internal message format to integrate against; the ordering surface is the contract. The Orders capability owns the order model and its lifecycle; the hub owns getting orders across the organisation boundary in both directions. Orders reference entries in the hospital service catalog by the canonical code (LOINC in the lab domain); results come back coded the same way.

Orders live at two levels on that surface. The business order is the clinical ask as the orderer placed it — one requisition, possibly a panel. The dispatch unit is one piece of device work derived from it: one per catalogue entry per performer, linked back to its business order. The hub carries dispatch units only; how a panel expands into per-analyte units is catalogue knowledge that lives with the laboratory profile, and how member results assemble back into one panel result belongs to the business lens above the hub. The hub itself never learns what a panel is — which is exactly what keeps it domain-neutral. Existing single-analyte orders need no expansion step and flow exactly as before.

Every connection is a managed connector

An ordering channel and a bench analyser are the same kind of thing to the hub: a managed connector on the device management framework. That gives every connection — upward or downward — the same operational story: added by configuration rather than by project, operated and monitored remotely, audited uniformly. One team, one skill set, one fleet view covers the Medipost channel and the immunoassay bench alike.

Each connector speaks its counterpart's dialect outward and canonical codes inward, so the ordering surface stays clean of per-system vocabulary. And an ordering system always recognises its own order: the identifier it sent arrives back with the result, unchanged.

Routing by the service tree

The service tree is the organisation's offer: every orderable service, keyed by canonical code, with mappings and routing per entry. An entry is either fulfilled in-house (routed to a bench analyser or a department) or is a proxy service — visible in the organisation's catalogue, delegated to a partner organisation for fulfilment. The orderer cannot tell the difference: same order shape, same result path. The tree lives on the configuration plane, outside the hub, because it feeds more than ordering: billing, insurance, and reporting read the same tree.

Enough of a lifecycle to work alone, and it steps aside

With no laboratory system connected, the hub runs the order itself: accept it, route it by the tree, track its status, match the returning result, close it. That is deliberately the minimum needed to move work safely — it is not clinical judgement. When a laboratory system takes the seat, that system owns validation, worklists and reporting, and the hub's own handling steps aside. Connecting one replaces the default; it was never required for orders to move.

Orders coming in

Facing the people who order: a connection to the hospital's own system, an ordering network such as Medipost, an ordering portal. Each one:

• receives orders in whatever format and vocabulary it speaks, translates them to the shared codes, and writes an order to the store;
• crosses the privacy boundary on the way in, where identity is stripped or resolved — inside the hub a laboratory order carries a sample number and an order number, nothing more;
• returns results to the orderer over the same channel, translated back, carrying the orderer's original order identifier.

Work going out

Facing the people and machines that do the work:

• bench analysers — drivers speaking ASTM, HL7v2, serial, FTP, or REST, running at the edge next to the hardware and working through network outages;
• partner labs — delegation channels (for example via Medipost) that carry a proxy-service order to another organisation and bring its result back;
• outside systems — the hospital's existing laboratory system can itself be a destination, so an order arriving from a network can be handed straight on to it, unchanged.

Each order's destination comes from its entry in the service tree. Where a partner genuinely needs to know who the patient is, identity is attached as the order leaves — inside the certified connection, on the way past, audited, and never held in the hub. Analysers get no such allowance: traffic to the bench can never carry identity at all.

Each direction stands alone

Neither direction is a product edition; each is simply the set of connections configured in that direction for the customer. Configure only the incoming side, only the outgoing side, or both — the same deployed component serves very different products:

| Orders in | Work out | What the organisation gets | |---|---|---| | off | on | Device connections — the bench and partner connections beneath an existing laboratory system, which reads and writes the store | | on | off | Order gateway — external orderers reach the organisation's existing systems through one FHIR surface | | on | on | Integration hub — orders from any channel routed to any performer, with no Jengu laboratory system involved | | on | on, plus the seat filled | A complete laboratory — the hub plus something that runs the work: the customer's own laboratory system, or a Jengu module |

Because both directions use the same framework, store and tree, turning the second one on later is configuration rather than a project — the first one already paid for the machinery.

One bench, many environments

A hospital has one set of analysers and one set of partner connections — but never only one version of its laboratory system. There is the live one, its test copy, and sometimes a successor being built. When the connections live inside that system, the choice is bad either way: the non-live copies get no bench at all, or somebody maintains a second set of hardware. Because the connections live outside it here, one hub — same service tree, same connections, same routes — serves them all at once.

• Which world you are in travels with your credentials. Every account is issued for exactly one of them: the live hospital system holds live credentials, the test system holds test credentials, developers get credentials that only ever simulate. A test system cannot place a live order — not because a rule forbids it, but because it has no way to. The environment travels with the order along the whole route, including partner delegation, and a result only ever returns to the environment its order came from.
• A dry run costs no reagent. For development and testing, connections simulate only the last metre: receiving, translating, routing and every change of state happen for real, and only the conversation with the physical device is imitated. A vendor can test against the hospital's actual bench setup without using up a sample.
• Real execution where wanted. What a connector does with each environment is configured per connector — emulate, execute on the real hardware (a verification bench, off-hours acceptance runs), forward to a partner's own test endpoint, or refuse. Unconfigured combinations are refused by default.
• Sample numbers are registered, not hoped for. Laboratories run on pre-printed barcode rolls, each controlled by one system. The hub keeps the register: every printed range belongs to exactly one of them, two ranges that would collide are refused when they are registered rather than discovered later at the bench, and a sample number from outside any registered range is not accepted at all. Checking ranges is a hub setting like the others, with a management page covering the range lifecycle (active, exhausted, retired); organisations that want more can later take hub-managed ranges with printed stickers as a service.

For a vendor replacing a hospital's laboratory system, this is the strongest version of the promise that nothing bought now is thrown away: the new system is built and rehearsed against the very bench and partner network the old one runs on, and the switch-over becomes a change of credentials rather than a bench project. The same machinery extends to running a candidate system alongside the live one on the same orders, for comparison.

Privacy — one ring, one policy per crossing

There is exactly one way in or out of the system: a privacy boundary gate on the device framework ring. Gates differ only in declared policy — audit only, strip, resolve, enrich — and every crossing is wire-traced and audited regardless of policy. The interior of the ring, including the store and any Jengu-side brain, is pseudonymous: specimen ID and order ID, never patient identity. Gates whose policy touches identity require a certified membrane connector and redact identity from their wire traces; audit-only gates — the analyser drivers — carry no such burden, which keeps writing a new device driver lightweight.

A deployment without identity-bearing policies holds no patient data at all, which is what keeps the hub-only offerings outside GDPR patient-data scope and makes their data-protection review short.

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.

Why this matters

The platform already moves orders and results across the organisation boundary — the Order Hub is deliberately faceless plumbing. What a hospital buys, however, is not plumbing; it is the ability to run its integrations: see the fleet, know which connector is live in which environment, trace what actually went over the wire when a result looks wrong, and hand an external integration partner a safe place to test without endangering production.

Without a module to own that story, device operations scatter across a generic Administration menu, visible to every org admin of every department whether or not that department operates a single device. Device Hub gives the story an owner: a module a customer organisation enables and binds to the departments that actually run connectors, exactly the way clinical modules bind to the departments that practise.

Two lenses, one store

Device Hub and a LIS module (Lab) are two lenses over the same FHIR resources — never two stores.

• Device Hub is the transport lens: the connector fleet, the dispatch queue, the manual queue, held messages, wire traces, environments and grades, specimen ranges. It answers "is the boundary healthy, and what exactly crossed it?"
• Lab is the business lens: accession, worklists, panel completeness, reporting. It answers "where is this sample in the laboratory process?"

Both read and write the organisation's ordering surface (order, measurement) owned by the Orders capability. Removing either module removes a view, never data.

What the module owns

The device-operations surface

Device Hub subsumes the device administration pages that previously floated in generic Administration:

• Devices — the connector fleet: every managed connector, its driver, its binding, its state.
• Edges — the edge appliances the connectors run on (edge fleet management).
• Wire Traces — the captured byte-level I/O of every connector crossing, for integration debugging.
• Specimen Ranges — the specimen-number ranges the intake seam verifies against (flag-gated with range verification).

Devices have physical locations; a location's fleet is managed by the department bound there. Binding the module to a department is what makes these pages appear for that department's users — unbound departments and customer organisations without the module see nothing. Cross-department and cross-location reporting is deliberately out of the module: that is a separate reporting story.

The Devices & Connectors view reads the way the fleet is organised: organisation node → placement → device — the customer organisation root first, Cloud before edges. Configuration affordances render only at the definition level; an inherited connector shows its enablement instead — a guarded toggle where this level's own flag decides (confirming the impact: the department and all its sub-departments), and a locked state naming the ancestor whose rule disabled it where deeper re-enablement is unrepresentable. Enablement changes are configuration changes: they commit to the organisation's configuration and take effect on the next sync pass.

Department binding, module mechanics

Device Hub attaches through the standard module integration contract: one a module description, one navigation contribution, department binding and enable/disable exactly as for any clinical module. There is nothing bespoke about how it appears and disappears — the module mechanics are the platform's, only the content is device operations.

Ownership, placement, enablement

Devices & connectors follow the physical and organisational structure. Every connector has a defining organisation — the customer organisation root or a department (the device's owner); the root always exists and may own connectors itself. Every connector has a placement: Cloud (implicitly available at every organisation node) or a specific Edge — an edge is nothing more than an extender of the cloud into a physical space. Each driver type declares where it may run (cloud, edge, or both), and a placement contradicting the declaration is rejected when the connector is defined — not discovered at runtime.

A connector defined at one level is usable in the whole subtree below and configurable only where defined. Sub-organisations hold an enablement flag, never a copy — and enablement is deny-only along the organisation path: a disable at any level excludes the entire subtree beneath it, and re-enabling deeper is unrepresentable. The routing that dispatches orders consults the same effective set, so a disabled connector simply stops being a candidate. Where a connector is inherited-disabled, the interface says so and by whose rule.

The dispatch dashboard

The module's operational heart is a live view over the ordering surface — never a parallel store. The Dispatch page shows the department's dispatch units by state: routable, dispatched and awaiting result, and the manual queue — orders whose catalogue entry declares a human decision or for which no serveable candidate exists, listed with enough context to hand to the right person (the workflow itself arrives with the task engine). Held partner messages surface here too, where a transport exposes held semantics. Every row links back to its business order where one exists — the transport lens keeps no business state.

The Connectors page tells the grading story per connector: the environment grade badge, what the connector does with each environment's orders (execute / emulate / forward / block), its personal data gate policy, the wing it constitutes, whether its operator is live, and whether a dry-run twin is registered.

Wings are emergent, not configured

A hub wing exists for a department because capable Devices exist there: dispatch because the fleet carries order-submitting or result-producing connectors, intake because an intake channel is live. There is nothing to switch on — defining the connector is what opens the wing, removing the last one is what closes it. The module shows each wing's state with the devices that constitute it. The organisation-level wing flags remain only as an emergency brake: incident response that stops a wing without touching device definitions.

Connector grading

An environment grade is a connector's identity, not a mode switch: one Device per grade, and the binding — endpoint, credentials, counterpart instance — is the environment. A physical analyser usually serves test through an emulated twin row rather than a second physical binding. Definition-time validation rejects grade/endpoint contradictions, so a test connector cannot quietly point at a production counterpart.

The integration cockpit

Developer access is a product feature, not a back door: a devhub:developer role composed of three forced guards. The environment wall is structural — the developer view is test and development only, and no parameter exists that widens it. The device scope comes from a per organisation assignment on the configuration plane naming the developer's connectors. Within that, the own-call filter shows traces whose principal is the developer or whose order the developer placed — wire-trace attribution is what makes a scheduler-thread dispatch still read as "my call". An external integration partner debugs their own connector self-service — against the same surfaces the hospital's own team uses, minus everything they must not touch, with identity-bearing gates redacting inline regardless.

Boundaries

• The hub lifecycle, wings, environments, and personal data gates belong to the Order Hub; Device Hub operates them.
• Drivers, codecs, and the crossing gates belong to the device management framework; Device Hub manages the fleet built on them.
• Accession, worklists, and panel completeness belong to the LIS lens (Lab), above the hub.
• Cross-department/cross-location device reporting is out of scope for the module.

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.

The promise

The most sensitive records are not merely encrypted; they are encrypted so that reading them requires the participation of everyone who co-owns them. Each co-owner — the patient, the clinic, jengu, a partner organisation where one is involved — holds a part of the key. Compose all parts and the record opens; destroy any one part and the record is permanently unreadable, everywhere it exists, including copies and offline backups that nobody enumerated.

That makes erasure a cryptographic fact rather than an operational campaign. A patient's right to be forgotten is honoured by destroying the patient's key part — and the record distinguishes, auditably, a part destroyed on a signed erasure request from a part lost in an incident. For data classes that opt into independent access — consent records, contributions a patient makes directly — each co-owner instead holds its own wrapped copy of the key, so one party's revocation removes only that party's access.

Why this matters to a customer

Every deletion promise in ordinary software has an asterisk: the backups. Co-owned encryption removes the asterisk — compliance does not depend on finding every replica, because no replica is readable without the destroyed part. And the veto is mutual: the clinic cannot be locked out of its own records by jengu, and jengu cannot open a clinic's records without the clinic. Who can end access to what is a design decision made per class of data, written down, and enforced by mathematics rather than policy.

What it does not promise

Co-owned encryption governs the sealed record, not knowledge already legitimately extracted from it — a signed clinical report sent to another hospital is that document's own story, governed by consent and audit. And the veto is deliberately absolute: a destroyed key part is not recoverable by jengu, by the clinic, or by court order served on either. That is the feature.

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.

Why "Privacy Boundary" is a group of its own

A platform that treats patient data as ambient — visible to every module, embedded in every clinical resource, leaked through every screen — is a platform with a privacy exposure proportional to the number of modules it carries. Each new clinical module inherits the leak surface; each integration with an external system multiplies it.

The opposite design — a small group of components that own the personal data surface, with every other component working on pseudonymous references and safe text — bounds the privacy exposure to that group. Adding a new clinical module does not expand the personal data surface. An auditor reviewing the personal data posture of the system reviews the privacy boundary group, not every module.

That group has three entry points:

• Master Patient Index — the identity entry point. Exactly one path from a pseudonymous clinical reference back to a real human's identity, and that path is the MPI's lookupForDisplay operation. Every personal data-bearing inbound or outbound I/O of identity — national registry queries, insurance card reads, discharge correspondence, family contact, prescription dispatch — is brokered through certified operator bundles that live inside the MPI's domain.
• Patient Data Anonymisation — the free-text entry point. Raw clinical text (in transcripts, imported notes, uploaded documents) is anonymised in-zone before any downstream feature consumes it. Names become stable placeholders; the original text stays behind a sealed boundary.
• Speech Anonymisation — the audio entry point. Captured clinical voice is transcribed and anonymised inside the privacy boundary; downstream features receive only safe transcript segments. Raw audio and raw transcripts stay behind the sealed boundary. No LLM call sits between audio and safe text.

The strategic value compounds with each module:

• The lab module holds no patient identifiers at all. Not on screen, not in storage, not in any FHIR resource it touches. Specimen ID + order ID are the only handles; mapping back to a real person happens outside the lab system entirely.
• The visit assistant runs a two-stage anonymisation: the doctor owns the patient binding at the bedside, the cloud workflow never sees patient data.
• A future imaging module inherits the same posture: imaging studies referenced by pseudonymous Patient + study ID; identity attached only at delivery (the radiology report sent to the GP).
• A future pharmacy module inherits the same posture: scripts bound to pseudonymous references; identity resolved at dispensing.

This is the same architectural pattern the Foundation grouping applies to authentication and audit: solve it once at the foundation, every module inherits the solution.

What's in the group

| Component | Capability | Owns the entry point for | |---|---|---| | Master Patient Index | Master Patient Index | Identity — the only place a reference becomes a name. | | Patient Data Anonymisation | Patient Data Anonymisation | Free text — raw clinical text → safe text + placeholder map. Reusable engine consumed by Speech Anonymisation and any text-bearing inbound surface. | | Speech Anonymisation | Speech Anonymisation | Audio — captured clinical voice → safe transcript segments + annotations. Consumes Patient Data Anonymisation internally. |

The Privacy Boundary is a group rather than a single component because each of the three entry points has distinct mechanics (identity broker, text engine, audio pipeline) while sharing the membrane semantics — bridges identifiable personal data and pseudonymous clinical work. The group stays separate from Foundation so the membrane band is reviewable as a unit.

The four promises the MPI carries

These are the customer promises that the (future) MPI capability doc will lay out in detail. For now they're the headline list:

1. Single source of patient identity. There is exactly one place a patient's name, DOB, national ID, contact details live. Every other component works on pseudonymous references.
2. Identification is on demand, never default. Clinician UIs show pseudonymous bed / visit / visit records references and clinical context. Patient names appear only when a doctor explicitly taps Reveal identity with a stated purpose, and every reveal is audited. See the identification-on-demand invariant.
3. Every personal data-bearing I/O is brokered through certified operators. National registry queries, insurer interactions, patient correspondence — all go through MPI operator bundles that the platform certifies. No clinical module talks to a personal data channel directly.
4. GDPR Art 15 / 17 are served structurally. Patient access to their data and patient erasure requests run through the MPI; one component to authorise, audit, and execute. Erasure propagates to derived per-mention provenance back-references so it remains servable even against multi-subject care-coordination recordings.

How the three services relate

The three group members are full members of the privacy boundary band, not sub-capabilities of one another. They do compose:

• Speech Anonymisation consumes Patient Data Anonymisation internally for every transcript it produces. The two-pass pipeline, stable placeholders, per-zone patterns, and the sealed raw boundary are defined once in the Patient Data Anonymisation contract and reused.
• Patient Data Anonymisation is reusable beyond speech. Any text-bearing inbound surface (uploaded documents, prior clinical notes imported from external systems, narrative fields in inbound API payloads) consumes the same engine before downstream features see the content.
• MPI sits beside both. It owns identity (the structural pseudonymisation layer per identity pseudonymization); the other two own narrative content. The three together cover the full patient data surface — identity fields, free text, and audio.

Cross-cutting capabilities absorbed

The former Consented data use standalone capability is delivered by the Consent ledger component in Shared Clinical Surface, with enforcement runs at the MPI membrane: the ledger holds consent records; the MPI checks them at every personal data-bearing crossing. There is no separate consented-data-use capability doc.

What this group does not include

• Identity & roles (clinicians, not patients) is in Foundation. Authenticating a doctor at login is a Foundation concern; resolving a patient's pseudonym to a name is a Privacy Boundary concern.
• Consent ledger is in Shared Clinical Surface. The ledger holds records; the MPI enforces checks against the ledger. They are paired across the boundary, not co-located.

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.

Why this matters

Clinical decisions are reached by accumulating evidence and re-ranking candidates. A doctor taking a history collects symptoms, forms candidate conditions, asks discriminating questions, narrows the list. A microbiology lab identifies a pathogen, tests susceptibility, ranks therapy regimens. An imaging radiologist sees a finding, considers candidates, asks for confirmatory views or correlative tests. The shape of the reasoning is the same everywhere — what is known leads to a ranked list of what it could be, and a ranked list of what would settle it — even though the evidence, the possibilities and the next moves differ completely between specialties.

A platform that delivers AI-assisted clinical decision support across multiple modules has two bad options for handling this reasoning: re-implement it per module (every team building its own ranking logic, inconsistent stance, different evidence chain shapes, hard to audit collectively) or hand the reasoning to an LLM as a free-form generation task per module (hallucinated candidates, ungrounded citations, variable quality across languages, no audit chain). Neither scales as the module catalogue grows.

The platform's answer is one reasoning engine every AI feature uses. It takes what is known in coded form, asks the Medical Knowledge Base which known relationships bear on it, and returns two ranked lists together with the reasoning behind each entry. Where a model is involved it is asked for structured answers to specific questions, never for free text. The shape of the reasoning is the same in every specialty; what fills it is not.

What's in the box

• Coded in, coded out. A feature passes what is known as clinical codes — findings, phenotypes, laboratory values, identified pathogens, whichever apply — each with its value and where it came from. Back come the two ranked lists, each entry carrying how strongly the knowledge base links it and the chain of evidence behind it. The engine is never given free text; whatever calls it maps to codes first.

• Two lists, never one. The first is what this could be if we stopped looking now — possible conditions, possible pathogens, possible diagnoses. The second is what would narrow it down fastest: a question to ask, an investigation to order, a test to run, a value to watch. Both come back every time, because that is how the reasoning actually works — a possibility with nothing that would confirm or rule it out is a dead end.

• It proposes; the clinician decides. Outputs read as "X is on the candidate list — supported by A and B; not yet probed for C" and "consider asking about C — would discriminate between X and Y". The engine does not synthesise diagnostic conclusions, does not assert probabilities in clinical-claim language, and does not recommend treatment. Consumers that need a more decisive surface (a one-click action for a high-confidence possibility) build that on top of these proposals, in their own words and with their own audit.

• Nothing is invented. Every relationship behind every proposal comes from the Medical Knowledge Base: which findings point to which disorders, which traits are typical of which diseases, and what is common in this particular region. The engine never asserts a relationship the knowledge base does not hold. Anything beyond that is the calling feature's own responsibility, outside this engine.

• The model answers questions; it never writes the proposal. Where a model is used at all — to turn a short piece of text into codes, to compare two possibilities, to phrase a question worth asking — it is asked a specific question and must answer in a fixed form. It is never asked to write prose. The answers come back as codes and values, and the engine assembles the proposal from them. This is why quality does not sag in languages a model handles less well, and why the trail of reasoning looks the same in every language.

• Each region chooses its own AI. Model calls go through the right-sized AI pipeline, which picks the provider each region has chosen for this kind of work. A region running a model on its own hardware and one paying for a hosted service use the engine identically; only what answers underneath differs.

• Every proposal shows its working. Each entry in either list carries what supported it, which known relationships connected that evidence to it, whether local prevalence adjusted its position, and which version of the engine produced it. A clinician can be shown that chain; an auditor can replay it and get the same answer.

• Evidence accumulates; the ranking is redone. As new evidence arrives, the engine is asked again with everything known so far and returns a fresh ranking. It remembers nothing between calls — what it is given is the whole input — which is what makes the same evidence always produce the same answer.

• It does not know which specialty it is serving. Symptoms pointing at conditions, an organism leading through susceptibility to a therapy, an imaging finding suggesting diagnoses — the engine cannot tell these apart, and does not need to. The specialty knowledge sits in the knowledge base, in which relationships exist, and in the codes each feature chooses to send. The engine supplies only the shape of the reasoning.

Standards we lean on

• HL7 FHIR — evidence and proposals use the standard's own shapes: CodeableConcept, Observation, Condition and Task where they fit naturally, so a feature can attach a proposal to a patient's record without translating it first.
• GDPR Article 22 — automated decision-making. The engine produces decision support; the clinician (or microbiology director, or radiologist) is the human in the loop. The platform records the user's curation (accepted / dismissed / acted-on) as evidence.
• EU AI Act (Annex III, healthcare risk class) — clinical decision-support classification informs how proposals are framed, how the reasoning is audited, and how the evidence chain is preserved.
• MDR / IVDR class IIa — software-as-medical-device considerations for decision-support outputs; the engine is the shared boundary at which those obligations apply.

What customers and operators experience

• A clinician seeing a hint during a visit sees a possible condition with the evidence behind it, and a question worth asking with the reason it would help. The same engine, in the laboratory, proposes treatments for an identified pathogen with the susceptibility results behind them, and confirmatory tests with the reason each would settle something. Same reasoning, different specialty.

• A compliance officer reviewing how the platform uses AI for decision support reviews one engine — that it proposes rather than decides, that every proposal shows its working, and that nothing is asserted which the knowledge base does not hold — instead of reviewing separate ranking logic in every feature.

• A clinical lead in Estonia adjusts how common a condition is locally, in the knowledge base's regional layer; the change applies to every clinical AI feature on the platform that uses the reasoning engine — smart hints, microbiology decision support, future imaging — without per-feature configuration.

• A module developer adding a new AI feature with diagnostic-adjacent reasoning consumes the engine. They define their evidence mapping (which codes their domain passes in), specify their candidate space (which result type the engine should rank), and let the engine handle the ranking + next-step proposing. They do not re-implement ranking; they do not negotiate LLM provider routing; they do not maintain prompt templates.

• An auditor asking "where did this AI suggestion come from?" receives an evidence chain that names the input evidence, the known relationships used (with the published catalogues they come from), any regional adjustment, the engine version, and which AI provider answered along the way.

Limits and trade-offs

• The engine is bounded by the foundation. A candidate the Medical Knowledge Base does not know about is a candidate the engine will not propose. Coverage is broad but not exhaustive; consumers needing reasoning beyond the foundation must build it themselves, outside the engine, with their own audit posture.

• The proposer stance is deliberate. Consumers wanting a single-likely-answer decisive surface will not find one here. The platform's stance is propose, don't decide; decisive surfaces are the consumer's framing on top of the engine's proposals.

• Recall over precision is the default. The engine errs on the side of more candidates and more next-steps, on the assumption that single-click dismissal is the cheap step. Consumers needing high-precision surfaces (one-shot recommendation) filter the engine's output; they don't get high-precision proposals for free.

• Speed depends on which AI answers. The engine's own work is a lookup in memory and is fast; asking a model is not, and whatever that costs is inherited. A region using a remote hosted provider sees different latency than a zone routing to a local model.

• Evidence state is the consumer's responsibility. Mapping the consumer's domain into the engine's coded evidence shape — which codes, which provenance, which values — is the consumer's mapping work. The engine cannot reason about evidence it didn't receive.

• The engine is not a chatbot. It does not maintain conversational state, does not handle natural-language follow-ups, does not narrate. Consumers wanting any of those layer them on top, with their own framing.

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.

Why this matters

A platform that delivers AI-driven clinical decision support needs more than a list of codes. It needs to know that "fever

• productive cough" is a presentation that points toward community-acquired pneumonia, that "tick bite + erythema migrans" raises Lyme borreliosis to the top of the differential, that a SNOMED CT finding is cross-referenced to an ICD-10 disorder and to an HPO phenotype that annotates a Mendelian disease. Without a shared knowledge base of these relations, every AI feature on the platform either re-implements its own (inconsistent, hard to audit, easy to drift) or asks an LLM to reason from first principles every time (slow, expensive, hallucinates citations, varies by language).

The platform solves it once, and every feature inherits the answer. The Medical Knowledge Base holds what clinical facts have to do with each other — drawn from internationally recognised catalogues, kept in a form that can be asked questions quickly, versioned so any answer can be traced back, and with each region's own picture of what is common layered on top. Every AI feature that ranks possible conditions, proposes a useful investigation, or offers a hint reads from this one place.

This is a different job from Terminology & Code Bindings, which answers what a code means, which codes this organisation uses, and what else a test is called locally. This one answers what a code has to do with other codes. Both draw on the same published catalogues — SNOMED CT, ICD-10, LOINC, HPO, MONDO — and answer different questions.

It also decides nothing on its own. Asked a question, it answers it; ranking possibilities under the evidence in front of a particular patient happens above it, in clinical reasoning and the features that use it.

What's in the box

• Everything comes from published catalogues. Which findings are associated with which disorders, from SNOMED CT. Which traits are typical of which diseases, and how often, from the human phenotype catalogues. Which names in one coding system mean the same disease in another, from MONDO. The sources are public, each release is numbered, and every single relationship can be traced back to the release it came from.

• Answers come from memory. Ask about a code and back come the codes related to it, how strong each link is, what kind of link it is, and which catalogue says so. Nothing goes to disk or over a network, so the answer is immediate. The whole body of knowledge carries one version number naming the catalogue releases inside it, and every answer carries that version — which is what lets the same question be asked again later and give the same answer.

• Each region adjusts what is common locally. International knowledge does not know that Lyme borreliosis is far more likely in Estonia than the global average. So each region keeps a small, reviewed adjustment on top of the international base. It is written as configuration, reviewed like any other change before it takes effect, and it is not something the system learns on its own — a person decides it, deliberately, and the decision is recorded.

• It looks things up; it does not think. Asking it a question involves no AI model at all. Anything that weighs the answer against a particular patient, proposes what to ask next, or puts it into words happens above it — so the slowness of asking a model never becomes the slowness of looking something up.

• Every relationship names its source. Which catalogue, which release, what kind of relationship. So the chain behind a hint — these words in the consultation, therefore this symptom code, therefore this known relationship, therefore this possible condition — ends somewhere real. An auditor following it back arrives at a published catalogue release, not at us.

• It updates the same way everything else does. When a catalogue publishes a new release, it is picked up, reviewed as configuration, and takes effect on the next sync — through the platform's one configuration pipeline rather than a refresh mechanism of its own. A hint given last year can still be traced against the version that produced it; new questions get the current one.

• Shared by region, not held per customer. Every Estonian organisation reads the same international knowledge with the same Estonian adjustment; the adjustment is reviewed once for the region rather than separately for each customer. This keeps it small, keeps the audit simple, and the AI-feature evidence chains comparable across customer organisations.

Standards we lean on

• SNOMED CT International + zone extensions (TEHIK Estonian extension for zone-ee) — clinical findings, disorders, and the associated-with (and related semantic) relationships.
• Human Phenotype Ontology (HPO) + HPOA annotations — phenotype-to-disease links with frequency annotations where available.
• MONDO disease ontology — unified disease identifiers cross-referencing SNOMED disorder, ICD-10, OMIM, Orphanet, so the same condition is recognisable regardless of which catalogue the regional adjustment uses.
• ICD-10 / ICD-11 — diagnosis catalogue cross-references.
• LOINC — for cross-references where lab observations participate in differential reasoning.
• HL7 FHIR — query result shapes use FHIR coded value
  • code where the consumer surface naturally maps to FHIR.

What customers and operators experience

• A clinician seeing a smart hint that says "community-acquired pneumonia is on the candidate list — supported by fever, productive cough" can open the evidence chain and see that the link from "fever" (SNOMED finding 386661006) to "community-acquired pneumonia" (SNOMED disorder 385093006) traces to SNOMED CT International 2026-03 associated-with. The hint is auditable back to a published catalogue release.

• A compliance officer can review the knowledge base's source provenance independently of any AI feature: every edge in the index has a citation, every release loaded is logged. The question "where does this AI hint's medical knowledge come from?" has a one-line answer that doesn't depend on the module that produced the hint.

• A clinical lead in zone-ee can review and adjust the Estonian adjustment: which conditions warrant a higher local prior, which warrant a lower one. Changes flow through the customer config repository, reviewed by the clinical lead, and apply to every AI feature on the platform uniformly.

• A module developer building a new AI feature that needs to rank possible conditions binds to the knowledge base's query API. They do not assemble their own copy of SNOMED + HPOA; they do not negotiate licensing with the catalogue providers (the platform does it once); they do not maintain refresh pipelines. Adding a new AI feature is module work, not work on the knowledge base itself.

• An auditor reviewing the platform's AI evidence chains reviews one knowledge base, not one per feature. The same KB powers smart hints in the Visit Assistant, the microbiology decision support in the Lab module, and any future imaging or pharmacy AI features.

Limits and trade-offs

• It holds relationships, not full clinical reasoning. A consumer that wants ranked candidates under current evidence, discriminating-question proposals, or narrative explanations needs the consumer-side reasoning layer on top. The knowledge base gives the relationships; the reasoning service combines them with the current evidence state.

• International coverage is broad but not exhaustive. Rare presentations, atypical phrasings, and conditions that are not yet well-represented in the upstream catalogues are not reachable through it. The regional adjustment can add high-priority local conditions, but the overlay is a re-weighting layer, not a new-edge-creation layer.

• Zone overlays are small and reviewed. They are not learned per-zone priors. A platform-wide signal that a zone prior needs adjustment becomes a config-repo change with a clinical review, not a model retraining job. The trade-off is that overlays grow slowly and by deliberate choice.

• Substrate version is part of the evidence chain. When the foundation is refreshed, an AI feature's hints may re-rank. Reproducing an old hint requires the old foundation version — which is preserved in the audit trail as part of the hint's evidence chain, not in the running foundation. The running foundation is the current one only.

• Cross-zone customer organisation deployments inherit per organisation zone. A hospital group spanning zones runs each customer organisation against its zone's overlay. The foundation base is shared; the overlay differs. An AI feature surfaces hints consistent with the organisation's zone.

• The foundation is not a translation layer. It works on codes, not on display text. The Terminology & Code Bindings capability handles display in the clinician's language and per organisation value-set membership.

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.

Why this matters

Many clinical contexts produce a spoken record: a doctor seeing a patient, a nurse on inpatient rounds, a triage handover, a multidisciplinary case meeting, a remote consultation between two specialists, an operating-room debrief. Every one has the same regulatory weight: the recording contains personal medical data, the patient may not be aware of it beyond consent, and any leak has serious consequences.

Building a recorder per use case means re-implementing encryption, retention, audit, and anonymisation each time — and ending up with subtle differences that compliance officers (rightly) refuse to certify. One shared, audited service solves this once. Any clinical workflow that needs to capture clinical voice plugs into the same service and inherits the same compliance posture. New use cases (an inpatient-rounds tablet, a remote-consult app, a meeting recorder) become clinical-feature work, not regulatory engineering.

The strategic value: clinical voice records — across every context the platform supports — are governed by one set of rules, captured in one code path, audited in one place.

This service is the speech-side of the Privacy Boundary: the membrane band of the platform that bridges identifiable personal data and pseudonymous clinical work. The Master Patient Index handles the identity entry point; this service handles the speech entry point; Patient Data Anonymisation is the narrative-anonymisation engine both services rely on. Together they bound the platform's personal data surface to a small, certifiable set of components. Every other module — visit assistant, lab, future imaging, future pharmacy — works on pseudonymous references and safe text consumed from these services.

What's in the box

• Audio in, safe text + structured annotations out. The service receives audio from a capture surface (in-person visit UI, rounds tablet, multi-stream televisit, meeting recorder) along with whatever metadata that surface provides. It transcribes the audio, runs the raw transcript through anonymisation, and exposes only the result — automatically and in near-real time. Downstream consumers receive a stream of safe transcript segments carrying the anonymised text plus passthrough annotations (per-stream speaker id, declared role, language, timestamps, confidence, consent regime). Consumers never reach upstream of the privacy boundary.

• No LLM inference inside the privacy boundary. The membrane uses cheap deterministic processing only — voice-activity detection, speech-to-text, two-pass anonymisation (regex + classifier). Annotations the privacy boundary carries are passthrough from the capture surface (which stream produced this audio, what role was declared at session open) or cheap-deterministic (when the transcriber said the words, in what language). Generative AI never sits between audio and safe text. Features that want to infer something — speaker role on a single mixed mic, action intent, candidate diagnosis — do so downstream, on segments the privacy boundary has already made safe.

• Speaker identity is input, not inference. Each recording context provides whatever speaker information it has — the logged-in nurse, the participants of a video call, the pre-declared roles in a meeting. The service stores this metadata alongside the recording but never tries to deduce identity from voice. Features that want role inference layer it on top.

• Sealed raw boundary. Raw transcripts and original audio live in the speech-anonymisation service alone. Other features cannot receive them by default — receiving raw is an explicit, audited action that requires specific authorisation.

• Per-zone retention. Each compliance zone defines how long raw audio and raw transcripts are kept. Anonymised transcripts follow the longer clinical-record retention. Minimum-necessary retention for raw is the design intent.

• Every action audited. Recording started, transcription run, anonymisation applied, raw transcript accessed, audio played back, retention deletion executed — all surface as audit events.

• Built on open-source audio. Capturing, mixing and routing audio — for recordings in the room and remote consultations alike — runs on an open-source real-time communication stack already used underneath certified secure-conversation products in regulated industries. The platform's contribution is the clinical compliance layer on top — anonymisation, audit, retention, zone-aware routing.

• Consent is the caller's responsibility. Consent capture happens in the calling clinical workflow, before recording starts. The service trusts that consent has been obtained.

Audio consent regimes

Clinical audio is not one thing. A doctor recording an ambulatory visit, a team huddling between beds on a ward round, a clinician dictating notes after the patient has left, a team discussing one patient's case in a consilium, a code team resuscitating an unconscious patient — these look superficially similar (audio captured, transcribed, summarised) but rest on materially different legal grounds. A platform that treats them as one shape ends up with a quiet lawful-basis problem: the patient who consented to their visit being recorded did not consent to the team huddling about them in the corridor, and the patient lying unconscious in resus could not consent to anything.

The platform's answer is to make the distinction explicit. Every clinical audio recording produced on Jengu is captured under one of three consent regimes, decided at the moment recording opens. The regime determines the lawful basis, the access policy, the retention class, the consent resource (if any), and the path the patient's GDPR rights take. Modules declare which regime they are opening; the platform is the authority on what each regime entails.

The regime is carried in FHIR through standard fields, not through a Jengu-specific extension. The recording is bound to a FHIR visit record; the visit records's standard class field records the clinical setting (inpatient, ambulatory, emergency, virtual), its standard type field records the recording purpose (ward-round bedside, ward-round huddle, post-visit dictation, case consilium, post-round addendum, reanimation event), and its standard meta.security field carries the consent regime as a security label from a Jengu CodeSystem. Using the same field FHIR already uses for confidentiality codes and purpose-of-use labels means the regime propagates automatically to every derived artefact and is recognised by standard FHIR-aware access-control tooling without learning anything Jengu-specific.

One room per recording — the platform-wide rule

Every clinical recording the platform produces lives inside exactly one the live video service room, and every room corresponds to exactly one clinical visit records. The room is the trust boundary: access policy, retention class, consent context, anonymisation pipeline, and audit scope all attach to it. There is no recording that spans two patients and no patient whose recording is split across two rooms.

Recordings the patient takes part in

The patient is in the room as a participant. The recording is a clinician–patient communication captured under the patient's own consent.

• Where it applies: ambulatory consultations, televisits, ward bedside visits, single-patient MDTs with the patient present, therapy sessions, recorded discharge teach-back.
• Lawful basis: GDPR Art 9(2)(h) treatment + ePrivacy 2002/58/EC consent obtained from the patient + Art 6(1)(a) consent for the recording itself.
• Consent: captured as a FHIR consent record resource before recording starts, with a positive capacity declaration. No consent, no recording.
• Retention: the standard patient-record class — raw audio and raw transcript 7 days (zone default), anonymised transcript for the clinical-record retention window.
• Patient rights: GDPR Art 15 (access) and Art 17 (erasure) follow the visit records through the standard patient-record path.

Recordings the clinicians make alone

Only clinicians are in the room. Patients may be named in the content — and clinical decisions about them may be reached — but no patient is a party to the recorded communication.

• Where it applies: ward-round huddles between beds, post-visit dictation by the doctor after the patient has left, case consilia discussing one patient's case, post-round per- patient addenda the next morning, multi-clinician shift handovers, anonymised teaching debriefs.
• Lawful basis: GDPR Art 9(2)(h) treatment + Art 6(1)(f) legitimate interest for care coordination — not patient consent. Patients are not parties to the recording and cannot consent to a conversation they are not part of.
• Consent: no patient consent record resource. Clinician participation is consented via employment / role; voiceprint enrolment carries its own clinician-biometric DPIA.
• Access: frozen team-roster group declared at recording start. Mid-session roster changes emit a roster-change Provenance and a new access rules version. Patients named in the content do not automatically gain read access to the whole recording (it contains other patients) — they gain access to the per-mention excerpts attributed to them.
• Retention: tighter than patient-record class — raw audio 24 hours or end-of-shift (whichever is shorter), raw transcript 7 days, anonymised transcript retained only for segments attributed to a specific patient anchor (those segments inherit the anchor's retention); unattributed content deleted with the raw layer.
• Patient rights: Art 15 served through per-mention Provenance back-references — every detected patient identifier in a clinician-only recording emits a back-reference to the affected Patient resource. Art 17 served through speaker-turn-level redaction of the anonymised transcript — never by deleting the whole recording, which would erase other patients' clinical record.

Recordings made when a life is at risk

The patient is in the room but cannot consent.

• Where it applies: reanimation events (code blue), emergency stabilisation of an unconscious patient, ED arrival of a patient unable to communicate, acute psychiatric crisis with documented absence of capacity.
• Lawful basis: GDPR Art 9(2)(c) processing necessary to protect vital interests + Art 9(2)(h) treatment.
• Consent: none — structurally unobtainable. The visit records records "unable" with a vital-interests justification.
• Retention: longer than patient-record class — vital-interests bucket per zone medico-legal policy. Default 10 years for the anonymised transcript; 30 days for raw audio (to support post-event review).
• Patient rights: retrospective notification once capacity is regained. Art 17 erasure is conditional — the legal-obligation carve-out (Art 17(3)(b)) applies where national clinical-record retention law mandates preservation. The patient retains the right to challenge but cannot unilaterally erase a record from a regime that legally requires its retention.

What kind it is, is fixed when it starts

A recording does not change regime mid-session. If circumstances change — the patient leaves the room, a code is called, the doctor moves to solo dictation — the current recording ends and a new one opens under the new regime. The transition is itself an audited event.

This rule is a consequence of the consent moment being at recording open: a patient who consented to a recording they took part in did not consent to that recording silently mutating into a clinician-only dictation about them after they leave.

How recordings compose into clinical workflows

Most clinical features combine the regimes in predictable ways. The platform names four patterns; new features pick the one that fits.

• With the patient present. One visit records, patient present. The ambulatory visit. The televisit.
• Anchor + adjunct (a recording with the patient, then one without). A patient-facing encounter is followed by a clinician-only recording related to it. The adjunct attaches to the anchor via visit records.partOf. The doctor's post-visit dictation. The case consilium. The post-round addendum.
• Cohort + huddle (the ward round). A no-patient parent visit records groups several bedside-visit children (one per patient, each with the patient present) and one team-only huddle. During the parent's open window, exactly one child's recording is the active target — either the huddle (default, between beds) or one bedside (when the doctor taps a bed card). The auto-switch is enforced server-side at the recording service. This is the only pattern with two simultaneously-open rooms.
• A life-at-risk recording on its own. A vital-interests event. One visit records, longer retention, constrained Art 17. Post-event medico-legal review attaches as an Anchor + adjunct (the review is a clinician-only recording partOf the event).

What customers and operators experience

• A patient consenting to a recorded visit sees the same consent UX every time, in plain language, before the recording starts. Their consent record is per-visit records, capacity-gated.
• A patient named in a team discussion they were not part of is a person spoken about in a clinician-only recording by reference. The platform emits a per-mention provenance back-reference at the moment the name is detected, so the patient's Art 15 access and Art 17 erasure remain servable even though no patient consent was given for the underlying recording.
• A doctor on a ward round sees a persistent chrome telling them in plain text which room is recording — ROUND PAUSED, HUDDLE LIVE, or BED N LIVE — and switches with a single tap. The chrome is unmistakable from 1.5 m under ward light.
• A patient in an emergency they cannot consent to is recorded because a life was at risk, retrospectively notified once capacity is regained, and retains constrained Art 17 rights against the medico-legal retention baseline.
• A compliance officer has one taxonomy to certify, not one per clinical feature. New features that add recording inherit the regime semantics; the consent surface, the retention bucket, and the Art 15/17 path are decided once.
• An auditor can ask one regime-aware question — "show me every clinician-only recording over the past 30 days that named patient X, and show me the per-mention provenance and the recording-target-switch audit chain" — and get a complete answer from the recording service alone.

Related

• Runtime spec: clinical audio consent regimes — the implementation contract: state machine, FHIR shapes, audit event shapes, retention tables, ward-round orchestration.
• Clinical audio: three consent regimes — the architectural decision pinning the three-regime model.
• US-ACUTE-ROUND user story — the morning-ward-round scene that the cohort + huddle pattern implements.

Standards we lean on

• HIPAA 45 CFR 164.312(a)(1) — access control on ePHI.
• GDPR Article 9 — special-category data (health and biometrics) requires explicit lawful basis and tightened controls.
• ePrivacy Directive 2002/58/EC — recorded communications carry their own consent regime.
• ISO/IEC 27037 — handling of digital evidence (audio, raw transcript) under controlled access.

What customers and operators experience

• A clinician opening any recording-capable feature sees the same indication that a recording is starting and the same consent UX. Behaviour is consistent regardless of context.
• A patient is protected by a uniform policy: encrypted storage, minimum-necessary retention of raw audio, access on cause only, full audit. The protection does not vary by which clinical app captured them.
• A nurse on inpatient rounds uses a tablet that records as they walk. Each observation knows which patient it concerns and who is speaking — both supplied as metadata, not inferred.
• A doctor in a face-to-face visit records the consultation on a single microphone. Their own identity is known from login; the patient is speaker-unknown content, anonymised before it leaves the boundary.
• A multi-party meeting recorder captures audio with each participant's identity tagged from the moment they speak (per-microphone or per-stream identification).
• A clinical feature consuming the output receives the anonymised transcript, never the raw text.
• A compliance officer sees one policy governing all clinical recordings: who can listen, who can read raw, what retention applies, how long anonymised text persists.
• An investigator with cause can request raw access through an audited path. The request, the reason, the identity, and the timestamp are all recorded. There is no informal back door.

Limits and trade-offs

• No diarisation by the service itself. When the recording context cannot provide speaker metadata (e.g., a single mixed track of an unattended meeting), downstream features must layer their own diarisation or accept speaker-unknown content.
• Raw retention is short by design. Raw audio is biometric; raw text is identifying. Both expire on policy. Long-term raw access is an exception that requires explicit, time-bound authorisation.
• Transcription quality limits everything downstream. Anonymisation works on the text the transcriber produces; speech the transcriber misses cannot be redacted. Quality varies by language and acoustic conditions and is the underlying provider's contribution.
• Multi-language support depends on the transcription provider. Expanding language coverage is provider-side work.
• The service does not record consent itself. Consent capture happens in the calling clinical workflow, before the recording starts.
• The service does not display patient identity. The clinician-facing UIs that use the recording service follow the platform-wide identification-on-demand invariant: bed / visit / visit records references and clinical context are persistent on screen; patient names appear only when the doctor explicitly taps Reveal identity, for a stated purpose, with an audit event. The recording captures spoken names; anonymisation strips them before the transcript leaves the recording boundary. The screen never shows them by default.
• Physical containment is incomplete in shared-bay wards. The recording boundary is logically clean (one room per bedside encounter; the tablet screen is pseudonymous), but bay acoustics still carry the doctor's spoken voice to neighbouring beds — a clinical-building-design property the platform inherits and does not pretend to fix. Mitigations available at the platform side are the anonymisation pipeline (so the leak does not re-export into the downstream record) and tablet-hardware practices (privacy filter, screen-off-when-idle); the residual risk remains a property of the physical ward.

Staff messages cross organisations through the same privacy boundary as everything else.

The promise

When staff in different organisations need to talk — a clinic asking its laboratory about a sample, a ward coordinating with a partner — the conversation runs inside the platform, and it crosses organisational boundaries the same way data does: through a declared, audited channel, never around it.

Every boundary crossing is recorded, and message content faces the same discipline as clinical text — what leaves an organisation passes the privacy boundary, so a hurried message cannot become the leak the rest of the platform was built to prevent. In development environments, messaging deliberately degrades to a local log rather than reaching any real recipient.

Why this matters to a customer

The alternative is what actually happens today: patient details in private chat apps and personal e-mail, invisible to the audit trail and to the DPO. Giving staff a channel that is as convenient as the workaround and as governed as the record removes the incentive to leak — and gives an investigator one place to look instead of subpoenas into personal phones.

What it does not promise

This is staff-to-staff coordination, not patient communication — the patient's own channel is the portal's concern. And messaging is a channel, not a record: clinical facts belong in the clinical record, and a message referring to them is not a substitute for writing them there.

Jengu screens run inside the hospital's existing system — launched from their patient record, no separate login.

The promise

A hospital does not have to leave its own system to use jengu. A jengu appliance — a focused screen anchored to exactly one clinical process, such as capturing a visit — launches from inside the hospital's own record system using the SMART App Launch standard: the clinician is already signed in, already in a patient's context, and the appliance opens carrying both. No second login, no re-finding the patient, no retyping.

Each appliance is deliberately narrow: one process, its own small contract, launched where the work happens. The hosting system and the appliance exchange only what the standard's handshake defines, and what jengu writes lands in the clinical record with the same provenance and audit as work done in jengu's own interface.

Why this matters to a customer

The graveyard of clinical software is full of good tools that lost to the alt-tab: whatever the hospital's main system is, that is where clinicians live, and a tool that demands they leave it is a tool that goes unused. Embedding by open standard inverts the adoption problem — jengu meets clinicians inside the system they already use, and the hospital's IT department integrates it the way the standard prescribes rather than by bespoke project.

What it does not promise

An appliance is a door into jengu, not a copy of it — the full platform experience, administration and cross-module views live in jengu proper. And embedding depends on the hosting system implementing the standard's launch correctly; jengu conforms to the standard, it cannot conjure it where the host lacks it.

Everything jengu does for clinical actors is reachable through one open, documented healthcare API, in the standard the industry already speaks.

The promise

A hospital system, a laboratory system, or a clinical application integrates with jengu through one front door that speaks FHIR — the open standard healthcare data interchange already uses. What the API offers is partitioned by actor: each kind of caller sees exactly the surface that belongs to its role, described by generated, always- current documentation with a working try-it console, so an integration engineer can read, authorise and exercise a call before writing a line of code.

Access is declared, not accumulated. A customer organisation declares its API clients; each client is bound to the department whose data it may touch, and the department context is resolved on every call rather than trusted from the caller. What a client sees through the door is scoped to the customer organisation and department it belongs to — the partition is the promise.

Why this matters to a customer

Integration cost is the tax on every healthcare IT decision, and closed or idiosyncratic APIs are how vendors collect it. An open, standard, per-actor door means a customer's other systems — and its future vendors — meet jengu on public terms: no proprietary dialect to learn, no surface wider than the role requires, documentation that cannot drift because it is generated from what is actually served. The door is also how jengu avoids becoming the thing it replaces: leaving is as documented as arriving.

What it does not promise

One door, not one permission: the API's openness is about reachability and standards, never about access — every call still crosses customer organisation isolation, consent, and audit exactly as an interactive user would. Bulk research use of clinical data is not this API's business; it belongs to consented data use, with its own consent and anonymisation guarantees.

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.

Why this matters

Estonia — and the EU generally — has no shared infrastructure for private health-insurance eligibility and claims. Every insurer–provider pair improvises: phone calls and PDFs for coverage questions, spreadsheets for claims, weeks of latency for adjudication, and no common definition of what a "service" even is. The US has a mature FHIR claims stack, but it is bound to American regulation; Europe's equivalent is whitespace.

That whitespace is what the gateway fills, on three foundations already core to the platform:

• Standards. The base FHIR financial resources (cover record, CoverageEligibilityRequest/Response, claim, claim response, settlement statement, payment settlement) are payer-neutral and country-agnostic; the gateway constrains them with Jengu-EU profiles — European coding (ICD-10, ATC, LOINC, SNOMED CT, national procedure codes), EUR, and extensions for risks, limits, and deductibles.
• Shared semantics. Eligibility and claims are only decidable when both sides mean the same thing by a service — the zone service catalogue, which the insurer's coverage and the provider's offering are both bindings of.
• Privacy by construction. The provider side works pseudonymously; the insurer is entitled to know its own member and receives exactly that — a brokered, consent-checked, audited membrane resolution, purpose-limited to the claim (EHDS bars secondary and underwriting use).

What's in the box

Multi-payer by design, statutory included

One gateway, many insurers; a provider integrates once. Tervisekassa is just another insurer in the model — its only distinction is that its published service and tariff list already exists, which makes it a convenient seed for the zone catalogue. Every payer, statutory or private, binds its coverage to the same catalogue and adjudicates through the same exchange.

The full loop

• Eligibility — at the point of care: is this service covered for this member, what limit, sub-limit, and deductible remain, is pre-authorisation required.
• Pre-authorisation — approval before high-cost delivery; rule-based automatic or human review on the insurer's side.
• Claim → adjudication — the provider submits delivered services (catalogue codes, ICD-10 diagnoses, EUR charges); the insurer approves, rejects, and computes the covered amount versus the patient's share — in real time or deferred review, a per-product policy rather than a rebuild.
• Payment advice — remittance and reconciliation data relayed to the provider. Jengu never touches money; the insurer pays the provider directly.
• Pharmacy — the same loop for dispensing: prescription, coverage check, dispense, ATC-coded pharmacy claim.

Insurers author their own products

Coverage is the insurer's differentiator — insurers compete on terms, not only price. Each insurer owns its products: risks and sub-risks, limits and sub-limits, deductibles (omavastutus), exclusions, waiting periods, and the risk↔service mapping onto the zone catalogue. What is shared is the machinery: the rules engine, the standard rule types, and the catalogue. A statutory reference rule pack is an optional starting point to customise, never an imposed standard.

Portal-first, then API

In the first phase a provider participates with zero IT integration: a Jengu web portal covers eligibility, pre-auth, and claim submission. Deep integration — the provider's HIS via API, the insurer's core system via certified connectors (X-Road for the statutory payer, insurer APIs for private ones) — follows without changing the exchange semantics.

Every exchange is brokered, durable, audited

The gateway is a brokered participant exchange: each eligibility check, pre-auth, claim, and payment advice runs as a durable workflow under a bounded service account, crossing the membrane only through consent-checked, audited resolution. Provider and insurer each keep their own copies of the exchange records in their own sealed spaces; the workflow log is the authoritative trail of who asked and what was answered.

Standards we lean on

• HL7 FHIR financial module under Jengu-EU profiles.
• ICD-10 / ATC / LOINC / SNOMED CT and national procedure codes, via the zone terminology layer; currency EUR.
• TEHIK FHIR implementation guides and X-Road (X-tee) where Estonian national systems are touched.
• EHDS purpose limitation — claims data is never available for secondary or underwriting use.
• Reference designs: the Netherlands' Vektis / VECOZO declaration exchange and the UK's Healthcode + CCSD private clearing model — borrowed from, not adopted.

What customers and operators experience

• A clinic receptionist answers "is this covered and what will it cost you?" while the patient is at the desk, from the portal, for any participating insurer.
• An insurer's product manager configures a new product — risks, limits, mapping — as reviewed configuration; adding a risk is a config change that disrupts no running flow.
• A hospital's finance team sees claims adjudicated in real time where the product allows it, with denial reasons per line, and remittance advice that reconciles itself against submitted claims.
• A patient sees their own benefit statements through the patient-facing surface, and their identity never travels to anyone not entitled to it.
• A compliance officer can trace any claim from portal submission to adjudication as one workflow with one audit trail, and answer exactly what the insurer received and under which consent.

Limits and trade-offs

• Jengu is a data gateway, not a financial institution. No payment execution, no holding of funds — remittance flows are data only.
• Real-time adjudication has a latency budget. Point-of-care answers must survive connector round-trips to insurer cores; where a core is slow, the per-product deferred mode is the honest fallback.
• The catalogue is the gate. A service missing from the zone catalogue cannot be checked or claimed until the change-request flow adds it — semantic agreement is deliberately prior to exchange.
• Consent mechanics gate production. How and when the patient's consent to insurer data-sharing is captured is an open decision; the prototype can run against test members, but production requires the consent ledger in the loop.

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.

Why this matters

A clinical recording is the most sensitive data a healthcare organisation produces routinely: voice is biometric, the content is medical, and the patient's identity is rarely separable from either. Recording the consultation reliably is essential for downstream features — transcription, anonymised summaries, clinical assists — but the recording itself must be governed tightly enough to satisfy the compliance officer who signed off on the platform.

Two failure modes are common in clinical recording systems. One: consent is captured before the consultation starts but loosely, so a regulator can reasonably ask whether the patient understood. Two: the recording flows to several downstream systems (transcription provider, AI provider, analytics) and each handoff is a place a recording can leak.

Visit recording is built around those two concerns explicitly. Consent is captured in the same flow as recording start, with a record of what the patient heard and agreed to. The recording is encrypted at rest, lives only in the platform's secure recording service, and is never handed to a downstream component without an audited raw-access path.

What's in the box

• Platform secure recording service is the substrate. Audio capture, transcription, and anonymisation pipeline are platform features; Visits is one consumer.

• Consent as a FHIR Consent resource. It references the encounter, names the language version shown, records who agreed, and timestamps the agreement. Consent precedes recording start; without it, recording does not proceed.

• Sealed boundary on raw content. The raw audio and raw transcript live only in the recording service; downstream Visits features receive anonymised text by default. Raw access is an explicit, audited action.

• Encryption at rest. Raw audio and raw transcript are encrypted at rest by the platform's encryption feature — the recording is never stored unencrypted.

• Retention follows the zone. Each compliance zone defines raw-audio and raw-transcript TTLs; per-zone retention workers delete past-TTL recordings, audited as AUDIT_DELETE.

• Speaker identity is metadata, not inference. When the recording client provides speaker identity (logged-in clinician, conference participant), it carries through as metadata. When the client cannot provide identity, no diarisation is attempted.

Standards we lean on

• GDPR Article 9 — special-category data (health, biometrics) with tightened controls.
• ePrivacy Directive 2002/58/EC — recorded communications carry their own consent regime.
• HL7 FHIR R4 Consent — the standard shape for the consent record on the encounter.
• ISO/IEC 27037 — handling of digital evidence (audio, raw transcript) under controlled access.

What customers and operators experience

• A clinician starting a recording sees a consent prompt for the patient (or their representative). Consent is captured with language and version; the recording starts only when consent is recorded.
• A patient asking later "what was recorded?" receives a precise answer: the date, time, duration, the consent language shown, and the audit record of who has accessed the raw recording since.
• A clinician pausing or resuming during a sensitive moment records that pause as an event. The clinical thread is preserved; the redacted content does not enter the recording.
• A compliance officer reviewing the platform sees that every recording event — start, pause, resume, finalise, raw access, anonymised access, deletion — is an audit event in the same trail as the rest of the platform.
• An investigator with cause can request raw-recording access through an audited path.
• A clinician at end-of-shift sees expired raw recordings removed automatically per the zone's retention policy.

Limits and trade-offs

• Consent is the calling workflow's responsibility. The recording service trusts that consent has been obtained per the configured language; quality of consent is governed by workflow design, not enforced post-hoc.
• Audio is not anonymised. Voice itself is biometric and carries identity. Audio is protected through retention and access controls, not redaction.
• Pause-resume preserves clinical thread but loses content during the pause. A clinician who pauses for a sensitive conversation has the unrecorded content out of the system entirely. This is the intended trade-off.
• Recording quality is bounded by the device. The microphone, the room acoustics, and the network conditions set the upper bound on transcription and anonymisation quality downstream.

Related features

• Visit note generation — the recording is the input to the note draft.
• Live clinical assists — consume the anonymised live transcript stream.
• Platform: Secure recording service — the substrate Visits builds recording on.
• Platform: Patient data anonymisation — the policy enforced on every transcript before it leaves the boundary.
• Platform: Regulatory audit trail — every recording event is an audit event there.

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.

Why this matters

A clinician in a consultation is doing several things at once: listening, examining, deciding, documenting. The cognitive load is real, and the moments where AI can usefully assist are the moments where adding cognitive load is least welcome. Assists that arrive seconds late, or surface in a separate window, or interrupt the clinical flow do not help — they irritate.

The window that matters for live assists is roughly the length of a sentence. A drug-interaction warning that surfaces while the clinician is still saying the prescription out loud is a save. The same warning, shown after the visit ends, is a paperwork item.

Live clinical assists are the platform's answer for the in-conversation case. The pipeline is engineered for sub-second latency on the critical path: keyword filter → lightweight model → assist surfaced. The clinician sees the relevant prompt while the conversation is still on the topic; they can act, dismiss, or note for follow-up without pausing the interaction.

What's in the box

• Pre-filter before LLM call. A keyword catalogue recognises segments that have no plausible clinical trigger (greetings, casual chat) and skips them. Most segments cost nothing.

• Anonymisation runs first. Patient identifiers, ID numbers, contextual identifiers are removed before any LLM call.

• Right-sized model per task. Action detection and role labelling run on a fast model for sub-second latency; pattern-matching against clinical guidelines runs asynchronously on a stronger model.

• Streaming transcript drives assists. The transcript is produced incrementally; assists evaluate against each finalised segment within the segment's lifetime.

• Per-zone provider routing. Which AI provider runs each assist task is determined by the tenant's compliance zone through the platform's right-sized AI router.

• Inline prompts, not modals. Assists appear in a side panel of the visit UI; they do not interrupt the recording or the clinician's documentation.

Standards we lean on

• GDPR Article 22 — automated decision-making constraints; assists are 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 assists are presented and audited.

What customers and operators experience

• A clinician mentioning a medication during the visit sees an interaction check inline if the patient's existing prescriptions contraindicate. The prompt surfaces while the clinician is still finishing the sentence.
• A clinician saying "let's do a CBC and metabolic panel" sees a one-click lab-order action surface, with the test list pre-populated and the order ready to confirm.
• A clinician treating a pregnant patient sees relevant context-flags surface ("pregnancy: dose-adjusted limits apply" / "this medication is contraindicated in pregnancy") whenever the conversation triggers it.
• A clinician who finds an assist unhelpful dismisses it with a single click; the assist disappears and is logged as reviewed-and-dismissed.
• A clinician in zone-ee sees assists informed by Estonian terminology and Estonian-recognised reference data; a clinician in zone-de (when delivered) sees German ones — same product, different zone-aware data.

Limits and trade-offs

• Assist quality is bounded by the underlying model and the available context. A clinician using terminology the model was not trained on, or referencing patient context the platform does not have, sees fewer or weaker assists.
• The platform errs on the side of fewer-but-stronger assists. Suggestion fatigue trains clinicians to dismiss even good prompts. The default tuning is conservative.
• Live assists run during recording only. A clinician who chose not to record the visit gets no live assists.
• Latency is bounded by the slowest provider in the chain. Network round-trip to the LLM provider is the largest component; zones that route to remote providers see higher latency than zones that route to local models.

Related features

• Visit recording with audited consent — recording produces the live transcript live assists consume.
• Smart action detection — distinct concern: smart actions are detected actions surfaced as one-click; live assists include suggestions that don't necessarily map to an action.
• Platform: Right-sized AI pipeline — Visits's live assists are routed through the platform's per-zone, per-task-kind AI router.
• Platform: Patient data anonymisation — anonymisation is the boundary that protects the LLM input.

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.

Why this matters

Most clinical intents stated during a visit ("I'll prescribe amoxicillin", "let's get a CBC", "send a referral to cardiology") do not need to be completed in front of the patient. They become draft entries on the note for the clinician to review and confirm afterwards — that's what visit note generation and live clinical assists already deliver, and that's the right shape for them. Inserting a form into the consultation for every such intent would turn the visit into a paperwork session.

A small fraction of actions are different. They need to be decided together with the patient, while the patient is in the room, because the patient has to agree to specifics — a particular MRI slot at a particular date and time, a follow-up visit scheduled after the MRI result is back, a referral picked from a list of specialists with availability the patient can make. These cannot wait for the post-visit review: the patient is what's missing afterwards.

Smart action detection exists for exactly this case. It surfaces a focused, interactive form during the recording so the clinician and patient can agree and complete the action together — without the clinician switching out of the visit context, and without the action becoming a "to do" item that pushes the booking to some later moment. The design constraint is minimal interruption: fewer triggers, better completion, recording continues throughout.

What's in the box

• Triggers come from a vetted catalogue. Each smart-action type is explicitly marked as smart-action-eligible — at the platform level for the general types (slot bookings, follow-up scheduling, referral pickups), and within module service catalogues (e.g., Lab's standardized service catalogue) for individual items that need patient agreement at the time of order. The lab director marks the few tests whose nature requires the patient's agreement — a slot-based procedure, a scheduled sample, an after-hours service — while routine tests in the same catalogue do not trigger. Whether an item is smart-action-eligible is a catalogue decision, reviewed like any other configuration in the customer's config repo.

• Two activation paths. Smart actions can be invoked either by conversation (the LLM detects a triggering phrase and surfaces the action button mid-recording) or by typing (the clinician types into the always-available smart-action box on the visit form; the LLM autocompletes with full, context-aware suggestions like "book first free MRI slot for meniscus from 21 July + follow-up 3 weeks later" or "book MRI asap, then follow-up two weeks after"). Either path opens the same focused form.

• Focused form, scoped to one action. When a trigger fires, a side panel opens with a form pre-filled from the conversation so far (test type, indication, patient preferences, urgency). The clinician's attention narrows to this form for the duration of the action.

• Parallel editing in the focus, serial elsewhere. While the focused form is open, the clinician can edit by hand and the LLM can update fields as the conversation produces new information ("actually, push it a week later"). Race conditions inside the focused area are handled deliberately — the focus is what permits parallel editing. Outside the focused form, the rest of the visit's transcript and assists continue updating in their normal serial way; parallel LLM + clinician editing is only permitted inside the focused smart-action form.

• Patient agreement during recording. The patient is in the room while the action completes; the audio of their agreement is captured in the same recording as the rest of the visit. No separate consent path; the consultation is the consent.

• Chained smart actions. Completing one action can spawn a dependent one. After the MRI slot is set for date X, "let's arrange follow-up after the MRI result" opens a follow-up smart action seeded with date X + 2 weeks. As the conversation refines ("I'm on vacation that week"), the seed shifts. A typed composite suggestion ("book MRI asap + follow-up three weeks later") is the same chain expressed upfront.

• Confirmation = the action applied. When the clinician confirms, the booking is made, the referral is filed, the appointment is created. From that moment, this is a real clinical action on the record — not a draft, not a pending task awaiting background processing, not a "we'll get back to you". The patient leaves the visit with the slot already on their calendar. The audit trail records confirmation as the moment of application.

Standards we lean on

• HL7 FHIR R4 Appointment, ServiceRequest, ReferralRequest — the standard shapes confirmed actions immediately become.
• GDPR Article 22 — automated decision-making. The clinician's confirmation (with the patient present) is the human-in-the-loop required by the article.
• EU AI Act (Annex III, healthcare risk class) — clinical decision-support classification informs how smart actions are presented and audited.

What customers and operators experience

• A clinician saying "let me see when the first MRI slot is for your potential meniscus injury" sees a smart-action button appear inline. One click opens a search-and-book form pre-filled with test type, indication, and the patient's context.
• A clinician typing into the smart-action box "book MRI for meniscus + follow-up three weeks later" sees an LLM-generated autocomplete list of complete action suggestions; picking one opens the same focused form (or, for composite suggestions, the first form in the chain) with parameters already set.
• A clinician ordering a Lab catalogue item flagged as smart-action-eligible (e.g., a glucose tolerance test that needs a 2–3 hour slot) sees the same focused-form pattern, pre-filled from the catalogue entry. The slot lives in the Lab module's worklist; the booking is applied through cross-module workflow at the moment the clinician confirms with the patient.
• The clinician and patient deciding together see slot options. The clinician picks one; the patient agrees out loud; the clinician confirms — and the booking exists from that moment.
• The clinician adding extra information mid-form ("she's also on a blood thinner — flag it on the request") sees the LLM update the form's relevant field while they keep talking. Manual edits and LLM edits coexist inside the focused form.
• A chained follow-up — "let me arrange follow-up two weeks after the MRI" — opens a second smart action with the follow-up window already calculated from the just-confirmed MRI date.
• A clinician saying "I'm on vacation that week, push it a week later" sees the chained follow-up's search window shift accordingly without re-typing the original parameters.
• A patient leaving the visit has the agreed slot bookings and follow-ups on their calendar already. There is no "we'll be in touch" step.

Limits and trade-offs

• The trigger catalogue stays small. Adding a new smart-action type — or flagging more items in a module catalogue — is a deliberate choice, not a side-effect of better detection. The constraint is the clinician's attention; more triggers mean more interruptions.

• Confirmation makes the action real. A clinician who confirms a slot they did not actually intend has booked the slot. The platform treats confirmation as the act of agreement, not a draft step. Cancellation is a subsequent clinical action, audited like any other.

• A smart action that doesn't complete during the visit is abandoned. It does not queue, does not become a reminder. The intent flows to the note as a regular plan item; the patient doesn't get the slot pre-booked.

• Parallel editing is only inside the focused form. Outside it, the LLM updates serially and the clinician edits at their own pace. The platform deliberately does not extend the parallel-editing pattern to the whole visit UI.

• Chained dependencies are best-effort. A follow-up scheduled relative to an MRI date depends on the MRI date being confirmed first; if the MRI booking is abandoned, the follow-up's seed becomes meaningless and the follow-up smart action closes.

• Booking-style smart actions to external systems depend on EHR integration as a precondition. When the booking target is a system outside the platform — hospital EHR slots, external imaging services, third-party scheduling — the customer's system must be integrated first. This is contract-time setup, not runtime opportunism. Three things have to be agreed up-front:

  1. Near-realtime slot-availability feed. The external service publishes slot-status updates to the platform frequently enough that the options the clinician sees in the focused form are accurate at the moment of the visit.
  2. Near-realtime booking writeback as FHIR. When the clinician confirms, the resulting Appointment / ServiceRequest flows back to the customer's EHR within seconds — so the hospital's own systems reflect the booking the platform just applied.
  3. A customer-side conflict-resolution rule. If two systems attempt the same slot, the customer owns the resolution policy (which one wins, how the losing side is notified, how the patient is informed). The platform surfaces the conflict; it does not decide it.

  Without those three agreements, smart-action bookings to that external system are not enabled for the tenant. Bookings whose target is an internal Jengu module — for example, a slot the Lab module already manages on the platform — do not need this setup; they flow through the platform's cross-module workflow feature and are integrated by definition.

Related features

• Live clinical assists — surfaces routine suggestions and warnings during the visit; not a smart action. Smart actions are the rare cases that need form-based completion during the visit.
• Visit note generation — routine intents (prescriptions, lab orders) flow into the note's plan, not into smart actions. Confirmed smart actions are linked from the note's plan section as already-applied.
• Patient-facing visit summary — confirmed smart-action bookings and follow-ups appear in the patient's take-home summary, already arranged.
• Platform: Cross-module clinical workflow — confirmed smart actions interact with downstream modules (imaging, scheduling, referral) at the moment of confirmation.
• Platform: Right-sized AI pipeline — both the detection trigger and the in-form LLM updates run through the platform's per-zone AI router.
• Platform: Regulatory audit trail — every confirmed smart action is an audit event recording who agreed, when, with what parameters.

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".

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.

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.

Why this matters

A multi-module healthcare platform connects to a lot of external systems. The lab module talks to clinical analysers and to partner laboratories. An insurance module talks to public and private insurers. A billing module talks to accounting systems. The platform itself talks to the on-site appliances at every customer site.

Without a shared framework, each module would build its own plumbing — its own configuration screens, its own status panels, its own audit hooks, its own update mechanism. Compliance teams would see a patchwork of integration logs; administrators would learn three different "add a device" screens; the IT team would chase an update through three release pipelines.

With one framework, the experience is uniform. A lab administrator adding a new analyser, a billing administrator adding an accounting connector, and a platform operator enrolling a new edge appliance all use the same shape of screen, see the same shape of status, and produce the same shape of audit entry. When a regulator asks "show me every external system Jengu connects to for this customer organisation", there is one answer, not several.

What's in the box

• One device inventory. Every external system — analyser, partner lab, insurer endpoint, accounting connector, on-site edge appliance — is registered as a typed device in one per organisation (or shared) inventory. The device record holds the type, the location it operates from, its current status, and the connection details.

• Modules contribute device types. When a module needs to talk to a new kind of external system, it adds the device type to the framework. The rest — configuration UI shell, monitoring, lifecycle, audit, secure update — is provided. The radiology module that ships in two years adds a "PACS server" device type the same way the lab module adds an analyser today.

• One configuration surface. Each device type contributes its own form fields (an analyser needs a serial port, an insurer needs an OAuth endpoint), but the form lives inside the same Devices admin screen. Administrators learn one screen, not one per module.

• One monitoring story. Devices that opt into fleet monitoring (edge appliances, lab analysers, anything with a heartbeat) appear on the same fleet view with last-seen, health, current version. Adding a new monitorable device type does not require building a new monitoring page. Trouble on a device reaches the cloud dashboard within about a second of happening at the edge — operators see a transport drop, a credential failure, or an analyser disconnect as it happens, not at the next heartbeat tick. A network blip between an edge and the cloud delays the signal but doesn't lose it; the edge buffers events locally and resumes streaming the moment the link comes back.

• One audit trail. Every interaction with every external system is recorded with a uniform shape — what happened, when, on which device, against which patient or order, in which module. Compliance officers query one log.

• Multi-stage workflows for tests that take days. Not every integration finishes in seconds. A microbiology culture produces results in stages — gram stain at four hours, growth at twenty-four, organism identification at forty-eight, antimicrobial susceptibility at seventy-two — each landing as it becomes available, with the report walking from preliminary through partial to final automatically. Send-out tests to a reference laboratory follow the same shape, with the partner-lab connector tracking the order until the final report arrives. Multi-day insurance pre-authorisations behave the same way. A clinician sees stages as they land, not just a delayed-and-then-complete result.

• Edges as a hosting plane. An on-site appliance is itself a device in the inventory. Other devices — a lab analyser connected over a serial cable, for instance — can declare they operate from "the edge at site X". The framework routes operations to the right place so the lab administrator does not have to know which appliance is wired to which analyser.

• Driver updates without a Jengu release. New driver code for a specific device type ships as its own update; the rest of Jengu does not need to restart. In-flight interactions finish on the old version before the new one starts serving.

• Driver contracts are versioned and machine-checked. The contract a driver is written against is a standard, semantically versioned plug-in package whose declared dependencies are generated and checked against the code itself when it is built. A change that breaks driver compatibility cannot ship quietly: the build names the changed contract package and the version bump it demands. A third-party driver author — using standard tools, not ours — works against that contract with no Jengu-specific machinery.

• Customer boundaries respected. A device private to one organisation (the lab's own analyser) cannot be reached by another customer organisation. A shared device (a national insurer used by every customer organisation in a jurisdiction) carries the calling customer organisation's identity on every outbound interaction so the external system sees who is asking.

Standards we lean on

• HL7 FHIR — device record, connection details, and organisation record are the resource shapes that hold every external system, its connection details, and the operator that owns it.

What customers and operators experience

• A lab administrator adding a new analyser opens the Devices admin, picks "Lab analyser" from the catalogue, fills in the connection details, and clicks save. The analyser appears in the fleet view with its current status; every result that flows in or command that flows out from now on is in the audit trail.

• A billing administrator enabling an accounting connector uses the same Devices admin, picks an accounting system from the catalogue offered for their region, and supplies their own credentials and account identifiers. The integration is wired and audited; every customer organisation in the region uses the same vetted connector, with each customer organisation's calls authenticated by their own credentials. Same screen, different type.

• A platform operator approving a new edge enrolment uses the same Devices admin to approve the appliance — the edge is just another device type, with its own approval flow.

• A compliance officer answering a regulator queries the unified audit trail filtered by "external-system interactions for customer organisation X". Every analyser, every partner-lab handoff, every insurer call, every accounting export is in the same list.

• The CIO upgrading the analyser driver sees the new version appear on devices of that type. Existing interactions complete on the previous version; new interactions land on the new one. No platform-wide downtime.

• A specialty group authoring a niche driver uses the same framework Jengu's in-house authors do. There is no second-tier integration path.

Limits and trade-offs

• Some device types are a stretch for the underlying model. FHIR's device record resource describes "a manufactured item used in healthcare". A lab analyser fits; an accounting system is a semantic stretch. The framework accepts both for the sake of uniform tooling, and uses careful type codes where the fit is looser.

• The shared configuration screen caps depth. A type with very rich configuration may want to link out to a module-specific deep-configuration page rather than fitting every option into the shared shell. The framework allows that escape hatch; using it is a deliberate choice.

• Cloud-side devices are catalogued by Jengu; edge-side devices are owned by the organisation. Regional integrations on the cloud side — a national insurer endpoint, a hosted LLM provider, an e-prescription gateway — are defined once per region in Jengu's curated catalogue. An administrator at the customer picks from what's offered, supplies their own credentials and quotas through a reference, and the integration is wired and audited; every customer organisation in a region calls the same vetted endpoint with their own identity attached. The trade-off: a customer organisation cannot unilaterally wire a brand-new cloud-side connector — they request it be added to the catalogue. Edge-side flips the rules: a customer organisation is free to author their own drivers for whatever exotic local hardware or third-party system they need — an unusual accounting package, a niche analyser — and run them on their own edge appliance, using the same framework Jengu's in-house drivers do. The catalogue keeps cloud-side connectors consistent and audited across all customer organisations in a region; the edge keeps the organisation's authoring freedom intact.

• Driver authoring still requires real skill — but it's standardised skill. Drivers plug into a published, stable contract: the same interface Jengu's in-house drivers target, the same device record and connection details shape, the same audit surface. That's a real customer benefit: a driver written by one team isn't a vendor-proprietary artefact tied to Jengu, it's an implementation of a well-defined integration shape, swappable for a better implementation when one comes along. No lock-in to a specific driver author. What the framework doesn't make easy is the integration itself — writing a robust connector to a flaky third-party system is still a non-trivial engineering job. Standardisation makes the shape uniform; the work to talk to the actual external system is still the work.

Every recorded visit is a task in the doctor's queue until reviewed — across sessions and devices, nothing lost.

The promise

A recorded visit does not end when the recording stops; it ends when the doctor has reviewed and signed what jengu wrote. Until then it is a task in that doctor's personal queue — one per visit, persisting across sign-ins and across devices, so the work is picked up where it left off rather than where the doctor happened to be sitting.

A task moves through a small, explicit set of states from processing to completed. When a stage fails, the task says which stage and offers the doctor real choices — retry, work from the raw material, or withdraw — within a bounded retry budget. Additions the doctor makes on top, by dictation or in writing, are labelled with their source and time, so what the AI produced and what the clinician added stay distinguishable forever. Dictation is transcribed by jengu's own speech service — never a third party.

The queue is also deliberately quiet: no push notifications, no e-mails, no interruptions. It is the only surface, and it is enough.

Why this matters to a customer

The failure mode of clinical documentation tools is silent loss — a note that never got written because the prompt appeared on the wrong screen at the wrong moment. A durable queue makes the pending state visible and owned: nothing is signed implicitly, nothing evaporates, and the decision to interrupt a doctor mid-consultation is one jengu has refused on principle rather than made configurable.

What it does not promise

The queue tracks authoring, not clinical workflow — orders, referrals and results have their own capabilities. And it does not manage workload across doctors: a task belongs to the practitioner who held the visit, and reassignment is a human decision, not an algorithm's.

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.

Why this matters

Healthcare is not one workflow. The day of a laboratory technician, a family doctor, a radiologist, a triage nurse and a hospital pharmacist look almost nothing alike, and software that tries to be one application for all of them either stays too generic to be useful or grows into something nobody can maintain.

Being modular is what lets the platform go deep in each specialty and still be one product. A hospital running the laboratory today can add visit recording tomorrow without buying the core again. A specialty group that wants something particular to their practice can build it without forking anything.

What's in the box

• A specialty brings only its own knowledge. What a lab order is, what a visit recording captures, what an imaging study contains — that is the module. Everything around it already exists.

• Everything around it is inherited, not rebuilt. One customer boundary, one way of handling identity, one audit trail, one consent ledger, one patient timeline. A module that wanted its own would have to be a separate product.

• A module is a library, not a separate application. It ships inside the platform a customer already runs, so adding one is a configuration change rather than another system to deploy, secure and certify.

• A module contributes; it does not reach. It declares its menu, its settings pages, its catalogue entries, its order types and its device drivers, and the platform puts each where it belongs. Modules never address each other. See module integration for the contract.

• One module, many departments. The laboratory module exists once and serves whichever departments are given it; a department that is not given it sees nothing of it at all.

Limits and trade-offs

• A module cannot escape the rules it inherits. That is the point, and it is also the constraint: a specialty need the platform does not yet serve — a data shape, a workflow step — is a change to the platform rather than something a module can arrange privately.

• Depth is bounded by what the shared surface carries. Where a specialty needs something genuinely new, the honest answer is that it waits for the platform to grow it, rather than being smuggled in as module-private state nobody else can see.

The platform can always show which of its commitments are proven, and by what evidence.

The promise

Every commitment jengu makes about its own behaviour — that a customer organisation's data stays inside its boundary, that raw audio does not outlive the window a clinician approved, that a consent record identifies no patient — is written down as a numbered requirement, and each one is tied to the check that demonstrates it.

At any moment, for any commitment, the platform can answer three questions without anyone preparing an answer:

• Is it proven? Automatically verified, verified by a person, or still only promised.
• By what? The specific check that demonstrates it.
• Since when? The point at which the evidence started holding.

Why this matters to a customer

A healthcare buyer is not asking whether a supplier believes its software is correct. They are asking what the supplier can show.

Most software answers that question by producing a document. A document describes what was true when it was written, and it drifts from the running system quietly, in the direction of flattery: features change, tests are removed, and the claim in the document survives both. The gap between the two is invisible precisely when it matters — during procurement, an audit, or an incident.

Here the answer is derived from the running system rather than maintained alongside it. A commitment nobody checks anymore cannot keep claiming to be proven, because the claim is drawn from the check itself. Evidence that stops holding stops being reported as evidence.

That gives three audiences something they can act on directly:

• Data protection officers and regulators — a standing account of which safeguards are demonstrated rather than asserted, which is ordinarily assembled by hand and out of date on arrival.
• Procurement and clinical governance — a way to ask "show me" about a specific promise and receive a specific answer, before signing.
• Incident response — when something goes wrong, the question becomes which commitments were actually being enforced at the time. That is answerable rather than reconstructed.

What it does not promise

This capability does not claim the platform is correct, nor that its commitments are the right ones. It makes a narrower and more durable promise: what is claimed, and what backs the claim, are the same thing — so a promise cannot quietly become decorative.

A commitment with no evidence behind it is not hidden. It is reported as unproven, which is a statement in its own right, and an honest one.

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.

Why this matters

A platform that treats patient identity as ambient — visible to every module, embedded in every clinical resource, leaked through every screen — is a platform whose privacy exposure scales with the number of modules it carries. Each new clinical module inherits the leak surface; each integration with an external system multiplies it. A new module's risk review repeats every boundary check; an auditor's privacy posture review touches every module. None of that work compounds.

The opposite design — one component that holds patient identity, with every other component working on pseudonymous references — bounds the privacy exposure to that one component. Adding a new clinical module doesn't expand the personal data surface. An auditor reviews one component, not all of them. A penetration tester maps the attack surface against one boundary, not many.

The Master Patient Index is that one component. It carries four promises that together let every other module on the platform operate without ever needing to see a patient's real name.

What's in the box

Single source of patient identity

There is exactly one place a patient's name, date of birth, national ID, and contact details live: the MPI. Every other component — lab orders, visit transcripts, clinical notes, imaging studies, future modules — references the patient through a stable pseudonymous handle. The mapping back to a real human exists only in the MPI's domain.

In practice this means that:

• The lab module holds no patient identifiers at all. Not on screen, not in storage, not in any clinical resource it touches.
• The visit assistant runs a two-stage anonymisation. The doctor knows the patient at the bedside; the cloud workflow that generates the note works on anonymised transcripts.
• Future modules — imaging, pharmacy, ward management — inherit the same posture without re-deriving it.

A clinician at a workstation still sees the patient as a person, because their screen calls the MPI to resolve identity at render time. The data store underneath references the patient pseudonymously. A snapshot of the database, a backup tape, a compromised module's memory dump — none of these reveal a patient's identity, because the identity isn't there.

Identification is on demand, never default

A clinician using any module never has a patient's name on their screen by default. The tablet on a ward round shows bed positions and clinical context. An outpatient queue shows visit references and procedures. A lab worklist shows specimen IDs.

When a clinician genuinely needs a name — to address the patient verbally, to call a family member, to compose an outbound referral letter, to verify identity before a high-risk drug — they tap a Reveal identity affordance, pick a controlled purpose tag (verbal-address / family-contact / external-referral / safety-verification / outbound-document / other), and the name appears in a short-lived modal that dismisses on a timer.

Each reveal emits an audit event with the purpose tag. A DPO reviewing a clinician's identity-reveal pattern over a month sees what they revealed and why — without interpreting clinical context. Anomalous patterns (thirty reveals at 02:00 with purpose other) are detectable without any per-module forensics.

This invariant generalises the lab module's stronger position (no identifiers anywhere) into the default for every clinician-facing module the platform carries today and will carry in future.

Brokered personal data-bearing I/O

Every interaction with the outside world that requires the patient's identity — querying a national patient registry, verifying an insurance card, posting a discharge letter, sending a televisit invitation, dispatching a prescription — goes through a certified operator bundle that lives inside the MPI's domain. No clinical module talks to a personal data-bearing channel directly.

An operator bundle is certified by the platform: its code is reviewed, its access scope is bounded, its outputs are audited. A new national-registry integration, a new e-invoice format, a new prescription destination — each lands as a certified bundle without expanding the privacy surface of any clinical module.

The customer benefit is one membrane to review per zone. Estonia gets its operator bundles for PÜT, Tervisekassa, digiretsept, ELHR; Finland gets its own set; the EU layer carries eHDSI. A hospital procuring Jengu reviews the privacy boundary, not each clinical module's outbound integrations.

GDPR Art 15 and Art 17 served structurally

When a patient asks "what does your system hold about me?" (Art 15 right of access), the request goes through one component: the MPI. The MPI aggregates the patient's data across every pseudonymous reference, returns it as one bundle.

When a patient asks to be forgotten (Art 17 right to erasure), the request again goes through the MPI. Erasure propagates to every component that ever held a reference, including derived artefacts (per-mention provenance back-references in care-coordination recordings) so a multi-subject team discussion can be redacted at the speaker-turn level rather than deleted whole.

Art 18 (restriction) and Art 21 (objection) work the same way: one component to consult, one component to act on, one audit trail to demonstrate to a regulator that the right was honoured.

Standards we lean on

• GDPR Art 4(5) (pseudonymisation), Art 5(1)(c) (data minimisation), Art 25 (data protection by design) — the membrane is data protection by design at the platform level.
• GDPR Art 9 (special-category data) — patient identity combined with health data is special-category processing; the membrane bounds where this combination exists.
• GDPR Art 15 / 17 / 18 / 21 — the patient-rights workflows the privacy boundary realises.
• ePrivacy Directive 2002/58/EC — applies to communications with the patient, brokered through MPI operator bundles.
• HIPAA 45 CFR 164.514 — de-identification standard; the membrane provides the structural mechanism.
• ISO 27001:2022 Annex A.5.34 (privacy and protection of personal data) — the privacy boundary is the privacy boundary an A.5.34 audit walks.

What customers and operators experience

• A clinician sees the patient as a person at the bedside, addresses them by name, dictates notes that mention names — and never has a name persistent on their screen. Patient identity is a tool they reach for via Reveal identity, with a stated purpose, when they genuinely need it.
• A DPO has one component to certify the privacy boundary through, one audit feed to query for identity exposure, one workflow to demonstrate Art 15 / 17 compliance against. The DPIA covers one boundary; new modules inherit it.
• A hospital procurement reviewer has one component to assess for the platform's personal data posture, regardless of how many clinical modules the hospital plans to enable.
• A patient has one place to ask "what do you hold about me?" and one place to ask to be forgotten. The response covers every module the platform carries.
• An auditor following a national-registry incident asks one question — "which records were sent to PÜT in March?" — and gets one answer from the privacy boundary's operator-bundle audit.
• An attacker compromising a clinical module's running process finds pseudonymous references, no identities. The blast radius is bounded by construction.

Limits and trade-offs

• Spoken names cannot be controlled at capture time. A doctor saying "Tere, Riin" at the bedside is captured in the recording's raw audio. The platform strips the spoken name via anonymisation before the transcript leaves the recording boundary, but until that step runs, the audio contains identity. The recording service's regime model carries the retention constraints for raw audio (speech-anonymisation.md).
• Outbound communications carry identity by definition. A discharge letter has a name on it; an invoice has an addressee. The membrane brokers these crossings and audits them; it does not pretend they don't happen.
• Physical containment is incomplete. The membrane controls what's on a screen and what flows over a wire. It does not control what's overheard in a shared-bay ward or what's seen on a printed handover sheet left on a trolley. Those are clinical-building-design and clinical-discipline problems the platform inherits, not amplifies.
• The membrane is one component. A failure or compromise of the MPI has wider blast radius than a failure of a clinical module. The platform's response is to keep the MPI's surface narrow, its code path simple, and its operations audited at a semantic level that detects anomalies fast.

Clinics sign in with the identity provider they already trust — national eID, hospital single sign-on — through certified connectors.

The promise

A clinic does not adopt a new identity system to adopt jengu. Its staff sign in the way their country and their hospital already decided people should sign in: national electronic identity, the hospital's own single sign-on, or another provider the customer organisation trusts. Jengu delegates the question "who is this person" to the authority the customer already answers it with.

Each kind of authority is reached through a connector that is certified by construction: a connector can only do what its narrow contract allows, its behaviour is proven against a stand-in authority that speaks the real protocol, and adding a new authority means adding a connector — never loosening the platform's own authentication.

Why this matters to a customer

Identity is where healthcare IT projects acquire risk: a second password is a second attack surface and a daily annoyance; a mis-integrated login is a breach. Delegation removes the second password, and certification-by-construction bounds the integration risk — the connector cannot exceed its contract even in error. For a buyer, the question "how does jengu handle our logins" has a short answer: with your provider, through a connector we can demonstrate.

What it does not promise

Jengu does not vouch for the identity provider itself — the strength of a national eID or a hospital directory is its operator's promise. And delegation covers sign-in, not authorisation: what a signed-in person may do remains governed by jengu's own roles and permissions, customer organisation by customer organisation, organisation by organisation.

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.

Why this matters

AI is not one product, it is many. Naming a speaker on a transcript is trivial work that has to come back in milliseconds. Drafting a discharge summary is heavy reasoning that takes seconds. Suggesting whether a mention of "MRI" is an actionable order is a near-real-time signal clinicians use during the conversation.

A platform that uses the same large model for every one of these tasks spends excessively, and is slow exactly where the clinician needs it fast. A platform that uses one small model for everything misses diagnoses-in-language that only a stronger model can pick up.

Equally, AI is not one provider. Different jurisdictions hold different views on which AI infrastructure their patient data may touch. A national healthcare system may require its AI to run on local hardware; a private group may prefer a hyperscaler under their existing data-processing agreement.

The right-sized AI pipeline is the platform's answer: each clinical AI job is named, classified, and routed to the model and provider that match its latency, cost, and regulatory profile. The choice is independent for every (zone, task kind) pair, and each task can carry its own helpers — code-system indexes, terminology lookups, retrieval over the organisation's templates — so the model is informed by the right structured knowledge for the work it is doing.

What's in the box

• Task kind as the unit of routing. Speaker labelling, summarisation, action detection, anonymisation, and free-text-to-clinical-resource conversion are the initial set of distinct named jobs. Adding a kind is how the platform takes on a new class of AI work without conflating it with existing ones.

• Per (zone, task kind) routing. Every zone × task kind pair maps to its own model and provider independently. Speaker labelling in one zone may run on a small local model while summarisation in the same zone runs on a hyperscaler; the same speaker labelling in another zone may use yet another provider. The matrix — not a single global model choice — is the configuration the platform follows.

• Bounded throughput per model. Heavy jobs — post-visit summaries above all — run on models with finite capacity. The platform caps how many of them run at once (a per-zone setting), so a burst of visits ending together can't overrun the model or starve the real-time work (action detection, role labelling) a clinician depends on mid-conversation. Excess heavy jobs wait in a queue and drain as capacity frees, rather than all hitting the model at once.

• Task helpers. A task kind may need more than a prompt and a model. Code-system lookups (so the AI's output resolves to a real ICD or SNOMED code rather than free text), terminology indexes, and retrieval over the organisation's own templates are configured per task kind and can be zone-specific — jurisdictions use different code systems and national catalogues. Helpers run alongside the model call so each module does not have to reimplement them.

• The zone declares what can be recognised. A terminology index only holds what a clinician could plausibly say. A jurisdiction's terminology directory carries much more than that — reference ontologies the knowledge base reasons over, administrative code lists bound by forms — and none of it is dictated aloud. The zone names the catalogues that belong to the spoken surface, and that declaration is configuration: a jurisdiction widens what its clinicians can be understood to have said without waiting for a release. An absent or broken declaration narrows the surface to a known-good set rather than opening it, because the alternative is offering a clinician's words to a model against material nobody speaks.

• Pre-filters save calls. Real-time tasks like action detection are guarded by a keyword catalogue; segments that have no plausible bookable item never reach the AI. Most chit-chat segments cost nothing.

• Constrained outputs. The platform asks each provider for a specific structured response, eliminating the "the model returned prose" failure mode that costs retries.

• Stable prompt prefixes. The fixed instructions sent to each provider are byte-identical across calls of the same kind, allowing modern providers to re-use cached interpretations and respond faster, cheaper.

• Providers as configuration. Adding a provider that follows a standard interface — most self-hosted local LLMs do — is a configuration change. Bespoke APIs need a one-time adapter; once it exists, every subsequent zone using the same provider is configuration only.

Standards we lean on

• GDPR Article 32 — security of processing. Provider choice is part of the security posture, not a hidden detail.
• HIPAA Business Associate Agreements — every AI provider that processes ePHI is under a BAA; routing constrains which providers any customer organisation's work touches.
• ISO/IEC 23894 — AI risk management framework; providers and tasks are classified consistently across jurisdictions.

What customers and operators experience

• A clinician during a visit sees real-time prompts (action detection, role labelling) come back almost instantly because they run on a fast model — while richer post-visit summaries arrive a few seconds later from the heavier model.
• A jurisdiction with strict data residency runs its sensitive AI work on local infrastructure; the same product elsewhere runs the same work on a cloud provider. The clinician's experience is identical.
• A finance lead can see how much each kind of AI work costs and retune routing in configuration — promoting more work to local models, demoting non-critical work to cheaper providers — without an engineering project.
• A clinician's first words after "hello" don't trigger an AI call at all: a fast keyword filter recognises chit-chat and skips the model entirely.
• An operator adding a new AI provider registers it once and lets zones opt in. Standard-interface providers can be added by configuration alone.

Limits and trade-offs

• Provider quality varies per task. When changing a provider for a given kind, accuracy must be re-validated for that kind — quality guarantees do not transfer.
• Switching providers mid-customer organisation requires planning: cached prompt prefixes do not move with the data, so the first hours after a switch run more slowly until the new provider warms up.
• The keyword catalogue needs upkeep. New procedures, treatments, and languages require keyword additions; the platform errs on the side of running the AI when in doubt, but un-tended catalogues drift toward over-running.
• A narrow recognition surface can be too narrow. Restricting the index to declared catalogues means a term nobody declared is a term the platform cannot recognise, however common it is in speech. The failure is silent — a missing catalogue looks like a model that simply did not hear the word. Widening is a config commit, but noticing that it is needed takes someone reading transcripts against what was proposed.
• AI quality is bounded by the underlying provider. Routing optimises which model handles each job; it does not improve any individual model's clinical accuracy.
• Heavy work queues under load. Because concurrent heavy jobs are capped to protect the model and the real-time path, a burst of post-visit summaries can wait briefly for a free slot. Summaries are deliberately the no-latency-budget kind, so they queue rather than slow down the real-time work — but the cap has to be sized to the model's capacity, or the wait grows under sustained load.

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.

Why this matters

A hospital cannot pause patient care because something outside its control fails. The internet goes down, the grid stutters, an internal network is damaged in a building incident, a supplier delays a part. A cloud-only platform makes the hospital hostage to every one of those dependencies — exactly the wrong stance for a clinical environment.

A purely on-premise platform pushes the opposite cost: the hospital's IT team operates everything — deployment, updates, integrations, cross-site dashboards — work most healthcare organisations would gladly outsource to a SaaS vendor.

The hybrid model resolves the contradiction by being principled about the split: the edge is sufficient for crisis operation; the cloud is better for everyday operation. Both teams work normally when both are healthy, and clinical work continues when only one of them is.

What's in the box

• Edge–cloud split. The edge runs what must keep working when disconnected: local clinical store, transcription, the modules its site uses. The cloud runs what benefits from being central: cross-site reporting, off-premise integrations, configuration, the heavier AI features.

• Self-contained edge. Each edge is sufficient on its own for the configured offline budget. It holds enough of the canonical record to keep clinical work flowing without contact to cloud.

• Edge data minimisation. Once a piece of data has been reconciled to cloud, the edge removes its local copy. A connected edge holds little; a long-disconnected edge holds more, then drains as soon as connectivity returns. The footprint adapts to the situation.

• On-premise integrations through the edge; off-premise through the cloud. The hospital's existing systems (LIS, instruments, identity providers) integrate with the edge over the local network. National registries, insurance partners, regulators integrate through cloud. The rule is determined by where the other system lives, not by what kind of system it is.

• Resilience extensions. Edges run on commodity hardware (small single-board computers, off-the-shelf, replaceable from any electronics distributor). They can fall back to ad-hoc networking (WiFi mesh, long-range radio) when structured networking is damaged, and to offline data carriers (signed patient-bound tokens) when no link exists at all.

• Declarative cloud-managed edges. Configuration, module selection, user provisioning, and software updates flow from cloud to edges over a managed channel. No edge requires manual configuration after enrolment.

• Per-edge audit. Each edge keeps its own audit log of every locally-taken action so audit survives an outage. When connectivity returns, edge audit events sync into the cloud audit trail and become part of the canonical record.

• Edge URL mirror. An edge is bound to one (customer organisation, organisation). It serves the same URL paths the cloud does — /o/{tenant}/{org}/{module}/{action} — so clinicians keep the same bookmarks across cloud and edge, switching seamlessly when one is unreachable. Requests naming any other (customer organisation, org) return a clean 404; the edge holds no data for them.

Practices we lean on

• GDPR Article 32 — security of processing. Resilience is named as 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/IEC 27001 Annex A.17 — business continuity. Redundancy and failover principles applied to clinical operation.

What customers and operators experience

• A hospital facing disruption beyond its control continues operating critical clinical work on its on-premise edges. On-premise integrations through the edge keep working; cloud-dependent features show a clear "offline mode" indication.
• A nurse on a tablet doing rounds gets sub-second response from the edge in the corridor — no round-trip to a distant cloud.
• A central administrator managing five sites works from one cloud console. Configuration changes, user management, module enablement flow from cloud to edges automatically.
• An off-premise system integrates with the platform once, through the cloud. Edges never speak to off-premise partners directly.
• An on-premise system integrates through the edge over the local network. Cloud is unaware.
• A clinician's everyday day is on the cloud UI: richer dashboards, search across the whole organisation, AI features that benefit from larger models. The edge is the safety net, not the daily driver.
• A new edge site is deployed by shipping hardware, connecting it to power and network, and letting it auto-enrol with cloud. No on-site engineer visit required for routine setup.

Limits and trade-offs

• Cloud-dependent features degrade when cloud is unreachable. Cross-site search, off-premise integrations, the heavier AI features. Clinicians see "offline mode"; the platform does not silently retry.
• Edge storage is bounded. Long-term retention happens in cloud. Edges hold the active working set; older records are visible only when reconnected.
• Extended outages enlarge the local footprint. Resilience during a crisis is worth a temporarily wider footprint, provided the edge minimises again on reconnect.
• Reconnection costs bandwidth. A long offline period produces a reconciliation backlog. Plan offline budgets to fit available bandwidth.
• Hardware lifecycle has a cost. Each edge is a physical device to procure, monitor, and eventually replace. The benefit is the resilience floor; the cost is the operational ceiling.

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.

Why this matters

A traditional EHR puts the patient's name, identifier, address, and date of birth on every clinical resource it stores. A doctor opens a chart and sees everything — name and DOB at the top, every observation, every visit, every prescription, all in one record marked with the patient's identity. Convenient for the workflow. Disastrous for a breach: any leak, however narrow, includes identity by default.

GDPR Article 4(5) describes a different architecture: identity readable only through a controlled, accountable gate. The clinical layer of our FHIR store carries no names, addresses, contact details, or national identifiers at all — identity lives in a separate Master Patient Index store that only the broker can reach, and the clinical patient record is a pure pseudonym carrying an opaque link key. Every other system — every module, every background worker, anyone with clinical-store access — sees a reference that resolves to nothing without the broker.

The benefit is not just defence-in-depth. The clinical layer is HIPAA Safe Harbor de-identified at rest — the 18 identifiers in 45 CFR 164.514(b)(2) are not readable in any clinical resource. For customer organisations under GDPR, the clinical layer is pseudonymised personal data under Article 4(5), which Article 32 names as a primary security-of-processing measure. The architectural choice produces those regulatory positions, not the other way around.

What's in the box

• Identity in a separate store. A patient's name, contact details, date of birth, and national identifier live on an identity record in a dedicated Master Patient Index store, reachable only by the broker. The clinical patient record carries none of it — only a pseudonym, an opaque link key, and minimal safe context (sex, birth month). One person may own several clinical pseudonyms, each unlinkable to the others except through the broker.

• Default-pseudonymised reads. A read of a clinical record returns the pseudonymous reference and its opaque link key — no identity. Identity is resolved only when the request explicitly asks for it with a purpose. Routine browsing of charts is identity-free without any special effort by the clinician.

• Purpose-bound reveal. When identity is genuinely needed (the doctor at point of care, the billing system generating an invoice, a legal release), the request states a structured purpose drawn from a defined taxonomy — clinical-care, billing-claim, release-of-information, legal-request, research-with-consent, emergency-care, audit-investigation. The taxonomy maps onto GDPR Article 6 and Article 9 lawful bases. Only the broker resolves the reveal, and only for the active session.

• Disclosure audit. Every reveal writes an audit record carrying the accessing user, the patient record reference, the stated purpose, and a timestamp. The accumulated log is the customer's evidence for HIPAA Accounting of Disclosures and GDPR Article 5(2) accountability.

• Search-by-name returns IDs. A query for "all patients named Smith" runs as native search inside the broker-only MPI store and returns a list of opaque references — just enough context to confirm the right person, no full demographics. Modules cannot reach the identity store, so mass exfiltration via search is structurally impossible.

• Master Patient Index semantics. The broker resolves a canonical identifier (national ID, passport) with a uniqueness constraint per (tenant, system, value). Two clinical records that resolve to the same canonical identifier resolve to the same person — including across edges when a patient is registered offline and later synced.

• Erasure by removing the identity record. A patient's right to erasure (GDPR Article 17) is honoured by deleting the identity record in the MPI store — the one place a pseudonym maps to a real human — without deleting the clinical records that retention law requires the customer organisation to keep. The pseudonymous reference remains but no longer resolves to anyone. (Patient-co-owned free text and audio the privacy boundary still holds are separately crypto-shredded.)

• Volatile edge identity. Edges hold no readable names on disk. Identity is resolved from cloud at point of care, held in volatile memory, evicted when the visit closes. Offline-captured patients use a temp identifier and merge to canonical on reconnect.

• Structural, not opt-in. A module that wants identity has to ask the broker, with a purpose — and even then receives only what the reveal grants. No module can reach the identity store, so the "oh I'll just join the Patient table" leak class is closed at the architecture level, not as a code-review concern.

Standards we lean on

• GDPR Articles 4(5), 5(1)(b)(c), 17, 25, 32 — pseudonymisation, purpose limitation, data minimisation, erasure, privacy by default, security of processing.
• HIPAA 45 CFR 164.514(b)(2) — Safe Harbor de-identification.
• HIPAA 45 CFR 164.502(b) and 164.528 — Minimum Necessary; Accounting of Disclosures.
• ISO 25237 — Pseudonymisation in healthcare. Separation principle and controlled re-identification path.

The detailed mapping — which requirement satisfies which article — lives with the requirements themselves.

What customers and operators experience

• A doctor opening a chart sees medical context first — chief complaint, history, current observations — labelled with an opaque reference. A clearly-marked "identify patient" action discloses the name in a session-scoped sidebar with a captured reason.
• A receptionist looking up a patient by name types the name and gets opaque references with just enough context (e.g., year of birth) to confirm the right person.
• A compliance officer can produce a complete log of every personal data disclosure for a customer organisation — who accessed which patient's identity, when, for what purpose.
• A patient asking "who has seen my data?" receives a precise answer: a list of disclosures with timestamps, accessing user, and purpose. Not "many people, in the normal course of care".
• A patient exercising the right to be forgotten has their identity record removed from the MPI store; their name can no longer be recovered, while the clinical record the customer organisation must retain survives as pseudonymous data.
• A platform operator with clinical-database access cannot read patient names — the clinical store carries none; identity lives in a separate store the operator's clinical access cannot reach. Bulk clinical-database access still does not tell whose data is whose.
• A research team running consented analytics gets a clinical dataset that's structurally Safe Harbor de-identified. The data is born pseudonymised.

Limits and trade-offs

• Free-text re-identification persists. A doctor writes "Mrs Smith was anxious" in a Procedure.note. Field-level encryption doesn't catch this — that's [Patient Data Anonymisation]'s job. The two layers compose.
• Quasi-identifier leakage is possible. A rare condition + admission date + customer organisation + sex + birth year can re-identify someone in a small population. Mitigation requires statistical safeguards or small-cohort access limits — complementary controls.
• Clinical workflow needs identity at point of care. The "identify patient" reveal is always available; the regulatory benefit is that the act is audited, not that it doesn't happen.
• External integrations need adapting. A module that pulls patient record resources expecting a readable Patient.name will see a pseudonym with no name. Broker reveal is available for legitimate clinical-care reads.
• The broker is the high-value target. Concentrating composition access in one audited service is the point — but it makes that service the thing to protect hardest. It runs in its own trust zone with its own key access, the tightest deployment controls, and an audit entry on every reveal.

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.

Why this matters

A SaaS vendor onboarding a hospital cannot answer "what exactly is configured for us, and how do we know?" with screenshots of an admin panel. Hospital compliance teams expect to review what the vendor is setting up before it goes live, and to see every change made afterwards — preferably in a form their own technical team can read directly.

Configuration through an admin UI alone has predictable failure modes: operators forget what they changed, manual setups drift between sites, and there is no peer review. In a regulated environment, "the configuration was right at some point" is not enough — the question is "who changed it, when, and why".

A git repository solves both at once: change goes through review like code, history is immutable, and the customer can audit their own configuration without depending on the vendor for a report. That same artefact is also what protects the customer if everything else is lost — a recovery anchor, not just a record.

What's in the box

• Git as the source of truth. Customer configuration — modules, practitioners, enrollment keys, integration bindings — lives as text in a git repository. The platform reads from it on startup and reconciles on change. There is no separate internal configuration store.

• Customer-owned repository. The repository typically lives on the customer's own GitHub (or equivalent) under their organisation. The platform connects with a read/write token the customer issues and can revoke at any time. Configuration sovereignty stays with the customer.

• FHIR as the configuration format. Practitioners, organisations, locations, healthcare services, and schedules are stored as FHIR resources in the repo — the same shape they take in the runtime data store. The customer's setup work produces a standard FHIR description of their hospital, reusable beyond this platform.

• Two pathways, one history. Routine changes go through the admin UI, which commits them back to git directly. Larger or higher-risk changes are drafted as pull requests against a staging branch, validated against a staging deployment, then merged. Both end up in the same history; no path bypasses it.

• Idempotent reconciliation. Re-running the platform against the repo converges to the repo's state. There is no separate "apply" step that could drift. The same property makes the repo a rebuild source: a freshly-deployed platform pointed at the repo restores the customer's operational configuration without any vendor-side state.

• Branch-per-environment. Production, staging, and zone-specific deployments each follow their own branch. Promoting a change from staging to production is a merge — exactly the change the customer reviewed and tested is what reaches production.

• Rollback by revert. A change that turned out wrong is rolled back like any code change: revert the merge, the platform reconciles. The rollback itself appears in the history as a commit anyone can read.

• Secrets out of git. Sensitive credentials live in the platform's secret store; the repo references them by name. A leaked repo never leaks live credentials.

• Recovery anchor. If runtime state, backups, and cloud infrastructure were all lost, the git repo alone is enough to bring the platform back into a known operational shape. The repo is the last resort for the system, not for patient records.

Practices we follow

• GitOps. Configuration as code, declarative reconciliation, pull-request review, audit through commit history. Standard cloud-native practice applied to customer organisation setup.
• HL7 FHIR Conformance resources — Practitioner, Organization, Location, service entries, Schedule. The same resources used for clinical reference are used for platform configuration.
• ISO/IEC 27001 change control. Reviewed change with full audit trail of who, what, when, why — git satisfies the standard's expectation directly.

What customers and operators experience

• A hospital onboarding sees its customer organisation configuration assembled as a git change — reviewed by the vendor's operations team, shared with the customer's compliance officer for sign-off, then merged.
• A compliance officer can clone the configuration repository and read, in plain text, exactly what is configured. No admin-UI access required for compliance questions.
• A customer's IT team sees the history of every change — who made it, when, and the diff. Disputes resolve to a commit.
• A vendor operator drafting a substantial change opens a pull request, gets review, merges. Routine changes go through the admin UI and still commit back to git.
• A non-trivial change is drafted in staging, tested in a staging environment that mirrors production, then merged. Configuration mistakes are caught before reaching the running ward.
• A change that turned out wrong is rolled back the same way any code change is — a git revert, a reconciliation, and the rollback itself a commit in the history.
• A CIO planning for worst-case can answer "what if everything else is lost?" with: as long as the configuration repo survives, the operational shell of the hospital is rebuildable.
• A regulator sees configuration as code with full version history — the same evidence model they already trust for software systems.

Limits and trade-offs

• Git is the source of truth, full stop. No shadow store inside the platform; the canonical answer is always the repo. The admin UI is a way to write to git, not a way around it.
• Customers without git skills need vendor support. A small hospital without a technical team will rely on the vendor to draft and review changes — the value is real but the access is not free.
• Staging discipline is required. The promotion model only protects production if changes are actually tested in staging. Emergency hot-fixes are flagged in audit; routine reliance erodes the workflow.
• Live operational state is not in the repo. Sessions, device liveness, queue depths belong in monitoring. The repo describes intent, not instantaneous state.
• Repo continuity is a customer responsibility when they own the repo. Backups, access control, and recovery sit with whoever owns it.
• Repo-based recovery is operational shell only. The shape of the system, not its clinical data. Clinical recovery still depends on data backups.

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.

The promise

A customer organisation's whole life is a set of governed transitions, not a sequence of console operations. Creation provisions everything a clinic needs — its sealed data space, its organisation tree, its encryption keys — atomically, from the reviewed configuration files that define it, with the first administrator invited by email rather than handed a shared password.

Suspension blocks new sign-ins and new writes but preserves every record and every audit line; reactivation restores access without anything having been lost, and a suspended clinic's staff see an honest "customer organisation suspended" message, not a broken login. Deletion begins with a thirty-day grace timer — cancellable back to suspension — and finishes with cryptographic erasure: the keys are destroyed, and with them every copy of the data, wherever it sits.

The transitions themselves are durable: a platform restart mid-workflow resumes rather than corrupts. Each one reaches the clinic's on-site equipment — suspend quiets the edges, delete revokes their credentials — and each is recorded twice, in the platform operator's trail and in the organisation's own.

Why this matters to a customer

Onboarding, offboarding and emergencies are where multi-customer platforms show their real discipline. Here a customer can verify all three: joining is a reviewed change with a paper trail, leaving ends in erasure that backups cannot undo, and a payment dispute or incident can pause a clinic without destroying anything. The dual audit trail means neither party depends on the other's record of what happened.

What it does not promise

The grace period is a protection, not a loophole: during it the data is preserved but the clinic stays suspended. And erasure by key destruction is final by design — once the timer runs out, no party, jengu included, can bring the data back.

Recordings exist only under consent, sealed at rest, and opened only by a deliberate, audited act.

The promise

A recording is the most sensitive artefact jengu handles, and the platform treats its entire life accordingly. Nothing records without the consent gate; pausing genuinely excludes the paused audio rather than editing it out later. Who is speaking is supplied by the recording client — the platform never infers a speaker's identity from their voice, because voice is biometric data and guessing identities from it is a line jengu does not cross.

At rest, recordings are encrypted with the organisation's own keys, each file carrying a self-describing sealed envelope — a copied file is a sealed file. Downstream features receive only the anonymised transcript, a wall enforced by the platform's type system rather than by convention; reading the raw audio or raw transcript requires an explicit request that names the requester, the reason and the target, and is audited as such. Retention is short by design, and the same deletion discipline applies on the clinic's own equipment as in the cloud.

Why this matters to a customer

Consultation audio is the recording of a doctor and a patient at their most candid. A clinic offering recording must be able to tell its patients — and its regulator — exactly who can hear it, when, and why: here the answer is "almost no one, briefly, deliberately, and on the record." The no-voice-identification stance also means the recording feature cannot quietly become a biometric system.

What it does not promise

Sealed storage protects the recording, not the room — a phone on the desk is outside any platform's reach, which is why consent remains a human act the recording gate enforces rather than replaces. And the anonymised transcript that outlives the audio is governed by its own retention and consent rules, not by this service's.

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.

Why this matters

Healthcare data is the most sensitive thing a hospital holds, and the sessions through which clinicians reach that data are the narrowest gate where identity becomes access. A weak session model — silent renewal, ambiguous logout, "shared" workstations, unauditable device hand-offs — undoes every isolation guarantee the rest of the platform provides. A regulator asking "who was logged in when this record was read?" deserves a precise answer, not an inference.

A modern healthcare workflow also no longer lives on one screen. A clinician moves between a desktop in the consult room, a tablet on rounds, and a mobile companion app in the corridor. Each device is its own attack surface; pretending they're the same session by sharing a password is the failure mode hospitals already see. The platform's answer is a single owned session, extended to additional devices through a deliberate, auditable pairing, with a single sign-out that ends every device's inheritance simultaneously.

The strategic value: clinicians stay in flow across devices without the platform losing track of who is acting; the audit trail names the session every action belongs to; and a lost device or terminated employee is one sign-out away from being sealed out everywhere.

What's in the box

• Sign-in establishes a session. A successful sign-in mints a session bound to exactly one user, one customer organisation, and one identity. The session carries no clinical data — only a verifier the user agent presents on every subsequent request. The boundary is set the moment the session begins.

• Sign-out is a real action. Signing out invalidates the session immediately on the server side, clears the device-side session credential, and produces an audit event recording who signed out and when. The next request from the same browser starts unauthenticated. There is no quiet session extension on the way out.

• Sessions are time-bounded. Every session has a defined maximum lifetime, enforced regardless of activity. After expiry the next request returns to the sign-in page, and the expiry itself is an audit event — the trail distinguishes user-initiated sign-out from a session that simply ran out.

• One user, one customer organisation per session. A user choosing to work with a different customer organisation gets a fresh session. The platform never issues a token that authorises both customer organisations at once; impersonation between customers is structurally impossible at the session layer.

• Suspended customer organisations reject sign-in cleanly. A user trying to sign in to a paused customer organisation sees a distinct "this organisation is paused" message — not the deliberately-vague invalid-credentials fallback. Operators can tell "wrong password" from "customer organisation suspended" without contacting support.

• Audit covers every transition. Sign-in success, sign-in failure, sign-out, expiry — and (when device binding lands) device-pair and device-revoke — each is a regulator-readable audit event in the affected customer organisation's trail. A regulator asking "who logged in to this customer organisation in the last 30 days" gets a precise answer.

• Device binding extends the session to a known device. (Planned.) A clinician's mobile or tablet companion app authenticates once against the user's active session and inherits its identity and organisation context. The pairing produces an audit event naming the device. The bound session follows the same lifecycle as the originating session — sign-out propagates, expiry propagates — and the user can revoke a single device without ending the whole session.

Standards we lean on

• GDPR Article 32 — security of processing. Session security is part of the technical safeguards regulators expect.
• HIPAA 45 CFR 164.312(a)(2)(iii) — automatic logoff. The session-expiry property is the platform's answer to this technical safeguard.
• HIPAA 45 CFR 164.312(b) — audit controls; every session transition is captured.
• OAuth 2.0 (RFC 6749) and OIDC — session-establishment patterns the platform builds on rather than reinvents.
• NIST SP 800-63B — digital identity guidelines for session management.

What customers and operators experience

• A clinician signing in is bound to their organisation for the duration of their session. The session lasts long enough for a working day but no longer; re-authentication is part of the rhythm, not an interruption to apologise for.
• A clinician signing out can verify the session is gone — the next page-load is the sign-in screen, the audit trail records the sign-out, and any device paired to that session loses its access at the same moment.
• A clinician on a tablet (future) pairs the tablet to their active session once; subsequent rounds use the tablet without a second password. Sign-out from desktop ends the tablet session immediately, with a clear message rather than a silent failure.
• A clinician with the wrong password sees an invalid-credentials message that doesn't disclose whether the username or customer organisation exists. A clinician hitting a paused customer organisation sees the distinct "organisation paused" message instead.
• A regulator auditing sign-ins for a customer organisation runs a vanilla FHIR query against the audit trail (audit record by type code, by date) and gets the full who-when-where record.
• A platform admin investigating a session anomaly can see the same trail, scoped to the customer organisation in question, without any privileged read path.

Limits and trade-offs

• No silent session extension. Sessions don't quietly renew on activity past the absolute lifetime; the user signs in again. Convenience would be invisible erosion of the audit-trail integrity the rest of the platform depends on.

• One session per user-customer organisation pair. Concurrent multi-customer work means two browser sessions side-by-side, not one token authorising both. Annoying for users with several organisations; non-negotiable for the boundary.

• Idle vs. absolute timeout — both apply. Whichever fires first ends the session. The platform errs toward the shorter of the two.

• Device binding inherits the user's session lifecycle. (When it lands.) A device cannot outlive the session it's bound to. Hospitals that want device-only access for long-running displays will need a separate provisioning path (out of scope today).

• A rotated signing key drains; it does not cut — but only within its window. Rotating the key that signs sessions keeps the outgoing key for verification, so sessions issued before the rotation run out their own clock instead of dropping at once. Retire the outgoing key sooner than the session lifetime and those sessions end immediately. That is a deliberate operator choice, and the only way to end every session at once on purpose.

• Session credentials are device-side. The platform cannot revoke a stolen device's local credential after network loss; the credential's expiry is the bound on damage. This is the reason for short maximum lifetimes.

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.

The promise

The operations jengu's own operators perform — creating and suspending customer organisations, granting roles, reading a customer organisation's configuration and API description — are not console clicks or database edits. They are calls on a documented management API, gated by the operator's own authenticated identity, with every action audited like any other actor's.

Role administration carries its guardrails in the API itself: what a role may grant is computed, not remembered, and a grant that would exceed the granter's own authority is refused by the door rather than caught by review. Each customer organisation's API surface is described by a machine- readable document generated from what is actually enabled for that customer organisation — the description cannot promise a door the customer organisation does not have.

Why this matters to a customer

An operations surface that is an API is an operations surface that can be inspected, automated and audited. It also bounds jengu's own power visibly: the operator walks through a door with a defined shape, not through the back of the database — which is the posture a healthcare customer should demand of its platform vendor. And the same door, with deliberately narrowed authority, is what a future distribution partner receives: able to pause a customer organisation it manages, never able to remove one.

What it does not promise

The management API governs the platform's operational objects — it has no path to clinical content, which stays behind customer organisation isolation and the operator-cannot-read-clinical guarantee. Narrower actor doors (partner, reseller) inherit its shape but not its scope; each is its own capability with its own, smaller contract.

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.

Why this matters

Clinical conversation transcripts and notes contain the most sensitive information a healthcare organisation handles: patient names, nationally-issued identifiers, phone numbers, addresses, family details, and circumstantial identifiers like "the patient who came in last Tuesday from a small village near Tartu". Every additional system that sees this text widens the blast radius of any future leak.

Sending raw clinical text to an AI provider — even one with strict contractual data-handling — moves personal data outside the organisation's direct control. Storing raw text alongside everything else turns every analytic, every export, every backup into a patient-identification risk.

Anonymisation says: the systems that don't need patient identity should not see it. Names become placeholders. ID numbers become tokens. The text retains its clinical meaning — what was said, in what order, by whom — but loses the part that identifies the individual. Done immediately and uniformly, anonymisation reduces the regulatory load of every downstream feature to almost nothing.

This is the narrative layer of pseudonymisation. The structural layer (Identity Pseudonymization) keeps identity fields out of clinical resources entirely; this layer scrubs the free text where clinicians wrote names anyway. Together they cover the full patient data surface.

What's in the box

• Two-pass pipeline. A deterministic pattern pass catches structured personal data (national ID format, phone, email) with near-perfect recall. A second classifier pass catches names, free-text addresses, and contextual identifiers a regex cannot reasonably match. Both passes are deterministic and run in-zone; raw clinical text is not sent to a generative model.

• Stable placeholders preserve meaning. The same name becomes the same placeholder throughout a transcript, so coreference ("the patient said... she also reported...") survives anonymisation.

• Sealed raw boundary. Downstream features cannot receive raw text by accident — the platform only hands them the anonymised version. Receiving raw text is an explicit, audited decision.

• Per-zone patterns. Each jurisdiction's distinctive personal-data formats (Estonian isikukood, Finnish henkilötunnus, French NIR, German Krankenversicherungsnummer, Spanish DNI/NIE) are recognised by zone-specific rules. A new jurisdiction adds patterns without changing the core.

• Original kept, not destroyed. Raw transcripts persist in the service that captured them, behind tightened access controls. Anonymisation is forward-only; the raw text is the source of truth, the anonymised text is what flows.

• Realtime by design. Anonymisation runs inline with transcription so downstream features can react during the encounter. The pipeline has no human-in-the-loop review step; the realtime use cases the platform supports do not allow for one.

• Misses are incidents, not edits. A failed redaction cannot be caught by a human reviewer before it reaches downstream features. Any observed leak of personal data into anonymised output is treated as a security incident — investigated, recorded, and used to harden the rules. The improvement loop is the quality control; there is no quality gate before it.

Standards we lean on

• GDPR Article 4(5) — pseudonymisation as defined treatment of personal data.
• HIPAA 45 CFR 164.514(b)(1)–(2) — Expert Determination and Safe Harbor as the de-identification bars anonymised output must clear.
• ISO 25237 — Pseudonymisation in healthcare. Methods, controlled re-identification path.

What customers and operators experience

• A clinician dictating a note about a patient sees their AI assistant perform the same task it always did — without that AI ever having received the patient's name, ID, or contact details.
• A compliance officer can demonstrate to the regulator that the AI provider never received personal data, by reviewing the anonymisation policy and the audit log of every raw access.
• A patient asking "what data did your AI see about me?" receives a precise answer: a list of placeholder labels, never their actual name, ID, or phone.
• A research team running consented analytics works against an anonymised stream from day one — not a re-engineered pipeline that strips data after the fact.
• A platform operator investigating a clinical issue can request raw access through the audited path; the request is logged with the reason, the operator's identity, and a timestamp.

Limits and trade-offs

• Anonymisation is a layer, not a guarantee. A small village plus an unusual condition can re-identify a patient even after every named field is replaced. For high-stakes use (publication, public research), human review remains the final safety net.
• The platform errs on the side of over-redacting. A too-aggressive pattern is acceptable; a missed name is not. Reviewers occasionally see common words flagged when context makes them ambiguous.
• Audio is not anonymised. Voice itself is biometric and carries identity. Audio is protected through retention and access controls, not replacement.
• Re-identification by combining datasets is outside the platform's reach. If an attacker has access to other systems with identifiable data, they can correlate.
• Quality is bounded by transcription. Anonymisation works on the text the transcriber produces; speech the transcriber misses cannot be redacted.

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.

Why this matters

A hospital's data is written over years by many versions of the same platform. Systems that never planned for this end up in one of two bad places: records nobody dares touch because "the old module wrote those", or big-bang migration weekends where the system is down until the last record is converted.

Both are unacceptable in clinical operations. A ward cannot pause because the vendor released an update, and a clinician cannot be told that last year's orders display incorrectly because they predate a format change. At the same time, refusing to ever change data structures means the platform ossifies — every improvement bolted around the old shape instead of into it.

The resolution is to treat data structure change as a routine, governed activity: every record knows what shape it was written in, every shape change ships with the recipe to bring old records forward, and the platform updates its own data — mostly in the background, while the hospital keeps working.

What's in the box

• Every record knows its shape. Each stored record is validated against a published, versioned structure definition and carries the version it was written under. "What shape is this data in?" is a query, never an investigation.

• Shape changes ship with their recipe. A structure change is released together with the converter that upgrades existing records — declared in the standard FHIR mapping form, tested against real samples of the old shape in every build. The build fails if a shape changes without a version bump, or a breaking change ships without its converter. The discipline is enforced by machinery, not memory.

• Updates ahead of time, not downtime. For a planned breaking change, the new shape is announced one release before the software starts relying on it. Stored data converges to the new shape quietly in the background while the hospital runs on the current one; when the follow-up release flips over, the work is already done.

• A short, honest maintenance moment when it can't be avoided. Some changes genuinely conflict with running the old software on the data. After such an update, a customer organisation is held in maintenance — visibly, per customer organisation — only long enough to update its configuration and its active records: open orders, visits in progress. Years of history update afterwards, in the background, without anyone waiting on them.

• Configuration updates arrive as reviewed git changes. For configuration data, the upgrade is written into the organisation's configuration repository as an audited commit — the same reviewed, promotable path every configuration change takes — and applied to the runtime store the normal way. Operational records are updated in place, each one carrying a provenance record of what converted it, when, and from what.

• Old integrations keep working. A device driver or partner system still sending the previous shape is accepted at the door and converted on arrival, within a published support window. The hospital upgrades integrations on its own schedule, not the vendor's.

• The platform refuses to guess. If a rollback or a skipped update would make the software older than the data it faces, the customer organisation stays in maintenance with a clear diagnosis. Silent misreading of clinical data is not a failure mode on offer.

Practices we follow

• HL7 FHIR conformance machinery — StructureDefinition versions, version-specific canonical citations, and StructureMap / FHIR Mapping Language as the declarative converter form. The versioning grain and the conversion language are the standard's, not ours.
• Expand/contract (parallel change) — the industry pattern for zero-downtime schema evolution, applied to FHIR shapes: announce, converge, flip.
• GitOps — configuration data migrates through the same reviewed, audited, promotable git path as every other configuration change.

What customers and operators experience

• A ward during a routine update notices nothing: the update lands, data converges in the background, dashboards and histories keep rendering.
• A customer organisation after a breaking update sees a brief, explicit maintenance state — "your system is updating" — measured by its open workload, not by the size of its archive.
• A compliance officer can trace any record's history of shape changes: what converted it, when, from which version, under which release.
• A hospital's IT team reviewing the configuration repository sees structure upgrades as commits — diffable, revertable, promoted from staging to production like any other change.
• An integration partner on last year's interface keeps sending the shape they built against; the platform converts at the door and publishes how long that window lasts.
• An operator watching a fleet update sees per organisation migration progress; a customer organisation that is stuck is a visible fact, not a silent one.

Limits and trade-offs

• Breaking changes take two releases. The zero-downtime path trades calendar time for uptime: announce first, flip second. A change that must land in one release buys that speed with a maintenance moment.
• Not every change can be made seamless. A change that removes information cannot be converted back and forth losslessly; those take the maintenance path, and the release notes say so.
• The support window for old shapes is finite and published. Integrations older than the window are refused with a clear message, not silently accepted.
• Immutable evidence is left alone. Audit trails and wire-level traces are never rewritten to a new shape — their evidentiary value depends on it. They are converted on read if ever consumed.
• Fleets are briefly heterogeneous. After a release, customer organisations finish their background convergence at different times. The per organisation gate makes this safe; the ops surface makes it visible.

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.

Why this matters

Inpatient rounds are one of the highest-volume clinical documentation activities in a hospital. A nurse on a ward of twenty patients makes observations on every patient several times per shift — vital signs, mobility, pain scores, mental status, fluid balance, medication response. Documenting all of them in a desktop EHR pulls the nurse out of patient contact for tens of minutes per shift; documenting them on a tablet at the bedside helps but still demands typing while observing.

A spoken-dictation workflow, captured by a tablet that knows which bed the nurse is at, fits the actual rhythm of rounds. The nurse walks, observes, speaks the observation, moves to the next bed. The platform handles the structure: which patient, which observation type, what value. The nurse's hands and eyes are with the patient.

The strategic value: nursing time at the bedside increases, documentation completeness improves, and observations are captured at the moment they happened rather than reconstructed at end-of-shift.

What's in the box

• Patient context per bed. Each bed in the ward has an identifier (FHIR Location resource) the nurse's tablet recognises (NFC tag, QR scan, or bed-list selection). Selecting the bed sets the patient context for all subsequent recording in that location.

• Speaker is the logged-in nurse. The recording service receives speaker identity from the tablet's login session. Diarisation is not attempted; the nurse is the only identified speaker.

• Structured vital-sign recognition. A nurse-tuned AI task recognises common vital-sign formats ("BP 124 over 78", "pulse 72") and produces FHIR Observation resources with the right LOINC code, value, and unit per zone.

• Narrative content remains as a note. Observations that don't map to a structured vital ("patient seems more alert than yesterday") become clinical-note entries on the encounter.

• Cross-zone vital-sign codes. The structured recognition uses the zone's preferred coding; an Estonian rounds tablet uses the zone-ee codes, a German one the zone-de codes (when delivered).

• Edge-resilient. Rounds happen at the edge by default; the recording, structuring, and FHIR write all run edge-side. Cloud reconciliation is not on the rounds critical path.

Standards we lean on

• HL7 FHIR R4 Observation and Location — the standard shapes for vitals and bed identifiers.
• LOINC — terminology for the structured vital-sign codes.
• HIPAA 45 CFR 164.312(a)(1) — access control on bedside documentation devices.

What customers and operators experience

• A nurse on rounds carries a tablet that recognises the bed they are at. The patient context is set when they arrive.
• The nurse dictates observations: "blood pressure 124 over 78, pulse 72, fluid balance positive 200 ml since morning, pain score 3, no new mobility issues". The recording captures the speech.
• The platform structures the observation. Recognised vital signs become FHIR Observation resources on the patient's record; narrative content becomes a clinical note linked to the encounter.
• The nurse moves to the next bed. Patient context switches; the previous patient's observations are finalised; the new patient's recording starts.
• A doctor doing morning ward review sees the nurse's observations from the night shift on each patient's timeline, time-stamped, attributed to the nurse who took them.
• A nurse reviewing their work at end-of-shift sees a list of the observations they recorded across the shift.

Limits and trade-offs

• Patient-context selection must happen. A nurse who dictates without selecting the bed first produces a speaker-unknown-patient recording. The platform surfaces this as an error to be resolved before the observation enters the record.
• Vital-sign recognition is bounded. Common formats are recognised; unusual phrasings fall back to free-text notes. The platform errs toward not-fabricating-structure rather than confidently mis-structuring.
• Background ward noise affects quality. Inpatient ward acoustics are not ideal; transcription quality is bounded by the device microphone and the ambient noise level.
• Multi-nurse rounds need single-tablet ownership. Two nurses on different tablets work fine; two nurses sharing one tablet need each to log in before their dictation.

Related features

• Visit recording with audited consent — the same recording mechanism applied to a different context.
• Smart action detection — observations that warrant action (concerning vitals, medication overdue, abnormal pain trend) surface as actions for follow-up.
• Platform: Secure recording service — the substrate underneath rounds capture.
• Platform: Hybrid edge–cloud operation — rounds happen at the edge by default.
• Platform: Organizational structure — rounds are scoped to the inpatient ward (organisation) the nurse works in.

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.

Why this matters

Healthcare regulators do not accept "we believe nothing went wrong". They expect proof: who accessed which patient's record, when, from where, under what authorisation. Disputes — between a patient and a provider, between a provider and a payer, between a vendor and a regulator — almost always resolve to "show me the timeline".

A platform without a built-in audit trail forces every customer to build their own from log files, knowing those files were not designed for compliance use. A platform with audit as a crosscutting feature delivers the same evidence to every customer in the same shape, with no extra integration.

The strategic value is not just "we log things". Every clinical operation across every module, every login, every administrative change, every lifecycle transition produces audit records in the same format and the same place. Compliance review becomes one query rather than a dozen log searches.

What's in the box

• Same store as records. Audit events live in the same data store as the records they describe, inside the same customer organisation boundary. There is no separate audit silo to reconcile or query separately.

• One format, everywhere. Every audit event is a FHIR audit record resource — same shape regardless of which module or layer produced it. A single query pulls the full timeline for a patient, an operator, a customer organisation.

• Cross-cutting, not per-module. Audit is provided by the platform; modules emit events through one shared channel. Routing, formatting, and persistence are not each module's problem.

• Edge-first, sync-later. Each edge produces audit events for every locally-taken action — online or offline — and forwards them to cloud as part of the normal reconciliation flow. Audit continuity does not depend on connectivity.

• Source attribution and time-of-event ordering. Each event carries the system that produced it (cloud, or a specific edge) and two timestamps — when it happened, and when the cloud first saw it. Investigators filtering by source see one edge's events in isolation; ordering is by when-it-happened, so a delayed sync from a previously-offline edge slots into the timeline at the moment the action took place, not at the moment cloud received the record.

• Dual-logged lifecycle. Affecting a whole organisation events are written to both the platform's own trail (operator oversight) and the affected customer organisation's trail (customer's own history). The customer always has the full record of their own data.

• Queryable like any clinical resource. Audit events participate in the same query, retention, and authorisation model as records, so customers can build their own views over them.

• Categories audited today. Clinical record access (read, write, update); authentication events (login, logout, failures); administrative actions (user creation, permission change, module enablement); lifecycle events (customer organisation created, suspended, edge enrolled, retired); raw transcript access (with reason); AI processing (task, input by reference, provider, outcome).

Standards we lean on

• HIPAA 45 CFR 164.312(b) — audit controls.
• GDPR Articles 5(2) and 30 — accountability; records of processing activities.
• ISO/IEC 27001 Annex A.12.4 — logging and monitoring.
• HL7 FHIR audit record — the standard shape every event takes.

The detailed mapping — which requirement satisfies which article — lives with the requirements themselves.

What customers and operators experience

• A regulator auditing the platform is shown a per-patient timeline assembled from one queryable source: every access to that patient's record, by whom, from where, when.
• A compliance officer can answer "did anyone access patient X's records on date Y" in seconds, without hunting across log files.
• A clinician investigating "who else has touched this record" sees the access history alongside the record itself.
• A patient exercising their right to see access logs gets a consistent answer regardless of which module recorded their data.
• An insurer investigating a claim can be served from the same trail through the customer's normal disclosure process. The platform does not need a separate "insurance investigation" feature; the same evidence base answers regulator, patient, and payer questions.
• A platform operator can demonstrate that operational tooling did not access customer organisation clinical content. The audit trail draws the boundary.
• A compliance officer reviewing a specific clinical site filters the audit trail to that site's edge — not by reading every cloud- originated event in sequence, but by picking the edge from a source filter. The resulting view is the timeline of activity at that physical location, sorted by when activities took place, even when some events synced to cloud hours after the fact.
• A finance lead can see usage patterns: which modules are most active, which AI tasks generate the most cost, which sites produce the most clinical activity.

Limits and trade-offs

• Audit volume is high. Every clinical action emits an event. Long-term storage budget is non-trivial; retention policy is set per zone, balancing regulatory minimums against cost.
• Audit is an honest record, not a cryptographic one. A malicious actor with full database access could in theory alter the history. Mitigation is separation of duties and external write-once archiving for the most sensitive trails — not a hard cryptographic guarantee.
• Signal-to-noise matters. "Who accessed what" is most useful when not drowned in noise. Operational reads by the system itself are marked so investigations can filter them out without missing human accesses.
• Audit trails are bounded by what is observed. The platform records actions through itself. External integrations carry their own audit; the platform's record stops at the integration boundary.

Clinical work flows across modules as durable processes — results find the clinician who asked, and nothing is lost between the seams.

The promise

A visit that orders a lab test, a result that must reach the ward that asked for it — clinical work routinely crosses module boundaries, and those crossings are where systems traditionally drop things. Here the modules never talk to each other directly: work travels over the platform's event spine and through shared clinical records, so there is exactly one kind of seam, and it is a governed one.

Results follow the clinician, not the module — whoever ordered receives the answer in their own notification stream, wherever in jengu they happen to be working. Events are never silently lost: a subscriber's failure is a visible condition, not a swallowed message. The processes themselves are defined in code and projected everywhere else — documentation, running work items, integrations all derive from one definition — and each running step links back to the definition it instantiates. A disabled module simply ignores events for its domain; toggling modules cannot make work bleed across the boundary.

Every cross-module step is audited, so the entire journey — order, dispatch, result, notification — reconstructs from the audit trail alone.

Why this matters to a customer

The dangerous failures in clinical IT are the quiet ones at hand-off points: the result that arrived in a module nobody was watching. A single governed spine with no silent loss and clinician-following results is the structural answer, and audit-reconstructable journeys mean an incident review takes hours of reading, not weeks of forensic guesswork.

What it does not promise

The spine carries clinical work between modules; it is not an external integration channel — other systems connect through the platform's doors, which put every crossing through consent, isolation and audit. And durability is about the process, not the clock: work survives restarts and failures, but clinical urgency is still governed by each module's own escalation rules.

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.

Why this matters

A hospital is not flat. It has wards, clinics, departments, satellite sites, outpatient units, training units — each with different staff, different module needs, different operational rhythms. A platform that treats the customer organisation as a single undifferentiated unit forces all of that variety into one bucket: every clinician sees every module, every worklist, every menu item. That's not how clinical work happens; it's how clinicians abandon software.

The opposite extreme — one customer organisation per department — fragments the patient. A patient seen in cardiology and nephrology lives in two customer organisations? The patient timeline is split, the audit trail is split, the clinical record is split. The customer boundary, designed to protect the customer, becomes an obstacle to the customer's own care continuity.

The right model is one customer organisation per customer with organizational sub-structure inside. Departments, sites, and units are first-class within the customer organisation; clinical modules bind to the organisations that use them; the patient timeline crosses departments seamlessly because they are all in one customer organisation.

What's in the box

• One customer organisation is one customer. One customer, one boundary; that's the boundary documented elsewhere as Customer Data Isolation.

• Org tree inside the customer organisation. Each department, site, or unit is a FHIR organisation record resource with partOf pointing at its parent (the hospital, or another department). Tree depth is up to the customer.

• Modules bind to organisations, not to the customer organisation. Hogwarts Laboratory has the Lab module; Outpatient clinic has Visit Assistant; Cardiology has both. Module assignment is per-(org, module).

• Menu reflects (user, organisation, module). When a clinician selects an organizational context, the platform's web shell filters navigation to that organisation's enabled modules. Modules contribute their navigation; the platform composes it.

• Permissions combine four facets. Authorisation asks: this clinician, in this organisation, for this module, performing this action — granted or denied? Roles are organisation-level; the combination with (organisation, module, action) is what's checked at runtime.

• One module, many bindings. The Lab module exists once in the codebase; it appears under Laboratory, Cardiology, and Emergency in the menu — the same module, three contexts. Module-internal logic uses the organizational context to scope worklists, ordering destinations, and result delivery.

• URL structure carries the org segment. Every module-bearing URL has the shape /o/{tenant}/{org}/{module}/{action}. The customer organisation admin assigns each Organization a unique code when the org tree is defined; that code is what appears in URLs and in bookmarks. The org segment is mandatory — URLs that omit it are redirected to the organisation's root organisation.

• Audit captures organizational context. Every audit event records which organisation the action happened in, so retrospective queries can be scoped per department.

Standards we lean on

• HL7 FHIR organisation record resource with partOf — the standard shape for the tree.
• HIPAA 45 CFR 164.308(a)(3) — Workforce Security. Role-based access matched to organizational structure.
• ISO/IEC 27001 Annex A.6 / A.9 — access control. Permissions combined from organizational role and resource context.

What customers and operators experience

• A hospital admin onboarding defines the org tree: Hogwarts Hospital → Laboratory department, Outpatient clinic, Cardiology ward, Emergency department — declared in the configuration repo as FHIR organisation record resources.
• Each organisation gets the modules it uses. Module enablement is a configuration decision per-(org, module).
• A clinician's menu reflects the structure. Working in Cardiology, they see "Cardiology > Lab > Pending orders" and "Cardiology > Visits > Today's appointments". Switching context changes the menu — same login, same customer organisation, different scope — and the URL bar reflects the change too: moving from the main lab to a satellite lab swaps /main-lab/ for /satellite-lab/ in every module link.
• A patient seen in Cardiology and Outpatient appears in one chronological timeline. The org context tells where each encounter happened; the timeline crosses departments because they share the customer organisation.
• A new department added is a configuration change — declare the Organization, list its modules, set its staff. The platform applies the change without any module-side installation.
• A department reorganised (renamed, merged, moved under a new parent) is a configuration change too — history persists, audit persists, only the tree shape changes.
• A compliance officer reviewing access sees the full (clinician, organisation, module, action) tuple in audit. "Who in Cardiology placed lab orders this month" is one query.

Limits and trade-offs

• One organizational tree per customer organisation. A multi-organisation network is modelled as several customer organisations if data must stay separate, or as one customer organisation with multiple top-level organisations if it doesn't.
• Module enablement is per-organisation, not per-clinician. A clinician's view of available modules is determined by the organisation they are working in, not by personal preferences. This keeps clinical context predictable.
• Org-tree changes propagate immediately. Removing a department's module access takes effect on next request. Audit of past actions persists; new actions don't.
• Reshuffles cost configuration review. A department merge or rename is a configuration change in git, reviewed before merge. The customer cannot do this in a hurry; that's deliberate.
• Cross-organisation sharing within a customer organisation is governed by organisation-level rules. Whether cardiology can read outpatient's notes is a customer organisation policy, not a per-organisation setting.

Data is used only for what was consented to — one switch, one catalogue, and withdrawal that stops everything at once.

The promise

Where customer organisation data serves any purpose beyond care itself — service improvement, statistics, research — that use is governed by one explicit consent, given against a versioned catalogue that says precisely what would be extracted and why. A new kind of extraction is a new catalogue version, and a new version requires consent again; nothing rides in on an old yes.

Withdrawal is immediate and total: every extractor stops. Catalogue changes are announced before they take effect, and the catalogue's history stays queryable, so a customer can always answer "what did we agree to, and when." What leaves is never raw identifying content — extractor output is anonymised, aggregated or pseudonymised. And no person at jengu sits behind this: extractors run as workload identities, and vendor staff have no direct query path into customer organisation data at all.

Why this matters to a customer

"We may use your data to improve our services" is the sentence healthcare buyers have learned to fear, because it usually means an unbounded grant exercised by unseen people. This capability replaces the sentence with a mechanism: a catalogue you can read, a version you consented to, a switch you can flip, and a structural guarantee that no human at the vendor can browse your data regardless. Consent becomes something a DPO can verify rather than something a contract implies.

What it does not promise

This governs secondary use, not care: clinical features working on a patient's own data for that patient's own treatment are governed by medical consent, not this switch. And withdrawal stops extraction from the moment it is flipped — insights already lawfully derived and anonymised before withdrawal are not retroactively unmade.

Every module answers to one governance: who may do what, where, under which rules — decided once, enforced everywhere.

The promise

Adding a clinical module to jengu never adds a second way of deciding who may do what. Zones, roles, permissions, audit, module enablement and data sharing are platform concerns that every module consumes and none may reimplement — there is no module-private copy of any of these to drift out of line.

Roles are declared in the organisation's reviewed configuration files, not clicked together in an admin screen, and a role change reaches every module within the same session. Disabling a module blocks new actions but preserves everything it ever did — audit history and timeline content stay. And when work crosses modules, the audit trail crosses with it: every step of a cross-module workflow is captured, so an investigator reconstructs the whole chain from the trail alone.

Why this matters to a customer

Governance that lives per-module is governance that diverges — one module's idea of a "doctor" quietly stops matching another's, and an auditor finds five permission systems where the policy described one. Single governance means a clinic's rules are written once, reviewed once, and true everywhere; a compliance answer given for the platform is an answer for every module on it, including the ones added next year.

What it does not promise

One governance does not mean one behaviour — modules still decide what their own features do; they simply may not decide who is allowed to do it. And preserved history is preservation, not availability: a disabled module's records remain and remain auditable, but its functions are genuinely off.

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.

Why this matters

Patient care is a continuum, not a series of module silos. A clinician opening a patient's record needs to see what happened across every module — lab orders and results, visits, notes, prescriptions, audit events — woven into one timeline. A platform that gives each module its own database forces the clinician to context-switch between views and forces the customer's IT team into reconciliation work that should not exist.

The cost of getting this wrong is not just inconvenience. Two systems holding partial views of the same patient is the classic source of clinical errors: a clinician sees the visit but misses the lab result because they live in different places. A unified timeline makes that class of error structurally unlikely.

The strategic value is also durability. A new module added in five years' time joins the same timeline retroactively — its data appears in the same chronological view alongside everything that came before, without a migration project. The platform's value compounds rather than fragmenting.

What's in the box

• One clinical record per customer organisation. The laboratory writes orders, samples and measurements; visits write consultations, messages and documents. Both point at the same patient. No feature keeps a private database of its own.

• FHIR-native references. A visit note that cites a lab result links by FHIR reference, not by module-internal ID. A follow-up scheduled from a lab result links back to the ordering encounter the same way.

• Standard FHIR queries. A "show me everything for this patient" query is a single Patient/$everything call — every module's data is included by default.

• No private module databases. Modules that need fast lookups use indexes over the shared clinical record, not separate copies of the data. Storing clinical content in a module-private database is a violation, not an option.

• Audit events are in the timeline. Every module's audit events live in the same clinical data boundary as the clinical records, queryable in the same place.

• Retroactive joining. A new module enabled later fills in the timeline for records that already exist — there is no module-bounded history to migrate.

Standards we lean on

• HL7 FHIR — Patient/$everything is the standard longitudinal-record query; FHIR references are the standard cross-resource link.
• GDPR Article 20 — right to data portability. One bundle, not one per module.
• HIPAA 45 CFR 164.524 — right of access. Patient gets a coherent record across all modules.

What customers and operators experience

• A clinician opening a patient record sees one chronological timeline that includes lab results, visits, dictated notes, and follow-up actions — regardless of which module produced each entry.
• A clinician reviewing a patient mid-visit sees the latest lab result inline with their visit context, without leaving the Visit Assistant module to switch to Lab.
• A compliance officer answering a data-access request can produce one record per patient, not one per module — the audit trail and clinical content live together.
• A patient asking for their data receives one export, in standard FHIR, covering everything the platform holds about them. No "lab data export" plus "visit data export".
• A new module enabled later fills in the timeline retroactively for records that already exist — there is no module-bounded history to migrate.
• A customer leaving the platform takes their full clinical record as a single FHIR bundle, not a stack of per-module exports.

Limits and trade-offs

• Modules must use FHIR idiomatically. Module data that does not fit a FHIR resource type is either expressed via FHIR extensions (within the standard) or stays out of the timeline entirely.
• Cross-module reporting stays per organisation. The unified timeline is unified within a customer organisation; combining timelines across customer organisations are deliberately not a feature.
• Module ordering on the timeline depends on event timestamps, not module preference. A late-arriving lab result is sorted by when it was finalised, not by when the visit happened.
• Schema evolution is shared. A change to how Lab uses measurement affects every module that reads measurement. The discipline is real; the alternative is silos.

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.

Why this matters

Vendor lock-in is one of the first concerns a hospital procurement team raises about a SaaS platform. "We can take our data with us" is not a comfort feature — in many EU procurement frameworks it is a contractual prerequisite. A vendor whose answer is "we'll prepare an export when you leave" is already negotiating from a weak position.

European healthcare has a recognised interoperability standard, FHIR, increasingly extended with national profiles (Estonian, French, German, Spanish, Nordic, and others) that codify local realities on top of the common base. National registries, electronic prescription systems, lab analytics tools, public-health reporting, and most modern clinical software either already speak FHIR or can be made to. Storing clinical data in proprietary shapes turns every one of those integrations into a custom translation project; storing in FHIR turns them into configuration.

Open standards also align with what regulators expect. They read the data shape directly — they are already familiar with FHIR resources and can verify retention, access, and audit semantics against the standard. A vendor's proprietary schema, however well documented, is one more thing the regulator must learn before they can trust the system.

What's in the box

• FHIR as the canonical data store. Clinical resources are written, queried, and audited as FHIR. Nothing lives in shadow tables that would need separate export.

• National profiles by zone. Each compliance zone declares its national FHIR profile (where one exists) — the jurisdiction's local refinements of the common standard. The same patient resource carries the right local extensions in the right zone.

• One clinical data boundary per customer organisation. Each customer organisation's data lives in a dedicated clinical data boundary; export and disposal operate at project granularity, with no entanglement between customers to separate.

• FHIR APIs are the integration surface. Inbound and outbound integrations consume and produce FHIR; bespoke adapters live at the integration boundary, not the data store.

• Audit is FHIR too. audit record resources carry every action in a queryable, exportable, regulator-recognisable shape — the audit trail is portable on the same terms as the records.

• Modules share one record. Clinical modules read and write the same per organisation clinical record. Switching a module on or off does not migrate data between schemas.

• Open-source FHIR implementation. The underlying FHIR server is itself open source, so the dependency is on a standard plus an open implementation, not on a closed vendor product.

Standards we lean on

• HL7 FHIR — canonical resource shapes for clinical data, audit, configuration.
• National FHIR profiles — Estonian, French, German, Spanish, Nordic and others, layered on the common standard per zone.
• GDPR Article 20 — right to data portability. Receive personal data in a structured, commonly used, machine-readable format.
• EU eHealth Network common standards — cross-border exchange formats anchored in FHIR.

What customers and operators experience

• A hospital's procurement team sees that all clinical data — patients, encounters, observations, documents, audit events — is stored as FHIR resources. Lock-in concerns are answered by reference to the standard, not by the vendor's promises.
• A customer's IT team integrating with an external system (a national lab registry, an e-prescription service, a public-health reporting interface) speaks FHIR through standard APIs. No proprietary data shape to translate.
• A customer leaving the platform exports their full clinical data as a standard FHIR bundle. No "preparation" delay, no proprietary conversion. Whatever system they go to next can read what comes out.
• A regulator reading per-patient timelines, audit events, and consent records does so against FHIR resources — the same shape they audit elsewhere.
• A research team running consented analytics works against the same FHIR resources that drive clinical care; there is no "analytics replica" with a different schema to keep in sync.
• A new clinical module plugging into the platform reads and writes the same shared clinical record every other module uses. It does not introduce a parallel data store of its own.
• A national registry adapter consumes FHIR from the platform, applies any zone-specific national profile mapping, and submits to the registry. New jurisdictions add a national profile, not a new data store.

Limits and trade-offs

• FHIR is verbose. The standard is rich enough to express almost any clinical concept, which makes resources larger and queries more involved than a tightly-scoped proprietary schema would be. Portability is worth more than the storage saving.
• Specialty coverage varies. Some clinical specialties have well-developed FHIR profiles; others are still emerging. Modules in less-covered specialties may need to contribute custom resources within FHIR's extension mechanism until standard profiles catch up.
• National profiles need maintenance. Each zone's national profile evolves over time; keeping the platform aligned is ongoing work, not a one-off setup.
• "Take your data" is clinical data. The export covers clinical resources, audit events, and consent records — what a customer needs to continue care elsewhere. It does not include the platform's anonymisation memory, AI prompt history, or operational telemetry. Those are vendor-internal by design.
• Standard does not mean trivial. FHIR being the common language reduces integration cost; it does not eliminate it. Mapping a national registry's idiosyncrasies onto FHIR remains real work.

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.

Why this matters

Clinical documentation is one of the largest cognitive and time costs in clinician work. A clinician who has spent twenty minutes in a consultation often spends another fifteen minutes on the note: reconstructing the chief complaint, organising the history, writing the examination, recording the plan. The note is necessary — for clinical continuity, for billing, for medico-legal record — but the time is taken from the next patient.

A platform that drafts a usable note from the recording flips this. The clinician's time shifts from writing the note to reviewing it. Reviewing is faster than writing, more accurate because it engages a different cognitive mode, and produces notes that are structurally consistent because they were drafted from the same template every time.

The principle: the AI drafts; the clinician owns. Every note is reviewed and signed by the clinician; the platform never publishes an AI-drafted note unsigned. The clinician's name, the clinician's sign-off, the clinician's edits are what make it a clinical record.

What's in the box

• Anonymised transcript is the input. Note drafting runs on the anonymised transcript stream; raw text never reaches the drafting model.

• Zone-aware drafting. The note's structure, terminology, and language are configured per zone. A zone-ee draft uses Estonian medical terminology; a zone-de draft (when delivered) uses ISiK-aligned structure.

• FHIR DocumentReference + Composition. The signed note is stored as a FHIR Composition resource, referenced from the encounter, with structured sections that can be queried independently. Free-text and structured content coexist.

• Smart actions linked into the note. Lab orders placed during the visit, prescriptions written, referrals generated — all linked from the note's plan section.

• Edits feed the improvement loop. For consenting tenants, anonymised before/after pairs feed drafting-model improvement through the platform's consented data use programme.

• The clinician owns the signature. The platform never publishes an unreviewed draft. Every signed note carries the clinician's name and sign-off; what was AI-drafted vs clinician-edited is visible in audit.

Standards we lean on

• HL7 FHIR R4 Composition and DocumentReference — the standard shape for the signed note and its registry entry.
• GDPR Article 22 — automated decision-making. The clinician's review and signature are the human-in-the-loop required by the article.
• EU AI Act (Annex III, healthcare risk class) — clinical decision-support classification informs drafting and review UX.
• HIPAA 45 CFR 164.514(b) — Safe Harbor / Expert Determination for the de-identification bar input must clear.

What customers and operators experience

• A clinician at the end of the visit sees a draft note organised in the structure they expect (chief complaint, history, examination, assessment, plan). Lab results referenced in the conversation are linked. Smart actions detected during the visit are listed.
• A clinician reviewing the draft edits inline. Changes are tracked; the audit trail shows what the AI drafted vs what the clinician changed.
• A clinician signing the note publishes it to the patient's unified timeline. From that moment the note is a regular FHIR DocumentReference; it can be queried, exported, and referenced like any other clinical record.
• A clinician picking up another clinician's patient sees consistent note structure across notes — even across clinicians — because the drafting structure is the same.
• A coding team or billing department sees notes with structured sections, recognisable terminology, and consistent quality. Coding inputs improve.
• A patient asking "what did the doctor write?" receives a signed note in standard FHIR; portable to any other FHIR-aware system.

Limits and trade-offs

• Drafting quality is bounded by transcript quality. A noisy recording produces a noisy transcript produces a weaker draft. The clinician's review is meaningful, not cosmetic.
• The clinician must review. The platform never publishes an unreviewed draft. A clinician who blindly signs is using the feature wrong; the platform encourages review through UX but does not enforce a minimum review duration.
• Drafted facts that the clinician disagrees with are the clinician's responsibility to correct. The signed note is the clinician's record, regardless of how the draft started.
• Some specialty notes are harder to draft well. Highly structured specialty notes (specific ophthalmology examinations, certain procedure notes) may need specialty-specific drafting templates that lag behind general-practice ones.

Related features

• Visit recording with audited consent — the recording's transcript is the drafting input.
• Smart action detection — detected actions are linked into the drafted plan.
• Patient-facing visit summary — the lay-language patient-facing summary is generated from the signed note.
• Platform: Right-sized AI pipeline — drafting runs as one of Visits's AI tasks routed through the platform.
• Platform: Open standards data portability — signed notes are FHIR Composition / DocumentReference resources; portable like everything else.

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.

Why this matters

Studies of patient comprehension after consultations consistently show a gap. A patient who heard the clinician's instructions in the moment retains a fraction by the time they get home, and that fraction degrades through the days that follow. The clinician's signed note is not the right document for the patient — it uses medical terminology, reflects clinical reasoning, and is structured for the next clinician, not for the patient.

A take-home note designed for the patient closes part of this gap. It uses lay language, focuses on what the patient needs to do and watch for, and is in the patient's language rather than the clinician's clinical language. It does not replace the medical note; it complements it.

The strategic value is downstream care quality. Patients who understand their treatment plan adhere to it better; patients who know when to call the clinician avoid both unnecessary calls and delayed escalation; patients who can re-read the summary days later carry the consultation forward instead of forgetting it.

What's in the box

• Generated from the signed clinical note. The patient summary is downstream of the clinician's signed note, not from the raw transcript directly. This ensures the summary reflects what the clinician actually decided, not what the AI thought the clinician decided.

• Lay-language model task. A specific AI task translates clinical content to lay language. The task is routed through the platform's right-sized AI pipeline; zone-specific provider rules apply.

• Structured action sections. Medications, appointments, things-to-watch-for, when-to-call are FHIR resources (MedicationStatement, Appointment, CarePlan) the summary references. The same data drives the patient portal's reminders.

• Translation into the patient's language. The platform maintains a list of zone-supported languages for patient-facing content; the patient's preferred language is part of the patient record. Where the language is supported, the summary is generated directly in it; where not, English (or the zone's default) is used with a note.

• Delivery channel per tenant. SMS link, email, printable PDF, patient-portal entry — the tenant configures which channel(s) the summary delivers through.

Standards we lean on

• GDPR Article 12 — transparent communication to the data subject in clear and plain language.
• HIPAA 45 CFR 164.524 — right of access. Patients receive their record in a form they can use.
• HL7 FHIR R4 Composition, CarePlan, MedicationStatement, Appointment — the standard shapes underlying the summary's action sections.
• WCAG 2.2 — accessibility for patient-facing content (reading level, contrast, screen-reader compatibility).

What customers and operators experience

• A clinician finishing the visit sees the patient summary drafted alongside the clinical note. They review both; edits to the clinical note flow into the patient summary.
• A patient leaving the visit receives the summary on their phone (or printed, depending on tenant configuration). It is in their language, in plain vocabulary, with structured action items.
• A patient at home reviewing the summary sees clear sections: "What we discussed", "What to do", "What to watch for", "When to call us". Each section is short.
• A patient with low health literacy sees a summary pitched for general audiences — short sentences, common words, no jargon. Per-tenant settings can configure the reading-level target.
• A non-native-language patient receives the summary in their preferred language (where the platform's translation supports it). The clinical content is the same; the language is the patient's.
• A clinician seeing the same patient at follow-up can reference the prior summary to reinforce or revise the plan; the patient has it on their phone.

Limits and trade-offs

• Translation quality depends on the language model for that language. A patient receiving a summary in a language with weaker LLM coverage receives a less-fluent summary.
• The summary is not a clinical record. A patient reading their summary should understand their care plan; they should not use it to substitute for medical advice. Per-tenant configuration controls how prominently this disclaimer appears.
• Lay-language content can over-simplify. A complex clinical situation summarised as a few short sentences may flatten nuance the clinician intended to preserve. The clinician reviews; the platform encourages but does not enforce nuance.
• Patient delivery depends on contact details. SMS delivery requires a current phone number; email delivery requires a verified email. Patients without these receive printable PDFs.

Related features

• Visit note generation — the signed clinical note is the input to the patient summary.
• Smart action detection — detected actions become structured action items in the patient summary.
• Platform: Patient data anonymisation — the patient summary contains the patient's identifying content (the patient is the audience), but it is delivered only to the patient, not to AI providers downstream.
• Platform: Right-sized AI pipeline — summary generation is one of Visits's AI tasks.
• Platform: Compliance zones — language support and patient-content delivery rules vary by zone.

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.

Why this matters

Televisits are now a routine part of clinical care, not an exception. Outpatient follow-ups, second-opinion consultations, specialist-to-GP discussions about a shared patient, post-discharge check-ins — all happen as often over video as in person. A platform that treats remote consultations as a separate, weaker product than in-person creates two-tier clinical workflows: live assists for the in-person visit but not the remote one, signed note from the in-person but a different note format from the remote.

The opposite — building televisit on a different stack from in-person — multiplies engineering effort and certification burden. Two recording paths, two transcription paths, two anonymisation paths, two audit trails. Each is a separate compliance review.

Televisit reuses the same substrate. The audio capture happens through LiveKit; the audio reaches the same platform recording service; the same anonymisation runs; the same live assists appear; the same signed note structure results. The clinician's experience and the patient's safeguards are identical.

What's in the box

• A capture mode of the Speech Anonymisation membrane. Televisit is one of several capture modes that feed the platform's Speech Anonymisation membrane. The audio enters the same membrane as an in-person ambulatory visit; the output SafeTranscriptSegment stream drives the same downstream features. The membrane's invariants — no LLM inference between audio and safe text, sealed raw boundary, per-zone retention, audit on every crossing — apply unchanged.

• LiveKit is the audio/video substrate. Audio + video capture, mixing, and routing run on LiveKit; the same open-source substrate the in-person recording mode uses. Televisit adds video as a track that LiveKit carries alongside audio; the audio side flows into the membrane; the video side is handled by the call surface.

• Multi-stream speaker metadata from the call context. Each televisit participant is a LiveKit stream with a declared identity (the patient who joined the link, the clinician logged in at their end, additional participants per role). Each line of the transcript therefore carries who said it and in what role, taken from the call itself. The platform does not try to work out who is speaking from the audio: it is told.

• Patient-facing portal flow. Join links, remote consent capture, identity verification before the call opens, and the patient-side waiting room are televisit's own consumer-side surface — they are not part of the membrane. Consent is captured upstream of the recording open (REC-001), the same as the in-person visit's consent capture; the mechanism of capture (portal vs. bedside tablet) is different, the contract is the same.

• Cross-zone televisit support. A televisit between a clinician in zone-ee and a specialist in another zone routes through the participating tenants' compliance zones; the more-restrictive zone's residency and provider rules apply.

• Recording opt-in per call. Some televisits should not be recorded (e.g., crisis-line equivalents); the clinician can start a televisit without recording, and the platform records that choice in the audit trail.

Standards we lean on

• ePrivacy Directive 2002/58/EC — confidentiality of electronic communications and consent for recording.
• GDPR Article 9 — special-category health data over remote channels.
• eIDAS (EU 910/2014) — cross-border identity assurance for clinician-clinician televisits across EU jurisdictions.
• HL7 FHIR R4 Encounter (virtual class) — the standard shape for the remote-encounter record.

What customers and operators experience

• A clinician scheduling a televisit does so through the same scheduling surface used for in-person; the patient receives a join link.
• A patient joining the televisit clicks a link, sees a consent prompt, joins the call. Consent is captured the same way as in-person.
• A clinician in the televisit sees the same live assists they would see in person — drug interactions, lab orders detected, role labelling. The recording surface is identical.
• A clinician at end of the call sees the same draft note format, the same smart actions, the same patient timeline. Closing the call is the same as ending an in-person visit.
• A patient receiving a follow-up summary receives the same lay-language take-home note as for an in-person visit.
• A specialist-to-GP discussion about a shared patient uses a televisit format with multi-party identity carrying through to the transcript.

Limits and trade-offs

• Televisit quality depends on network conditions on both ends. A patient on poor connectivity produces a poor recording produces a weaker transcript. The platform does not improve audio it didn't get cleanly.
• Platform-mediated, not browser-only. Televisit requires the platform's UI on both ends; integrations with arbitrary third-party video systems are not supported.
• Multi-party with mixed audio is harder. When a televisit has multiple participants but audio is mixed rather than per-stream (e.g., one phone calling in to a video conference), speaker identity for the mixed participants is unknown.
• Recording retention applies. Televisit recordings follow the same per-zone retention policies as in-person; raw recordings expire on schedule.

Related features

Substrate it composes:

• Platform: Speech Anonymisation — the speech-side PII Membrane service. Televisit is one capture mode that feeds it.

Sibling capture-mode capabilities (consume the same membrane):

• Visit recording with audited consent — in-person ambulatory recording. Same membrane, different capture surface.
• Inpatient rounds capture — cohort + huddle capture composition. Same membrane.
• MDT meeting capture — multi-participant Regime B capture. Same membrane.

Downstream consumers (run on every capture mode's segments):

• Live clinical assists — surface during televisits the same way as in-person.
• Smart hints — real-time candidate-differential and information-gap proposer.
• Visit note generation — televisit notes are drafted the same way.

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.

Why this matters

Multidisciplinary team (MDT) meetings carry decisive clinical weight. A tumour board's recommendation about a patient's treatment plan, a complex case discussion's consensus on diagnosis, an MDT review's conclusion about whether to operate — these are the moments specialists agree on a course of action that no single specialist would have decided alone. The patient's record needs to reflect not just the conclusion but who said what and why.

A meeting captured by one participant's notes loses the multi-voice structure: it becomes "the consensus was X" without the supporting discussion. A meeting captured by audio without speaker identity loses attribution: an inspector reviewing the recommendation later cannot tell which specialist contributed which view.

MDT meeting capture solves both. The recording happens with per-participant identity (each participant's microphone or stream is tagged at source); the transcript carries that identity; the generated meeting note attributes contributions to the right specialist by name, role, and discipline.

What's in the box

• Multi-stream call channel. Each MDT participant joins as a separate stream; the call platform tags each stream's audio with the participant's identity. The platform's secure recording service consumes the multi-stream input.

• Speaker identity is metadata, never inferred. The recording service treats identity as input from the call context, not as something to deduce. A participant on a shared microphone is "speaker-unknown" unless the meeting context provides identity.

• Per-case structure. The meeting agenda lists cases as patient-context boundaries. The transcript for each case is associated with that patient's record; the generated note appears on the patient's encounter.

• Structured meeting note generation. The drafting AI task produces per-case structured notes (recommendation, rationale, dissent, follow-up actions) attributed to speakers. Same drafting infrastructure as visit notes.

• Decisions surface as smart actions. An MDT recommendation that requires a follow-up — schedule treatment, order further imaging, refer to another specialty — surfaces as a smart action on the patient's encounter, ready for the treating clinician to confirm.

• Multi-tenant participation. A specialist from another organisation joining an MDT (e.g., external consultant) participates under a guest identity; their contributions are recorded in the host tenant's record per the host's zone policies.

Standards we lean on

• HL7 FHIR R4 Composition and CarePlan — the standard shapes for the meeting note and resulting follow-up plans.
• GDPR Article 9 — special-category data; tightened controls apply to MDT recordings.
• ePrivacy Directive 2002/58/EC — recorded multi-party communications consent regime.
• eIDAS (EU 910/2014) — cross-border identity for participants from other EU jurisdictions.

What customers and operators experience

• An MDT coordinator scheduling a meeting invites participants through the platform's scheduling surface. Each participant joins with their own audio stream; identity is tagged at the moment they speak.
• An MDT participant joins the meeting (in person or remotely via televisit), sees the agenda, and contributes during their case. Each contribution is attributed to them automatically.
• An MDT chair sees a structured timeline of the meeting in real time: which case is currently being discussed, which participants have spoken, the time pressure on each case.
• An MDT clinician reviewing the meeting note afterwards sees attributed discussion: "Dr. Smith (Oncology): recommended chemotherapy regimen X based on Y. Dr. Jones (Surgery): supported, conditional on Z. Dr. Patel (Pathology): noted risk of W."
• A patient whose case was discussed has the MDT recommendation recorded against their encounter.
• A regulator reviewing a treatment decision sees the MDT discussion that produced it, with each contributing clinician identified.

Limits and trade-offs

• Identity quality depends on the meeting setup. A meeting with everyone on per-stream microphones produces high-quality attribution; a meeting with a single mixed microphone in a conference room loses attribution for participants in that room.
• Cross-tenant meeting data is constrained. When a clinician from one tenant joins another tenant's MDT, the recording lives in the host tenant.
• Meeting note structure varies by specialty. Oncology MDTs structure differently from cardiology MDTs. Per-tenant or per-zone templates can be configured.
• MDT scheduling integration is partial. Scheduling surface integration exists for tenants using the platform's scheduling; integration with hospital-wide scheduling systems requires the LIS-bridge-equivalent for the scheduling system.

Related features

• Televisit — MDT meetings often include remote participants via televisit; same substrate.
• Visit recording with audited consent — the same recording mechanism applied to multi-party context.
• Visit note generation — the drafting infrastructure used for the meeting note.
• Platform: Secure recording service — the substrate with per-stream identity support.
• Platform: Cross-module clinical workflow — MDT decisions flow as smart actions on the patient's encounter.