HIT Standards CommitteeHIT Standards CommitteePrivacy and Security WorkgroupPrivacy and Security Workgroup

Recommendations on Certification of EHR ModulesRecommendations on Certification of EHR Modules

Dixie Baker, ChairWalter Suarez, Co-Chair

December 19, 2012

• 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

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

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

Certified EHR Module

2011 Edition: Certification and Adoption

Certified Complete

EHR

Certified Complete

EHR

CEHRTCEHRT

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

Privacy/Security

Privacy/Security

Privacy/Security

Privacy/Security

Security

Operational Environment of Meaningful Users

Example Modular EHRs from Current CHPL

Practice Setting

Product Classification Product Vendor Additional Software Version

170.302(a) Drug-drug,

drug-allergy

170.302(b) Drug

formulary checks

Ambulatory Modular EHR i2iTracks i2i Systems N/A 7 0 0

Ambulatory Modular EHR SmartCareEHRStreamline Healthcare Solutions, LLC N/A 3.0 1 0

Ambulatory Modular EHRCielo Clinic (Crimson Care Registry)

The Advisory Board Company N/A 2.1 0 0

Ambulatory Modular EHR ThinkEHR eHealthObjects N/A v3.0 1 0Inpatient Modular EHR ThinkEHR eHealthObjects N/A v3.0 1 0

Inpatient Modular EHR Centricity Perinatal GE Healthcare

7-Zip Version 9.20 §170.302(u); File Checksum Integrity Verifier (FCIV) Version 2.05 §170.302(s) 6.90 0 0

Inpatient Modular EHR Picis OR Manager Picis, now part of Ingenix N/A 8.1 0 1Inpatient Modular EHR Picis Anesthesia Manager Picis, now part of Ingenix N/A 8.1 0 1

Ambulatory Modular EHR 1 Connect HePoEx EHR Darena Solutions LLC

Microsoft Online Services, Microsoft InfoPath 2010; all applicable requirements 2011 0 0

Ambulatory Modular EHR FlagShipMD FlagShipMD LLC 5 1 0

Inpatient Modular EHR OPUS-CriticalCare"Healthcare Clinical Consultants, dba, Theronyx

Excel 2003; to output Audit Log results for §170.302.r 2 0 0

Ambulatory Modular EHRInsightCS® 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.v 2012.2.1 0 0

Criteria certified against

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

Certified EHR Module

2014 Edition: Certification and Adoption

Certified Complete

EHR

Certified Complete

EHRBase EHR Def

Certified EHR Module

Base EHR Def

Certified EHR Module

Certified EHR Module

ONC HIT Certification Program

CEHRTCEHRT

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

2014 Edition: Base EHR Definition

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

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

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.    

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.

Certified EHR Module

Proposed 2016 Edition: Certification and Adoption

Certified Complete

EHR

Certified Complete

EHRBase EHR Def

Certified EHR Module

Certified EHR Module

Certified EHR Module

ONC HIT Certification Program

CEHRTCEHRT

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

ExternalP&SCertified

EHR Module

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

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

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

2014 Privacy and Security Certification Criteria and Related Standards