Healthcare software used in US clinical settings must meet one or both of two primary regulatory requirements: ONC health IT certification for electronic health records and clinical IT, and FDA 21 CFR Part 820 for medical devices, and software as a medical device (SaMD). Products such as healthcare analytics solutions that support clinical decision-making may fall under ONC certification criteria, while diagnostic or monitoring software is subject to FDA regulation. The CHPL certified health IT product list at HealtHit is a publicly accessible registry displaying certified products after completing the ONC certification process.
What is ONC and why is it important for healthcare information technology?
The Office of the National Coordinator for Health Information Technology (ONC) is a federal agency within the U.S. Department of Health and Human Services (HHS) responsible for promoting the adoption and interoperability of healthcare information technology (HIT) across the U.S. healthcare system. ONC was created within HHS, and its authority was significantly expanded by the HITECH Act (2009) and the 21st Century Cures Act (2016).
Through HealthIT, ONC manages the ONC certification program, sets interoperability standards, including HL7 FHIR, regulates health information exchange (HIE) policies, and oversees ONC health IT certification for products including care delivery management solutions. Developers creating products for federal programs must understand ONC requirements products that fail to demonstrate compliance with ONC certification criteria may be excluded from Medicaid/Medicare programs to promote interoperability. Unlike FDA 21 CFR Part 820, ONC certification does not rely on product review, but rather on market access and eligibility for federal reimbursement.
Partner with Elinext to create a compliant foundation before development begins
The ONC Health IT Certification Program
The ONC certification program is a formal framework through which healthcare IT infrastructure products, including electronic health records (EHRs), clinical documentation systems, and population health management platforms, are assessed for compliance with published healthcare software standards. ONC health IT certification is achieved through a two-step process: Accredited Testing Laboratories (ATLs) conduct technical testing, and ONC Authorized Certification Bodies (ONC-ACBs) issue formal certifications. Certified products are publicly listed on the CHPL.
The program currently operates according to the 2015 edition of the certification criteria, which set requirements for interoperability, privacy, and clinical functionality. Healthcare IT consulting services often help vendors prepare for certification by conducting gap analyses and readiness assessments. ONC does not directly test or certify products; it accredits bodies that do. Products used in federally funded clinical settings are expected to have a valid ONC certification in health information technology.
1. Who Needs ONC Certification and When
Understanding health IT developer requirements ONC sets is essential before development begins. ONC health IT certification is voluntary by law but in practice, most enterprise health system buyers contractually require it, and federal reimbursement programs including Medicaid and Medicare Promoting Interoperability mandate a certified EHR.
Internal tools with no external clinical data exchange and pure billing software without EHR functions generally do not require ONC certification. Unlike FDA 21 CFR Part 820, ONC certification does not require full product coverage and partial certification is permitted, meaning only relevant modules need to be certified. Developers can verify which products currently hold certification at the CHPL public registry.
2. The 60 Certification Criteria Across 8 Categories
Just as ERP implementation requires mapping business processes to system modules, ONC certification maps 60 technical criteria across 8 categories each representing a specific functional or security requirement the product must meet. Applying ERP best practices to certification planning means treating each criterion as a trackable backlog item.
The 8 categories under the 2015 Edition are:
- Clinical Processes: core clinical documentation, medication management, and clinical decision support
- Care Coordination: referral management, care planning, and transitions of care
- Clinical Quality Measures: recording, calculating, and reporting standardized quality measures
- Privacy and Security: authentication, access controls, auditing, and encryption
- Patient Engagement: patient portals, view/download/transmit capabilities, and patient-generated data
- Population Health: reporting tools, immunization registry integration, and syndromic surveillance
- Interoperability: HL7 FHIR APIs, CCDA document exchange, and USCDI data support
- Electronic Prescribing E-prescribing including controlled substance prescribing capabilities
3. The Certification Process: From Testing to CHPL Listing
ONC certification of health information technology products occurs in three stages, structurally distinct from the FDA’s procedures. Unlike the jurisdictional disputes and quality management system structure under FDA 21 CFR Part 820 and ISO 13485, ONC’s process is linear and product-specific.
Stage 1 – Testing: An Accredited Testing Laboratory (ATL) tests the product for compliance with defined certification criteria. Currently, accredited ATLs include Drummond Group and ICSA Labs (check the current list of accredited labs at HealthIT).
Stage 2 – Certification: An ONC Authorized Certification Body (ONC-ACB) reviews the ATL results and issues an official certificate.
Stage 3 – Inclusion in the CHPL Registry: The certified product appears in the publicly accessible CHPL Registry at HealthIT.
Healthcare IT compliance with ONC standards for health information technology requires advance planning; the full process typically takes several months, depending on the number of criteria being assessed. Partial certification (certification of only the relevant modules) is permitted and can reduce the timeframe.
What Is FDA 21 CFR Part 820?
FDA 21 CFR Part 820 is a Quality System Regulation (QSR) establishing mandatory requirements for the design, manufacture, and maintenance of medical devices sold in the United States, as codified in the Code of Federal Regulations (CFR).
Unlike ONC certification, which is market-driven, FDA 21 CFR Part 820 has full legal effect and non-compliance can result in FDA warning letters, product recalls, or a ban on sales in the U.S. market. The regulation applies to all medical device manufacturers, including developers of SaMD (software as a medical device), such as clinical decision support tools and diagnostic image analysis software. Each manufacturer covered by this regulation must maintain a formal quality system regulation medical device documented through controlled documentation.
The FDA 21 CFR Part 820 vs ISO 13485 comparison is frequently relevant for healthcare software development services teams working in international markets. The FDA actively audits manufacturing facilities for quality management system compliance.
Both standards address quality management systems for medical devices, but they have different scopes, purposes, and regulatory contexts. The main differences include:
- FDA 21 CFR 820 is obligatory, while ISO 13485 is optional;
- FDA 21 CFR 820 is specific to the United States;
- ISO 13485 adheres to a modernized structure, whereas FDA 21 CFR 820 has maintained the same format since 1997;
- FDA 21 CFR 820 is solely developed by the FDA, whereas ISO 13485 was created through collaboration;
There is a planned effort by the FDA to align the Quality System Regulation (QSR) with ISO 13485.
One of the challenges we constantly encounter whether in laboratory management system development services or in broader healthcare IT work is that teams discover ONC health IT certification requirements or FDA 21 CFR Part 820 obligations after the architecture has been defined. Implementing a document management system, design history files, or APIs to ensure compatibility in a released product is much more expensive than developing them from scratch. Regulatory compliance should be part of Sprint 0, not Sprint 60.
Key Requirements of FDA 21 CFR Part 820
FDA 21 CFR Part 820 defines several healthcare software standards that medical device manufacturers, including SaMD developers, must implement as mandatory quality control measures. These key requirements shape development practices differently than the typical health IT developer requirements ONC certification imposes:
- Design Control (21 CFR 820.30): Formal documentation of design inputs and outputs, reviews, verification, validation, and handover.
- Documentation Control: All quality documents must have a version control system, approval workflows, and defined retention periods.
- Corrective and Preventive Actions (CAPA): A formal system for investigating, correcting, and preventing quality issues.
- Post-Market Surveillance and Complaint Handling: A documented system for monitoring device performance after release and reporting adverse events to the FDA.
- Procurement Control: Suppliers and components used in device production must be qualified.
- Manufacturing and Process Control: Manufacturing processes must be validated and controlled.
Each requirement entails the creation of formal documentation, which must be stored in an accessible quality management system, not simply in a code repository.
1. Design Controls (21 CFR 820.30)
Design Controls under 21 CFR Part 820 software requirements (21 CFR 820.30) are one of the most challenging FDA 21 CFR Part 820 provisions for software development teams to implement correctly. A Design Control is the formal system that ensures a medical device including software is developed in a controlled, documented, and traceable manner from initial requirements through release.
It encompasses: design inputs (what the product must do), design outputs (how it does it), design reviews (formal checkpoints), design verification (does it meet the specification?), and design validation (does it meet actual user needs?).
The critical distinction:
- Design verification confirms the software was built correctly per spec
- Design validation confirms it was the right thing to build
For SaMD developers: A Jira backlog is not a Design Control system. FDA requires a separate, formal Design History File (DHF) with controlled documentation. This is a structural requirement, not a process suggestion.
2. Document Controls and Quality Management Records
Document Controls under the quality system regulation medical device framework (21 CFR Part 820) require that every document affecting device quality is formally controlled and meaning it has an approved version, a change history, an owner, and a defined retention period.
Two key document types must not be confused:
- Device Master Record (DMR): Contains the instructions for building the device (specifications, drawings, procedures)
- Quality Management Records (QMR): Document that those procedures were followed (test results, training logs, audit reports)
Unlike ONC health IT certification, which focuses on functional capabilities tested by an ATL, Part 820 document control focuses on the organization’s internal quality processes.
Critical practical note for software teams: Git version control is not equivalent to Part 820 document control. A separate, validated QMS system with formal approval workflows and access controls is required. Source control and QMS document control must coexist.
3. Corrective and Preventive Action (CAPA)
Corrective and Preventive Action (CAPA) is a required Part 820 quality process that is among the most scrutinized during FDA inspections. Unlike ONC certification criteria, which focus on feature functionality tested at an ATL, CAPA is an internal quality management obligation.
- Corrective action: Addresses an identified problem root cause analysis, fix implementation, and effectiveness verification.
- Preventive action: Addresses a potential problem before it occurs, based on trend analysis and risk assessment.
Why does the FDA focus on CAPA so intensely? Because an immature CAPA system signals that quality problems are handled reactively rather than systematically and a red flag for device safety. For ONC health IT certification holders who also have SaMD in their portfolio, maintaining separate CAPA processes per regulatory framework is necessary.
Practical reality for developers: A bug report in Jira does not constitute a CAPA. A CAPA requires formal documentation: problem statement, investigation, root cause, corrective action, verification of effectiveness, and closure record.
4. Post-Market Surveillance and Complaint Handling
Post-market surveillance and complaint handling under the quality system regulation medical device framework is a mandatory healthcare IT compliance obligation for all SaMD manufacturers and one that software teams routinely underestimate.
The FDA defines a “complaint” as any written, electronic, or oral communication alleging deficiencies in the identity, quality, durability, reliability, safety, efficacy, or performance of a device after its release. This definition is much broader than a typical customer service ticket.
Under the Medical Device Reporting (MDR) requirements (21 CFR Part 803), manufacturers must report to the FDA instances where a device may have caused or contributed to serious injury, illness, or death within 30 days (or 5 days in emergency situations).
Practical Implications: if your SaMD has a customer service team, these tickets are regulatory documents. Each complaint must be assessed for reportability under the MDR, and the investigation must be documented in the quality management system (QMS). The lack of an adequate complaint handling system is a common finding in FDA 483 inspection reports.
Elinext helps teams create compliant architectures before writing a single line of code.
The 2024 Update — FDA 21 CFR Part 820 Aligning with ISO 13485
In a significant update to regulatory requirements related to healthcare IT compliance both in the US and internationally, the FDA published a final quality management system rule (QMSR) in the Federal Register on February 2, 2024, replacing the legacy 21 CFR Part 820 structure with a structure aligned with ISO 13485:2016.
The effective date is February 2, 2026, providing a two-year transition period for manufacturers to adapt their quality management systems.
Key structural changes: The legacy 21 CFR Part 820 used a prescriptive format specific to the US; the new QMSR adopts the process structure of ISO 13485:2016 while retaining FDA-specific requirements such as the design history file and CAPA documentation.
- Company Situation: Already ISO 13485:2016 certified
Impact: Path to U.S. market compliance is meaningfully simplified - Company Situation: Operating under old Part 820 only
Impact: QMS adaptation required before February 2026
Unlike the ONC certification program, which operates on an ongoing basis, the transition to QMSR has a strict compliance deadline.
FDA 21 CFR Part 820 vs ISO 13485
FDA 21 CFR Part 820 vs. ISO 13485 regulates quality management systems for medical device manufacturers, but they differ significantly, which is important for developers creating products for the US market.
With the QMSR update in 2024, the structural gap between the two systems has narrowed significantly; ISO 13485:2016 now serves as the foundational framework for the new QMSR. However, ISO 13485 certification does not replace compliance with FDA 21 CFR Part 820 for the US market. FDA registration, inclusion in the facility registry, and full compliance with QMSR requirements remain mandatory legal obligations in the US.
ONC certification criteria address completely different aspects (compatibility, clinical functionality) and operate in parallel with, not instead of, Part 820 obligations.
| Parameter | FDA 21 CFR Part 820 (QMSR) | ISO 13485:2016 |
|---|---|---|
| Jurisdiction | USA (required for US market) | International (80+ countries) |
| Legal status | Mandatory (US federal law) | Voluntary (standard, not law) |
| Who applies | FDA (inspections, enforcement) | Certification bodies (audit) |
| Structure (until 2024) | Separate US-specific format | Modern QMS format |
| Structure (after 2024) | Aligned with ISO 13485 | ISO 13485:2016 |
| Applicability to SaMD | Apparently extends to SaMD | Applicable, requires interpretation |
| Penalties for non-compliance | Warning Letter, recall, sales ban | Loss of certificate |
| Mutual recognition | Yes, after 2024 update (partial) | Accepted in EU, Canada, Japan |
The Elinext team will develop an action plan for you that addresses all 60 criteria. Get started with a free consultation to determine the scope of work.
What These Standards Mean for Healthcare Software Developers
For healthcare software developers, the ONC certification program and FDA 21 CFR Part 820 define the basic compliance requirements for market entry. Appearing on the CHPL certified health IT product list is a procurement prerequisite for many enterprise buyers of medical systems, while FDA Part 820 compliance is a legal requirement for SaMD not a hallmark, but a condition for market entry. Developers should determine which regulatory framework applies before writing the first line of product code.
1. Determine Which Standard Applies to Your Product
Determining which regulatory framework applies to your product is the first and most important technical decision in healthcare software development. The boundaries are typically as follows:
| Product Type | Applicable Framework |
|---|---|
| EHR / clinical documentation software | ONC certification |
| Software that diagnoses, treats, or monitors patients (SaMD) | FDA 21 CFR Part 820 (mandatory) |
| EHR with integrated clinical decision support meeting SaMD definition | Both ONC + Part 820 |
For applying the requirements of 21 CFR Part 820 to software, the starting point is the FDA guidance “Software as a Medical Device,” available on FDA.gov, which proposes a risk-based classification approach.
Before finalizing the regulatory path, a qualified regulatory consultant or attorney specializing in medical devices should evaluate the product’s intended use and clinical function. Attempting to make this decision without regulatory expertise is a recognized risk factor for delaying market entry.
2. Build a Quality Management System Early
The most frequently cited lesson from medical software development teams that have successfully met FDA 21 CFR Part 820 requirements is this: build a quality management system alongside the product, not afterward.
A quality management system for SaMD includes three core components that should be active from the very beginning of development:
- Design History File (DHF) – a continuously updated, controlled record of all design decisions, specifications, reviews, and validations for the device;
- CAPA Process – a formal corrective and preventive action workflow separate from the development issue tracking system;
- Document Control – a system for version control and quality document management within the approval workflow, separate from Git or Confluence.
eQMS platforms such as Greenlight Guru and Qualio (not endorsed) are specifically designed to manage a quality management system for medical devices and integrate design control, CAPA, and documentation control within a validated platform. Engage ONC-certified consultants or regulatory affairs specialists during the scoping phase, not after initial FDA review.
For development teams seeking ONC or FDA compliance, our healthcare software development practice includes regulatory compliance preparation as part of the scoping process.
3. Plan for ONC Certification as a Project, Not a Feature Content
ONC Health IT Certification isn’t just a checkbox to add at the end of development, but a project within your project, with its own backlog, milestones, and external dependencies.
The 60 certification criteria across 8 categories represent specific functional requirements: each criterion defines precisely what a product must do to pass ATL testing. They should be included in the product backlog as high-priority tasks, not added as post-release work.
Some criteria, particularly in the Interoperability category, require specific decisions about API architecture: HL7 FHIR endpoints and USCDI data support cannot be easily integrated into an incompatible data model.
Participation in ATL itself takes time Drummond Group and ICSA Labs have testing queues, and the entire process from initial ATL participation to CHPL listing typically takes several months to over a year. If only some of the ONC certification criteria are relevant to your product, partial certification is possible, but must be clearly stated in the project plan.
This results in product inclusion on the CHPL list, making certified products unique and distinguishing them in competitive tenders for large medical institutions.
In both pharmaceutical software development services and healthcare IT, we see the same pattern: regulatory compliance is treated as an afterthought rather than a fundamental architectural constraint. By the time a team realizes that its data model doesn’t support USCDI or that its change management process doesn’t comply with Part 820 documentation standards, the cost of remediation is significantly higher than it would have been at the design stage. Regulatory readiness must be ensured at stage 0 of development.
Key Takeaways
- ONC certification in healthcare IT is performed by accredited testing laboratories (ATLs) and ONC-authorized certification bodies (ONC-ACBs), resulting in inclusion on the CHPL list — voluntary by law, but de facto mandatory for electronic health records used in federal programs.
- FDA 21 CFR Part 820 (Quality System Rules/QMSRs) is mandatory for manufacturers of medical devices in the US, including software as a medical device (SaMD), and carries consequences such as warning letters and product recalls.
- In 2024, the FDA completed the harmonization of 21 CFR Part 820 with ISO 13485:2016, significantly narrowing the structural gap between US regulations and the international standard.
- FDA 21 CFR Part 820 and ISO 13485 serve the same purpose, managing the quality of medical devices, but differ in their legal status (mandatory or voluntary) and jurisdiction (US or international).
- Healthcare software developers should determine the applicable framework before beginning development, refining ONC certification criteria or FDA design rules is significantly more expensive than implementing them from the start.
Conclusion
Healthcare software compliance systems will only expand and become more complex through 2026. ONC health IT certification continues to be the market access standard for electronic health records and clinical IT systems in US healthcare systems and according to ONC’s Health IT Dashboard, by 2024, more than 96% of non-federal acute care hospitals will have implemented ONC-certified electronic health record technologies. Grand View Research projects the global healthcare IT market to exceed $820 billion by 2026, reflecting the scale of digital transformation driven by regulatory compliance.
For specialized systems, including radiology information system development services, laboratory platforms, and diagnostic decision support tools, the overlap between ONC and FDA 21 CFR Part 820 (now QMSR) certification creates a double compliance burden that must be addressed proactively.
Teams that approach regulatory compliance as a foundational architectural element, rather than as a final audit step, consistently achieve faster time to market and lower remediation costs. Elinext’s healthcare software practice supports teams through all stages of ONC and FDA compliance, from initial scoping to CHPL listing and FDA quality management system readiness.
FAQ
-
ONC Health Information Technology Certification is a federal program that evaluates and certifies health information technology products, primarily electronic health records (EHRs), for compliance with published functional, interoperability, and security standards established by the Office of the National Coordinator for Health Information Technology (ONC). The certification process consists of two phases: first, an accredited testing laboratory (ATL) tests the product for compliance with specific criteria; then, an ONC-Authorized Certification Body (ONC-ACB) issues a formal certificate.
As a result, the product is included in the CHPL (Checked Health Information Technology Product List) at healthit.gov/chpl, a publicly accessible registry of all certified products. ONC Health Information Technology Certification primarily applies to EHR developers, developers of EHR modules, and any organization whose product is intended for use in federally funded programs, such as Medicaid and Medicare, that promote interoperability. For example, a hospital system purchasing an electronic health record typically requires CHPL inclusion as a prerequisite for contract award.
-
ONC Certification Criteria are the specific technical, functional, and security requirements that a health information technology product must meet to receive ONC certification under the 2015 version. There are approximately 60 criteria grouped into eight categories, each covering a specific area of healthcare information technology functionality:
- Clinical Processes – Core clinical functions, including medication management and clinical decision support
- Care Coordination – Referral management and care transitions
- Clinical Quality Metrics – Recording and reporting of standardized quality metrics
- Confidentiality and Security – Access control, audit trails, and encryption
- Patient Engagement – Patient portal and data viewing/downloading/transfer capabilities
- Population Health – Immunization registry reporting and syndromic surveillance
- Interoperability – Support for HL7 FHIR APIs, CCDA data exchange, and USCDI data
- Electronic Prescribing – Electronic prescribing of medications, including controlled substances
A current, authoritative list is maintained at HealthIT – always check the exact number of criteria and their names there before planning a certification project. Partial certification is permitted: a product may be certified only against criteria relevant to its specific functionality.
-
FDA 21 CFR Part 820 is a Quality System Regulation (QSR), a legally binding U.S. federal regulation establishing requirements for the design, manufacture, packaging, labeling, storage, installation, and servicing of finished medical devices, including software as a medical device (SaMD). It is codified in Title 21 of the Code of Federal Regulations (CFR).
Compliance with FDA 21 CFR Part 820 is administered by the U.S. Food and Drug Administration (FDA) and is not voluntary; all manufacturers of FDA-regulated medical devices sold in the United States are required to comply, regardless of company size or product type. Beginning in 2024, the structure of Part 820 was updated to align with ISO 13485:2016 through a new Quality Management System Regulation (QMSR), effective February 2, 2026.
This regulation applies to SaMD developer software that meets the FDA definition of a medical device and must comply with the requirements of Part 820/QMSR. For information on applicability to a specific product, please consult a qualified regulatory professional.
-
FDA Section 820 applies to software if the software meets the FDA’s definition of a medical device, namely, if it qualifies as software as a medical device (SaMD), defined as software intended for use in one or more medical purposes without incorporation into a hardware medical device.
Examples of SaMD covered by Section 820 of the U.S. Code of Federal Regulations (FDA):
- Clinical decision support tools that diagnose or treat a specific disease
- Diagnostic image analysis software that identifies abnormalities
- Remote patient monitoring platforms that provide treatment recommendations
Software NOT considered SaMD (not covered by Section 820):
- Administrative functions of electronic medical records (scheduling, billing, documentation)
- Software designed solely for billing and coding
- General communication tools not used for clinical decision making
Important Note: The boundary between SaMD software and non-SaMD software is determined by the intended use of the product and can be ambiguous. Always consult with a qualified regulatory professional before determining the applicability of Part 820.
-
The 21 Code of Federal Regulations (FDA) 2024 update to Part 820 introduced the Quality Management System Rule (QMSR), a structurally revised rule published in the Federal Register on February 2, 2024, that replaces the outdated structure of Part 820 with a new structure aligned with ISO 13485:2016. The effective date of the QMSR is February 2, 2026, giving medical device manufacturers a two-year transition period to update their quality management systems.
Structurally, the changes shift away from the prescriptive, US-specific format of Part 820 toward the ISO 13485 process model, while retaining FDA-specific requirements such as the design history file.
-
ONC health IT certification is obtained through a three-step process governed by the ONC certification program:
Step 1. Preparation and Gap Analysis: Before engaging a testing laboratory, conduct a gap analysis of your product against all applicable 2015 Edition ONC certification criteria (use HealthIT.gov/certification/2015-edition as the reference). Determine whether full or partial certification is needed.
Step 2. ATL Testing: Engage an Accredited Testing Laboratory (ATL) to formally test your product against the selected criteria. Currently accredited ATLs include Drummond Group and ICSA Labs and verify the current complete list at HealthIT.gov, as the accredited body list may be updated. ATL testing schedules fill in advance; plan for lead times of weeks to months per test module.
Step 3. ONC-ACB Certification and CHPL Listing: An ONC-Authorized Certification Body (ONC-ACB) reviews ATL test results and issues the certificate. The product is then listed on the CHPL.
The total timeline from initial gap analysis to CHPL listing typically ranges from several months to over a year, depending on the number of criteria, ATL queue times, and the product’s readiness level.
-
To ensure software compliance with FDA 21 CFR Part 820, a formal quality management system (QMS) structured around four core processes must be implemented. These processes must be established from the very beginning of the product’s lifecycle:
Step 1. Create a QMS: Create a formal, documented quality system that covers all Part 820 requirements. eQMS platforms such as Greenlight Guru or Qualio (not approvals) are designed specifically for medical device quality management.
Step 2. Implement Design Controls from Day One: In accordance with 21 CFR 820.30, every design decision must be formally documented in a design history file (DHF), identifying inputs, outputs, reviews, verification, and validation. Implementing this after development is very expensive.
Step 3. Develop a Corrective and Preventive Action (CAPA) Process: Create a formal corrective and preventive action system separate from your problem tracking system—error reports are not automatically considered CAPA records.
Step 4. Post-Market Surveillance: Implement a documented complaint handling and adverse event reporting process that complies with FDA Medical Device Reporting (MDR) requirements.
When to contact a regulatory consultant: Immediately and before defining the product architecture. Note: The specific compliance plan depends on the device classification (Class I, II, or III) and intended use. Always consult with a qualified regulatory professional for product-specific compliance planning.
-
ONC certification and FDA 21 CFR Part 820 are two distinct U.S. regulatory frameworks that apply to different parts of the healthcare technology stack. They differ in five key ways:
- Scope. ONC certification applies to health IT modules (e.g., EHR functionality, interoperability APIs, data exchange capabilities). FDA 21 CFR Part 820 applies to finished medical devices, covering their full lifecycle: design, manufacturing, labeling, and servicing.
- Applicability. ONC certification is pursued by health IT developers whose software needs to demonstrate compliance with defined certification criteria, often to support customers participating in federal incentive programs. FDA Part 820 applies to manufacturers whose product meets the legal definition of a medical device, regardless of program participation: applicability is triggered by device classification, not by business choice.
- Legal status. ONC certification is technically voluntary: there is no law requiring a vendor to certify. However, certified technology may be a practical requirement for providers to participate in certain federal programs (e.g., CMS Promoting Interoperability), making certification a de facto market necessity for many EHR vendors. FDA Part 820 is a legally enforceable federal regulation — noncompliance can result in warning letters, product holds, or other enforcement action.
- Enforcement body. ONC certification is administered through ONC-Authorized Testing Laboratories (ONC-ATLs) and ONC-Authorized Certification Bodies (ONC-ACBs), which conduct testing and issue certification. FDA Part 820 is enforced directly by the FDA through inspections and audits of manufacturing facilities and quality records.
- What it tests/requires. ONC certification evaluates specific technical criteria: functionality, interoperability, privacy, and security features defined in 45 CFR Part 170. FDA Part 820 requires a documented quality management system covering the entire product lifecycle. Note that as of February 2026, Part 820 has been harmonized with ISO 13485:2016 under FDA’s Quality Management System Regulation (QMSR), so current compliance is assessed against the QMSR/ISO 13485 framework rather than the legacy QSR text.
A product can be both a certified health IT module and an FDA-regulated medical device: for example, clinical decision support software that meets the definition of a medical device. In that case, the vendor must satisfy both frameworks independently, since they test different things and are overseen by different bodies.
If it’s unclear which applies it is best to consult qualified regulatory counsel to determine the product’s classification and the applicable compliance obligations, since misclassification carries legal and market-access risk.
