solutions · healthcare

Wytness for healthcare

Audit agent activity touching patient data, without sending the patient data to your audit vendor.

YOUR RUNTIMEWYTNESS · OPERATORYour AI agentsees patient identifierin clearWytness PII layermint pseudonym · sign event<PII:PATIENT_*>keys never leave yousignedOperator surfaceholds pseudonym onlywytness_envelope_sigagt_merkle_entry_hashSupervising clinicianapproves where policyrequires itHHS OCR, OAIC, EU AI Act export, auditor-readysigned export · pseudonyms only · tamper-evident

the question every regulator asks

Can you produce the evidence?

HIPAA §164.312(b) demands audit controls over every system touching electronic PHI; GDPR Article 9 makes patient data special-category; the EU AI Act puts healthcare triage in Annex III high-risk. The structural problem is that traditional audit logging ships the data being audited to the place it's audited from — and when the auditable event is a prompt carrying a patient's name, condition, and history, shipping it to a third-party SaaS is a HIPAA-disclosure event of its own. Wytness tokenises PHI in your runtime; the audit trail reaches us already sealed.

HIPAA §164.312(b)HIPAA §164.308(a)(1)(ii)(D)EU AI Act Annex III §5(a)GDPR Article 9AU Privacy Act (APPs 6 + 11)My Health Records Act §75ISO 27799:2016NIST SP 800-66 r2

a scenario

A privacy-counsel review, with and without

A Melbourne digital-health startup triages six hundred GP referrals a day with an AI agent — reading free-text letters, extracting Medicare numbers and conditions, routing to specialists. Two clinic groups it sells into have a HIPAA-covered US parent. Counsel asks: prove no Medicare identifier ever left Australia readable, show which referrals were auto-routed without a clinician, and produce the chain of custody on one referral a patient is disputing.

Without Wytness that's Datadog traces, OpenAI logs they can't export, and a Postgres table — each containing the very PHI the question is about. With it, it's one signed export: pseudonymised patient tokens, tool calls, model versions, clinician approval flags, and the policy fingerprint each routing was evaluated against. The Medicare numbers never appear because they never left the runtime. One meeting, closed.

event.json
Healthcare audit record

// Event identity:

id:"evt_01HX9F9R2N4K8J6Y3Z5T8M"
time:"2026-05-22T09:38:21.604Z"
agent_id:"agt_referral_triage_v4"
source:"agt://triage-assistant/v4"

// What the agent did:

tool_name:"patient.fetch"
decision:"allow"
source_format:"wytness_agt_py"Python wrapper
supervising_clinician_id:"clin_b9d3"

// Parameters (PHI tokenised before this row was sealed):

data.patient_id:"<PII:PATIENT_a3f9b1c4>"pseudonymised
data.encounter_id:"<PII:ENC_TOKEN_8e2d>"pseudonymised
data.scope:"referral_triage"
data.urgency:"routine"
data.model_endpoint:"azure.openai.au-central"

// Integrity proof (3-layer):

agt_merkle_prev_hash:"sha256:c47b91a8..."chain link
agt_merkle_entry_hash:"sha256:9a1f4c7b..."SHA-256
wytness_envelope_sig:"MEUCIQC4f9R2N..."Ed25519
wytness_envelope_key_id:"key_c7a4"

one referral fetch from the scenario — PHI arrives as tokens we cannot reverse

the deliverable

What you can prove

  • Which agent accessed which patient record, with what tool, and on whose authority, to the granularity §164.312(b) calls for.
  • That PHI never left your environment in plain form: pseudonymisation happens in your runtime, before any event reaches Wytness.
  • That clinical-decision-support agents stayed inside their scope and did not retrieve records belonging to patients outside the current encounter.
  • That a tool destination never received a PHI field unless an approved tool path required it.
  • That a breach investigation can reconstruct, for a specific patient, every agent interaction touching their record in the last seven years.

how the surfaces map

Three surfaces, one product.

/product/ledger

Ledger

Every action signed with your browser-generated key; PHI pseudonymised in your code before egress. Re-identification runs in your runtime on demand — Wytness holds tamper-evident metadata, never the patient data behind it.

/product/registry

Registry

Inventory of every clinical agent and PHI-touching tool call. Anomaly rules flag cross-encounter contamination, off-hours retrieval, destinations outside the BAA list, and behaviour shifts after a model upgrade that need clinical safety re-review.

/product/shield

Shield

High-risk actions — releasing PHI externally, suggesting medication changes, generating billing codes — gated behind the approval workflows your clinical governance team already runs.

for your auditor

Frameworks that matter here

SOC 2 Type II

Trust services criteria for the audit pipeline itself.

ISO 27001:2022

Pairs with ISO 27799 for the health-sector profile.

EU AI Act

Annex III §5(a) covers AI used in healthcare access and triage.

GDPR

Article 9 special-category data underpins all EU health-AI work.

HIPAA Security Rule

§164.312(b) audit controls — control matrix in progress.

NIST AI RMF 1.0

MEASURE and MANAGE support via the signed trail — in progress.

HITRUST CSF v11

Framework alignment available on request.

the boundary

What Wytness does not do

  • We are not an Electronic Health Record. We log what your agents did against your EHR (Epic, Cerner, AthenaHealth, or your own); we do not replace it.
  • We do not sign Business Associate Agreements at launch. BAA readiness is gated on the vendor-side controls a HIPAA-covered customer requires from sub-processors; we are honest about this with every healthcare prospect and will revisit as the customer-controlled-key model and pen test close the relevant gaps.
  • We do not provide clinical content review. A Wytness audit trail evidences what happened; whether it was clinically correct remains your clinical governance team's call.

Questions about your clinical AI audit obligations? Ask us.

We set no cookies. Sign-in and preferences use essential first-party browser storage only — no tracking, advertising, or third-party analytics. Privacy Policy