Ambient clinical scribes
Supervise the encounter. Preserve the evidence..
Ambient documentation can move protected health information through models at conversation speed. Buyers need to connect intended PHI controls to the configured workflow and to scoped evidence of what those controls reported.
The gap
Security review now asks for operational evidence.
Health-system reviewers may ask what happens to PHI at the model boundary in production and what evidence supports the answer for covered encounters. Architecture diagrams, assurance reports, logs, and event-level records answer different parts of that question.
Operator logs remain useful evidence. Signed records can add independently checkable integrity and key attribution for covered fields, while identity, routing, execution, source truth, coverage, and effectiveness still require surrounding evidence.
Glacis is designed to connect a configured PHI control at the draft-note boundary to a signed record of the covered event and reported outcome. That record does not establish that every encounter was routed through the control or that the wider system is HIPAA-compliant.
Regulatory surface
The questions reach further than HIPAA.
Ambient documentation sits where privacy law, contract scope, and procurement diligence overlap. A decision-linked record can complement the policies, contracts, architecture, testing, and logs used to answer those review questions.
HIPAA minimum necessary
HIPAA’s minimum-necessary standard is role- and transaction-specific and has exceptions, including many treatment uses. Where it applies, define the necessary data scope and pair the configured path’s reported egress outcome with architecture, access, and coverage evidence.
BAA scope
Business associate agreements define what a scribe vendor may do with PHI, including audio retention and model-training questions. Runtime receipts can preserve signed reports from configured controls alongside the contract; they do not independently establish source truth, complete coverage, or BAA compliance.
Recording consent
CIPA and other all-party-consent regimes treat the clinical conversation as a confidential communication, with statutory damages that can reach $5,000 per violation. Recent litigation over undisclosed recording has put consent documentation under direct scrutiny.
Buyer security questionnaires
Health-system questionnaires can include AI-specific questions on egress, logging, and control execution. A signed record may support answers about covered events, while architecture, testing, contracts, and scope evidence remain separate.
EU AI Act Article 12
Where a scribe is classified as high‑risk under the EU AI Act, Article 12 requires automatic logging capabilities appropriate to the system. Signed records may support selected events; required content, retention, access and sufficiency remain system-specific.
One record, different review questions
A privacy officer, security reviewer and EU reviewer may each check the integrity and provenance of the same covered fields. The record does not answer every role’s question or eliminate the need to assess the vendor, key, deployment and coverage.
From encounter to evidence
One configured workflow, with its evidence boundary stated.
Encounter audio
In this illustrative deployment, the visit is captured and transcribed inside the operator’s environment; the actual data flow must be verified for each implementation.
Draft note at the model boundary
The model produces a draft clinical note. This is the moment PHI could leave, and the moment security review asks about.
Configured PHI-boundary check
The selected path is configured to evaluate the draft against policy and report an outcome. Architecture and routing evidence establish where it executed; a data-minimizing receipt profile can omit note and audio content.
Receipt signed
The configured path’s reported check, outcome, and event time become covered fields in an operator-signed Ed25519 record. Portal-minted records may add a Glacis service-operated witness countersignature and inclusion proof; SDK or self-hosted records may be operator-signed only.
Selected records assembled for review
Supported records may carry disclosed chain information and can be selected for a manually assembled evidence pack. A reviewer can run supported checks at /verify; the pack does not prove complete capture.
The canonical receipt for that workflow, reduced to its key fields: subject.workflow is the scribe draft-note step, and controls.phi_egress_check recorded a pass. The verifier below loads the full receipt and runs every check.
Demonstration workflow data. The cryptography is real: every signature and hash verifies in your browser.
Run the checks belowVerify it yourself
The checks run in your browser.
The verifier below fetches the full canonical receipt and checks both Ed25519 signatures and the hash commitments with WebCrypto, locally, on this page.
Runtime coverage
What a scoped implementation defines.
For one named scribe workflow, agree the action boundary, control path, evidence profile, deployment plan, and acceptance criteria. Timing follows the verified scope and agreed plan.
One named workflow
Start with a single encounter workflow and declare the covered path, exclusions, and evidence boundaries.
A live arbiter at egress
For the named workflow, runtime controls execute at the model egress boundary on in-scope draft notes routed through the configured path.
Signed receipts
Each covered consequential decision can produce a hash-chained, operator-signed Ed25519 receipt. Portal-minted receipts may also carry a Glacis service witness countersignature and inclusion proof.
A verifiable evidence pack
The deliverable: a pack the health system’s reviewer checks themselves at /verify, without taking anyone’s word for it.
Bring the workflow your buyers ask about.
Scope the action boundary, supervision decision, and evidence a buyer needs to check. Deployment timing and deliverables follow the verified workflow and agreed implementation plan.
Talk to us