Transport & Security Standards Workgroup Notice of Proposed Rulemaking Dixie Baker, chair Lisa Gallagher, co-chair April 8, 2015.

Transport & Security Standards Workgroup

Notice of Proposed Rulemaking

Dixie Baker, chairLisa Gallagher, co-chair

April 8, 2015

Agenda

Topic Time AllottedNPRM Introduction 20Workgroup Discussion: NPRM Comments

• Health IT Module Certification Requirements: Privacy & Security• Automatic Access Time-Out• End-User Device Encryption• Integrity

60

Public Comment 5 minutes

Interoperability Roadmap CommentsFinal Timeline

Date Task

Feb 24 WG discussion on Section E

Mar 11 WG discussion on Section F & G

Mar 18 HITSC Meeting

Mar 25 Additional discussion, final review of comments

April 8 Final comments distributed to group;Transition to NPRM discussion

April 22 Comments presented to HITSC

We are here

Thank you for your comments &discussion on the roadmap!

NPRM IntroductionMichael L. Lipinski, Esq.Director, Division of Federal Policy and Regulatory Affairs, ONC

5

Supporting the Broader Care Continuum

• Current: Prior editions were adopted with a specific focus on the EHR Incentive Programs

• Proposed: A more accessible ONC Health IT Certification Program supportive of:

Diverse health IT systems, including but not limited to EHR technology (“Health IT Module” instead of “EHR Module”)

Health IT across the care continuum, including long-term and post acute care settings

Supporting the Broader Care Continuum: How Would It Work?

The Past (2011 and 2014 Editions) The Proposed Future (2015 and Future Editions)• ONC included policy that supported

the EHR Incentive Programs in its previous Editions• Defined the Certified EHR

Technology (CEHRT) definition on behalf of CMS

• Required “meaningful use measurement” criteria

• Specified the minimum number of clinical quality measures developers must certify to in order to participate in the EHR Incentive Programs

• ONC does not include policy to support the EHR Incentive Programs in its Editions• Each program sets its own requirements

(e.g., CMS defines the CEHRT definition in its rule)

• ONC’s Health IT Certification Program is “agnostic” to settings and programs, but can support many different use cases and needs

• This permits the ONC Health IT Certification Program to support multiple program and setting needs, for example:• EHR Incentive Programs• Long-term and post acute care• Chronic care management• Behavioral health• Other public and private programs

Other Programs Using theONC Health IT Certification Program

A number of programs currently use or propose to use ONC’s Health IT Certification Program. They include:• Physician Self-Referral Law exception and Anti-

kickback State safe harbor for certain EHR donations• CMS chronic care management services• Department of Defense Healthcare Management

System Modernization Program• The Joint Commission for participation as an (ORYX)

vendor – eCQMs for hospitals

8

Certification Program Requirements

Proposed 2015 Edition criteria pointed to by CMS for MU 3 & to implement statute (Base EHR definition)

(n=37)

Available proposed 2015 Edition criteria for certification

(n=19)

Criteria proposed as always required for

2015 Edition certification

(n=2)

Criteria proposed as conditional for 2015 Edition certification

depending on capabilities in scope

(n= 10)Quality Management System - (g)(4)

Authentication, AccessControl, Authorization-(d)(1)

CPOE Medications (a)(1) Patient-specific Education Resources -(a)(17)

Vital Signs, BMI, and Growth Charts - (a)(6)

Accessibility-Centered Design-(g)(8)

Auditable Events andTamper-resistance- (d)(2)

CPOE Laboratory (a)(2) Patient Health Information Capture – (a)(19)

Image results - (a)(13)

Audit Report(s) - (d)(3) CPOE Diagnostic Imaging (a)(3) Implantable Device List - (a)(20) Patient List Creation - (a)(16)

Amendments - (d)(4) Drug-drug, Drug-allergy Interaction Checks for CPOE – (a)(4)

Transitions of Care – (b)(1) eMAR- (a)(18)

Automatic Access Time-out - (d)(5)

Demographics -- (a)(5) Clinical Information Reconciliation and Incorporation – (b)(2)

Social, Psychological, and Behavioral Data - (a)(21)

Emergency Access-(d)(6) Problem List – (a)(7) E-Rx - (b)(3) Decision Support – knowledge artifact - (a)(22)

End-User Device Encryption-(d)(7)

Medication list – (a)(8) Data Portability – (b)(6) Decision Support – service - (a)(23)

Integrity - (d)(8) Medication Allergy List – (a)(9) CQM – record and export - (c)(1) Incorporate Laboratory Tests and Values/Results – (b)(4)

Safety Enhanced Design - (g)(3)

CDS – (a)(10) CQM – import and calculate – (c)(2) Transmission of Laboratory Test Reports – (b)(5)

Consolidated CDA Creation Performance – (g)(6)

Drug-formulary and Preferred Drug List Checks –(a)(11)

CQM – report (c)(3) DS4P – send (b)(7)

Smoking Status - (a)(12) VDT - (e)(1) DS4P – receive (b)(8)

Family Health History (a)(14); or Family Health History – Pedigree (a)(15)

Secure messaging - (e)(2) Care Plan - (b)(9)

Transmission to Immunization Registries (f)(1)

Transmission to PHA – case reporting (f)(5) CQM filter - (c)(4)

Transmission to PHA – syndromic surveillance (f)(2)

Transmission to PHA – antimicrobial use and resistance reporting (f)(6)

Accounting of Disclosures – (d)(9)

Transmission to PHA – reportable laboratory tests and values/results (f)(3)

Transmission to PHA – health care surveys (f)(7)

Accessibility technology compatibility (g)(5)

Transmission to Cancer Registries (f)(4) Automated Numerator Recording - (g)(1) or Automated Measure Calculation - (g)(2)

SOAP Transport and Security Specification and XDR/XDM for Direct Messaging – (h)(3)

Application Access to Common Clinical Data Set – (g)(7)

Direct Project (h)(1) orDirect Project, Edge Protocol, and XDR/XDM (h)(2)

Healthcare Provider Directory – query request (h)(4)

Healthcare Provider Directory – query response (h)(5) Electronic Submission of Medical Documentation– (i)(1)

Green = new to the 2015 Edition

Light Blue = previously adopted in a certification edition to support MU1/MU2

9

2015 Base EHR Definition* red = new to the Base EHR Definition** privacy and security removed – now conditional certification requirements Base EHR Capabilities Certification Criteria

Includes patient demographic and clinical health information, such as medical history and problem lists

Demographics § 170.315(a)(5)Problem List § 170.315(a)(7)

Medication List § 170.315(a)(8)Medication Allergy List § 170.315(a)(9)

Smoking Status § 170.315(a)(12)Implantable Device List § 170.315(a)(20)

Capacity to provide clinical decision support Clinical Decision Support § 170.315(a)(10)

Capacity to support physician order entry

Computerized Provider Order Entry (medications, laboratory, or diagnostic imaging) § 170.315(a)(1), (2) or (3)

Capacity to capture and query information relevant to health care quality

Clinical Quality Measures (CQMs) – record and export § 170.315(c)(1)

Capacity to exchange electronic health information with, and integrate such information from other sources

Transitions of Care § 170.315(b)(1)Data Portability § 170.315(b)(6)

Application Access to Common Clinical Data Set § 170.315(g)(7)Direct Project § 170.315(h)(1) or Direct Project, Edge Protocol, and

XDR/XDM § 170.315(h)(2)

Certified Health IT Module(s) to Support the EHR Incentive Programs Stage 3

10Base EHR Capabilities Base EHR Definition

Meaningful Use Measurement CapabilitiesCEHRT

Definition requirements

(Objective 2)e-Prescribing,

Drug-formulary checks

(Objective 3)Clinical decision support, Drug-drug

drug-allergy interaction checks

Capabilities to support meeting

specific Objectives (Objective 4)

Computerized provider order entry (choose 1 of 3)

(Objective 5 only)

Patient-specific education resources

(Objectives 5 & 6)View, download, &

transmit to 3rd party; API access to CCDS

(Objective 7)Transitions of care,

Clinical info reconciliation & incorporation

(Objective 6 only)

Secure messaging

(Objective 8)Public health

(EP: choose 3 of 7, EH/CAH:

choose 4 of 7)

Family Health History(choose 1 of 2)

Patient Health Information Capture(and supports Objective 6)

CEHRT Definition

requirements

Import, Calculate, and Report CQMs

Privacy & Security Safety-enhanced DesignConditionalcertification

requirements CCDA Creation Performance

Quality Management System Accessibility-centered DesignMandatorycertification

requirements

Certified Health IT Module(s) to Support Other Health Care Settings and HHS Programs (Examples)

11

Long-term Post Acute Care Certification (example only)Capabilities to

support meeting

specific needsTransitions of care Clinical information

reconciliation & incorporation Care plan

Behavioral Health Certification (example only)Capabilities to

support meeting

specific needs

Transitions of careClinical info

reconciliation & incorporation

Social, psychological, & behavioral data

Data segmentation for privacy

Use of the Health IT Certification Program across the care continuum

Conditionalcertification

requirements Privacy & Security Safety-enhanced

Design CCDA Creation Performance

MandatoryCertification

requirements Quality Management System Accessibility-centered Design

Quality Management System Accessibility-centered DesignMandatory

Certification requirements

Conditionalcertification

requirements Privacy & Security Safety-enhanced

Design

12

2015 Edition Common Clinical Data Set (CCDS)

• Propose to rename the “Common MU Data Set”• The Common Clinical Data Set includes key health

data that should be exchanged using specified vocabulary standards and code sets as applicable

Patient name Lab values/results

Sex Vital signs

Date of birth Procedures

Race Care team members

Ethnicity Immunizations

Preferred language Unique device identifiers for implantable devices

Problems Assessment and plan of treatment

Medications Goals

Medication allergies Health concerns

Lab tests

2015-2017Send, receive, find and use a common clinical data set to improve health and health care quality.

ONC Interoperability Roadmap Goal

13

When and How to Comment• ONC published the 2015 Edition Proposed Rule in the Federal Register

on March 30, 2015

• The comment period is open until May 29, 2015

• You can review the proposed rule and comment here: http://www.regulations.gov/#!documentDetail;D=HHS_FRDOC_0001-0572

• To assist in commenting on the rule, ONC provides a: Microsoft Word version of the rule (http://

www.healthit.gov/sites/default/files/2015_editionnprm_ofr_disclaimer_3-20-15.docx); and

Public Comment Template (http://www.healthit.gov/sites/default/files/2015editionnprm_public_comment_template_4-1-15_final508_.docx)

Transport and Security Workgroup Review of NPRM

NPRM Assignments & Workplan(HITSC – NPRM Comments Due May 20)

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

• Data Segmentation for Privacy – Send/Receive

• §170.315(b)(7)/ §170.315(b)(8)• pp. 135-136

• C-CDA Data Provenance • pp. 110-111, 167-168

May 6, 2015 3:00pm-4:30pm ET

• Electronic Submission of Medical Documentation

• §170.315(j)(1): pp. 222- 234

• Auditable Events and Tamper-Resistance • §170.315(d)(2): pp. 151-154

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.

Workgroup Discussion: NPRM Comments• Health IT Module Certification Requirements: Privacy and

Security• Automatic Access Time-Out• End-User Device Encryption• Integrity

EHR Module Certification: 2011 – 2015 NPRM

• 2011 Edition certified “Complete EHRs” and “EHR Modules” Complete EHRs were required to meet all privacy and security criteria EHR Modules were required to meet all privacy and security criteria unless a

developer could demonstrate that a P&S criterion was inapplicable or that it would be technically infeasible for the EHR Module to be certified in accordance with such certification criterion

EHR Module developers complained that P&S criteria often were not applicable to their products and the certification process was cumbersome/inefficient

• 2014 Edition introduced “Base EHR Definition” as baseline capability that providers needed to meet to receive MU incentive payment – security included in definition Certification available for “Complete EHRs” (included Base EHR Definition) and

“EHR Modules,” which were not required to meet any P&S criteria HITSC/PSWG asserted that providers would have no way of knowing whether

any given set of EHR Modules they might choose to use would enable them to meet HIPAA P&S requirements – and suggested an alternative approach [1) implement capability, 2) define interfaces to external security services, 3) document why N/A]

2011Ed.

2014Ed.

EHR Module Certification: 2011 – 2015 NPRM

• 2014 Release 2 final rule eliminated Complete EHR certification for all future edition (starting w/ the 2015 Edition) so that all technology submitted for certification would be assessed as an “EHR Module” HITSC/PSWG recommended specifically allocating security requirements to

types of EHR modules, based on the functionality each provided. Then, for each applicable requirement, module could meet requirement in any of 3 ways [2) implement capability, 2) define interfaces to external services, 3) document why N/A]

• 2015 NPRM proposes to do as the PSWG recommended, except provides only two options: Technically demonstrate; or Document that service interfaces are implemented for each applicable P&S criterion* ONC does not propose the inapplicable or technically infeasible approach for the 2015 Edition because they propose what they think is applicable. They request comment on this approach. ** P&S certification criteria are not directly linked to the EHR Incentive Programs Stage 3

2014 NPRM

2015NPRM

NPRM Allocation (page 261 in review document)

Health IT Module Certification Requirements:Privacy and Security

• Proposal: a new approach for privacy and security (P&S) certification– Requirement: an ONC-Authorized Certification Body (ACB)

must ensure that a Health IT Module presented for certification to any of the certification criteria that fall into each regulatory text “first level paragraph” category (see chart on next slide) is certified to one of two approaches:• Technically demonstrate, or• System documentation

• Comment: ONC seeks comment on the overall clarity and feasibility of this approach.

Workgroup Discussion: NPRM Comments• Health IT Module Certification Requirements: Privacy and

Security• Automatic Access Time-Out• End-User Device Encryption• Integrity

Automatic Access Time-Out

• NPRM proposes no changes to “automatic access time-out” criterion for the purposes of gap certification – See 2014 Edition “automatic log-off” criterion

• NPRM acknowledges past TSS WG (PSWG) work– Eliminate reference to “sessions”; avoid being overly

prescriptive so as to inhibit system architecture flexibility • Proposal: require a Health IT Module to … automatically stop

user access to health information after a predetermined period of inactivity and require user authentication in order to resume or regain the access that was stopped

• Comment: ONC welcomes comments on this assessment

Workgroup Discussion: NPRM Comments• Health IT Module Certification Requirements: Privacy and

Security• Automatic Access Time-Out• End-User Device Encryption• Integrity

End-User Device Encryption

• NPRM proposes no changes to “end-user device encryption” criterion for the purposes of gap certification

• Require criterion consistent with Appendix A of Federal Information Processing Standards (FIPS) Publication 140-2– Propose move to updated version (Draft, October

8, 2014)• Comment: ONC welcomes comments on this

assessment

Workgroup Discussion: NPRM Comments• Health IT Module Certification Requirements: Privacy and

Security• Automatic Access Time-Out• End-User Device Encryption• Integrity

Integrity

• NPRM proposes no change to “integrity” criterion, but proposes that testing against this criterion focus on receipt of a summary record

• NPRM seeks guidance on when the SHA-1 integrity standard should be changed to SHA-2– Many companies, including Microsoft and Google, plan to

move to SHA-2 no later than January 1, 2017– Direct requires that both SHA-1 and SHA-256 (one type of

SHA–2 hash algorithm) be supported• Comment on: If, and when, NPRM should set the baseline for

certification to the 2015 Edition “integrity” certification criterion at SHA–2.

*144 http://www.symantec.com/en/au/page.jsp?id=sha2-transition

Next Set of NPRM Topics

Workgroup Discussion: Topics For April 21• Data Segmentation for Privacy – Send/Receive• CCDA Data Provenance• Auditable Events and Tamper-Resistance (time

permitting)

Backup & Reference Material

Proposed CMS Meaningful Use Objectives

• Objective 1: Protect Patient Health Information• Objective 2: Electronic Prescribing• Objective 3: Clinical Decision Support• Objective 4: Computerized Provider Order Entry• Objective 5: Patient Electronic Access to Health Information• Objective 6: Coordination of Care through Patient

Engagement• Objective 7: Health Information Exchange• Objective 8: Public Health and Clinical Data Registry

Reporting