The Office of the National Coordinator for Health Information Technology Health IT Playbook

Section 2

Certified Health IT

In this section

Learn:

How can certified health IT help my practice?

The Office of the National Coordinator for Health Information Technology (ONC) oversees the Health IT Certification Program for health IT modules — including electronic health records (EHR). The certification program sets several nationwide standards including:

Certified EHR

  • Health IT standards
  • Implementation specifications
  • Certification criteria

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

How certified health IT benefits your practice

Certain health care payment programs, including the Promoting Interoperability Programs and the Quality Payment Program, require the use of certified health IT. CMS refers to the minimum set of required certification functionalities that the health IT used by eligible clinicians must have in order to qualify for the CMS incentive programs as Certified EHR Technology (CEHRT).

Using certified health IT improves care coordination through the electronic exchange of clinical-care documents. It provides a baseline assurance that the technology 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.

Examples of ONC standards include vocabulary code sets, like SNOMED-CT®, that ensure consistent clinical terminology between systems. Standards for exchanging clinical content include Consolidated Clinical Document Architecture (C-CDA), which is discussed in section 1 of this playbook. It allows different EHR systems to electronically send and receive a patient’s clinical care summary while retaining the same meaning across systems.

To date, ONC has issued 3 editions of health IT certification criteria:

  • 2011 Edition (retired)
  • 2014 Edition
    ONC has proposed potential deregulatory actions that include the removal of the 2014 Edition from the Code of Federal Regulations (CFR) to make the 2015 Edition the baseline for health IT certification.
  • 2015 Edition

Each edition builds upon the previous version by adopting newer standards and more advanced health IT functions. The goal: continually move toward nationwide interoperability, improved clinical care, and better health information exchange.

Certified health IT can help your practice offer:

  • Electronic prescribing
  • Patient-specific education resources
  • Secure e-messaging

Certified health IT can also help your practice to:

  • Check drug-drug and drug-allergy interactions
  • Document patient social, psychological, and behavioral data
  • Denote sensitive electronic patient documents
  • Document patient care-plan preferences

Many programs and organizations encourage or require the use of health IT certified under the ONC Health IT Certification Program — in addition to the CMS quality reporting programs like the Merit Based Incentive Program (MIPS). These programs and organizations include, but are not limited to:

  • Hospital Inpatient Quality Reporting
  • Department of Defense Healthcare Management System Modernization Program
  • The Joint Commission for performance measurement initiative (“ORYX vendor” — eCQM for hospitals)
  • Prospective Payment System and Consolidated Billing for Skilled Nursing Facilities
  • Chronic care management services billing in the Medicare Physician Fee Schedule
  • Mechanized Claims Processing and Information Retrieval Systems (MMIS), which requires that state MMIS systems align with adopted standards and allow for interoperability with health information exchanges
  • Advanced Alternative Payment Models (APMs), which — under the Medicare Access and Chip Reauthorization Act of 2015 (MACRA) — must require qualifying participants to use CEHRT in order to receive the APM bonus

Certification Program Overview

Public Health IT Certification Program Overview

Overview
Describes ONC’s certification program; includes key players, operations, and structure

Who it’s for
Clinicians, health IT implementers

When it’s used
To learn the basics of ONC’s health IT certification program

Download Certification Program Overview [PDF - 692 KB]

How do ONC and CMS work together to help your practice?

In the Health Information Technology for Economic and Clinical Health (HITECH) Act, signed into law on February 17, 2009 as a part of the American Recovery and Reinvestment Act (ARRA), Congress established the EHR Incentive Programs (also known as the “Meaningful Use” Program; now known as MIPS/ACI). The HITECH Act also established ONC and its Certification Program as the principal Federal entity charged with coordination of nationwide efforts to implement and use the most advanced health information technology and electronic exchange of health information.

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

How to establish eligibility

To participate in the CMS incentive programs, clinicians must demonstrate their “meaningful use” of CEHRT. That means meeting certain requirements — such as attesting that you record patient information electronically using ONC standards and, where applicable, that you exchange patient information through a summary of care record.

ONC 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 the Merit-based Incentive Payment System (MIPS) and Advanced Alternative Payment Models (APMs).

The 2015 Edition final rule updates the ONC Health IT Certification Program to support clinicians across the care continuum including a wide range of health care settings in their efforts to increase care coordination, engage with patients, and improve outcomes.

Improving clinician access to these technical standards will help make important patient data consistently available to the appropriate people at the right time and place.

Learn more about how certified health IT can help you with:

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

To learn about what certified health IT you will need in order to participate in certain CMS programs, please visit the CMS website.

Compare health IT certification criteria

The 2014 Edition Health IT Certification Criteria (also referred to as the “2014 Edition”) is a collection of health IT certification criteria that ONC adopted under its Health IT Certification Program in 2012. ONC adopted the 2015 Edition — a more recent collection of certification criteria that builds upon the 2014 Edition — in 2015. Read more about the 2015 Edition Health IT Certification Criteria.

A certification criterion defines the specific function that the health IT, including the functionalities within an electronic health record (EHR), will perform. Sometimes certification criteria require that a functionality be performed using a specific standard. For example, the 2015 Edition “problem list” certification criterion must include a functionality that lets users record, change, and access a patient’s active-problem list using a specific version of SNOMED-CT®. Learn more about SNOMED-CT.

The 2015 Edition includes most of the health IT functionalities found in the 2014 Edition, but it upgrades standards and adds new functionalities that foster innovation and open new market opportunities. It also gives clinicians and patients more choices for electronic health information access and exchange.

The 2015 Edition also includes new certification criteria that would let your health IT (like an electronic health record) take advantage of Application Programming Interfaces (API). APIs allow clinicians to use many existing applications (or “apps”) that can take health data within the EHR and provide innovative clinical tools or help engage patients.

The table below outlines the key certification criteria categories in the 2014 and 2015 Editions.

Categories of health IT certification criteria

Criteria Categories 2014 Edition 2015 Edition
Clinical X X
Care coordination X X
Clinical quality measures X X
Privacy and security X X
Patient engagement X X
Public health X X
Utilization X  
Design and performance   X
Transport methods and other protocols   X

Learn more about the 2014 and 2015 Editions

The following downloadable guides will help you learn more about the 2014 and 2015 Editions.

2015 Edition Base EHR Definition

The 2015 Edition Health IT Certification Criteria facilitates greater interoperability for several clinical health information purposes and enables health information exchange through new and enhanced certification criteria, standards, and implementation specifications. This Edition also identifies the base EHR capabilities such as medical history, clinical decision support, and physician-order entry. Download the 2015 Edition Base EHR Definition [PDF - 291 KB].

2014 Edition EHR Certification Criteria Required to Satisfy the Base EHR Definition

Lists base EHR capabilities with corresponding 2014 certification criteria. Download the 2014 Edition EHR Certification Criteria Required to Satisfy the Base EHR Definition [PDF - 242 KB].

Comparison of the 2014 Edition & 2015 Edition Certification Criteria

Compares the 2014 and 2015 criteria in the following health IT certification categories: clinical, care coordination, clinical quality measures, privacy and security, patient engagement, public health, design and performance/utilization, transport methods, and other protocols. Download the Comparison of the 2014 Edition & 2015 Edition Certification Criteria [PDF - 512 KB].

Common Clinical Data Set: 2014 Edition Standard and 2015 Edition Standard

Lists common data sets — including information like patient name, sex, and date of birth — with their corresponding 2014 and 2015 standard requirements. Download the Common Clinical Data Set: 2014 Edition Standard and 2015 Edition Standard [PDF - 246 KB].

What is the ONC certified health IT product list?

The Certified Health IT Product List, or CHPL (pronounced “chapel”), is the authoritative and comprehensive list of health IT modules that are certified through the ONC Health IT Certification Program. All products listed on CHPL have been tested by an ONC-Authorized Testing Laboratory (ONC-ATL) and 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).

Updated in April 2016, CHPL provides a streamlined user interface, faster search functionality, improved product selection, refined user navigation, and the capability to compare health IT products by certification criteria.

What can CHPL do for you?

Health IT modules appear on CHPL after they’ve been tested and certified under the ONC Health IT Certification Program. Clinicians attesting that they’re using certified EHR technology (CEHRT) for programs such as the Medicaid EHR Incentive Program and the QPP can use CHPL to create a unique Centers for Medicare and Medicaid Services (CMS) EHR Certification ID to identify their certified health IT modules. During attestation, eligible clinicians and hospitals share their CMS EHR Certification ID with CMS. CHPL generates this number once the clinician or hospital selects all the certified health IT modules that satisfy the base EHR definition.

CHPL also supports data accessibility of health IT certifications — in both human- and machine-readable formats. Examples include publicly available surveillance data results of certified products to ensure they continue performing as expected in real-world care settings and detailed information about any usability testing that health IT module had undergone.

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 CHPL that do not comply with certification requirements and regulations
  • Register for a CHPL API key

Download CHPL User Guide [PDF - 1.9 MB].

Understand the capabilities and limitations of certified health IT

A lack of reliable information about the costs, limitations, and trade-offs of competing health IT products makes it hard for health IT buyers to understand and estimate the various costs and potential implementation issues.

ONC now requires health IT developers (including health IT and EHR vendors) to comply with enhanced transparency requirements associated with their products. These requirements include mandatory disclosures and voluntary transparency attestations that will help buyers and users better understand the capabilities and limitations of health IT products. Learn more about ONC transparency requirements.

CHPL maintains a transparency list with hyperlinks to each developer’s mandatory disclosure statement; it also indicates each developer’s response to the transparency attestation. Learn more about the transparency attestation requirement.

Developers must also display their disclosures prominently on their websites and in their marketing materials. In addition, links to these disclosures can be found on ONC’s Certified Health IT Product List.

Mandatory health IT developer disclosure statements

Under ONC’s enhanced transparency requirements, health IT developers must fully disclose all known material types of costs and limitations that users could encounter when implementing or using their technology. This includes all technical and contractual restrictions.

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 limitations and types of costs that may apply.

Transparency attestation by health IT developers

Health IT developers must also submit a transparency attestation that states whether they’ll take additional, voluntary actions to promote transparency. These voluntary actions include:

  • Engaging in an open dialogue about their business practices
  • Making information available to potential customers and others in targeted, useful ways

Developers who attest their support for transparency will be expected to provide their disclosed product-and-service information to any requestor.

ONC encourages professional associations, product researchers, and other groups to take advantage of health IT developer disclosures and transparency attestations. Doing so can help you develop information and tools that clinicians can use to evaluate and compare health IT products more effectively.

Surveillance transparency in certified health IT

Surveillance and oversight activities have a significant role in the ONC Health IT Certification Program (Program) as they are critical to providing assurance that certified complete EHRs and health IT modules function as intended in a production environment and do not present safety and/or public health risks. 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 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

ONC-Authorized Certification Bodies (ONC-ACBs) issue health IT certifications once they determine that products meet ONC Health IT Certification Program requirements. An accredited certification body must be authorized by ONC to begin certifying health IT under the program. Once authorized, an accredited body is referred to as an ONC-ACB.

When an ONC-ACB determines that a health IT product doesn’t comply with its certification requirements, it deems that health IT product non-conforming. Working with their ONC-ACB, the product developer must:

  1. Create an appropriate corrective-action plan
  2. Fix the identified non-conformity or deficiency
  3. Bring the product back into compliance

Nonconformities are updated on CHPL every week. In implementing their corrective action plans, developers often resolve many non-conformities or deficiencies quickly, and 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.

Surveillance and the corrective-action process play a significant role in the ONC Health IT 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 application programming interface (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.

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

When API meets EHR

Just as APIs have dramatically changed travel planning, API-enabled EHRs can revolutionize the health care system to decrease burden benefiting both patients and clinicians; health-IT developers can use APIs to build apps and other innovative software products.

These apps have the potential to integrate information from multiple EHRs and precisely target clinicians’ needs — well beyond what’s currently available. Clinicians will have new and powerful apps that help them take care of their patients even more effectively.

Future health care payment programs — including Alternative Payment Models — will depend on exchanging, aggregating, and analyzing health information. APIs will help clinicians exchange health information with other clinicians efficiently and integrate the information from multiple sources in a scalable way. API-based tools will also play an important role in clinicians’ ability to participate in health care payment programs.

Recognizing the growing importance of APIs, the 2015 Edition Health IT Certification Criteria includes several API-based certification criteria. Those 2015 Edition criteria are now helping clinicians access and exchange the health information in EHRs more easily.

The resource link below offers additional information about API requirements and other criteria that focused on expanding electronic health information access and exchange in the 2015 Edition.

2015 Edition Final Rule: Expanding Electronic Health Information Access and Exchange

2015 Edition Final Rule

Overview
Modifications to ONC Certification Program to support other types of health IT such as long-term post-acute care (LTPAC), behavioral health, and pediatrics

Who it’s for
Clinicians and health IT implementers

When it’s used
To support expanding health information exchange to other care settings

Download 2015 Edition Final Rule: Expanding Electronic Health Information Access and Exchange [PDF - 572 KB]

ONC recently proposed a new rule to build on the 2015 Edition API requirements. The new rule would support seamless and secure access to and exchange and use of electronic health information (EHI), as required by the 21st Century Cures Act. The proposed regulation calls on the health care industry to adopt standardized application programming interfaces (APIs), which would help individuals securely and easily access structured EHI using smartphone applications.

To learn more about the proposed rule and its reference to APIs, please visit the following resources:

Help us stop information blocking

Help the U.S. Department of Health and Human Services (HHS) identify and stop instances of information blocking. Report complaints via our online Health IT Feedback Form.

Background

In a 2015 report to Congress, the Office of the National Coordinator for Health Information Technology (ONC) provided a definition of information blocking, an analysis of the extent to which the practice exists in the industry, and recommendations to address the issue.

What is information blocking?

Section 4004 of the 21st Century Cures Act (Cures Act) defines information blocking by a health care provider, health IT developer, health information exchange, or health information network. In general, information blocking is a practice that’s likely to interfere with, prevent, or materially discourage electronic health information (EHI) access, exchange, or use information. The exception is when the practice is required by law or specified by the Secretary of Health and Human Services (HHS) as a reasonable and necessary activity.

What is Information Blocking? Graphic.

What are examples of practices that could constitute information blocking?

Section 4004 of the Cures Act specifies certain practices that may 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 information technologies
  • Implementing health information technology in nonstandard ways that are likely to substantially increase the complexity or burden of accessing, exchanging, or using EHI
  • Implementing health information technology in ways that are likely to —
    • Restrict the access, exchange, or use of EHI with respect to exporting complete information sets or in transitioning between health information technology systems, or
    • Lead to fraud, waste, or abuse, or impede innovations and advancements in health information access, exchange, and use, including care delivery enabled by health information technology

    ONC also specifies in its recent notice of proposed rulemaking (proposed rule) numerous examples of practices that may implicate the information blocking provisions. These practices include but are not limited to:

    • Imposing formal or informal restrictions on access, exchange, or use of EHI
    • Implementing capabilities in ways that limit the timeliness of access, exchange, or use of EHI
    • Imposing terms or conditions on the use of interoperability elements that discourage their use
    • Discouraging efforts to develop or use interoperable technologies or services by exercising influence over customers, users, or other persons
    • Discriminatory practices that frustrate or discourage efforts to enable interoperability
    • Rent-seeking and opportunistic pricing practices

    What are potential reasonable and necessary activities that would not constitute information blocking?

    Section 4004 of the Cures Act authorizes the Secretary of Health and Human Services to identify reasonable and necessary activities that don’t constitute information blocking. In the proposed rule, ONC has identified 7 categories of practices that would be reasonable and necessary provided certain conditions are met. These exceptions to the definition of information blocking allow for EHI to be seamlessly and securely accessed, exchanged, and used.

Notice

If you report a complaint via our online Health IT Feedback Form, we may contact you for additional information, depending on the nature of your complaint. In some instances, we may share the information you provide with other appropriate federal and state government agencies, officials, and authorities.

Please understand that, while we will endeavor to keep the information you share with us confidential, federal or state laws may require us to disclose certain information in some circumstances.

While legal and administrative constraints prevent us from responding to every complaint, we carefully review and share all information with appropriate officials. We appreciate your feedback, as it helps us to improve our awareness and ability to address health IT-related issues and challenges.

Proposed Exceptions to the Information Blocking Provisions Fact Sheets

To learn more about the 7 proposed exceptions to the information blocking definition, check out the resources below.

Protect patient safety. PDF. Click to download.

Practices that Prevent Harm [PDF – 160 KB]
Under this exemption, it would not be information blocking for an actor to engage in practices that are reasonable and necessary to prevent harm.

Promote the privacy of electronic health information. PDF. Click to download.

Privacy-Protective Practices [PDF - 164 KB]
This exemption would specify when access, exchange, or use of EHI can be limited to protect privacy.

Promote the security of electronic health information. PDF. Click to download.

Security-Related Practices [PDF – 235 KB]
This exemption would specify when access, exchange, or use of EHI can be limited for security reasons.

Allow for the recovery of costs reasonably incurred. PDF. Click to download.

Recovery of Costs Reasonably Incurred [PDF- 179 KB]
This exception would allow an actor to recover costs reasonably incurred. It explains conditions for cost recovery method and costs specifically excluded.

Excuse an actor from responding to requests that are infeasible. PDF. Click to download.

Requests that are Infeasible [PDF - 149 KB]
This exemption would make a provision for an actor who isn’t able to comply with a request or who would need to incur unreasonable costs or other burdens.

Permit the licensing of interoperability elements on reasonable and non-discriminatory terms. PDF. Click to download.

Licensing of Interoperability Elements on Reasonable and Non-discriminatory Terms [PDF – 20 6KB]
This exemption would allow an actor to limit access to an interoperability element, so long as the interoperability element is available for use by those that need it on reasonable and non-discriminatory terms.

Allow actors to make health IT temporarily unavailable for maintenance or improvements that benefit the overall performance and usability of health IT. PDF. Click to download.

Practices that Maintain and Improve Health IT Performance [PDF - 143 KB]
This exception would allow an actor to make health IT unavailable in order to undertake maintenance or improvements to the health IT.

To qualify for any of these exceptions, a regulated actor (health care provider, health IT developer, health information exchange, or health information network) would, for each relevant practice and at all relevant times, have to satisfy all of the applicable conditions of the exception.

If the actions of a regulated actor satisfy one or more of the exceptions, the actions wouldn’t be treated as information blocking and the actor wouldn’t be subject to civil penalties and other disincentives under the law.

Get a one-page summary of the exceptions [PDF – 634 KB].

What are the potential penalties and disincentives for information blocking?

Section 4004 of the Cures Act identifies potential penalties and disincentives for information blocking:

  • Health IT developers, health information networks, and health information exchanges that the Inspector General, following an investigation, determines to have committed information blocking shall be subject to a civil monetary penalty determined by the Secretary of Health and Human Services for all such violations identified through such investigation, which may not exceed $1,000,000 per violation. Such determination shall take into account factors such as the nature and extent of the information blocking and harm resulting from such information blocking, including, 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 to be subject to appropriate disincentives using authorities under applicable Federal law, as the Secretary of Health and Human Services sets forth through notice and comment rulemaking.

In its recent proposed rule, ONC included a Request for Information (RFI) regarding disincentives for health care providers.

Complaints

Information blocking complaints can be submitted through the online Health IT Complaint Form.

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

We will review your complaint under ONC’s available authorities. 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.

We request input from the public in our proposed rule on the best way to implement a standardized process for the public to submit reports on claims of information blocking that will include the appropriate information to best support the investigation of such complaints. We encourage the public to comment through the rulemaking process.

For more information on information blocking and the recent ONC proposed rule please reference the following webinar:

How to address health IT complaints and issues

If you have complaints about certified health IT products, ONC recommends taking the following steps:

  1. Contact the health IT developer or electronic health record (EHR) vendor to resolve the issue
  2. If the issue remains unresolved, contact the ONC-ACB — search the product name in the Certified Health IT Product List (CHPL) to find the issuing ONC-ACB
  3. Report any unresolved concerns about product performance or product certification using the ONC Health IT Feedback Form

Clinician Complaint Process

Step 1 Contact Developer
Work with developer to resolve issue.
If issue remains unresolved and is related to a certified capability go to step 2 - contact ONC-ACB.
Step 2 Contact ONC-ACB ONC-Authorized Certification Body
The ONC-ACB will check to see if the reported issue is applicable to one or more certified capabilities.
The ONC-ACB will work with the complainant and developer to get more information. It may also perform surveillance to determine if non-conformities exist.
If non-conformities are found, the ONC-ACB will report findings on the CHPL and will require the developer to implement a corrective action plan. If this does not resolve your issue go to step 3 – Contact ONC.
Step 3 Contact ONC
ONC will check to see if product in question is certified. If it is, we will refer the matter to the appropriate ONC-ACB at Step 2.
If developer is unresponsive, contact ONC-ACB
If ONC-ACB is unresponsive, contact ONC
Centralized Complaints System

Resources

Section 2 Recap

Take steps towards improving your practice with certified health IT.

  • Learn about certification criteria
  • Review certified health IT products
  • Use APIs to ease information exchange
  • Understand information blocking
  • Report EHR issues

Join the conversation.

Do you have a tip or suggestion for using certified health IT that's worked well in your practice? Share it here!

Content last updated on: May 31, 2019