MedScan AI · Auris+ · Decision Ledger
The deployer’s ledger.
Why a private, cross-vendor record of how AI-medical-device decisions actually played out is the missing piece of post-market AI accountability.
What it is
A Decision Ledger is the deployer’s own private log of how AI medical devices behaved on real cases — what the algorithm called, what the clinician concluded, and a one-line reason if those diverged. It is owned by the hospital or the clinician, not the manufacturer, and it spans every AI tool in use, not just one vendor.
The aim is undramatic: to make drift, silent version updates, and slow patterns visible. No single case can reveal whether a radiology AI quietly retrained last quarter, or whether a dermatology classifier behaves differently for one skin tone than another. A ledger of decisions can.
Why now — the regulation
The EU AI Act lands obligations on three articles that touch the deployer directly. Article 14 (human oversight) gives clinicians the explicit right to disregard, override, or reverse a high-risk AI system’s output. Article 12 (record-keeping) requires that high-risk systems automatically record events over their lifetime — period of use, persons involved, reference data. Article 26 (deployer obligations) requires the deployer to keep those logs for at least six months.
The original 2 August 2026 high-risk start date has slipped under the Digital Omnibus Council position (March 2026 — not yet enacted): standalone Annex III systems to 2 December 2027, embedded medical-device AI to 2 August 2028. The legal duty on deployers therefore lands in 2028, not 2026. We don’t recommend waiting — the override habit, and the data trail it leaves, take years of practice to make routine. Read our full EU AI Act guide →
The shape on the wire — HL7 FHIR
The HL7 AI Transparency on FHIR Implementation Guide (v1.0.0 ballot December 2025) defines the canonical shape: paired Observation resources — one for the AI’s finding, one for the clinician’s — linked via derivedFrom, with paired Provenance records carrying the override semantics. AI-asserted Observations are tagged with the AIAST security tag so downstream systems can distinguish algorithmic from human assertions. Our schema borrows this shape via a JSONB passthrough column, so when DSTU lands and FHIRcast handlers ship, the existing rows accept them without migration.
Where this is going
v1 ships the empty-state surface and the FHIR-listener-ready schema. The data path follows: FHIRcast subscription, DICOM Structured Report parsing, and an HL7 v2 ORU bridge — likely three separate tickets, prioritised by what Pro users tell us they actually run today. The deployer-side ledger is genuinely unbuilt market space. We’d rather build the second integration well than the eighth one badly.