HTI-1 (final 2024) introduced the Decision Support Intervention criterion requiring source attributes and intervention risk management for predictive models in certified EHRs. HTI-2/HTI-3 extend transparency, interoperability, and information-blocking requirements. HTI-1 requires certified health IT developers that supply predictive decision support to give users access to source attributes, such as intended use, training data details and performance, and to apply risk management practices. It also set the USCDI v3 standard. HTI-2, finalized in parts in 2024, added public health and payer-related certification criteria. These rules apply to EHR and health IT developers, which can include MedTech companies selling software into hospitals.

Why it matters

Even non-EHR vendors are affected: model 'nutrition labels' are increasingly expected by HDOs procuring AI-enabled tools.

Common pitfalls

•Misconception: These rules only apply to EHR vendors, but any developer whose software integrates with or provides data to certified EHRs may be indirectly affected.
•A common pitfall is failing to adequately document the 'source attributes' of predictive models, which can lead to non-compliance during certification.
•Overlooking the necessity of a robust intervention risk management plan for all decision support interventions is a frequent error.
•Assuming that existing risk management processes are sufficient without specifically addressing the unique risks of AI-driven interventions can lead to gaps.
•Failure to keep up with subsequent ONC rules, such as potential HTI-2 or HTI-3 updates, could lead to outdated compliance strategies.

Sources

ONC HTI-1 · ONC
FDA - Software as a Medical Device (SaMD) · FDA
FDA - AI/ML-Enabled Medical Devices · FDA

Open full page

Select term B to compare.

Why compare MedTech terms side by side?

MedTech terminology is full of pairs that look interchangeable but carry very different regulatory, clinical, and commercial consequences. Picking the wrong framework, pathway, or standard early in a project can add months to a submission, invalidate clinical evidence, or trigger an audit finding. Side-by-side comparison is the fastest way to surface those differences before they become costly mistakes.

Each comparison on this page pulls from the same vendor-neutral, sourced definitions used throughout the MedTech Terms glossary. You see the one-line summary, the formal definition, why it matters in practice, common pitfalls, and the primary sources (FDA guidance, EU MDR/IVDR articles, ISO/IEC standards, MDCG documents, IMDRF principles) that back each entry. That makes the comparison defensible in regulatory strategy memos, design reviews, and submission narratives.

Common comparison patterns

Regulatory pathway choice - 510(k) vs PMA, 510(k) vs De Novo, Abbreviated vs Special 510(k).
Quality systems - QSR vs ISO 13485, QMSR vs QSR.
Software classification - SaMD vs SiMD, Locked vs adaptive AI.
EU frameworks - MDR vs IVDR, CE Mark vs UKCA.
Cybersecurity artifacts - SPDX vs CycloneDX SBOM, CVE vs CVSS.
Post-market actions - Recall vs field action, Removal vs correction.

How to use this tool

Pick term A and term B from the dropdowns, or click a preset above. The URL updates with both slugs so you can bookmark or share the exact comparison with a colleague, a notified body reviewer, or your regulatory consultant. Click Open full page on either side for the complete entry, including FAQs, related terms, and the full citation list. If you are not sure which term to start with, browse the Categories view or the A-Z index.

MedTech Terms is a vendor-neutral community resource sponsored by Blue Goat Cyber. Definitions are written for educational use and are not legal or regulatory advice.