1. Recommendations on Certification of EHR Modules HIT Standards Committee Privacy and Security Workgroup April 11, 2014

2. EHR Module Certification: 2011 – NPRM 2011 Edition certifies “Complete EHRs” and “EHR Modules,” both of which are required to meet all privacy and security criteria  EHR Module vendors complained that P&S criteria often were not applicable to their products 2014 Edition certifies “Complete EHRs” and “EHR Modules” – EHR Modules are not required to meet any P&S criteria  HITSC/PSWG asserted that providers would have no way of knowing whether any given set of EHR Modules they might choose to use would enable them to meet HIPAA P&S requirements – and suggested an alternative approach NPRM proposes to drop certification of “Complete EHRs” so that all EHR technology submitted for certification will be assessed as either an “EHR Module” (MU or Non-MU) -- requests feedback on approaches for certifying EHR Modules against privacy and security criteria, for consideration for 2017 Edition 20112014 2015- 2017 NPRM

3. December 2012: Recommendations to HITSC* 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. * Recommendation transmitted to ONC on March 23, 2013

4. December 2012: Recommendation for 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.

5. ONC Concerns re 2013 HITSC Proposal (Posnack email, 3/26/14) Paths 1 and 3 = 2011 Edition; path 2 is new Path 1 creates risk of having multiple modules with incompatible security Paths 2 and 3 don’t require technical testing – 3 was inconsistently implemented by certifiers; sometimes easier to implement poor solution than to undertake back-and-forth with certifier – Need specific processes and characteristics of what would need to be submitted “70% of 2014 Edition EHR Modules were certified to at least one P&S criterion and more than 50% of EHR Modules have been certified to 4 or more P&S criteria” … “evidence on which to judge the policy change” [DBB: Is this meaningful?] 2 things are sure: – We don't know what scope of clinical capabilities an EHR Module presented for certification will have – We don't know the existing operating environment in which future certified EHR Modules will be dropped into Suggests working Paths 1, 2, and 3 through with the Implementation WG and getting implementer feedback in addition to considering the empirical data

6. NPRM Request for Consideration for 2017 Edition Includes HITSC recommendation and seeks comment on four options for certifying EHR Modules for privacy and security: – Option 1: Re-Adopt the 2011 Edition approach – Option 2: Maintain the 2014 Edition approach – Option 3: Adopt the HITSC recommendation -- Notes that this approach “reintroduces some of the challenges we sought to avoid with our current policy and introduces potentially new administrative burdens for EHR technology developers.” – Option 4: Adopt a limited applicability approach Establish a limited set of P&S functionality that every EHR Module would be required to address in order to be certified Notes that this approach has the same downsides as options 1 and 3, but to a lesser extent given that its broad applicability could still result in EPs, EHs, and CAHs adopting EHR Modules that had been certified with duplicative capabilities.

7. Baker Informal Assessment of Relevance After examining the relevance of each P&S criterion to the functional areas addressed by EHR certification criteria, concluded that all of the P&S criteria are not strictly necessary and/or appropriate for every functional area A subset of the P&S criteria could indeed be applied to "all" EHR Modules, without diminishing the importance of the other P&S criteria with respect to the risks they address For each functional area, a minimal set of relevant P&S criteria can be identified The best fit seems to be to: Propose a minimal set of P&S criteria for each functional area For each minimal set, allow three paths to certification

8. Baker Proposal 1.Certify all EHR Modules against the following criteria: authentication, access control, and authorization; auditable events/tamper-resistance; audit record(s); and integrity. 2.If the EHR Module is being certified against one or more clinical or care coordination criteria, also certify against these criteria: automatic log-off; emergency access; and end-user device encryption. 3.If the EHR Module is being certified against one or more clinical criteria, also certify against the amendments criterion. 4.If the EHR Module is being certified against one or more public health or utilization criteria, also certify against the end-user device encryption criterion. 5.Each required criterion could be met using one of the following three paths: a)Demonstrate, through system documentation and certification testing, that the EHR Module includes functionality that fully conforms to the criterion. b)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 criterion. c)Demonstrate through documentation that the privacy and security certification criterion is inapplicable or would be technically infeasible for the EHR Module to meet.

9. John Travis Response to Criteria Partitioning Proposed minimal set and partitioning of additional subsets is generally workable Exceptions noted: File management and reporting kinds of modules would have minimal needs for role- based access controls  (DBB) Criterion does not require role-based access control – “Establish the type of access to electronic health information a user is permitted based on the unique identifier(s) provided in paragraph (d)(1)(i) of this section, and the actions the user is permitted to perform with the EHR technology.” Security products could be modules themselves  (DBB) The 3 options for demonstrating compliance should cover all of these cases Certification of multiple modules that all use same security service is uselessly repetitive; suggests allowing vendor to attest to certification of common capability for modules that use that capability  (DBB) Agree – this is what 3b offers Re encryption of end-user devices for public health and utilization criteria, seems to presume that these systems store data on end-user devices; disagrees with this assumption (DBB: Need for PSWG input)

10. Steve Posnack Email #2 Assuming we were to implement the proposed policy, will the provider wind up with Product A, Product B, and their current system, each of which may include different P&S capabilities? What implementation impacts will the proposed approach impose on providers? Would like the PSWG to get input from Implementation Workgroup