The ONC Health IT Certification Program is an initiative run by the Office of the National Coordinator for Health Information Technology (ONC), the agency responsible for overseeing national health IT policy. Although participation is technically voluntary, ONC certification ensures that EHRs, digital health tools, telehealth platforms, and FHIR servers meet federally required standards for technology, functionality, and security. It’s also a must-have for federal incentive programs, such as the Quality Payment Program, the Inpatient Quality Reporting Program, and the Medicare Promoting Interoperability Program; CMS requires ONC-certified technology for MIPS participation. If you build or manage systems that handle PHI, you need to understand what ONC certification is, how to get ONC certified, and what the requirements entail.
This guide answers those questions and highlights related standards, FHIR, HL7, USCDI, and HIPAA, so vendors, clinicians, and engineers can navigate ONC compliance with confidence.
What Is the ONC Health IT Certification Program and Why It Matter
ONC stands for the Office of the National Coordinator for Health Information Technology at the U.S. Department of Health and Human Services. So, in simple words, what is ONC certification? It’s a federal program that verifies health IT against criteria for interoperability, security, and patient access. The goal is simple: make data shareable, keep it safe, and give people access to their records. These criteria align with FHIR, USCDI, and related regulations like the HTI-1 rule.
Important: ONC ≠ oncology certification. If you’re searching “what is ONC in healthcare” or “what does ONC stand for in healthcare,” remember this ONC is about health IT regulation, not cancer-care credentials for nurses.
Who seeks certification? EHR vendors, digital health product teams, telehealth and patient-access app builders, interoperability platform developers, analytics and API/facade vendors, and other health IT software builders that handle Electronic Health Information (EHI). Certification signals your product meets national standards for secure, standards-based exchange and patient access.
ONC Certification Requirements: Core Criteria and Functional Standards
The Office of the National Coordinator’s Health IT Certification Program sets minimum capabilities that electronic health records must meet to appear on the Certified Health IT Product List. The latest version (2015 Cures Update) contains approximately 60 criteria across 8 categories. These criteria ensure systems can capture clinical data, safeguard privacy, and exchange information via open standards. Below is a brief overview of these ONC certification requirements, grouped into three practical areas: clinical functions, privacy & security, and interoperability.
Clinical criteria
These criteria cover core clinical functions. Certified modules must allow clinicians to enter medication and lab orders electronically; check for drug interactions; maintain patient demographics, problem lists, and medication/allergy lists; and provide decision support. They also require tools for patient education and for collecting behavioural‑health data. Care‑coordination rules cover C‑CDA summaries, electronic prescribing, and data export, while patient‑engagement rules ensure patients can view and share their own records securely. These features define the “clinical” side of the EHR certification program.
Privacy & security
These requirements focus on security and patient privacy. The ONC EHR certification requires user authentication, controlling access, logging who accesses data, and generating tamper‑resistant audit trails. They must allow record amendments, enforce time‑outs, support emergency access, encrypt data on devices, and maintain message integrity.
Interoperability & data exchange
Interoperability rules ensure certified products can exchange information with partners and patients. Systems must generate and consume C‑CDA documents, support transport protocols like Direct Project and XDR/XDM, and use standardized vocabularies. They must provide FHIR‑based APIs conforming to USCDI so apps can request patient and population data. Public‑health requirements include sending data to immunization and cancer registries, as well as to other surveillance systems. Additional design and performance criteria support quality‑measure calculation and accessibility, and encourage modular certification.
Examples of ONC criteria by category
| Category | Selected requirements (examples) |
| Clinical processes | Computerized provider order entry (CPOE) for medications, labs and imaging;Drug–drug and drug‑allergy interaction checks;Demographic, problem, medication and allergy lists;Clinical decision support; patient‑specific education and social, psychological and behavioural data. |
| Privacy & security | Authentication and access control;Audit logs and tamper resistance;Amendments to health records; automatic session time‑outs;Emergency access; end‑user device encryption;Integrity checks;Trusted connections. |
| Interoperability & exchange | Support for C‑CDA summaries;Electronic prescribing and clinical information reconciliation;FHIR‑based APIs aligned with USCDI;Transmission to immunization registries, cancer registries and other public‑health agencies;Direct Project and other transport methods. |
ONC Certified EHR vs Non‑Certified
Most providers use electronic health record (EHR) systems, but only those that have been tested and approved under the ONC Health IT Certification Program are considered certified. Certification means the software has undergone independent testing and been reviewed by an ONC-authorized certification body, ensuring it meets national standards for structured data, interoperability, and security. Certified systems also undergo post‑market surveillance to confirm continued compliance.
Certified vs non‑certified
- What “certified” (CEHRT) means. The system has passed formal tests for accurate data capture, privacy and security safeguards, and standards-based exchange (including modern APIs like FHIR/SMART). It’s listed on the Certified Health IT Product List (CHPL) and can be used to meet Medicare and Medicaid Promoting Interoperability and MIPS requirements.
- What “non-certified” means. The software may handle daily documentation, but it hasn’t been validated against federal criteria and isn’t eligible for CMS incentive programs. In practice, that can make quality reporting harder and increase the risk of negative payment adjustments.
| Aspect | Certified EHR | Non‑Certified EHR |
| Testing & standards | Independently tested and certified to national criteria for functionality, privacy and interoperability | No formal testing; may not meet ONC or CMS standards |
| Interoperability | Supports structured data and standardized APIs for patient and provider access | May use proprietary formats; data exchange is limited |
| Program eligibility | Qualifies for Promoting Interoperability and MIPS incentives | Not eligible; providers risk payment penalties |
| Oversight | Listed on CHPL and subject to ongoing surveillance and attestation | No official oversight or listing |
Certification is a visible signal that a product meets rigorous standards. It assures buyers that the system supports structured data exchange and modern APIs for patient access, implements required privacy and security safeguards, and enables participation in federal incentive programs. In contrast, uncertified systems may not protect patient data, may not qualify for incentives, and can expose providers to penalties.
How to Get ONC Certification: Step-by-Step Guide
Step 1: Determine your product’s certification scope
Decide which criteria you’ll certify, choose modular vs complete certification, and map criteria to real features, and confirm whether you must meet the Base EHR definition.
Step 2: Select an ONC-authorized testing laboratory
Choose an ATL and agree on timelines, environments, and evidence. Align on the test method and what you’ll run first.
Step 3: Pre-test preparation
Stand up a stable test tenant and public developer docs (base URLs, scopes, endpoints). Lock your US Core version, seed must-support data (with Provenance), and verify SMART on FHIR flows, refresh tokens, and revocation. Dry-run full suites and fix gaps before the formal session.
Step 4: Undergo testing
Execute discovery/authorization, single-patient US Core, and Bulk Data flows, including negative/security tests. Capture logs and validator output, remediate issues, then re-run to green.
Step 5: Certification by an ONC-authorized certification body (ACB)
Submit your test evidence to an ACB. Address any findings, finalize your certification package, and receive the formal decision.
Step 6: Listing on CHPL (Certified Health IT Product List)
Provide listing details (version, criteria, transparency URLs). Verify your CHPL entry and keep docs and base URLs current for implementers.
Step 7: Ongoing surveillance
Plan for attestations, real-world testing, and potential surveillance by the ACB. Track standards updates, assess release impacts, and recertify when functional changes affect certified criteria.
Understanding the Standardized API Criterion for ONC Certification (g)(10)
The ONC 170.315(g)(10) criterion refers to the Standardized API for Patient and Population Services. This certification criterion requires electronic health record (EHR) technology to provide a standardized application programming interface (API) that enables patients to access and transfer their health information in a way that is computable and usable by the receiving system.
The API must use the FHIR standard and support all data elements of the United States Core Data for Interoperability (USCDI) standard, as well as other specific features outlined in the certification criteria. The goal of this criterion is to facilitate patient access to their health information and to promote interoperability among healthcare providers and systems.
In practice, (g)(10) lets trusted apps securely read USCDI data from certified EHRs. You expose FHIR R4 endpoints with SMART on FHIR for single-patient and bulk access. Standardized endpoints cut custom integrations and speed analytics. Teams can run cohort queries for quality, research, and population health. § 170.315(g)(10) applies to all health IT developers who are certifying to the EHR base definition on or after December 31, 2022.
Before you scope your API, review our primer on ONC (b)(10) certification.
In order to demonstrate compliance with API technology standards in ONC certification, the following technical outcomes and conditions must be met:
1. Data response: The API must be able to respond to requests for a single patient’s data and multiple patients’ data in accordance with the standard and implementation specifications adopted by ONC. All mandatory data elements must be supported.
2. Supported search operations: The API must be able to respond to search requests for a single patient’s data and multiple patients’ data consistent with the search criteria included in the implementation specification.
3. Application registration: The API must enable an application to register with the health IT module’s “authorization server.”
4. Secure connection: The API must establish a secure and trusted connection with an application that requests data for patient and user scopes, as well as system scopes, in accordance with the implementation specifications adopted by ONC.
5. Authentication and authorization: The API must ensure authentication and authorization for patient and user scopes, as well as for system scopes. This must occur during the process of granting access to patient data, and a refresh token must be issued for subsequent connections.
6. Patient authorization revocation: The API must allow a patient to revoke an authorized application’s access.
7. Token introspection: The API must be able to receive and validate tokens it has issued.
8. Documentation: The API must include complete documentation that contains information on syntax, function names, required and optional parameters, return variables, exceptions, and exception handling methods, software components and configurations necessary for an application to interact with the API, and all applicable technical EHR certification requirements and attributes. This documentation must be publicly accessible without any preconditions or additional steps.
Typical use cases
Once teams implement (g)(10), the standardized FHIR API becomes a practical growth lever: startups move faster without fragile custom integrations, and EHR vendors turn connectivity into a product with predictable onboarding, security, and real-world testing baked in.
For startups:
- Patient apps that pull meds, allergies, problems, and labs from multiple EHRs via SMART on FHIR.
- Care navigation and medication tools that use USCDI data to flag gaps and interactions.
- RPM companions that join device readings with EHR context, like conditions and recent labs.
For EHR providers:
- EHR vendors cultivate a third-party app ecosystem by supporting SMART launch, dynamic client registration, and reliable token revocation workflows.
- Patient access and patient portals reuse the same standardized FHIR endpoints to power app connectivity and view-download-transmit features without parallel interfaces.
- Quality programs and registries receive population-level data through bulk FHIR exports that feed reporting pipelines, registries, and population health analytics.
What Is the (g)(10) API Certification Test, and What Tools Do You Need
In the ONC certification pathway, §170.315(g)(10) is the interoperability gate: it verifies your product exposes a standardized FHIR API that lets patients and authorized apps securely access USCDI data for both single-patient and population scenarios. Passing (g)(10) proves real, working API behavior, so third-party apps can connect reliably across certified systems.
The (g)(10) certification criterion requirements can be assessed for conformance of a health IT module using the ONC-approved tools for the test procedure. These include:
Inferno Framework
The (g)(10) Standardized API Test Kit, built using the Inferno Framework, is used for (g)(10) API testing in the ONC Health IT Certification Program. The (g)(10) Standardized API Test Kit comes with all of the services necessary to test health IT modules seeking to meet the requirements of the Standardized API for patient and population services criterion finalized at 170.315(g)(10).
Drummond G10+ FHIR API powered by Touchstone
In July 2022, ONC announced the approval of the Drummond Group’s Drummond G10+ FHIR API powered by Touchstone tool, a new alternative test method (ATM) for testing conformance to ONC’s 170.315(g)(10) Standardized API for patient and population services certification criterion. Through this new ATM, software developers will now have a new option for conformance testing in addition to the previously approved Inferno (g)(10) Standardized API Test Kit. The approval of Drummond’s testing method continues ONC’s mission to further diversify the suite of test methods used as part of the ONC Health IT Certification Program.
Best Practices for Using Inferno in Your ONC Certification Testing
CTOs, engineering leads, and FHIR developers working toward (g)(10), this section is for you. Inferno is the official ONC test tool that validates your standardized FHIR API and confirms USCDI access through real, executable tests.
Quick start
- Install. Use the maintained Docker image (fastest) or run from the official release locally. Keep versions pinned in your repo.
- Configure. Set your Service Base URL, SMART endpoints, client credentials, allowed scopes, and pick your US Core version. Verify .well-known OIDC config and your CapabilityStatement load without errors.
- Run test suites. Execute Discovery & Authorization, Single-patient US Core, and Bulk Data flows. Include negative and security checks. Export reports, fix issues, and re-run to green.
As part of the ONC Approved SVAP Standards for 2022, four (g)(10) standards (USCDI, US Core, SMART App Launch, and Bulk Data Access) have been updated. Developers of Health IT participating in ONC’s Health IT Certification Program have the option to integrate these new versions into their certified health IT modules.
The Inferno Framework provides the option to choose the standard version that the health IT developer chose.
US Core Version
The US Core Implementation Guides are based on the FHIR standard, a modern healthcare interoperability standard developed by HL7. The US Core Implementation Guides leverage FHIR resources and profiles to define a core set of data elements and metadata necessary for the exchange of healthcare information in the United States.
The US Core Implementation Guides also follow the US Core Data for Interoperability (USCDI) standard, which was developed by the ONC to define a minimum set of health data elements that should be standardized and made available for exchange across different health IT systems. The US Core Implementation Guides provide specific guidance on how to implement the USCDI standard in EHRs and other health IT systems.
Two versions of USCDI have been published. The primary difference between USCDI version 1 (v1) and USCDI version 2 (v2) is the number and type of data classes and data elements included. A third version of the USCDI has already been published, and USCDI v4 is currently being drafted, which will be included in the Inferno Testing Framework in the future.
USCDI version 1 includes 21 data classes and 49 data elements that primarily focus on basic patient demographics, laboratory tests, and vital signs. It does not include information related to social determinants of health or certain clinical data, such as clinical notes.
USCDI version 2, on the other hand, includes 24 data classes and 130 data elements, which include more comprehensive clinical data such as diagnostic imaging reports, clinical notes, and social determinants of health. It is intended to provide a more complete picture of a patient’s health status and enable better clinical decision-making.
HL7 FHIR US Core Profiles and Implementation Guides were developed to harmonize the requirements of the USCDI and FHIR resources through profiles.
The key difference between US Core 3.1.1 and 5.0.1 is that 3.1.1 supports USCDI v1, while 5.0.1 supports USCDI v2. Therefore, US Core 5.0.1 guides on implementing the additional data classes and data elements included in USCDI v2.
Smart App Launch
The SMART App Launch specification defines the technical requirements for integrating third-party applications with ONC-certified EHR systems via the FHIR API.
Bulk Data
Bulk Data 1.0.1 and Bulk Data 2.0.0 are two versions of the Bulk Data API developed by the SMART on FHIR project to support the scalable, secure exchange of patient data between healthcare systems and third-party applications.
Improvements to Bulk Data 2.0.0 include:
- Documentation on transmitting binary content in attachments;
- Improvements to incremental update handling (retrieving historical data for new members of a group, propagating resource deletions);
- Performance-oriented enhancements (limiting fields returned using the _elements parameter, POST-based kickoff requests with the Parameters resource, addition of a patient parameter for filtering);
- Improvements on handling metadata and other optional resources such as Provenance with the includeAssociatedData parameter; better export job management (clearer errors, signaling download completion to servers);
- Documentation clarifications (inclusion of resources outside of Patient Compartment, parameter optionality for servers).
Inferno Test Procedures: What You Need to Know
We’ve helped our clients make the process of preparing and passing the ONC Certification (g)(10) Criterion as painless as possible. Our team understands all the intricacies of the testing procedures in the Inferno Framework Testing Kit, and we’d like to share them with you to help you make the journey of getting ONC-certified just a little bit easier.
First, it’s important to note that the (g)(10) criterion concerns standardized APIs; it doesn’t involve the use of interfaces (forms or screens). The only exception is the chain of authorizations, where the user must be identified (such as providing login credentials) and an interface to define the requested scopes.
When choosing the test parameters, keep in mind that all tests use the defined conditions, meaning you cannot change attributes related to the authorization server, client, and the general list of scopes.
Certification testing includes both automated and manual components. Automated tools like Inferno make thousands of API calls quickly, verifying compliance with standards. Manual testing is still necessary to demonstrate user‑facing functionality, confirm proper handling of edge cases, and show evidence of security controls.
| Aspect | Manual | Automated |
| Speed & repeatability | Slower, variable | Fast, consistent |
| Coverage | Spot checks | Full test suites |
| Negative cases | Easy to miss | Built into suites |
| Data needs | Explore on the fly | Seed must-support data first |
| CI/CD | Hard to scale | One command/pipeline |
| Human error | Higher risk | Lower risk |
1. Standalone Patient App Tests Group
1.1 SMART on FHIR Discovery
The requirements of this test follow the OpenID Connect protocol. A well-known endpoint is a URL path that points to a JSON document containing metadata about an OpenID Connect provider. This JSON document, called the OpenID Provider Configuration Document, provides information about the provider’s authentication endpoints, keys, and supported scopes and claims.
The .well-known endpoint for the OpenID Provider Configuration Document is typically located at the /.well-known/openid-configuration URL path relative to the issuer URL. For example, if the issuer URL is https://example.com, the OpenID Provider Configuration Document would be available at https://example.com/.well-known/openid-configuration.
By providing a standard way to locate the OpenID Provider Configuration Document, the well-known endpoint simplifies the discovery of the information required for implementing OpenID Connect clients.
1.2 Standalone Launch With Patient Scope
This test verifies the authorization flow between the authorization server and the FHIR server. The entire authorization process is demonstrated below:
For better understanding, let’s consider a mobile app that needs to access patient information to display a historical heart rate graph. When a user installs this app and initiates the sign-up process, they are redirected to the authorization server, where they encounter a login screen requesting their approval for the required scopes.
SMART on FHIR uses scopes to grant specific access rights to third-party applications. These scopes are categorized into patient-specific, user-specific, and system-specific-level scopes that can authorize various permissions like .read, .write, and .* (SMART on FHIR version 1.0.0) or *.cruds (SMART on FHIR version 2.0.0).
If the login process is successful, the authorization server issues a temporary authorization token that the mobile app uses to request an access token. The access token is an encrypted piece of information that is digitally signed, adheres to FHIR standards, and contains critical information like the issuer, expiry date, and scope.
The mobile app sends the access token to the FHIR server, which then verifies the token with the authorization server. If the validation is successful, the app is authorized to access and read the requested information, allowing it to display the heart rate graph to the user.
1.3 OpenID Connect
OpenID Connect (OIDC) and OAuth 2.0 are both protocols that provide a framework for authorization and authentication for web and mobile applications.
OAuth 2.0 is primarily an authorization framework that allows third-party applications to access a user’s data without requiring the user to provide their password. It enables a user to grant a third-party application access to their resources stored on another service, such as Facebook or Google, without giving the application their password.
OAuth 2.0 provides authorization by issuing an access token to the client after the user grants the application permission. The access token is used to authenticate the client to access protected resources on the user’s behalf.
OpenID Connect is built on top of OAuth 2.0 and provides both authentication and authorization. It allows a user to authenticate with an application using their existing login credentials from a trusted identity provider (IdP) such as Google or Facebook. OpenID Connect provides an identity layer on top of OAuth 2.0, allowing applications to verify a user’s identity based on the authentication performed by the IdP.
OAuth 2.0, for example, doesn’t define how a user declares the required scopes, just that the scopes exist. OpenID Connect, on the other hand, defines scopes in detail.
OAuth 2.0 is primarily focused on authorization, while OpenID Connect provides both authentication and authorization.
1.4 Token Refresh
The 170.315(g)(10) criterion outlines specific requirements for initial and subsequent connections between a health IT module and an authorization server. For first-time connections, the authorization server must issue a refresh token that remains valid for at least 3 months to applications capable of storing a client secret and securing refresh tokens for native applications.
For subsequent connections, the authorization server must issue a new refresh token that remains valid for at least 3 months to applications capable of storing a client secret. These refresh token requirements aim to provide patients with persistent access to their electronic health information without any additional effort.
Health IT developers may enable patients to express their preferences for persistent access and configure the duration of access accordingly. While presenting patients with options for persistent access, developers must include an option of at least three months.
1.5 Unrestricted Resource-Type Access
This test decrypts the access token and performs read-type operations on the defined resources based on the scopes defined in the token. Essentially, it verifies that a user can access only the resources that the access token allows them to read. It doesn’t check whether these resources are available; it only checks the access configuration. For the test to be successful, access to unauthorized resources must be denied.
2. Limited Access App
This group of tests is similar to the first one, with the only difference being that, during authorization, it’s expected that the user will grant access only to specific resources (listed in the test parameters), not others. For these tests, a new access token is generated.
The main goal of these tests is to verify that the authorization server sends the correct scopes in response to the authorization request.
3. EHR Practitioner App
This group of tests emulates the scenario of launching an app within an app, meaning an app is launched within an EHR. Below is an example of such an authorization flow. This “app-within-an-app” authorization flow uses the user-level scopes.
4. Single Patient API
These tests use the access token from the previous group of tests. Note that the USCore version depends on the options chosen prior to running the test procedure.
The Inferno Test Kit requests the Patient resource and all profiles related to it. The list of profiles is different depending on the USCore version chosen.
This test verifies the following:
- Patient-related resource availability;
- The availability of the Provenance resource for the requested resource using the _revinclude operation;
- Conformance to the USCore Implementation Guide;
- All must-support elements in profiles.
Note: For this test, at least one of the retrieved resources has to contain the must-support element, meaning that let’s say in at least one AllergyIntolerance resource, the clinicalStatus field has to be present, even if it’s defined as not mandatory by its cardinality (e.g., 0..1).
5. Multi-Patient API
FHIR Bulk Data Access is a standardized method for retrieving large amounts of data from a FHIR server. SMART Backend Services provides authorization for FHIR Bulk Data Access through OAuth2 scopes.
To access bulk data, a client must first obtain an access token from the authorization server. Once the client has obtained an access token with the necessary scopes, it can use the FHIR Bulk Data Access API to initiate a bulk data request. The request includes parameters such as the resource type to retrieve, the data date range, and the format of the returned data.
The SMART Backend Services authorization server validates the access token and authorizes the request if the client has the necessary scopes. The FHIR server then processes the request and returns a response containing a link to download the requested data in the specified format.
Essentially, this test launches the FHIR Bulk API, then after receiving the requested data, imports it back into the system. When it uploads the data, it verifies that it matches the listed profiles.
6. Additional Tests
6.1 SMART Public Client Launch
SMART on FHIR supports two types of apps: public and confidential. This test runs the authorization process using public app access.
Confidential apps require authentication and authorization to access sensitive data or perform actions that could significantly impact the system. These apps are intended for use by authorized users, such as healthcare providers or patients, and can access a wider range of data and functionality than public apps.
Public apps, on the other hand, are designed for use by anyone with a login and password. These apps can access only a limited set of data and functionality, and they cannot be used to access sensitive data or perform any actions that could have a significant impact on the system.
Public apps typically do not access or display protected health information (PHI) but may provide general health information, educational resources, or other non-PHI-related services.
A good example of this is health calculators. They can be either public or confidential apps, depending on the use case and data handling. For example, a simple calculator that calculates BMI based on user input may not require any patient data and can be considered a public app. On the other hand, a calculator that requires access to a patient’s electronic health record to calculate medication dosage or disease risk may need to be a confidential app and follow stricter security and privacy measures.
6.2 Token Revocation
This test follows the OpenID Connect protocol’s standard procedure for token revocation.
Neither SMART on FHIR nor the ONC specifies a standard for token introspection, but ONC encourages the industry to coalesce around using a common standard, like OAuth 2.0.
6.3 SMART Invalid AUD Launch
6.4 SMART Invalid Token Request
6.5 SMART Invalid PKCE Code Verifier
Tests 6.3 through 6.5 follow the same authorization procedure as in the first group of tests. However, the difference here is that, for these tests, “incorrect” data is being sent, such as an invalid token. It’s expected that the test will yield a negative outcome, meaning the system denied the request.
Common Challenges with ONC Certification
Even well‑prepared teams encounter obstacles during certification. Understanding common pitfalls can help you anticipate and overcome them:
Technical complexity of meeting criteria. Developers must implement numerous standards (FHIR, HL7, C‑CDA, USCDI, SMART on FHIR) and ensure that all functions interoperate seamlessly. Because standards and test scripts change, the target can move mid-project. It’s much easier to handle when you assign dedicated compliance engineers, use test-driven development, and keep a close eye on ONC announcements.
Misunderstanding the scope of certification. Some vendors assume the criteria are narrower than they are or treat “optional” items as unimportant for their market. A detailed gap analysis at the start, plus a call with an ATL or a seasoned compliance consultant, helps you set the right scope and avoid painful rework later.
Difficulties with Inferno or AEGIS tests. Inferno and AEGIS (for patient-access APIs) are strict about configuration, scopes, search parameters, and resource conformance. Teams often only discover issues late in the cycle. Running these tools regularly in your continuous integration (CI) pipeline, using realistic datasets, and designating one person as the “testing owner” turns them into routine checks rather than last-minute blockers.
Lack of documentation and test data. ONC expects clear descriptions of workflows, APIs, and security controls, along with solid test data to support them. If documentation is thin or outdated, the whole process slows down. Writing docs alongside development, keeping a living knowledge base, and using synthetic data generators for test datasets make reviews faster and far less stressful.
Security and encryption validation. Certification examines how you encrypt data in transit and at rest, manage access, and capture audit logs. Misconfigured security layers can easily trigger failures. Sticking to proven practices such as TLS 1.2+, encrypted databases, and role-based access control, and running internal security audits before the session, helps catch issues early.
Time and budget constraints. Certification takes focused time and specialized skills, and unexpected test failures can quickly stretch both timelines and budget. Teams that set realistic schedules, leave a buffer for retesting, and bring in experienced consultants or outsource parts of development and testing usually move through the process with fewer surprises.
Best Practices for Health IT Vendors Seeking Certification
Certification goes more smoothly when it’s treated as part of product development, not a separate project at the end.
Start early with a gap analysis. Map your current product to the ONC criteria and highlight missing features, security controls, and interoperability pieces. Doing this early gives you time to close gaps without pushing release dates.
Build for modular certification. Design the system so that major areas, such as e-prescribing, the patient portal, or decision support, can be certified separately. This lets you bring working modules to market sooner and limits how much you need to retest when standards change.
Use certification-style tests in your pipeline. For each criterion, create automated tests that mirror the examiner’s scripts and run them in CI. When something breaks, you see it right away instead of just before the certification session.
Engage with the ATL/ACB before you’re “ready.” Short, early calls with your testing lab and certification body help clear up ambiguous criteria, tricky edge cases, and documentation expectations. That reduces rework and avoids surprises during formal testing.
Keep documentation clear and current. Maintain straightforward documentation for architecture, APIs, data flows, user workflows, and security controls. Step-by-step notes for examiners make their job easier and usually shorten the review.
Bring in outside help when it makes sense. If your team lacks of time or ONC experience, certification consultants can handle gap analysis, test preparation, and communication with ATLs/ACBs so your engineers can focus on the core product.
Track ONC updates as part of your roadmap. Follow the Health IT Standards Bulletin and industry newsletters for updates, such as USCDI v4 or HTI-4. Adding these updates to your roadmap early is much easier than reacting just before renewal or recertification.
How to Maintain ONC Certification
Passing the certification exam is only the beginning. Maintaining compliance requires continuous attention:
Post‑certification surveillance. ONC‑Authorized Certification Bodies will check each year that required capabilities still work and that recent updates didn’t introduce regressions. You’ll be ready if certification test scripts live in CI, and each release notes what changed and how it was verified.
Update compliance with new ONC criteria. ONC criteria evolve, often through new USCDI versions or updated interoperability expectations. (USCDI v4, for example, expands allergy, vital-sign, and facility data.) Flag these shifts early, add them to the roadmap, and align engineering, QA, and docs so updates land well before renewal.
Bug fixes and recertification. New modules, a revised storage model, or reworked core workflows may require retesting. A quick check with your ACB during planning clarifies what’s in scope so you can schedule recertification without derailing other work.
Security maintenance. Compliance rests on routine hygiene: timely patches, reviewed access rights, current encryption, and periodic penetration tests or vulnerability scans. Treat these as recurring tasks to stay aligned with HIPAA and catch issues long before an audit, or an incident.
Kodjin’s Role in Helping You Achieve ONC Compliance
At Kodjin, we specialize in building FHIR‑compatible products and helping healthcare organizations navigate the complexities of ONC certification. Our team of engineers and compliance experts can:
- Develop modular, cloud‑native solutions that support FHIR R4, US Core, and SMART on FHIR.
- Ensure compliance with HL7, HIPAA,and ONC criteria through rigorous testing and documentation.
- Prepare your product for (g)(10) certification by configuring patient‑access and bulk‑data APIs and running Inferno test suites.
- Assist with gap analyses, test preparation, and documentation for both ATL and ACB reviews.
If you need to accelerate your path to certification or want expert guidance on maintaining compliance, contact us at Kodjin ONC compliance solution. Our experience with FHIR, HL7, and healthcare standards can help you get your health‑IT product ONC certified faster.
Upcoming Changes in ONC Certification: What to Expect Beyond 2025
The ONC is actively monitoring the health IT industry’s progress toward achieving near-real-time interoperability of health information among all stakeholders, with a particular focus on patients. A recent HealthITBuzz blog, co-authored by ONC and HHS, provides an update on compliance with the Cures Act mandate, which requires all Certified EHR developers to “Certify and Provide” their customers with a FHIR-based API by December 31, 2022, specifically the (g)(10) criterion.
According to an ONC HealthITBuzz blog post, over 95% of certified health IT developers met the compliance deadline for the Cures Act Final Rule.
The ONC will now monitor adoption and conformance in deployed systems through their Lantern tool, while also engaging with the health IT industry to ensure hospitals and clinicians across the nation can utilize FHIR-based APIs. The Lantern tool was developed to monitor the nationwide implementation of FHIR APIs and facilitate interoperable linkages to these endpoints.
The ONC plans to provide ongoing updates on compliance with the Cures Act Final Rule requirements throughout 2023. Health IT developers of ONC-certified software must attest twice yearly for compliance with the Conditions and Maintenance of Certification requirements, with the first attestation starting on April 1, 2022. ONC-ACBs will review the submissions and make them publicly available through the CHPL. Additional guidance on submitting attestations will be provided by ONC.
Conclusion
The ONC Health IT Certification Program is the gold standard for ensuring that electronic healthcare products meet national requirements for functionality, security, and interoperability. Certification empowers patients through secure data access, promotes interoperability among healthcare systems, and helps clinicians qualify for federal incentive programs. While achieving certification can be complex, following a structured process, scoping your product, engaging with testing laboratories, preparing thorough documentation, using official test harnesses, and adopting best practices will smooth the journey. Ongoing surveillance and proactive maintenance ensure that certified products remain compliant as standards evolve.
For vendors, certification is a competitive advantage and a sign of trust. For healthcare providers, it means better data exchange, improved clinical workflows, and enhanced patient engagement. ONC certification is essential but challenging; working with an experienced partner like Kodjin can help you get certified faster and stay compliant in the rapidly changing landscape of healthcare technology.
