Medical AI workflow links intended use to monitored clinical decisions

The International Medical Device Regulators Forum (IMDRF) published final principles for planned medical-software changes on August 6, 2026. A predetermined change control plan identifies specific changes, an implementation and control protocol with prespecified criteria, and an assessment of their effects; covered changes remain within the software's original intended purpose.

The update framework completes a lifecycle that starts before a model receives data and continues after release. Medical AI, or the use of artificial intelligence in health care, is an umbrella for many tools rather than one product class, and a system's intended purpose and the rules in each market determine whether it enters a medical-device pathway.

Medical AI covers several kinds of work

World Health Organization (WHO) guidance published in January 2024 groups health uses of large multimodal models into diagnosis and clinical care, patient-guided use, administration, education, and research and drug development. That list concerns generative models, while the wider medical AI field also includes image classifiers, risk models, signal analysis and systems that rank cases for review.

A model can produce a class, probability, ranking, measurement, summary or draft. Its place in the workflow decides who sees that output, what decision it may influence and what evidence is needed.

Function	Typical inputs	Output and user	Control question
Clinical interpretation	Images, waveforms or laboratory values	A finding, measurement or score for trained staff	Does the evidence cover the intended population, equipment and setting?
Prediction and prioritization	Health records, medication records or vital signs	A risk estimate, alert or ranked worklist for a care team	Are the time horizon, threshold and response to an error defined?
Documentation and operations	Speech, notes, messages or scheduling data	A draft note, summary or work item for clinical or administrative staff	Who checks omissions, controls access and signs the final record?
Patient-facing information	Questions, forms or personal records	A generated response or organized record for a patient or caregiver	What is the stated scope, and when does the service transfer the interaction to a person?

This table is an APPI News editorial grouping, not a regulator's classification system. A scheduling assistant and software that supplies information for a clinical decision can use similar technology while carrying different evidence, governance and legal requirements.

Five stages connect data to a clinical workflow

A controlled workflow links the declared purpose, data, evaluation, human interaction and monitoring record. The five-stage sequence below is an APPI News synthesis of the cited WHO and IMDRF documents, not a certification program or a legal test in any country.

Stage one: Define the intended use

WHO's 2023 regulatory considerations place intended use, human intervention, continuous learning, cybersecurity, external validation and data quality inside the lifecycle for AI in health. A usable specification names the intended user, population, setting, input, output and decision that the output may influence.

The scope also records exclusions, missing-input behavior and the process that remains available when the system cannot produce a result. A broad phrase such as “assists clinicians” cannot determine a relevant test population, performance measure or response to failure.

Stage two: Build a traceable data pipeline

IMDRF's 10 good machine learning practice principles call for datasets that represent the intended population, use environment and measurement inputs, with training and test data kept appropriately independent and external validation proportionate to risk. The principles also identify subgroups and conditions in which a model may underperform as part of the evaluation.

A data record therefore needs provenance, collection dates and sites, equipment, units, missing-value handling, labeling methods and preprocessing. It also needs to connect each dataset to the model version that used it, because a later data pipeline or model release may no longer match the original test.

Stage three: Answer three evaluation questions

IMDRF's clinical-evaluation framework separates valid clinical association, analytical validation and clinical validation. Those tests ask whether the output has a sound relationship to the target condition, whether the software processes inputs reliably, and whether the output achieves its intended purpose in the target population and care context.

An overall accuracy score cannot answer all three questions or show what happens to false positives, false negatives and unusable inputs. A hospital validation record also needs independent data, subgroup results, workflow checks and defined responses when monitoring finds a problem.

Stage four: Connect the output to people and systems

The 2025 IMDRF principles call for assessing the human-AI team in the intended environment rather than evaluating the model alone. The assessment covers how users understand the output and its limits, possible overreliance, reasonably foreseeable misuse and the effects on work performance.

The operating design must state whether a person can accept, modify, reject or disregard the output, and it must preserve a fallback during an outage or unsupported case. An audit record can connect the input time, model and software version, output, reviewer and later action without treating the existence of a review button as proof of effective oversight.

Stage five: Monitor use and control changes

The IMDRF machine-learning principles call for risk-based monitoring in real-world use and controls for retraining risks such as overfitting, unintended bias and performance degradation. A monitoring record can set a baseline, review schedule, alert and stop conditions, investigation owner and recovery route for the deployed version.

The 2026 IMDRF framework divides a predetermined change control plan into a description of changes, a change plan and an impact assessment. It says the change plan should specify verification and validation, acceptance criteria, deployment and communication, while the impact assessment connects anticipated benefits, risks and mitigations.

The document is a common reference rather than a worldwide authorization, and it says some jurisdictions may not accept these plans for regulatory review. APPI News has separately examined how planned AI software changes require version-specific tests, user communication and a local hospital release record.

One record keeps the five stages aligned

The workflow can be reviewed as five connected records, each describing the same intended use and deployed version. A separate APPI News analysis organizes deployment readiness into purpose, evidence, interoperability, human control and monitoring.

Record	Minimum scope	Mismatch it can expose
Purpose	User, population, setting, input, output, affected decision, exclusions and fallback	A marketing claim that is broader than the tested use
Data	Provenance, sites, dates, equipment, preprocessing, labels and subgroup coverage	Deployment data that differ from the evaluation sample
Evaluation	Reference standard, independent test set, prespecified measures, errors and unresolved limits	A headline score that does not support the intended decision
Workflow	Interface, user authority, audit trail, training, outage handling and escalation	A model result that reaches the wrong record or has no effective reviewer
Release and monitoring	Version, baseline, alerts, stop authority, update evidence, notice and recovery	A changed system that still relies on evidence for an earlier version

The records need common identifiers for the model, software, data pipeline and interface. If a supplier changes one component without updating the linked evidence, the file no longer describes the system in routine use.

How this plays out outside Taiwan

The same workflow produces different regulatory tasks in different markets. A team planning a clinical AI product for the United States should start with the intended use and the function's place in the product, then check the US Food and Drug Administration's device-software guidance and submission pathway. The FDA's August 2025 guidance treats a predetermined change control plan as part of a marketing submission for certain AI-enabled device software functions. It asks the manufacturer to describe the planned modifications, the method for developing, validating and implementing them, and the impact assessment. That does not create a general permission to update any health application after launch. The manufacturer still needs to establish which FDA pathway applies and whether a proposed change stays within the cleared or authorized intended use.

For an American hospital, the practical question is therefore not whether a vendor says that a model is “learning.” The procurement file should identify the product's FDA status, the exact cleared or authorized function, the model and software version, the evidence population, and the process for reviewing a change notice. The FDA's public device-software guidance navigator is a useful starting point for locating the relevant documents. If the product is not being marketed as a medical device, the hospital still needs its own rules for privacy, security, clinical review and record retention; the FDA device pathway does not answer those operational questions.

In the United Kingdom, the Medicines and Healthcare products Regulatory Agency (MHRA) says its software-and-AI guidance covers products that meet a clinical need and may be regulated as medical devices or in vitro diagnostic devices in the UK. A supplier should use that guidance to test whether its intended purpose makes the software a medical device, which conformity route is relevant, and what post-market or incident obligations follow. The UK label is not a substitute for a clinical validation file. A hospital evaluating an AI tool should still ask which population and care setting were tested, who can override the output, and how the supplier will report a material change.

The United Kingdom also illustrates why availability cannot be inferred from a product page. A tool may be offered to UK customers as an administrative assistant while a separate diagnostic function may fall under medical-device controls. Teams should check the product's intended purpose, the manufacturer's UK regulatory information and the MHRA guidance before treating a claim of “clinical” use as evidence of authorization. If the answer is unclear, the MHRA's published software and AI material provides the route for classification questions; a vendor's marketing language does not settle the issue.

Singapore gives the workflow a more explicit software lifecycle frame. Singapore's Health Sciences Authority (HSA) says digital-health products intended to investigate, detect, diagnose, monitor, treat or manage a medical condition are generally subject to its medical-device controls. HSA also points developers to software-medical-device guidance, product-registration routes and its Artificial Intelligence in Healthcare Guidelines. The agency's current digital-health page describes an immediate registration pathway for some standalone software and mobile applications that relies on qualifying review by reference regulators, but that is a defined route with eligibility conditions, not a blanket exemption.

For a Singapore deployment, the file should separate three questions: whether the product is a medical device under the Health Products Act 2007, whether it has the required HSA registration or another applicable route, and how the healthcare organization will govern use after supply. HSA's software guidance calls for lifecycle controls such as risk assessment, verification and validation, change control, traceability and post-market duties. Its AI-in-healthcare guidance assigns responsibilities across developers, healthcare organizations and professionals. That makes the human-review record important even where the model's output never appears in a diagnostic report.

Australia uses a similar intended-purpose test, but the regulator and register are different. Australia's Therapeutic Goods Administration (TGA) says software and AI are regulated as medical devices when they meet the medical-device definition, including software intended to diagnose, monitor, treat or manage disease. The TGA identifies the Therapeutic Goods Act 1989 and the Therapeutic Goods (Medical Devices) Regulations 2002 as the legislative basis. A developer or sponsor should check the TGA's classification material and the Australian Register of Therapeutic Goods (ARTG) requirements before supply. A product listed in another market is not automatically listed in Australia.

These examples give buyers a concrete comparison. The United States centers the change plan within an FDA marketing submission; the United Kingdom asks the supplier to work through MHRA software and AI classification and conformity guidance; Singapore combines HSA registration and lifecycle guidance with a health-sector AI framework; Australia applies its own statutory definition and ARTG process. None of those routes turns a model score into proof of safe use. Across all four markets, a hospital still needs a local record of intended use, tested inputs, human authority, version changes, incident escalation and the point at which the tool must be paused.

The framework does not establish a worldwide verdict

WHO describes its 2023 publication as a high-level, nonexclusive overview rather than a regulatory framework or policy. IMDRF likewise publishes harmonized principles for jurisdictions to consider; its documents do not authorize a named product, assign liability or replace national and regional rules.

The good machine learning practice principles apply to AI-enabled medical devices, while the clinical-evaluation framework applies to software with a medical purpose. Administrative systems, research tools and patient-facing services may sit outside those scopes, although they still raise data, safety and governance questions.

Evidence also remains bound to the population, setting, inputs, workflow and version that were evaluated. Results from one hospital or dataset cannot establish performance after those conditions change.

APPI News could not find a comparable international dataset showing how many hospitals connect all five stages in routine medical AI use at the time of writing. Published principles describe the records organizations should consider, but they do not measure completion of the full workflow across countries.

A traceable medical AI workflow links a declared use to its data, evaluation, human interaction and deployed version. Monitoring then records whether the same system continues to operate within that evidence and what happened when a signal or software change crossed a preset boundary.