User stories

The scene

Tuesday 11:18, a family-medicine clinic in Tartu. Dr. Pärn has just finished a 12-minute hypertension follow-up. The patient, Andres, has left to book his next appointment.

The visit itself was recorded, with Andres's agreement — the red dot was on, the transcript captured both sides, and the decisions they reached together ("let's try the same medication for another month, bring your home BP diary next time") are already in the draft note waiting in Dr. Pärn's queue.

But Dr. Pärn has been holding a few thoughts she did not say aloud: white-coat effect on his clinic readings (130/80 at home per his diary, 152/94 today); the half-full medication blister he absent-mindedly took out and put back — a quiet adherence concern; a plan to introduce a medication change next visit if home readings hold. These belong in the record. They are her clinical reasoning about Andres's care — but they were never part of the conversation with him, and calling him back into the room to say them out loud would be absurd.

The walkthrough

On the task in her authoring queue, Dr. Pärn clicks 🎙 Dictate. A red dot pulses on the button and an empty note appears in the Additional notes stack — the same stack the + Add note button fills. She speaks:

"Quick add — worried about white-coat effect. Home BP per his diary running 130/80, clinic 152/94. Holding off on medication change today but planning to escalate to a CCB at next visit if home readings stay this way. Also noticed his medication blister looked half-full — possible adherence issue, want to address it gently next visit, maybe via the nurse for a med-review appointment."

As she speaks, the audio is streamed to the platform's own speech-to-text service and the recognised words appear in the note. She clicks the button again to stop, fixes "CCB" into the full drug class, and the note is saved like any other — a kind:note block on the authoring task, indistinguishable from one she typed by hand. When she later confirms the task, that text is part of the note she pastes into the hospital system.

The audio leaves the browser only to reach our own transcription service — the same one the visit recording uses, working in Estonian, Russian or English — and is discarded the moment the text comes back. It never reaches an outside speech service, it is never stored, and nothing anyone could replay survives. The text itself passes the same anonymisation as any other clinical text before it is kept or shown to a model — not because dictation is special, but because that is the rule for all of it.

Nothing else is created: no separate visit record, nothing for the patient to consent to, and no "this was dictated" marker on the note. It is a faster keyboard whose keystrokes happen to be spoken.

Why this matters

Across a 25-patient outpatient day this is 10–15 minutes of saved typing per clinician — but the larger gain is completeness. Today, post-visit clinical reasoning either gets typed (lossy, deferred, sometimes never) or stays in the doctor's head and is gone by Friday. A spoken note captured at the moment the mental model is freshest, landing straight into the draft as editable text, gets it down without the typing tax — and without pretending the patient consented to a recording of the doctor talking about them after they left, because there is no recording to consent to.

The scene

The hospital grants the vendor's engineer a devhub:developer login — a role, plus an assignment naming the one connector the vendor is integrating. That is the entire ceremony.

The engineer places a T-tagged order through their test channel. The hub routes it, the connector's dry-run twin serves it, and the engineer opens Wire Traces: the view shows exactly the crossings of their assigned connector that belong to their own calls — the order they placed, attributed by the hub at dispatch, and any request-thread crossing made under their own principal.

What they cannot do matters more than what they can. The environment wall is structural: the developer view is test and development only, and no parameter exists that widens it — requesting the production view simply is the test view. Another vendor's traffic on a different connector is outside their assigned scope. Another principal's calls on the same connector are not theirs to read. A guessed record id outside the scope reads as not-found. And identity-bearing gates redact inline regardless — belt and braces.

What the platform had to do

• Record which order and which account produced every exchange, so "my calls" is something the platform can answer rather than something the reader has to work out.
• Enforce all three limits together and in the only place that can serve this view: test environments only, only the devices assigned to that integrator, and only their own calls. Not three filters that could each be forgotten — one path that cannot serve anything else.
• Keep the assignment itself in configuration: a document per customer naming which connectors each integrator may see, handled like every other piece of configuration.

Why it matters

Self-service integration debugging is a headline benefit of the Device Hub: every integration project spends its first weeks in exactly this loop, normally gated on the hospital's IT department forwarding log excerpts by email. Giving the integrator a safe window into their own traffic collapses that loop to minutes — and the hospital can grant it without a governance debate, because the guards are unrepresentable states, not policies someone remembered to configure.

Runtime visibility (administrator side)

The cockpit's administrator-facing companion is the Runtime view: the live state of the device framework as the runtime itself knows it — installed driver bundles, declarative-services components with an unsatisfied component naming the reference it waits for, registered services, configurations (secret values masked at the source), and the configuration schemas the Add-Device forms render from. "Why is my driver not up" is answered from the running framework's own data structures, not from SSH sessions or log archaeology. A JSON twin serves the same snapshot to tooling and agents.

The scene

The distributor sells and supports the practice software sixty small clinics in the region already run, on a cloud hospital system/laboratory system of its own. Its support desk is the number those clinics call. Its identity directory already holds their staff accounts, because it already administers them.

It now resells Jengu alongside. Rein, its integration engineer, is adding a Jengu leg to an onboarding script that already provisions a clinic in their own products. He has never spoken to anyone at Jengu about this particular clinic and does not intend to.

The clinic is Männi Perearstikeskus: four GPs, two nurses, a receptionist. They want visit recording and lab ordering. Their practice manager, Kadri, will set up the edge box in the back office herself.

What a distributor is

A distributor is a participant in its own right — not a department of Jengu's administrative organisation and not a member of it. The platform already asks what kind of participant something is, and answers with aspects: healthcare-provider, insurer. A distributor is the third.

That placement is not filing tidiness. Jengu's own admin org is barred from every customer organisation URL space as a GDPR boundary, and a commercial counterparty — with its own contract, its own staff, sometimes its own competing product — has no business inside it. Membership is also the wrong shape for the question that matters: "which customer organisations are yours" is a relation between two participants, and cannot be derived from "you are in our admin org".

As a participant it gets everything the platform already does per participant: its own configuration repository, keys, users, clients and audit trail — and its own lifecycle, so a distributor that stops paying can be suspended like anyone else. It carries no healthcare-provider aspect, so there is no clinical data in its project to reach: the ceiling on patient data is structural rather than a scope check that has to be right.

The distributor's key, and its ceiling

The distributor holds a machine key bound to its own participant. It is not a shared password, not a Jengu employee's account, and not a credential any of its customers can borrow — a token minted for a customer customer organisation cannot reach the surface that governs customer customer organisations, however that client was declared.

The rule the operator surface applies has no special cases in it: the caller's client is bound to a participant carrying the distributor aspect, and the target customer organisation's owner is that participant. Jengu's own direct customers are owned by a participant too, so there is one rule rather than a rule plus an exception.

What the key can do is bounded on purpose:

• create a customer organisation, naming the customer's first administrator;
• read the status of customer organisations it owns;
• suspend and resume them — the commercial lever, for a clinic that stops paying;
• declare its own authority connectors, and push the people its directory holds.

What it can never do is destroy one. Disposal ends in cryptoshredding, and a channel relationship is not a reason to hold that: a hospital's record has to outlive a billing dispute.

And it cannot enumerate the platform. There is no list of Jengu's customer organisations for a distributor to read — that list is our customer base, and it is not something to hand to a party that may also sell against us. A distributor sees the customers it owns and nothing else; two distributors on one platform are two disjoint views.

Asking after a customer organisation that is not yours answers the same way as asking after one that does not exist. The platform already refuses to leak customer organisation existence — a request that crosses customers answers 404 rather than 403, so nobody can probe for "that exists but you cannot have it" — and the operator surface holds the same line.

Every call lands in two trails, the platform's and the organisation's own, naming the distributor client that made it. A hospital can always see what its distributor did to it.

Step 1 — the customer organisation, and the person who owns it

The create call names the clinic's first administrator: their address, and the subject identifier the distributor's authority will assert for them.

The customer organisation materialises with its own project, organization tree and keys. A local administrator account is created for that person and a temporary credential reaches their mailbox. The path runs platform → person: the distributor supplies the address and never sees the credential, cannot replay it, cannot suppress it.

At this moment nothing is delegated. The clinic's only way in is the account it alone controls — which is precisely why the next step is the clinic's decision rather than the distributor's.

The first administrator is the hospital's

By contract, the first administrator of a customer organisation is a person at the customer, not at the distributor. Afterwards the owner may add the distributor's own account as an administrator — for support, on purpose, and revocably. What the distributor may not do is arrive that way.

The platform cannot prove an address belongs to a hospital, so the rule is enforced the honest way: contractually, and made detectable.

• Creation records the first administrator's address and subject, the distributor client that named them, and when.
• "First" is answered from the append-only trail, not from current state — removing that admin later does not remove the evidence.
• The customer organisation's trail is append-only against an administrator at the customer too. Otherwise a distributor that breached the rule holds exactly the rights needed to tidy up after itself.
• And the hospital sees it unprompted: "Your customer organisation was created by on . Your first administrator was
  ."

Comparing the address domain against the clinic's own is a useful flag and not proof — a distributor that runs a clinic's IT can make a mailbox in the clinic's domain. The control is that the fact is permanent, visible to the party harmed, and a named breach of the partnership contract.

Step 2 — the distributor declares its authority once, per environment

The distributor does not configure sixty clinics' logins. It declares its authority connector: a reference to the driver that speaks its protocol, plus the credentials to reach it — once per environment.

Three of those exist for the same reason the order lane has them: development, test and production are separate connectors with separate credentials, and the wall between them is structural. A test authority cannot mint a session in a production customer organisation. Not discouraged — refused at resolution. Identity is the one place where a misconfigured reference is a one-hop path into patient data with no exploit required.

Declaration and secret split the way the platform already splits them elsewhere: the connector's driver reference, issuer and client id are declared config; the secret lives only in the secret store and is resolved at ceremony time, so rotation is one write and touches no customer organisation.

Three authorization rules carry the whole security surface of this:

• a distributor declares and rotates only its own connectors;
• a customer organisation may reference only its own distributor's connector — otherwise clinic A points at distributor B's authority and B mints sessions into A;
• and a connector serves only customer organisations in its own environment.

A connector proves itself before it may serve production: discovery reachable, keys resolvable, one real login round trip in test. The platform already promotes versions and configuration dev → prep → prod; an authority earns production the same way.

Accepted blast radius. One connector serving sixty clinics means a compromise there reaches all of them at once. Contained by per organisation enablement, the per organisation role map, the environment wall and the local door — but accepted deliberately, not discovered later.

There is a benefit on the other side of the same property: when a contract ends, disabling the connector ends delegated login for every customer organisation it served, in one action, while every hospital still gets in through its own account. That is only survivable because the local door exists.

Step 3 — the hospital decides to trust it

Kadri opens the customer organisation URL, signs in with the temporary credential and changes it. That is the consent point, and it is deliberately the first thing she does: the hospital exercises the door it controls before it comes to depend on any other.

She then sees what her distributor has proposed — "sign in with ", with a suggested mapping from the distributor's roles to Jengu's — and decides. The distributor's script carried the configuration so nobody types an issuer URL by hand; the act of trusting is hers, recorded in her customer organisation's own trail as hers.

What she is granting is not one switch but a set:

• delegated login — her staff sign in through the distributor's authority;
• people management — the distributor's directory may create and deactivate the clinic's practitioners;
• remote role management — the distributor's claims, through her map, govern who may do what.

They are separately enablable, because they are separate concessions. A clinic may accept its distributor's login without also accepting a roster push into its practitioner list.

The role map is hers even when the input is not. The distributor asserts a claim; the customer organisation decides what it means, deny-by-default — a claim her map does not name grants nothing. The distributor cannot widen rights on its own side, and this holds however the claims arrive.

When remote role management is on, local role edits are refused, not merged. Two writers and one truth: if she can hand-edit a role the next login recomputes, the clinic fixes something, it silently reverts, and neither side is trustworthy afterwards. On means the map governs and the local controls are visibly read-only. Off means people may still arrive by SSO while she grants their rights herself.

Her own administrator account is never remotely managed. If the distributor's directory could strip that role, the door the whole model rests on closes from the distributor's side. It sits outside the switch by construction, so the customer organisation always retains at least one locally-governed administrator.

Step 4 — the clinic's people

Two different questions get two different answers, and conflating them is where identity integrations usually go wrong.

Who works here is the distributor's directory to know. It pushes: the four GPs, two nurses and the receptionist exist as practitioners in the clinic's own project before any of them signs in — which matters, because a practitioner is referenced by orders, results, encounters and authoring tasks, and clinical structure cannot be built out of people who do not exist yet. When someone leaves, the distributor removes them where it always did, and their access ends without anyone opening a Jengu admin page. What they did stays in the record; it is their way in that closes.

What they may do right now is re-derived at every login from the claims the authority asserts, through the organisation's map. No sync lag, no drift, and a role revoked at the distributor is a role gone at the next ceremony.

Neither is redundant: one answers who is there, the other what may they do this morning.

The third option — Jengu polling the distributor's directory — is deliberately not taken. It would require Jengu to hold directory-read credentials and to pull a partner's employment data across the membrane, a materially larger PII surface than either alternative, for freshness the other two already provide.

Step 5 — the clinic configures its own equipment

Kadri enrols the edge box, watches its devices appear, and enables the device hub for her clinic herself.

None of this is a distributor API call. The edge is the clinic's hardware, in the clinic's back office, handling the clinic's patients. Every capability the distributor does not need is a capability it cannot get wrong — and the distributor's job ended when the clinic could sign in.

Never one door

The distributor owns the authority. If that were the only way in, it could lock a hospital out of its own record — during a billing dispute, or on the way out of a contract. So access is a ladder, each rung less convenient and louder than the one above:

1. Delegated login — normal, instant, through the distributor's authority.
2. The local administrator account — reset to the administrator's own address, needing neither distributor nor Jengu. Not a dormant path: it is how the customer organisation was opened in the first place, so it has been exercised before it is needed.
3. Platform-side restoration — for the hijack case, where the addresses on file turn out to be the distributor's. Jengu mints or restores an administrator credential for a hospital contact verified out of band, through a channel that is not the distributor.

Rung 3 has a hard limit: Jengu hands the keys back, Jengu does not walk in. Platform admins are blocked from every customer organisation URL space by construction, and recovery must not puncture that — it mints access for the owner, it does not grant Jengu a session in a customer's customer organisation. Two named people request and approve it, it lands in the hospital's own trail, and it is counted. If it is not rare, the first-administrator rule is not working.

What each leg leans on

Every one of these is already promised elsewhere; the story leans on them rather than adding to them:

• a machine key that creates customer organisations, and customer tokens that cannot
• the customer organisation coming into existence from that one call, whole or not at all
• its configuration committed before anything is created
• every operation recorded in both the distributor's trail and the customer's
• suspension that is reversible and preserves the data
• login handed to whichever authority the customer declared
• claims nobody declared granting nothing
• a first login binding to the person already provisioned to receive it
• staff managed from the partner's own directory
• a local way in that survives the authority being unavailable
• the customer administrator's form writing to their own configuration
• a customer organisation that a caller without access cannot even tell exists

The story adds no new promise to that list. What it adds is the joins: the administrator named in step 1 is the identity step 3's consent is given by and step 4's provisioning has to agree about, before step 5 is reachable at all. No single-leg test crosses those seams, and delivery chains break at seams.

The scenario

A laboratory operates inside a partner network whose hospital system already holds every staff member's identity: accounts, credentials, and a role model the partner administers daily. When the lab adopts jengu, its technicians should not receive a second username and password to lose, and its administrators should not maintain a second user directory that drifts from the first.

Instead, the organisation's connector to that partner system — the same connector jengu already trusts for orders and results — carries one more capability: delegated authentication. A technician clicking "sign in" is sent through the partner's own OIDC login; on return, jengu binds the authenticated subject to the pre-provisioned practitioner record, grants exactly the roles the connector's declared mapping table names for the partner's custom roles, and issues its own ordinary session. When someone leaves the partner organisation, their next jengu login simply fails at the partner — no jengu-side offboarding step to forget.

What must hold

• The platform stays the session authority. The partner is consulted at the login ceremony only; partner tokens never become jengu sessions, and every isolation mechanism that keeps customers apart sees an ordinary jengu session.
• Roles map through a declared table, deny-by-default. A partner role the table doesn't name grants nothing — an authenticated user can hold zero jengu roles.
• Binding is to pre-provisioned practitioners by external identifier; an unknown subject gets no session.
• Delegation is never the only door. A partner outage removes the delegated option; local login is untouched (the local org:admin exists before the connector by construction).
• Tokens are verified properly — issuer, audience, nonce, signature against the authority's published keys; a token from anywhere else is rejected.

Why it matters

Every second credential is an adoption barrier at rollout and a liability at offboarding. Delegating to the identity system the partner already runs — through the connector relationship that already exists contractually and technically — removes both, without jengu ever holding or proxying the partner's credentials.

The scene

A regional hospital runs the Jengu platform with two departments on the customer organisation: the main laboratory and an ambulatory clinic. The laboratory operates the bench — three analyzers behind an edge appliance — so the organisation's org admin enables the Device Hub module and binds it to the laboratory department, the same gesture used to bind Visit Assistant to the clinic.

From that moment the laboratory's users see a Device Hub menu in their department's sidebar group: Devices, Edges, Wire Traces, and — because range verification is switched on for this customer organisation — Specimen Ranges. The integration lead checks the fleet after a firmware update, pulls the wire trace of last night's failed transmission, and confirms the specimen-range registry — without leaving the department's own menu.

What the fleet view shows is live, not last-known: a box that is up shows as up, and a healthy box with nothing to say stays that way rather than decaying to unknown between messages. A fleet page that forgot the difference would send the lead to a comms cupboard to look at hardware that was never broken.

The clinic's users see their own modules and nothing of the device surface. When the customer organisation later disables the module entirely, the pages disappear for everyone — no orphaned menu entries, no dead links.

What the platform had to do

• Package the device-operations pages as a module: one descriptor, one navigation contribution, department-bindable through the standard module mechanics.
• Move Devices, Edges, Wire Traces, and Specimen Ranges out of generic Administration into the module's menu, preserving the range-verification flag gate.
• Let the binding drive visibility: bound department's users see the menu, unbound departments and disabled-module customer organisations see nothing.

The lead's view reads the way the fleet is organised: the customer organisation root's connectors first (inherited — usable here, configurable only at the root, with an enablement switch this department may flip), then the department's own devices grouped by placement — Cloud, then each edge. Where the root has switched a connector off, the department sees a locked entry naming the level that decided — there is nothing to click, because deeper re-enablement does not exist.

Why it matters

Device operations are departmental work — devices have physical locations, and the people who run a location's fleet are that department's staff. Binding the surface to the department keeps every other department's sidebar clean, keeps the access model one gesture instead of page-by-page grants, and turns the device-integration offering into a module a customer can point at, price, and switch on — the product face the Order Hub's plumbing deliberately lacks.

The scenario

A laboratory's laboratory system bridge goes down at 07:40 — the vendor is rebooting the host system. In most platforms, the lab admin's menu still lists every bridge page; clicking any of them produces an error screen, a support ticket, and twenty minutes of "is it us or them". In Jengu, the pages backed by the unavailable connector are simply not in the menu. When the bridge comes back at 07:55, the entries return. Nobody restarted anything, nobody configured anything, and nobody clicked a broken link in between.

The same mechanism serves subtler cases: a driver whose version is not supported in the current environment never shows its configuration pages at all — the administrator cannot even begin an action the runtime cannot complete.

What must hold

• Navigation entries whose backing services are unavailable are structurally absent — not greyed out, not error-prone links. Absence is decided by the runtime's own dependency resolution (a declarative reference on the contribution), never by a hand-written availability check that can drift.
• Availability changes take effect without restart — on the next render, and in already-open shells via the platform's push channel; no browser polling.
• The static navigation (module pages, administration) composes exactly as before — reactivity is additive, not a rewrite of the menu.

Why it matters

Every broken link an operator can click is a support ticket the vendor pays for and a trust dent the product pays for. Making navigation a live view of the service registry converts "the UI promised something the runtime couldn't deliver" from a recurring incident class into an unrepresentable state — the same design philosophy the platform applies to data boundaries, applied to the shell.

The scene

A regional hospital in Viljandi has agreed to the pilot. The CMIO (Chief Medical Information Officer) signed the contract Monday morning. The hospital has roughly 350 beds, three operating theatres, a busy outpatient clinic, an ED that processes ~30,000 visits a year, and one medium-sized in-house lab plus a partner arrangement with a Tallinn lab for specialised tests.

The hospital runs an existing hospital system that the platform team has integrated with before (one of the regional Estonian hospital system variants). The lab system is a separate stack, also seen before. The hospital has no prior relationship with Jengu.

The CMIO is the local champion. The IT director is cautiously supportive. The clinical leadership is mixed — some eager, some sceptical. The deployment lead from Jengu is Elin, a senior deployment engineer who has done two prior customer organisation on-boardings.

The day-zero kickoff meeting establishes the six-week plan.

Week 1 — customer organisation provisioning

Day 1, Monday. The first action is on the project-setup git repo. Elin opens a PR adding the new customer organisation:

git: jengu-net/project-setup
PR #847 — Add customer organisation: viljandi-haigla
─────────────────────────────────────────────────────────────────
+ customer organisations/viljandi/settings/project.json
+ customer organisations/viljandi/practitioners/{seed users}.json
+ customer organisations/viljandi/modules/{enabled-modules}.json
+ customer organisations/viljandi/zones/zone-ee.binding

The PR is reviewed by the platform team, merged. Within one bootstrap cycle (the cloud syncs git config every ~60 seconds), the customer organisation exists:

• A new FHIR storage Project for viljandi-haigla is provisioned.
• The root Organization is created.
• A few seed Organizations (departments) are created — initial scaffolding to be filled in by the CMIO over the week.
• A ClientApplication credential pair is generated and stored in the project's settings.
• Tenant-scoped the durable workflow runner workflows are ready to run on the cloud (the customer organisation code is passed as a parameter to every lifecycle workflow).
• The customer organisation is bound to zone-ee.

Within an hour, the URL https://jengu.cloud/o/viljandi/... resolves and the CMIO can log in with his initial credentials. The hospital exists on the platform. It has no data, no users, no integrations.

Day 1 also: an SSL certificate for the hospital's vanity URL (viljandi.jengu.cloud) is provisioned via the platform's auto- cert flow; the organisation's email domain is set; SAML SSO if the hospital wants it is provisioned (this hospital uses standard Mobiil-ID authentication, so no SAML needed).

Day 2–3. The CMIO works with Elin to seed the organisation structure: departments (internal medicine, surgery, ED, outpatient clinic, ICU, ophthalmology, ENT, paediatrics), and the head of each. The seed practitioner data comes from the hospital HR database, exported and ingested.

Day 4–5. Initial user provisioning. Practitioners get invitation emails. Most use Mobiil-ID; a few use ID-card desktop authenticator. By Friday, 47 of 280 staff have logged in at least once — the core team plus interested early-adopters.

Week 1 ends with the customer organisation live, structured, and populated with identity. No clinical data has flowed yet.

Weeks 2–3 — laboratory system bridge configuration

The hospital's in-house lab uses a specific Estonian lab system. Jengu has a configured laboratory system bridge module for this system (the [lab partner routing model] section in the platform memory shows the pattern). The bridge needs to be configured for this hospital specifically — JDBC connection to the hospital's laboratory system database, the field mappings for the specific schema version they're on, the test catalog mapping to LOINC.

Day 6 (Mon week 2). The hospital's IT director carves out a read-only JDBC user against a replica of the lab database. The credentials are stored in the hospital's edge secret store (one of the two edge appliances being shipped this week). The bridge is configured on a Jengu appliance operating from a developer laptop on the hospital network temporarily.

Day 7–10. Field mapping. The hospital's lab catalog has ~340 test codes; mapping to LOINC requires going through each one and either picking a direct LOINC match or marking it as a local-only code with no public mapping. About 270 map directly; 40 map with ambiguity; 30 are local-only. The CMIO and the lab lead spend a couple of half-days on this mapping with Elin.

The test catalog mapping lives in the organisation's project-setup git repo — auditable, version-controlled, reviewable. PRs against this file go through hospital + platform review.

Day 11–14. Trial flow. Test orders move from the hospital system → through the bridge → to the analyzers → results return → through the bridge → into the organisation's record. The flow runs in shadow mode for the second half of week 3: real lab activity, captured by the bridge, written to a side database for review. No clinical action on the bridge data; the hospital's existing systems remain the authoritative path.

End of week 3. The shadow flow has captured ~600 test events. The CMIO and lab lead spot-check 50 of them; correctness rate is high but with three mapping issues identified. Mappings adjusted in the git config. Within an hour, the corrected mappings are live on the bridge.

Week 4 — edge bring-up and staff training

Two edge appliances arrive at the hospital — one for the medicine ward (where the morning round will be), one for the outpatient clinic (where the planned soft launch will run).

Day 15–16. Edge enrollment. Each edge is paired to the customer organisation via the headless enrollment flow:

1. Edge reads the enrollment key from its boot config.
2. Edge POSTs to the cloud's enrollment endpoint with the key + a hardware identifier.
3. The cloud creates a PENDING entry visible to the platform admin surface (in this case, Elin's deployment account scoped to the pilot).
4. Elin approves; the edge receives its operating credentials (edge ID, client ID, client secret).
5. The appliance connects to FHIR storage, scoped to that one customer; runs its first config sync; pulls down the organisation's practitioner cache + the active modules.

Both edges enrolled by end of day 16.

Day 17–18. Mobile-edge tablets for the home-care team (a planned second-phase activity) arrive; same enrollment flow; provisioned but not deployed to nurses yet.

Day 19. Training. A 90-minute hands-on session for the planned soft-launch clinicians — three GPs in the outpatient clinic plus the medicine consultant for the ward round. Hands on the tablet; hands on the tablet; record a mock consultation each; review the output; discuss the consent flow with patients.

The trainer is Elin plus a Jengu clinical-engagement lead who has walked clinicians through this experience at two prior customer organisations. The training emphasis is not on features but on the consent surface and the patient conversation around recording.

Day 20. Final pre-soft-launch checks. The CMIO walks through the audit surface, the medication-adherence dashboard, the patient- side portal preview. Three open items get added to a punch list for week 6.

Week 5 — soft launch

Monday week 5. The three GPs start using Jengu in the outpatient clinic. Their first day each is ~6 patients; the consent conversation is explicit and patient-by-patient; recording is opt-in. Five of six accept the first day; pattern continues.

The medicine consultant's first ward round is Tuesday morning. The tablet is in place; the team has practiced. The round captures six beds; outputs reviewed in detail with Elin after.

The first soft-launch week generates ~80 visit recordings across the GPs and ~30 ward-round episodes. Each one is reviewed by the clinician before publication; about 15% have edits before the patient-facing summary is published. This rate is consistent with prior customer organisations in their first week.

The CMIO meets with Elin on Friday. Review:

• Three clinicians have specific complaints about the smart-action surface (it's surfacing too much for routine consults). Tuning needed.
• The ward round nurse handover surface needs configuration — the hospital's existing handover sheet has fields that aren't surfaced.
• One patient asked to delete a recording after the visit; the retraction surface worked correctly but was slower than the patient wanted.

Three workable issues. None are showstoppers.

Week 6 — wider launch

Monday week 6. Soft launch continues; six more clinicians added across two departments. The medicine ward goes to twice-daily rounds. The first patient-portal correction surfaces (one patient finds a wrong dose in his summary — see patient-timeline-portal).

By Friday of week 6, ~22 clinicians are actively using the platform across the outpatient clinic, the medicine ward, and the ED (added Thursday). The lab bridge is in production for both ordering and result flow. Patient portal access is enabled.

The hospital is live. The pilot has begun. The next phases — roll-out across remaining departments, edge deployment to home- care team, surgical and anaesthesia modules — are planned over the next three months.

What the six weeks really demand

The technical lift is real but bounded. What's harder, and what the timeline measures, is the operational discipline:

• Day-by-day execution against a 6-week plan. Slipping one week somewhere usually slips the whole plan by two.
• CMIO time. The local champion's hours are the rate-limiting resource. A CMIO who can give 8 hours a week makes this work; one who can give 2 hours a week does not.
• IT director cooperation. JDBC user provisioning, network allow-lists, certificate handling, edge appliance install permission. Each of these is small; in aggregate they require IT-side ownership.
• The lab catalog mapping. This is unglamorous and high-value. Skipping it means lab results show up with the wrong codes, which means the trajectory aggregator doesn't compose them correctly, which means the trajectory view doesn't work right.
• Clinical-leadership credibility. The CMIO and the participating clinicians need to be able to say to peers "this is a clinical tool, not an IT project". The training emphasis on consent and conversation supports this.

The platform has matured the technical components — bootstrap, laboratory system bridge, edge enrollment, training material — over the prior two customer organisations. The matured components are what makes six weeks possible. The customer organisations before this one took 11 weeks and 9 weeks respectively.

Why this matters

Hospitals are not single decisions. They are organisations with schedules, vendors, contracts, training programmes, IT change windows, and clinical politics. A pilot that takes six weeks from contract signing to first live use is short by hospital-IT standards (typical is 3–6 months for an EHR integration project). Compressing that timeline by a factor of three is both a commercial advantage (more pilots per year) and a clinical-engagement advantage (the momentum from signing the contract is still present when the first clinicians touch the system).

The story runs the whole customer lifecycle end to end: from git push adding a new customer organisation to a production hospital generating audit-grade clinical recordings. Every primitive on the platform side is touched. Every operational discipline on the hospital side is required.

The scene

A small-town clinic's practice system sends an order for a TSH to the regional hospital it contracts with. The hospital's lab runs its analyzers behind the Jengu Order Hub; the incumbent laboratory system was decommissioned for this satellite bench and nothing replaced it — for this bench, transport is all that's needed.

The order arrives on the hospital customer organisation's ordering surface as a FHIR ServiceRequest: LOINC-coded, the clinic's order number preserved as an identifier, the immunoassay analyzer named as performer by the routing configuration.

The hub's dispatch pass picks it up: the analyzer's operator is live, the order is submitted in the analyzer's own protocol, the ServiceRequest flips to in-progress with the operator's tracking id stashed for correlation.

Twenty minutes later the analyzer transmits the result. The operator translates it to a LOINC-coded FHIR Observation whose basedOn references the order. The hub's result pass matches it — identifier-strictly: had the reference pointed at any order not on this customer organisation's surface, the result would have been rejected and nothing written. It matches; the Observation is stored, the ServiceRequest flips to completed, and the result returns to the clinic over the channel it ordered through, carrying the clinic's original order number unchanged.

What the platform had to do

• Accept an order from an outside system and keep that system's own order number on it, so the result comes back carrying the number the sender recognises.
• Carry the order all the way through — accept, route, dispatch, match the result, close — with no laboratory system installed, and record every step.
• Keep all of that state in the customer's own records rather than in the platform, so a laboratory system can take the work over later without anything having to be migrated.
• Refuse any result that does not match an order it knows about.

Why it matters

This is the Order Hub's product floor: the hub is sellable as pure transport (devices integration, order gateway, integration hub) precisely because the lifecycle works with the laboratory system seat empty. Every higher configuration — a customer's laboratory system, a Jengu module — replaces this default rather than depending on it.

The scene

Tuesday morning at a regional hospital. The production system places routine orders through the Order Hub; the immunoassay bench runs them; results return. Business as usual.

In a vendor's office across the country, an integration engineer points their test laboratory system at the same hospital's hub — using the test credentials the hospital issued. They place a TSH order. The hub stamps it with the test environment the credentials are bound to — the engineer never chose an environment, and could not have chosen production: their credentials cannot say it.

The order routes exactly as a production order would — same service tree, same routing decision — but the analyzer's operator is bound to production, so the test order does not execute there; it reaches the analyzer's emulated twin instead, which runs the full plumbing and produces a synthetic result. The result comes back tagged test, matches only the test order, and returns to the vendor's test laboratory system carrying their own order number.

Meanwhile a sloppy detail surfaces: the vendor's system hardcodes "P" (production) in the wire's processing-ID field, as many systems do. The hub accepts the message into the test environment — the credentials decide, not the field — and raises an alert so the mismatch is visible at integration time rather than discovered later. Had the direction been reversed — test-marked content on production credentials — the hub would have rejected it outright: nothing marked non-production ever enters production.

What the platform had to do

• Tie every account and every connection to exactly one environment — test or production — decided by the credentials used, and carry that with the order from end to end.
• Trust the environment only in the safer direction: if the instrument says "test" and the order says "production", treat the order as test and say so loudly. Never the other way round.
• Match results to orders only within the same environment, and dispatch only within it.
• Scope every record and every search the same way, so a test run is invisible to production and the reverse.

Why it matters

The bench exists once; laboratory system environments are many. This story is the mechanism behind "nothing adopted now is throwaway": a successor system develops and rehearses against the real bench and partner network the incumbent runs on — which is a capability an laboratory system-embedded connectivity layer structurally cannot offer.

The scene

A clinic orders a lipid panel from the regional laboratory. To the clinic that is one order: one request, one specimen, one thing to wait for.

A lipid panel is not one measurement, though. It is four — cholesterol, triglycerides, HDL and LDL — and the laboratory's service catalogue knows that. As the order arrives, the platform looks the panel up and creates one job per measurement, each inheriting the specimen and the environment of the order it came from.

From there each job travels on its own. Cholesterol and triglycerides go to the chemistry analyser, HDL to a different instrument, LDL is calculated rather than measured. Nothing in that journey needs to know the four belong together — each is routed by the laboratory's own rules, to whichever bench or partner does that test.

The results come back the same way, one at a time, each matched to the job that produced it. When the last one lands, the platform gathers them into a single panel result on the original order and marks it complete. The clinic sees what it ordered: one order, one result.

What this asks of the platform

• Recognise a panel and split it into its measurements as the order arrives, using the laboratory's catalogue rather than anything hard-coded — and split it once, however many times the order is retried.
• Send each measurement wherever that measurement is done, and never send the panel itself anywhere. The panel is the clinic's request; it is not a job an instrument can run.
• Report the panel finished only when every measurement in it is in, assembled into one result on the order the clinic placed.

Why it matters

Panels are how laboratories actually sell tests — a lipid panel, a CBC, a metabolic panel — but benches work per analyte. Splitting the clinical ask from the unit of device work lets each side keep its own shape: orderers deal in panels, connectors deal in analytes, and the hub in between stays domain-neutral transport that never needs a release when a panel's composition changes — that is a catalogue edit in git.

The scene

10:00 Thursday morning. The quality officer at a regional hospital in northern Estonia, Tiina, receives a formal letter from Terviseamet. The letter references a complaint filed by a patient's family member about the management of an inpatient admission in February. The Health Board requests the audit trail for this patient's care over the twelve months preceding the complaint, and specifically for the in-hospital encounters during the February admission.

The request specifies:

• Patient: by national ID, named in the letter.
• Time window: 2025-02-04 to 2026-02-04.
• Specific encounters: the inpatient admission from 2026-02-01 to 2026-02-07.
• Scope: all access events to the patient's record, all modifications, all AI-generated content with provenance, the identity of every clinician who interacted with the record.
• Format: signed export, with cryptographic verification chain.

Tiina has seen this kind of request before. Pre-Jengu, fulfilling it took weeks — the hospital's prior EHR system logged access events but in a form that required IT support to extract; AI- generated content (a recent addition before the complaint) had its provenance only loosely tracked; identifying every clinician who touched the record involved cross-referencing several systems.

She opens the audit response surface in the hospital's customer organisation.

The query

AUDIT RESPONSE — Health Board investigation
══════════════════════════════════════════════════════════════════
PATIENT
  National ID:   xxxxxxxxxxx
  In customer organisation:     hospital-id

TIME WINDOW
  From:  2025-02-04 00:00 (12 months back)
  To:    2026-02-04 00:00 (date of complaint)

SCOPE
  ☑ All access events to this patient's record
  ☑ All modifications (clinical, administrative)
  ☑ All AI-generated content with full provenance
  ☑ All clinicians and roles who interacted with the record
  ☑ Every data flow crossing to another customer (in or out)
  ☑ Consent events and any consent changes
  ☑ Patient-initiated actions (portal usage, corrections, etc.)
  ☐ Audio recordings (separate consent + privacy review;
     reserved for explicit Health Board request)

FORMAT
  ☑ Signed PDF report (human-readable, ~30-50 pages)
  ☑ Structured JSON export (FHIR + audit-extension format)
  ☑ Cryptographic verification chain
  ☑ External attestation receipts (independent verification)

[Generate audit package]    [Save query]

She fills in the patient's national ID (from the letter). The time window auto-derives from the complaint date. The scope is the standard Health Board scope, with audio recordings held back pending explicit request (audio is privacy-sensitive and not typically requested unless specifically relevant).

She clicks Generate.

What gets generated

The audit package is built. It takes about four minutes.

The structured JSON export contains:

• Access events. Every time anyone read this patient's record. Each entry: who (clinician + role), when (down to the second), what (which fields or which resources), context (which encounter or which administrative action it was associated with).
• Modifications. Every change to the record. Each entry: who, when, what (before/after diff), reason (where captured). This includes the change nobody at the hospital made: when a platform release brought the hospital's stored records up to a newer shape — something each hospital switches on in its own configuration, after reading a dry-run report — the rewritten record carries a provenance entry naming what converted it, when, and from which version. "Why does this order say what it says" has the same answerable shape whether a clinician or an upgrade wrote it.
• AI-generated content. Every AI summary, draft order, smart- action suggestion, with full provenance: which model, which inputs, which prompts (templated), which version, who reviewed and accepted (or rejected).
• Cross-customer organisation flows. Lab results in (from the partner lab), prescriptions out (to the national health information system), dispense events in (from the national health information system), any referrals.
• Consent events. Initial consent at registration, any updates, the per-encounter consent flags.
• Patient-initiated actions. Patient portal logins, corrections, requests.

The signed PDF report is human-readable: 47 pages of structured narrative organised by encounter, with a summary section up-front and full detail in the back. Every entry has its internal reference ID for cross-checking against the JSON export.

The cryptographic verification chain is the most investigator-visible part:

AUDIT PACKAGE — Cryptographic Verification
══════════════════════════════════════════════════════════════════
This audit package was generated on 2026-04-25 10:14 EET by:
  Quality Officer Tiina M. (signed: Mobiil-ID)
  At customer organisation: hospital-id
  Against patient: (national ID), time window above.

Package SHA-256:    e4f23a...8c91
Tenant signature:   (Hospital's FHIR storage project signing key)
Platform signature: (Jengu cloud signing key, scoped to this customer organisation)

INDEPENDENT ATTESTATION RECEIPTS
─────────────────────────────────
Anchor 1: external timestamping service A
   Receipt ID:    TS-A-2026-04-25-09:14:23-...
   Anchor SHA:    e4f23a...
   Confirms package existed and content was unchanged as of
   2026-04-25 10:14:23 EET.

Anchor 2: external timestamping service B
   Receipt ID:    TS-B-2026-04-25-09:14:24-...
   Anchor SHA:    e4f23a...
   (Independent confirmation by a second timestamping service.)

VERIFICATION
─────────────
The Health Board investigator can:
1. Compute SHA-256 of the JSON export and confirm it matches.
2. Verify the customer organisation + platform signatures against the published
   public keys (linked below).
3. Verify the timestamping receipts against the two timestamping
   services' published verification endpoints.
4. Confirm that the audit-internal sequence numbers form an
   unbroken chain (no missing entries, no insertions after-the-
   fact).

Verification documentation: https://jengu.cloud/audit/verify

The package is downloaded as a single ZIP. Tiina cover-letters it and sends it to the Health Board via the registered secure-mail channel.

She has spent about 75 minutes total. Of that, the audit-surface work was 12 minutes; the rest was reading the letter, internal discussion with the medical director, writing the cover letter.

What the investigator does

Linda, the Terviseamet investigator, receives the package later that morning. She opens it. The PDF is well-organised; she reads the summary section, identifies which encounter she wants to dig into first (the February admission's day 3, where the family member's complaint centres).

She turns to the structured JSON and pulls up the day-3 events. She sees:

• Morning ward round at 09:20 with three named clinicians (signed digital signatures).
• An AI-generated patient summary at 10:05; reviewer's accept signature at 10:11.
• A medication change at 10:23: dose reduced; reason field captures the clinician's voice transcript "patient developed bradycardia, reducing dose".
• The bradycardia event itself logged at 09:45 (vitals monitor capture; reviewed and acknowledged).

This is what the family member was unsure about — the medication change wasn't explained to them at the time, and they thought it indicated something had gone wrong. The audit trail shows the sequence: the bradycardia was noted, the dose was reduced as a response, the change was discussed on the round (with the clinician's voice captured). The clinical management was documented in real-time, not reconstructed afterward.

She also verifies the cryptographic chain. The SHA matches; the customer organisation + platform signatures verify; the two timestamping receipts both confirm the package was anchored at the stated time.

This matters because in a complaint case, the question "could this audit trail have been edited after the fact?" is always implicit. The cryptographic anchoring answers it: anything in the package existed in the form shown, at or before the timestamp on the receipts. Any post-hoc modification would require breaking both timestamping services and forging two external signatures, which is not feasible.

Linda spends the next several days reviewing the package, asks one follow-up question (a clarification on a specific nurse-handover note), and ultimately concludes that the clinical management was appropriate. The complaint is closed without further action.

What's NOT in the package

Two things are deliberately not in the package:

1. Audio recordings. Voice recordings of the ward rounds, the consultations, and the team discussions are not in the package. They were captured and retained, but they require a separate Health Board request that includes specific justification and a privacy review. The patient consent for recording does not extend to "any future investigator can listen". This is intentional: audio is the highest-fidelity record of clinical conversation, but also the most privacy- sensitive.

2. Records of other patients. Even when other patients were discussed in the same ward round or were in the same bay, their records are not in the package. The audit surface scopes strictly to the patient named in the request. Cross-references (e.g., "discussed in bed 4 round") are anonymised in the package.

This scoping is enforced at generation time; it can't be bypassed even by the Tiina-as-quality-officer role. To get beyond it requires a different scope of Health Board request, explicitly authorising the broader access.

Why this matters

Healthcare investigations are inevitable. The question is whether the audit trail makes them easier or harder, more trustworthy or more contested. In most healthcare systems today, audit trails exist but are:

• Fragmentary. Different sub-systems log differently; pulling them together is manual.
• Not provenance-aware for AI content. AI-generated summaries and drafts are produced by clinical-AI tools but the provenance (which model, which inputs, what prompt) is usually not captured in a way the audit can show.
• Vulnerable to post-hoc editing. Audit logs without cryptographic anchoring can be edited; in some scandals they have been.
• Time-consuming to extract. A week of IT-and-quality- officer work for a single request is not unusual.
• Over-scoped or under-scoped. Either too much PHI is shared (because scoping is imprecise) or too little (because the system can't extract specific things).

A platform-native audit surface with cryptographic anchoring, AI-provenance capture, precise scoping, and one-click generation collapses the timeline from weeks to hours and makes the audit trail more trustworthy at the same time. The hospital's reputation, the patient's family's understanding, and the regulator's investigation all benefit.

The pattern matters culturally too. Clinicians sometimes worry that a high-fidelity audit trail will be used against them in complaint cases. The structural reality is the opposite: when clinical decisions are well-documented and provenance-traced, the audit trail typically defends the clinician by showing the decision was reasonable in the context known at the time. It is missing audit that makes clinicians vulnerable to claims they cannot rebut.

The scene

A health centre runs a Jengu edge appliance in a comms cupboard: a Pi with an NVMe disk, the official power supply, a network cable. The box has worked unattended for months, and it will keep working unattended for years — through a failure that needs it rebuilt, and through the releases that will move underneath it.

The practice has a receptionist, three GPs, and a head nurse who is "the person who restarts the router". There is no monitor attached to the box, no keyboard in the building that fits it, and nobody who has ever seen a Linux prompt. Every guarantee below exists because that is who is standing next to the hardware.

The rescue

The customer organisation admin — off-site — opens the Device Hub's edge page and downloads the organisation's installer. The download is a folder of files extracted onto any USB stick; the admin uses the one in their drawer, writes it, and sends it over with the morning courier. The stick carries a time-boxed authorisation minted at download: it proves this installer is genuine and recent, and it will expire — a stick found in a car park months later is a brick.

The nurse's entire procedure:

1. Insert the stick into the box.
2. Pull the power cable, plug it back in.
3. Wait.

What the platform guarantees underneath — each the answer to a way this exact procedure has failed on real hardware:

• The stick gets power at boot. The appliance EEPROM assumes a full-current supply, so the stick enumerates during cold boot instead of silently losing to a boot-time USB power cap.
• The firmware waits for the stick. A nurse who replugs the cable quickly leaves the stick's controller un-reset, and it can take longer to enumerate than the firmware's default discovery window — the boot would silently move on. The appliance EEPROM extends the window so a slow stick is still discovered rather than losing the race to the resident system.
• The stick's system is the one that boots. The resident NVMe still looks like a perfectly bootable Alpine system; the installer evicts it from every discovery decision — overlay, package repository, kernel modules — so the rescue cannot frankenboot into the broken installation it came to replace.
• The box rejoins as itself. The hardware id is the identity: a known box on a valid installer token rebinds unattended to its existing fleet entry — name, department binding, devices, module enablement all survive; only the secret rotates. No cloud-side click is needed for a rescue; a first-ever enrolment still gets its human approval.
• No console at any point. The installer's packages provision their own services and system accounts, and a boot with no per-device configuration lands in enrolment-only mode — nothing in the first boot assumes a pre-prepared system or a person at a keyboard.
• Pull the stick and it comes up working, by itself. The box keeps its USB-first boot order (that is what let the stick boot in the first place, and it stays the recovery entry point). After the install the courier does not reboot into itself — it waits for the nurse to pull the stick, then warm-reboots into the freshly installed NVMe slot on its own. No second power-cycle, no timing games — and because the courier only ever reboots into the slot (never into itself), the box can never spin in an install loop.
• The fleet tells a remote operator which box is waiting. When the rescue is driven from afar — nobody standing at the Pi — the fleet page shows the box, by name, as "running on its installation medium — pull the stick to enter working mode," refreshed while it waits and cleared once it comes back up in working mode. The prompt only appears for a box the fleet already knows (a re-rescue of an enrolled box), so even when several boxes are being worked at once the operator is told exactly which stick to pull, never an anonymous one.
• Failure is visible, not silent. If the boot goes wrong the screen says so (the boot transcript is kept), and the cloud distinguishes "installer issued but never presented" from "nothing ever happened".

The admin watches the fleet page: the box reappears, same name, online. The stick goes back in the drawer.

The healthy-box variant

Months later the same box needs a clean reinstall — nothing is broken, the software should simply be laid down fresh. Nobody weakens the boot order for that: the nurse inserts the stick into the running box, the fleet row grows an "Installer inserted" badge, and the admin clicks Reinstall from inserted stick. The cloud lends the stick exactly one boot (the firmware's one-shot boot-order override, consumed on use); the box reinstalls, rebinds to its own fleet entry, and the next boot returns to the internal disk by itself — even with the stick still in the slot. The row's boot-medium chip is the receipt: usb exactly once, then nvme again.

The courier variant

The stick the courier drops off is getting lighter. The original rescue medium carried a whole operating system; the courier is a netinstall medium — boot files and the signed enrolment data, nothing more. Inserted and powered on, it provisions the disk and fetches the system as packages from the organisation's cloud, laying it into a fresh slot; there are no installed-system bytes on the stick to go stale, and which OS the box gets is decided cloud-side. Its rescue sequence is fixed — capture what was there, reinstall, restore /data, rejoin — and it will not touch anything destructively before the capture is safely taken. It captures the resident /data to the box's own backup partition first, reinstalls the system fresh from the cloud into a slot (leaving the backup and data partitions untouched), and puts /data back — in place when it survived, from the just-taken capture when it did not. So a populated box — the real rescue case — comes back with its local store intact and no clicks; a blank box it installs end to end all the same, rejoining under its own token. The same capture runs before an in-place system update — a failed capture aborts the update.

Keeping the fleet current

Months later nothing is broken, and the box is simply behind. A new release is pinned for the customer organisation, and it has to reach every clinic without anyone visiting one.

From the edge's drill-down panel the admin sees the installed version against the organisation's pinned release (the declared target — git config owns which release a customer organisation should run). When they differ and the edge is reachable, the panel offers a single Update action to that release. There is deliberately no commit step and no countdown: the health-gate decides, edge-side, and the panel simply reflects the outcome — updating, then up to date or fell back with the reason. A stale or double click cannot stack a second update: the launch gate is re-derived server-side, and an update already in flight is refused.

Undo without pressure lives in the same panel: restore a chosen backup bundle — the deliberate rollback, distinct from the automatic fall-back.

How the instruction reaches the box

The Update button does not talk to the edge. It queues a fleet task, and the box collects it on its own poll — the only direction that works behind a clinic's NAT, where nothing outside can open a connection inwards. The admin's click, the box's collection and the box's report are three separate moments, and the panel is honest about which have happened.

That separation is also where the channel can fail quietly. A task queued and acknowledged but never collected leaves the panel truthfully reporting a request nobody received. This happened: on bench-pi-1 (2026-07-25) an apk-upgrade never arrived at an online, heartbeating edge, because the task's for reference held a fleet id FHIR storage's reference search could not match and the poll endpoint's catch turned the failure into a healthy-looking empty list. Every leg was unit-tested; the whole had never worked, which meant no fleet task — reboot, upgrade, rollback, reinstall — had ever been delivered in the field. So the platform's promise is the round trip, not the click: a task queued for an enrolled edge is delivered to that edge's poll and its completion lands on the task record, and queueing for an edge the fleet does not know fails loudly rather than handing back a success handle to a task nobody will ever collect.

The box too old to be spoken to

A box that has been offline for a long upgrade cycle may speak a connectivity protocol a major version behind the cloud's. It is not turned away and it is not humoured: the handshake answers UPDATE_REQUIRED, naming the bundle coordinate to fetch and the target protocol, and closes the incompatible channel rather than degrading into a half-working session where some frames are understood and others are silently dropped. The box then pulls the named bundle over HTTP — outside the broken channel — swaps it, self-checks its new uplink, and reconnects speaking the compatible protocol. It self-heals over the wire; nobody drives to the site and nothing is re-imaged.

Why this story matters

This work began with the opposite experience. A real appliance was rebuilt, restarted, and quietly came back running the old software — and finding that out took an engineer with deep knowledge of the device. Every guarantee above was written in response to that failure, and proved on real hardware before it became a promise.

Why the update reads the way it does

The superseded single-slot model asked the admin to confirm before an auto-revert timer expired — a race the off-site admin could lose. The A/B gate removes the race: safety is automatic and local, so the cloud never prompts for a commit. The UI's job is to make the automatic outcome legible, nothing more. The cloud observes the gate; it never drives it.

The scene

Wednesday 10:20 at a primary-care clinic in Pärnu. The patient, Mart S., 42, has been losing weight unexpectedly over the past three months and feels tired most afternoons. His GP, Dr. Ojaste, takes a history, examines him, finds nothing obvious. She wants a broad screen: CBC + differential, comprehensive metabolic, TSH + free T4, ferritin, vitamin D, HbA1c, CRP, urinalysis with culture if leukocytes, and a coeliac panel.

She places the order during the consultation:

ORDER — Mart S. — fatigue, unintentional weight loss
══════════════════════════════════════════════════════════════
☑ CBC with differential
☑ Comprehensive metabolic panel
☑ TSH + free T4
☑ Ferritin
☑ Vitamin D 25-OH
☑ HbA1c
☑ CRP
☑ Urinalysis (reflex culture if leukocytes)
☑ Coeliac panel (tTG-IgA, total IgA)

Routing:    Partner lab (Tallinn) — usual carrier
Priority:   routine (1-2 day)
Specimens:  blood × 3 tubes; urine × 1
Order ID:   ORD-2026-04-22-PA-009482
─────────────────────────────────────────────────
[Confirm]   [Print labels]   [Schedule pickup]

She confirms. The label printer (next to the exam table) prints specimen labels. Each label has the order ID, the specimen type, the collection date and time, and a 2D barcode. There is no patient name on the label, no patient ID, no date of birth. Just the order ID and specimen details.

The phlebotomist collects the specimens, applies the labels, places them in the transport pouch. The transport pouch is also labelled with the order ID — no patient info.

What the lab sees

The transport courier picks up at 13:00. The specimens reach the partner lab in Tallinn at 14:45. The lab receives:

INBOUND — Pärnu route — 14:45
Order ID:    ORD-2026-04-22-PA-009482
Origin:      Pärnu-Tervis (customer organisation: parnu-tervis)
Specimens:   3 × blood tubes (purple, gold, red), 1 × urine cup
Tests:       CBC+diff, CMP, TSH+fT4, ferritin, vit D 25-OH,
             HbA1c, CRP, UA (reflex culture if leuk), coeliac panel
Priority:    routine
Pickup:      Pärnu courier — 13:00 — temp logged

[ACCEPT INTO LAB]   [REJECT — specify reason]

There is no patient information visible to the lab. The lab does not know whose blood it is processing. It knows the order ID, the ordering customer organisation, the test list, and the chain-of-custody information.

This is the lab-without-patient-identity model. The lab operates on specimens and orders; the identity mapping lives entirely on the ordering customer organisation's side. The lab cannot accidentally leak patient identity because it has none to leak; the lab cannot be a target of a re-identification attack via the specimen because no identity is present to re-identify.

The lab accepts the order. Specimens enter the laboratory workflow: the CBC tube goes to the hematology analyzer; the gold-top to the chemistry/immunoassay line; the urine to UA dipstick (reflex culture on positive); the red-top for the coeliac panel.

The analyzers report results in a few hours. Each result is bound to the order ID and the test code — ORD-2026-04-22-PA-009482 : HBA1C : 6.1 %. Some results require analyst review (anything flagged abnormal); a lab tech reviews and releases.

By 18:30 the full panel is complete except the urine culture (needs 24-48 hours).

What returns to the GP

The results panel is bundled and pushed back to the ordering customer organisation:

RESULTS — order ORD-2026-04-22-PA-009482 — partial
Origin:      partner-lab-tallinn
Reported:    2026-04-22 18:30
Tests (partial — urine culture pending):
─────────────────────────────────────────────────────────────
CBC               within range, mild anaemia (Hb 121 g/L) ⚠
CMP               creatinine slightly high, otherwise normal ⚠
TSH               5.8 mIU/L  (1.5× upper)  ⚠
Free T4           14.2 pmol/L  (normal)
Ferritin          18 μg/L     (LOW, suggests iron deficiency) ⚠
Vitamin D 25-OH   42 nmol/L   (insufficient)
HbA1c             6.1 %        (just within prediabetic range)
CRP               4 mg/L       (just elevated, non-specific)
Urinalysis        dipstick: leuk +1; nitrite negative
                  → reflex culture sent, result pending
Coeliac (tTG-IgA) 18 U/mL     (LOW positive — borderline)
Total IgA         2.1 g/L     (normal)

[Receive into patient record]

The receiving customer organisation maps the order ID back to Mart S. through its private mapping table. The mapping is purely on the ordering customer organisation's side. The lab couldn't do this mapping if it tried — the mapping table doesn't leave the GP customer organisation.

The results land on Mart's record. The trajectory aggregator updates. The smart-action surface drafts a follow-up plan:

DRAFT — follow-up for Mart S.
─────────────────────────────────────────────────
Findings (consensus across panel):
  - Iron deficiency anaemia (ferritin 18, Hb 121)
  - Subclinical hypothyroidism (TSH 5.8, fT4 normal)
  - Borderline-positive coeliac serology
  - Vitamin D insufficiency
  - Mildly elevated CRP, mildly elevated creatinine

Suggested actions:
  ☑ Schedule follow-up consultation within 1 week
  ☑ Discuss coeliac investigation (endoscopy + biopsy)
  ☑ Iron supplementation pending coeliac result
       (treatment of suspected cause first)
  ☑ Repeat TSH in 6 weeks
  ☑ Vitamin D 2000 IU/day OTC
  ☑ Recheck creatinine + UA culture once available
  ☐ Refer to gastroenterology (if coeliac confirmed)

The pattern of findings is consistent with coeliac disease. Iron deficiency + borderline coeliac serology + subclinical thyroid abnormality + persistent fatigue and weight loss. The smart-action draft is conservative — it doesn't auto-refer; it surfaces the referral as an unselected option pending the next consultation.

The phone-between-consultations check

Dr. Ojaste is in another consultation when the results land. Her phone vibrates — Jengu notification, "Mart S. results in, abnormalities flagged". She doesn't look at it then.

At lunch, 13:10, she pulls out her phone. Opens Mart's result in the mobile app. Reads the panel; agrees with the consensus picture; agrees with the suggested actions. She messages Mart via the in-app messaging:

"Tere, Mart. Tulemused on tagasi tulnud. Mõned asjad on, mis tahaks järgmisel nädalal arutada — võtaks 30 minutit. Kas Esmaspäeval 16:00 sobib? Iseennast tunnete nüüd kuidas?"

Mart replies five minutes later (he sees the message at work): "Sobib. Tunnen sama, aga ma ootan kohtumist."

The Monday consultation is booked. The consultation will open with this morning's lab review.

The urine culture returns negative the next morning. The result joins Mart's record. The smart-action surface drops the "recheck UA culture" from the active list.

Why this matters — the no-patient-identity principle

There is a strong version and a weak version of this design.

The weak version says: lab UIs don't show patient names because that's not the lab tech's job to know, but the lab system could know if it had to. The mapping lives in the lab database under access control.

The strong version, which is the platform's design, says: the lab system holds no patient identifiers at all. Not in the worklist, not in the analyzer integration, not in the database, not in the archive. The mapping table is on the ordering customer organisation's side. The lab has order IDs, specimen IDs, test codes, and results.

The strong version has consequences:

• GDPR. The lab is not a data processor for patient identity, because it processes no patient identity. The data processing agreement (DPA) shape changes — possibly no DPA needed for the patient-identity dimension; the lab's processor relationship is to the specimen and order data only.
• Breach impact. A breach at the lab — disk image stolen, database dump, ransomware exfiltration — yields no patient identifiers. The attacker gets order IDs and test results, but no name, date of birth, or any way to re-identify without also breaching the ordering customer organisation.
• Aggregation safety. Multi-lab quality programmes, comparison of result distributions across labs, performance benchmarking — all of these are fine to run on lab-side data without any privacy concern, because there is no privacy data in the lab.
• Operational simplification. The lab's audit obligations shrink. The lab's IT security obligations shrink. The lab can be operated by smaller teams with smaller compliance overhead.

The weak version protects nobody from a determined adversary or an internal mistake. The strong version is structurally safer.

The cost is that the lab cannot do the things that require patient identity — for example, calling a patient directly with a critical result. Critical results return through the ordering customer organisation; the ordering clinician handles the call. This shifts work but doesn't remove it.

What about the partner lab being a competitor?

Estonia's lab market has multiple commercial operators. A GP customer organisation routes to a particular partner. The partner may also be ordering from the same population through their own competing GP network. The strong identity-isolation model means the partner lab cannot cross-link its own GP-network orders to its partner-network orders — there's no patient identity to link on.

This matters for a hospital-network commercial relationship where trust is partial.

The scene

Tuesday morning, 08:55, internal-medicine ward at a regional hospital. Six beds in the bay. The team is gathering at the nurses' station: Dr. Karm (consultant), Dr. Lokk (year-3 registrar), Dr. Veski (year-1 registrar), Liina (4th-year medical student), and the day-shift nurse Tiia.

Dr. Karm picks up the ward-round tablet from the station. On its screen, the ward round view shows the six beds in order, each with the patient's identity, primary diagnosis, length of stay, key overnight events flagged by the night shift, and a colour stripe indicating the consultant's "needs attention" tagging from the afternoon before.

Ward Round — Internal Med Bay 4A — Tue 08:55
══════════════════════════════════════════════════════════════════════════
1  F 72, day 4    CAP                  ↑ T 38.7 overnight
2  M 68, day 2    AECOPD               desat to 89 at 04:00 → O2 titrated
3  M 55, day 7    pancreatitis         lipase ↓ 412→201 ✓
4  M 81, day 11   HF exacerbation      fluid balance +800 mL ⚠
5  F 78, day 3    UTI/delirium         settled with quetiapine
6  M 49, day 1    cellulitis           admitted 22:30, awaiting culture
══════════════════════════════════════════════════════════════════════════
[Start round]   [Order from station]   [Open patient]   [⚐ Reveal identity]

The tablet shows bed positions, demographics, and clinical context — no names. Dr. Karm and the team have been treating beds 1–5 for days; they carry the bed-to-person mapping in their heads. Bed 6 is new overnight; the consultant will reveal identity once at first bedside contact to introduce herself, then mental mapping takes over for the rest of the stay. The Reveal identity tool sits on every bed card and every patient-bound action; it is opt-in, audited, transient.

Dr. Karm taps Start round. The session opens; speakers are identified by their pre-login on the tablet and their voiceprints from the team-onboarding step done at the start of rotation; the round clock starts.

Recording boundary

A note on what is being recorded, because the rest of the story depends on it.

The platform rule is one the live video service room per bed-visit. Each bed on this morning's round is its own room with its own consent, its own access list, its own retention. A room is the recording service's trust boundary, full stop.

A ward round is not itself a recording — it is a cohort container that groups the bed-visit rooms together. When Dr. Karm tapped Start round, the platform opened an additional, team-only room: the off-bed huddle. Patients are not participants in the huddle; only the team — Dr. Karm, Dr. Lokk, Dr. Veski, Liina, Tiia — is in it. The huddle is what records the conversation in the corridor between beds, at the nurses' station, on the walk from bed 3 to bed 4. It is the round's default recording target whenever no bedside room is active.

Three states, then, and the tablet chrome makes them unmistakable from 1.5 metres in fluorescent ward light:

• HUDDLE LIVE — between beds. Team only. No patient in scope.
• BED N LIVE — at a specific bedside. Patient is a participant. A small patient-facing recording indicator is visible to the patient (back-of-tablet LED + the doctor turning the screen toward them), not only on the team's view.
• ROUND PAUSED — neither huddle nor any bed is recording. An explicit team-decision state, used in the bed-5 case below.

Exactly one of these is true at any instant during the round. The recording service enforces this server-side; a second concurrent recording in the same round container is rejected and audited. A UI bug cannot turn it into a privacy leak.

The auto-switch is the orchestration that makes the round usable: tapping a bed card pauses whichever room was active (almost always the huddle) and starts that bed's room. Pausing or ending the bedside switches the active target back to the huddle. The consultant does not confirm "switch from huddle to bed 3" mid-round — one tap, one switch, one auditable transition.

Each bed's room and the huddle are separate FHIR Encounters under a parent round Encounter (class=IMP, type=ward-round). The huddle Encounter has the same parent but no patient subject — it is structurally invisible to any patient-timeline query. The team-only access list is a frozen roster captured at round-start; it does not inherit any bedside room's patient-scoped policy, and no bedside room inherits the team roster.

Identification boundary

A related boundary, separate from the recording one. The tablet's default display carries no patient identifying information — only bed positions, demographics (age + sex), and clinical context. Names are never persistent in the UI. Anyone glancing at the tablet in the corridor, a passing visitor, an over-the-shoulder look from the next bay — what they see is "bed 1, F 72, day 4, CAP, fever overnight". Clinically meaningful, not identifying.

Identity is doctor-initiated through a Reveal identity tool that lives on every bed card and every patient-bound action. Tapping it opens a short-lived modal showing name (+ DOB / MRN / contact, as the purpose calls for), asks the doctor to pick a purpose tag from a controlled set (verbal-address, family-contact, safety-verification, external-referral, outbound-document, other), and dismisses on a timer or on explicit close. Each reveal emits an AuditEvent with that purpose tag.

For most of this story, no reveal is needed — the team has been treating beds 1–5 for days and remembers everyone by name. The two reveals that do fire are explicit and natural: at bed 6 (new admission, first encounter) for verbal-address to introduce the consultant; and after the round, when Dr. Karm calls bed 5's next-of-kin about the capacity question, for family-contact.

Dialogue at the bedside still uses names — the team speaks them aloud — but those names live in the spoken audio only, get captured in the bedside recording the patient took part in, and are stripped by the anonymisation pipeline before the transcript leaves the recording boundary. The tablet screen never shows them.

This is consistent with the platform-wide invariant in Master Patient Index: identity is never displayed by default on a clinician's screen; identification is a doctor-initiated, purpose-tagged, audited reveal.

At each bed

The team walks to bed 1; Dr. Karm has the tablet in hand. The chrome at the top of the screen reads HUDDLE LIVE — the team is mid-handover from the nurses' station, and the huddle has been recording since round-start. Riin is awake, propped up, mid-coughing fit. Dr. Lokk presents to Dr. Karm:

"Riin Mägi, 72, day 4 of a community-acquired pneumonia. Started on co-amoxiclav. Spiked to 38.7 overnight, settled with paracetamol. CRP coming down — 180 to 110. Sats 94 on 2L. Cough looser today. Still tachycardic at 102."

Dr. Karm taps Start recording at bed 1 on the tablet. That one tap is the room switch: the huddle pauses, bed 1's room opens, a capacity-and-consent check completes against Riin (she is alert, oriented, the consent is for this Encounter and is signed by Dr. Karm with a positive capacity declaration), and the patient-facing red dot lights up on the back of the tablet, visible to Riin. Chrome now reads BED 1 LIVE. Dr. Karm bends down: "Tere, Riin. Kuidas täna tunne on?" Riin answers, shorter, in Estonian; the tablet's mic catches both turns inside bed 1's room. Dr. Karm listens to the chest, says "still some crackles right base, no new findings", and turns to the team:

"Let's continue current antibiotic, repeat CRP tomorrow, and we can start to wean oxygen — try room air, target sats above 92. Physio for chest. Let's plan for discharge Thursday if she's off oxygen overnight."

The tablet's view at this moment is split between the live transcript scrolling at the bottom (Estonian + English, both speakers labelled) and a draft order panel on the right that has been filling in real-time as the consultant talks:

DRAFT ORDERS — bed 1                     [✓ accept all]   [edit]
─────────────────────────────────────────────────────────────────
☑ Continue co-amoxiclav 1.2g IV TDS (no change)
☑ Repeat CRP tomorrow (08:00)
☑ Wean O2: trial room air, target SpO2 ≥ 92%
☑ Physio referral — chest physiotherapy
☑ Plan discharge Thursday IF off O2 overnight Wed→Thu

The student adds something the consultant said but the model didn't catch — Liina taps the transcript line "and let's check her chest X-ray again before discharge" and flags + order: CXR repeat pre-discharge. The order is added to the draft. Liina's identity is the student role from the tablet pre-login, so the order is flagged for supervisor accept; Dr. Karm glances, nods, taps accept.

The team moves to bed 2. As Dr. Karm walks, she taps the bed 1 card off — bed 1's room pauses (it does not end; the round is not over and the team may return), and the chrome switches back to HUDDLE LIVE. Whatever Dr. Lokk says to Dr. Karm in the two paces between beds — "the next one is the one I'm worried about" — is captured in the huddle, not in any patient's room. Tap bed 2; huddle pauses; chrome reads BED 2 LIVE; Anton's consent runs.

The mid-round return

The team is at bed 3 (Mart, pancreatitis). Chrome reads BED 3 LIVE. Dr. Karm wants Tiia's view on Riin's overnight — "did she actually settle after the spike or just fall asleep?" The tablet offers two affordances on the transcript line: tag this utterance as also references → bed 1 / Riin without leaving bed 3's room, or rejoin bed 1 for a proper addendum.

The question is a real clinical decision about Riin, not a side-comment about Mart, so Dr. Karm picks rejoin. One tap: bed 3's room pauses, bed 1's room re-opens (consent already on file for this Encounter — no re-prompt within the round window), chrome reads BED 1 LIVE again. She says "context: came back to Riin to clarify overnight"; Tiia answers; the addendum is captured in bed 1's room at 09:11, attributed to a side-discussion within Riin's bed-1 Encounter, not to Mart's.

Dr. Karm taps bed 1 off as she turns back toward bed 3. The two paces of walking are huddle territory again — chrome reads HUDDLE LIVE — and the team's "OK, so bed 3, pancreatitis" murmur lands there. Tap bed 3; chrome reads BED 3 LIVE; bed 3's room resumes where it paused.

In a real round, the conversation is not linear. Patients are referenced out of order. Decisions about bed 1 happen during bed 3. The room model accommodates this — each bed-visit is its own durable Encounter, the huddle holds the corridor talk that references no single patient, and the mid-round return is a clean rejoin rather than a new room. The UI has to make these switches cheap enough — one tap, no confirmation prompt — that the team uses them instead of leaking everything into one always-on recording.

The fluid balance debate

At bed 4, Erki has gained 800 mL overnight despite IV furosemide. The discussion gets clinical: Dr. Lokk thinks reduce IV fluids; Dr. Karm wants to up the diuretic; Dr. Veski mentions the renal function is worsening — eGFR from 38 to 32; should they be cautious about a prerenal hit. They debate. The patient — Erki — is listening, alert.

The tablet's transcript captures the debate verbatim. The draft order panel does NOT auto-fill during this kind of multi-option discussion — the smart-action model is conservative about ambiguous decisions and waits for a clear instruction. When Dr. Karm finally says "OK, hold the IV maintenance, increase furosemide to 80 mg IV BD, recheck U&E tomorrow, sit out in the chair this afternoon", the order panel populates with that and only that.

The patient summary that will be generated for Erki includes a plain-language version of the plan ("we've changed your water tablet because we want to remove some of the extra fluid; we'll check your kidney function tomorrow") and a flag that the dose change is explicit so the nurse will note it.

The privacy problem

At bed 5, Hilja is mildly delirious. She does not understand that she is being recorded, even though there is a sign on the tablet and on the bed bracket. Dr. Karm pauses for a moment. She taps pause transcript on the tablet; the team discusses Hilja's case quietly off-mic; agreed plan is dictated explicitly back on-mic so the order goes in. The session has a gap in the transcript at 09:34 marked "team discussion off-record, plan dictated".

This is one resolution. Other resolutions: capture and redact, or have a "delirium / capacity unclear" presence model that records voice but does not run AI on it. The pattern is unresolved in v1 — for now the team chooses per-bed.

At bed 6, the patient is new — admitted overnight, hasn't been on a round yet. This is the one bedside where Dr. Karm does not yet have the name in her head. She taps Reveal identity on the bed-6 card. The modal opens:

┌──────────────────────────────────────────────────┐
│  Bed 6 — Reveal identity                         │
│  ─────────────────────────────                   │
│  Purpose: ▼ verbal-address                       │
│  ──────────────────────                          │
│  Karol Jürgens · M 49 · DOB 1976-09-12           │
│  Admitted Mon 22:30 — cellulitis                 │
│                                                  │
│              [confirm]    [cancel]               │
└──────────────────────────────────────────────────┘

She confirms. The modal closes after ~5 seconds; the tablet records an AuditEvent (subtype = identity-revealed, purpose verbal-address, agent Dr. Karm, target bed-6-occupant). She introduces herself: "Tere, härra Jürgens, ma olen Dr. Karm" — recording continues capturing that, anonymisation will strip the name before the transcript leaves. Chrome reads BED 6 LIVE. The whole bed takes nine minutes. The orders are heavier — full admission set, blood cultures back, escalation plan if cellulitis extends. Dr. Karm sets a 48-hour review trigger. The tablet records it.

For tomorrow's round she will not need to reveal again — she has the name in her head now, and the tablet's bed-6 card will still show "M 49, day 2" by default.

End of round

09:57. Round ends. The tablet shows the round summary:

Round complete — 6 beds in 62 min — avg 10 min / bed
═══════════════════════════════════════════════════════════════
        Notes draft   Orders draft   Pt summary
bed 1   ready          5 / 5         ready (et)
bed 2   ready          3 / 3         ready (et)
bed 3   ready          1 / 1         ready (et)
bed 4   ready          4 / 4         ready (et)
bed 5   ready (gap)    2 / 2         held* (capacity)
bed 6   ready          7 / 7         ready (et)

Nurse handover for afternoon shift:  draft ready    [open]

Each note is a draft that the responsible doctor reviews and signs later in the morning. Each order set is a draft that the same doctor (or, by delegation, the registrar) submits to the prescribing/ordering system after a final check. Each patient summary is rendered in Estonian, in patient-friendly register, for the patient to read or have read to them at the next nursing interaction.

Bed 5's summary is held: the model is unsure whether the patient's capacity to read a summary is intact this morning, and surfaces that uncertainty rather than auto-publishing.

The nurse handover draft is a per-bed terse update plus the trigger conditions ("call doctor if bed-1's sats drop below 92 on air", "monitor bed-4's urine output; if less than 30 mL/h call", "bed 6 — cultures expected by 15:00, if positive escalate per plan").

Calling family — the second reveal

10:04. The team disperses. Dr. Karm steps into the staff room. Bed 5's capacity question — the gap in the transcript and the held summary — needs a next-of-kin conversation today; the night-shift note flagged that the patient's daughter had asked to be called. Dr. Karm taps Reveal identity on bed 5's row in her patient list:

┌──────────────────────────────────────────────────┐
│  Bed 5 — Reveal identity                         │
│  ─────────────────────────────                   │
│  Purpose: ▼ family-contact                       │
│  ──────────────────────                          │
│  Hilja Raud · F 78 · DOB 1947-04-22              │
│  NoK: daughter Mari Raud · +372 555 41 207       │
│                                                  │
│              [confirm]    [cancel]               │
└──────────────────────────────────────────────────┘

She confirms, places the call, has the conversation. The modal auto-dismisses on its 30-second timer. A second AuditEvent (identity-revealed, purpose family-contact) lands in the audit feed. By 10:11 Dr. Karm is back to a pseudonymous patient list and walking to her outpatient clinic.

Why this matters

Ward rounds are the spine of inpatient care. They are also the biggest single source of clinical-documentation lag: a 60-minute round generates 60 minutes of decision-making and then 90 minutes of doctors going back to a workstation and typing it up afterwards, during which time some of it gets forgotten or compressed. The typing tax falls on the most expensive, scarcest resource — clinician time.

A round that produces draft notes, draft orders, patient summaries, and a nurse handover as it happens compresses the documentation half of the day. The doctor goes from round straight to seeing outpatients or covering an admission, with the morning's work already captured. The nurse picks up the round outputs without needing the doctor to find her and brief her.

The privacy and capacity edge cases — multi-bed bay acoustics, delirium, patient consent — are real, and the system has to handle them by design, not by assuming patients are like clinic patients.

The scene

It is 02:14 on a Tuesday in northeast Estonia. A ambulance of the regional EMS service is dispatched on a chest-pain call to a private address in Jõhvi. The crew is two: a paramedic in the patient compartment, an EMT driving. Roughly forty minutes' transport to the nearest hospital with PCI capability.

The crew rolls. Inside the cabin: a multiparameter vital-signs monitor, a defibrillator/AED, a portable ventilator, an infusion pump, and the crew's smartphones and a tablet. All of these talk to the jengu-appliance bolted into the vehicle, paired to the EMS service's customer organisation in the cloud. The appliance is connected to the LTE/5G modem under the dash with a 4G failover.

A few minutes after dispatch the appliance receives a session-start signal — either pushed from the dispatch system over its API, or triggered manually by the crew when they tap "Start transport" on the cabin tablet. From that instant onward, the appliance is recording.

What gets captured

The integrated devices report continuously over Bluetooth or medical-device-class serial / Ethernet:

• Vital-signs monitor: 1-Hz heart rate, blood pressure cycles, SpO₂, respiratory rate, ECG waveform (high-rate, downsampled for transport), temperature.
• Defibrillator: standby/armed/shock-delivered events with rhythm strips around the event.
• Ventilator: settings changes (FiO₂, PEEP, tidal volume), alarm events.
• Infusion pump: drug, concentration, rate, total dose delivered.
• Cabin microphone array: continuous audio (≈ 16 kHz mono per channel, multiple channels for diarization).

The crew's voice is the connective tissue between everything. They narrate to each other and to the radio: "BP eighty-five over fifty, giving five hundred saline bolus", "ETA eighteen minutes", "shockable rhythm, charging". Some of these statements are also captured by the device events (the saline bolus appears on the pump, the shock appears on the defibrillator). Others are crew observations that no device records: skin colour, mental status, the patient's family member present at the scene, the question the patient asked at minute three.

The appliance weaves all of this into a per-session timeline:

00:00:00  Session started (paramedic ID: 02148, EMT: 03917)
00:00:12  GPS lock acquired (location reference)
00:00:21  Vital monitor connected — first reading: HR 112, BP 142/88, SpO2 94, RR 22
00:00:34  Voice: "Female, sixties, chest pain since midnight, history of MI 2018"
00:01:02  IV established (crew narration + pump connect event)
00:02:18  Voice: "BP eighty-five over fifty, dropping. Giving fluid bolus."
00:02:21  Infusion pump start: NaCl 0.9% bolus, target 500 mL
00:04:09  12-lead ECG captured (image + leads), transmitted to receiving hospital
…

The audio is processed locally on the edge by the same Whisper stack used in clinical visits, producing transcript per crew turn. A diarization pass labels each sentence by speaker role (Paramedic, EMT, Patient, Dispatch-on-radio).

What flows to the cloud

The appliance knows the data is destined for the cloud, but it also knows that cellular coverage is not guaranteed. The sync strategy is:

• Always-on metadata stream. Vital-signs summaries (rolling one-second averages), event markers (medication given, intervention performed, alarm fired), and rough location are streamed as small protobuf messages whenever there is connectivity. Receive on the cloud side is idempotent on a session-id + event-id basis.
• Opportunistic media upload. Voice transcript chunks (small), ECG waveforms (medium), high-rate ECG strips around alarm events (medium), images of the 12-lead (small). These are queued; the edge uploads when bandwidth allows and the queue drains before the session ends. If cell coverage drops the queue grows; when coverage returns the queue catches up.
• Audio: never raw. The full audio file stays on the edge for the session-storage retention window, then is deleted per zone policy. What goes to the cloud is the transcript plus anonymized embeddings if the consent model permits.
• Pre-arrival burst. When the edge detects (by GPS + ETA calculation) that the vehicle is within five minutes of the declared receiving hospital, it raises queue priority — anything not yet uploaded gets pushed hard so the receiving team has the full timeline by the time the gurney comes through the doors.

The cluster-side ingest writes everything into the receiving customer organisation's FHIR project as it arrives. Each event becomes an Observation, Procedure, MedicationAdministration, or Communication resource on a single Encounter that represents this transport. The Encounter.status advances: triaged → in-progress → arrived → finished as the session lifecycle plays out.

What the receiving hospital sees

In the ED of the destination hospital, the triage nurse opens Jengu's "incoming transports" view. There are three reanimobiles en route from different regions; this one is highlighted because its vital-signs trajectory shows a worsening trend (BP dropping across the last two cycles, HR rising) and the receiving filter matches the on-call PCI team's roster.

Incoming                ETA   Severity   Last vitals             Alerts
─────────────────────  ────  ─────────  ──────────────────────  ──────────────
RM 02148  Jõhvi → Ahtme  14m  HIGH       HR 124 BP 78/52 SpO2 91  ↑ PCI standby
RM 03104  Kiviõli → IVKH  22m  medium     HR 88 BP 130/82 SpO2 97
RM 02991  Sillamäe → IVKH 35m  low        stable

The nurse taps the first row. The view expands into the live session timeline — transcript scrolling at the bottom (rendered in Estonian), waveforms ticking at the top, the most recent interventions on the right, the GPS-position dot on the map at the left.

She picks up the phone, calls the cardiology resident, names what she's seeing, and says "PCI team in fifteen". The resident pulls up the same session view on his phone, confirms the on-the-way 12-lead ECG looks like an inferior STEMI, calls the cath lab to spin up, and walks to the trauma bay to meet the gurney.

When the doors open, the receiving team has been watching for twelve minutes. They have already brought the right equipment to the right bay. The handoff is not a briefing — it is a continuation of an event the receiving team has been participating in remotely.

Why this matters

For severe time-critical conditions — stroke, MI, major trauma — time to definitive care is the outcome lever. Every minute saved in the door-to-balloon or door-to-needle window changes prognosis measurably. Today most of those minutes are spent on the briefing that happens after arrival: the receiving team did not know what was on the way, so the gurney lands in the bay, then the talking starts, then the decisions get made, then the team mobilizes. With the timeline arriving before the patient, the team has already mobilized by the time the gurney arrives.

The second-order benefit is the durable audit trail. The session artifacts — transcript, device events, interventions, decisions — are time-anchored and immutable. Clinical review, quality improvement programmes, mortality-and-morbidity discussions, and medico-legal review all become easier when the question "what happened" has a citation, not a recollection.

The scene

It is 17:42 on a wet October Friday. A coach hits black ice on the E263 between Põltsamaa and Jõgeva and rolls. Local witnesses dial 112; within four minutes the Estonian emergency-response centre (Häirekeskus) declares a mass-casualty incident (MCI) and dispatches every ambulance and AED-equipped first-responder within a 50 km ring. The trauma hub is the regional centre 38 minutes south by ambulance, 11 minutes by helicopter.

Within twenty minutes, eight transports are en route to the same hospital ED. Two of the ambulances belong to one regional EMS service, four to another, one is a private medical transport returning a routine patient who was rerouted, and the helicopter belongs to the national rescue service. Four different customer organisations in Jengu's data model. One receiving customer organisation.

In the ED, the senior physician on duty is paged. She opens the MCI command view — a screen that exists for exactly this moment.

What the command view shows

INCIDENT  MCI-2026-1023-E263  declared 17:46  by Häirekeskus disp #1142
═════════════════════════════════════════════════════════════════════════
INBOUND (8)                ETA   Sev    Last vitals          Crew/From
─────────────────────────────────────────────────────────────────────────
HEL  PIRG-04   helicopter   06m  RED    HR 138 BP 78/40 SpO2 84   PERH air
RM   28-04     ambulance  14m  RED    HR 122 BP 95/55 SpO2 90   Jõgeva EMS
RM   16-09     ambulance  16m  RED    intubated, vent: PEEP 8   Jõgeva EMS
AMB  41-12     ambulance    18m  ORG    HR 102 BP 130/75          Põltsamaa EMS
AMB  41-08     ambulance    22m  ORG    HR 88 BP 122/80 GCS 14    Põltsamaa EMS
AMB  03-21     ambulance    26m  YEL    multiple abrasions        Jõgeva EMS
AMB  03-15     ambulance    28m  YEL    stable, anxious           Põltsamaa EMS
PMT  L-447     private      31m  GRN    walking wounded, lac      Med-Express

BAY ALLOCATION                    READY TEAMS
─────────────────────────────────  ──────────────────────────────────────
Trauma 1   HEL  PIRG-04            Trauma team A (Dr. K, anaesth, ortho)
Trauma 2   RM   28-04              Trauma team B (Dr. M, gen surg, neuro)
Trauma 3   RM   16-09              Trauma team C (Dr. R, anaesth, vasc)
Bay A      AMB  41-12              Resus nurse + ED reg
Bay B      AMB  41-08              Resus nurse + ED reg
Bay C/D    YEL × 2                 ED registrars
Minors     PMT  L-447              Minor injuries nurse

INCIDENT COMMAND
─────────────────
ED Commander:   Dr. Sirje Kask
Triage lead:    Nurse Marek Põder
Anaesth lead:   Dr. Joonas Talviste
Surgery lead:   Dr. Hanna-Liis Roosvee
Operations:     House manager + admin

The eight ambulance sessions are clustered by incident ID, not by their EMS-service customer organisations — that's the MCI overlay. Each transport's detail panel still belongs to its originating customer organisation; what the command view does is project them onto a single receiving-customer organisation canvas, with consent inferred from the MCI declaration.

The severity column comes from a rolling AI assessment on each transport's live vitals + crew narration. RED for life-threatening unstable, ORG for serious, YEL for moderate, GRN for ambulatory. The triage nurse can override any cell and the assessment back-fills.

The bay allocation is a draft drawn by the command surface based on incoming severity and bay+team availability; the ED commander adjusts and accepts. Once accepted, each bay tablet locks to its allocated transport's live session; the team in that bay can read the full pre-arrival timeline before the gurney arrives.

The arrival cascade

Helicopter lands first. Trauma 1 team has watched the last 6 minutes of the patient's deterioration: BP slipping, the crew narrating "likely splenic — abdomen tender, distended". The trauma surgeon has called the OR; OR 4 is being readied for emergency laparotomy. The gurney rolls through the doors and into a team that is already past the briefing phase — they are at the doing phase.

Each subsequent ambulance has a similar shape. The handover is near-empty: vitals, allergies, what's been given, what's the working impression. Two minutes per patient instead of seven.

For the YEL/GRN cohort, the bay teams have looser teams pre-staged and the patients sort themselves through the minor-injury workflow. By 18:55 — about 90 minutes after the first call — all eight patients are placed, two are in OR, two are being transferred to ICU, four are stable in beds for observation.

What stays in the data layer

Through the entire event, the underlying Jengu sessions don't change shape. They are still per-transport sessions belonging to their originating customer organisations — same as any single-patient transport. What changes is the incident projection: every session is tagged Incident: MCI-2026-1023-E263, and the receiving customer organisation has a consented read-window into the data for the active phase of the incident.

When a transport's Encounter reaches finished (patient placed in a hospital bed), the data still belongs to its EMS customer organisation; what the hospital captured during the encounter belongs to the hospital customer organisation; the incident tag lets reviewers re-bind the two halves for quality review.

After-action review

The next morning, the ED commander runs the AAR view. The same incident ID. The same timeline. Now bounded — first call to last patient placed.

Time-to-first-arrival, severity-distribution-vs-prediction, bay-allocation-throughput, OR-call-to-incision, transport-call-to- hospital-arrival per ambulance. Where time was lost. Where the prediction model called severity wrong. Whether the helicopter should have been allocated to a different patient given what we now know.

The AAR is shared with each participating EMS service, with their sessions still in their own customer organisations — the hospital sees the hospital portion; each EMS sees its own portion; the incident tag joins them for the review surface.

Why this matters

In MCIs, the limiting resource is not equipment or staff — it is clarity. Who knows what is going on, fast enough that the response is coordinated rather than serial. Every minute of "what's coming in?" becomes a minute the trauma bay is empty, the OR is unbooked, the on-call specialist is at home.

The receiving-side visibility built for the ambulance story — showing a single incoming transport — scales naturally to many incoming transports, but only if the underlying sessions are designed to compose. Per-transport sessions clustered by incident ID is the composition primitive.

Beyond the acute event, MCIs are also the highest-stakes setting for after-action learning. The decisions made in the first thirty minutes are typically not legibly recorded after the fact; people remember what they think they remember. A reviewable timeline turns the AAR from "what did we do?" into "this is what we did, now why and could we have done it better?".

The scene

Thursday 15:30, three Tartu hospitals. Dr. Tamm, cardiologist, saw Toomas K. for new-onset exertional chest pain last week. The stress echo from Monday came back equivocal — mild wall-motion abnormality on the inferior wall, but Toomas is 64, hypertensive, and a 30-pack-year smoker. Dr. Tamm wants to escalate but does not want to over-investigate.

She picks up the phone — figuratively — and pulls two colleagues into a 20-minute televisit consilium: Dr. Veski, a chest radiologist; Dr. Lokk, a cardiothoracic surgeon. All three log in to their own hospital's Jengu customer organisation. None of them is Toomas's primary clinician today; only Dr. Tamm is.

The walkthrough

Dr. Tamm opens Toomas's record, finds last week's cardiology visit Encounter, and taps Open consilium. Jengu prompts her: which colleagues, what is the question. She picks Dr. Veski and Dr. Lokk, types one line ("equivocal stress echo, planning discussion"), and sends.

Both colleagues see a join request. They accept; Jengu opens a the live video service room and binds it to a new Encounter:

• class = AMB (inherits from the anchor visit)
• type = case-consilium
• meta.security = care-coordination
• subject absent + team-only-no-subject = true
• partOf = Toomas's cardiology visit Encounter
• team-roster Group = {Tamm, Veski, Lokk}

The chrome reads:

CONSILIUM LIVE  ●
Anchor visit: cardio-2026-06-04 · 64M · exertional chest pain
Team: Tamm (cardiology, host) · Veski (rad) · Lokk (CT surg)
──────────────────────────────────────────────────────────
                              [⚐ Reveal identity if needed]

The persistent display carries the anchor visit reference and the clinical context the three participants need to talk — not the patient's name. Dr. Tamm remembers him from last week; Dr. Veski and Dr. Lokk don't need to know his name to read his stress echo. The tablet's Reveal identity tool is available if any participant needs to dictate his name into the spoken record or into an outbound document.

Dr. Tamm shares the stress echo loop. Dr. Veski draws on it, walks through the inferior wall motion frame-by-frame, says it's "real but soft". Dr. Lokk asks for risk factors, hears the 30-pack-year history, says he would not operate on this report alone — wants CT angiography first to characterise the stenosis. They agree.

Dr. Tamm summarises into the recording: "Plan — coronary CT angiography this week, follow-up consult on result. If high-risk lesion, surgical referral; if not, optimised medical management with cardiac rehab." The other two assent on the record.

She taps End and commit. The commit dialog briefly resolves identity for confirmation (purpose: outbound-document — the agreed plan will surface on the patient's portal):

┌──────────────────────────────────────────────────┐
│  Commit consilium outcomes                       │
│  ─────────────────────────────                   │
│  To anchor visit cardio-2026-06-04 for           │
│  Toomas Kask · M 64 · DOB 1961-08-15             │
│                                                  │
│  • CarePlan addition — coronary CT angiography   │
│  • ServiceRequest — CT angiography this week     │
│  • Composition (consilium minutes)               │
│                                                  │
│              [confirm]    [cancel]               │
└──────────────────────────────────────────────────┘

She confirms. The modal closes; an AuditEvent (identity-revealed, purpose outbound-document) lands. Jengu generates three artefacts attributed to the consilium Encounter through the anchor patient:

• A CarePlan addition naming the agreed plan
• A ServiceRequest for the CT angiography
• A Composition (consilium minutes) referencing both, linked via Provenance back to the consilium recording's transcript segments

Each participating clinician receives a notification in their own customer organisation: "you participated in a consilium that committed the following actions to a record outside your customer organisation" — Dr. Veski and Dr. Lokk see what was committed, but Toomas's record stays inside Dr. Tamm's customer organisation.

Why this matters

Case discussions like this happen constantly across specialties and they are usually undocumented or scattered into emails. The clinical reasoning — which specialist said what about which finding, which one dissented, what the convergence was — disappears as soon as the call ends. When the patient asks two years later why a surgery was deferred, the trail is gone.

Recording the consilium as a clinician-only recording keeps the reasoning durable, attributes each statement to the speaker, and lands the agreed actions on the patient's record with audit-quality provenance. The patient is not asked to consent to a discussion they are not in; per-mention provenance keeps their Art 15 access intact. And the participants get a clean audit footprint of their own clinical advice.

The scene

Wednesday 07:45, internal-medicine ward. Dr. Karm — the consultant from US-ACUTE-ROUND — is in the staff room with her coffee, reviewing overnight summaries on her phone.

Riin Mägi from bed 1 had the lab and obs trend she expected: fever resolved at midnight, weaned to room air at 04:30, sats holding 94 on air at the 06:00 round of obs. Yesterday's bed-1 note already says "Plan discharge Thursday IF off O2 overnight Wed→Thu". Last night's overnight is the first half of that condition met.

Dr. Karm wants to add three things to bed 1's record before today's round opens:

• Note that overnight criterion is met.
• Pre-empt today's discussion: ask physio about home exercise plan today rather than at discharge.
• Flag a small concern: Riin mentioned yesterday she has nobody at home to help if she has another exacerbation — social-work referral if not already in motion.

Yesterday's bedside visit record (type=ward-round-bedside, subject=Riin) is closed but not gone. It is what this attaches to.

The walkthrough

Dr. Karm opens her patient list on her phone, filtered to her admitted patients. Bed 1 from yesterday's round is in the list — her phone shows the same pseudonymous default the tablet shows: bed reference, days of admission, diagnosis, the held overnight flags. No name. She taps the row, then Add addendum.

The phone chrome flips:

ADDENDUM LIVE  ●
Anchor: bed 1 · ward round 2026-06-07 · CAP day 4
Clinician only · solo · partOf the bed-1 Encounter
──────────────────────────────────────────────────────────
Recording — speak when ready                     [stop]
                      [⚐ Reveal identity if needed]

No patient red dot — Riin is not in this recording. No huddle context — this is not a round. A new clinician-only recording has opened, partOf Riin's bed-1 Encounter from yesterday, no subject, team roster is just Dr. Karm.

She speaks:

"Quick addendum on Riin Mägi — overnight obs reviewed, fever resolved at midnight, weaned to room air at 04:30, sats 94 on air at 06:00. First half of the discharge criterion met, pending Thursday. Two adds for today: ask physio about a home exercise plan today rather than waiting for discharge planning. And social — Riin mentioned yesterday she has nobody at home if she has another exacerbation; check whether social work is already on it, refer today if not."

She taps stop. The recording ends. Anonymisation runs; the text feeds the same note-update pipeline as the original round did. By the time she reaches the ward at 08:55, Riin's bed-1 note has gained:

Addendum (Dr. Karm, dictated Wed 07:45)
  Overnight criterion met (fever resolved 00:00, O2 weaned
  04:30). Adds for today: physio re. home exercise plan; social
  work check / refer re. home support.

And when today's round opens with the team walking to bed 1 at 09:08, the bed-1 card on the tablet already surfaces the addendum as already-considered material — Dr. Karm does not re-discuss it, the team picks up from there.

Why this matters

Ward rounds capture the in-the-moment decisions but not the between-rounds thinking. A consultant who has a thought overnight today scribbles it on paper, sticks it on the chart, hopes it makes it into the round. The longitudinal record of clinical reasoning fragments.

The addendum pattern is the same clinician-only addition as US-VISIT-DICTATION — but the anchor is a bed-visit Encounter inside a closed round, not an ambulatory visit. The model doesn't care. The doctor speaks to a phone, the recording is attributed to the right patient via the right Encounter, the note gains a timestamped addendum from the right author, and the next round picks it up. The thought makes it into the record at the moment it occurs.

The scene

Tuesday 16:30, family-medicine clinic in Pärnu. Dr. Vahter has just released her 14:00 patient and her next scheduled consultation is at 17:00. The 30-minute gap is hers. She opens her tablet (could be her laptop in the staff room, could be her phone if she's mobile; the queue is device-independent) and taps the Authoring queue tile.

The queue shows four ready tasks plus context:

Authoring queue · Dr. Vahter                              ⓘ
─────────────────────────────────────────────────────────────
ready  · visit-7c2 · ambulatory · 14:00 · hypertension f/u
ready  · visit-7c3 · ambulatory · 14:32 · sore-throat
ready  · visit-7c4 · ambulatory · 15:10 · pre-employment medical
ready  · visit-3a  · ward bed-5  · yesterday's morning round
─── processing ─────────────────────────────────────────────
proc.  · visit-7c5 · ambulatory · 15:45 · diabetic f/u
proc.  · visit-7c6 · ambulatory · 16:00 · paediatric well-child
─── failed ────────────────────────────────────────────────
fail.  · visit-7c1 · ambulatory · 13:45 · anonymisation-failed

She has six tasks behind her morning's work and one stuck in failed — she'll deal with that in a moment.

The walkthrough

She taps visit-7c2 first. The per-task view loads:

visit-7c2 · ambulatory · 14:00–14:25 · hypertension f/u
─────────────────────────────────────────────────────────
AI draft — SOAP + 3 smart-action proposals
   • [refill ramipril]
   • [home BP monitoring]
   • [follow-up 4w]

[Edit in place]               [⚐ Reveal identity if needed]
[Add dictation]   [Add written note]      [Reject task]
                                          [Confirm task]

The draft is good. She taps Edit in place, fixes one minor BP value the transcription got wrong, removes the [refill ramipril] proposal (he asked her to wait), keeps [home BP monitoring] and [follow-up 4w]. She taps Confirm task.

The structured view collapses to a single copyable text block:

S: 72M, hypertension f/u, on ramipril 10mg ×6mo. Home BP per
   diary 130/80 typical. No new symptoms. Tolerating medication.
O: BP 152/94 in clinic (white coat suspected), weight stable.
A: Hypertension — adequately controlled per home readings.
P: Continue current regimen.

Home BP monitoring (twice daily, morning + evening).
Follow-up in 4 weeks.

Dr. Vahter taps Copy, opens her hospital system tab (already logged in, patient already selected from her hospital system view), pastes into the note field. visit-7c2 is now completed. ~90 seconds.

She moves to visit-7c3 (sore-throat). Clean draft — viral pharyngitis, supportive care, no antibiotics. She accepts as-is, copies, pastes. ~30 seconds.

She moves to visit-7c4 (pre-employment medical). The AI captured the conversation but missed a remark she'd made about a borderline ECG finding she wanted to mention. She taps Add dictation. The chrome flips:

visit-7c4 · authoring · DICTATION LIVE  ●
─────────────────────────────────────────
Solo dictation — clinician only, attached to this visit       [stop]
                              [⚐ Reveal identity if needed]

She dictates 20 seconds about the borderline ECG and the recommendation to repeat at 6 months, taps stop. The summarisation re-runs on the new input; the dictation lands as an Additional findings section in the structured view. The smart-action proposals stay frozen (smart actions are claims about events that happened during the visit; the visit is over, new claims would be misrepresentation). She confirms the task, copies, pastes.

Reveal-identity moment

visit-3a — yesterday's ward bed-5. The AI summary is good but she remembers wanting to refer this patient to nephrology for the eGFR finding. The referral letter needs the patient's identity for the letterhead. She taps Reveal identity if needed. A short-lived modal opens, audited:

Reveal identity for visit-3a
Purpose: external-referral
─────────────────────────────
<name + DOB + national ID, on a dim background>
Bed:        5 (Ward N, 2026-06-07)
[Close]

She reads the name, mentally annotates the referral she's about to compose, taps Close. The name does not persist anywhere in the UI — the bed reference + clinical context is what stays on screen. The reveal emits an AuditEvent with subtype = identity-revealed, outcomeDesc = external-referral.

She drafts a written note in the per-task view: "Recommend nephrology referral. eGFR 38 (trending down), see attached laboratory results." The referral letter generation itself happens in her hospital system — when she pastes the final block in and tags it as "outgoing referral", her hospital system calls the the identity broker's outbound communicate to render the named letter and dispatch it through the configured channel. Dr. Vahter just writes the clinical content.

The failed task

visit-7c1 (failed). She taps it.

visit-7c1 · ambulatory · 13:45 · processing failed
─────────────────────────────────────────────────────────
Error class:    anonymisation-failed
Last attempted: 14:12 (3 automatic retries exhausted)

[Retry]   [Open with raw transcript only]   [Withdraw task]

She taps Retry — the anonymisation queue accepts the re-submission; this time it completes (Mistral was just timing out earlier). The task moves to ready. She opens it, confirms, copies, pastes.

Why this matters

The doctor's clinical-care time is not invaded by documentation; her clinical-care time is just clinical care. The note-writing happens when convenient — between consultations, at lunch, end-of-day if necessary. The product sells freedom from the office-runback: capture happens during care, paperwork happens when convenient.

Across a 25-patient outpatient day with the average task taking 90 seconds to 5 minutes, this is 30–90 minutes of recovered time. But the more important gain is the elimination of the post-clinic queue at home. Today's reality is that GPs commonly take 2–3 hours of documentation home after a full clinic day; this story shows what it looks like when that work happens instead during the doctor's existing clinical workday.

The scene

Wednesday 07:30. The district nurse station in Otepää, a small town in southern Estonia. Today's nurse on call is Maris. Her route this morning was pre-planned the day before: eight patients, mostly elderly, spread between Otepää, Pühajärve, Sangaste, and Kanepi. Total drive distance: about 60 km.

Her Jengu kit fits in a backpack: a 13-inch tablet (the mobile edge), a portable BT vitals cuff, a glucometer that pairs by Bluetooth, a small thermal printer that pairs by Bluetooth, a folding magnifier with a clip-on LED light, a digital camera for wounds, and a packet of single-use sensors. The tablet has its own LTE SIM, with Wi-Fi as a fallback wherever it's available.

The patient list looks like this:

Wednesday route — Maris — 08 / 8 patients
══════════════════════════════════════════════════════════════════
1  Helmi K (87)  Otepää   leg ulcer dressing change, photo & assess
2  Aino S (74)  Otepää   T2D, new insulin titration, glucose check
3  Vello P (81) Pühajärve catheter change, urinary obs
4  Linda T (79) Pühajärve post-op knee day 14, wound check + sutures out
5  Mati R (68)  Sangaste  oncology home support — pain assessment
6  Helle K (90) Sangaste  bath assist + weekly vitals
7  Karl L (72)  Kanepi    BP review, medication reconciliation
8  Olga M (84)  Kanepi    falls follow-up + grip strength
══════════════════════════════════════════════════════════════════
[Start day]    [Open patient]    [Office sync]

She taps Start day and the tablet pulls down the morning's update: overnight changes to medications, any messages from the GP about the patients on her list, the latest lab results from the lab she sent specimens to yesterday. Aino's glucose log from her home glucometer has uploaded overnight via her son's Wi-Fi — Maris opens it for a moment, notes the trend.

She drives to the first house.

Helmi (87) — Otepää — leg ulcer

Helmi has had a leg ulcer for three months. She lives alone in a two-room apartment on the second floor; the radio is on; the cat is on the couch. Maris settles in beside Helmi, the tablet on the small table.

The visit's session opens. Maris narrates as she works:

"Tere, Helmi. Vaatame täna seda haava... Eelmise korraga võrreldes on natuke väiksem, eks?"

She unwraps the dressing, photographs the wound under the LED, holds a ruler beside it for scale. The wound photo is captured, EXIF stripped of GPS, tagged with the session ID and the structured ulcer-assessment template. The tablet's AI compares it against the last visit's photo and overlays an automated measurement: 4.3 × 2.7 cm last time, 3.9 × 2.4 cm today. Improving.

Maris does the dressing change, narrating products and steps. The session captures it as a structured procedure log:

PROCEDURE — leg ulcer dressing change
─────────────────────────────────────────
Cleaning: saline, gentle
Debridement: minimal slough removed mechanically
Topical: hydrocolloid (size M)
Secondary: foam absorbent, light compression
Photo before, photo after — both attached
Pt tolerated well; pain VAS 2/10 during change

She also notes Helmi has been less interested in eating in the past week. She asks the standard nutrition screening questions. Marks a mild risk flag. Tells Helmi she'll mention it to Dr. Liis at the GP.

She wraps up the visit. The tablet has captured the entire interaction: voice transcript in Estonian, photos, structured procedure record, screening tool results, and Maris's narrative nursing note. Out the door, into the car, six minutes to drive to Aino.

She has no cell signal on Helmi's street. The tablet has noticed. The session is queued for sync.

Aino (74) — Otepää — diabetes titration

Aino's house is in a different part of Otepää with good LTE. As Maris parks, the tablet's sync indicator lights up — Helmi's session uploads in the background as she walks to Aino's door.

Aino has been adjusting her basal insulin under GP supervision after a hospital admission for DKA last month. The plan is to escalate slowly. Today's visit checks fasting glucose, reviews her self-log, adjusts the dose by 2 units if her readings have been consistent.

Maris uses the BT glucometer; the result (6.8 mmol/L fasting) lands on the tablet and joins the morning's session. She pulls up the home log — three days of readings between 6.1 and 7.4, with one spike to 11 after a granddaughter's birthday cake.

She and Aino talk about the cake; Aino laughs. The conversation captures naturally. Maris recommends the planned dose escalation — basal up by 2 units, hold the bolus pattern. The smart-action surface picks this up; a draft prescription update queues for GP approval.

Aino's blood pressure is 162/94, higher than recent trend. She checks again ten minutes later: 158/92. Maris flags this for the GP — it's not urgent enough for a same-day callback but it's not ignorable either.

The session closes. Out the door. Drive 22 km to Pühajärve.

On the road — the sync model

Between Aino and Vello, Maris is on the main road. Strong 4G the whole way. The tablet is using the drive time to:

• Finish uploading Helmi's session (the wound photos are the bulk)
• Upload Aino's session
• Pull down the morning's MET-CARE alert (a nurse from another district has flagged a shared-care patient as deteriorating; Maris isn't directly involved but the alert is on the team feed)
• Pull down a message from Dr. Liis at the GP confirming the BP flag from yesterday's visit to Karl — adjust his amlodipine
• Push the queued prescription-update draft for Aino

The sync model has three priority tiers:

1. Live messages — clinical alerts, GP messages, urgent replies. Smallest payload, push as soon as cellular is back.
2. Structured records — orders, prescriptions, draft notes. Pushed within seconds of cellular.
3. Media — photos, voice files. Queued, pushed when bandwidth is good (≥ 1 Mbps uplink) or before end of day, whichever first.

By the time Maris arrives at Vello's, she has the GP message visible on the tablet. She'll talk to Karl about the amlodipine this afternoon when she gets there.

Vello (81) — Pühajärve — catheter

Vello lives with his wife in a small house at the end of a forest road. No cellular. Wi-Fi: none. The tablet runs entirely offline.

Catheter change is procedural; takes 20 minutes; recorded the same way as Helmi's ulcer. The urine has trace haematuria today where there wasn't before; Maris flags it; takes a small sample for the lab — labels the specimen with the order ID on the thermal printer, places the specimen in a transport pouch in her cooler bag.

Vello's wife mentions he hasn't been sleeping well. Maris asks some sleep questions, captures it as a brief screen. Out the door. Forest road, no signal, for the next 15 minutes.

The disconnected hour

Linda (post-op knee) and Mati (oncology) are both in rural sub-areas of Pühajärve and Sangaste with no cell. Maris does both visits fully offline. The tablet captures everything; the queue grows to about 200 MB by the time she's done with Mati.

Mati's pain has worsened. He was on paracetamol + low-dose codeine; the dose isn't holding him. Maris listens, examines, narrates. The smart-action surface drafts an escalation recommendation: "request GP review for opioid titration; consider adding short-acting morphine PRN." Maris reviews the draft; it matches her plan; she leaves it as draft for GP approval at the end of the day.

She also notices Mati is alone today — his daughter usually comes from Tartu but is unwell herself. She flags a social-services follow-up. The flag lives on the patient's record, not the session record.

Walking back to the car, the tablet still shows no signal. She drives. After about ten minutes back toward the main road, the LTE icon lights. The queued sessions — Vello, Linda, Mati — start uploading. The escalation recommendation for Mati hits the GP's queue.

A few minutes later, a GP message comes in: "Reviewed Mati's escalation request. Agree. Prescribing short-acting morphine 2.5 mg q4h PRN; can you collect from Sangaste pharmacy on way to next patient and deliver? Will issue e-script now."

Maris confirms. Stops at the pharmacy in Sangaste; the e-script is already there; she picks up the morphine and a printed information sheet. Continues to Helle's house.

This is what working with the cloud looks like when you're mostly disconnected: opportunistic, conversation-on-tape-delay, but the chain still closes.

Mid-day sync at the office

13:20. Maris stops at the Otepää nurse station for lunch and a quick mid-day sync over the office Wi-Fi. The tablet flushes the morning queue completely — all photos, all voice files — and pulls down any afternoon updates.

The supervisor (the station's nursing lead) gets a notification that Maris's queue is clear. Some supervisors check in-progress day status as a way of keeping a light eye on community-nurse load; whether to surface this is a per organisation policy.

The day's draft note summaries are now visible to the GP team — they can read them, comment, or just leave them. By late afternoon, the GP will sign off on the prescription updates and any escalations.

Afternoon — Helle, Karl, Olga

The afternoon four visits run similarly. Karl gets his amlodipine adjustment discussed (per Dr. Liis's earlier message). Olga's grip strength is measurably worse than three months ago; Maris captures this and recommends a physio referral. Helle wants to talk about her son in Sweden for ten minutes; the visit captures the BP and weekly vitals; the conversation about Sweden is recorded but the AI doesn't try to make a clinical note out of it — it's social, the model knows the shape.

16:25. Back at Otepää nurse station. The tablet syncs the last queue. The day's record is closed.

End of day — 8 / 8 visits — 17 min avg / visit
═══════════════════════════════════════════════════════════════════
                Notes   Photos   Specimens   Escalations   Status
1  Helmi K       ✓       2        —            nutrition flag   in GP queue
2  Aino S        ✓       —        —            BP flag + Rx     in GP queue
3  Vello P       ✓       —        urine        sleep query     in GP queue
4  Linda T       ✓       3        —            sutures out OK   final
5  Mati R        ✓       —        —            opioid + soc    Rx delivered ✓
6  Helle K       ✓       —        —            none             final
7  Karl L        ✓       —        —            BP plan agreed   final
8  Olga M        ✓       —        —            physio referral  in GP queue

Queue clear. Tomorrow's route: [open]

She closes the day. The tablet's local cache is purged of all session media older than 7 days. Tomorrow's route is on the landing screen.

Why this matters

District nursing is where the centre of gravity of geriatric care sits in Estonia and most northern European countries, and where documentation burden is heaviest because clinicians are alone with the patient with no scribe and no good way to write later. The typical pattern is: the nurse remembers everything, drives back to the office, types it up, half of it is lost or compressed, the GP sees a thin summary the next morning.

Offline-tolerant capture changes this calculation. The record is made at the bedside, in the patient's living room, while the information is fresh. The patient sees the nurse making the note as part of the visit, not as a separate paperwork act. Escalations are queued in flight and acted on within minutes of cellular return, not at end of day.

The story exercises the "edge keeps working when cloud is unreachable" property at its highest-leverage point. A hospital edge being unreachable is an emergency; a rural-route edge being unreachable for ninety minutes is just Tuesday.

The scene

Thursday 09:40 at a general practice in Viljandi. The patient is Andres T., 58 years old, software engineer, diagnosed with type-2 diabetes in 2016 at his pre-employment medical for his current employer. His GP, Dr. Saar, has been seeing him for almost the full decade. Andres comes in once a year for a routine review, twice in years when something has changed.

Today is the annual review. Lab work was done last week (HbA1c, eGFR, lipid panel, urine ACR). Eye exam was done six weeks ago at a private ophthalmology clinic. Andres had a brief admission to the regional hospital two years ago for DKA after a viral illness.

When Dr. Saar opens Andres's record, she sees the per-visit timeline in the foreground — today's visit at the top, the annual review last year below it, etc. She switches to the longitudinal view.

The longitudinal view

Patient · M · 58y · type-2 diabetes              [⚐ Reveal identity]
Last 10 years — clinical timeline   [▼ filter]   [pivot ▼]
══════════════════════════════════════════════════════════════════════
                                                            2026 ▾
                                                       │ ←—— today
  ┌─────────── HbA1c ──────────────────────────────────│──┐
  │ 9 ─                                              ──▲  │
  │ 8 ─                                       ──/──/         │
  │ 7 ─                                ──/──/─                │
  │ 6 ─                       ──/──/──/                       │
  │ 5 ─       ●dx                                            │
  └────────────────────────────────────────────────────────┘
   '17   '18   '19   '20   '21   '22   '23   '24   '25   '26

  ┌─────────── Weight kg ────────────────────────────────────┐
  │ 95 ─                                          ─▲          │
  │ 90 ─                                ──/──/                │
  │ 85 ─                       ──/──/                         │
  │ 80 ─       ●dx                                            │
  └────────────────────────────────────────────────────────┘

  ┌─────────── eGFR ──────────────────────────────────────────┐
  │100 ─       ●                                              │
  │ 90 ─       ── ── ──                                       │
  │ 80 ─                  ──── ─                              │
  │ 70 ─                              ──── ─                  │
  │ 60 ─                                            ─▼        │
  └─────────────────────────────────────────────────────────┘

  ┌─────────── Medications ──────────────────────────────────┐
  │ metformin                ────────────────────────────────── │
  │ gliclazide                                ─────────────── │
  │ insulin glargine                                  ──────  │
  │ ramipril                                       ────────── │
  │ atorvastatin                                ───────────── │
  └─────────────────────────────────────────────────────────┘

  ⚑  2024-08: DKA admission (regional hospital) — 4 days
  ⚑  2025-11: retinopathy noted at eye exam (private clinic)
  ⚑  2026-02: foot neuropathy noted at neurology (regional)

  AI ASSESSMENT
  ─────────────
  ⚠ HbA1c trajectory: rising 6.5 → 7.2 → 7.8 over last 18 months
  ⚠ Weight: +5 kg in 18 months
  ⚠ eGFR: declining at 4 mL/min/1.73m² per year — above expected
  ⚑ Endocrinology follow-up overdue (last 2 years ago)
  ⚑ Microalbuminuria appeared 6 months ago — not yet on
     SGLT2-inhibitor (eligible per NICE pattern)

The timeline is sourced from three customer organisations:

• Dr. Saar's GP customer organisation — most of the visit history, the prescribing record, the routine labs.
• The regional hospital — the DKA admission encounter, with its own session record + discharge summary.
• The private ophthalmology clinic — the eye exam reports, with the retinopathy notation.
• The regional neurology — the foot exam from February.
• Andres's own home-monitoring data — his glucose readings via his phone app, syncing to his patient-side timeline, shared with the GP via patient-consented sharing.

All five are independent customer organisations. The longitudinal view assembles data across all of them under the consented-data-use model: Andres has granted his GP read access to the hospital records and the specialist records, with revocation surfaced as a patient- visible toggle in his portal.

What changes in the visit

Dr. Saar reads the AI assessment. She agrees with most of it. She clicks through to the supporting data — the AI's claim that "eGFR declining at 4 mL/min/1.73m² per year — above expected" — and the view shows the underlying eGFR values, the time deltas, the line fit. Provenance.

She brings it up with Andres:

"Andres, vaata, su veresuhkur on viimase kahe aasta jooksul tasapisi tõusnud, ja kaal samuti. Neerud teevad ka veidi rohkem tööd, kui ootaks. Arvan, et oleks aeg endokrinoloogile kontrollimas käia, ja võiks ka uue ravimi lisada — see SGLT2 grupp, mis aitab nii suhkurile kui neerudele."

They talk. She makes the referral. She prescribes empagliflozin 10 mg. She brings up the foot exam — Andres confirms his feet have been numb in the toes for the past six months but he hadn't mentioned it to her because the neurologist already saw him. She adds it to today's note.

The smart-action surface drafts:

DRAFT ORDERS — today's visit
─────────────────────────────────────────────────
☑ Endocrinology referral — outpatient, routine,
   reason: trajectory worsening, microalbuminuria,
   eGFR decline
☑ Prescribe empagliflozin 10 mg PO OD
☑ Add foot exam to chronic problem list
☑ Repeat ACR + eGFR in 12 weeks
☑ Counsel re: SGLT2 sick-day rules + DKA risk
   (relevant given prior DKA history)
☐ Renal follow-up if eGFR continues to decline
☐ Update HbA1c target — discuss in next visit

Dr. Saar accepts five of the seven, holds the renal follow-up (she'll decide at the 12-week recheck), and notes "discuss target" as a manual reminder for next visit.

Andres asks: "the SGLT2 — last time I was on something new I got that thing where my blood sugar dropped. Will this do that?" The session captures the question. The smart-action surface adds a counselling note about hypoglycaemia risk profile (low with SGLT2 alone, but he's also on insulin and gliclazide; combined risk profile needs discussing).

The visit ends. Andres gets a patient summary in Estonian, with the medication change, what to watch for, when to come back. Dr. Saar's note is drafted, ready for sign-off.

What the next specialist sees

Three weeks later, Andres is seen by the endocrinologist at the regional hospital. The hospital customer organisation pulls the referral packet: not just the GP's referral note, but a structured patient summary auto-generated for this referral that includes the same longitudinal view Dr. Saar saw, plus everything since.

The endocrinologist sees the empagliflozin started three weeks ago, the latest home glucose readings showing some morning lows (triggered the gliclazide reduction Dr. Saar made by phone two weeks ago), and the AI assessment updated with the trajectory shift since the SGLT2 went on. The DKA two years ago is flagged prominently.

The consultation is 25 minutes. Half of it is talking about real clinical content — sick-day rules in more depth, an insulin adjustment, a CGM trial — instead of "tell me your story." The visit captures, the orders draft, the referral-back to the GP is generated. Andres goes home with a CGM kit.

The GP sees the endocrinology note in her inbox the next morning.

Why this matters

Type-2 diabetes is the prototypical chronic disease where the arc of care is a decade or three, the providers change, the records fragment, and the patient does most of the carrying of their own story. The clinical decisions that matter most — when to escalate therapy, when to add a class, when to refer — are decisions about trajectory. Trajectory is what longitudinal data shows; per-visit data hides it.

Today the trajectory view doesn't exist in most healthcare systems. The doctor sees the latest HbA1c value and remembers, roughly, what the previous one was. The decision to escalate is driven by single-point thresholds, not by the slope. The escalation often comes too late.

Building a trajectory view that aggregates across customer organisations under patient consent is doable. The platform substrate exists. The specific module needs to be built.

The harder, social half of this is patient consent for cross- customer organisation aggregation. Estonia has cultural and regulatory groundwork for this (the patient owns their the national health information system record), but organisation-level opt-in for sharing into the trajectory view is a separate consent than "I'm OK with this hospital having my records." That consent must be patient-driven, granular, and reversible.

The scene

A late-March outpatient consultation at the gastroenterology clinic of Tartu University Hospital. The patient, Liisa V., is a 32-year-old woman with a probable diagnosis of autoimmune hepatitis, overlap features with primary biliary cholangitis. The case is genuinely uncertain — biopsy is suggestive but not diagnostic, response to first-line therapy has been partial. The Tartu gastroenterologist, Dr. Tuvi, wants a second opinion from a hepatologist at HUS (Helsingin yliopistollinen sairaala) who has deep specialty experience with overlap syndromes.

Dr. Tuvi discusses with Liisa. Liisa agrees. Cross-border referral within the EU is supported in principle by EU Directive 2011/24 and the Estonia-Finland operational bilateral; in practice it requires explicit patient consent for the data movement and a specific receiving provider.

Dr. Tuvi opens the cross-zone referral surface in Liisa's record.

Building the referral packet

Cross-zone referral — Liisa V. → HUS (Helsinki)
═════════════════════════════════════════════════════════════
RECEIVING PROVIDER
─────────────────────
Tenant:      HUS-Hepatology
Zone:        zone-fi (EU/Finland)
Consultant:  Dr. Sami Korhonen (specified)
Pivot lang:  fi  (Finnish — receiving zone official)
                + en  (EU pivot language, default)

CONSENT
─────────────────────
Patient consent for cross-zone data flow:
  ☑ Scope: hepatology records (past 24 months)
  ☑ Purpose: second-opinion consultation
  ☑ Receiving provider: HUS-Hepatology only
  ☑ Re-use restrictions: no research use, no
     onward sharing without renewed consent
  ☑ Duration: 90 days; auto-revoke after
  ☑ Right to revoke at any time (patient portal)

CLINICAL PACKET
─────────────────────
☑ GP history (relevant to liver / immune)
☑ Hepatology clinic notes (5 visits, 2024-2026)
☑ Lab trajectory (LFTs, autoimmune panel, IgG, AMA, ANA)
☑ Liver biopsy report + slides reference
☑ Imaging: 2× MRCP, 1× CT abdomen
☑ Treatment history + response
☐ Pharmacy dispense history (offer; not selected)
☐ Family history detail (selected by patient at portal)

PRESENTATION
─────────────────────
Format:    FHIR Bundle (R4) + IHE XDS metadata
Language:  Primary fi (translated); also en (pivot);
           originals retained in et (untranslated source)
Format:    Auto-generated 2-page case summary (fi+en)
           + raw FHIR Bundle for clinician's EHR

[Generate packet]    [Send to HUS gateway]

The packet bundles five visits, the lab trajectory, the biopsy report, the imaging studies (by reference; full DICOM available on pull, not pushed), and the treatment history. The presentation layer renders the case summary in Finnish (the receiving zone's official language) and English (the pivot language); the raw FHIR Bundle is also translated where free text appears, with the Estonian source retained as an attachment for any clinician who reads Estonian.

Dr. Tuvi reviews the auto-generated case summary. A two-page narrative in Finnish, with a clean ICPC/ICD-10 problem list, the treatment history, and an explicit "consulting question" section that Dr. Tuvi has dictated:

"Mitä mieltä olette? Pidän tätä todennäköisenä päällekkäisenä AIH-PBC-syndroomana, mutta vaste UDCA + atsatiopriini -hoitoon on ollut osittainen. Pohdin lisämukoofenolaatti-hoitoa versus rituksimabia. Toivoisin teidän arvionne kuvantamis- ja biopsiavalinnoista jatkohoidon suunnittelussa."

Dr. Tuvi reads the Finnish back, makes one small correction (the model rendered "AIH-PBC päällekkäisyysoireyhtymä" where the shorter "overlap-syndrooma" is more standard in Finnish hepatology register; native-speaker register-softening per the platform's translation pipeline). Hits send.

Cross-zone transport

The packet leaves zone-ee. It crosses the zone boundary through the cross-zone referral gateway, which is a Jengu service that:

1. Validates the consent envelope — does the consent declared by the sending customer organisation authorise the data being sent to the declared receiving customer organisation for the declared purpose?
2. Logs the transit in the cross-zone audit ledger — anchored on both sides of the boundary.
3. Translates the payload's free-text and structured fields using the per-zone translation policy.
4. Wraps in IHE XDS metadata so the receiving customer organisation's EHR integration ingests it as a referral document.
5. Delivers to the receiving customer organisation's inbox.

The packet arrives at HUS-Hepatology's Jengu customer organisation in about fifteen seconds.

What the Finnish specialist sees

Dr. Korhonen logs in at HUS the next morning. His inbox has a new external referral. He opens it. The case summary is in Finnish; he reads it. The structured data (labs, biopsy report, imaging) is in his normal clinical view. He can switch any field to its English or Estonian source view if he wants to see the original.

He reviews. He requests the biopsy slides be sent for re-review by the HUS pathologist — that becomes a sub-referral, with its own consent and audit trail. He sees Liisa twice over the next month (once in person at HUS, once via televisit).

His final consultation report is generated:

HUS-Hepatology  Consultant report — Dr. S. Korhonen
Re:  Liisa V. (Estonian patient, referred 2026-03-25 by Dr. Tuvi, TUH)
───────────────────────────────────────────────────────────────────

KLIININEN ARVIO
[Finnish clinical narrative — 1.5 pages]

SUOSITUKSET
1. Diagnoosi: ...
2. Hoito: ...
3. Seuranta: ...
4. Erityishuomioita: ...

The report is published from his customer organisation. It crosses back to Tartu — the return path of the same gateway, with the same consent envelope, the same audit anchoring.

What lands at Tartu

Dr. Tuvi receives the report in two languages simultaneously:

External consult — HUS — Liisa V.
═══════════════════════════════════════════════════════════════
Author:    Dr. S. Korhonen, HUS-Hepatology
Date:      2026-04-29
Original:  Finnish ▾   View also: Estonian ▾   English ▾

KLIINILINE HINNANG / KLIININEN ARVIO
[Estonian translation rendered as primary]
[Finnish original available on toggle]
[English pivot available on toggle]

SOOVITUSED
1. Diagnoos: ...
2. Ravi: ...
3. Jälgimine: ...

[Accept into Liisa's record]    [Discuss with patient]

The Estonian-language rendering is the formal version that goes into Liisa's Estonian medical record — Estonia's records-language law (Keeleseadus + Tervishoiuteenuste korraldamise seadus) requires clinical records to be in Estonian. The Finnish original is retained as a source document attached to the same record; legally the Estonian translation is the operational record but the original is preserved for clinical fidelity and any future question of translation accuracy.

Dr. Tuvi reads the report. Imports it into Liisa's record. The treatment plan changes accordingly. Liisa is told. Her next gastroenterology visit references the consult.

The consent envelope auto-revokes 90 days after the referral was initiated. After that point, HUS's customer organisation retains its own record of the consultation (as the legal author and record-keeper for the Finnish-side event), but cannot proactively pull additional Estonian-side data.

Why this matters

Cross-border specialist consultation is a real and growing demand in the EU. The Estonia-Finland axis is particularly active because of language overlap, geographic proximity, and complementary specialty depth. Today it happens, but the data movement is manual: PDFs emailed, sometimes faxes, sometimes a patient walking in with a paper folder. The clinician on the receiving side often asks the patient to re-describe everything because the inbound documentation is in a foreign language or an unstructured format their EHR can't ingest.

A FHIR-Bundle-with-translated-narrative referral packet, moving through a cross-zone gateway with explicit consent envelopes and audit anchoring on both sides, makes the cross-border consult work the same way a within-country consult works. The clinical question gets a clinical answer; the legal and language layers are handled by the platform.

The principle that the formal record is in the patient's home zone's official language — not in the originating consultant's language — is the load-bearing one. It means the patient's record at home remains legible to every Estonian clinician without translation, and it means the legal status of the Finnish consultant's opinion is preserved (he authored it in Finnish; the Estonian record carries the authoritative translation plus the original).

The scene

Thursday 14:00. A regional oncology tumour board for a multi-hospital network in northern Estonia. Participants are:

• Two surgical oncologists from Tallinn (PERH and ITK).
• One medical oncologist from Tartu.
• One radiologist (PERH).
• One pathologist (PERH).
• One palliative care lead (Tartu).
• One patient navigator (rotating among the three hospitals; this week Tartu).

Each participant joins from their own office, via Jengu's televisit surface. Each is logged in to their own hospital's customer organisation. The tumour board is a meeting in Jengu's sense — a multi-customer collaborative session with a specific structure.

The agenda for today: eight cases. Six from Tallinn, two from Tartu.

tumour board — North-Estonia Oncology — Thu 14:00 (90 min)
Chair: Dr. Mari Põllu (medical oncology, Tartu)
═══════════════════════════════════════════════════════════════════════
Case      Patient (initials, age)   Tumour                  Tenant
───────────────────────────────────────────────────────────────────────
1   K.S.M (62)   Pancreas — locally advanced              PERH
2   T.A.V (54)   Breast — HER2+ post-NACT                 PERH
3   M.K.T (71)   Colorectal — liver mets resectable?      ITK
4   E.R.K (38)   Cervical — staging surprise              PERH
5   H.U.P (66)   Prostate — bRCR after RT                 ITK
6   A.L.J (49)   Sarcoma — soft tissue thigh              Tartu
7   P.O.S (58)   NSCLC — driver mutation?                 Tartu
8   M.E.R (45)   Lymphoma — primary CNS                   PERH

Participant roster (8):
─ Dr. M. Põllu          Tartu — medical oncology — CHAIR
─ Dr. K. Roosvee        PERH  — surgical oncology
─ Dr. J. Sirel          ITK   — surgical oncology
─ Dr. H. Madisson       PERH  — radiology
─ Dr. R. Niinemets      PERH  — pathology
─ Dr. T. Aas            Tartu — palliative care
─ Liina K.              Tartu — patient navigator
─ Tiina M.              PERH  — admin / scribe (observer)

[Start tumour board]   [Open case 1]    [Recording: on with consent flag]

Each case has been pre-prepared by the presenter — a short summary, the imaging slices that matter, the pathology stains, the proposed question. The pre-prep is a small piece of work the presenter does the day before; the tumour board module supports it as a half-page template.

Inside the tumour board call

The call uses the live video service. Audio + video + screen-share. Eight participants in tiles, the active screen-share in the middle. The tumour board module overlays the case sidebar on the right.

Case 1 is K.S.M, a 62-year-old man with locally advanced pancreatic cancer. The presenter, Dr. Roosvee (PERH surgery), screens through the case in 90 seconds: presentation, CA 19-9 trajectory, current imaging from the MRCP done last week. The radiologist (Dr. Madisson) jumps in: "I think this is more borderline-resectable than locally-advanced; the SMA is abutted but not encased — look at coronal slice 38." The screen-share moves to slice 38; everyone sees it.

The pathologist describes the biopsy: well-differentiated adenocarcinoma, no peritoneal involvement on the staging laparoscopy.

The medical oncologist (Dr. Põllu) proposes neoadjuvant FOLFIRINOX then re-stage; if response is good, take to surgery; if not, switch to chemoradiation. Discussion of fitness (the patient is well, ECOG 0), of FOLFIRINOX vs. gemcitabine-nab-paclitaxel given his renal function. Decision: 4 cycles FOLFIRINOX, restage at 8 weeks.

The tumour board module captures all of this as a structured decision record:

Case 1 — K.S.M — Pancreas (PERH)
DECISION (chair: Põllu)
─────────────────────────────────────────────
Diagnosis (consensus):
  Borderline-resectable pancreatic adenocarcinoma,
  no peritoneal involvement (staging lap negative)

Plan:
  1. Neoadjuvant FOLFIRINOX, 4 cycles
  2. Restage at 8 weeks: MRCP + CA 19-9 + CT chest
  3. Multidisciplinary re-review at next tumour board
  4. If response & resectable: Whipple resection (PERH surgical)
  5. If non-response: switch to gemcitabine-nab-paclitaxel
     + chemoradiation (PERH oncology + RT)

Action items:
  → Med oncology (Põllu, Tartu):   schedule chemo start, week 1
  → Imaging (PERH):                book restaging MRCP at week 7
  → Patient navigator (Liina):     communicate plan, coordinate
                                   travel to Tartu for chemo
  → Surgical onco (Roosvee, PERH): pending re-review

Recorded by: tumour board module + chair confirmation
Time stamp:  2026-thu 14:08

The decision lands as a CarePlan resource addition on K.S.M's record at the PERH customer organisation. The action items are routed to each named participant's task queue: Dr. Põllu sees "schedule chemo start for K.S.M week 1" appear in her Tartu task list; Dr. Madisson sees the imaging booking appear in her PERH list; Liina sees the navigation task in her Tartu list (because she's based there this week — the navigation team is shared across the three hospitals).

The chair confirms the decision. Move to case 2.

Writing into another hospital

The interesting structural thing happening here is the between customers write. The decision is being added to K.S.M's record at PERH — correct, that's where his customer organisation lives. But the authoring is by a chair (Põllu) at Tartu, with contributions from participants at three customer organisations. The audit trail records:

• The decision was made in an tumour board session (session ID, with participants enumerated).
• The decision was added to K.S.M's CarePlan at the PERH customer organisation.
• The authoring participant signatures include Põllu (Tartu), Roosvee (PERH), Madisson (PERH), Niinemets (PERH), and Sirel (ITK — yes, even though Sirel didn't speak on case 1, he was present and the tumour board pattern is "by consent of the assembled board").
• Task assignments flow to participant queues at their own customer organisations; from each customer organisation's perspective the task arrived via the tumour board bridge.

The collaboration between customers is bounded by the tumour board session. It is not a standing data-sharing arrangement between the four participating customer organisations; it is a transient, recorded, consented collaboration with a specific decision output.

The other seven cases

Each case takes ~10 minutes. Some are simple ("recommend adjuvant chemo, no controversy") and take three. Some are difficult and take fifteen. The chair manages time. The navigator captures patient-side communication items.

Case 7 (NSCLC driver mutation) gets bumped — the molecular pathology report hasn't come back yet, so the discussion is held to next week. The case is rescheduled in the module; the participating clinicians get a notification.

Case 8 (primary CNS lymphoma) is hard. There's disagreement on chemotherapy choice. The discussion runs over. The chair allows it, recognising the stakes. The decision is documented as a non-unanimous recommendation: chair's preferred plan as the primary recommendation, dissenting opinion captured verbatim as an attached note. The patient navigator is asked to convey the preferred plan to the family with the caveat that the case is complex; if the family wants a second opinion, that pathway is available.

15:32. The tumour board ends two minutes over. Each participant gets a post-meeting summary in their inbox: the cases they were involved in, their action items, the call recording (held for the standard tumour board retention period).

The hardest part — patient identity in the call

The participants discuss "K.S.M, 62-year-old man with pancreas" verbally. The tumour board recording captures audio with that pseudonym; the case sidebar shows the full identity to the participants only (rendered locally, not in the screen-share if a participant shares); the recording's audio transcript is anonymised at rest to use the initials and case number.

When the chair asks Dr. Madisson "can you show slice 38 of his MRCP" and the screen-share opens the imaging viewer, the patient name on the imaging-viewer header is masked in the share by a participating-customer organisation overlay (the share goes through the tumour board module's screen-share proxy, not the raw screen).

This is a non-trivial UX thing. If anyone screenshots, anyone records on a phone, anyone leaves a screen mirroring on, the mask is the difference between "we discussed K.S.M anonymously" and "a confidential discussion of K.S.M was recorded identifiably". The pattern works only if everyone uses the tooling.

Why this matters

MDTs are how oncology decisions actually get made for complex cases. They are also infamously underdocumented. The decisions are real; the audit trail is often a paper sheet that gets typed up by an admin half a day later. Dissenting opinions rarely make the written record. Action items are tracked on emails sent later.

A structured tumour board module that:

1. Captures the decision as a structured record on the right patient's chart at the right customer organisation
2. Routes action items to participant queues at their own customer organisations
3. Preserves the discussion (recording + transcript) for clinical review and quality purposes
4. Handles authoring across hospitals cleanly

...makes the tumour board both more reliable and easier to run. The overhead of preparing a case drops; the overhead of executing on a case drops; the audit substrate is automatic.

The harder pattern is the screen-share-with-identity-masking. It's not visible until you look for it, but it's the difference between an tumour board recording being safe to retain and being a privacy liability.

The scene

Saturday 11:20 at an ED in Tallinn. A woman walks in clutching her chest. She is Astrid R., 58, from Hamburg, on a weekend trip with her husband. They arrived Friday; she's been feeling unwell since Saturday morning; the chest pain started an hour ago.

She speaks fluent English; some Estonian phrases; no Russian. Her husband speaks German and English. She hands the triage nurse her German EHIC (European Health Insurance Card) and her German passport.

The triage nurse — Tiia — handles foreign patients regularly (Tallinn is a tourist city). She opens the foreign-patient registration surface in the ED.

Registration without a national ID

FOREIGN PATIENT REGISTRATION
══════════════════════════════════════════════════════════════════
IDENTITY
  Passport:   German (number recorded)
  Name:       Astrid R.
  DOB:        1968-08-14
  Sex:        F
  Country:    Germany
  Address:    Hamburg (full address recorded)

CARE-COVERAGE STATUS
  ☑ EHIC card valid (Germany — TK insurance)
  ☐ Private travel insurance (offer to record if present)

LANGUAGE
  Preferred:  German (de)
  Also speaks: English (en)
  Estonian:   minimal

CONSENT — INITIAL
  ☑ Consent to receive care
  ☑ Consent to record this encounter
  ☑ Consent to share with German GP on discharge
  ☑ Consent to share with German insurance for billing
  ☐ Consent to retain in Estonian records after discharge
     (separate consent at discharge)

NATIONAL ID
  ☐ Estonian — none (foreign patient)
  ★ Auto-generated Jengu foreign-patient ID: FP-EE-2026-04-25-09147

[Confirm registration]   [Start encounter]

Astrid is registered with an Estonian-side ID generated for the encounter (the FP- prefix marks foreign patient). Her German identity is recorded but is not the canonical key inside the Estonian system — the Estonian system has no read access to German national identity infrastructure, so the foreign-patient ID is the operational identifier here.

Triage opens her encounter. She's taken to a bay.

The encounter — three days of care

She has chest pain, dyspnoea, mild diaphoresis. ECG shows ST-elevation in the inferior leads. Troponin is elevated. The diagnosis is inferior STEMI. She is taken to the cath lab within the hour for primary PCI; right coronary artery is stented. Smooth procedure. She's admitted to the coronary care unit.

Day 2: stable, no further events. Echo shows mild residual inferior wall hypokinesis but reasonable EF. Started on standard post-PCI medical therapy: dual antiplatelet (aspirin + ticagrelor), statin, ACE inhibitor, beta-blocker.

Day 3: stable, ambulating, planning discharge. She wants to fly home Tuesday; cardiology is comfortable with discharge today provided she has follow-up arranged in Germany. Her husband has already messaged her German GP, who has agreed to see her on Wednesday.

Throughout the three days, the encounter is captured in the standard Jengu shape: voice + structured + device + AI summaries. The records are in Estonian (the zone-ee official-record language) by the platform's compliance-zone policy. The patient-facing summaries are rendered in German for Astrid.

Discharge — the cross-border export

Day 3, 14:00. Dr. Saar, the cardiologist, finalises the discharge plan. The discharge surface has a cross-border discharge mode that triggers when the patient is registered as foreign:

DISCHARGE — Astrid R. — foreign-patient export
══════════════════════════════════════════════════════════════════
PATIENT NEXT-OF-CARE
  GP:         Dr. K. Wolff, Hamburg, Germany
              (entered by patient at registration)
  GP's email: (entered by patient at registration)
  GP's EHR:   patient unsure; ask GP at first visit

LANGUAGE POLICY
  Estonian-side record:  Estonian (official; retained per zone)
  Patient-side summary:  German (also available in English)
  GP-bound packet:       German

DISCHARGE PACKAGE — components
  ☑ Structured FHIR R4 Bundle (de + en pivot)
     Includes: encounter, procedure (PCI), diagnoses, medications,
     follow-up, ECG (image attachments)
  ☑ Plain-language patient summary (de)  [4 pages PDF]
  ☑ Medication list (de + en)  [1 page PDF]
  ☑ Follow-up instructions (de)  [1 page PDF]
  ☑ Original ECG strips (PDF + DICOM)
  ☐ Cath lab images (DICOM, large — opt-in)

DELIVERY METHOD — patient's choice
  ☑ Print all (paper packet at discharge)
  ☑ Carry on USB stick (encrypted, password told to patient verbally)
  ☐ Direct send to GP via cross-border health bridge
     [Germany supports inbound for FHIR-aware practices via
      gematik gateway; her GP's status: unknown]
  ☐ Direct send to insurance (separate billing flow)

[Generate package]

Dr. Saar generates the package. About two minutes. Astrid leaves the hospital with:

• A printed German-language summary in a folder. Four pages, patient-readable, covers: what happened (STEMI, inferior), what was done (primary PCI, RCA stented), what medications she's on now and what they're for, what to watch for, when to follow up.
• A printed medication list (separate page for easy reference in a pharmacy).
• A printed follow-up plan.
• A USB stick with the FHIR Bundle, the PDF summaries, the ECG images, and a small README explaining what's on the stick and how to share with her GP.

The USB stick is encrypted; the password is told to her verbally (she writes it on a card). Her husband takes a copy. The patient controls who sees the data.

She also carries the encrypted record on her [patient wristband] if she's been issued one — but as a German tourist on a short trip, she wasn't. The wristband flow would be the alternative.

What lands at her German GP

Wednesday morning at Dr. Wolff's office in Hamburg. Astrid arrives. Hands over her folder.

Dr. Wolff reads the German PDF summary in five minutes. He has the clinical picture. He opens her USB stick on a Wi-Fi-isolated laptop, copies the FHIR Bundle. His EHR happens to support FHIR R4 import; he imports. Within a minute, the encounter, the procedure, the medications, and the diagnosis codes all populate his EHR.

His EHR's medication-interaction check flags one thing — the ticagrelor (the antiplatelet) interacts with one of her chronic medications she's been on for three years (he forgot to write it down at registration, but it's in his system). He adjusts a non-cardiac dose. He sees her cardiology follow-up needs and books her for an ECG and a cardiology consult next week.

His Estonian colleague's plan is now his plan. The handoff worked.

If Dr. Wolff's EHR did NOT support FHIR (some German GP systems don't yet), he would use the paper folder; the same information, just slower to enter into his records. The system degrades gracefully.

What stays in Estonia

The Estonian-side hospital customer organisation retains:

• The full encounter record (in Estonian per the records-language policy).
• The patient's foreign-patient registration entry.
• The discharge package as generated.
• The audit trail of every access to her record.

Astrid was asked at discharge whether she wanted the Estonian record retained or deleted after a period. She chose retention — "in case I come back". The retention is per a foreign-patient retention policy (typically shorter than the resident-patient retention but still meaningful, e.g., 7 years rather than 30). The audit trail is retained per zone-ee audit policy regardless.

If Astrid had chosen deletion, the clinical record would be deleted at the end of the foreign-patient retention period (default: 60 days post-discharge), but the audit-trail summary ("foreign patient X received care during dates Y-Z") would be kept — because audit retention is for the hospital's regulatory obligation, not just the patient's clinical record.

Insurance billing — separate flow

Astrid's care is covered under EHIC + her German statutory insurance (TK). Billing flows through the Estonian Health Insurance Fund (EHIF), which reconciles with TK under the EU framework.

The billing data flow is separate from the clinical record flow. The billing packet contains:

• Patient identity (German national insurance number, name, DOB).
• Diagnoses (ICD-10 codes).
• Procedures (medical-billing codes per Estonian system).
• Charges (per the EHIF schedule).

It does NOT contain the clinical narrative, the AI summaries, the voice recordings, the trajectory data. The billing system gets only what billing needs.

This separation matters for both privacy (clinical content not exposed to billing) and operational simplicity (the billing system doesn't have to handle clinical complexity).

Why this matters

Tourist and traveller healthcare is a high-volume, low-margin challenge that most healthcare IT systems handle awkwardly. The patient arrives without an entry in the national system; care is delivered; the patient leaves; the record stays in a system the patient cannot easily share with anyone at home.

The pattern matters because:

• It's not rare. A tourist-receiving city like Tallinn has thousands of foreign-patient ED encounters a year. A smaller number become admissions. The shape is the same.
• The home GP follow-up matters clinically. Without a smooth handoff, the patient arrives at their home doctor with a story and no documentation; their home doctor either repeats investigations or proceeds without the context.
• The patient owns their record. A discharge package that the patient physically carries is privacy-preserving and cross-jurisdiction-clean by design. No data-residency questions, no cross-border data-flow agreements required (just patient-mediated transfer).
• FHIR works as the interop format. The use case is exactly what FHIR was designed for: structured clinical information movable between systems. The platform's job is to package and the receiving system's job is to ingest; the patient is the carrier.
• Paper still works. When the receiving system can't ingest FHIR, the same information in PDF form does the work, just with manual data entry by the receiving clinician. The system doesn't fail when the receiver's tooling lags.

The scene

Wednesday 15:40 at a general practice in Tallinn. The patient, Marina K., 51, is being seen for a follow-up on hypertension. Her blood pressure on home readings has been 148/92 average over the past month despite being on amlodipine 5 mg. The GP, Dr. Suur, decides to add a low dose of perindopril. She also renews Marina's atorvastatin chronic prescription, which expires next month.

In a third item, Marina mentions she's been having recurrent bacterial vaginosis; the GP examines, agrees, prescribes a 7-day course of metronidazole.

The smart-action surface during the consultation drafts:

PRESCRIPTIONS — today's visit
─────────────────────────────────────────────────
NEW
 ☑ Perindopril 2.5 mg PO OD, 90-day supply, repeats × 3
 ☑ Metronidazole 500 mg PO BD × 7 days, 1 supply, no repeat

RENEWAL
 ☑ Atorvastatin 20 mg PO ON, 90-day supply, repeats × 3
   (current expires 2026-05-30)

NO CHANGE
 ─ Amlodipine 5 mg PO OD (continues; remaining supply OK)

[Confirm prescriptions]   [Schedule next BP review: 4 weeks]

Dr. Suur reviews, confirms. The signing surface asks for her identity confirmation (Mobiil-ID is the standard surface in Estonia; she taps and authenticates).

Marina is asked which pharmacy she'd like. The platform shows her saved-preferences pharmacy in Telliskivi as the default, plus three nearby alternatives. She confirms Telliskivi. The consultation closes.

What flows where

Three prescriptions go out:

Outbound — Marina K. — 2026-04-22 15:43

→  the national health information system (Eesti e-Tervise infosüsteem / Estonian e-Health):
   3 × digital prescriptions signed by Dr. Suur (Mobiil-ID),
   bound to Marina's national ID
   - perindopril 2.5 mg
   - metronidazole 500 mg
   - atorvastatin 20 mg

→  Marina's pharmacy preference: Telliskivi Apteek
   (the pharmacy choice is metadata on the e-script;
    she can still pick any pharmacy when she presents)

→  Marina's patient-side timeline:
   3 new prescription events; pickup status = pending

→  Dr. Suur's outbox:
   Audit trail of the three e-scripts; awaiting dispense events

The e-scripts live in the national health information system — the Estonian national e-health system — not directly in Jengu. Jengu's role at this point is to have authored the prescription, sent it to the national health information system (which is the authoritative e-script registry), and to listen for dispense events that will come back from the national health information system.

Marina leaves the clinic. The patient-portal app on her phone shows the three prescriptions, with a "ready at Telliskivi Apteek" status on each (the pharmacy choice is sticky but advisory; she can present at any pharmacy in the country).

At the pharmacy

17:05. Marina walks into Telliskivi Apteek on her way home. She presents at the counter. The pharmacist asks for her ID; Marina shows her national ID card. The pharmacy's terminal, linked to the national health information system, queries: "any active prescriptions for this patient?" Three come back.

The pharmacist confirms each:

• Perindopril 2.5 mg, 90-day supply. In stock. Dispenses.
• Metronidazole 500 mg, 7-day course. In stock. Dispenses. Asks Marina if she's been on it before; she has; gives the standard alcohol-warning leaflet.
• Atorvastatin 20 mg, 90-day supply. In stock (the cheaper generic is available; Marina is fine with the generic). Dispenses.

The total comes to a small co-payment (Estonia's pricing model subsidises chronic medications heavily; new acute prescriptions have higher co-pay). Marina pays. She leaves the pharmacy with three small bags.

The pharmacy's terminal posts dispense events back to the national health information system:

DISPENSE — Marina K. — 2026-04-22 17:14 — Telliskivi Apteek
  - perindopril 2.5 mg × 90 days dispensed (lot: PER-2026-04-018)
  - metronidazole 500 mg × 14 tablets dispensed (lot: MTZ-2026-03-122)
  - atorvastatin 20 mg generic × 90 days dispensed (lot: ATG-2026-04-009)

Substitution: atorvastatin brand → generic (patient consented)
Co-payment processed.

What lands back at Jengu

the national health information system pushes the dispense events back to the participating providers under the patient's data-sharing consent. Jengu listens on the national health information system bridge:

INBOUND — the national health information system bridge — Marina K. — 17:14

3 dispense events:
  perindopril, metronidazole, atorvastatin

→  Patient timeline:
   prescription events transition from "pending" to "dispensed";
   pickup-status flag clears
→  Dr. Suur's medication-adherence dashboard:
   refresh: Marina's three new prescriptions show as filled
→  Smart-action queue:
   schedule: BP review reminder in 4 weeks (set at consultation)
   schedule: metronidazole completion check in 8 days (per protocol)

The dispense events become MedicationDispense resources on Marina's record, tied to the original MedicationRequest resources that Dr. Suur authored. The loop is closed.

At the next visit

Four weeks later Marina comes back for the planned BP review. Dr. Suur opens her record. The medication-adherence dashboard shows:

Marina K. — medication overview (12 weeks)
═══════════════════════════════════════════════════════════════════
                         dispensed   adherence    next due
─────────────────────────────────────────────────────────────────
amlodipine 5 mg           yes (90d)   97%         2026-06-12
perindopril 2.5 mg        yes (90d)   started ✓   2026-07-21
atorvastatin 20 mg        yes (90d)   94%         2026-07-21
metronidazole 500 mg      yes (14×)   completed ✓ (28-day past)
                                       early refill: no

Home BP since perindopril add (4 weeks):
  baseline avg: 148/92  →  current avg: 134/82  ✓

The adherence percentages come from the gap between expected and actual dispense intervals — atorvastatin is supposed to be refilled every 90 days; if Marina has gone 96 days between two dispenses, that's 90/96 ≈ 94% adherence. (Adherence as a metric has well-known limitations; it measures dispensing, not taking; the dashboard surfaces the metric for what it is.)

Marina has been good on perindopril; her home BP has dropped 14/10 points; Dr. Suur is happy. They discuss continuing the dose.

The metronidazole shows as completed in the dispense record; Dr. Suur asks Marina how that course went; Marina reports resolution. The completion check that was queued by the smart-action surface auto-resolves.

Why this matters

The prescription-to-dispense loop is one of the few in healthcare where digital infrastructure mostly already exists — the national health information system in Estonia, equivalents in many EU countries — and the platform's role is not to build the loop but to close it cleanly:

• Author the prescription as a structured artefact of a recorded consultation, not as a manually-typed afterthought.
• Surface the patient's adherence trajectory at the next visit.
• Detect anomalies (early refills suggesting overuse, missed refills suggesting non-adherence, drug-drug interactions when the patient is on a new prescription from a different provider).

Without the loop closure, prescribing is fire-and-forget. The GP doesn't know whether the patient picked up the medication unless the patient says so. Adherence is invisible. Drug interaction detection only works at the point of dispense, not at the point of prescribing.

With loop closure, the GP can see the trajectory of medication behaviour over months, can have a fact-based conversation with the patient ("you've been refilling at about 60% of expected — is the medication causing problems?"), and can detect when a separate provider has added something unexpected.

The the national health information system integration is the unsexy plumbing that enables all of this. It's also where data-sovereignty constraints get exercised most concretely: the e-script is registered in a national system, the dispense event is in the national system, the patient's authoritative medication record is in the national system, and Jengu is a participant in the data flow under patient consent — not the primary holder.

The scene

Thursday 07:20. The patient, Krista L., 64, retired teacher, is at home in Tallinn with morning coffee. She had a GP visit yesterday afternoon — a routine review with two medication changes. She gets a notification on her phone: "Krista, eilse visiidi kokkuvõte on saadaval portaalis."

She opens the patient portal in her browser. Her name; her photo; the timeline of her recent visits. Yesterday's visit is at the top, expanded.

Visiit  2026-04-22  klo 14:30  —  Dr. Anu Saar (perearst)
═══════════════════════════════════════════════════════════════════════
KOKKUVÕTE
─────────
Tulite vererõhu kontrollile. Olete mõnda aega tundnud, et õhtuti
tekib peavalu. Mõõtsime vererõhu — 152/94, mis on natuke kõrgem
kui sooviks. Vaatasime üle ka teie kodumõõtmised, mis näitasid
samasugust kõrgenemist viimasel 2-3 nädalal.

MUUDATUSED RAVIS
────────────────
• Amlodipiin 5 mg → 10 mg (üks tablett hommikul)            ← ⚠
• Lisame perindopriili 2 mg (üks tablett hommikul)

PLAAN
─────
• Mõõtke vererõhku kodus 2 nädala jooksul kaks korda päevas.
• Helistage praksisesse, kui rõhk on alla 100/60 või kui tekib
  peapööritus, köha või jalgade turse.
• Järgmine kontroll 4 nädala pärast (kokku lepime telefoni teel).

[Salvesta / Prindi]   [Saada e-postiga]   [Tagasiside]

Krista reads. The dose change line catches her eye — "Amlodipiin 5 mg → 10 mg". She frowns. She picks up her phone, looks at the prescription bottle that the pharmacy gave her yesterday evening on the way home. It says 10 mg. She looks at the summary again. The before-arrow is 5 mg but she was on 10 mg already, and the new dose is — what? She remembers Dr. Saar saying the dose was being kept the same and only perindopril was added.

She taps the warning icon next to that line. A small correction surface opens:

You spotted something to clarify

LINE:  "Amlodipiin 5 mg → 10 mg (üks tablett hommikul)"

What would you like to flag?
○ This dose is wrong
○ The medication name is wrong
○ I wasn't told to do this
○ I don't understand this — please explain
○ Something else

[Optional: tell us what you remember being told]
______________________________________________
| The doctor said: "the amlodipine stays the   |
| same — 10 mg — and we add perindopril".      |
| So this line looks like it's saying I should |
| change to 10 mg, but I was already on 10 mg. |
______________________________________________

[Send to Dr. Saar]   [Cancel]

She picks "This dose is wrong", adds her note in her own words, and taps Send.

The flag lands in Dr. Saar's review queue at the GP customer organisation. The patient sees a confirmation: "Your flag has been sent. Dr. Saar will review and reply. You'll see the corrected summary here when done."

What the GP sees

Dr. Saar comes into the office at 08:30. Her morning has a small inbox of items. Among them:

Patient flag — Krista L. — yesterday's summary
═══════════════════════════════════════════════════════════════════════
Flagged line:
  "Amlodipiin 5 mg → 10 mg (üks tablett hommikul)"

Patient says:
  "The doctor said: the amlodipine stays the same — 10 mg —
   and we add perindopril. So this line looks like it's saying
   I should change to 10 mg, but I was already on 10 mg."

What I find:
  - Krista's medication record before visit: amlodipine 10 mg OD
  - Voice transcript at 14:42: "kohe võib jätkata amlodipiiniga
    10-mg annusega" (continue with the 10 mg dose)
  - Smart-action draft from consultation: "amlodipine continued"
    (NO change)
  - AI summary line: rendered as "5 mg → 10 mg" — INCORRECT

Suggested correction (auto-drafted):
  "Amlodipiin 10 mg — jätkub samas annuses (üks tablett hommikul)"

Decision:
[Accept correction]   [Edit correction]   [Discuss with patient]
[Mark this as a model error for review]

Dr. Saar reads. The patient is right. The AI rendered a "continued at 10 mg" line into a "5 mg → 10 mg" change. She accepts the correction. The summary on the patient's portal updates within seconds.

She also marks it as a model error for review. The platform's model-quality dashboard logs it — one of the inputs to the benchmark trend file that engineering uses to track summary quality over time.

What Krista sees

Krista refreshes the portal. The line now reads:

MUUDATUSED RAVIS
────────────────
• Amlodipiin 10 mg — jätkub samas annuses (üks tablett hommikul)
• Lisame perindopriili 2 mg (üks tablett hommikul)

✓ Krista, teie tagasiside põhjal parandasime eelmist rida —
  amlodipiin annus ei muutu. Aitäh!

A small thank-you note acknowledges her input. The summary now matches what she was actually told and what's on her pill bottle.

What the audit trail records

Behind the surface, three versions of the line now exist:

Krista L. — visit summary — line revision history
═══════════════════════════════════════════════════════════════════
Line: medication-change-1

v1 (2026-04-22 16:14, AI-authored)
   "Amlodipiin 5 mg → 10 mg (üks tablett hommikul)"

v2 (2026-04-23 07:24, patient-flagged)
   STATUS: under-review
   Flag reason: "This dose is wrong"
   Patient note: "The doctor said: the amlodipine stays the same..."

v3 (2026-04-23 08:42, GP-corrected)
   "Amlodipiin 10 mg — jätkub samas annuses (üks tablett hommikul)"
   Corrected by: Dr. Anu Saar (signed via Mobiil-ID)
   Reason: AI rendering error confirmed against consultation
   transcript at 14:42 ("kohe võib jätkata amlodipiiniga
   10-mg annusega")
   Model-error report: filed under model-quality dashboard

The patient sees v3 by default. She can open the revision history if she wants — many patients won't; some will, and the visibility is the right pattern. The audit trail is durable; even if v3 is later corrected again, all versions remain visible to anyone with audit access.

Why this matters

Two layers.

The clinical-quality layer. Patient-facing summaries written by AI from a recorded consultation are an obvious safety surface: if the AI gets the dose wrong, the patient who reads the summary may adjust their medication wrongly. The defence has to be three-fold: the AI is conservative on doses; the clinician reviews before publication where the risk is high; the patient has a low-friction correction path when something looks off. The third layer is what this story is about.

The trust layer. Patients vary in how much they trust their medical records. A patient who finds an error and has it corrected — with a thank-you and a visible audit trail — gains trust in the system. A patient who finds an error and has nowhere to flag it, or whose flag is ignored, loses trust permanently. The correction-feedback loop is a trust-building primitive, not just a quality mechanism.

The clinical model-quality benefit is real but secondary. Each patient flag becomes a labelled training signal for the next iteration of the model — a real-world ground-truth correction generated by the people most motivated to get it right. Over time this is the most valuable training data the platform can collect, because it surfaces exactly the errors that matter.

The scene

Thursday 13:00 at the anaesthesia department of a regional hospital. The day's preop list for Friday surgery has twelve patients across five specialties — three cataracts, two cholecystectomies, one arthroscopy, two hernias, one varicose veins, two ENT day-cases, one elective C-section.

The on-call pre-op anaesthesiologist, Dr. Kiri, has done this session every Thursday for two years. Pre-Jengu, it was a workflow of: print the list, dial each number, scribble notes on the print-out, type them up later, sign at the bottom of a paper form that someone else scanned. Three-hour rolling marathon.

Today the surface looks like this:

PRE-OP TELEVISITS — Fri 2026-04-23 surgical list — Dr. Kiri
══════════════════════════════════════════════════════════════════════════
  Slot   Procedure                    Sex Age   Status
─────────────────────────────────────────────────────────────────────────
1 07:30  Term C-section (elective)    F 39      ready
2 09:00  Cataract OD                  F 73      ready ▶
3 09:30  Cholecystectomy lap          M 61      ready
4 10:00  Inguinal hernia              M 42      pulled doc
5 10:30  Varicose vein stripping      M 58      ready
6 11:00  Cataract OS                  F 54      ready
7 11:30  Knee arthroscopy             M 68      ready
8 13:00  Cataract OD                  F 81      ready
9 13:30  Cholecystectomy lap          M 48      ready
10 14:00 Septoplasty                  F 34      ready
11 14:30 Inguinal hernia              M 71      ready
12 15:00 Tonsillectomy                F 59      ready

[Start preops]    [⚐ Reveal identity per row]    Avg call: 13 min

The list shows slot + procedure + demographics — no names. The clinician's working surface is pseudonymous; identity is revealed per row when Dr. Kiri starts a call (purpose tag verbal-address), so she can address the patient by name and dial the right number.

Each row's "ready" status comes from a pre-call data check the system has already done: medications reconciled from the national health information system, last labs pulled, anaesthesia history (if any), and the surgeon's preoperative note imported. Row 4 is "pulled doc" because the surgical pre-op note didn't get uploaded; the surface tells her she needs to chase it before she starts that call.

She opens the 09:00 cataract — taps the row, the reveal-identity modal opens, she confirms purpose verbal-address, the modal shows name + DOB + dialling number, she places the call. The modal dismisses on its short timer once the call is in progress.

A single call — slot 09:00, cataract

The screen splits: left side is the pre-op questionnaire, partially populated from existing data; right side is the televisit call controls (audio-only — the patient doesn't have video set up). Dr. Kiri dials.

Helmi answers. They greet each other in Estonian. Dr. Kiri explains briefly why she's calling — to go through some questions before tomorrow's cataract operation.

The questionnaire is structured but conversational. Dr. Kiri reads each section header, then has a real conversation around it. The structured-extraction LLM task listens and populates the form in real-time:

SECTION: ALLERGIES
[Auto-populated from the national health information system / known record]
  ✓ Penicillin — anaphylaxis (2009)
  ✓ Sulfa drugs — rash (2017)

Dr. Kiri: "Helmi, kas teil on uusi allergiaid alates eelmisest
korrast?"
Helmi: "Ei, ei ole olnud uusi."
                           [✓ No new allergies — confirmed by patient]

SECTION: MEDICATIONS
[Auto-populated from the national health information system]
  ✓ Amlodipine 10 mg OD
  ✓ Metformin 500 mg BD
  ✓ Atorvastatin 20 mg ON
  ✓ Eye drops (timolol) OS — for glaucoma
  ✓ Multivitamin (Helmi's own purchase)

Dr. Kiri: "Helmi, ma näen siin teie ravimid. Kas te võtate veel
midagi, mida siin ei ole?"
Helmi: "Ma võtan õhtuti ühe melatoniini, et magama jääda."
                           [+ melatonin 3 mg PRN ON (patient-reported)]

SECTION: ANAESTHESIA HISTORY
[Auto-populated]
  ✓ 2018: general anaesthesia for cholecystectomy — uneventful

Dr. Kiri: "Eelmine kord olite üldnarkoosis 2018. aastal — sapikivi
operatsioon. Ei tekkinud probleeme?"
Helmi: "Ei, kõik läks hästi. Pärast oli natuke iiveldust, aga
mitte väga halb."
                           [+ mild post-op nausea — noted; will plan
                            antiemetic prophylaxis]

SECTION: SYSTEMS REVIEW
[Walks through cardiac / respiratory / metabolic / neuro / other]
Dr. Kiri: "Hingamine on okei? Treppidest üles minemine?"
Helmi: "Jah, kaks korrust ilma probleemita."
                           [✓ Cardiac functional capacity ≥4 METs]
...

The extraction is accurate but conservative. When Helmi mentions the post-op nausea, the model captures it as a structured note; it does not auto-set "high PONV risk" — that's a clinical inference Dr. Kiri makes, and she taps the appropriate flag in the assessment surface.

When Helmi mentions her melatonin, it goes into the medication list with the source labelled "patient-reported" — distinct from the lines that came from the national health information system, which are anchored to a dispensing event.

The call is 14 minutes. At the end, the surface shows:

ASA score (auto-drafted):
  ASA II — mild systemic disease (HTN well-controlled, T2D
  well-controlled, glaucoma localised)

Fasting instructions:
  ✓ Auto-generated: "Nothing to eat after midnight; clear
    fluids until 06:00; usual morning medications EXCEPT
    metformin (skip Friday morning dose); eye drops as usual."

Anaesthesia plan (anaesthesiologist input):
  [_  Topical + light sedation for cataract                ]
  [_  PONV prophylaxis: ondansetron pre-induction          ]
  [_  Discussed risks: corneal abrasion, blurred vision     ]
       under light sedation — patient consented verbally     ]

[Confirm pre-op assessment]   [Edit]   [Escalate to in-person]

Dr. Kiri reviews the ASA draft — agrees with II. She types in the anaesthesia plan and selected risk-discussion items. Confirms the pre-op. Helmi gets a confirmation message on her phone with fasting instructions in Estonian.

Move to patient 2.

Slot 10:00 — the escalation

Row 4 is the one without an uploaded surgical pre-op note. Dr. Kiri's surface lets her message the surgeon directly: "I'm calling your hernia patient for pre-op — your note isn't visible to me; can you push it?" Surgeon replies within four minutes, the note appears.

Dr. Kiri reads it. There's a concerning history note: the patient had a TIA six months ago, was started on clopidogrel, has not been seen by neurology since. The surgical note doesn't address whether clopidogrel was stopped or how the perioperative anticoagulation was planned.

She taps Reveal identity on row 4, confirms purpose verbal-address, places the call. Conversation reveals:

• He stopped clopidogrel "a week ago" because his GP said something about stopping before surgery. He's not sure how many days exactly.
• His blood pressure has been "a bit high" lately; home readings he doesn't take.
• He says he's been short of breath walking up the stairs at his shop, which he attributes to being out of shape.

This is enough. Dr. Kiri stops the questionnaire. The patient needs a proper preop in person — too many open items, especially the new-onset breathlessness combined with recent TIA. She tells him this; he agrees.

She uses the surface's escalation control: "escalate to in-person preop today/tomorrow morning". This creates a same-day in-person slot and notifies the surgical scheduler that Friday's case may need to be delayed.

The escalation is captured as part of the row-4 pre-op record. The surgeon gets notified. By 14:00 the in-person preop slot is booked for late afternoon. The case may or may not happen Friday — it depends on the in-person assessment.

What flows from each call

Each completed pre-op call generates:

• A structured PreoperativeAssessment record on the patient's chart, populated from the questionnaire.
• A drafted ASA classification.
• An auto-generated fasting + medication instructions message to the patient.
• A signed (Mobiil-ID) anaesthesiologist note.
• An entry in the surgical day-list, marked "preop done".
• Voice recording of the call (held for the standard pre-op retention period, patient-consented at the call's start).

For the OR team Friday morning, the day-list view shows each patient's assessment summary, allowing the OR coordinator to plan order, anaesthetist allocation, and equipment.

The end of the day

17:20. Dr. Kiri finishes patient 12. She's done eleven complete pre-ops and one escalation. The voice-only televisit model has worked — the data she needed was either in the national health information system, in the surgical note, or extractable from the conversation. The questionnaire discipline that used to be paper-and-after-the-fact is now real- time and structured.

She did not type any of the notes. The dictation surface, the structured extraction, and the auto-drafted ASA + fasting instructions covered ~80% of the documentation. The remaining 20% — the anaesthesia plan, the risk discussion, her clinical judgement on borderline cases — she input directly.

Why this matters

Pre-op assessment by phone is increasingly the default for day-case and low-complexity surgery in most EU systems. The clinical content of the assessment doesn't change much by modality — the same questions need answers, the same risk profile needs evaluation. What changes is the workflow: phone calls don't produce documentation as a side-effect; in-person visits do (because the patient is there with a paper or screen).

A voice-only televisit with structured extraction restores the documentation-as-side-effect property to the phone-call modality. The anaesthesiologist conducts the call as a clinical conversation; the record assembles itself. The hidden tax of "type up all my preops at the end of the day" disappears.

The pattern generalises beyond anaesthesia. Most phone-based clinical work (mental health check-ins, post-discharge follow-up, chronic-disease monitoring) has the same documentation property: the conversation is rich, the typed record is thin. Closing that gap with structured extraction is the highest-leverage documentation intervention for telehealth.

The scene

Friday 18:40 at a regional hospital in northern Estonia. A woman, Marta, age 71, is admitted to the ED after a fall at home. She has multiple chronic conditions — atrial fibrillation on warfarin, hypertension, mild cognitive impairment — and lives alone. Her son drove her in. She's coherent, in pain, with a swollen left hip; possible fracture.

She is wearing a patient wristband — a slim, sealed plastic band with a small embedded NFC + secure-element chip. Her son hands the ED nurse a card explaining it. The hospital recognises the Jengu wristband; the ED is enrolled.

This is not science fiction — small NFC wristbands with secure elements are commodity hardware. The novelty is in how they're used: as a portable, signed slice of the patient's record that each clinical surface can read AND write to under the platform's identity and audit model.

What's on the wristband

The wristband holds a compact subset of Marta's data:

• Patient identity slice. Her national ID, name, date of birth, blood type, language preference, signed by her home customer organisation.
• Critical allergies + medications. Warfarin (lifelong), ramipril, amlodipine. Allergic to penicillin.
• Recent encounters (last 6 months). Pointers to the records themselves, with a one-line summary per encounter. Pointers are signed and time-stamped; the records they point to live in customer organisation systems and can be pulled when cloud is available.
• Advance directives + emergency contacts. Her son (with phone number), her preferences (capacity for decisions, resuscitation wishes).
• Most recent vitals trajectory (last 30 days). Captured by her home-care nurse and her own BT cuff; abbreviated form.
• Free space. Reserved for ward-by-ward additions during this admission.

The total payload is a few hundred kB. Storage on commodity NFC secure-element wristbands is in the tens of kB to low hundreds of kB; tight, but enough for a structured signed slice with references rather than full payloads.

The data is held in a structured signed-record format — each entry is a signed bundle, with the signature chain going back to the issuing customer organisation's signing key. Tampering or substitution is detectable.

ED admission

The ED registrar, Dr. Talviste, walks up to Marta. He has a handheld NFC reader (a small device he wears clipped to his scrubs) and his tablet. He taps the reader against Marta's wristband.

Within a second, the tablet's screen populates:

PATIENT (read from wristband — signed by customer organisation: tartu-perearst)
═══════════════════════════════════════════════════════════════════
Marta R.  born 1955-03-12  female  blood type: O+
Language: Estonian (preferred); also speaks Russian
National ID: xxxxxxxxxxx

CRITICAL — ALLERGIES
  ⚠ Penicillin — angioedema (2018)

CURRENT MEDICATIONS (last verified 2026-04-15)
  warfarin 5 mg PO OD (target INR 2-3 for AF)
  ramipril 5 mg PO OD
  amlodipine 5 mg PO OD

RECENT ENCOUNTERS (last 6 months — pointers, not full records)
  2026-04-15  GP visit (tartu-perearst) — routine review
  2026-03-22  Cardiology (regional-cardiology) — AF rate control
  2026-02-08  ED visit (this hospital) — fall, no fracture
  2026-01-30  Lab — INR 2.4

ADVANCE DIRECTIVES
  Capacity: intact (per GP 2026-04-15)
  Resuscitation: full code per current wishes
  Surrogate: son (M. R.) ☎ +372 5xxx xxxx

VITALS (last 30 days, home + community)
  [trajectory abbreviation]

────────────────────────────────────────────────────────────────────
Signed by customer organisation: tartu-perearst (key id: ...)  fingerprint verifies ✓
Last updated:     2026-04-15 14:22 (by home customer organisation)

Dr. Talviste has the salient picture instantly. Warfarin on board (important: she had a fall, intracranial hemorrhage risk is elevated, urgent CT brain). Penicillin allergy (avoid the default IV antibiotic if she needs cover). Capacity intact and full-code per advance directive.

He examines, orders the CT, requests a hip X-ray. He also captures the ED encounter using the tablet. The session opens. Voice + vital monitor + manual input.

What gets written back to the wristband

After his initial assessment, Dr. Talviste writes the ED encounter summary back to the wristband. The tablet issues a signing operation against the hospital's edge signing key; the signed entry is taped into the wristband's free space:

ENTRY — added 2026-04-22 18:51
Tenant: regional-hospital-id
Signer: Dr. Talviste (edge-signed for: regional-hospital-id)
Signature: ...

ED ENCOUNTER
  Chief complaint: fall at home, hip pain
  Examination: left hip externally rotated, shortened;
  pain on movement; neurovascular intact
  Vitals on admission: BP 162/94, HR 78 (rate-controlled AF),
  SpO2 96, temp 36.7
  Orders placed: CT head (urgent — warfarin + fall),
  XR L hip + pelvis, INR, FBC, U&E, type & screen
  Working impression: probable L hip fracture; warfarin
  reversal may be needed if intracranial hemorrhage

Marta is now carrying this entry on her wrist. The hospital's appliance has the same record locally; if the cloud is reachable, it syncs upward to the regional hospital's customer organisation.

The CT and XR happen. Hip is fractured (intertrochanteric, left). CT head is clear. Orthopaedics on call accepts. She'll go to surgery tomorrow morning; needs warfarin reversal tonight before the operation.

Dr. Talviste writes a second entry to the wristband with the findings and the plan. By 20:30 Marta is admitted to the orthopaedic ward.

Inter-ward transit when the hospital is offline

The same night, around 22:30, the hospital experiences a partial network outage (not as severe as hospital-it-blackout; just the ED-to- orthopaedics network segment is down because of an unrelated fault). The ED edge can't reach the orthopaedic-ward edge over the hospital network.

The orthopaedic ward nurse, Liina, is at Marta's bedside getting her settled in. She has the orthopaedic ward's tablet. She taps her NFC reader against Marta's wristband.

The wristband presents:

PATIENT (read from wristband — signed chain verified)
══════════════════════════════════════════════════════════════════
Marta R., 71F, hip fracture, admitted ED 2026-04-22 18:40

[base record from home customer organisation]
+ ED entry by Dr. Talviste (regional-hospital-id, signed
  2026-04-22 18:51) — examination, orders
+ ED entry by Dr. Talviste (signed 2026-04-22 19:55)
  — imaging confirms L hip intertrochanteric fracture, plan
  for surgery, warfarin reversal needed

Signature chain: 3 entries verify ✓

The orthopaedic ward edge has not seen Marta before in its local cache. The hospital network is down between ED and orthopaedics. But the wristband carries the data. Liina has the full picture without any network coordination — the patient is the carrier.

She adds the warfarin reversal plan and admission orders. Writes a signed entry to the wristband. Now there are four entries on Marta's wrist, each signed by its issuing surface, chained back to the issuing customer organisation.

When the network comes back at 23:40, the ED edge and the orthopaedic ward edge both sync upward to cloud. The entries they generated locally appear in the regional hospital customer organisation's record. The wristband's entries match. Reconciliation is by signature: each entry has a unique signed hash; duplicates can be merged; ordering is by sequence number; the audit chain is continuous.

What's special about the wristband as a data carrier

A wristband-as-data-carrier model differs from a wristband-as- identifier model in important ways:

• The wristband is not a key to a database. Reading the wristband doesn't query anything. It provides the data itself, signed and verifiable, offline.
• Writing to it captures clinical actions for transit. Each ward signs its own entries; the wristband becomes a chain of signed claims from each ward that touched the patient.
• Network failures are invisible. As long as the wristband is on the patient and the next ward has a reader, the chain continues.
• Cryptographic integrity makes the device honest. A wristband replaced by an attacker can't carry honest claims forward because the new wristband doesn't have the signing chain.

The pattern works because the wristband is a carrier and the clinical-edge surfaces are signers. The wristband holds no signing keys of its own; it cannot sign anything. The signing authority is at each surface that writes to it.

Reconciliation with cloud after re-connection

Once the network is restored, three things happen:

1. Each edge syncs its own local-captured records to cloud. The ED edge pushes the ED encounter; the orthopaedic ward edge pushes its admission notes; both via standard sync.
2. The wristband's contents are not separately uploaded. The wristband is a carrier, not a record-of-record. The authoritative records are at the edge that authored them; the wristband is the same data in transit form.
3. The cloud reconciles the two record streams to produce a single timeline. Each entry has its signature; signature matching identifies duplicates; the union is the patient's timeline.

If for some reason an edge fails before syncing (catastrophic loss), the wristband's signed entries are still valid evidence that the records existed — they can be re-derived from the wristband content. The wristband is a kind of distributed backup.

Marta goes home

Five days later, Marta is being discharged. The orthopaedic ward writes a discharge summary entry to her wristband — the operation done, the medications she's on now (warfarin restarted, paracetamol PRN, no opioids per her wish), the physiotherapy plan, the follow-up appointment.

She and her son leave. She still wears the wristband. The home customer organisation (her GP) will read it at her next visit and update her GP-side record from the discharge entry.

The foreign-patient export — bridging to her German GP

Marta is half-Estonian, half-German. She spends summers in Germany visiting her sister. Three months later she's in Berlin, needs a follow-up with a German GP about a question that came up.

She walks into the German GP's office wearing the wristband. The German GP does NOT have a Jengu reader. He has a smartphone with an NFC reader chip (standard on most modern phones), and the Jengu platform has a thin reader app that any smartphone can install.

The doctor scans her wristband. The app:

• Reads the signed chain on the wristband.
• Verifies signatures against the platform's public key directory.
• Renders the contents in German (translated via the platform's translation pipeline).
• Offers a standard FHIR export: the wristband's content packaged as a FHIR R4 Bundle, ready to import to any FHIR-aware German system.
• Offers a PDF printout: the same content as a 4-page patient-summary document in German.

The German GP imports the FHIR Bundle into his EHR. If his EHR doesn't accept FHIR (some don't yet), he prints the PDF and puts it in Marta's paper folder. Either way, he has the clinical context.

He doesn't write back to the wristband (his system is not enrolled on the platform; the wristband would reject an unsigned addition). The interaction is read-only from his side. Marta still has the wristband when she returns to Estonia.

Why this matters

Healthcare interoperability has been a 30-year unsolved problem because the assumed pattern is "every system talks to every other system over the network". Network-based interop requires agreements, integrations, and trust relationships that don't scale across all the systems a patient will encounter in their life.

A patient-carried portable signed record is a different pattern:

• The patient is the data carrier. No network coordination required for the read side.
• Each clinical surface signs its own additions. Audit integrity preserved without a central audit authority.
• The carrier survives offline events. Hospital IT blackouts, rural disconnections, cross-border travel all become transparent.
• The fall-back to paper exists. Print the same data; paper still works.

It's not a replacement for record-of-record systems. Each clinical surface still holds its own authoritative record. The wristband is a courier between them.

The pattern is not new in principle — medical bracelets with critical info have existed for decades — but the combination of NFC + secure element + signature chain + standard FHIR export + ubiquitous reader (any smartphone) makes it operational at platform scale for the first time.

The scene

23:14, Tuesday in November. A regional hospital in northern Estonia. The basement gas-plant room — old equipment, deferred maintenance — has a fitting failure on the oxygen-supply manifold; a small fire follows; an isolated explosion in the plant room itself. Nobody is killed; one maintenance technician is injured and is brought up to the same hospital's ED.

The explosion damages:

• The main hospital network distribution switch (the basement comms rack is in the same plant area).
• The hospital's link to its primary internet provider via the underground fibre.
• One of the two main electrical distribution panels.

The damage means: half the hospital is on generator power within 90 seconds; the other half stays on grid. The hospital system, the lab system, the imaging system, the PACS, and the hospital's email — all centralised on the inside of the damaged switch — are unreachable from clinical wards. The hospital is isolated: not externally, but internally. Centralised IT inside is down. Clinical wards are still powered and running, but they cannot talk to their own hospital's systems, let alone the outside world.

The ED is on grid power; it's working. The night charge nurse, Tiia, is the first to notice when she tries to look up the maintenance technician's record (he's a hospital employee) and the hospital system screen has been frozen for two minutes.

What the Jengu edge does

The hospital's main appliance for the medicine ward is a rack-mounted appliance with an internal battery rated for 4 hours of operation. Each clinical-area edge (ED, ICU, three wards, three outpatient zones) has similar battery backup.

Within 15 seconds of the network distribution failure, every edge in the hospital has noticed that its cloud uplink is dead. The behaviour kicks in:

• Stay running. All capture (voice, devices, structured input) continues. Sessions in progress are not interrupted.
• Buffer locally. Anything that would have been synced to cloud queues to local disk. Each edge has multi-day local storage.
• Switch the UI mode. The tablet's status bar shows a red "OFFLINE — capturing locally, will sync when reachable" badge. Functionality that depends on cloud (lookups between customers, the trajectory aggregator) is greyed out with a tooltip.
• Try local mesh. Each edge attempts to reach other edges it knows about over the local network. The local network is damaged but not gone — edges within the same subnet (the ED edges find each other; the medicine ward edges find each other) can still talk. Cross-subnet (between ED and medicine ward) is dead because the distribution switch is the bridge.

The edges now form two local clusters: the ED cluster and the medicine-ward cluster. Each cluster can still pool state internally. Cross-cluster communication requires the cloud (or some other bridge).

What gets recorded during the blackout

Three patient arrivals at the ED during the blackout window (23:14 to 03:48):

• 23:25: the injured maintenance technician. Burns to hands and face, smoke inhalation.
• 00:48: a 67-year-old man from a nursing home with possible stroke (left-sided weakness).
• 02:14: a 28-year-old woman with abdominal pain and pregnancy test positive.

The ED edge records each arrival as normal. Voice + vital monitor + manual input. The stroke patient's case is the most clinically time-sensitive — the ED registrar wants to consult neurology and start the stroke pathway, which usually means talking to the on-call neurologist who is at home and would normally be reached via the hospital phone system, which is also down.

The local mobile network is up. The registrar dials neurology on his personal phone — works. Neurology gives advice verbally. The advice is captured on the ED-side voice channel (the registrar narrates back: "talked to Dr. K, said thrombolysis can wait until imaging available — currently imaging not reachable, will reassess in 15 minutes"). The captured record now has a structured note for "phone consultation with neurology, 00:52, voice-captured".

CT imaging is unreachable. The ED registrar uses the bedside ultrasound (a registered device on the edge) for what he can, defers the CT until imaging is back.

The medicine ward continues with a quiet night — no new admissions during the blackout, the existing patients are stable, nurses are doing routine observations on paper because the EHR is down but Jengu is up.

The bridge

00:35. The ED consultant on-call, Dr. Põllu, arrives. She has been called in for the explosion casualties (only one casualty, in the end). She sees the situation: edges are recording, but nothing is going to the cloud. She has her personal smartphone with her, on a different mobile network than the hospital's broken external link.

The platform has a disaster-mode uplink pattern. She opens the Jengu mobile app, taps "share my connection as cloud uplink", scans the QR code on the ED's main edge appliance. The edge's outbound traffic now routes through her phone's hotspot.

Edge: hospital-ed-main
═════════════════════════════════
Status: OFFLINE — primary uplink down (since 23:14)
Local cluster: 4 edges co-operating
Local queue: 2.4 GB pending sync

Disaster-mode uplinks available:
  → Dr. M. Põllu's phone (Elisa LTE, 24 Mbps)
                          [accept and route via this]
  → Nurse R.'s phone (Telia LTE, 18 Mbps)
                          [available; not yet activated]

She accepts. Within seconds, the edge's outbound queue starts draining. Priority-tier-1 messages (active patient events, vital trajectories, the new arrivals' records) start landing in the cloud. Priority-tier-2 (queued structured records) follow. Priority-tier-3 (large media files like full audio recordings) are deferred — they can come over the regular uplink once infrastructure is back, no need to push them over a mobile hotspot.

The mobile uplink also covers the medicine-ward cluster, but only because the medicine-ward cluster can reach the ED cluster via the local mesh now that the ED edge is acting as gateway — wait, no. The distribution switch is down, so the two clusters can't reach each other locally.

The disaster-mode pattern handles this case too. The medicine ward's nurses see the ED has a working uplink (the platform's local-cluster discovery surfaces it), and one of them does the same QR-code pairing with her own phone for the medicine ward cluster. Now two parallel bridges: one through Dr. Põllu's phone for ED; one through Nurse R.'s phone for medicine.

By 00:50, both clusters are flushing high-priority traffic to cloud. The ED's stroke patient's session shows up in the hospital's cloud view. The fact that the hospital is in a disaster state is visible to the platform (and visible to the ICT director who's been notified by his on-call paging system of the cloud-side anomalies; he's now driving in).

The powerbank

The ED edge's battery is rated for 4 hours; by 03:00 it's at 20%. The Jengu edge spec calls for an externally-attachable USB-C-PD powerbank port; the ED edge has one. A 26,000 mAh powerbank gets plugged in. The edge goes back to full charge draw. Estimated additional runtime: another 6 hours.

The medicine ward edge has a similar pattern; the IT team (who arrived around 01:30 once they realised the scope of the outage) has wheeled additional powerbanks from the hospital's emergency-preparedness store to each edge.

The phones being used as bridges are also on powerbanks now — Dr. Põllu's phone has been running for two hours as a hotspot and is heating up. Powerbank inline. The IT team takes over managing the bridge phones as their main task — keeping them powered, swapping when one runs low, monitoring throughput.

The audit trail through the blackout

Every edge captured local-storage records during the blackout. Each record has its full audit metadata: speaker IDs, timestamps, context. The records that synced during the blackout (through the bridges) carry an additional marker: "synced via disaster-mode uplink at hh:mm, uplink-provider was X". This is not invisible — it's part of the audit story.

When infrastructure is restored at 03:48, the regular uplink returns. The remaining queued media files start syncing. The edges revert to normal operation. The disaster-mode markers remain on the records that synced during the bridge period.

The next morning, the ICT director and Tiia (the quality officer) generate an audit summary of the blackout period:

BLACKOUT INCIDENT — 2026-11-XX 23:14 → 2026-11-XX 03:48
═══════════════════════════════════════════════════════════════════════
Duration:           4h 34min
Cause:              basement plant explosion (separate report)
Cloud uplink:       severed at 23:14; restored at 03:48

Edges operating during blackout:    8 (all)
Sessions in progress at start:      3 ongoing
New sessions during blackout:       3 (ED arrivals)
                                    + 17 medicine ward nurse-obs
Sessions captured offline:          23 total

Disaster-mode bridges activated:
  → ED main edge ← Dr. Põllu's phone (00:35–03:48)
  → Medicine ward edge ← Nurse R.'s phone (00:48–03:48)
  → ICU edge ← stayed offline (no critical updates needed)

High-priority data synced via bridge:  ~340 MB
Total queued at restore:                ~6.2 GB
Total synced after restore:             6.2 GB (full)

Audit chain integrity:  CONTINUOUS through blackout
                        (offline sequence numbers verified
                         against pre + post-blackout chain)

Disaster-mode events:
  - 23:14  ED main edge: uplink lost (within 15s of explosion)
  - 23:18  All edges: local-only mode active
  - 23:25  ED registrar phone consult to neurology — recorded
  - 23:32  ED registrar bedside US — substituted for CT
  - 00:35  Dr. Põllu activates phone bridge → ED edge
  - 00:48  Nurse R. activates phone bridge → medicine ward edge
  - 01:30  IT team on-site; powerbank deployment begins
  - 02:14  Third ED arrival (28F, abdominal pain)
  - 03:48  Main uplink restored
  - 04:02  All edges back to standard operation

NO DATA LOSS.

The audit chain integrity is the most important property in this story. Every record captured during the blackout was sequenced into the audit chain, with its offline sequence numbers spanning the gap continuously. When the cloud-side chain resumes, the offline-side chain rejoins it. Mathematically, there is no inserted, missing, or modified entry across the blackout window. The Health Board, if they ever investigate the night, can verify this against the cryptographic anchoring.

Why this matters

Hospital IT outages are not rare. They happen because of infrastructure failures, ransomware, electrical events, fires, construction accidents, and software-update botches. The question for a clinical platform is not whether the centralised systems can be relied upon, but what the platform does when they can't.

The answer in this story is:

• Keep clinical work going. Capture, record, structure. Local-only mode is not "degraded"; it's "fully functional on local resources, just not syncing for now".
• Compose around the failure. Each clinical area's edge is autonomous; local clusters pool state where they can.
• Provide a bridge path. Personal phones as disaster-mode uplinks; QR-paired; high-priority traffic only; survives hours.
• Preserve the audit chain. Through the offline period; with explicit markers for atypical paths; with mathematical reconstruction proof.

The pattern is not "disaster recovery" in the IT sense. There is no restore-from-backup operation. The data was never lost. It was just locally held until the network came back. The platform's offline-tolerance is what made the blackout a clinical inconvenience instead of a clinical crisis.

The story is also evidence for a specific platform design choice: the appliances are not thin clients to a cloud. They are functional clinical appliances that happen to sync. The distinction is invisible when everything is working; it is load-bearing when it isn't.

The scene

A Wednesday in October during a respiratory-virus surge. The public-health authority has stood up a mobile testing programme to catch cases early and inform surveillance. One of the vans is parked outside the Tallinn central railway station from 09:00 to 17:00. The team: two health-care assistants doing swabs, one registration clerk inside the van running the edge, one public- health officer overseeing.

The van itself is a converted minivan with a sliding door, a small interior workstation, and a heated swabbing booth. The edge appliance is bolted to a shelf inside; it runs on a combination of vehicle power and a small UPS. Cellular is via a dual-SIM modem with carrier failover.

By 09:30 there's already a queue of fifteen people on the sidewalk.

The flow per person

Each person walks up. The registration clerk taps a tablet running the van's edge UI.

MOBILE TEST REGISTRATION — Van JV-04 — Tallinn Central
══════════════════════════════════════════════════════════════════
TEST OFFERED:  SARS-CoV-2 PCR (nasopharyngeal swab)
COST:          free (public health programme)

IDENTITY
  ☑ Estonian ID card / Mobiil-ID
  ☐ EHIC card (EU)
  ☐ Passport (non-EU)
  ☐ Anonymous (declined identification)

  [Tap to scan ID]   [Wait for Mobiil-ID auth]

SYMPTOMS — quick screen
  [ ] None — pre-travel / contact
  [ ] Mild — runny nose, sore throat
  [ ] Moderate — fever, cough, fatigue
  [ ] Severe — escalate to clinical guidance

CONSENT — concise (read on screen + verbal)
  ☑ Consent to be tested
  ☑ Consent to be informed of result
  ☑ Consent to submit to national surveillance
     (anonymised aggregate + identified result to the national health information system)

CONTACT — for result delivery
  ☑ SMS to phone (auto-filled if Mobiil-ID)
  ☑ Email (auto-filled if available)
  ☑ Patient portal (if Estonian)

A typical encounter:

1. Person presents national ID. Tap on the card reader. National identity verified.
2. Registration auto-populates name, DOB, national ID. Phone number pulled from the national health information system register.
3. Symptom screen — quick three-tap answer.
4. Consent confirmed (the clerk reads the brief consent verbally in Estonian or English; the person confirms; the screen records the consent).
5. Test order generated. Order ID printed on a small adhesive label.
6. Person moves to the swabbing booth. Health-care assistant swabs. Specimen goes in a tube; label applied to the tube; the tube goes in the cooled specimen tray.
7. Person told: result within 6-12 hours, by SMS + portal.

Time per person: about 90 seconds at the registration tablet, ~30 seconds at the swab. Pipeline running: while person A is being swabbed, person B is registering. Throughput at peak: ~50 people per hour.

The pseudonymity model

The specimen label has only:

• The order ID.
• The collection date and time.
• The collection location code (van + city + station).

No patient name. No national ID. Just the order ID.

The mapping from order ID to person is held entirely on the ordering side — the van's edge, which syncs to the public-health programme's customer organisation in cloud. The lab that processes the specimens never sees patient identity. Same pattern as order-to-result-loop, applied to mass public-health testing.

This matters at the scale of public-health programmes:

• The lab's database is anonymous. Even at hundreds of thousands of specimens, no patient identifiers are present. A breach yields nothing identifiable.
• The programme's database has identities. Mappings exist there, under strong access control + audit.
• National surveillance gets aggregates. When the programme reports daily case counts to the surveillance backbone, the aggregate is by demographics and geography, not by individual.
• Individual results to the individual. The result flows back via SMS + portal to the person tested — through the ordering programme, never through the lab.

Edge operating on a busy street

The van's edge has to handle:

• Variable cellular. Tallinn central station is busy; cell congestion is common. The dual-SIM modem with carrier failover helps; the edge's queue-and-sync pattern handles the rest.
• Bursts. When a tram empties, fifteen people queue at once. Throughput at the edge has to keep up.
• Cold and wet outdoor. Wet ID cards, cold hands, gloves on the swabber, condensation on screens. The hardware spec has to survive this.
• Identity diversity. Estonian ID cards (most common); EHIC from any EU country; passports from anywhere; declined identification (people who refuse to identify but want a test — a small fraction, supported with anonymous-mode for surveillance value).

Each registration writes to the van's local queue. When cellular is good, the queue drains in seconds; when cellular is poor, the queue grows. The edge can hold a full day's testing locally; the hospital-style multi-day capacity is overkill but provides safety margin.

Specimen run

12:30. The morning's specimen tray is full — ~120 specimens collected. A courier from the partner lab picks up. The tray is sealed with a tamper-evident strip. The chain-of-custody handoff is recorded on the van's edge: courier ID, time, specimen count.

The tray reaches the lab at 13:45. The lab runs PCR. Results start coming back from 18:00 onwards.

Each result returns to the programme's customer organisation with its order ID:

RESULT — order ORD-2026-10-XX-JV-04-...-00072
─────────────────────────────────────────────
Specimen: nasopharyngeal swab
Test:     SARS-CoV-2 RT-PCR
Result:   POSITIVE  (Ct: 22)
Reported: 2026-10-XX 18:14

The programme's customer organisation joins the order ID to the registered person. Result delivery is automatic:

• SMS to the person's phone, in their preferred language: "Your COVID test result from JV-04 is POSITIVE. Please isolate at home. Information and guidance at [link]. Contact your GP if you develop severe symptoms."
• Patient portal updated.
• For positive results: contact tracing surface notified.
• For negative results: similar SMS, no further action.

By 22:00 of the same day, ~190 of the ~200 tested have results delivered. The remaining ~10 require lab follow-up (indeterminate, low specimen quality, requires re-test).

Surveillance reporting

Each result also flows to the national surveillance backbone in aggregate form:

DAILY AGGREGATE — 2026-10-XX
Van:        JV-04
Location:   Tallinn central station
Tested:     200
Positive:   17  (8.5% positivity)
By age:     0-18: 1/12 (8.3%)
            19-39: 7/72 (9.7%)
            40-59: 6/84 (7.1%)
            60+: 3/32 (9.4%)
By symptom: asymptomatic: 4/132 (3.0%)
            symptomatic: 13/68 (19.1%)

The aggregate is broken down enough for surveillance value but holds no identifiable data. The surveillance backbone uses it to track positivity trends, geographic clusters, demographic patterns.

Individual results to the surveillance backbone (with national ID) are submitted separately, under the consent flow, for case tracking and contact tracing. This is a stricter consent path and the patient sees it at registration as a separate item.

Why this matters — beyond COVID

The story is COVID-flavoured but the pattern generalises:

• Mobile testing for any condition. Influenza surveillance, HIV outreach, hepatitis screening, STI testing. The same van-based, anonymous-lab, identified-programme, aggregate- surveillance pattern works for many things.
• Mobile vaccination. Same registration shape, different product. Edge captures vaccination event; vaccine record flows to national registry.
• Pop-up clinics. Festivals, large events, transit hubs. Same pattern.
• Disaster response. Refugee health screening, post-event symptom surveillance. Same pattern.

The capabilities exercised are: low-friction registration with diverse identity sources, the anonymous-lab pattern, structured consent, edge-operating-in-the-field, lab-bridge results return, surveillance-aggregate output, individual result delivery.

The combination doesn't exist in most healthcare systems as a unified offering today. Each public-health programme builds its own ad-hoc registration system, its own results delivery, its own surveillance pipeline. Consolidating these into a configured shape of the platform reduces the build-cost per programme.