Tavrik for healthcare

Tavrik AI-ESB’s healthcare vertical landed in the M5.A omnibus. This directory carries buyer-facing documentation for hospital biomedical engineering teams, clinical AI program leads, and compliance officers evaluating Tavrik as the governance layer for clinician-facing AI tools.

Who Tavrik is for in healthcare

Hospital biomedical engineering teams procuring AI tools for clinicians (radiology AI, ED note drafting, discharge summarisation, clinical research support). Tavrik is the gateway clinicians’ AI traffic flows through; it catches PHI before model invocation and emits audit events to the hospital’s existing audit-aggregation infrastructure.
Clinical AI program leads scoping rollouts (e.g., a radiology department pilot, a hospital-wide ED rollout). Tavrik provides per-tenant policy and detection coverage so different clinical groups can run different AI tools under different controls.
Compliance / privacy officers establishing the BAA scope and audit-trail integration. Tavrik signs as a Business Associate; audit events flow to your existing integration engine (Mirth Connect, Cloverleaf, Rhapsody, Iguana) or FHIR audit endpoint.

What Tavrik IS for healthcare

An AI traffic governance gateway. Tavrik catches PHI before it leaves the browser or API client en route to AI tools. PHI detection covers HL7 v2.x message fragments, FHIR R4 resource snippets, DICOM identifiers (Study/Series/SOP Instance UIDs, Accession Number, Patient ID), and the standard US/AU healthcare identifier classes (NPI, DEA, Medicare PIN, IHI, HPI-I, HPI-O, Medicare AU) when clinicians paste them into AI tools.
A browser extension that intercepts clinician submissions to AI tools. ChatGPT, Claude.ai, Gemini, Copilot, Perplexity, Cursor, GitHub Copilot Chat, Mistral Le Chat, Poe, You.com per M4-extension. Submission hits the in-page handler before egress; Tavrik applies the tenant policy (allow / redact / block) and writes audit.
An API gateway that intercepts programmatic AI API calls. OpenAI, Anthropic, Google, Azure OpenAI, Bedrock, Ollama, vLLM, custom adapters. Tavrik applies the same policy + audit + redaction discipline to programmatic traffic that the browser extension applies to clinician submissions.
A compliance-grade audit producer. Audit events flow into the hospital’s existing audit aggregation pipeline via HL7 v2.x ARV (Mirth/Cloverleaf/Rhapsody/Iguana over MLLPS, M5.A.8 — not yet exercised against a real engine, see pilot-blockers.md B12), FHIR R4 AuditEvent (HTTPS, M5.A.9 — verified live), or SIEM-direct emission (Splunk HEC verified live; Elastic, Datadog and Microsoft Sentinel share the same dispatcher and are configured through the admin API). Operator picks per-tenant via ADR-0036’s three-state policy. Also: a hash-chained, append-only audit log in Tavrik’s own ledger (ADR-0026; per-event SHA-256 with prev_hash links, verifiable via POST /v1/audit/verify) — a backstop when the hospital integration engine experiences an outage. A daily Merkle-root seal is not yet available (the M3.7.B scheduler has not shipped).
A vendor-neutral integration point. Tavrik works with whatever EHR, integration engine, MDM (Intune / Jamf / Workspace ONE), identity provider, and SIEM the hospital already runs. No EHR-vendor lock-in; no integration-engine-vendor lock-in.

What Tavrik is NOT for healthcare

Per ADR-0043 Decision 1 + ADR-0040 Decision 6, structurally enforced:

NOT a clinical messaging system. Tavrik does NOT process HL7 v2.x messages flowing through the integration engine between EHR and lab / imaging / pharmacy systems. Existing message flows are unaffected. Tavrik’s HL7 v2.x ARV connector emits Tavrik’s own audit-event messages into the same integration engine that carries clinical traffic; the clinical traffic itself is not mediated by Tavrik.
NOT an EHR replacement or integration platform. Tavrik does NOT read or write clinical data in the EHR. Hospitals’ existing EHR workflows (order entry, results review, documentation, problem-list maintenance) continue unchanged. PHI detection operates on AI-traffic content (clinician-pasted text + AI-API payloads), not on EHR-resident data.
NOT a FHIR proxy or healthcare data interchange layer. Tavrik does NOT mediate FHIR R4 API calls between hospital systems. The FHIR R4 audit forwarder emits Tavrik’s own audit events in FHIR AuditEvent format (the AuditEvent resource); Tavrik does not proxy clinical FHIR resources (Patient, Observation, MedicationRequest, etc.) between hospital systems.
NOT a clinical decision support tool. Tavrik does NOT analyze clinical content for medical purposes. PHI category detection is a data governance enforcement mechanism, not a clinical inference engine. Tavrik does not advise on care; does not place orders, document findings, update problem lists, or modify any EHR-resident data; does not interact with PACS at the imaging layer (DICOM recognizers detect identifiers in clinician-pasted text only).
NOT a general-purpose DLP. Tavrik focuses specifically on AI traffic. Existing DLP solutions (Microsoft Purview, Forcepoint, Netskope, Symantec) continue to handle other data egress channels (email, file transfer, removable media, browser uploads to non-AI destinations). Tavrik integrates alongside DLP, not as a replacement; the operator’s existing DLP policy and infrastructure remain in place.

Why this matters

Explicit boundary positioning serves three audiences:

Compliance buyers evaluating Tavrik’s scope under HIPAA / GDPR / APRA frameworks. Knowing Tavrik’s processor scope is bounded to categorical-only AI-traffic metadata (per ADR-0040 Decision 6 + ADR-0013) reduces their DPA / BAA scope analysis. The BAA covers governance + audit + EHR-adjacent audit-forwarding connectors only — never clinical-data processing.
Clinical informatics teams worried Tavrik will interfere with existing clinical workflows. The boundary statement confirms Tavrik sits adjacent to (not in) clinical data flows. The HL7 v2.x ARV connector shares the integration engine with clinical traffic but does not mediate or consume it; clinical message routing is untouched.
IT operations teams mapping Tavrik into existing infrastructure. The boundary clarifies which existing systems Tavrik integrates with (audit aggregation, MDM, identity, optional SIEM) and which it does not touch (EHR clinical data, integration engine clinical message flow, FHIR clinical APIs, PACS, DLP egress channels other than AI traffic).

HIPAA posture

Tavrik signs as a Business Associate of the covered entity. The BAA covers governance + audit + EHR-adjacent audit-forwarding connectors. Tavrik never crosses into covered-entity territory.

See compliance/healthcare/README.md for the full compliance posture matrix across HIPAA, APRA CPS 234, ISO 27001, GDPR, and the My Health Records Act 2012 (Australia).

Deployment topologies

Two topologies are first-class per ADR-0043 Decision 6:

Topology A — on-network (the pilot shape). Tavrik runs on your hospital network as systemd units on a single Linux VM per ../operations/on-prem-vm-runbook.md — the shape that has been executed end to end. A Kubernetes Helm chart (deploy/helm/tavrik) exists and is install-smoked in CI but is not the pilot shape; there is no single-binary appliance build (ADR-0008 defers it). Direct MLLPS / HTTPS access to your integration engine + FHIR audit aggregator.
Topology B — SaaS via companion — not yet available. Tavrik gateway runs in Tavrik-managed cloud; an operator-deployed hospital-side companion connector re-emits Tavrik audit events into your local integration engine over the same MLLPS / HTTPS surface. Filed for the M6 on-prem packaging milestone; no companion binary exists today.

See architecture.md for detailed wire-flow diagrams.

Browser support (pilot)

Chromium-based browsers — Google Chrome Enterprise and Microsoft Edge — are the pilot offering for the Tavrik browser extension, deployed by MDM force-install (compliance/extension-mdm-deployment.md). Firefox ESR is scheduled, not offered: the build exists but has not been exercised on a managed fleet; lead time from a named partner requirement is about two weeks (a build cycle plus a managed-fleet test cycle). Safari is out of scope.

Onboarding sequence

A design-partner onboarding typically runs four weeks; see onboarding.md for the detailed phased plan. High-level:

Week	Phase
0	Pre-deployment: BAA execution, network access review, integration engine config exchange
1	Deploy: gateway + admin API + per-tenant config (start with one clinical group)
2	Pilot: clinicians exercise AI tools; operator reviews audit events flowing to integration engine
3	Tune: per-tenant recognizer + connector policies adjusted; expand to additional clinical groups
4+	Steady state: operator runbooks engaged; cert rotation, capacity review, etc.

Operational runbook

Day-to-day operations covered by ../runbooks/healthcare-connector-operations.md:

Client cert rotation for MLLPS / FHIR-HTTPS connectors (14-day expiry warning audit event on both mTLS paths)
CA bundle rotation (operator-supplied trust store)
Integration engine outage handling (retry parking lot drains automatically on restoration; DLQ rows are visible by SQL — a DLQ replay surface is not yet available, B5)
FHIR endpoint URL drift / bearer-token rotation (static bearer only; SMART-on-FHIR refresh is not implemented)
Audit-log hash-chain verification (operator-initiated; see ../runbooks/audit-log-tamper-investigation.md)

Sub-document index

architecture.md — deployment topologies, data flow, audit forwarding wire shape
onboarding.md — design-partner onboarding plan
../runbooks/healthcare-connector-operations.md — connector operational runbook
../../compliance/healthcare/README.md — compliance posture matrix
../../compliance/healthcare/control-mapping.md — cross-framework control mapping
../../compliance/healthcare/fhir-audit-codes.md — FHIR R4 AuditEvent CodeSystem reference
demo-script.md — the design-partner demo, start to finish, with expected vs observed output (2026-09-02).
pilot-blockers.md — weeks 0–4 audited against the shipped product; the ranked pilot-blocker list and post-pilot register.

References

ADR-0042 — Vertical-pack framework
ADR-0043 — EHR-adjacent connector architecture
ADR-0040 — Browser extension architecture (never-transmit-content posture)
ADR-0013 — Audit event types closed enum
ADR-0035 — BYOK key resolution (envelope-encrypted credentials)
ADR-0036 — Connector framework (Writer/Reader, outbox/DLQ, per-tenant configs)
ADR-0026 — Audit-read endpoints and the per-event hash chain