Transport & Security Standards Workgroup

Notice of Proposed Rulemaking Comments

Dixie Baker, ChairLisa Gallagher, Co-Chair

May 6, 2015

Topic Time AllottedReview of NPRM Comments from April 21st Meeting 20 minutes

Workgroup Discussion: NPRM Comments

• Data Segmentation for Privacy (DS4P)• Electronic Submission of Medical Documentation

(esMD)

60 minutes

Public Comment 5 minutes

Agenda

2

Meeting NPRM Assignments Rule & 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

Review of NPRM Comments from April 21st Meeting

4

REVIEW OF NPRM COMMENTS

5

NPRM April 21st Meeting Topics

• C-CDA Data Provenance• Auditable Events and Tamper-Resistance• Privacy and Security Applicability

HITSC Readiness Evaluation and Classification Criteria for Technical Specifications

Emerging Standards

Pilots

National Standards

Adoptability

Mat

urity

Low Moderate High

Low

M

oder

ate

H

ighMaturity Criteria:

•Maturity of Specification•Maturity of Underlying Technology

Components•Market Adoption

Adoptability Criteria:• Ease of Implementation and Deployment• Ease of Operations • Intellectual Property

Source: http://jamia.oxfordjournals.org/content/jaminfo/early/2014/12/17/amiajnl-2014-002802.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

• § 170.210(h) of the 2014 Edition specifies ASTM E4127-01 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

13

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

• 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 § 170.205(a)(3) and (4) that is tagged as restricted and subject to restrictions on re-disclosure according to the standard adopted in § 170.205(o)(1).

• Comment on: inclusion in the 2015 Edition

Proposed: Data Segmentation for Privacy – Send§170.315(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 § 170.205(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§170.315(b)(8)

15

WORKGROUP DISCUSSION

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

16

17

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

documents3. Capability 3 - Create and transmit “external digital

signatures” using W3C XADES standard4. Capability 4 - Create and transmit digital signatures

that assure both data integrity and non-repudiation

• 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: http://www.healthit.gov/FACAS/sites/faca/files/2013-07-17_HITSC_summary_final.pdf Source: http://healthit.gov/archive/archive_files/HIT%20Standards%20Committee/2013/Privacy%20%26%20Security/2013-08-08/2013-08-08_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, 180-2 (esMD); FIPS 186-3, 180-3 (DEA)– Superseded by FIPS 186-4, 180-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: https://www.federalregister.gov/articles/2015/03/30/2015-06612/2015-edition-health-information-technology-health-it-certification-criteria-2015-edition-base *Source: http://www.gpo.gov/fdsys/pkg/CFR-2011-title21-vol9/pdf/CFR-2011-title21-vol9-sec1311-120.pdf

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 21089 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/HL7 10781 EHR System Functional Model Release 2 (2014)– HL7 EHR Lifecycle Model (2008)(Added October 23, 2014)– ISO 21089 Trusted End-to-End Information (2004, currently in revision)– CDISC ODM Production Version 1.3.2

22

Auditable Events and Tamper Resistance (1 of 2) – April 2014

23

NPRM RequestThe 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 2014

24

PSWG ResponseThe 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 2014

25

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 2014

26

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 2014

27

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 1b. Implement a digital signature system and hash function must be compliant with FIPS 186-2 and FIPS 180-2c. Store the private key on a FIPS 140-2 Level 1 validated cryptographic module using a FIPS-approved

encryption algorithm

2) The system must support multi-factor authentication that meets or exceeds Level 3assurance as defined in NIST SP 800-63-2.3) The system must set a 10-minute inactivity time period after which the certificateholder must re-authenticate the password to access the private key.4) For software implementations, when the signing module is deactivated, the systemmust clear the plain text private key from the system memory to prevent theunauthorized access to, or use of, the private key.5) The system must have a time system that is synced with the official National Instituteof Standards and Technology time source (as described by the standard adopted at 45CFR 170.210(g)).

Valid Digital Signature Guidance

* Source: http://www.nist.gov/itl/fips.cfm ** Source: http://csrc.nist.gov/drivers/documents/FISMA-final.pdf *** Source: http://www.idmanagement.gov/sites/default/files/documents/FBCA%20Certificate%20Policy%20v2.27.pdf

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*§ 170.315(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 186-2 and FIPS 180-2. Superseded by FIPS 186-4 and 180-4 in 2013.• Store the private key on a FIPS 140-2 Level 1 validated cryptographic module using

a FIPS-approved encryption algorithm.• Must support multi-factor authentication with level 3 assurance defined in NIST

800-63-2.• 10 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 170.210(g)).

31*Source: https://www.federalregister.gov/articles/2015/03/30/2015-06612/2015-edition-health-information-technology-health-it-certification-criteria-2015-edition-base

Proposed: Electronic Submission of Medical Documentation (esMD) – Comparison

DEA Digital Signature Standard*§ 1311.120 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 186-4 and 180-4 in 2013.

• 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 http://www.gpo.gov/fdsys/pkg/CFR-2011-title21-vol9/pdf/CFR-2011-title21-vol9-sec1311-120.pdf