Transport & Security Standards Workgroup Notice of Proposed Rulemaking Comments Dixie Baker, Chair Lisa Gallagher, Co-Chair April 21, 2015

TopicTime Allotted Review of NPRM Comments from April 8 th Meeting30 minutes Workgroup Discussion: NPRM Comments C-CDA Data Provenance Auditable Events and Tamper-Resistance (time permitting) 50 minutes Public Comment5 minutes Agenda 2

MeetingNPRM AssignmentsRule & Reference (Public inspection version) April 8, :00pm-4:30pm ET Health IT Module Certification Requirements: Privacy & Security pp & Appendix A Automatic Access Time-Out § (d)(5): pp End-User Device Encryption § (d)(7): pp Integrity § (d)(8): pp April 21, 2015 (Tues) 3:00pm-4:30pm ET C-CDA Data Provenance pp , Auditable Events and Tamper-Resistance § (d)(2): pp , May 6, :00pm-4:30pm ET Data Segmentation for Privacy – Send/Receive § (b)(7)/ § (b)(8) pp , 390 Electronic Submission of Medical Documentation § (j)(1): pp NPRM Assignments & Workplan (HITSC – NPRM Comments Due May 20) We are here 3

Review of NPRM Comments from April 8 th Meeting 4

NPRM April 8 th Meeting Topics Health IT Module Certification Requirements: Privacy & Security – Assignment: John Hummel End-User Device Encryption – Assignment: Aaron Miri Automatic Access Time-Out Integrity 5

Health IT Module Certification Requirements: Privacy & Security Security certification criteria – Section (d) (1) Authentication, access control and authorization (2) Auditable events and tamper-resistance (3) Audit reports (4) Amendments (5) Automatic access time-out (6) Emergency access (7) End-user device encryption (8) Integrity

Security Applicability Table Excludes (8) integrity. Is this an oversight? Excludes (4) amendments only. OK? Excludes all of (g) Design & Performance. This section includes Application Access to Common Clinical Data Set, but it is not context-specific, and it includes its own security criteria. OK?

End-User Device Encryption Passwords – Org. flexibility; 2fx authentication; PW length; market development around PW strength Encryption keys – Organizational policies driven by risk assessment – Focus: capability to change keys v. frequency – Flexibility: data at rest (SAN layer / layer 1) v. application layer

Workgroup Discussion: NPRM Comments CCDA Data Provenance Auditable Events and Tamper-Resistance (time permitting) 9

2010 President’s Council of Advisors on Science and Technology (PCAST) Report “Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans”* 2014 Standards and Interoperability (S&I) Framework** 2014 HL7 IG for CDA Release 2: Data Provenance and Release 1 (US Realm) (DSTU)*** 2014 S&I Framework 2014 HL PCAST Report *PCAST Report **S&I Framework ***HL7 IG for CDA Release 2 andhttp://wiki.hl7.org/index.php?title=HL7_Data_Provenance_Project_Space Release 1 DSTU C-CDA Data Provenance: 2010 –

The HL7 IG for CDA Release 2: Data Provenance, Release 1 (US Realm) standard was published as a DSTU for the September 2014 ballot.* The S&I Data Provenance Community identified 11 different standards**, just within HL7, that may describe provenance related requirements or events. Most of these are normative, final standards (such as the CDA itself). The S&I project therefore proposed this standard be developed, with the goal of building on provenance related requirements from existing standards, and compiling them into a single standard which can be used as an “overlay” to address provenance for the CDA. 11 HL7 IG for CDA Release 2: Data Provenance, Release 1 (US Realm) Maturity * **

The HL7 IG for CDA R2: Data Provenance DSTU standard is an Implementation Guide, and contains templates describing conformance for different types of provenance events such as: – “Assembling” existing data into a new artifact, based on a predetermined algorithm – “Composing” derivative information from a subset of the available information (choosing / selecting certain things to include) The HL7 CDA DPROV IG will be able to be used with existing standards to help ensure the data elements being transmitted are constrained to ensure provenance information is captured. 12 HL7 IG for CDA Release 2: Data Provenance, Release 1 (US Realm) Appropriateness

The HL7 DPROV IG may be useful in addressing the challenge of identifying where the multiple sources of information originally came from – such as VDT information provided to a patient. – For example, a provider may have used information from multiple sources (personal fitness device, consult, etc.,) to compose something new, which is then made available through VDT. – It would be useful for subsequent receivers of that information (e.g. another provider receiving it through ToC) to know what the sources of the original data were (e.g. the personal fitness device), rather than just “this came to me from a provider”. The HL7 DPROV IG will increase traceability to original sources of data by utilizing capabilities in existing standards. 13 HL7 IG for CDA Release 2: Data Provenance, Release 1 (US Realm) Usefulness

C-CDA Data Provenance ONC seeks comment on the following: – Maturity and appropriateness of HL7 IG for the tagging of health information with provenance metadata in connection with C-CDA – Usefulness of the HL7 IG in connection with certification criteria, such as ToC and VDT certification criteria 14

Workgroup Discussion: NPRM Comments CCDA Data Provenance Auditable Events and Tamper-Resistance (time permitting) 15

Auditable Events and Tamper-Resistance NPRM proposes no change to “auditable events and tamper-resistance” criterion, but seeks comment on the following: – Modify/Add auditing standard to require change of user privileges to be audited; any recommended standards to use – Whether a critical subset of auditable events should remain enabled at all times (Specific questions on following slides) 16

Change in user privileges: ONC seeks comment on: – Whether ONC must explicitly modify/add to the overall auditing standard […] to require change of privileges to be audited or if this event is already audited at the point of authentication – Any recommended standards to be used in order to record these additional data elements Auditable Events and Tamper-Resistance 17

Critical Subset of Auditable Events: ONC seeks comments on : – Whether there is a critical subset of auditable events that ONC should require remain enabled at all times, and if so, additional information regarding which events should be considered critical and why – Whether there is any alternative approach that ONC could or should consider – Whether any negative consequences may arise from keeping a subset of audit log functionality enabled at all times Auditable Events and Tamper-Resistance 18

Workgroup Discussion: Topics For May 6 Data Segmentation for Privacy (DS4P) Electronic Submission of Medical Documentation (esMD) Next Set of NPRM Topics 19

Back Up Slides 20

C-CDA Data Provenance Data Provenance Task Force – January 2015 brief to HITSC Question presented: – Given the community-developed S&I Data Provenance Use Case, what first step in the area of data provenance standardization would be the most broadly applicable and immediately useful to the industry? Question 3: Are there any architecture or technology specific issues for the community to consider: – Content: Refining provenance capabilities for CDA/C-CDA while supporting FHIR? – Consider related work in HL7 projects: CDA/C-CDA provenance, FHIR Provenance Project, Privacy on FHIR Projects 21

Auditable Events and Tamper-Resistance : 2013 – report entitled “ Not All Recommended Safeguards Have Been Implemented in Hospital EHR Technology (OEI )* Keep audit log operational during updates or viewing HHS Office of Inspector General (OIG) released a report entitled “The Office of the National Coordinator for Health Information Technology’s Oversight of the Testing and Certification of Electronic Health Records.”** Failure to address logging emergency access or user privilege changes 2014 HHS OIG 2013 HHS OIG *2013 HHS OIG Report ** 2014 HHS OIG Report 22

Auditable Events and Tamper-Resistance : 2013 – 2015 Continued 2014 Edition “auditable events and tamper-resistance” certification criterion requires that health IT technology must be able to record additions, deletions, changes, queries, print, copy, and access. NPRM proposes to adopt a 2015 Edition “auditable events and tamper-resistance” certification criterion that is unchanged re: the 2014 Edition (§ (d)(2)), but seeks comment on two issues – user permissions and critical auditable events 2015 NPRM 2014 NPRM 23

2015 Edition Health IT Certification Criterion: (2) Auditable events and tamper-resistance (i)Record actions. Technology must be able to: (A) Record actions related to electronic health information in accordance with the standard specified in § (e)(1); (B) Record the audit log status (enabled or disabled) in accordance with the standard specified in § (e)(2) unless it cannot be disabled by any user; and (C) Record the encryption status (enabled or disabled) of electronic health information locally stored on end-user devices by technology in accordance with the standard specified in § (e)(3) unless the technology prevents electronic health information from being locally stored on end-user devices (see paragraph (d)(7) of this section). (ii) Default setting. Technology must be set by default to perform the capabilities specified in paragraph (d)(2)(i)(A) of this section and, where applicable, paragraph (d)(2)(i)(B) or (C) of this section, or both paragraphs (d)(2)(i)(B) and (C). (iii) When disabling the audit log is permitted. For each capability specified in paragraphs (d)(2)(i)(A) through (C) of this section that technology permits to be disabled, the ability to do so must be restricted to a limited set of users. (iv) Audit log protection. Actions and statuses recorded in accordance with paragraph (d)(2)(i) of this section must not be capable of being changed, overwritten, or deleted by the technology. (v) Detection. Technology must be able to detect whether the audit log has been altered. Proposed: Auditable Events and Tamper-Resistance 24