Safety receipt layer for permit-before-action gating of AI-assisted clinical decision support interventions
A safety receipt layer is interposed between an electronic health record (EHR) system and clinical decision support intervention (DSI) engines, including AI-assisted DSIs. For each DSI episode, the layer constructs a canonical clinical context envelope, evaluates a policy graph, and computes a permit outcome (permit, guarded permit, override, deny) that is enforced in a permit-before-action, fail-closed configuration. A time-of-check-to-time-of-use latch binds policy evaluation and any anchoring precondition to rendering and EHR write-back so outputs cannot be finalized without an affirmative permit or recorded override. The layer emits a structured, machine-verifiable safety receipt encoding policy identifiers, the context envelope or a cryptographic digest of a canonicalized field list, the permit outcome, requested and effective behavior modes, and clinician response. Receipts are anchored in an append-only verifiable log with maximum-merge-delay signed heads and inclusion and consistency proofs, enabling verification, role-based views, monitoring, and mappings to health IT transparency or certification requirements.
1 . A computer-implemented method comprising:
intercepting, by a safety receipt layer interposed between an electronic health record (EHR) system and a clinical decision support intervention (DSI) engine, a DSI request for a DSI episode, the DSI request comprising patient data from the EHR system;
constructing, by the safety receipt layer, a clinical context envelope representing a subset of the patient data and one or more DSI metadata fields;
evaluating, by a policy graph evaluation engine of the safety receipt layer, a policy graph over the clinical context envelope to determine a permit outcome for the DSI episode;
gating, by a permit decision engine of the safety receipt layer, execution of the DSI engine based at least in part on the permit outcome, including enforcing permit-before-action and fail-closed semantics for rendering an AI-assisted clinical recommendation to a clinician or for initiating any DSI-initiated write-back to the EHR system; and
generating, by a safety receipt generator of the safety receipt layer, a structured, machine-verifiable safety receipt for the DSI episode, the structured, machine-verifiable safety receipt comprising data representing at least: (i) the clinical context envelope or a cryptographic digest of a canonicalized listing of fields of the clinical context envelope, (ii) the policy graph or an identifier of the policy graph, and (iii) the permit outcome.
2 . The method of claim 1 , further comprising transmitting, by a proof-of-policy-compliance (PoPC) anchor client, at least a portion of the structured, machine-verifiable safety receipt or a cryptographic digest thereof to a tamper-evident audit store comprising an append-only verifiable log configured to publish signed heads under a maximum-merge-delay freshness policy and to expose inclusion proofs and consistency proofs, and treating successful transmission and verification of an inclusion proof against a fresh signed head as an anchoring precondition for finalizing or delivering the AI-assisted clinical recommendation.
3 . The method of claim 1 , further comprising computing the permit outcome as one of:
permit, permit with guardrails, require override, or deny.
4 . The method of claim 1 , further comprising:
receiving, at the safety receipt layer, a clinician response to the AI-assisted clinical recommendation, the clinician response indicating an override type and one or more override reason codes associated with an override-permitted outcome and, when present, a secondary authentication identifier associated with a secondary authentication event; and
encoding, in the structured, machine-verifiable safety receipt, data representing the clinician response, including the override type, the one or more override reason codes, and the secondary authentication identifier.
5 . The method of claim 1 , wherein constructing the clinical context envelope comprises including at least: one or more diagnosis codes or problem list entries, one or more vital signs or laboratory results, one or more active medications, a clinician role or user identifier, and a DSI type identifier.
6 . The method of claim 1 , wherein evaluating the policy graph comprises evaluating the policy graph based at least in part on the one or more DSI metadata fields, the one or more DSI metadata fields comprising at least one of: a DSI type identifier; a model identifier, a DSI family identifier, a version identifier, or a configuration identifier; a transparency profile identifier or a profile identifier associated with the DSI engine or a deployment thereof; a risk-tier indicator, a hazard classification, a change-control identifier, or a mitigation-status indicator associated with the DSI type or model configuration; a deployment identifier, a tenant identifier, or a site identifier; a requested behavior mode; or a site-local validation indicator, a monitoring indicator, or a governance-status indicator associated with the DSI engine or a deployment thereof.
7 . The method of claim 1 , further comprising operating the permit decision engine to enforce fail-closed behavior by preventing finalization of both (i) rendering the AI-assisted clinical recommendation to a clinician and (ii) any DSI-initiated write-back of orders or documentation to the EHR system for the DSI episode unless the permit outcome satisfies a permit condition and an anchoring precondition, and enforcing a time-of-check-to-time-of-use latch binding policy evaluation and any anchoring precondition to render and write-back finalization.
8 . The method of claim 7 , further comprising generating, by the safety receipt generator, a failure-mode safety receipt encoding a structured reason code when the permit outcome does not satisfy the permit condition.
9 . The method of claim 1 , further comprising encoding, in the structured, machine-verifiable safety receipt: (i) an explicit listing of electronic health record fields and clinical decision support intervention metadata fields included in the clinical context envelope, and (ii) a cryptographic digest of that listing, and exposing a verification interface configured, given EHR and DSI logs for the DSI episode, to recompute the listing and the cryptographic digest using deterministic canonicalization rules and confirm that the permit outcome was generated from that clinical context envelope.
10 . The method of claim 1 , wherein constructing the clinical context envelope and generating the structured, machine-verifiable safety receipt further comprise encoding, in the structured, machine-verifiable safety receipt: (i) a requested imaging behavior mode, (ii) an effective imaging behavior mode, and (iii) the permit outcome for an imaging triage DSI episode.
11 . The method of claim 1 , further comprising enforcing a permit validity interval and a revocation mechanism, wherein expiration of a recorded permit validity interval or presence of an active revocation identifier causes the safety receipt layer to deny finalization of render or write-back for the DSI episode under fail-closed semantics, and to emit a failure-mode safety receipt.
12 . A non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause a system to:
intercept, by a safety receipt layer interposed between an electronic health record (EHR) system and a clinical decision support intervention (DSI) engine, a DSI request for a DSI episode, the DSI request comprising patient data from the EHR system;
construct a clinical context envelope representing a subset of the patient data and one or more DSI metadata fields;
evaluate a policy graph over the clinical context envelope to determine a permit outcome for the DSI episode;
gate execution of the DSI engine based at least in part on the permit outcome, including enforcing permit-before-action and fail-closed semantics for rendering an AI-assisted clinical recommendation to a clinician or for initiating any DSI-initiated write-back to the EHR system; and
generate a structured, machine-verifiable safety receipt for the DSI episode, the structured, machine-verifiable safety receipt comprising data representing at least: (i) the clinical context envelope or a cryptographic digest of a canonicalized listing of fields of the clinical context envelope, (ii) the policy graph or an identifier of the policy graph, and (iii) the permit outcome.
13 . The non-transitory computer-readable medium of claim 12 , wherein the instructions, when executed, further cause the system to transmit at least a portion of the structured, machine-verifiable safety receipt or a cryptographic digest thereof to a tamper-evident audit store comprising an append-only verifiable log configured to publish signed heads under a maximum-merge-delay freshness policy and to expose inclusion proofs and consistency proofs, and to treat successful transmission and verification of an inclusion proof against a fresh signed head as an anchoring precondition for finalizing or delivering the AI-assisted clinical recommendation.
14 . The non-transitory computer-readable medium of claim 12 , wherein the instructions, when executed by one or more processors, further cause the system to enforce a time-of-check-to-time-of-use latch binding policy evaluation and any anchoring precondition to render and write-back finalization for the DSI episode, and to apply an idempotency mechanism configured to ensure atomic finalization of render and write-back for the DSI episode across retries, the idempotency mechanism comprising at least one of: an idempotency token, a transaction fence, a compare-and-swap-based commit marker, a write-ahead-log barrier, or a functionally equivalent control mechanism that prevents duplicate or split-brain finalizations across retries.
15 . The non-transitory computer-readable medium of claim 12 , wherein the instructions, when executed, further cause the system to encode, in the structured, machine-verifiable safety receipt: (i) an explicit listing of electronic health record fields and clinical decision support intervention metadata fields included in the clinical context envelope, and (ii) a cryptographic digest of that listing, and to provide a verification interface configured, given EHR and DSI logs for the DSI episode, to recompute the listing and the cryptographic digest using deterministic canonicalization rules and confirm that the permit outcome was generated from that clinical context envelope.
16 . The non-transitory computer-readable medium of claim 12 , wherein the instructions, when executed, further cause the system to operate the safety receipt layer over an agentic clinical workflow in which one or more autonomous or semi-autonomous software agents orchestrate multiple DSI steps, retrieval operations, or documentation steps for an episode of care, and to treat each DSI step as a bounded DSI episode or sub-episode subject to the same permit-before-action and fail-closed semantics enforced by the safety receipt layer.
17 . A system comprising:
an electronic health record (EHR) system configured to store patient data;
a clinical decision support intervention (DSI) engine configured to receive patient data from the EHR system and to output a clinical recommendation, including AI-assisted clinical recommendations, based at least in part on the patient data; and
a safety receipt layer interposed between the EHR system and the DSI engine for a DSI episode, the safety receipt layer comprising:
a context capture module configured to construct, responsive to an invocation of the DSI engine for the DSI episode, a clinical context envelope representing a subset of the patient data and one or more DSI metadata fields associated with the DSI engine;
a policy graph evaluation engine configured to evaluate a policy graph over the clinical context envelope to determine a permit outcome for the DSI episode;
a permit decision engine configured to gate execution of the DSI engine based at least in part on the permit outcome, including enforcing permit-before-action and fail-closed semantics for rendering the AI-assisted clinical recommendations to a clinician or for initiating any DSI-initiated write-back to the EHR system; and
a safety receipt generator configured to generate a structured, machine-verifiable safety receipt for the DSI episode, the structured, machine-verifiable safety receipt comprising data representing at least: (i) the clinical context envelope or a cryptographic digest of a canonicalized listing of fields of the clinical context envelope, (ii) the policy graph or an identifier of the policy graph, and (iii) the permit outcome.
18 . The system of claim 17 , further comprising a proof-of-policy-compliance (PoPC) anchor client configured to transmit at least a portion of the structured, machine-verifiable safety receipt or a cryptographic digest thereof to a tamper-evident audit store comprising an append-only verifiable log that publishes signed heads subject to a maximum-merge-delay freshness policy and exposes inclusion proofs and consistency proofs; wherein the permit decision engine is further configured to treat successful transmission by the PoPC anchor client, including verification of an inclusion proof against a fresh signed head under the maximum-merge-delay freshness policy, as an anchoring precondition for finalizing or delivering the AI-assisted clinical recommendation; and wherein the structured, machine-verifiable safety receipt further encodes a status tuple comprising at least a signed_head_id, a head_timestamp, and a staleness_interval derived from the anchoring event and the maximum-merge-delay freshness policy, the status tuple being configured to enable verification of log freshness and anchoring integrity at review time.
19 . The system of claim 17 , wherein the policy graph evaluation engine is further configured to classify the permit outcome into one of: permit, permit with guardrails, require override, or deny.
20 . The system of claim 17 , wherein the permit decision engine is configured to enforce a time-of-check-to-time-of-use latch binding policy evaluation and any anchoring precondition to render and write-back finalization for the DSI episode; to apply an idempotency mechanism configured to ensure atomic finalization of render and write-back for the DSI episode across retries, the idempotency mechanism comprising at least one of: an idempotency token, a transaction fence, a compare-and-swap-based commit marker, a write-ahead-log barrier, or a functionally equivalent control mechanism that prevents duplicate or split-brain finalizations across retries; and to enforce fail-closed behavior unless (i) the permit outcome satisfies a permit condition and (ii) any applicable anchoring precondition is satisfied.
21 . The system of claim 17 , wherein the clinical context envelope comprises at least: (i) one or more diagnosis codes or problem list entries, (ii) one or more vital signs or laboratory results, (iii) one or more active medication orders, (iv) a clinician role or user identifier, and (v) a DSI type identifier associated with the DSI engine.
22 . The system of claim 17 , wherein the safety receipt generator is further configured to include, in the structured, machine-verifiable safety receipt, data representing a clinician response to the AI-assisted clinical recommendation, including any override type and one or more override reason codes associated with an override-permitted outcome and, when present, a secondary authentication identifier associated with a secondary authentication event required to complete the override.
23 . The system of claim 17 , wherein the safety receipt generator is further configured to encode the structured, machine-verifiable safety receipt in a machine-readable serialization format comprising defined fields mapped to one or more health information technology transparency or certification requirements, including at least (i) a DSI transparency profile identifier and (ii) either a framework profile identifier or a reference to associated transparency documentation for the DSI engine, such that the structured, machine-verifiable safety receipt can be interpreted both as a permit-before-action execution record and as machine-readable evidence of conformance to one or more transparency or certification frameworks.
24 . The system of claim 17 , wherein the policy graph evaluation engine is configured to evaluate the policy graph based at least in part on the one or more DSI metadata fields, the one or more DSI metadata fields comprising at least one of: a DSI type identifier; a model identifier, a DSI family identifier, a version identifier, or a configuration identifier; a transparency profile identifier or a profile identifier associated with the DSI engine or a deployment thereof; a risk-tier indicator, a hazard classification, a change-control identifier, or a mitigation-status indicator associated with the DSI type or model configuration; a deployment identifier, a tenant identifier, or a site identifier; a requested behavior mode; or a site-local validation indicator, a monitoring indicator, or a governance-status indicator associated with the DSI engine or a deployment thereof.
25 . The system of claim 17 , wherein the structured, machine-verifiable safety receipt further comprises data representing: (i) an explicit listing of electronic health record fields and clinical decision support intervention metadata fields included in the clinical context envelope, and (ii) a cryptographic digest of that listing, and wherein the safety receipt layer exposes a verification interface configured, given EHR and DSI logs for the DSI episode, to recompute the listing and the cryptographic digest using deterministic canonicalization rules and to confirm that the permit outcome was generated from that clinical context envelope.
26 . The system of claim 17 , wherein the structured, machine-verifiable safety receipt further comprises one or more cross-rail references to external governance receipts, including at least one of: a sensor receipt emitted by a trusted sensor ingress rail, a reality receipt emitted by a trusted reality compositor, a safety evidence receipt emitted by a safety risk budget engine, or a revenue-cycle governance receipt, and wherein the cross-rail references are evidentiary only and do not alter the safety receipt layer's gate conditions, permit outcomes, permit-before-action semantics, or fail-closed behavior.
27 . The system of claim 17 , wherein the DSI engine comprises an imaging triage DSI configured to process medical images and output imaging behavior modes including at least a decision-support imaging behavior mode and an autonomous or semi-autonomous imaging behavior mode, and wherein the permit decision engine is further configured to gate entry into the autonomous or semi-autonomous imaging behavior mode based at least in part on site-local validation indicators and the permit outcome, and wherein the structured, machine-verifiable safety receipt further comprises data representing a requested imaging behavior mode and an effective imaging behavior mode for the DSI episode.
28 . The system of claim 17 , wherein the safety receipt layer is further configured to operate over an agentic clinical workflow in which one or more autonomous or semi-autonomous software agents orchestrate multiple DSI steps, retrieval operations, or documentation steps for an episode of care, and wherein each step is treated as a bounded DSI episode or sub-episode subject to the same permit-before-action and fail-closed semantics enforced by the safety receipt layer, and the structured, machine-verifiable safety receipt further comprises data indicating at least a workflow identifier and a step identifier linking the DSI episode to the agentic clinical workflow.
29 . The system of claim 17 , wherein patient, encounter, and organization identifiers encoded in the structured, machine-verifiable safety receipt are pseudonymous identifiers derived via a per-tenant keyed HMAC (hash-based message authentication code), enabling cross-receipt linkage for oversight and analytics without exposing direct identifiers.
30 . The system of claim 17 , wherein the structured, machine-verifiable safety receipt further comprises a policy_digest and, optionally, a policy_signature over the policy graph or policy profile used to compute the permit outcome.