ONC’s Certification Program includes the certification of two types of electronic health record (EHR) technology: Complete EHR and EHR Module. To meet the EHR adoption requirement to qualify for meaningful use incentive payments, an eligible professional or hospital can use either a Complete EHR, or a set of EHR Modules that collectively meets the definition of Certified EHR Technology (CEHRT).  Responsibility for assuring that a set of certified EHR Modules can be successfully and securely integrated together is left up to the adopter.

Certified EHR Modules

Certified EHR Modules offer adopters the flexibility to select “best of breed” products.  At the same time, a decision to meet the CEHRT definition by combining a set of certified EHR Modules could affect system-wide security and the consistency through which an enterprise security policy is enforced if implementers are not careful and do not fully understand the technical differences among the certified EHR Modules.

Combining a set of certified EHR Modules may introduce several types of security risks:

1. A single EHR Module on its own may not provide the security functionality an enterprise needs to comply with HIPAA;
2. The combination of certified EHR Modules may provide redundant security functionality that cannot be integrated with, and may even conflict with, enterprise security solutions within which all of the certified EHR Modules would operate; and
3. The collective, system-wide behavior of separately developed certified EHR Modules operating together may result in system behaviors that put enterprise security at risk.

2011 Edition EHR Certification Process

The 2011 Edition EHR certification process requires that EHR Modules meet all security certification criteria unless the presenter can demonstrate that certain security capabilities are either technically infeasible or inapplicable.  In too many cases, this approach has led to product developers’ implementing security functions that will never be used in actual operations, or having to generate documentation explaining why the requirements were inapplicable or technically infeasible, but providing no real value beyond the EHR certification process. Also, this approach discourages developers and implementers from taking advantage of external security services, such as those provided by enterprise security solutions (for which certification is generally not required).

2014 Edition EHR Certification Process

In response to these concerns, the 2014 Edition Standards and Certification Criteria final rule eliminated the upfront requirement for EHR Modules to be certified against the privacy and security criteria.  Rather, privacy and security criteria were made part of the “Base EHR definition” that all CEHRT must meet.  In other words, if an eligible professional or hospital elects to use a set of certified EHR Modules as its CEHRT, one or more modules in the set must meet the security criteria, and it is left up to the eligible professional or hospital to make sure the modules can interoperate securely and/or work within their overall organizational/enterprise approach to security. So an EHR Module may or may not implement privacy and security capabilities in order to be issued a certification, and from a different perspective an EHR Module that meets the Base EHR definition may or may not make its security services available to other modules (because such “openness” is not currently required as part of certification).

This potential leaves open the possibility that a certified EHR Module could interact in unexpected ways with the protection provided by another EHR technology certified to provide privacy and security services – or that privacy and security services assumed to be available from EHR technology certified to meet the Base EHR definition may not be accessible to other modules.   

ONC’s Approach to the Next Edition of EHR Certification

To help figure out the path forward, ONC tasked the Privacy and Security Workgroup of the HIT Standards Committee (HITSC) with addressing the following questions, and providing recommendations, targeted for the 2016 Edition of EHR certification.

• Should ONC’s approach stay the same for the next Edition of EHR certification?
• Are there small changes that could be made that could also have a big impact?
• For the 2016 Edition, might it be possible to require that each EHR Module be certified against some minimal set of privacy and security criteria, without imposing unreasonable regulatory burden?

HITSC’s Preliminary Recommendation

At the November HITSC meeting, the Workgroup presented its preliminary recommendation [PDF – 711 KB]:  that each EHR Module presented for certification be required to meet each of the security criteria, except Amendments and the optional criterion for Accounting of Disclosures, using one of four paths:

1)     Implement the functionality;

2)     Implement a standards-based interface to external security services to meet the functionality;

3)     Implement a non-standards-based service interface to other certified EHR technology;

4)     Document why the criterion is inapplicable or technically infeasible.

The HITSC discussed the four paths and suggested that the distinction between “standards-based” and “non-standards-based” be dropped, and replaced with a requirement for system documentation describing the interface in sufficient detail to enable integration.  The HITSC also recommended the paths be applied to all privacy and security criteria (no exceptions), since any non-applicable criteria could be addressed using path #4.

Provide Feedback on the HITSC Recommendation

We are soliciting your feedback on the following recommendation.  For 2016 Edition EHR certification, each EHR Module presented for certification should be required to meet each privacy and security criterion using one of the following three paths:

1. Demonstrate, through system documentation and certification testing, that the EHR Module includes functionality that fully conforms to the privacy and security certification criterion.
2. Demonstrate, through system documentation sufficiently detailed to enable integration, that the EHR Module has implemented service interfaces that enable it to access external services necessary to conform to the privacy and security certification criterion.
3. Demonstrate through documentation that the privacy and security certification criterion is inapplicable or would be technically infeasible for the EHR Module to meet.

Please provide your comments using the Comment function below.  Thank you.