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

TopicTime Allotted Review of NPRM Comments from April 21 st Meeting20 minutes Workgroup Discussion: NPRM Comments Data Segmentation for Privacy (DS4P) Electronic Submission of Medical Documentation (esMD) 60 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 21 st Meeting 4 REVIEW OF NPRM COMMENTS

NPRM April 21 st Meeting Topics C-CDA Data Provenance Auditable Events and Tamper-Resistance Privacy and Security Applicability 5

HITSC Readiness Evaluation and Classification Criteria for Technical Specifications Emerging Standards Pilots National Standards Adoptability Maturity Low Moderate High Maturity Criteria: Maturity of Specification Maturity of Underlying Technology Components Market Adoption Adoptability Criteria: Ease of Implementation and Deployment Ease of Operations Intellectual Property Source: nl full.pdf?%2520ijkey=8oAq1ZTZyQ6edqC&keytype=ref nl full.pdf?%2520ijkey=8oAq1ZTZyQ6edqC&keytype=ref The Metrics the HITSC has adopted for helping to determine when a technology specification is ready to become a national standard. 6

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 (e.g. transition of care (ToC) and VDT criteria) HL7 DPROV IG Maturity – HL7 DPROV IG may be useful in identifying the origin of multiple sources of information – What about market adoption and adoptability criteria? 7

Auditable Events and Tamper-Resistance Change of privileges: – Should ONC explicitly modify/add to the auditing standard […] to require change of privileges to be audited (or is this already audited at the point of authentication)? 8

The Big Issue w.r.t. Auditing Criteria § (h) of the 2014 Edition specifies ASTM E as the certification standard for audit log content – Section 5 specifies that the audit log is a “record of actions (queries, views, additions, deletions, changes) performed on data by users” – it does not specify that the audit log should record “all security-relevant events” – Events such as creation/deletion of an account, login attempts, adding a network connection, and “changes in privileges” are not specified as auditable events – Need to recommend a standard that requires that the full range of security-relevant events be auditable Is there a standard we can cite? If not, do we know of an example we might use as a model? 9

Should a critical subset of events be enabled at all times? Currently, audit logs can be disabled (must identify when, by whom, and restricted set of users) ONC again asks: Is there is a critical subset of auditable events that should never be disabled (and why?) Is there any alternative approach ONC could or should consider? What are any negative consequences of keeping a subset of audit log functionality enabled at all times? The Workgroup addressed these issues in April 2014 Auditable Events and Tamper-Resistance 10

Auditable Events and Tamper-Resistance Straw comments for discussion: With regard to disabling audit logs, the PSWG suggests no change from the 2014 Final Rule. The current criteria adequately function as a floor for meaningful use 11

WORKGROUP DISCUSSION: NPRM COMMENTS Workgroup Discussion: NPRM Comments Data Segmentation for Privacy (DS4P) Electronic Submission of Medical Documentation (esMD) 12

Proposed: Data Segmentation for Privacy (DS4P) ONC proposes to adopt two new certification criteria that would focus on the capability to separately track (“segment”) sensitive health information – Data Segmentation for Privacy: Send – Data Segmentation for Privacy: Receive 13

Data segmentation for privacy – send – Technology must enable a user to create a summary record formatted in accordance with each of the standards adopted in § (a)(3) and (4) that is tagged as restricted and subject to restrictions on re-disclosure according to the standard adopted in § (o)(1). Comment on: inclusion in the 2015 Edition Proposed: Data Segmentation for Privacy – Send § (b)(7) 14

Data segmentation for privacy – receive – Technology must enable a user to: Receive a summary record that is tagged as restricted and subject to restrictions on re- disclosure according to the standard adopted in § (o)(1); Apply document-level tagging and sequester the document from other documents received; and View the restricted document (or data), without incorporating the document (or data). Comment on: inclusion in the 2015 Edition Proposed: Data Segmentation for Privacy – Receive § (b)(8) 15

WORKGROUP DISCUSSION Workgroup Discussion: NPRM Comments Data Segmentation for Privacy (DS4P) Electronic Submission of Medical Documentation (esMD) 16

Proposed: Electronic Submission of Medical Documentation (esMD) NPRM proposes four capabilities: 1.Capability 1 – Create a document 2.Capability 2 - Embed digital signatures in C-CDA documents 3.Capability 3 - Create and transmit “external digital signatures” using W3C XADES standard 4.Capability 4 - Create and transmit digital signatures that assure both data integrity and non-repudiation 17 Comment on: inclusion of capabilities in the 2015 Edition

Proposed Proposed: Electronic Submission of Medical Documentation (esMD) - Continued Summary of Concerns (July/August 2013) July/August 2013 –Proposed esMD digital signature standard different from DEA standard for electronic prescribing of controlled substances Would require significant changes to existing administrative and clinical workflows to incorporate into the specification 18 Source: Source: 08_standards_ps_co_transcript_final.pdfhttp://healthit.gov/archive/archive_files/HIT%20Standards%20Committee/2013/Privacy%20%26%20Security/ / _standards_ps_co_transcript_final.pdf

esMD and DEA Digital Signatures esMD and DEA use the same digital signature standards, but different revisions – FIPS 186-2, (esMD); FIPS 186-3, (DEA) – Superseded by FIPS 186-4, (new algorithms) esMD has additional requirements – Multifactor authentication (NIST LOA 3) – 10-minute inactivity time out – System time sync with NIST source 19 *Source: *Source:

Workgroup Discussion: Topics For May 19 Possibly reschedule for week of May 11 to finalize comments Next Workgroup Meeting– New Topics 20

Back Up Slides 21 BACK UP SLIDES

C-CDA Data Provenance - Continued HL7 Leverages 11 existing standards (in bold): – HL7 Clinical Documentation Architecture Release 2 (CDA R2) – HL7 Version 2 Vocabulary & Terminology Standards – HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1 – HL7 FHIR DSTU Release 1.1 Provenance Resource – W3C PROV: PROV-AQ, PROV-CONTRAINTS, PROV-XML – HL7 Health Care Privacy and Security Classification System, Release 1 – HL7 Version 3 Standard: Privacy, Access and Security Services (PASS) – HL7 EHR Records Management and Evidentiary Support (RM-ES) Functional Model, Release 2 – HL7 Digital Signature – ISO Health Informatics: Trusted End-to-End Information Flows – Personal Health Record System Functional Model – HL7 Record Lifecycle Event Metadata using FHIR (project underway 2014) – ISO/HL EHR System Functional Model Release 2 (2014) – HL7 EHR Lifecycle Model (2008)(Added October 23, 2014) – ISO Trusted End-to-End Information (2004, currently in revision) – CDISC ODM Production Version

Auditable Events and Tamper Resistance (1 of 2) – April NPRM Request The 2014 Final Rule allows for selected users to disable audit logging, and the 2015 proposal proposes to remove this functionality. ONC seeks comment on the "impact and potential unintended consequences of" their proposed change "and specific examples where disabling an EHR technology’s audit log is warranted.”

Auditable Events and Tamper Resistance (2 of 2) – April PSWG Response The PSWG suggests no change from the 2014 Final Rule; the current criteria adequately function as a floor for meaningful use. Although the current certification criteria do not preclude the audit log from being disabled, they do require access controls restricting the capability to disable the audit log to a limited set of identified users (presumably those with audit-log administrative duties) and the capability to record the user ID, data, and time when the log was disabled. Since the proposed change would “prevent all users from disabling the audit log,” the PSWG contends that prohibiting the disabling of the audit log would hamper security administrators from performing their functions properly. Generally, this kind of action comes from concern that a system administrator would do something nefarious. A countermeasure is to audit the act of turning the audit log off and on; this capability is required in the current criteria. Furthermore, audit administrators are typically separate from other security administrators. Audit administration typically includes tuning (disabling) the list of audited events or turning off positive authentication events while leaving negative authentication events enabled. Sometimes, the storage capacity required for the audit trail expands and can threaten continuing operations. While the PSWG does not suggest a regular practice of disabling the audit trail to manage storage, it does suggest that certification criteria should not thwart administrators ability to perform their assigned functions.

Audit Report(s) (1 of 3) – April NPRM Request (for 2017) ONC is requesting comments on the sufficiency of ASTM E1247 for the 2017 NPRM, specifically: 1)"The 'query' action in section 7.6 of the ASTM E2147 standard is not a defined term in the standard’s definition section." ONC wants to know A) "whether this ambiguity has caused additional burden or challenges for EHR technology developers," B) "how EHR technology developers have interpreted the term when designing their EHR technology," and C) if there is any "industry knowledge related to any plans to revise ASTM E2147 to address this ambiguity.“ 2)"Whether [ONC] should establish a minimum/baseline set of actions that EHR technology must always be capable of" for the purpose of audit? 3)Whether there are other actions that ONC should consider specifying in an updated standard for the 2017 Edition that the current standard does not sufficiently address, such as the act of ‘transmission’? ONC does not favor this approach because implementing it in regulation would cause addition to the existing standard and seeks feedback on whether the standard is sufficiently up-to-date and appropriately specifies all of the actions necessary for EHR audit logs to capture. 4)Are there "any alternative standards to ASTM E2147 that [ONC] should consider in light of the aforementioned concerns and ambiguities.”

Audit Report(s) (2 of 3) – April PSWG Response (2017) 1)Re: The 'query' action in section 7.6 of the ASTM E2147 standard: ASTM E2147 was updated a year ago, and the PSWG is not aware of any need to define ‘query’ or any problems developers have encountered regarding query. Greater vendor input is needed to fully answer this question for the entire healthcare industry. We recognize that there is confusion in the market in understanding the Security Audit Logging concept. We would suggest that a broader reference to ASTM E2147 might serve well to help clarify any misunderstandings. Specifically, we recommend expanding the references to include at least section 5 which explains Security Audit Logging and describes the kinds of events that should be recorded in the audit log. In addition, we recommend that Section 7 be referenced in its entirety, rather than individually enumerating those parts of Section 7 that are not labeled “optional.” Note that by citing all of Section 7, the labeled provisions still would be treated as “optional.” 2) Re: Minimum/baseline set of actions for the purpose of audit Typically, one audits security-relevant actions associated with performing required functions; one does not require functions so that they can be audited. The PSWG is opposed to establishing a minimum or baseline set of actions that EHR technology must always be capable of so that they can be audited.

Audit Report(s) (3 of 3) – April PSWG Response (2017) 3)Re: Other actions to consider specifying, such as the act of ‘transmission’: The PSWG believes it is quite feasible to certify EHR compliance with the ASTM E2147 audit log standard, and does not recommend ONC specify other actions in an updated standard for the 2017 Edition, or that ONC consider any additional standards. 4) Re: Alternative standards to consider: The PSWG believes it is quite feasible to certify EHR compliance with the ASTM E2147 audit log standard, and does not recommend that ONC consider any additional standards.

To create a valid digital signature that meets Federal Information Processing Standards (FIPS)*, Federal Information Security Management Act of 2002 (FISMA)**, and Federal Bridge Certification Authority *** requirements, the system used to digitally sign C-CDA Release 2.0 or CDP1 IG documents in accordance with the DSDR IG must satisfy the following: 1)The cryptographic module210 used must: a.Be validated to meet or exceed FIPS 140-2, Level 1 b.Implement a digital signature system and hash function must be compliant with FIPS and FIPS c.Store the private key on a FIPS Level 1 validated cryptographic module using a FIPS-approved encryption algorithm 2) The system must support multi-factor authentication that meets or exceeds Level 3 assurance as defined in NIST SP ) The system must set a 10-minute inactivity time period after which the certificate holder must re-authenticate the password to access the private key. 4) For software implementations, when the signing module is deactivated, the system must clear the plain text private key from the system memory to prevent the unauthorized access to, or use of, the private key. 5) The system must have a time system that is synced with the official National Institute of Standards and Technology time source (as described by the standard adopted at 45 CFR (g)). Valid Digital Signature Guidance * Source: ** Source: *** Source: 28

The Author of Record Level 1 IG provides specific guidance on the use of a single digital signature, external to document, to: Provide a non-repudiation signature that attests to the identity of the signer; Allow the recipient to validate the data integrity of the signed document; Provide for a delegation of rights where the signer is a delegated signer and not the authorized signer responsible individual or organization (e.g., the signer is acting as an authorized agent); and Define how to incorporate the public certificate of the signer. Digital Signature External to Document Guidance 29

The Provider Profiles Authentication: Registration IG provides specific guidance on the creation and use of a single digital signature for an electronic transaction, as accompanying metadata, to: Provide a non-repudiation signature that attests to the identity of the signer; Allow the recipient to validate the data integrity of the signed transaction; Provide for a delegation of rights where the signer is a delegated signer and not the authorized signer responsible individual or organization (e.g., the signer is acting as an authorized agent); and Define how to incorporate the public certificate of the signer. Registration IG Single Digital Signature Guidance 30

Proposed: Electronic Submission of Medical Documentation (esMD) – Comparison esMD Digital Signature Standard* § (i)(1) (Electronic submission of medical documentation) The system used to digitally sign C-CDA Release 2.0 or CDP1 IG documents in accordance with the DSDR IG must meet the following requirements: The cryptographic module used to digitally sign the data elements must be at least FIPS 140–2 Security Level 1 validated. Implement a digital signature system and hash function must be compliant with FIPS and FIPS Superseded by FIPS and in Store the private key on a FIPS Level 1 validated cryptographic module using a FIPS-approved encryption algorithm. Must support multi-factor authentication with level 3 assurance defined in NIST minute inactivity time period with re-authentication to access private key. When the signing module is deactivated, the system must clear the plain text private key from the system memory to prevent the unauthorized access to, or use of, the private key. Time system synced with the official National Institute of Standards and Technology time source (45 CFR (g)). 31 *Source:

Proposed: Electronic Submission of Medical Documentation (esMD) – Comparison DEA Digital Signature Standard* § Electronic prescription application requirements. The digital signature functionality must meet the following requirements: The cryptographic module used to digitally sign the data elements must be at least FIPS 140–2 Security Level 1 validated. The digital signature application and hash function must comply with FIPS 186–3 and FIPS 180–3. Superseded by FIPS and in The electronic prescription application’s private key must be stored encrypted on a FIPS 140–2 Security Level 1 or higher validated cryptographic module using a FIPS- approved encryption algorithm. For software implementations, when the signing module is deactivated, the application must clear the plain text password from the application memory to prevent the unauthorized access to, or use of, the private key. 32 *Source