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

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

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

4. Review of NPRM Comments from April 8 th Meeting 4

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

6. Health IT Module Certification Requirements: Privacy & Security Security certification criteria – Section 170.315(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

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

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

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

10. 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 HL7 2010 PCAST Report *PCAST Report https://www.whitehouse.gov/sites/default/files/microsites/ostp/pcast-health-it-report.pdfhttps://www.whitehouse.gov/sites/default/files/microsites/ostp/pcast-health-it-report.pdf **S&I Framework http://wiki.siframework.org/Data+Provenance+Initiativehttp://wiki.siframework.org/Data+Provenance+Initiative ***HL7 IG for CDA Release 2 http://wiki.hl7.org/index.php?title=HL7_Data_Provenance_Project_Space andhttp://wiki.hl7.org/index.php?title=HL7_Data_Provenance_Project_Space Release 1 DSTU http://gforge.hl7.org/gf/project/cbcc/frs/?action=FrsReleaseBrowse&frs_package_id=240http://gforge.hl7.org/gf/project/cbcc/frs/?action=FrsReleaseBrowse&frs_package_id=240 C-CDA Data Provenance: 2010 – 2014 10

11. 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 *http://wiki.hl7.org/index.php?title=HL7_Data_Provenance_Project_Spacehttp://wiki.hl7.org/index.php?title=HL7_Data_Provenance_Project_Space **http://wiki.siframework.org/Data+Provenance+Charterhttp://wiki.siframework.org/Data+Provenance+Charter

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

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

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

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

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

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

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

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

20. Back Up Slides 20

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

22. Auditable Events and Tamper-Resistance : 2013 – 2015 2013 report entitled “ Not All Recommended Safeguards Have Been Implemented in Hospital EHR Technology (OEI-01-11-00570)* 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 https://oig.hhs.gov/oei/reports/oei-01-11-00570.pdfhttps://oig.hhs.gov/oei/reports/oei-01-11-00570.pdf ** 2014 HHS OIG Report http://oig.hhs.gov/oas/reports/region6/61100063.pdfhttp://oig.hhs.gov/oas/reports/region6/61100063.pdf 22

23. 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 (§170.314(d)(2)), but seeks comment on two issues – user permissions and critical auditable events 2015 NPRM 2014 NPRM 23

24. 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 § 170.210(e)(1); (B) Record the audit log status (enabled or disabled) in accordance with the standard specified in § 170.210(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 § 170.210(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