Platform features

Why this matters

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

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

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

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

What's in the box

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

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

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

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

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

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

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

Standards we lean on

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

What customers and operators experience

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

Limits and trade-offs

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

Related features

• Tenant data isolation — the boundary inside which a zone's rules apply.
• Right-sized AI pipeline — uses zone membership to pick AI providers.
• Patient data anonymisation — runs zone-specific redaction patterns.
• Regulatory audit trail — records every decision under the zone's audit format and retention rules.
• Open standards data portability — national FHIR profiles ride on zones.
• Sources of truth — per-zone terminology + classifiers + overlays follow the two-tier rule: authored / synced into project-setup/<zone>/... in git, then synced into Medplum at bootstrap + on a scheduler.

Why this matters

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

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

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

What's in the box

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

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

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

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

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

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

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

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

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

Practices we follow

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

What customers and operators experience

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

Limits and trade-offs

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

Related features

• Tenant lifecycle — lifecycle workflows read intent from the configuration repo.
• Tenant data isolation — the repo defines each tenant's boundary.
• Compliance zones — branches and folders carry zone-specific configuration.
• Regulatory audit trail — the git history is itself an audit trail of configuration changes.
• Sources of truth — this capability is the canonical realisation of Rule 1 (git is the configuration source of truth). Rule 2 names Medplum as the runtime source of truth that the git config flows into.
• Edge fleet management — edge enrollment keys and per-site settings live in the same repo.
• Open standards data portability — configuration is itself FHIR R4, so the setup work is reusable in any other FHIR-aware system.

Why this matters

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

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

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

What's in the box

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

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

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

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

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

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

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

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

Practices we lean on

• GDPR Article 32 — security of processing. Resilience is named as a security measure in its own right.
• HIPAA Contingency Plan (45 CFR 164.308(a)(7)). Required feature to access ePHI during an emergency.
• ISO/IEC 27001 Annex A.17 — business continuity. Redundancy and failover principles applied to clinical operation.

What customers and operators experience

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

Limits and trade-offs

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

Related features

• Tenant data isolation — edges belong to a single tenant.
• Edge fleet management — running many edges together (enrolment, updates, retirement).
• Speech anonymisation — recordings happen at the edge by default; raw audio rarely leaves the site.
• Modular clinical features — modules declare what they need at the edge versus the cloud.
• Regulatory audit trail — receives the audit events each edge produces locally.

Why this matters

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

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

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

What's in the box

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

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

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

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

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

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

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

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

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

Practices we follow

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

What customers and operators experience

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

Limits and trade-offs

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

Related features

• Device management framework — the unified framework every external integration registers with; edges share configuration screens, monitoring, and audit with every other device type. Edge-fleet-management is the edge-specific lifecycle within that framework.
• Hybrid edge–cloud operation — individual edges are described there; fleet management is how many of them run together.
• Tenant data isolation — every edge belongs to exactly one tenant.
• Tenant lifecycle — a tenant's edges follow its lifecycle.
• Regulatory audit trail — every fleet event is an audit event in the same trail as clinical actions.
• Declarative tenant configuration — enrollment keys and per-site settings live in the same config repo.

Why this matters

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

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

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

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

What's in the box

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

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

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

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

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

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

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

Standards we lean on

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

What customers and operators experience

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

Limits and trade-offs

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

Related features

• Identity pseudonymization — the structural layer of pseudonymisation. The two compose: IPS removes the field, ANO removes the name a clinician wrote in a note.
• Speech anonymisation — the upstream pipeline whose only output to the rest of the platform is anonymised text.
• Right-sized AI pipeline consumes anonymised text for every downstream AI job; anonymisation runs before any of those jobs see the transcript.
• Regulatory audit trail records every raw access — when raw is needed, the access is auditable.
• Compliance zones declare each zone's patterns for jurisdiction-specific personal-data formats.

Why this matters

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

GDPR Article 4(5) describes a different architecture: identity in one place, clinical content in another, a controlled gate between them. Most EHRs don't implement it; we do. The clinical layer of our FHIR store holds no names, addresses, contact details, or national identifiers. Identifying information lives in Person resources, encrypted at rest, accessed only through a purpose-stating disclosure path that audit-logs every read.

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

What's in the box

• Two-resource model. Person is the identity holder. Patient and Practitioner are thin clinical-context resources that reference Person by ID. Tenant FHIR profiles enforce the boundary: a write that includes a forbidden field on Patient is rejected at validation.

• Default-pseudonymised reads. Every read returns the clinical-only resource. Identity is added only when the request explicitly asks for it with a purpose. Routine browsing of charts is identity-free without any special effort by the clinician.

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

• Disclosure audit. Every enriched read writes an AuditEvent carrying the accessing user, the accessed Person ID, the stated purpose, and a timestamp. The accumulated log is the customer's evidence for HIPAA Accounting of Disclosures and GDPR Article 5(2) accountability.

• Search-by-name returns IDs. A query for "all patients named Smith" returns a list of opaque references — just enough context to confirm the right person, no full demographics. Mass exfiltration via search is structurally impossible.

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

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

• Structural, not opt-in. A new module that wants to read identity has to call the purpose-bound API; no module gets identity by default. The "oh I'll just join the Patient table" leak class is closed at the architecture level, not as a code-review concern.

Standards we lean on

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

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

What customers and operators experience

• A doctor opening a chart sees medical context first — chief complaint, history, current observations — labelled with an opaque reference. A clearly-marked "identify patient" action discloses the name in a session-scoped sidebar with a captured reason.
• A receptionist looking up a patient by name types the name and gets opaque references with just enough context (e.g., year of birth) to confirm the right person.
• A compliance officer can produce a complete log of every PII disclosure for a tenant — who accessed which patient's identity, when, for what purpose.
• A patient asking "who has seen my data?" receives a precise answer: a list of disclosures with timestamps, accessing user, and purpose. Not "many people, in the normal course of care".
• A platform operator with database access cannot read patient names — they aren't there. Bulk database access still does not tell whose data is whose.
• A research team running consented analytics gets a clinical dataset that's structurally Safe Harbor de-identified. The data is born pseudonymised.

Limits and trade-offs

• Free-text re-identification persists. A doctor writes "Mrs Smith was anxious" in a Procedure.note. Structural separation doesn't catch this — that's [Patient Data Anonymisation]'s job. The two layers compose.
• Quasi-identifier leakage is possible. A rare condition + admission date + tenant + sex + birth year can re-identify someone in a small population. Mitigation requires statistical safeguards or small-cohort access limits — complementary controls.
• Clinical workflow needs identity at point of care. The "identify patient" reveal is always available; the regulatory benefit is that the act is audited, not that it doesn't happen.
• External integrations need adapting. A module that pulls Patient resources expecting Patient.name to be populated will see empty fields. Enrichment APIs are available for legitimate clinical-care reads.
• Person lives inside Medplum today. Stage 1 keeps the identity store in the same project as clinical resources, with field-level encryption protecting it. Stage 2 (extracting Person to a dedicated identity-vault service) is documented as an escalation path with explicit risk triggers.

Related features

• Patient data anonymisation — the narrative layer of pseudonymisation. Identity Pseudonymization is the structural layer. The two compose.
• Tenant data isolation — sets the per-tenant boundary; this feature deepens its resilience.
• Regulatory audit trail — receives every identity-binding disclosure, with purpose.
• Consented data use — drives the purpose-bound enrichment path: a research-with-consent purpose is honoured only when the relevant consent is on file.
• Compliance zones — declare zone- specific identifier formats used for MPI semantics.
• Hybrid edge–cloud operation — defines the offline-capable edge model the volatile-edge-PII rules build on.

Why this matters

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

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

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

What's in the box

• Tenant = customer. One customer, one tenant boundary; that's the boundary documented elsewhere as Tenant Data Isolation.

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

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

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

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

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

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

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

Standards we lean on

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

What customers and operators experience

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

Limits and trade-offs

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

Related features

• Tenant data isolation — the boundary inside which the org tree lives.
• Modular clinical features — modules bind to organizations within the tenant.
• Cross-module governance — zone chain, audit, identity apply uniformly across all organizations and modules.
• Declarative tenant configuration — the org tree lives in the customer's git config repo.
• Unified patient timeline — patient timelines cross organizational boundaries within a tenant.

Why this matters

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

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

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

What's in the box

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

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

• One FHIR project per tenant. Each tenant's data lives in a dedicated FHIR project; export and disposal operate at project granularity, with no cross-tenant entanglement to separate.

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

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

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

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

Standards we lean on

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

What customers and operators experience

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

Limits and trade-offs

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

Related features

• Tenant data isolation — the per-tenant FHIR project is the boundary; export and disposal operate at that level.
• Compliance zones — zones declare the national FHIR profile they use.
• Modular clinical features — modules consume the same shared clinical record.
• Regulatory audit trail — audit records are FHIR AuditEvent resources, exported in the same bundle as clinical data.
• Sources of truth — configuration (which is also FHIR-shaped) follows the same two-tier rule: authored in git, synced one-way into Medplum at bootstrap + on a scheduler. The portability promise covers both clinical data and configuration uniformly because both are FHIR all the way through.
• Tenant lifecycle — disposal at end of lifecycle uses standard FHIR export.
• Declarative tenant configuration — configuration itself is FHIR R4 too.

Why this matters

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

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

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

What's in the box

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

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

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

• One user, one tenant per session. A user choosing to work with a different tenant gets a fresh session. The platform never issues a token that authorises both tenants at once; cross-tenant impersonation is structurally impossible at the session layer.

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

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

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

Standards we lean on

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

What customers and operators experience

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

Limits and trade-offs

• No silent session extension. Sessions don't quietly renew on activity past the absolute lifetime; the user signs in again. Convenience would be invisible erosion of the audit-trail integrity the rest of the platform depends on.
• One session per user-tenant pair. Concurrent multi-tenant work means two browser sessions side-by-side, not one token authorising both. Annoying for users with several organisations; non-negotiable for the boundary.
• Idle vs. absolute timeout — both apply. Whichever fires first ends the session. The platform errs toward the shorter of the two.
• Device binding inherits the user's session lifecycle. (When it lands.) A device cannot outlive the session it's bound to. Hospitals that want device-only access for long-running displays will need a separate provisioning path (out of scope today).
• Session credentials are device-side. The platform cannot revoke a stolen device's local credential after network loss; the credential's expiry is the bound on damage. This is the reason for short maximum lifetimes.

Related features

• Tenant data isolation — sessions are tenant-bound; the URL ↔ session-claim binding is the per-request enforcement of what this feature establishes per session.
• Regulatory audit trail — every sign-in, sign-out, failure, and expiry is a FHIR AuditEvent in the tenant's trail.
• Tenant lifecycle — suspending a tenant rejects new sessions; deleting a tenant cryptoshreds the trail of past sessions along with the rest of the tenant's data.
• Identity pseudonymization — the user identity carried in a session is the same one modules audit, distinct from clinical identity.
• Edge fleet management — edge devices have their own per-edge identities and are separate from user-session device binding (which extends a user's session to a personal device).

Why this matters

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

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

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

What's in the box

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

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

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

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

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

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

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

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

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

Standards we lean on

• HL7 FHIR R4 — Device, Endpoint, and Organization are the resource shapes that hold every external system, its connection details, and the operator that owns it.

What customers and operators experience

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

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

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

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

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

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

Limits and trade-offs

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

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

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

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

Related features

• Modular clinical features — modules plug device types into the same framework they use to plug in navigation, controllers, and FHIR handlers.
• Hybrid edge–cloud operation — the on-site appliance hosts device connectors that need to be physically close to the equipment they talk to.
• Edge fleet management — edges themselves are managed as devices through this framework.
• Tenant data isolation — every device interaction runs inside its tenant boundary.
• Regulatory audit trail — every external-system interaction is on the same audit trail as internal clinical actions.
• Open standards data portability — Device, Endpoint, and Organization records use the standard FHIR shape, so a customer leaving the platform takes their integration catalogue with them.
• Declarative tenant configuration — device configuration lives in the tenant's config repository alongside the rest of the tenant's settings.