The majority of healthcare organizations implementing EMR or EHR systems want to leverage the benefits of increased efficiency, improved patient care, and better decision-making. According to the AHA annual survey, as of 2021, nearly four in five office-based physicians (78%) and nearly all non-federal acute care hospitals (96%) adopted a certified EHR.
With an EHR, healthcare providers have instant access to a patient’s medical history, lab results, and other critical health information, which can help them make more informed decisions about patient care.
However, the sheer volume of EHR solutions available on the market can make the selection process overwhelming. The costs of EHR implementation projects, which can reach up to billions of dollars, also add to the pressure of decision-making.
In order to help healthcare providers choose the best tool to fit their needs, the Office of the National Coordinator for Health Information Technology (ONC) created the ONC Health IT Certification Program, a certification program for EHR software that can serve as a sort of “selection pool” of reliable certified health IT products that comply with federal legislation, EHR interoperability requirements, and information blocking prevention policies.
In this guide, we will cover everything you need to know about how to pass the ONC Health IT Certification Program and get ONC-certified. You will gain foundational knowledge about the certification program, its history, and ONC Сertification requirements. We will also take a detailed look at the 170.315(g)(10) Standardized API for Patient and Population Services criterion and the steps necessary to take during the API testing process.
The Basics of ONC Health IT Certification Program
The ONC Health IT Certification Program was implemented under the Public Health Service Act to establish standards for the constantly evolving health information technology sector. Third-party entities assess Electronic Health Record (EHR) programs to evaluate their recording, security, and information-sharing capabilities. Certification is only awarded to providers who meet the ONC’s standards. Medical providers are required to use ONC-certified EHR systems to receive Medicaid and Medicare incentive payments. Moreover, this certification inspires greater confidence in both providers and patients about the storage and usage of health information.
The Health IT Certification Program of the ONC is a voluntary assessment program for health information technology that follows the frameworks outlined by the International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC).
The program itself does not conduct conformance testing or provide certifications. Instead, ONC collaborates with specific organizations authorized and evaluated by ONC to conduct conformance testing and award certifications to health IT products. The Certification Program outlines the criteria, evaluation process, testing (if necessary), certification process, and maintenance requirements for health IT.
Key Entities Involved in the ONC Health IT Certification Program
Listed below are the key entities involved in the ONC Health IT Certification Program, and they work in collaboration with each other to establish and maintain the necessary testing and certification requirements for Health IT products.
- National Institute of Standards and Technology (NIST): It collaborates with the ONC to develop the necessary testing infrastructure and tools for the program;
- National Voluntary Laboratory Accreditation Program (NVLAP): It accredits testing laboratories to evaluate the conformity of health IT products with criteria in the ONC Health IT Certification;
- Accreditation Bodies: They accredit certification bodies to grant ONC certifications to health IT products;
- ONC-Authorized Testing Laboratories (ONC-ATLs): They perform actual testing of health IT products to determine conformance with ONC’s standards;
- ONC-Authorized Certification Bodies (ONC-ACBs): They grant certifications to health IT products that meet ONC’s certification criteria and post the results on the Certified Health IT Product List (CHPL);
- Health IT Developers: They develop health IT products and seek certification from ONC-ACBs to ensure their products meet the criteria defined by the ONC Certification Program.
The ONC Health IT Certification Program is primarily aimed at promoting innovation in healthcare technology and enhancing information delivery to patients and clinicians.
Since its inception in 2010, the program has introduced four editions, each designed to promote this objective. The program strives for continuous improvement, building on past rulemaking and updating ONC certification criteria, standards, and implementation specifications to enhance interoperability for diverse clinical health information purposes and facilitate health information exchange.
The 2015 Edition Cures Act Update, which is the latest version of the ONC Health IT Certification Program, was released in 2020 as part of the 21st Century Cures Act. This edition further promotes the smooth and secure access, exchange, and utilization of electronic health information.
The ONC Health IT Certification Program Goals
The ONC Health IT Certification Program aims to achieve the following goals:
- Ensure uninterrupted and secure access to Electronic Health Information (EHI);
- Foster an environment of new applications to promote innovation and competition;
- Encourage widespread use of standardized Application Programming Interfaces (API);
- Prevent the practice of information blocking;
- Impact areas such as Fast Healthcare Interoperability Resources (FHIR), information blocking, SMART IG/OAuth2.0, and various other areas.
The Cures Act encompasses various healthcare sectors and establishes six ongoing Conditions and Maintenance of Certification. These are as follows.
6 Ongoing Conditions and Maintenance of ONC Certification:
- APIs: Health IT must make API available transparent and comply with updated API requirements;
- Assurances: Health IT must report that it does not obstruct the exchange of electronic health information (EHI);
- Attestations: Health IT must attest to complying with the Conditions and Maintenance of Certification every six months, beginning in April 2021;
- Communications: Health IT cannot impede communications regarding the usability, interoperability, security, user experiences, business practices, or manner of use of health IT;
- Information Blocking: Health IT must not take any action that obstructs patient information;
- Information blocking is defined as “a practice that is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information”;
- Real-World Testing: Health IT must create and execute a plan to fully test the real-world use of the EHR annually. The first plan must be completed by the end of 2021 and implemented in 2022.
Additionally, the update includes a provision that mandates patients have electronic access to all their electronic health information, structured or unstructured, at no cost to the patient.
What Are the ONC Certification Program Criteria?
The ONC has released three versions of certification criteria, with the most recent being the 2015 Edition Health IT Certification Criteria. This edition combines earlier regulations and includes enhanced criteria, standards, and implementation requirements. All hospitals eligible for the Medicare and Medicaid Promoting Interoperability Programs are required to comply with the 2015 Edition. The 2015 Edition consists of 58 health IT certification criteria, which are classified into eight categories.
With such a vital certification, it’s critical to find third-party laboratories to review the submitted EHRs. As of now, the ONC only works with four labs to complete certification:
- Drummond Group;
- ICSA Labs;
- InfoGard Laboratories, Inc.;
- SLI Compliance, a Division of Gaming Laboratories International, LLC.
Vendors must ensure their EHR systems or health IT modules meet all 2015 Edition certification criteria and the 2015 Edition Base EHR definition to obtain 2015 Edition Certified EHR Technology (CEHRT) status. While earlier versions of the CEHRT program targeted specific regulatory goals, the 2015 Edition Health IT Certification Criteria is program-agnostic. As per an ONC final rule overview, 2015 Edition Certified Health IT can support various use cases, needs, and incentive programs, including initiatives concerning long-term and post-acute care, behavioral healthcare, and chronic care management.
The 2015 Edition Certification Final Rule includes updated criteria, requirements, and modifications supporting the following:
Interoperability
The 2015 Edition CEHRT criteria incorporate revised and novel terminology and content standards for organizing healthcare data documentation, recording, and sharing to support interoperability. One of the requirements is a standardized Common Clinical Data Set that uses current health IT standards. Additionally, compliance with the C-CDA exchange standard is necessary.
Health data exchange and access
Health IT that is certified under the 2015 Edition should provide enhanced data export capabilities to enable health data exchange and access. It should also include features that support transitions of care and allow third parties to connect to the health IT products through an application programming interface (API).
Health IT standardization across the care continuum
The final rule for the 2015 Edition Certification establishes a framework that promotes an open and accessible Health IT Certification Program to support various health IT systems that cater to different care and practice settings, as well as HHS programs and both public and private interests.
Enhanced demographic data capture
Health IT tools are required to capture detailed information related to various aspects such as race, ethnicity, sexual orientation, gender identity, socioeconomic factors, psychological history, and behavioral health concerns.
Sensitive data segmentation
The ONC’s final rule promotes the secure exchange of sensitive health information by incorporating data privacy requirements. ONC defines data segmentation as “the act of separating specific data elements that are deemed undesirable to share by a legal entity, institution, organization, or individual from being captured, accessed, or viewed.” Data segmentation for privacy enables healthcare providers and other entities to determine which particular data elements are suitable for sharing, who can access the information, when access is granted, and for what duration.
The final rule mandates that 2015 Edition Certified Health IT products provide support for computerized provider order entry (CPOE), electronic prescribing, and drug and allergy interactions. Additionally, these certified tools must have the capability to document patient demographics and smoking status, along with their behavioral, social, psychological, and family health history information. The EHR system must provide access to the patient’s problem list, medication list, implantable device list, and medication allergy list. The 2015 Edition Certified Health IT should also feature clinical decision support capabilities and allow providers to view, download, and transfer health data to a third party, among other functions.
To meet the 2015 Edition Base EHR definition, health IT companies can utilize a single certified health IT module or a combination of modules.
To meet the 2015 base EHR definition, a system must include the following capabilities:
- Provide clinical decision support;
- Support physician order entry;
- Capture and query health information;
- Exchange health information with other sources and integrate information received from external sources;
- Store patient demographic and clinical health information, such as medical history and problem lists.
Standardized API for Patient and Population Services Criterion
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 Fast Healthcare Interoperability Resources (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.
§ 170.315(g)(10) is applicable to all health IT developers who are certifying to the EHR base definition on or after December 31, 2022.
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.
(g)(10) Testing Tools
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.
Inferno Testing Recommendations
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 Fast Healthcare Interoperability Resources (FHIR) standard, a modern healthcare interoperability standard developed by Health Level Seven International (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, which focus primarily on basic patient demographic information, 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 US Core 3.1.1 supports USCDI v1 and US Core 5.0.1 supports USCDI v2. Therefore, US Core 5.0.1 provides guidance on how to implement the additional data classes and data elements included in USCDI v2.
Smart App Launch
The SMART App Launch specification is a set of technical requirements that define how third-party applications can integrate with ONC-certified EHR systems using 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 scalable and secure data 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 well 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 is all about standardized APIs; it doesn’t involve the use of interfaces (forms and 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 definition.
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.
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 is called the OpenID Provider Configuration Document and provides information about the authentication endpoints, keys, and supported scopes and claims of the provider.
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 important information required for the implementation of 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 the example of 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 providing access to the user’s 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 permission to the application. 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 authentication as well as 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 and allows applications to verify the identity of a user 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, describes the process of defining 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 three months to applications capable of storing a client secret and securing a refresh token for native applications.
For subsequent connections, the authorization server must issue a new refresh token that remains valid for no less than three 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 are allowed to 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 performs the access token decryption and performs the read-type operations on the defined resources based on the scopes defined in the token. Essentially, it verifies a user can access only the resources that the access token allows them to read. It doesn’t check if these resources are available, only 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 in the process of authorization, it’s expected that the user will only grant access to specific resources (listed in the test parameters) but not others. For these tests, a new access token is generated.
The main goal of these tests is to verify if the authorization server sends the correct scopes according 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 be retrieved, the date range of the data, and the format of the data to be returned.
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 FHIR Bulk API, then after receiving the requested data, imports it back into the system. When it uploads the data, it validates that the data 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 have a significant impact on 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 standard procedure of the OpenID Connect protocol for token revocation.
Neither SMART on FHIR nor the ONC does not specify 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 are performing the typical authorization procedure that was already performed in the first group of tests. However, the difference here lies in that for these tests, “incorrect” data is being sent, such as the invalid token. It’s expected that the test will have a negative outcome, meaning the system denied such requests.
What’s in the Future?
The ONC is actively monitoring the health IT industry’s progress towards achieving near real-time health information interoperability 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
Because third-party laboratories test the software, medical professionals that opt for ONC-certified software don’t have to take the word of a service provider—EHRs that are not secure, trustworthy, or functional don’t receive ONC certification. This means staff and physicians can rest easy knowing their software meets rigorous Health IT requirements.
As more medical professionals implement programs that meet these standards, patients stand to benefit as well. EHR systems make managing their health care easier than ever. Furthermore, because the certified systems are more secure than others, patients’ personal information remains private.
If you want to learn more about how to get certified in healthcare and prepare for the ONC certification, we can offer you our extensive experience in guiding healthcare providers through the certification process.
With our expertise and knowledge of the ONC Health IT Certification Program, we can help you navigate the complex requirements, prepare for the certification exam, and ensure your EHR meets the necessary standards. Contact us today to learn more about how we can help you get ONC-certified!
