1. HIT Standards Committee Privacy and Security Workgroup Recommendations 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. Certified EHR Module 2011 Edition: Certification and Adoption Certified Complete EHR CEHRT Privacy/ Security Certified EHR Module Certified EHR Module Certified EHR Module 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. ONC HIT Certification Program Adopter is responsible for HIPAA compliance. Privacy/ Security Security Operational Environment of Meaningful Users

6. Example Modular EHRs from Current CHPL Practice Setting Product Classification ProductVendorAdditional SoftwareVersion 170.302(a) Drug-drug, drug-allergy 170.302(b) Drug formulary checks AmbulatoryModular EHRi2iTracksi2i SystemsN/A700 AmbulatoryModular EHRSmartCareEHR Streamline Healthcare Solutions, LLCN/A3.010 AmbulatoryModular EHR Cielo Clinic (Crimson Care Registry) The Advisory Board CompanyN/A2.100 AmbulatoryModular EHRThinkEHReHealthObjectsN/Av3.010 InpatientModular EHRThinkEHReHealthObjectsN/Av3.010 InpatientModular EHRCentricity PerinatalGE Healthcare 7-Zip Version 9.20 §170.302(u); File Checksum Integrity Verifier (FCIV) Version 2.05 §170.302(s)6.9000 InpatientModular EHRPicis OR ManagerPicis, now part of IngenixN/A8.101 InpatientModular EHRPicis Anesthesia ManagerPicis, now part of IngenixN/A8.101 AmbulatoryModular EHR1 Connect HePoEx EHRDarena Solutions LLC Microsoft Online Services, Microsoft InfoPath 2010; all applicable requirements201100 AmbulatoryModular EHRFlagShipMDFlagShipMD LLC510 InpatientModular EHROPUS-CriticalCare" Healthcare Clinical Consultants, dba, Theronyx Excel 2003; to output Audit Log results for §170.302.r200 AmbulatoryModular EHR InsightCS® Revenue Cycle Information System Stockell Healthcare Systems, Inc. Windows Active Directory - §170.302.q, Microsoft FCIV Tool 2.05 - §170.302.s, TrueCrypt 7.1 §170.302.u, WSFTP Professional 12.3 - §170.302.v2012.2.100 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. Certified EHR Module 2014 Edition: Certification and Adoption Certified Complete EHR Base EHR Def Certified EHR Module Base EHR Def Certified EHR Module Certified EHR Module ONC HIT Certification Program CEHRT Base EHR Def 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. Adopter is responsible for HIPAA compliance. Operational Environment of Meaningful Users

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: 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.

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: 1.Authentication, access control, and authorization 2.Auditable events and tamper resistance 3.Audit report(s) 4.Amendments 5.Automatic log-off 6.Emergency access 7.Encryption of data at rest 8.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. Certified EHR Module Proposed 2016 Edition: Certification and Adoption Certified Complete EHR Base EHR Def Certified EHR Module Certified EHR Module Certified EHR Module ONC HIT Certification Program CEHRT Base EHR Def 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. Adopter is responsible for HIPAA compliance. Operational Environment of Meaningful Users P&S Base EHR Def External P&S Certified EHR Module

15. Implications Every EHR Module presented for certification will need to address each privacy and security certification criterion in the minimal set by: 1.Implementing the required functionality OR 2.Implementing and documenting an interface to an external service that provides the required functionality OR 3.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