Dixie Baker, Chair Walter Suarez, Co-Chair December 19, 2012

1. HIT Standards CommitteePrivacy and Security WorkgroupRecommendations on Certification of EHR Modules Dixie Baker, Chair Walter Suarez, Co-Chair December 19, 2012

2. Dixie Baker, SAIC John Blair, Taconic IPA Tonya Dorsey, BlueCross BlueShield of South Carolina Mike Davis, Veterans Health Administration Lisa Gallagher, HIMSS Leslie Kelly-Hall, Healthwise Chad Hirsch, Mayo Peter Kaufman, DrFirst Ed Larsen David McCallie, Cerner Corporation John Moehrke, General Electric Wes Rishel, Gartner Kevin Stine, NIST Walter Suarez, Kaiser Permanente Sharon Terry, Genetic Alliance Privacy and Security Workgroup

3. EHR Meaningful-Use Context • HIT Certification Program: Certifies two types of Electronic Health Record (EHR) technology • Complete EHR • EHR Module • Operational Environment of Meaningful Users: To qualify for meaningful-use incentive payment, an eligible professional (EP), eligible hospital (EH), or critical access hospital (CAH) must adopt and meaningfully use Certified EHR Technology (CEHRT) • Can select either a certified Complete EHR, or a set of certified EHR Modules that collectively meets the CEHRT definition • Responsibility for assuring that a set of certified EHR Modules can successfully and securely be integrated together is left up to the adopter • Adopter is also responsible for assuring that operational environment is HIPAA compliant

4. Certification of EHR Modules: 2011 – present • 2011 Edition (i.e., current) EHR certification process requires that all EHR technology presented for certification meet all privacy and security certification criteria unless the presenter can demonstrate that required security capabilities are inapplicable or technically infeasible • If EHR technology relies on additional software to meet criteria, then that external software must be included in the EHR technology’s testing and certification, must be disclosed to customers, and is listed with the primary EHR technology on the Certified HIT Products List (CHPL) • Applied to EHR Modules, 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 certification process • Also, as the Privacy and Security Workgroup noted, this approach discourages developers and implementers from taking advantage of external security services available from the enterprise in which the certified EHR Module is implemented

5. 2011 Edition: Certification and Adoption Operational Environment of Meaningful Users ONC HIT Certification Program Certified Complete EHR EPs, EHs, and CAHs are required to adopt CEHRT by either implementing a certified Complete EHR or a set of certified EHR Modules. Adopter is responsible for assuring that a set of certified EHR Modules can be successfully and securely integrated together. CEHRT Security Certified EHR Module Certified EHR Module Certified EHR Module Certified EHR Module Privacy/Security Privacy/Security Privacy/Security Privacy/Security Privacy/Security Privacy/Security Adopter is responsible for HIPAA compliance.

6. Example Modular EHRs from Current CHPL Criteria certified against

7. Certification of EHR Modules: 2014 Edition • 2014 Edition introduced changes aimed at streamlining the certification process and reducing regulatory burden • Eliminated the requirement for EHR Modules to be certified to the privacy and security certification criteria* • Introduced “Base EHR definition” – a set of core attributes, including privacy and security, that each Certified EHR Technology (CEHRT) adopted by an eligible professional (EP), eligible hospital (EH), or critical access hospital (CAH) must meet *2014 Edition Privacy and Security certification criteria, with associated standards, are given in Appendix

8. 2014 Edition: Certification and Adoption Operational Environment of Meaningful Users ONC HIT Certification Program EPs, EHs, and CAHs are required to adopt CEHRT by either implementing a certified Complete EHR or a set of certified EHR Modules. Adopter is responsible for assuring that a set of certified EHR Modules can be successfully and securely integrated together. Certified Complete EHR Base EHR Def Base EHR Def CEHRT Certified EHR Module Certified EHR Module Certified EHR Module Certified EHR Module Base EHR Def Adopter is responsible for HIPAA compliance.

9. 2014 Edition: Base EHR Definition

10. Task Assigned to Privacy and Security Workgroup • 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? • Provide recommendations for certifying EHR Modules under the 2016 Edition of the EHR Certification Program. • Identify the minimal set of privacy and security standards and certification criteria • Anticipate future broad adoption of NSTIC-based authentication, and therefore should be compatible with the NSTIC* approach *National Strategy for Trusted Identities in Cyberspace

11. Findings and Observations • EHR certification regulations do not explicitly define “Modular EHR” • Interpreted as software that meets “less than all” EHR certification criteria • If a vendor presents for certification a Module that meets the requirements of one or more security criteria but does not address any non-security criteria, that Module can be certified under the ONC HIT Certification Program – however, we are aware of only one EHR Module that has been certified against only privacy and security criteria  • Very difficult to define a rigid test approach for certifying the broad range of possibilities that EHR Modules could present • Most certified Modular EHRs are subsets of products certified as Complete EHRs, specialty software (e.g., anesthesia, critical care), and special-purpose applications (e.g., e-prescribing, meaningful-use reporting) • For strongest security protection, each EHR Module integrated within an enterprise would use a common set of enterprise-wide security services • The Privacy and Security Workgroup agrees that having each Module implement its own security is not an ideal approach

12. Recommendations • 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: • Demonstrate, through system documentation and certification testing, that the EHR Module includes functionality that fully conforms to the privacy and security certification criterion. • 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. • Demonstrate through documentation that the privacy and security certification criterion is inapplicable or would be technically infeasible for the EHR Module to meet.    

13. Recommendations – Minimal Set • Based on the 2014 Edition of EHR Certification Criteria, we recommend the following as the “minimal set” of security functionality that every EHR Module should be required to address via one of the defined paths: • Authentication, access control, and authorization • Auditable events and tamper resistance • Audit report(s) • Amendments • Automatic log-off • Emergency access • Encryption of data at rest • Integrity Note: As new privacy and security certification criteria are adopted, this minimal set will need to be revisited. For example, the “optional” Accounting of Disclosures criterion will need to be evaluated as a potential addition to this minimal set once the final rules are issued.

14. Proposed 2016 Edition: Certification and Adoption Operational Environment of Meaningful Users ONC HIT Certification Program Certified Complete EHR EPs, EHs, and CAHs are required to adopt CEHRT by either implementing a certified Complete EHR or a set of certified EHR Modules. Adopter is responsible for assuring that a set of certified EHR Modules can be successfully and securely integrated together. Base EHR Def Base EHR Def ExternalP&S CEHRT Certified EHR Module Certified EHR Module Certified EHR Module Certified EHR Module Certified EHR Module Base EHR Def P&S Adopter is responsible for HIPAA compliance.

15. Implications • Every EHR Module presented for certification will need to address each privacy and security certification criterion in the minimal set by: • Implementing the required functionality OR • Implementing and documenting an interface to an external service that provides the required functionality OR • Documenting why the criterion is inapplicable or technically infeasible to implement • EHR Modules that implement an interface to an external service (path #2) will not need to be tested with every potential software product with which it could be integrated, but will need to be certified and delivered with documentation at a level of detail that will enable the module to be integrated with the required external service • Many EHR Modules may meet privacy and security criteria using multiple paths – e.g., path #1 (implement) for encryption, path #2 (call a service) for authentication, and path #3 (inapplicable) for amendments

16. Needs • For Modules that select paths #2 or #3 to meet specific security criteria, certifiers will need to make yes/no decisions based on quality of documentation presented with the module • To support certification via path #2, need standard identifying minimal content that must be included in the documentation; e.g., • Detailed specification of the interface and its uses (e.g., parameters expected, data structures returned, service protocol) • Named products with which Module can be integrated • Named standards implemented in the interface • To support certification via path #3, while minimizing regulatory burden, need guidance on documentation required to justify inapplicability or infeasibility • Adapt CHPL for EHR Modules to account for 3 potential paths for meeting privacy and security criteria

17. Appendix: 2014 Edition Privacy and Security Certification Criteria and Related Standards

18. 2014 Privacy and Security Certification Criteria and Related Standards