Structure
The essay moves from arrival, to quiet failure, to a local duty to keep checking.
First, the essay establishes that clinical AI can enter through software channels and become routine without a fresh reliance decision. Then it shows why routine is a weak safeguard: models drift, calibration can fail, generated notes can invent details, and familiar alerts can be ignored or followed for reasons the click alone cannot reveal.
The middle separates three positions that earlier drafts blurred. The hospital deploys and renews. The clinician uses or signs. The patient inherits exposure. Those are not three identical decisions, and none can be reduced to a claim about private “trust.”
The landing assigns first-line checking to the institution that chooses, deploys, and renews the system and holds stop authority at least on paper. It also states the practical limit: a vendor’s contract or integration can make a feature hard to separate. Vendor accountability remains, and outside governance is a partial backstop. The intensity of checking scales with the tool’s power to change care or the permanent record.
The pressure summary
Changed
- The opening question moved from an evidence gate before adoption to a continuing-checking duty after adoption.
- The trust construct was narrowed to observable operational reliance; the patient was recast from decision-maker to exposed party.
- The prose changed from specialist register to a two-layer reader contract: plain body, exact receipts.
- Primary-source verification corrected nine details and moved earlier in the standing workflow for future issues.
Prevented
- Turning absence from the public record into proof that local checking never happened.
- Using one behavioral metric as a proxy for trust, review quality, or safety.
- Letting a locally tuned later tool validate an earlier version retroactively.
- Assigning responsibility so broadly that no actor held stop authority.
Stayed constant
- Installed is not the same as earned.
- Quiet failure is the central risk, not spectacular robot error.
- Hospitals hold the first-line local duty; vendors remain answerable.
- The checking burden rises with the system’s stakes.
Claim ledger
Open any entry to see what challenged it and what risk remains.
Installation and reliance are different events; reliance must be earned and renewable.
How it connectsThis is the essay’s hinge. Entry through an EHR, bundle, or pilot explains how a tool arrives, but does not establish that its local performance remains adequate.
What challenged itThe earliest frame treated evidence as a front-door gate. The author rejected that as temporally late; later review forced “reliance” to be described operationally rather than as private belief.
What happenedThe published issue asks what checking must exist at deployment, renewal, expansion, and major change.
What’s still at riskThe public record cannot show every institution’s internal review; the argument concerns the governance requirement, not a universal claim of non-review.
Related referenceRL-020-01, RL-020-02.
The dangerous failures can be quiet: calibration drift, invented chart details, and alert habituation.
How it connectsThis explains why adoption counts and user satisfaction cannot substitute for continuing performance checks.
What challenged itThe draft had to keep distinct failure modes distinct: risk-score calibration, ambient-note factual errors, and human response to repeated alerts.
What happenedThe final body uses short examples while the receipts retain study design, setting, and scope.
What’s still at riskThe examples come from different tool classes and cannot be collapsed into one failure rate.
Related referenceRL-020-02, RL-020-04, RL-020-05.
The Epic sepsis sequence shows why local validation and continuing checks matter.
How it connectsThe chronology gives the abstract argument an operational case: poor external performance, continued use, a hospital pause, and later locally tuned results.
What challenged itReview repeatedly distinguished “no public evidence of checking” from “no checking occurred” and v1 from a later locally tuned version.
What happenedThe essay carries the chronology without treating the later result as retroactive validation of the earlier tool.
What’s still at riskDifferent hospitals, versions, workflows, and endpoints limit direct comparison.
Related referenceRL-020-03.
Hospital, clinician, and patient occupy different positions in the reliance chain.
How it connectsThe institution deploys and renews, the clinician uses or signs an output, and the patient inherits exposure. Only the first two are operational decisions in the same sense.
What challenged itThe narrative review caught the draft calling all three “decisions,” even while saying the patient made none.
What happenedThe patient is described as exposed, not as having chosen or psychologically trusted the system.
What’s still at riskReal governance arrangements vary, and the three roles can overlap.
Related referenceRL-020-01, RL-020-06.
Behavioral measures do not directly reveal trust or review quality.
How it connectsAn unchanged draft, an overridden alert, or a prompt followed is observable behavior, not a clean measure of belief, attention, or correctness.
What challenged itAn external construct critique identified psychological overreach; the TREWS study supplied a counterexample to a simple “alerts are ignored” story.
What happenedThe essay treats behavior as bounded evidence and states what each measure cannot show.
What’s still at riskPublic studies rarely observe the private reasoning behind a click, signature, or override.
Related referenceRL-020-04, RL-020-05.
The hospital owns first-line operational checking; vendors remain answerable.
How it connectsThe hospital chooses, deploys, and renews the system and holds stop authority at least on paper; the vendor can make a feature contractually or technically inseparable and controls design, updates, disclosures, and often contract terms.
What challenged itThe remedy had to avoid shifting all responsibility to clinicians or patients and had to keep vendor duties visible.
What happenedThe final assignment is layered: institutional local checking first, with practical limits stated; vendor accountability intact; outside rules as a partial backstop.
What’s still at riskLaw and contracts differ by jurisdiction; this is a governance argument, not individualized legal advice.
Related referenceRL-020-07, RL-020-08.
Checking must scale with the tool’s power to change care or the permanent record.
How it connectsA drafting assistant, a risk score, and a system that triggers action should not face identical review intensity.
What challenged itA broad “check every tool” remedy risked becoming either impossible or ceremonial.
What happenedThe essay matches frequency, local validation, monitoring, and stop authority to the stakes and tool class.
What’s still at riskThe boundaries between classes are not always clean, especially when documentation changes downstream care.
Related referenceRL-020-02, RL-020-04, RL-020-08.
Outside governance exists, but it does not replace local checking.
How it connectsFederal transparency rules and professional or accreditation initiatives can improve information and expectations while leaving local performance and workflow effects unresolved.
What challenged itThe source layer had to keep final rules, proposed rules, and announced initiatives in their correct status.
What happenedThe final essay treats outside regimes as partial, not as proof that the local loop already exists.
What’s still at riskThese regimes can change after the issue’s publication date.
Related referenceRL-020-08.
Process is not proof.
How it connectsThe public record shows pressure, revisions, and source checks; the published claims still stand or fall on the sources and argument.
What challenged itIssue 20 used an unusually elaborate process, including several outside model reviews and a late source-fidelity correction pass.
What happenedThe record exposes changes and omissions, marks missing dialogue, and keeps the sealed diagnostic unpublished.
What’s still at riskReaders may mistake workflow complexity for reliability.
Related referenceThis record and the development record.