1 / 99

Meaningful Use Stage 2 Security and Privacy Requirements

Meaningful Use Stage 2 Security and Privacy Requirements. Kathleen Connor VA (ESC) HL7 Security WG April 2012. Table of Contents. Presentation Purpose.

kaipo
Télécharger la présentation

Meaningful Use Stage 2 Security and Privacy Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Meaningful Use Stage 2 Security and Privacy Requirements Kathleen Connor VA (ESC) HL7 Security WG April 2012

  2. Table of Contents

  3. Presentation Purpose • HL7 Policy Committee requests that Security and CBCC Work Group review and provide comment on the Meaningful Use Stage 2 Certification Criteria & Incentive NPRMs • Each of the Security and Privacy related provisions are in the following table with Proposed HL7 Response for approval by the Work Groups • Each relevant provision is listed (hyperlink to slides in TOC), and background from NPRM discussion and other sources are provided for background • Please review citations, questions, and proposed responses for Work Group discussions

  4. Overarching Collaboration Statement • HL7 notes several certification criteria that would likely benefit from and enhance the MU Stage 2 value proposition through cross-SDO development of semantically interoperable standards, e.g., • Structured CDA templates and supporting clinical, administrative, security, and privacy vocabularies for encoding: • Nationally recognized Advance Directive forms • Accounting of Disclosures and Access Reports • Privacy and Security encoded policies that receiving systems can consistently consume and enforce • Privacy and Security codes that enable annotation of specially protected information for purposes of data segmentation and restricting disclosure to authorized users for specified purposes

  5. General HL7 Response to Privacy and Security Certification Criteria • HL7 recommends that Privacy and Security Certification Criteria require the use of standard formats and vocabularies that align across related criteria such as: • Authentication, Access Control, and Authorization • Auditable Events • Audit Reports • Emergency Access • Accounting of Disclosure

  6. General HL7 Response to Privacy and SecurityIncentive NPRM • HL7 recommends that the MU Stage 2 Measure: • Conduct a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1) • Specifically include (in addition to Encryption of Data at Rest) a security risk analysis of and risk mitigation for the technological approach each EP, EH, or CAH chooses to meet the following certification criteria: • Authentication, Access Control, Authorization • Auditable Events and Tamper Resistance • Audit Reports • Emergency Access • Integrity • Secure Messaging • Amendments • Batch Exports of Patient Records

  7. Certification Criteria § 170.314(d)(1) Authentication, Access Control, and Authorization

  8. Authentication, Access Control, and AuthorizationMU Objective (Pages 95 – 96) MU Objective Protect electronic health information created or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities. 2014 Edition EHR Certification Criterion § 170.314(d)(1) (Authentication, access control, and authorization)

  9. Authentication, Access Control, and AuthorizationDiscussion on Approach (Pages 95-96) • Merged Authentication and Access control criteria • Capability to authenticate human users would consist of the assertion of an identity and presentation of at least one proof of that identity • Focus on users that would be able to access electronic health information in EHR technology and • Does not include external users that may make requests for access to health information contained in the EHR technology for the purpose of electronic health information exchange

  10. Authentication, Access Control, and AuthorizationDiscussion about Standards (Pages 95-96) Example standards and implementation specifications which could be followed in designing EHR technology to meet this certification criterion could include, but are not limited to: • NIST Special Publication 800-63, Level 2 (single-factor authentication) • ASTM, E1986-09 (Information Access Privileges to Health Information)

  11. Authentication, Access Control, and AuthorizationMerged 2011 Edition Criteria Page 106 45 CFR § 170.302 General certification criteria for Complete EHRs or EHR Modules. • (o) Access control. Assign a unique name and/or number for identifying and tracking user identity and establish controls that permit only authorized users to access electronic health information • (t) Authentication. Verify that a person or entity seeking access to electronic health information is the one claimed and is authorized to access such information.

  12. Authentication, Access Control, and AuthorizationCertification Criteria (Page 172) (d) Privacy and security. (1) Authentication, access control, and authorization. (i) Verify against a unique identifier(s) (e.g., username or number) that a person seeking access to electronic health information is the one claimed; and (ii) 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.

  13. Authentication, Access Control, and Authorization Questions • Do we support merged Authentication and Access Control criteria? • Do we agree with no focus on authentication of external users? • What about authenticating patients per § 170.210 (3) Ambulatory setting only—secure messaging. Enable a user to electronically send messages to, and receive messages from, a patient in a manner that ensures: • (i) Both the patient and EHR technology are authenticated; and • (ii) The message content is encrypted and integrity-protected in accordance with the standard for encryption and hashing algorithms specified at § 170.210(f).

  14. Authentication, Access Control, and AuthorizationQuestions • Do we agree that verifying “against a unique identifier(s) (e.g., username or number) that a person seeking access to electronic health information is the one claimed” is sufficient for Authenticating the user? • Do we agree with these example standards? • Are there others? ASTM, E1986-09 includes data objects and roles, some of which are mapped so SNOMED; and a subset of which was adopted by HITSP C80 and NHIN. Without more specificity, difficult to ascertain the adequacy of this standard when tested for certification. • Should Final Rule require adoption of the privacy and security standard vocabularies for Authentication, Access Control, and Authorization such as HL7 Confidentiality Codes, Data Operations Code System, RBAC Permissions Catalog Identifier Codes, Act Privacy Policy, Information Sensitivity, Purpose of Use, Obligation, and Refrain Policy?

  15. Authentication, Access Control, and Authorization Proposed HL7 Comments/Recommendations HL7 requests clarification on whether the criteria is: • Applies to internal system and/or human users • Applies to external system and/or human users that are recipients of “push” type health information exchanges such as those required for in the Incentive NPRM • Excludes all external system and/or human users HL7 notes the lack of lacks interoperable vocabulary standards by which to: • Consistently specify electronic health information as distinguishable security objects • Specify whether the access is at a coarse or fine grain level as would like be required for data segmentation for privacy • Encoding the actions in a consistent and meaningful manner • Specify an interoperable value set of standard Structural and Functional Roles These gaps impact the computability and human readable utility of the related audit reports and the accounting of disclosure certification criteria.

  16. Authentication, Access Control, and Authorization Proposed HL7 Response Recommend that the Final Rule: • Require that this Certification Criteria apply to external users with which Secure Messaging is conducted • Require adoption of the privacy and security standard vocabularies such as: • HL7 Confidentiality Codes • HL7 Data Operations Codes • HL7 RBAC Permissions Catalog Codes • HL7 US Privacy Law, Information Sensitivity, Purpose of Use, Obligation, and Refrain Policy Act Codes • HL7 Information Category Codes to denote information categories • Clinical Terminologies to denote information objects • ASTM E1986 Structural Role value set (constrained to meet the criteria requirements), and HL7 Participation Function codes associated with permissions, such as those encoded by the HL7 RBAC Permission Catalog to denote Security Roles to augment Unique User Identifiers, which may be associated with many roles • HL7 Data Types to encode User Identification • Where there are gaps, ONC should work with relevant SDOs such as ISO, HL7, ASTM, OASIS XSPA, and IHE to develop standards needed to fully implement Authentication, Access Control, and Authorization capabilities in EHRs.

  17. Revised Standard § 170.210(e) Certification Criteria § 170.314(d)(2) Auditable Events & Tamper Resistance

  18. 170.314(d)(2)Auditable Events & Tamper ResistanceDiscussion (Page 77-79) MU Objective Protect electronic health information created or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities. 2014 Edition EHR Certification Criteria § 170.314(d)(2) (Auditable events and tamper-resistance) § 170.314(d)(3) (Audit report(s)) Standard § 170.210(e) (Record actions related to electronic health information, audit log status, and encryption of end user devices)

  19. 170.314(d)(2)Auditable Events & Tamper ResistanceDiscussion (Page 77-79) Recommend for clarity that we move the specific capability “detection” from the Integrity criterion to the proposed auditable events and tamper-resistance criterion • More stringent audit logs certification policy will assist with better detection and investigation of breaches • Audit log must be: • Enabled by default (i.e., turned on) • Immutable (i.e., unable to be changed, overwritten, or deleted), • Able to record not only which action(s) occurred, but more specifically the electronic health information to which the action applies • Have ability to enable and disable the recording of actions be limited to an identified set of users (e.g., system administrator)

  20. Auditable Events & Tamper ResistanceDiscussion (Page 77-79) To Accommodate 170.314 (d)(2) proposing • Revised standard at §170.210(e) • Requiring that: • When the audit log is enabled or disabled, must record • Date and Time (in accordance with the standard specified at § 170.210(g) (synchronized clocks)) • User identification • Action(s) that occurred • When encryption for end-user devices managed by EHR technology is enabled or disabled, must record • Date and Time (in accordance with the standard specified at § 170.210(g) (synchronized clocks)) • User identification • Action(s) that occurred

  21. Auditable Events & Tamper ResistanceDiscussion (Page 77-79) • Did not use “security-relevant events” because ambiguous • Proposed minimum set of (testable) actions required to be captured • Example implementation specification: • ASTM E2147-01, Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems

  22. Auditable Events and Tamper-ResistanceRevised standard at § 170.210(e)(Page 161-162) (e) Record actions related to electronic health information, audit log status, and encryption of end-user devices. (1) When EHR technology is used to create, change, access, or delete electronic health information, the following information must be recorded: (i) The electronic health information affected by the action(s); (ii) The date and time each action occurs in accordance with the standard specified at §170.210(g); (iii)The action(s) that occurred; (iv)Patient identification; and (v) User identification.

  23. Auditable Events and Tamper-ResistanceRevised standard at § 170.210(e)(Page 161-162) (2) When the audit log is enabled or disabled, the following must be recorded: (i) The date and time each action occurs in accordance with the standard specified at §170.210(g); and (ii) User identification. (3) As applicable, when encryption of electronic health information managed by EHR technology on end-user devices is enabled or disabled, the following must be recorded: (i) The date and time each action occurs in accordance with the standard specified at §170.210(g); and (ii) User identification.

  24. Auditable Events and Tamper-Resistance Certification Criteria(Page 172 – 173) (2) Auditable events and tamper-resistance. (i) Enabled by default. The capability specified in paragraph (d)(2)(ii) of this section must be enabled by default (i.e., turned on) and must only be permitted to be disabled (and re-enabled) by a limited set of identified users. (ii) Record actions. Record actions related to electronic health information, audit log status and, as applicable, encryption of end-user devices in accordance with the standard specified in § 170.210(e). (iii) Audit log protection. Actions recorded in accordance with paragraph (d)(2)(ii) must not be capable of being changed, overwritten, or deleted. (iv) Detection. Detect the alteration of audit logs.

  25. Auditable Events and Tamper-Resistance Questions • Detection capabilities seems to be restricted to detecting alteration of audit logs • Is Integrity tamper resistance sufficient for detecting alterations of data? • What other security risks need detection capabilities? • Is ASTM E2147-01, Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems the only and/or most relevant standard? • Is the Synchronized Clock standard sufficient (see notes) • Should there be standardized methods for recording: • Information Objects • User Identification and Roles • Date and Time • Actions (e.g., HL7 Data Operations code system)?

  26. Auditable Events and Tamper-ResistanceProposed HL7 Response • Auditable Events are critical for enforcing all aspects of Security System, not just detecting alteration of Audit Log, and integral to Access Reports and Accounting for Disclosure. • Recommend that standard vocabularies required for the Authentication, Access Control, and Authorization criteria be used for managing and recording Auditable Events including: • Clinical Terminologies and HL7 Information Category codes to denote information objects • HL7 Data Operations Codes to denote “actions” • ASTM E1986 Structural Role value set (constrained to meet the criteria requirements) ; and HL7 Participation Function Codes associated with Security Permissions such as conveyed by the HL7 RBAC Permissions Catalog Codes to supplement User Identification where a User may play more than one role • HL7 Data Types to encode User Identification • Where there are gaps, ONC should work with relevant SDOs such as ISO, HL7, ASTM, OASIS XSPA, and IHE to develop standards needed to fully implement Authentication, Access Control, and Authorization capabilities in EHRs.

  27. § 170.210 (e)(2) Standard Certification Criteria § 170.314(d)(3) Audit Reports

  28. 170.314(d)(3) Audit ReportsDiscussion (Pages 77-79) • Recommend for clarity that we move the specific capability “detection” from the Integrity criterion to the proposed auditable events and tamper-resistance criterion.

  29. Audit Reports§ 170.210 (e)(2) Standard (Pages 161) (2) When the audit log is enabled or disabled, the following must be recorded: (i) The date and time each action occurs in accordance with the standard specified at §170.210(g); and (ii) User identification.

  30. Audit ReportsCertification criteria (Page 172) Enable a user to create an audit report for a specific time period and to sort entries in the audit log according to each of the elements specified in the standard at §170.210(e)(2): (2) When the audit log is enabled or disabled, the following must be recorded: (i) The date and time each action occurs in accordance with the standard specified at §170.210(g) {Synchronized Clocks}; and (ii) User identification.

  31. Audit ReportsQuestions • Is Integrity tamper resistance sufficient? • What other security risks need detection capabilities? • Is the Synchronized Clock standard §170.210(g) sufficient for documenting Date and Time in a manner that is human readable and can be used in Accounting of Disclosures? • Are the following Audit Report Data Elements sufficient? (i) The date and time each action occurs in accordance with the standard specified at §170.210(g); and (ii) User identification. • E.g., does the User Role, Information Object, Action, and perhaps other Context or Permission information need to be recorded?

  32. Audit ReportsProposed HL7 Response • HL7 notes that the Audit Report Synchronized Clock standard Date and Time be aligned with the Date and Time standards used for other Security Certification Criteria, e.g., • Access Control and Authorization especially where these are governed by time and date sensitive context constraints • Accounting of Disclosure standard data elements for time and date • HL7 requests clarification on whether the following Audit Report Data Elements are sufficient adequately informing end-users about Auditable Events and for populating Accounting of Disclosures: (i) The date and time each action occurs in accordance with the standard specified at §170.210(g); and (ii) User identification. • Specification, do the User Role, Information Object, Action, and perhaps other Context or Permission information also need to be recorded? • If so, HL7 recommends that ONC consider encoding this information with computable, interoperable, and human readable vocabulary and formats that align with those HL7 recommends for § 170.314(d)(2) Auditable events and tamper-resistance certification criteria.

  33. Certification Criteria 170.314(d)(4) Amendments

  34. 170.314(d)(4) AmendmentsDiscussion (Page 25-26) • MU Objective • Protect electronic health information created or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities • Enable compliance with HIPAA Privacy Rule Amendment requirements [45 CFR 164.526 See Notes below]

  35. Amendments - Summary (i) Enable a user to electronically amend a patient’s health record to: (A) Replace existing information in a way that preserves the original information; and (B) Append patient supplied information, in free text or scanned, directly to a patient’s health record or by embedding an electronic link to the location of the content of the amendment. (ii) Enable a user to electronically append a response to patient supplied information in a patient’s health record.

  36. AmendmentsRequested Comments (Page 26) We specifically request comment on whether EHR technology should be required to be capable of appending patient supplied information in both free text and scanned format or only one or these methods to be certified to this proposed certification criteria.

  37. Amendments Certification Criteria(Page 173) (i) Enable a user to electronically amend a patient’s health record to: (A) Replace existing information in a way that preserves the original information; and (B) Append patient supplied information, in free text or scanned, directly to a patient’s health record or by embedding an electronic link to the location of the content of the amendment. (ii) Enable a user to electronically append a response to patient supplied information in a patient’s health record.

  38. AmendmentsQuestions • What’s the difference between free text and scanned format? • While Amendments are included with Privacy and Security Criteria, are there Privacy and Security concerns that should be addressed? • E.g., Security concerns related to embedding an electronic link to the location of the content of the amendment

  39. AmendmentsProposed HL7 Response • HL7 recommends that the Amendment certification criteria reference the need to include Amendment technology, such as inclusion of hyperlinked Amendments, in the HIPAA Security Risk Assessment conducted as part of the MU Stage 2 Incentive program.

  40. Certification Criteria § 170.314(d)(5) Automatic Log-off

  41. § 170.314(d)(5) Automatic Log-offMU Objective (Page 96-97) MU Objective Protect electronic health information created or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities. 2014 Edition EHR Certification Criterion § 170.314(d)(5) (Automatic log-off)

  42. § 170.314(d)(5) Automatic Log-offDiscussion (Page 96-97) • Clarifies that to terminate a session should not be confused with locking a session, where access to an active session is permitted after reauthentication. • Not revising or refining this certification criterion, but are clarifying that to terminate a session should not be confused with locking a session, where access to an active session is permitted after re-authentication. • EHR technology must have the capability to terminate the session, including terminating the network connection.

  43. Automatic Log-off Certification criteria (Page 173) (5) Automatic log-off. • Terminate an electronic session after a predetermined time of inactivity.

  44. Automatic Log-offQuestions • Do we have concerns about EHR technology maturity wrt to the capability to terminate the session, including terminating the network connection?

  45. Automatic Log-offProposed HL7 Response • HL7 supports the certification criteria for Automatic Log-off.

  46. Certification Criteria 170.314(d)(6) Emergency Access

More Related