The International Electrotechnical Commission (IEC) published PAS 63621:2026 on March 18, 2026, setting out data-management processes for information used to train, test or validate artificial intelligence (AI) models in medical devices. The specification covers traceability, annotation, representation, privacy, versioning and the data lifecycle, but it stays at a high level and does not set a universal passing score.

The International Medical Device Regulators Forum (IMDRF) published 10 final good machine learning practice principles in January 2025 that call for representative clinical data, independent training and test sets, human-AI evaluation and monitoring after deployment. Together, the two documents place synthetic-data checks inside a larger evidence chain rather than treating statistical similarity as proof that a system is ready for clinical use.

Synthetic resemblance is only the starting point

Synthetic medical data are generated partly or entirely by computational methods instead of being acquired directly from a person. The US Food and Drug Administration (FDA) says its regulatory-science program is studying synthetic data as a way to supplement patient datasets that can be difficult to obtain because of cost, safety limits, privacy restrictions or low disease prevalence. The agency describes a research program, not a clearance route for synthetic datasets.

A generator can reproduce broad distributions while missing the rare feature that matters for a clinical task. A 2024 radiology review by nine FDA researchers distinguishes statistical fidelity from downstream utility and says primary research supporting device safety and effectiveness would continue to come from a robust test set of real patients. The paper is limited to radiological imaging and is not binding US FDA guidance.

A separate APPI News explainer covers how synthetic medical data are generated and why fidelity, privacy and recursive training need different tests. The broader implementation framework covers intended use, evidence, interoperability, human control and monitoring for medical AI. The five checks below connect those two stages for hospital review.

Five checks connect generated data to clinical evidence

Check 1: Record provenance and population coverage

A validation file first needs to identify the records, simulations or knowledge models behind the generator. It can name the source populations, care settings, equipment, collection dates, inclusion rules, labels, missing-data treatment, generator version and transformations applied after generation. Separate entries can identify groups, conditions or acquisition settings that the source did not cover.

The IEC specification's public summary includes dataset classification, annotations, traceability, metadata, representativeness and validity periods in its data-lifecycle scope. The IMDRF principles similarly call for training, testing and monitoring datasets that represent the intended patient population, use environment and measurement inputs. A large generated dataset cannot add evidence for a group that was absent from its source without an independently supported method for creating and testing that group.

A clinical data team reviews source records and population coverage on a screen (illustrative image)

Check 2: Isolate training from the clinical test

Independence has to be checked at the patient, site and acquisition level. A random row split can still leak information when several records belong to one patient, when synthetic examples derive from people in the test cohort or when the same hospital and device settings dominate both sides. The provenance record needs to follow the original data into the generator, the AI training set, model tuning and the final test set.

The IMDRF principles say training and test datasets should remain appropriately independent and that dependence related to patients, sites and data acquisition must be addressed. They also say the extent of external validation should be proportionate to risk. For radiology, the FDA-authored review says a robust real-patient test set would remain the primary evidence for safety and effectiveness even when synthetic data support development or supplementary testing.

A validation diagram separates synthetic training data from an independent clinical test set (illustrative image)

Check 3: Match the metrics to the clinical task

The US FDA says classification, estimation, image segmentation, time-to-event analysis and abnormality detection can require different performance measures, while label uncertainty and the way outputs are presented can change which measures are suitable. That rules out one accuracy score as a universal acceptance test.

The intended decision sets the test design. A classification review can report error types at the operating threshold and results for prespecified groups, while an image-segmentation review needs a reference standard that matches the clinical use. A text system needs tests for whether its output can be checked in the available workflow and whether unsupported content is detected before it reaches a decision.

Synthetic-data fidelity, downstream utility, clinical performance and privacy answer separate questions. Similar distributions do not show that a model performs on new patients, and good task performance does not establish that the generated records protect their sources. Each claim needs its own method, test population and uncertainty estimate.

Check 4: Test the interface and the human-AI workflow

Joint principles from the US FDA, Health Canada and the United Kingdom's Medicines and Healthcare products Regulatory Agency say device information should cover intended users, populations, inputs, outputs and workflow effects, and they list local acceptance testing among good practices. They also call for known data gaps, failure modes and model changes to be communicated when users need that information.

A hospital test can follow a result from patient selection through data retrieval, model output, human review and the final record. It can measure whether identifiers, units, timestamps and missing values arrive intact; whether latency fits the use; whether users see limitations; and whether an unusable result follows a defined fallback path. This assesses the human-AI team rather than the model in isolation.

Health Level Seven International (HL7) defines Fast Healthcare Interoperability Resources (FHIR) as a standard for electronic health-information exchange built from modular Resources that can be combined for specific uses. A successful FHIR exchange does not by itself show that local codes, units, permissions or clinical context were mapped correctly, and it says nothing about the model's clinical performance. Those require interface and clinical acceptance tests.

A clinical IT team reviews FHIR mappings and a medical AI evidence checklist (illustrative image)

Check 5: Monitor drift and control model changes

The IMDRF's final principle calls for ongoing monitoring in real-world use and controls for retraining risks such as overfitting, unintended bias and degradation caused by dataset drift. A monitoring record can identify the deployed model and data versions, baseline performance, review schedule, alert thresholds, investigation owner, stop condition and rollback version. The same record needs to distinguish a data-pipeline change from a model update.

The World Health Organization's 2021 evidence framework is intended to guide developers, researchers, policy-makers and implementers from AI medical-device development through post-market surveillance. It does not establish one monitoring interval or change rule for every country. Regulatory status, reporting duties and authorization for product changes still have to be checked in each market.

A hospital dashboard tracks medical AI model versions, performance and data drift (illustrative image)

The evidence package has to tell one consistent story

The five-check sequence is an APPI News synthesis, not an IEC or IMDRF certification scheme. A procurement file can turn it into a connected set of deliverables: the intended-use statement, source-data and generator records, an independent clinical evaluation, task-specific results, interface mappings, a workflow test, and monitoring and change-control plans. Each item needs to describe the same population, inputs, output, setting and model version.

This separation gives reviewers several stopping points. A dataset can fail its provenance review before integration work begins; a model can pass a benchmark but fail on an independent site; and a valid model can still be held back by an interface that loses units or a workflow with no fallback. Passing one check cannot compensate for missing evidence at another.

The cited documents do not provide a universal numeric threshold for synthetic-data quality. APPI News also could not find a comparable international dataset showing how many hospitals require all five checks in routine procurement at the time of writing. The framework therefore describes an evidence structure, not current adoption or proof that a particular system is safe, effective or authorized in any country.

Synthetic data can reduce some barriers to model development, rare-case simulation and standardized testing. It does not remove the need to establish provenance, test on independent clinical evidence, verify the real workflow and watch the deployed version for change. A hospital can accept synthetic data for a defined role without treating the dataset as a substitute for the rest of the clinical evidence.