Cruxi
FDA record research
The 2021–2025 analysis contains 1 selected substantially-equivalent FDA decisions under primary product code SAT. Use it to compare documented submissions and evidence with your product. A separate 2026 update contains 2 decisions through 2026-09-27. The latest selected decision across the acquired endpoint is dated 2026-08-21. Neither set establishes a suitable predicate or the route for your device. The complete-year window has 1 decisions; the separate all-observed-date count is 3. These denominators describe different date ranges.
Evidence retrieved 2026-10-07. Source versions and topic-specific limits are listed below.
An exact FDA-record regulation_number match to one acquired Title 21 section. Records with the same normalized scope definition, class, regulation and recorded submission/GMP flags are grouped. Sparse definitions and generic exemption boilerplate do not qualify. No text-similarity equivalence or legal applicability is inferred.
Pulmonary hypertension machine learning-based notification software employs machine learning techniques to suggest the likelihood of pulmonary hypertension for further referral or diagnostic follow-up.
Compare the proposed indication, user, anatomy, technology and operating principle with this actual scope; record differences and unresolved facts.
§ 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]
Read the identification, classification, conditions and referenced limitations in the cited section. A numeric reference match is not a buyer classification or exemption determination.
Historical FDA comparison
All statistics in this section use decisions dated 2021-01-01 to 2025-12-31. The partial 2026 update below is excluded from these distributions.
There are 1 valid recent date pairs. Distribution summaries require at least 20; older records are not substituted for a current benchmark.
Statistical source: FDA openFDA 510(k) decision dataset. Partition 1 Download the identified records and dates (CSV).
Deduplicate by official submission ID across the complete current manifest partitions. Select exact primary product code, K-number format and the stated SE decision codes with valid dates. Recent distributions use the five complete calendar years preceding the latest valid endpoint decision year. Partial-year counts compare equal January-to-cutoff periods. Quartiles use linear interpolation at (n-1)*p and are withheld below 20 valid date pairs. The analysis n describes only its declared complete-year window; selected_se_n separately counts all selected recorded dates through the cutoff.
3 selected records across all observed dates; 0 other/invalid identifier or decision-date records excluded. 0 missing or invalid date pairs in the five-year window.
Date fields: date_received → decision_date. Quantiles: Hyndman–Fan type 7: linear interpolation at (n − 1) × p; displayed to one decimal; n ≥ 20 valid pairs.
Receipt-to-decision calendar elapsed time includes time outside active FDA review; it is not FDA review time, a promised project timeline or an estimate of future clearance. This selected recorded cohort does not include all applications or establish a success probability, predicate suitability, market size, current market availability or legal authorization for another product.
Calculation fda-buyer-research-3 · database cutoff 2026-09-27. CSV rows identify each official K-number, cohort, date pair, exclusion reason and source version.
Separate partial-year update
2 selected decisions from 2026-01-01 to 2026-09-27. The equivalent previous-year period contains 0 decisions through 2025-09-27. These counts describe the records; they are not market growth or submission success rates.
Named records to investigate
These dated records may come from 2026 or earlier years. They are a separate investigation list, not the five-year statistical cohort. Compare the actual indications and technology before considering a record as a comparator.
| Official record / device | Recorded applicant | Decision | Recorded type | Calendar days |
|---|---|---|---|---|
| K253699 ↗Tempus ECG-PH | Tempus AI, Inc. | 2026-08-21 | Traditional | 270 |
| K252360 ↗ECG-AI Pulmonary Hypertension (PH) 12-Lead algorithm (1020) | Anumana, Inc. | 2026-03-28 | Traditional | 242 |
| K233666 ↗CorVista System with PH Add-On | Analytics For Life, Inc. | 2024-04-05 | Traditional | 142 |
Supporting documents actually acquired
Read the source context, then compare the evidence with your design. Topic locations below are text matches, including possible limitations or negative statements; they are not a mandatory test list.
The documents are a bounded sample of acquired summaries, not complete evidence coverage of the cohort.
Known context: US. Match the intended use and design with the recorded category before treating it as applicable.
| Source fact | Recorded value |
|---|---|
| FDA product code | SAT [1] |
| Generic device category | Pulmonary Hypertension Machine Learning-Based Notification Software [1] |
| Recorded scope | Pulmonary hypertension machine learning-based notification software employs machine learning techniques to suggest the likelihood of pulmonary hypertension for further referral or diagnostic follow-up. [1] |
| Recorded class | 2 [1] |
| Regulation | 870.2380 [1] |
| Medical specialty | Cardiovascular [1] |
Use this checklist to gather your business or product details before speaking with a specialist. The items below explain what to record and suggest useful supporting documents. You can add your own answers in the editable project brief.
Put your proposed label and design beside the quoted definition. Record matching facts, differences and missing facts separately; naming the category alone cannot resolve scope.
Useful evidence: Proposed indication/design and a definition-to-product comparison with source locators.
Record the applicable paragraph, conditions and cross-referenced limitations after specialist review. Keep a claimed exemption separate from actual establishment, listing and quality-system responsibilities.
Useful evidence: Dated classification/route rationale and the current provisions relied on, with unresolved conditions.
Choose a named record above. Put your proposed claim beside its actual indications-for-use statement. Record different patients, users, anatomy, settings and output claims; do not treat a shared code as proof of equivalence.
Useful evidence: Your draft indications for use + the selected official summary and its exact page.
For each comparison, record the different materials, hardware, software functions and operating conditions. Link each difference to existing evidence or an unresolved evaluation task.
Useful evidence: A three-column matrix: comparator fact / your design fact / evidence or unresolved gap.
This recent cohort has fewer than 20 valid date pairs, so it supplies no median or percentile benchmark. Ask for a schedule based on actual preparation, evidence gaps, interactions and response assumptions; keep any historical decision context separately dated.
Useful evidence: Document/test readiness, unresolved route/evidence tasks and the assumptions behind the specialist’s proposed sequence.
Read the official document in context. The audit details identify the precise locators and preserved versions used for this page.
2026-10-05 · retrieved 2026-10-06
Source key D01 · snapshot 936de5f5d47b9293b702fc32512a79173969fb788c74a63d9b91abe73f3b86a5
Fri, 04 Sep 2026 11:20:33 GMT · retrieved 2026-10-06
Source key D02 · snapshot 8a3173875d12b27cb0365a12336fc101fbf0f270983e1f67e59008a279087dc1
2026-10-05 · retrieved 2026-10-06
Source key D01 · snapshot 5a86994ba49a37e71e09be96803fd51981c6c43eaa96caab41aea2b188bfe002
Tue, 07 Apr 2026 11:06:17 GMT · retrieved 2026-10-07
Source key D02 · snapshot ee5db5e40c998381b57af75a27383a846a856b2f83f9c7f903e5121ae87911f6
Sat, 06 Apr 2024 16:41:32 GMT · retrieved 2026-10-07
Source key D02 · snapshot a23d480832e3c82496e05cc9ae555fa40af105af67c755cf55b5f326908fc1c6
Thu, 01 Oct 2026 22:01:48 GMT · retrieved 2026-10-06
Source key D04 · snapshot 2fb992918a3879de132b47a33c856da2b3234ee3d96cfd79fab03acf30512496
Confirm the facts, scope and contact preference before sharing your project. Preparing this page sends no provider outreach.
Compare FDA 510(k) Submission Services
Find FDA US Agent Services | Compare & Get Quotes · FDA QMSR Transition & Inspection Readiness (ISO 13485 Alignment)