{"id":3865,"date":"2012-12-05T11:35:02","date_gmt":"2012-12-05T16:35:02","guid":{"rendered":"http:\/\/www.healthit.gov\/buzz-blog\/?p=3865"},"modified":"2026-01-06T05:42:24","modified_gmt":"2026-01-06T05:42:24","slug":"shape-ehr-certification-process-privacy-security","status":"publish","type":"post","link":"https:\/\/healthit.gov\/blog\/privacy-and-security\/shape-ehr-certification-process-privacy-security\/","title":{"rendered":"Help Shape the EHR Certification Process for Privacy & Security"},"content":{"rendered":"\n

ONC\u2019s 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. <\/p>\n\n\n\n

Certified EHR Modules<\/h2>\n\n\n\n

Certified EHR Modules offer adopters the flexibility to select \u201cbest of breed\u201d 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.<\/p>\n\n\n\n

Combining a set of certified EHR Modules may introduce several types of security risks:<\/p>\n\n\n\n

    \n
  1. A single EHR Module on its own may not provide the security functionality an enterprise needs to comply with HIPAA;<\/li>\n\n\n\n
  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<\/li>\n\n\n\n
  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.<\/li>\n<\/ol>\n\n\n\n

    2011 Edition EHR Certification Process<\/h2>\n\n\n\n

    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\u2019 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).<\/p>\n\n\n\n

    2014 Edition EHR Certification Process<\/h2>\n\n\n\n

    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 \u201cBase EHR definition\u201d 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 \u201copenness\u201d is not currently required as part of certification).<\/p>\n\n\n\n

    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 \u2013 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.   
    <\/span><\/strong><\/p>\n\n\n\n

    ONC\u2019s Approach to the Next Edition of EHR Certification<\/h2>\n\n\n\n

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