Platform features

Why this matters

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

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

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

What's in the box

• One customer, one boundary. Each tenant's clinical data lives in its own dedicated FHIR project. There is no shared patient table, no shared search index, no cross-tenant join path.

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

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

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

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

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

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

Standards we lean on

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

What customers and operators experience

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

Limits and trade-offs

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

Related features

• Compliance zones group tenants by jurisdiction so the same platform can honour different regulatory regimes alongside isolation.
• Identity pseudonymization deepens the boundary's resilience: even an attacker who breaches the per-tenant database isolation cannot identify whose data they have without breaching the separately-protected Person resource.
• Patient data anonymisation is a distinct concern — operates on data within a tenant boundary, preventing personal data from reaching analytics or AI components.
• Regulatory audit trail records every attempt — successful or denied — that touches the boundary.
• Tenant lifecycle describes how customers are created, suspended, and removed without ever risking an isolation breach during transitions.
• Consented data use governs the only sanctioned way the vendor sees inside a tenant: named, anonymising extractors the customer has explicitly enabled.

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.

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.
• 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 SaaS platform serves customers that arrive, change, and sometimes leave. Each transition has both an operational dimension (provisioning, suspension for billing, decommissioning) and a regulatory dimension — GDPR-style frameworks give customers and patients the right to have their data removed, but also expect data to be preserved long enough for legitimate audit and dispute resolution.

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

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

What's in the box

• Lifecycle transitions are durable workflows. Creation, suspension, reactivation, and scheduled deletion are each a long-running process the platform manages — not a sequence of manual API calls. They survive platform restarts, are individually auditable, and complete or report failure unambiguously.

• Grace period as a managed timer. When deletion is initiated, a 30-day clock starts inside the platform's workflow engine. It survives restarts. It can be cancelled by a single reactivation signal. When it fires, the actual deletion runs as another workflow.

• Declarative provisioning. Customers and their configuration (departments, default users, module selection, zone) are described in the configuration source the platform reads. An operator describes a tenant; the platform enacts it. There is no hand-built tenant.

• Every transition is an audit event. Created, suspended, reactivated, disposal-started, disposal-cancelled, deleted — each emits a typed event into the audit trail, dual-logged to the platform's own trail and the affected tenant's trail.

• One tenant, one lifetime. A clinical record belongs to exactly one tenant for its lifetime. Migrating data between tenants is not self-service; merging or moving requires explicit operator and regulatory engagement.

• External notification, not enforcement. When a tenant is deleted, partners that hold derived data (insurance, registries, downstream EHRs) are notified to delete from their side. The platform produces the notification; it cannot enforce the partner's compliance.

Standards we lean on

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

What customers and operators experience

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

Limits and trade-offs

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

Related features

• Tenant data isolation — every lifecycle action operates on the tenant's own boundary.
• Regulatory audit trail — every lifecycle event is itself an audit record, dual-logged.
• Hybrid edge–cloud operation — edges follow their tenant's lifecycle: a suspended tenant's edges go quiet; a deleted tenant's edges are wiped.
• Declarative tenant configuration — lifecycle workflows read intent from the configuration repo; every transition traces back to a merged change.
• Open standards data portability — disposal at end of lifecycle uses standard FHIR export.

Why this matters

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

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

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

What's in the box

• Audio in, anonymised text out. The service receives audio from a recording client (visit UI, rounds tablet, conference endpoint) along with whatever speaker metadata that client knows. It transcribes the audio, runs the raw transcript through anonymisation, and exposes only the result — automatically and in near-real time.

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

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

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

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

• Open-source audio foundation. Audio capture, mixing, and routing — for in-room recordings and remote consultations alike — run on LiveKit, an open-source real-time communication platform already used as the foundation of certified secured-conversation products in regulated industries. The platform's contribution is the clinical compliance layer on top — anonymisation, audit, retention, zone-aware routing.

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

Standards we lean on

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

What customers and operators experience

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

Limits and trade-offs

• No diarisation by the service itself. When the recording context cannot provide speaker metadata (e.g., a single mixed track of an unattended meeting), downstream features must layer their own diarisation or accept speaker-unknown content.
• Raw retention is short by design. Raw audio is biometric; raw text is identifying. Both expire on policy. Long-term raw access is an exception that requires explicit, time-bound authorisation.
• Transcription quality limits everything downstream. Anonymisation works on the text the transcriber produces; speech the transcriber misses cannot be redacted. Quality varies by language and acoustic conditions and is the underlying provider's contribution.
• Multi-language support depends on the transcription provider. Expanding language coverage is provider-side work.
• The service does not record consent itself. Consent capture happens in the calling clinical workflow, before the recording starts.

Related features

• Patient data anonymisation — the policy the service enforces on every transcript before it leaves the boundary.
• Regulatory audit trail — receives the events the service emits.
• Hybrid edge–cloud operation — recordings most often happen at the edge; raw audio rarely leaves the site.
• Right-sized AI pipeline is the consumer of the anonymised transcripts.
• Modular clinical features — any clinical module that needs to capture clinical voice consumes this service.

Why this matters

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

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

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

What's in the box

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

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

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

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

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

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

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

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

Standards we lean on

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

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

What customers and operators experience

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

Limits and trade-offs

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

Related features

• Tenant data isolation — audit records inherit the same boundary as the records they describe.
• Tenant lifecycle — every lifecycle transition is itself audited, dual-logged where appropriate.
• Patient data anonymisation — raw access is the audit boundary that anonymisation establishes.
• Secure recording service — every recording, transcription, and replay is a tracked event.
• Hybrid edge–cloud operation — edges produce audit locally and reconcile to cloud.
• Identity pseudonymization — every identity-binding disclosure lands here with its purpose.

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).
• Secure recording service — 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, retired — every edge is in one of a small set of states the console displays plainly. Transitions are operator actions; every transition is audited.

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

• Heartbeat visibility. Edges report state to cloud on a heartbeat; long-disconnected edges are flagged rather than silently presumed healthy.

• 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 state for long-disconnected edges. An edge that has not contacted cloud for days shows its last known state. Operators should treat long-stale entries as suspect, 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 AI-driven pass catches names, free-text addresses, and contextual identifiers a regex cannot reasonably match.

• 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.
• Secure recording service — the upstream pipeline whose only output to the rest of the platform is anonymised text.
• Right-sized AI pipeline runs the AI second pass and consumes anonymised text for every other AI job.
• 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

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

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

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

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

What's in the box

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

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

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

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

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

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

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

Standards we lean on

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

What customers and operators experience

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

Limits and trade-offs

• Provider quality varies per task. When changing a provider for a given kind, accuracy must be re-validated for that kind — quality guarantees do not transfer.
• Switching providers mid-tenant requires planning: cached prompt prefixes do not move with the data, so the first hours after a switch run more slowly until the new provider warms up.
• The keyword catalogue needs upkeep. New procedures, treatments, and languages require keyword additions; the platform errs on the side of running the AI when in doubt, but un-tended catalogues drift toward over-running.
• AI quality is bounded by the underlying provider. Routing optimises which model handles each job; it does not improve any individual model's clinical accuracy.

Related features

• Compliance zones — decide which providers any given tenant's AI work is allowed to use.
• Patient data anonymisation — runs before the heavier AI calls, so personal data never reaches them.
• Secure recording service — the upstream pipeline that feeds the AI work.
• Modular clinical features — let new specialty modules introduce their own AI tasks without changing the platform routing.

Why this matters

Healthcare data is the most sensitive thing a hospital holds, and a SaaS vendor that says "trust us" fails the first procurement review. At the same time, software that learns from real clinical use improves faster than software that doesn't. The honest position is that some visibility, under named purposes, with meaningful customer control, is in the customer's interest — provided the boundary is real, not rhetorical.

This feature is that boundary. It lets a hospital tell its regulator, truthfully: "the vendor has no path into our clinical data except a small, named, auditable set of pipelines we have explicitly authorised, and we can stop them at any time."

What's in the box

The feature is built from a few working parts. Together they turn "we promise to behave" into "the platform cannot misbehave."

• Programme. A named bundle of related uses with one purpose statement and one decision. Today there is one: anonymised data use for product improvement. Customers say yes-or-no to the programme, not to its parts.

• Extractor. A named pipeline that runs inside the customer's boundary, reads clinical data, and emits only de-identified output. Each one is documented — what it consumes, what it produces, in what shape. No black boxes.

• Catalogue. The versioned list of extractors that make up the programme right now. A material change produces a new version, and the customer's "yes" is attached to the version they reviewed — not auto-extended to the next.

• Output type. Each extractor declares what it emits — anonymised text, aggregated statistics, or pseudonymised identifiers — and the runtime refuses to let it emit anything else. "Anonymous" is not the vendor's word; the standards define it, the platform enforces it.

• Consent record. Recorded as a standard FHIR Consent resource in the customer's own clinical project. Customers query, export, and audit their consent the same way they audit every other patient consent. No proprietary table sitting beside the record.

• Withdrawal. One switch, complete cascade. Future runs blocked, in-flight runs cancelled, the customer gets a list of what was emitted under the prior agreement. As easy to withdraw as to give.

• Separated identity. Extractors run as their own thing — not as a vendor employee with a database client. A support engineer cannot impersonate an extractor; an extractor cannot run an ad-hoc query. Same idea as the operator lockout in Tenant Data Isolation: enforced by who holds which key, not by who follows which policy.

• Run audit. Every extractor invocation produces an audit event in the customer's regulatory audit trail: which extractor, which catalogue version, when, how many records, how much was emitted. The customer's own record of what the vendor was authorised to do and what it did.

Standards we lean on

We didn't invent any of this. The shape comes from instruments hospitals already cite in their own data-protection assessments:

• GDPR (Articles 6, 7, 13, 14, 17) — lawful basis, specific consent, transparency about purposes and changes, right to withdraw.
• HIPAA (§164.508, §164.514) — authorisation for non-TPO uses; Safe Harbor / Expert Determination as the de-identification bar.
• ISO/IEC 27018 — cloud processor obligations: no secondary use without consent, structural separation of operator identities.
• HL7 FHIR R4 Consent resource — the standard shape for consent state.

Which requirement satisfies which article lives with the requirements themselves.

What customers and operators experience

• A compliance officer sees the vendor has no path into the tenant's data by default. The inability is structural.
• A DPO reviews one programme description and decides for the institution.
• A customer who consents contributes anonymised signals under a named, versioned catalogue.
• A customer who declines receives every clinical feature; they don't contribute to the data that drives refinements.
• A customer reviewing the catalogue sees every extractor in the current version and which version their consent attaches to.
• A customer notified of a change has a window to re-evaluate before a new version takes effect.
• A customer withdrawing consent stops extraction immediately and gets a complete record of what was emitted previously.
• A platform operator investigating an issue has no informal route — only the named extractors, gated by consent.

Limits and trade-offs

• Programme-level consent, not per-extractor toggles. Accept the catalogue as-shaped, or decline.
• Non-consenting customers see slower improvements. Honest, not punitive — but real.
• Catalogue changes are notified, not negotiated. Customers can withdraw ahead of a change; they cannot veto an addition while staying in the programme.
• De-identification is a layer, not a guarantee. Combining anonymised outputs over time can still reveal patterns specific to one site.
• Consent is a relationship, not a signature. Customers can change it any time; the platform must remain useful in either state.

Related features

• Tenant data isolation — the boundary inside which extractors run.
• Patient data anonymisation — the discipline that governs what extractors emit.
• Regulatory audit trail — where extractor runs and consent decisions live.
• Compliance zones — zone-specific de-identification rules apply; some zones may restrict extractors entirely.

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

Healthcare is not one workflow. The day-to-day work of a laboratory technician, a primary-care physician, a radiologist, a triage nurse, an oncology coordinator, and a hospital pharmacist look almost nothing alike — and a platform that tries to be one application for all of them either gets too generic to be useful or grows into an unmaintainable monolith.

The modular approach lets the platform deliver a deep, specialty-aware experience for each clinical domain while still being one product. A hospital running a laboratory module today can add a visit-assistant module tomorrow without re-buying the core platform. A specialty group that wants to build something specific to their practice can develop a module of their own without forking anything.

The strategic value is compounding: every new module ships with all the platform foundation already in place — multitenancy, anonymisation, audit, AI routing, deployment plumbing. Modules carry the specialty knowledge; the platform carries the regulatory and operational foundation. Both improve over time, in parallel.

What's in the box

• Modules are libraries, not separate applications. Each clinical module is packaged as a self-contained unit that integrates into the same runtime. A new module is added by including it; an unwanted module is removed the same way.

• Modules contribute their own surface. Each declares its navigation, its pages, and the clinical data resources it cares about. The platform composes these into one consistent UI.

• Modules share platform services. Authentication, audit, multitenancy, AI routing, recording, and storage are platform-provided. No module re-implements them.

• Modules bind to organizations, not to the tenant as a whole. Each organization in the tenant's tree (departments, sites, units) declares which modules it uses. Module enablement is per-(organization, module).

• One module, many bindings. The Lab module exists once in the codebase; it can serve the Laboratory department and Cardiology and Emergency. One organization can run several modules.

• Convention conformance is a prerequisite. A module that bypasses platform auth, audit, or zone lookup is rejected at review. The platform reviews module submissions for compliance.

Standards we lean on

• HL7 FHIR R4 — the shared data substrate every module reads and writes against.
• HL7 SMART on FHIR — the integration pattern for clinical apps composed under one shell.
• GDPR Article 25 — privacy by default. Every module inherits the platform's posture; modules cannot opt out.
• ISO/IEC 27001 — consolidated security management across every module.

What customers and operators experience

• A clinician uses several modules side by side under one login, one navigation, one consistent layout. The lab worklist and the visit summaries feel like parts of the same product because they are.
• A specialty group developing a module for their workflow inherits authentication, audit, multitenancy, AI routing, and clinical-data storage from the platform. They focus on the specialty logic.
• A hospital can enable only the modules they have licensed and staffed — and only in the departments that use them. A small clinic running just laboratory features doesn't pay or train for visit-assistant features they don't use.
• A clinician working in two departments sees the modules each department has enabled. Switching department context changes the available modules, the menu, and the actionable items — without switching tenant or re-logging.
• A central administrator manages the org tree (departments, sites, units) and decides per-organization which modules apply. Adding a new module to a department is a configuration change, not an installation.
• A platform operator rolling out a new module reaches all customers through the same delivery pipeline as the core. There is no separate "module deployment" project.

Limits and trade-offs

• Module developers must follow platform conventions. A module that bypasses platform auth or audit is a regulatory liability. Convention conformance is a prerequisite, not a suggestion.
• Modules share a runtime. A misbehaving module can affect the performance of others on the same instance. Operations procedures treat modules as siblings, not isolated services.
• Cross-module workflows are explicit. A module that wants to invoke another module's behaviour does so through documented interfaces, not by reaching into private state.
• Edge currently bundles all modules. On-premise edge devices carry the modules the platform ships; per-edge selective module installation is a future iteration.

Related features

• Tenant data isolation — each module operates within the tenant boundary, never across.
• Right-sized AI pipeline — modules declare their AI tasks and the platform routes them.
• Regulatory audit trail — every module emits the same shape of audit events.
• Hybrid edge–cloud operation — modules that need offline operation describe their offline data needs to the edge runtime.
• Unified patient timeline — the shared shared clinical record every module reads from and writes to.
• Cross-module clinical workflow — workflows that span modules.
• Cross-module governance — every module runs under the same zone chain, audit, identity, and RBAC.
• Organizational structure — modules bind to organizations within the tenant.

Why this matters

Each new module is a regulatory exposure if it brings its own governance. A platform where Lab applies one zone's rules and Visits applies another's is unauditable; a platform where a clinician's role permits something in Lab but not Visits creates security gaps the clinician's manager cannot reason about. Inconsistent governance across modules is how compliance reviews fail.

A traditional best-of-breed setup — separate lab system, separate EHR — inherits this problem by definition: each system has its own RBAC, its own audit format, its own data residency posture. The hospital's compliance team has to verify each one independently and hope the gaps line up.

Cross-module governance reverses this. The platform's zone chain, audit trail, identity, and RBAC apply to every module by construction. The compliance review surface is one set of rules, not one per module.

The strategic value: enabling a new module does not create a new compliance review. The customer already trusts the governance posture; the new module inherits it. Procurement and security review focus on the module's clinical fit, not on relitigating the platform's governance.

What's in the box

• One zone chain, all modules. Modules read the tenant's zone from the platform's shared zone service; they do not maintain their own zone configuration. A change to the tenant's zone binding propagates without module changes.

• One audit trail. Every module emits audit events through the same shared channel to the same per-tenant FHIR audit store. There is no module-private audit log to reconcile.

• One identity model. The same JWT token authenticates a clinician across every module. The tenant context is set once per request and applies regardless of which module handles it.

• Tenant-level RBAC. Roles are defined in the tenant's configuration (in the git config repo); modules check permissions through the platform's auth service rather than rolling their own RBAC.

• Module enablement = tenant configuration. Enabling a module is a flag in the tenant's config; the module immediately inherits the tenant's zone, audit, and identity posture without any per-module setup step.

• Module-specific permissions layer on top. A "lab-admin" permission inside Lab is a refinement of a clinician's tenant role, not a separate RBAC. Modules add detail; they do not fork governance.

Standards we lean on

• ISO/IEC 27001 — consolidated security management system, not one per subsystem.
• ISO/IEC 27018 — cloud processor obligations applied uniformly to every module's data handling.
• HL7 FHIR R4 — the shared substrate every module reads and writes against.

What customers and operators experience

• A compliance officer reviewing the platform sees one zone-chain configuration, one audit retention policy, one identity model — all of which apply to every module. They do not review one set per module.
• An HR change to a clinician's role propagates to every module on next login. Granting "department head" in one module also grants the equivalent in others if those modules respect the role.
• An audit officer investigating a patient's record sees one trail covering every module's action on that patient — lab orders, lab results, visits, notes, prescriptions — in one chronological view.
• A new module enabled inherits the tenant's full governance posture immediately. No "configure zone for the new module" step. The first action in the new module is governed correctly.
• A module disabled stops accepting new actions but does not fragment the patient's audit history — every prior action made through that module remains in the unified trail.
• A zone-chain change applies to every module simultaneously. The customer does not chase down per-module configuration.

Limits and trade-offs

• Module-specific permissions still exist, layered on top. Customers who expect fully independent per-module RBAC are not served; the platform deliberately rejects that model.
• Disabling a module does not remove its historical audit. The audit trail persists across module enablement changes; a clinician who acted through a now-disabled module still appears in audit. This is GDPR-correct, not a bug.
• Zone-chain changes affect all modules simultaneously. Usually wanted, occasionally surprising — a customer adjusting zone behaviour for one purpose may find every module's behaviour adjusts in step.
• Module authors must use platform governance APIs. A module that rolls its own audit, identity check, or zone lookup violates the principle. The platform reviews module submissions for compliance.

Related features

• Compliance zones — the zone chain every module reads from.
• Regulatory audit trail — the one trail every module writes to.
• Tenant data isolation — the boundary inside which all module governance applies.
• Modular clinical features — describes the module mechanism; cross-module governance is what makes module enablement safe.
• Declarative tenant configuration — tenant-level governance lives in the git config repo.
• Organizational structure — modules bind to organizations within the tenant; governance applies uniformly across the org tree.

Why this matters

Real clinical work doesn't respect module boundaries. A clinician examining a patient orders a lab without leaving the visit; the result needs to come back into that visit's context; a follow-up needs to be schedulable from either side. A platform that forces context-switches between modules loses time, breaks the clinical thread, and creates handoff errors at every boundary.

In a traditional best-of-breed setup, the lab system and the EHR are separate products from separate vendors with separate data shapes, glued together by an integration team. Cross-module workflow there is custom integration work, paid for in delays and reconciliation bugs.

In a modular platform, the same boundary is internal. The platform makes cross-module flow a first-class feature — modules publish and consume each other's events, share the same shared clinical record, and present a unified UI shell. The clinician completes a multi-module task without noticing it was multi-module.

The strategic value: clinicians stay in flow, fewer handoff errors happen, and adding a new module enriches existing workflows automatically rather than creating a new integration project.

What's in the box

• Platform-mediated events. Lab consumes the platform's ServiceRequestCreated event when Visits writes one. Visits consumes ObservationFinalized when Lab returns a result. Modules don't import each other's code.

• FHIR resources as the contract. Cross-module references use FHIR references on shared resources (ServiceRequest, Specimen, Observation, Encounter, Communication). Modules read and write the same resources.

• One UI shell, multiple module views. The platform's web shell hosts every module's UI; navigation, patient context, and notifications are shared. The clinician's session is unified; only the active panel changes.

• Notifications find the clinician, not the module. A "your lab result is back" notification is delivered to the clinician's inbox — surfaced wherever they are working — rather than waiting for them to open a specific module.

• Audit captures the cross-module thread. A single audit thread connects the visit, the lab order, the result, and any follow-up. Investigators see the chain, not fragments.

• Versioned event contracts. When a module changes how it emits an event, the platform versions the contract and gates breaking changes. Module authors coordinate without breaking consumers silently.

Standards we lean on

• HL7 FHIR R4 — shared resources as the cross-module contract.
• HL7 FHIR Subscription — the standard for delivering FHIR events to interested consumers.
• HL7 SMART on FHIR — the integration pattern for hosting multiple clinical apps under one shell.

What customers and operators experience

• A clinician in Visit Assistant orders a lab — one click during the encounter, sample collection task created on the lab's worklist. The clinician never leaves the visit.
• The lab returns the result — it arrives in the patient's unified timeline and surfaces in the visit's context. If the visit is still open, the result shows inline; if it has closed, a follow-up notification reaches the ordering clinician wherever they are.
• An out-of-range lab result triggers escalation — the notification finds the ordering clinician regardless of which module they are working in at the moment.
• A visit note auto-references lab results that informed the clinical decision; the link is structural (FHIR reference), not copy-pasted text.
• A follow-up scheduled from a lab result opens the next visit with the relevant context already in place.
• An MDT meeting reviewing a complex case pulls the patient's unified timeline into the meeting view, without each clinician having to assemble their own view.
• A patient asking "what happened?" receives a coherent narrative across modules, not a fragmented per-module log.

Limits and trade-offs

• Cross-module workflows must be designed as cross-module from the start. Bolting a cross-module step onto a module-internal workflow rarely produces the same UX. The platform supports the pattern; the discipline of using it is on module designers.
• Event contracts evolve. When Lab changes how it emits a result, every consuming module needs to be aware. The platform versions contracts and gates breaking changes; module authors still need to coordinate.
• Some workflows stay module-internal. Lab QC, instrument calibration, MDT meeting moderator controls — none of these benefit from being cross-module.
• Cross-module workflow assumes both modules are enabled. A customer who enables Visits but not Lab cannot order labs from visits — but the visit module degrades gracefully.

Related features

• Modular clinical features — describes how modules plug into the platform.
• Unified patient timeline — the chronological view cross-module workflows feed.
• Open standards data portability — FHIR is the contract modules speak across.
• Cross-module governance — the same zone, audit, and identity apply throughout the workflow.
• Regulatory audit trail — records the cross-module thread end-to-end.

Why this matters

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

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

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

What's in the box

• One FHIR project per tenant. Lab writes ServiceRequest, Specimen, Observation. Visits writes Encounter, Communication, DocumentReference. Both reference the same Patient. There is no module-private database.

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

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

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

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

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

Standards we lean on

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

What customers and operators experience

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

Limits and trade-offs

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

Related features

• Tenant data isolation — the unified timeline lives inside one tenant's boundary.
• Open standards data portability — FHIR R4 is the open standard that makes the timeline portable.
• Modular clinical features — every module plugs into the same shared clinical record.
• Cross-module clinical workflow — describes how flows that produce timeline entries cross module boundaries cleanly.
• Regulatory audit trail — audit events live in the same per-tenant timeline as clinical records.

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

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

• 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 adding an accounting connector uses the same Devices admin, picks "Accounting system", fills in the API endpoint and 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.

• Tenant-shared devices need extra care. Devices used by many tenants at once (a national insurer endpoint, a regulatory registry) carry strong rules about which tenant's identity travels with each call. Module authors must mark a device type as tenant-private or tenant-shared correctly; misclassifying has real consequences for cross-tenant isolation.

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