Regulations last checked for updates: Sep 20, 2026

Title 21 - Food and Drugs last revised: Dec 18, 2026
§ 870.2380 - Cardiovascular machine learning-based notification software.

(a) Identification. Cardiovascular machine learning-based notification software employs machine learning techniques to suggest the likelihood of a cardiovascular disease or condition for further referral or diagnostic follow-up. The software identifies a single condition based on one or more non-invasive physiological inputs as part of routine medical care. It is intended as the basis for further testing and is not intended to provide diagnostic quality output. It is not intended to identify or detect arrhythmias.

(b) Classification. Class II (special controls). The special controls for this device are:

(1) Clinical performance testing must demonstrate that the device performs as intended under anticipated conditions of use. The following must be met:

(i) Clinical validation must use a test dataset of real-world data acquired from a representative patient population. Data must be representative of the range of data sources and data quality likely to be encountered in the intended use population and relevant use conditions in the intended use environment. The test dataset must be independent from data used in training/development and contain sufficient numbers of cases from important cohorts (e.g., demographic populations, subsets defined by clinically relevant confounders, comorbidities, and subsets defined by hardware and acquisition characteristics) such that the performance estimates and confidence intervals of the device for these individual subsets can be characterized for the intended use population and acquisition systems (e.g., acquisition hardware or preprocessing software). Study protocols must include a description of the adjudication process(es) for determining ground truth of training and test datasets;

(ii) Data must be provided within the clinical validation study or using equivalent datasets to demonstrate the consistency of the output over the full range of inputs;

(iii) Performance goals used to determine success of clinical validation must be justified in the context of risks associated with follow-up testing;

(iv) Objective performance measures (e.g., sensitivity, specificity, positive predictive value or negative predictive value) must be reported with relevant descriptive or developmental performance measures. Summary level demographic information and sub-group analyses must be provided for each study site, relevant demographic sub-groups, and acquisition systems; and

(v) The test dataset must include a minimum of three geographically diverse sites, separate from sites used in training of the model.

(2) Software verification, validation, and hazard analysis must be performed. Software documentation must include:

(i) A description of the model/algorithm, algorithm inputs/outputs, and supported patient population;

(ii) Integration testing in the intended software system or software environment; and

(iii) A description of the expected impact of all applicable sensor acquisition hardware characteristics on performance and any associated hardware specifications, including:

(A) A description of input signal/data quality control measures; and

(B) A description of all mitigations for user error or failure of any subsystem components (including signal detection, signal analysis, data display, and storage) on output accuracy.

(3) Human factors assessment of the intended users in the intended use environment must evaluate the risk of misinterpretation of device output.

(4) Labeling must include:

(i) A summary of the performance testing methods, tested hardware, tested/supported patient population, results of the performance testing for tested performance measures/metrics, summary-level descriptions of patient demographics and associated subgroup analyses for training and test datasets, and the expected minimum performance of the device;

(ii) Device limitations or subpopulations for which the device may not perform as expected;

(iii) Warning that the user should not rely on the lack of a suspected finding to rule out follow-up;

(iv) A statement that the device output should not replace a full clinical evaluation of the patient and that the output may not be sufficient as the sole basis for further testing;

(v) Warnings identifying sensor acquisition factors that may impact measurement results;

(vi) Guidance for interpretation of the measurements and typical follow-up testing; and

(vii) The type(s) of hardware sensor data used, including specification of compatible sensors for data acquisition.

[91 FR 57787, Sept. 11, 2026]
authority: 21 U.S.C. 351,360,360c,360e,360j,360
source: 45 FR 7907, Feb. 5, 1980, unless otherwise noted.
cite as: 21 CFR 870.2380