As recently as in 2019, EHR developer Greenway made the headlines by having to pay $57 million to resolve allegations of fraudulently obtaining health IT certification. Its product Prime Suite was found to not fully comply with certification requirements: Greenway modified the testing software and deceived the certification lab. A similar incident occurred in 2017 when eClinicalWorks paid $155 million for the same allegations and a $132 million penalty for not reporting patient safety issues on time.
Consequences? A danger to public health and massive losses for their clients - hospitals and clinicians - who shouldn't have received incentive payments from the government because the EHR provider was using fraudulent software.
But if there’s anything good that comes from these stories it is that certification is a big deal for all parties in this industry: The government must control how its resources are distributed, EHR developers want to stay competitive and reputable, and healthcare providers seek software that will help them give patients better care. Let’s get into the details of this certification and what it takes to comply.
What is EHR certification and when is it needed?
EHR (or Health IT) certification is a program established and run by the Office of the National Coordinator for Health Information Technology (ONC) - an organization under the Office of the Secretary for the U.S. Department of Health and Human Services (HHS). The ONC has a clear goal of encouraging hospitals to use healthcare technology that’s standardized, secure, and easy to use.
Another contributor to certification requirements is the Centers for Medicare and Medicaid Services (CMS). In 2011, it created the Electronic Health Record Incentive Program that paid incentives to hospitals for purchasing and adopting expensive EHRs. But those incentives would be paid on two conditions: An EHR must be certified by ONC and providers must demonstrate “meaningful use” of the system, or if they’re using a system as intended.
The massively successful incentive program encouraged more than 90 percent of US hospitals to use certified EHRs. Since then the CMS’ priorities changed. And in 2018, they renamed the policies Promoting Interoperability Programs, which now fights for better health information exchange. And with interoperability final rules taking effect in November 2020, standardized data exchange will become the industry norm.
Health IT certification process from criteria creation to using certified software
Source: ONC
There are currently over 900 records in the CHPL - Certified Health IT Product List. These are not complete systems but their modules and different versions of those modules as well. The list is compiled by ONC to help hospitals and professionals search and choose a certified technology.
While certification isn’t forced, it is mandatory for hospitals working with Medicare and Medicaid and receiving incentives. As for vendors, they don’t have to certify every product they create, but they choose to do so to stay in the competitive field and be listed by ONC.
Now, what makes an EHR eligible for certification and healthcare providers for incentives?
EHR certification criteria
The most recent certification criteria is their 2015 Edition. It establishes not only the capabilities of an EHR but also standards and implementation specs that should allow healthcare providers to achieve “meaningful use.” There are eight criteria categories. Let’s go through them one by one.
Eight certification criteria for health IT
Source: ONC
Clinical process - what EHR modules and features should be included
This category describes what modules and features the EHR provider must include to meet the criteria. This includes:
- Computerized provider order entry (CPOE) either for medications, laboratory or radiology ordering
- Drug-drug, drug allergy interaction checks
- Demographics (race, ethnicity, preferred language, sex, sexual orientation, gender identity, date of birth)
- Problem list
- Medication list
- Medication allergy list
- Clinical Decision Support technology
- Drug-formulary and approved drug list for a patient
- Smoking status
- Family health history
- Patient-specific education resources (articles or videos for patients)
- Implantable device lists (product recalls, outcomes)
- Social, psychological, and behavioral data (financial resource strain, education level, amount of stress, alcohol use, physical activity level, and so on).
There are no descriptions of how these modules and features should be developed or implemented, so many technical and usability principles are at the discretion of the developer. That, of course, is apart from security and design criteria that we will talk about further.
Care coordination - how patient data should be transmitted
The care coordination category establishes the procedures for exchanging patient data between different care teams, pharmacies, or third-party care systems - what documents and their contents your EHR should be able to send and receive and in what format.
The main document standard that should be supported is HL7 Consolidated Clinical Document Architecture (C-CDA) that is encoded in Extensible Markup Language (XML). It defines the structure of all clinical documents and lists all key health data about the patient in one form.
From a technical standpoint, an EHR should be able to send and receive information in one of the following protocols: IHE XDR, SMTP, POP3, and IMAP4.
Confirmation is required that an EHR can perform the following functions using the aforementioned standards:
- Transition of care from one care team to another
- Compilation of an up-to-date patient record from external data sources
- Electronic prescribing to automatically send prescriptions to a pharmacy
- Sharing a care plan
Clinical quality measurement (CQM) - reporting hospital results
Reporting clinical quality measures is one of the objectives for CMS incentive programs and how hospitals demonstrate that they’re using an EHR in a meaningful way. CQMs measure such aspects of patient care as patient engagement, safety, care coordination, public health, efficient use of resources, and so on.
An EHR should be able to record, calculate, and export quality measure results automatically and in standardized format HL7 Quality Reporting Document Architecture (QRDA).
Privacy and security - determining health data access
This criterion specifies access to health data information by office staff. The minimal requirement for certification is one-factor authentication, where each user is assigned a username, password, and permission level. Apart from that, an EHR must be able to perform the following functions:
- Record events related to health information: who accessed patient data, when, and where it was accessed, certainty that the EHR prevents users from changing or deleting these logs
- Create reports of these events
- Append amendments to health records per patients’ requests (under the HIPAA Privacy Rule)
- Set up an automating access time-out
- Allow for emergency access to patient data
- Provide patient data encryption on end-users’ devices
- Provide a message digest verifying that health data hasn’t been altered during data exchange
- Provide an assurance that health data is exchanged securely (for example, by displaying a “lock” symbol)
Patient engagement - supporting patient experience
Patients can access and send their health information in an EHR remotely. To make their experience easy, an EHR must:
- Support Web Content Accessibility Guideline (WCAG) 2.0 Level A or AA
- Support data transmitting in HL7 C-CDA format
- Allow patients to view, download, and transmit Common Clinical Data Set (their personal data), laboratory test reports, diagnostic image reports, and their inpatient settings (admission dates and locations, etc.)
- Allow patients and clinicians to exchange messages in a secure manner
- Allow clinicians access to health information from patients and support the use of patient-generated health data (PGHD)
Public health - supporting public health reporting
One of the goals of CMS’ Promoting Interoperability Programs is public health data exchange. So, hospitals should use EHRs to submit electronic public health data to at least two of the following registries of their choice:
- Immunization registries (using NDC Directory and HL7 CVX for data content and SOAP for transport)
- Public Health Agencies on Syndromic Surveillance (using either ICD-10-CM or SNOMED CT for data content and XML, SOAP, or SSL for transport)
- Public Health Agencies on Reportable Laboratory Tests and Results (using LOINC and SNOMED codes and any transport standard)
- Cancer registries (using HL7 CDA, SNOMED, and LOINC)
- Public Health Agencies on Electronic Case Reporting (using any electronic case reporting standard)
- Public Health Agencies on Antimicrobial Use and Resistance Reporting (using HL7 CDA)
- Public Health Agencies on Health Care Surveys (using NAMCS and NHAMCS survey settings)
Design and performance - easing the reporting burden
Submitting reports for CMS payment programs is a problem for many clinicians, specifically concerning manual work and calculations, error-proneness of people and systems, and complicated usability. These criteria dictate what features can ease the EHR burden:
- Support for automatic report creation with numerator and measure calculation
- Compliance with any user-centered design processes, for example, ISO and NISTIR
- A quality management system consistent with any Federal government or a standards-developing organization
- Application of any accessibility-centered design standard or clarification that an EHR doesn’t meet any accessibility standard
- Provision of data exchange capabilities via API technology (FHIR specification recommended)
Electronic exchange - transmitting messaging using Direct
Despite overwhelming EHR adoption, paper, phone, or physical data transport is still prevalent. ONC mandates EHRs to use a low-cost and practical method called the Direct Project.
How Direct data exchange works
Source: ONC
Direct technology is provided by Health Information Service Providers (HISPs). It encrypts messages and allows sending them via email, EHR, and other interfaces. To implement this technology, an EHR developer should collaborate with a Health Information Service Provider (HISP) and ensure the support for standard protocols, message formats, and processing requirements.
Now, when you find yourself compliant with all these criteria, it’s time to prove it. How do you become certified?
EHR certification process
ONC itself doesn’t take certification applications and uses third-party laboratories and certification organizations to test and make a final decision about an EHR. Not to confuse you, let’s quickly recap what organizations have a role in the certification process.
First, the Office of the National Coordinator for Health Information Technology (ONC) creates certification criteria and regulates the certification process on the highest level.
Second, an ONC-Authorized Testing Laboratory (ATL) performs EHR testing and sends test results to an ONC-Authorized Certification Body.
Third, an ONC-Authorized Certification Body (ACB) submits an EHR to the ONC website and performs regular surveillance to make sure the software remains compliant.
Finally, the Centers for Medicare and Medicaid Services (CMS) provide incentives to hospitals who use a certified EHR.
Each EHR module should be certified and tested separately and each certification criteria is tested separately as well. The most difficult and time-consuming part is passing the actual testing. If the lab finds your software compliant, it will send a test report to a certification body that will publish all EHR information on ONC’s website. But proving your compliance doesn’t stop there - it doesn’t stop at all. But let’s start from the beginning.
Testing by an ONC-Authorized Testing Laboratory (ATL)
There are currently five labs authorized by ONC to test complete EHRs and EHR modules. You can choose either one, contacting them directly to ask how the testing will be performed. Most of them have a program guide or a knowledge base as your additional source for preparing for certification.
Start by reviewing the testing procedure for all criteria you’re applying, i.e., what tools you will be using or what actions you must perform to prove the compliance.
Example of a test procedure for the Electronic exchange criteria
Let’s go through the testing process with SLI Compliance lab:
1. Register on the website and wait for a phone call or email
2. Review a services agreement and provide a non-refundable 50 percent deposit.
3. Schedule a kickoff call with your testing team and receive pre-test materials you should complete before testing starts
4. Complete and submit the following materials:
- Vendor Certification Information form
- Vendor information required for every criterion
- Self-attestation forms for completion and signature(s)
- Any additional vendor docs such as manuals, policies, etc.
- Any 3rd party tools needed to demonstrate the compliance
5. Perform remote testing via video connection. SLI Compliance requires you to simulate normal client environments: standard PC or laptop, Internet connection, normal operating conditions for your EHR.
6. Provide personnel competent in functions of your EHR to help SLI Compliance team navigate interactive testing. This will include:
- Visual verification
- Offline verification
- Tool verification done by automated testing tools
Here's what to expect next:
- SLI Compliance assigns a pass or fail status for each criterion
- SLI Compliance allows for one-time retesting of a particular problem but it can’t consult or assist vendors on obtaining successful testing
- Upon complying with all criteria, SLI Compliance will send a test report to an Authorized Certification Body (ACB) that will make a final decision.
If the test is passed, a lab will send a test report to a certification body that will publish all EHR information on ONC’s website. But maintaining the certification is a different task. Now, ACBs will be conducting ongoing surveillance to make sure your EHR remains compliant “in the field”.
Surveillance by an ONC-Authorized Certification Body
There are annual surveillance plans created for every EHR. Some surveillances are reactive - for example, if the organization becomes aware of new facts or receives a complaint. Others are randomized.
ACBs often involve developers in surveillance activities, for example, to help understand the system’s variations.
If an ACB decides that the system no longer conforms to certification requirements, the product is labeled non-conforming in the registry and a developer is notified about the finding. Then the developer and ACB create a corrective action plan to make the product compliant again. If a developer doesn't resolve an issue by the deadline, ACB will suspend or withdraw the certification.
Finally, when rolling out a new version of a product, you have to apply for certification again.
Is it worth building health IT in 2020?
Absolutely. EHR certification criteria are not strict but detail-oriented. Many technical and design decisions remain at a developer's discretion, and this fact illustrates the current situation on the health IT market.
First, there’s an abundance of offers on the market, both as complete EHRs and as separate modules. ONC allows hospitals to use a combination of systems as long as all modules are compliant with the relevant criteria. That means that EHR users can freely choose what combination of software they choose, giving developers a chance to produce software that would cater to a user's needs more than the competitor’s. This makes all EHR propositions on the market very similar in general but very different in detail - and the choice between them is increasingly complex.
Second, EHR as a technology for hospital workflow is very unpopular among clinicians. But there’s a chance to change that by introducing innovative solutions to replace their old systems. Certification doesn’t restrict EHR developers - it creates a foundation and enough space to make great software.