Certified Health IT

How can certified health IT help my practice?

Certified health IT can help your practice by:

• Making electronic prescribing available — which is safer, cheaper, and more convenient for clinicians and patients
• Supporting standardized application programming interface (API) technology, electronic transitions of care, closing referral loops, and giving clinicians straightforward and secure access to their patients' records from outside organizations
• Making the process for patients to get their personal health information less time-consuming and tedious for all parties while maintaining confidentiality
• Automating the process of sending data to immunization registries
• Facilitating the reporting of electronic clinical quality measures to the Centers for Medicare & Medicaid Services (CMS)

History of the ONC Health IT Certification Program

In 2009, the Health Information Technology for Economic and Clinical Health (HITECH) Act was signed into law as part of the American Recovery and Reinvestment Act (ARRA). The HITECH Act established the Office of the National Coordinator for Health Information Technology (ONC) — now the Office of the Assistant Secretary for Technology Policy and the Office of the National Coordinator for Health IT (ASTP) — as the principal federal entity charged with coordinating nationwide efforts to implement and use the most advanced health IT and electronic exchange of health information.

ASTP oversees the Health IT Certification Program for Health IT Modules. The Certification Program sets several nationwide requirements including:

• Health IT standards
• Implementation specifications
• Certification criteria

The HITECH Act also established the Electronic Health Record (EHR) Incentive programs, or Meaningful Use programs (now known as the Promoting Interoperability Programs). In the Medicare Access and CHIP Reauthorization Act of 2015 (MACRA), Congress made meaningful use of certified electronic health record technology (CEHRT) (now known as Promoting Interoperability) part of the Merit-based Incentive Payment System (MIPS) for eligible clinicians.

Administered by CMS, the incentive programs encourage eligible professionals, hospitals, and critical access hospitals to adopt, implement, and use CEHRT.

To participate in the CMS incentive programs, clinicians must demonstrate their “meaningful use” of CEHRT. That means meeting certain requirements — such as proving that you capture and share patient data using CEHRT, have completed a security risk analysis, and have not knowingly and willfully limited or restricted the compatibility or interoperability of your CEHRT.

ASTP and CMS established these requirements so that clinicians can electronically send and receive patient care information in a consistent, usable manner. Other programs that call for using CEHRT include MIPS and Advanced Alternative Payment Models (APMs).

ASTP has released several final rules that support the certification and availability of certified health IT for its encouraged and required use under other federal, state, and private programs. CMS has released similar changes to their programs that align with ASTP's updates. Each of these updates has enhanced the Certification Program framework by continuing to support clinicians in their efforts to:

• Increase care coordination, engage with patients, and improve outcomes
• Advance the development and use of health IT capabilities and establish expectations for data sharing
• Advance equity, innovation, and interoperability
• Support access to — and the exchange and use of — electronic health information (EHI)

Improving clinician access to certified technology will help make patient data consistently available to the right people at the right time and place.

For clinicians, implementers, and developers seeking more information about the Certification Program structure, key players, operations, and history, please review the following resources:

• Certification Program Overview
• Certification Program Regulations

Why is the use of certified health IT important to your practice?

Certified health IT plays a vital role in establishing a nationwide, connected, and interoperable health information infrastructure. Health IT Modules certified under the Certification Program are listed on the Certified Health IT Product List (CHPL).

Using certified health IT — including standards-based APIs, electronic exchange of clinical care documents, and other standards-based transactions such as e-prescribing — improves care coordination. Certification provides a baseline assurance that a Health IT Module will perform clinical care and data exchange functions in accordance with interoperability standards and user-centered design. The benefits of standard data capture and interoperable exchange of information include enhanced patient safety, usability, privacy, and security.

Standards incorporated into the Certification Program include vocabulary code sets, like SNOMED-CT®, which ensure consistent clinical terminology between systems. Standards for structuring clinical content include the Consolidated Clinical Document Architecture (C-CDA), which is discussed in Section 1 of this playbook. The C-CDA allows different health IT systems to send and receive a patient's clinical care summary while retaining the same meaning across systems. Other standards for exchanging patients' health information include the Fast Healthcare Interoperability Resources (FHIR®) standard, which enables the APIs that allow health IT systems to access and share certain data elements — such as medications, allergies, or lab results — in a flexible, real-time, and standardized way.

Certain health care payment programs — including the Promoting Interoperability Programs for hospitals and MIPS under the Quality Payment Program for eligible clinicians (formerly the EHR Incentive or Meaningful Use programs) — require the use of certified health IT. CMS defines CEHRT as health IT that meets the minimum set of required certification functionalities needed for program participants to comply with incentive program requirements.

What certified health IT will I need to participate in certain CMS programs?

Certain criteria are leveraged to meet CMS measures and outcomes outlined in their incentive programs. CEHRT defines key criteria to which a Health IT Module should be certified to meet incentive program requirements. To learn more about what certified health IT you will need to participate in certain CMS programs, please visit the CMS page on value-based programs to find information about specifications that may apply to you.

Certification criteria for health IT

A certification criterion defines the specific function that the health IT will perform. Some certification criteria require that a capability be performed using a specific standard. For example, the “transitions of care” certification criterion at § 170.315(b)(1) certifies that a Health IT Module:

• Creates summary of care records that adhere to the C-CDA and United States Core Data for Interoperability (USCDI) standards
• Sends and receives transition of care and referral summaries in alignment with specific transport protocols

Certification criteria are grouped by an alphanumeric citation under 45 CFR 170.315 and include the following health IT certification categories: clinical, care coordination, clinical quality measures, privacy and security, patient engagement, public health, design and performance, and transport methods. You can see new and revised certification criteria currently available under the Certification Program, as well as learn about time-limited and removed criteria on the Certification Program Test Method site.

ASTP updates these criteria periodically via the rulemaking process to ensure ongoing alignment with industry direction and provider needs. For example, developers may need to update to newer versions of specified standards to maintain compliance with a criterion's requirements. View upcoming update deadlines by criteria.

Base EHR definition

Certification criteria facilitate greater interoperability for several clinical health information purposes and enable health information exchange through new and revised certification criteria, standards, and implementation specifications. Certified health IT that satisfies the base EHR definition has been developed to have, at a minimum, a key set of capabilities. View the Base EHR definition.

United States Core Data for Interoperability (USCDI)

The United States Core Data for Interoperability (USCDI) is a standardized set of health data classes and constituent data elements for nationwide interoperable health information exchange. Find more information on the USCDI page. Future versions of USCDI will include new data elements and data classes that advance interoperability and health IT standards with the intent to minimize the burden of use for all users.

The Certification Program leverages versions of USCDI in several certification criteria for health IT to express EHI as part of the criteria's requirements.

What are the Conditions and Maintenance of Certification?

The Cures Act Final Rule finalized the Conditions and Maintenance of Certification, which are initial and ongoing requirements that health IT developers and their Certified Health IT Modules must meet under the Certification Program. Learn more about the Conditions and Maintenance of Certification, including specific regulations related to the following topics:

Information Blocking

This requirement prohibits any health IT developer participating in the Certification Program from taking any action that constitutes information blocking as defined by the law. To learn more about information blocking, see Section 2.4 of this playbook.

Assurances

This requirement outlines that developers must assure they will not take actions that constitute information blocking or inhibits the appropriate exchange, access, and use of EHI.

Developers must ensure their Health IT Modules fully comply with their certification criteria capabilities and won't take any actions to interfere with a user's ability to access or use such capabilities.

Learn more about the Assurances Condition and Maintenance of Certification requirements.

Communications

This requirement bars any health IT developer from prohibiting or restricting communications about Certified Health IT Modules related to:

• The usability, interoperability, and security of the developer's health IT
• Users' experiences when using the health IT
• The manner in which a user of the health IT has used the technology
• The developer's business practices related to exchanging EHI

To comply with the accompanying Maintenance of Certification requirements that outline exceptions to the prohibition of the subject matters listed above, health IT developers who currently prohibit or restrict these practices must notify their customers annually that they won't enforce any communication or contract/agreement provision that violates the Communication Condition of Certification. The health IT developer must continue to notify all customers annually until the developer removes or voids any contractual provisions that violate the Condition of Certification.

Learn more about the Communications Condition and Maintenance of Certification requirements.

Application Programming Interfaces (API)

This requirement applies to developers with Health IT Modules certified to the criteria adopted in § 170.315 (g)(7) through (g)(10) and outlines practices to ensure APIs can be accessed, exchanged, and used without special effort.

ASTP finalized the Cures Act Final Rule in 2020 to expand API requirements within the Certification Program. This rule supports seamless and secure access to — and exchange and use of — EHI as required by the 21st Century Cures Act. The finalized regulation calls on the health care industry to adopt standardized APIs, which would help individuals securely and easily access structured EHI using smartphone applications.

To learn more about the Final Rule and its API requirements, check out the following resources:

• API Condition and Maintenance of Certification
• Standardized API for Patient and Population Services criterion
• API Resource Guide

To learn more about APIs in practice, see Section 2.3 of this playbook.

Real World Testing

This requirement is a process by which Certified Health IT developers demonstrate, in a public and transparent way, the interoperability and functionality of their certified health IT in real-world settings and scenarios — rather than in a controlled test environment with an ONC-Authorized Testing Lab (ONC-ATL). Health IT developers with Health IT Modules certified to specific certification criteria must successfully test the real-world use of their technology for interoperability in the types of settings where the technology would be marketed.

Learn more about the Real World Testing Condition and Maintenance of Certification requirements.

Attestation

This requirement ensures that Certified Health IT developers regularly attest to the continued compliance of their products with the applicable Conditions and Maintenance of Certification requirements.

Learn more about the Attestation Condition and Maintenance of Certification requirements.

Insights

This requirement outlines specific measures for which developers must report annually to ASTP if they meet the minimum reporting qualifications and have health IT certified to the criteria specified in those measures.

Learn more about the Insights Condition and Maintenance of Certification requirements.

What is the Certified Health IT Product List (CHPL)?

The Certified Health IT Product List (CHPL) (pronounced “chapel”) is the authoritative and comprehensive list of Health IT Modules that are certified through the Certification Program. All products listed on the CHPL have been certified by an ONC-Authorized Certification Body (ONC-ACB) to meet criteria adopted by the Secretary of the U.S. Department of Health and Human Services (HHS).

The CHPL is designed to give users a streamlined interface experience — plus comprehensive search functionality and the capability to compare health IT products by certification criteria.

What can the CHPL do for you?

Health IT Modules appear on the CHPL after they've been tested under the Certification Program. Clinicians attesting that they're using CEHRT for programs such as Promoting Interoperability and the Quality Payment Program administered by CMS can use the CHPL to create a unique CMS EHR Certification ID to identify their Certified Health IT Modules for reporting purposes. During attestation, eligible clinicians and hospitals share their CMS EHR Certification ID with CMS. The CHPL generates this identifier once the clinician or hospital selects all the certified Health IT Modules that satisfy the Base EHR definition.

The CHPL also supports data accessibility of health IT certifications — in both human- and machine-readable formats. Examples include:

• Publicly available surveillance data for certified products to ensure they continue performing as expected in real-world care settings
• Detailed information about any completed usability testing of a Health IT Module

The downloadable CHPL user guide below provides information on how to:

• Understand the data available on CHPL
• Create a CMS EHR Certification ID
• Search for and compare certified health IT products
• Identify and understand certified products listed in the CHPL that do not comply with certification requirements and regulations
• Register for a CHPL API key

Download the CHPL User Guide [PDF – 971 KB].

Understand the capabilities of certified health IT

A lack of reliable information about the additional costs and fees of competing health IT products makes it hard for health IT buyers to understand and estimate the various costs and potential implementation issues. For this reason, ASTP requires health IT developers to include mandatory disclosures that will help buyers and users better understand the additional costs or fees associated with the use of certified health IT products.

Developers must display their disclosures prominently on their websites and in their marketing materials. In addition, you can find links to these disclosures as part of the CHPL.

Mandatory health IT developer disclosure statements

Under ASTP's enhanced transparency requirements, health IT developers must fully disclose all known material information concerning additional types of costs and fees that users may be required to pay when implementing or using developers' technology.

Developers must describe this information — in detailed, plain language — on their websites and in their marketing materials. This lets clinicians and users identify and understand the specific types of costs and fees that may apply.

Surveillance transparency in certified health IT

Surveillance and oversight activities have a significant role in the Certification Program, as they are critical to providing assurance that Certified Health IT Modules function as intended in a production environment and don't present safety and/or public health risks. The CHPL lets clinicians view the surveillance activities by ONC-ACBs, the results of surveillance, and corrective action plans for health IT found to have non-conformities. Surveillance data results offer clinicians a way to ensure that their Certified Health IT Modules are meeting certification requirements and performing as expected.

This transparency helps potential health IT buyers assess how certified products perform in real-world settings. It also alerts existing customers to potential issues — and the plans to resolve them.

When certified health IT products don't perform as expected in real-world care settings

An accredited certification body must be authorized by ASTP to begin issuing health IT certifications for products that meet Certification Program requirements. Once authorized, an accredited certification body is referred to as an ONC-Authorized Certification Body (ONC-ACB).

When an ONC-ACB determines that a health IT product doesn't conform to its certification requirements, it deems that health IT product non-conformant. Working with its ONC-ACB, the product developer must:

• Create an appropriate corrective action plan
• Fix the identified non-conformity or deficiency
• Bring the product back into conformance

Non-conformities are updated on the CHPL every week. In implementing their corrective action plans, developers often resolve many non-conformities or deficiencies quickly, and the CHPL will reflect that updated information. This includes the date and a description of how the developer resolved the problem.

If the developer can't resolve the issue in accordance with the corrective action plan, an ONC-ACB will follow its procedures to suspend or withdraw the product's certification. Learn more about the corrective action process.

In certain situations where a Health IT Module has a potential or known non-conformity that could present a serious risk to public health or safety — or pose special challenges for ONC-ACBs' surveillance — ASTP can choose to directly review the product's conformity to program requirements. This process is called direct review.

ASTP's direct review complements ONC-ACB surveillance and is aimed at promoting health IT developer accountability for the performance, reliability, and safety of health IT. ASTP can also initiate direct review if it has a reasonable belief that a health IT developer hasn't complied with a Conditions and Maintenance of Certification requirement.

Surveillance, direct review, and the corrective action process play a significant role in the Certification Program. They provide vital transparency and accountability about certified health IT products, their capabilities, and the certification process itself.

We encourage clinicians to use this information to evaluate and compare products and to monitor issues affecting their certified health IT.

How APIs can help your practice

If you've ever booked a flight, reserved a hotel room, or purchased a concert ticket online, you've used an API. APIs have rapidly become integral to our personal and business worlds.

At their most basic level, APIs let one software application talk to another. When, for example, you go to an airline's website to search for available flights, you're using an API that IT developers built to let your web browser access the airline's database and ticketing system.

Without that API-enabled website, you'd have to talk to a customer service rep every time you wanted to book a flight. APIs make booking travel more convenient and efficient.

You can use the following resources to learn more about how APIs can help your practice:

• API Interactive Education Module
• API Education Module Video
• Key Privacy and Security Considerations for Healthcare Application Programming Interfaces (APIs) [PDF – 522 KB]

When API meets EHR

Just as APIs have dramatically changed travel planning, API-enabled EHRs can revolutionize the health care system to decrease burden and streamline patient access to their health data. Health IT developers can build applications (e.g., mobile apps) and other innovative software products to use APIs, benefiting both patients and clinicians.

These apps have the potential to integrate information from multiple EHRs and precisely target patients' and clinicians' needs — well beyond what's currently available. Patients will be able to use apps of their choice to access their health data, while clinicians will have apps that help them take care of their patients even more effectively.

Health care payment innovations — including APMs — will depend on exchanging, aggregating, and analyzing health information. APIs will help clinicians efficiently exchange health information with other clinicians and integrate information from multiple sources in a scalable way. Tools that rely on APIs, including analytics platforms and other digital solutions, will also play an important role in clinicians' ability to succeed in innovative health care payment models.

Recognizing the growing importance of APIs, the Certification Criteria for Health IT introduced several API-based certification criteria and API Condition and Maintenance of Certification requirements under the Cures Act Final Rule. These criteria and requirements are now helping clinicians access and exchange the health information in EHRs more easily.

To learn more about the Final Rule and its API requirements, check out the following resources:

• Standards-based Application Programming Interface (API) Certification Criterion [PDF – 215 KB]
• API Resource Guide

What is information blocking?

Regulations implementing section 4004 of the Cures Act define information blocking by a health care provider, as well as by a developer of certified health IT, a health information network, or a health information exchange. In general, information blocking is a practice that is not required by law and is likely to interfere with the access, exchange, or use of EHI. Certain categories of reasonable and necessary practices specified by the HHS Secretary are regulatory exceptions that are not considered information blocking.

What are examples of practices that could constitute information blocking?

Section 4004 of the Cures Act describes certain practices that could constitute information blocking:

• Practices that restrict authorized access, exchange, or use under applicable state or federal law of such information for treatment and other permitted purposes under such applicable law, including transitions between certified health IT
• Implementation of health IT in nonstandard ways that are likely to substantially increase the complexity or burden of accessing, exchanging, or using EHI
• Implementation of health IT in ways that are likely to:
  • Restrict the access, exchange, or use of EHI with respect to exporting complete information sets or transitioning between health IT systems
  • Lead to fraud, waste, or abuse — or impede innovations and advancements in health information access, exchange, and use, including care delivery enabled by health IT

To see more examples of practices that might constitute information blocking, read the Cures Act Final Rule.

What are the information blocking exceptions?

Section 4004 of the Cures Act authorizes the Secretary of HHS to identify reasonable and necessary activities that do not constitute information blocking.

In the Final Rule, HHS identified 8 categories of reasonable and necessary activities that do not constitute information blocking, if certain conditions are met. These are known as “exceptions.” Download the Information Blocking Exceptions fact sheet [PDF – 580 KB].

The exceptions support seamless and secure access, exchange, and use of EHI and offer certain actors — health care providers, health IT developers of certified health IT, health information networks, and health information exchanges — confidence that practices that meet the conditions of an exception will not be considered information blocking. Learn more by downloading the Information Blocking Actors fact sheet [PDF – 249 KB].

A practice that does not meet the conditions of an exception would not automatically constitute information blocking. Such practices would not have guaranteed protection from civil monetary penalties or appropriate disincentives and would be evaluated on a case-by-case basis to determine whether information blocking had occurred.

Deciding if information blocking occurred in a particular case would be based on whether:

• The individual or entity engaging in the practice was an “actor”
• The claim involved EHI, as defined in 45 CFR 171.102
• The actor met the requisite knowledge standard
• The practice rose to the level of an interference under 45 CFR 171
• The practice was required by law
• The actor's practice met the conditions of an exception under 45 CFR 171

The exceptions are divided into 2 classes:

• Exceptions that involve not fulfilling requests to access, exchange, or use EHI
• Exceptions that involve procedures for fulfilling requests to access, exchange, or use EHI

Exceptions that involve not fulfilling requests to access, exchange, or use EHI

Preventing Harm Exception: It is not information blocking when an actor engages in practices that are reasonable and necessary to prevent harm to a patient or another person, provided certain conditions are met. The Preventing Harm Exception's conditions are stated in 45 CFR 171.201.

Privacy Exception: It is not information blocking when an actor does not fulfill a request to access, exchange, or use EHI to protect an individual's privacy, provided certain conditions are met.

Security Exception: It is not information blocking when an actor interferes with the access, exchange, or use of EHI to protect the security of EHI, provided certain conditions are met.

Infeasibility Exception: It is not information blocking when an actor does not fulfill a request to access, exchange, or use EHI because of the infeasibility of the request, provided certain conditions are met.

Health IT Performance Exception: It is not information blocking when an actor implements a practice that is likely to interfere with the access, exchange, or use of EHI to maintain or improve health IT performance, provided certain conditions are met.

Exceptions that involve procedures for fulfilling requests to access, exchange, or use EHI

Content and Manner Exception: It is not information blocking when an actor limits the content of its response to a request to access, exchange, or use EHI or the manner in which it fulfills a request to access, exchange, or use EHI, provided certain conditions are met.

Costs Exception: It is not information blocking when an actor charges fees, including fees that result in a reasonable profit margin, for accessing, exchanging, or using EHI, provided certain conditions are met.

Licensing Exception: It is not information blocking when an actor licenses interoperability elements for EHI to be accessed, exchanged, or used, provided certain conditions are met.

What are the potential penalties or disincentives for information blocking?

Section 4004 of the Cures Act authorizes enforcement against actors who are found to have committed information blocking. Specifically:

• Health IT developers of certified health IT and health information networks or health information exchanges that the Inspector General determines, after an investigation, to have committed information blocking shall be subject to a civil monetary penalty for all such violations. The penalty, determined by the HHS Secretary, may not exceed $1 million per violation. Such determination shall take into account factors like the nature and extent of the information blocking and the harm resulting from the information blocking. This includes, where applicable, the number of patients affected, the number of providers affected, and the number of days the information blocking persisted.
• Health care providers determined by the Inspector General to have committed information blocking shall be referred to the appropriate agency. These providers shall be subject to appropriate disincentives using authorities under applicable federal law, as the HHS Secretary sets forth through notice and comment rulemaking.

Complaints

If you believe that you or your patients have been subject to information blocking by another actor — whether another health care provider, a health IT developer of certified health IT, or a health information network or exchange — you can report it through the online Information Blocking Portal.

As specified by the Cures Act, information blocking claims and information that ASTP receives in connection with a claim or suggestion of information blocking are generally protected from disclosure under the Freedom of Information Act.

ASTP reviews all complaints under ASTP's available authorities. Once you submit a complaint, depending on the nature of your claim, we may contact you for additional information or, to the extent necessary and permitted by law, share the information you provided with other appropriate government agencies, such as the HHS Office of Inspector General.

To learn more about information blocking and the Cures Act Final Rule, check out these resources:

• Information Blocking Webinar
• Information Blocking Q&A Webinar
• Information Blocking FAQs

How to address health IT complaints and issues

If you have complaints about certified health IT products that may not be performing as they are certified to or that you believe may pose a danger to public health or safety, ASTP recommends taking the following steps: