Executive takeaways
- Approve the configuration actually deployed. A manufacturer’s global validation and authorised change plan do not establish that a hospital-specific version passed its local acceptance criteria.
- Include hospital-side dependencies. Changes to documentation, laboratory inputs or alert routing may mean earlier validation no longer supports the current release decision—even when model weights are unchanged.
- Know what each kind of evidence can carry. Your release record supports your decision; an independent examination can test that record for a defined question; neither decides what your insurer will cover.
The decision is who can approve or delay the local release
When a hospital adapts medical artificial intelligence (AI) to its own records or care pathways, the configuration reaching clinicians may differ from the version previously evaluated. An unchanged software version can also behave differently when the hospital changes a source field, documentation practice or alert route. The practical decision is whether the exact configuration satisfies defined acceptance criteria before clinicians rely on it—and who can stop the release if evidence is insufficient.
A manufacturer’s global validation describes performance in a defined evaluation setting. A predetermined change control plan (PCCP), where authorised for a US medical device, may permit specified modifications under stated conditions. Neither substitutes for a retained account of which version, population, test conditions and limitations informed a particular hospital’s release. A named clinical and technical authority should decide whether to proceed, require further validation or defer deployment.
FDA’s hypothetical example describes a method, not a deployed product
On 20 October 2026 the US Food and Drug Administration (FDA) listed hypothetical PCCP examples in its Center for Devices and Radiological Health updates [1–3]. Its hospital-localised sepsis example is explicitly illustrative and incomplete: it is not an authorised product, an actual hospital deployment or a clinical-outcome study [1].
The example describes three bounded modifications: changing the weight of specified structured nursing-documentation inputs, retraining final model-output layers on local electronic health record data, and changing the alert threshold within a specified range [1]. These modifications are interdependent: the input adjustment can affect the tuning and threshold steps, and tuning can affect the threshold. FDA illustrates a sequence involving minimum local-data requirements, manufacturer review and approval, a locked model before site validation, independent data sequestered before training, prespecified acceptance criteria and post-deployment monitoring of alert positive predictive value, sensitivity and clinical response [1]. The global model remains available as a fallback in the hypothetical design.
Those details are regulatory illustration, not evidence that any manufacturer or hospital actually completed them. An authorised PCCP would have its own device-specific boundaries; a hospital cannot infer permission for unspecified tuning from the existence of FDA guidance [2].
Observed sepsis-model variation supports site-level scrutiny
Independent studies of a different, real-world proprietary sepsis prediction model illustrate why results from one setting should not be carried over without examination. In a 2021 US single-health-system external validation, researchers reported discrimination measured by the area under the receiver operating characteristic curve (AUROC) of 0.63. The 0.76–0.83 figures in the developer’s internal documentation arose in different evaluation settings and are not a matched comparison. The study reported alerts for 18% of hospitalised patients and failure to identify 67% of sepsis cases under its evaluation definitions [4].
A 2023 observational study covering 806,696 encounters at nine networked US hospitals reported a C-statistic of 0.55 at the largest hospital and a reported maximum of 0.73 across the hospitals, with lower performance where sepsis incidence, comorbidity and cancer prevalence were higher [5]. These are observational findings about that particular model, not FDA’s hypothetical device. Differences in case identification, population and practice constrain interpretation; the study cannot establish that local tuning itself improves or harms outcomes. It establishes a more limited proposition: a single global performance figure does not settle site-specific performance.
The operational principle transfers; regulatory permissions do not
United States, Canada and United Kingdom. FDA, Health Canada and the UK Medicines and Healthcare products Regulatory Agency issued joint guiding principles on PCCPs in October 2023 [6]. Shared principles are not interchangeable marketing permissions across jurisdictions.
European Union. The AI Act contains provisions relevant to predetermined and documented changes and conformity assessment of qualifying high-risk systems [7]. Joint guidance from the Artificial Intelligence Board and Medical Device Coordination Group discusses the Medical Device Regulation and In Vitro Diagnostic Medical Devices Regulation; the guidance is non-binding and does not replace the applicable legal text or notified-body assessment [8]. Regulation (EU) 2026/1744 amends Article 113 so that specified Chapter III, Sections 1–3 requirements apply from 2 August 2028 to high-risk systems under Article 6(1) and Annex I. This is not a blanket deferral of the AI Act or medical-device obligations [9]. Article 43(4) on predetermined changes is unchanged in the consolidated text [7].
India. The Central Drugs Standard Control Organisation (CDSCO) medical-device software guidance describes an Algorithm Change Protocol that may be devised where appropriate to the device and its risks. Its listed components are data management, performance evaluation and monitoring, retraining where applicable, software update and rollback plans; version control is addressed elsewhere in the guidance [10]. The document describes existing practice under the Medical Devices Rules, 2017; it expressly says it is not a new regulatory control. Classification and permissions for a particular device change require separate review.
Hospital changes can misalign an earlier release evaluation
The manufacturer may control model reweighting, retraining and technical release procedures while the hospital controls records, interfaces, clinical processes and alert destinations. Actual contractual and regulatory responsibilities depend on the deployment. A plausible failure mode is a late, missed or excessive alert caused or aggravated by a mismatch between the validated inputs and operational practice. Whether this affects a patient, creates loss, establishes legal liability or triggers insurance cover are separate questions.
ODA3 Institute assesses that a manufacturer-centred change plan can miss dependencies under hospital control. A revised nursing template, a changed laboratory interface or a new escalation route might alter the relevance of prior testing without changing the algorithm. Management should identify material dependencies in the site release record, link them to hospital change control and trigger proportionate impact review. A change does not automatically invalidate all previous validation; its effect must be assessed.
What a usable site release record should contain
For a single locally adapted clinical AI deployment, a minimum release record should identify (1) device and exact software/model/configuration version; (2) site, intended population and clinical use; (3) manufacturer-authorised change boundary; (4) site-specific data provenance, test-set separation and validation-report reference; (5) prespecified acceptance criteria and recorded results; (6) hospital-controlled dependencies and exceptions; (7) monitoring thresholds, escalation route and rollback-test evidence; and (8) named clinical and technical approvers with the decision date. These are ODA3 Institute’s proposed evidence fields, not a universal regulator-prescribed form.
The release authority should choose proceed, revise or defer against recorded criteria. Where evidence is unavailable, record the unresolved matter rather than relabelling it as a demonstrated control failure. Retention duration, signatures, clinical risk acceptance and access controls require an organisation-specific decision under applicable records requirements. An illustrative, synthetic site release record accompanies this article as a practitioner annex.
Independent examination must test the evidence, not merely receive it
Management and the manufacturer own their controls, test work and release evidence. A suitably competent and independent examiner could be commissioned to compare the deployed version with the evaluated version, inspect the separation of training and test data, reproduce or otherwise assess specified verification steps, and reconcile the recorded approval with prespecified acceptance criteria. The examiner could also test whether hospital-side dependencies, monitoring and rollback arrangements match the agreed release boundary.
Any conclusion must identify the exact configuration, population, time period, criteria, records examined, exceptions and limits of reliance. Such an examination would not guarantee future safety, demonstrate improved patient outcomes, determine legal liability or bind an insurer to provide cover. No independent examination of a deployed system was conducted for this article, and no assurance finding is issued.
An examination scope can be made operational through a bounded sequence: agree one system and one release question; obtain the manufacturer’s and hospital’s existing artefacts; reconcile version identity, evaluation boundary, acceptance criteria, exceptions and approvals; test a sample of underlying records and dependency-change triggers; and issue a report specifying what the evidence supports, what remains unknown and what was outside scope. Appropriate clinical, medical-device, machine-learning and quality-system competence must be established for the actual engagement. No delivery period, staffing arrangement, accreditation, insurer reliance right or assurance opinion is represented here as already established by ODA3 Institute.
A controlled release is a business decision, not only a technical control
For a CFO or Risk Committee, the economic question is whether the cost of maintaining a traceable release process is justified by the operational and evidentiary risks it addresses. Costs could include site data preparation, clinical review, change tracking, monitoring and tested fallback. Potential consequences to evaluate include additional diagnostic work, workflow disruption, incident investigation and disputed representations. No defensible numerical return on investment or loss estimate is available from the sources reviewed, and an evidence record is not a guarantee against liability or uncovered loss.
Three useful board tests are whether the organisation can retrieve the deployed configuration and its approval promptly, whether it can distinguish authorised change from validated local performance, and whether a named clinical authority has exercised the power to delay or reverse a release. A practical first-quarter objective is one completed dependency map, one approved site release record, one documented stop/defer decision exercise and one rollback test where safe and feasible. These are proposed milestones, not claims of completed ODA3 Institute client work.
Insurance relevance is a bounded, testable proposition
This discussion concerns underwriting AI-related risk—potential insured losses arising from a healthcare organisation’s or manufacturer’s use of AI—not an insurer’s use of AI to make underwriting decisions.
Insurer to organisation. A broker or underwriter may ask what tool is deployed, whether it differs from the authorised or evaluated version, how local acceptance was demonstrated and how monitoring and rollback work. One US broker, from its review of dozens of healthcare errors-and-omissions policies, reports that most are silent on AI, that a handful of carriers have introduced exclusions for unregulated AI in documentation and clinical decision support, and that some AI endorsements are limited to tools meeting validation or certification thresholds [11]. A US trade publication reports a malpractice insurer executive saying her company has no AI exclusion, while some carriers offer AI riders or specialised cover [12]. Neither source is a representative survey, nor does either establish a general requirement for site release records. Which policy, if any, responds depends on its actual terms, the insured activity, claim facts and applicable law.
Organisation to insurer. A hospital could substantiate an account of its AI deployment with its site release record, approved boundaries, validation results, monitoring history and exceptions, rather than rely on the unqualified statement that a system is “validated”. A manufacturer could supply product-version and supported-change evidence. Independent examination may improve the traceability of those assertions; it does not establish that an underwriter will accept them or grant favourable terms. Insurers may instead address an exposure through wording, exclusions, limits or indemnities. No premium discount, coverage outcome or insurer acceptance tied to a site release record has been established here. A proposed next research test is to present a synthetic, clearly labelled evidence pack to consenting underwriters and document whether it changes their information requests or risk assessment; that test has not been completed.
| Executive or underwriting question | Evidence to examine | What it can show | What remains uncertain |
|---|---|---|---|
| Is the local change within the permitted boundary? | Device authorisation, applicable PCCP, modification log | Whether changes appear consistent with documented scope | Device-specific regulatory determination and local testing |
| Was the exact site version evaluated? | Locked version identifier, sequestered-test record, validation report, sign-off | Whether prespecified criteria were evaluated for that version | Live clinical outcomes and unobserved populations |
| Did hospital operating assumptions change? | Data/interface dependency map, nursing and workflow change logs | Whether changes were identified and reviewed | Unrecorded changes or untested interactions |
| Are monitoring and rollback operational? | Metric history, escalation criteria, rollback test and clinical continuity plan | Whether detection and reversion arrangements exist and were exercised | Their effectiveness during future incidents |
| What would independent examination support? | Examiner’s scope, methods, verified records and exceptions | A bounded conclusion about specified evidence and controls | Future safety and system-wide performance |
| What insurance treatment applies? | Actual policy, endorsements, exclusions, proposal statements and indemnities | Relevant contractual terms and disclosed facts | Claim response, coverage interpretation and price |
The principle also applies outside healthcare
The technical details and regulatory permissions differ, but an analogous evidence question arises when a manufacturing plant reconfigures a quality-inspection model, or when a regional operation changes the inputs and decision workflow of an enterprise AI service. The organisation must know which configuration was examined, which local dependencies could change its behaviour, and who can authorise use. Those examples are analytical analogies—not studied deployments or evidence that medical-device requirements apply across sectors.
The Board should assign release authority and preserve exceptions
| Action | Accountable owner | Evidence and reconsideration condition |
|---|---|---|
| Require a recorded decision for each locally adapted release | Chief Medical Officer and Chief Information Officer | Version, test boundary, exceptions and joint approval; tailor requirements where a tool is genuinely unchanged and within the evaluated site/workflow scope |
| Connect hospital change management to release dependencies | Chief Information Officer and Chief Nursing Officer | Maintained dependency map, measured change triggers and review history; reliance on a supplier requires demonstrated monitoring and notification, not only a contractual promise |
| Require manufacturer evidence deliverables | Procurement lead and General Counsel | Supported modification scope, validation artefacts, incident escalation and rollback responsibilities; revisit if no adaptation is permitted or performed |
| Reconcile insurance submissions with the deployed AI inventory | Head of Risk/Insurance and General Counsel | Actual configurations, disclosure statements and reviewed wordings; reconsider when documented policy terms already address the relevant exposure |
| Test the effectiveness of delegated release authority | Clinical governance executive, overseen by Audit/Risk Committee | Record of releases approved, deferred, amended and rolled back; escalate when authority does not operate in practice |
Notably Absent
No authorised device dossier, live hospital dataset, completed site validation, patient-outcome comparison or deployed product was examined by ODA3 Institute. FDA’s example is hypothetical, not an approved hospital deployment. The cited clinical studies assess other systems, not the hypothetical device. The reviewed insurance sources do not provide a site-release-based coverage decision, premium effect or representative underwriting requirement. No exhaustive case-law review or insurer-market survey was performed. This article does not establish how a notified body, Indian licensing authority, court or insurer would decide a particular case.
Close
The next useful step is not another assertion that AI has been validated. It is to select one system, one bounded release question and one defined evidence base, then determine whether the existing manufacturer and hospital records can substantiate the decision to use that precise configuration. If they cannot, the missing evidence, accountable owner and release consequence should be explicit.
ODA3 Institute would welcome discussion with hospitals and manufacturers that have tried to assemble this evidence: which dependency, record or hand-off proved hardest to substantiate? Contact: contact@oda3.org. Any examination would require agreed scope, competence, confidentiality, access and deliverables before work begins, and would not imply certification, clinical clearance or insurer acceptance.
References
[1] US Food and Drug Administration. “Novel Medical Devices with Predetermined Change Control Plans: Hypothetical Case Examples.” FDA, page listed 20 October 2026. https://www.fda.gov/medical-devices/premarket-submissions-selecting-and-preparing-correct-submission/novel-medical-devices-predetermined-change-control-plans-hypothetical-case-examples (accessed 22 October 2026).
[2] US Food and Drug Administration. “Predetermined Change Control Plans.” FDA, page updated 20 October 2026. https://www.fda.gov/medical-devices/premarket-submissions-selecting-and-preparing-correct-submission/predetermined-change-control-plans (accessed 22 October 2026).
[3] US Food and Drug Administration. “CDRH New: News and Updates.” FDA, index entry 20 October 2026. https://www.fda.gov/medical-devices/medical-devices-news-and-events/cdrh-new-news-and-updates (accessed 22 October 2026).
[4] Wong A, et al. “External Validation of a Widely Implemented Proprietary Sepsis Prediction Model in Hospitalized Patients.” JAMA Internal Medicine, 2021;181(8), published online 21 June 2021; correction published 2 August 2021. https://pmc.ncbi.nlm.nih.gov/articles/PMC8218233 (accessed 22 October 2026).
[5] Lyons PG, et al. “Factors Associated With Variability in the Performance of a Proprietary Sepsis Prediction Model Across 9 Networked Hospitals in the US.” JAMA Internal Medicine, 2023;183(6):611–612, published online 3 April 2023. https://pmc.ncbi.nlm.nih.gov/articles/PMC10071393 (accessed 22 October 2026).
[6] FDA, Health Canada and MHRA. “Predetermined Change Control Plans for Machine Learning-Enabled Medical Devices: Guiding Principles.” GOV.UK, 24 October 2023. https://www.gov.uk/government/publications/predetermined-change-control-plans-for-machine-learning-enabled-medical-devices-guiding-principles (accessed 22 October 2026).
[7] European Commission AI Act Service Desk. "Article 43: Conformity assessment," Regulation (EU) 2024/1689, consolidated text as at 27 July 2026. https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-43 (accessed 22 October 2026).
[8] European Commission, MDCG / Artificial Intelligence Board. “FAQ on interplay between MDR and IVDR and the Artificial Intelligence Act,” MDCG 2025-6 / AIB 2025-1, June 2025. https://health.ec.europa.eu/document/download/b78a17d7-e3cd-4943-851d-e02a2f22bbb4_en?filename=mdcg_2025-6_en.pdf (accessed 22 October 2026).
[9] European Parliament and Council. Regulation (EU) 2026/1744 of 8 July 2026 (Digital Omnibus on AI), amending Regulation (EU) 2024/1689, Article 113. Official Journal of the European Union, 24 July 2026. https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=oj%3AL_202601744. Consolidated Article 113: https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-113 (both accessed 22 October 2026).
[10] Central Drugs Standard Control Organisation. “Guidance Document on Medical Device Software,” CDSCO/MD/GD/MDSW/01/2026, Ministry of Health and Family Welfare, Government of India, publication date not stated. https://cdsco.gov.in/opencms/export/sites/CDSCO_WEB/Pdf-documents/Guidance-document-on-Medical-Device-Software-under-MDR-2017.pdf (accessed 22 October 2026).
[11] Angelova M. “DoNoHarm.exe: The Liability Reckoning for AI in U.S. Healthcare.” EPIC Insurance Brokers & Consultants, 12 January 2026. https://www.epicbrokers.com/insights/donoharm-exe/ (accessed 22 October 2026).
[12] Littrell A. “AI on Trial: How malpractice insurers are adapting to AI risk.” Medical Economics, 8 October 2025. https://www.medicaleconomics.com/view/ai-on-trial-how-malpractice-insurers-are-adapting-to-ai-risk (accessed 22 October 2026).
Continue to Part 2: When a Hospital’s AI Changes Without a Model Update (link to be added after Part 2 is published).
Practitioner Annex — Illustrative Hospital AI Site Release Record
Synthetic demonstration for educational and research purposes. This record does not represent an examined hospital, an authorised medical device, a completed ODA3 Institute assessment or a regulatory-approved assurance methodology.
ODA3 Institute | Practitioner annex | 22 October 2026 | Synthetic example — not an examined device or hospital
Companion to the ODA3 Institute Insights article "Hospital AI Release Evidence Must Follow the Local Configuration".
This example demonstrates the structure of a release record. All identifiers, actions and outcomes below are fictional placeholders; none demonstrates clinical performance, authorisation, or conformity with a specific medical-device requirement. Replace all values with actual evidence before using the form.
| Field | Illustrative entry | Source/evidence to request |
|---|---|---|
| Release ID and site | DEMO-SITE-001 / Fictional Hospital A | Controlled release register |
| Device / intended use | Hypothetical sepsis alert; decision support only | Authorised intended-use statement |
| Manufacturer and base version | ExampleCo / Base model X.Y | Manufacturer release record; approved baseline |
| Local configuration | Model X.Y-L1; documented input mapping and threshold | Locked configuration manifest; difference report |
| Regulatory change boundary | UNVERIFIED — do not infer permission | Applicable authorisation, approved PCCP if relevant, regulatory review |
| Local population / dataset | NOT PROVIDED | Inclusion/exclusion criteria, source provenance and period |
| Held-out evaluation | NOT PERFORMED IN THIS EXAMPLE | Sequestering record, test dataset ID, validation protocol |
| Acceptance criteria and results | NOT ESTABLISHED | Predetermined criteria and signed validation report |
| Hospital dependencies | Nursing template, laboratory mapping, escalation route | Interface/version map, change notices, ownership |
| Monitoring and exceptions | Metrics/triggers TO BE DEFINED; exceptions open | Site monitoring plan, open-exception register |
| Fallback/rollback | NOT TESTED | Exercise report, continuity-of-care review, authority |
| Clinical and technical approvers | NOT ASSIGNED | Delegation matrix, dates, decision record |
| Release decision | DEFER PENDING EVIDENCE (illustrative governance outcome only) | Approved clinical-governance decision |
Suggested minimum decision rule
A competent clinical authority should not treat a missing or unverified site acceptance result as proof of adequacy. Record missing evidence as unknown, establish its consequences under the applicable procedure, and document a proceed/revise/defer decision with rationale. Where a criterion is demonstrably breached, document the confirmed exception separately from missing material.
Questions for an examination scope
- Is the installed configuration the precise configuration evaluated?
- Was local test data independent of tuning and fit for intended use?
- Were criteria declared before tests and met by the accepted configuration?
- Are hospital-controlled inputs and workflows within the evaluated boundary?
- Are monitoring triggers, escalation authority and rollback demonstrably operable?
- What evidence or competence is missing, and who has authority to defer use?
- What bounded conclusion, if any, is justified for a named system, site, period and evidence set?
Important: This illustrative worksheet is not an ODA3 Institute certification, audit, medical recommendation, approved assessment method, production-ready template or insurer reliance artefact. It is not evidence of prior clinical examinations by ODA3 Institute.
Annex status: Synthetic illustration only. Not an examined hospital, clinical release, validation, certification or assurance finding.
Methodology note
Defined configuration → authorised change boundary → site data and evaluation → acceptance criteria → clinical decision → monitoring and change-triggered reassessment
