Privacy and Security Tiger Privacy and Security Tiger Team MeetingTeam MeetingToday’s Topic: Provider Authentication for Health Information Exchange

Strawman Recommendations - For Discussion Only

November 8, 2010

Objectives and Scope of this Discussion

• Define policy recommendations to ensure that authentication "trust" rules are in place for information exchange between provider-entities (or organizations) 

Authentication is verification that a person or entity seeking access to electronic protected health information is the one claimed

Level of assurance is the degree of confidence in the results of an authentication attempt

2

Objectives and Scope of this Discussion

• We need to specifically address directed exchange transactions described in Stage 1 of meaningful use, but also consider other information-exchange transactions.   It is assumed that:– Identifiable clinical information is transmitted from one provider entity

to another for treatment purposes for stage 1 meaningful use

– Some of the information will be very sensitive to the individual

• We are evaluating these trust rules at the organizational level, and as such, the scope of this recommendation does not include authentication of individual users of EHR systems, or of patients   – With respect to individual users, provider entities and organizations

must develop and implement policies to identity proof and authenticate their individual users

– Beyond Stage 1 of Meaningful Use, policy on individual user authentication may be needed to promote trust among organizations

3

Proposed Questions for the Tiger Team & Public

1. What strength of provider-entity authentication (level of assurance) might be recommended to ensure trust in health information exchange (regardless of what technology may be used to meet the strength requirement)?

2. Which provider-entities can receive digital credentials, and what are the requirements to receive those credentials?

3. What is the process for issuing digital credentials (e.g., certificates), including evaluating whether initial conditions are met and re-evaluation on a periodic basis?

4. Who has the authority to issue digital credentials? 

5. Should ONC select an established technology standard for digital credentials and should EHR certification include criteria that tests capabilities to communicate using that standard for entity-level credentials?

6. What type of transactions must be authenticated, and is it expected that all transactions will have a common level of assurance?

4

Assumptions

5

Question 1 – Strength of Authentication/Level of Assurance

• What should be the level of assurance for entity authentication?– Although we need a trust framework for provider entity

authentication, the question of “level of assurance” (as expressed in the OMB/NIST Framework) applies at the level of individual authentication. This inquiry is not helpful in an organizational context.

– Need to leverage existing solutions for now (e.g., digital certificates); Standards Committee should choose a standard

• Should consider need to create a reliable trust framework, as well as cost and burden

6

Question 2a: Which Provider Entities Should Receive (or be issued) Digital Credentials

• Meaningful users of Health IT• Anyone engaged in health data exchanges• PBMs• Retail pharmacies• DME suppliers• Laboratories• Imaging centers• All healthcare organizations• Non-providers--payers, claims clearinghouses, HIOs• Only Certified EHR systems

7

Question 2b: Requirements to Receive (to be issued) those Credentials

• Would we want to include requirements for suitability checks? Suitability could include:– Valid licensure – Business validity (proof of address/corporate existence)– Financial account– Demonstration of certain security criteria– Having a certified EHR, if applicable– Other (e.g. aligning with individual or organizational certification

processes accepted today within the healthcare domain)

• Actual credentials are electronic – are there registration requirements for receiving those credentials that might need to be considered (electronic, in-person by a business representative)? 8

Question 3a: What is the process for issuing digital credentials (e.g., certificates)?

Options might include:• Federated model – providers can delegate to other

parties (such as vendors, HIEs)– Requirement that those entities meet minimum criteria or be

held liable in some respect for issuing certificates?

– How would such criteria be enforced?

– Leverage existing protocols (ICANN, Federal Bridge)

• Self-credentialing • Establish registration authority services• Federal/state role• Integrate process for issuing digital credentials into

other existing provider-entity registration processes9

Question 3b: What is the process for re-evaluation?

• No requirements• Periodic credential refresh• Credential refresh based on occurrence of defined

events

10

Question 4: Who can Issue Digital Credentials?

• Any entity willing to assume attendant risks and meeting established standards

• Establish an accreditation program for authorizing credential issuers

• Allow provider-entities to self-credential• Leverage federal or state government role to perform

credentialing• Vendors• HIOs

11

Question 5a: Should ONC select an established technology standard for digital credentials

• Do not develop standards, allowing vendors and large organizations to lead the way

• Yes, selection of a technology standard promotes interoperability– But ensure flexibility to accommodate innovation in the

marketplace

12

Question 5: should EHR certification include criteria that tests capabilities to communicate using that standard?

• Yes, entity-level credentials should be included in the security requirements

• Other options?

13

Question 6: What type of transactions must be authenticated and is there a common level of assurance

• Authentication required when transactions involve• patient risk or PHI

• system or infrastructure risk

• transactions that would normally be authenticated outside of health care

• Bulk transactions– Authenticate the transfer not transaction

• Under the “authentication at the organization level” assumption, does a single level of assurance seems appropriate?

14

BACKGROUND

15

Authentication: ReCap Definitions

• Authentication -- verification that a person or entity seeking access to electronic protected health information is the one claimed

• Level of assurance -- the degree of confidence in the results of an authentication attempt– Confidence is a valuation of the various controls implemented

to provide security, including: technology, process, policies, and governance

• Digital credentials - used to identify and authenticate organizations to each other (e.g., certificates)

16

Authentication Environment

17

The Federal E-Authentication Framework

The E-Authentication Framework was jointly developed by OMB and NIST

• A framework to map risk to levels of security investment and recommend requirements based on desired security level

• Developed to meet increasing need to secure an expanding set of Government-to-Business and Government-to-Citizen interactions

• E-Authentication focuses on securing access to transactions available via the Internet– Scope limited to aspects of technology and process

18

E-Authentication Mapping Tool

• E-Authentication includes a tool to select an appropriate level of assurance based on impacts due to authentication errors

• Levels of Assurance are suitable to different portions of the user community– Level 1 aligned with the general public (e.g., Facebook, Yahoo! Email)– Level 2 aligned with the general public, but with motivation (e.g. PayPal, 401k)– Level 3 aligned with affiliated access (e.g. Patent Examiners, Census Workers)– Level 4 aligned with employee access (e.g. Data Center operations)

19

Assurance Level Impact Profiles

Potential Impact Categories for Authentication Errors 1 2 3 4

Inconvenience, distress or damage to standing or reputation Low Mod Mod High

Financial loss or agency liability Low Mod Mod High

Harm to agency programs or public interests N/A Low Mod High

Unauthorized release of sensitive information N/A Low Mod High

Personal safety N/A N/A Low Mod/ High

Civil or criminal violations N/A Low Mod High

E-Authentication: Summary of Selected Requirements

Requirements Area Level 1 Level 2 Level 3 Level 4

RegistrationThe application process for obtaining identity credentials

In-person or remote

In-person or remote In-person or remote

In-person only

Identity ProofingThe process of verifying an applicant’s identity prior to credentialing

None Govt ID or financial account

Govt ID and financial account

Govt Photo ID and secondary Govt ID or financial account

NamingThe verification and assertion of meaningful names for applicants

None Verified name retained, pseudonyms allowed

Verified names only

Verified names only

Authentication TokenTechnical components used to electronically prove one’s identity

None Single-factor Multi-factor or Combined Single-factors

Multi-factor Hardware Device

Records KeepingPreservation of evidence regarding credentialing operations

None 7.5 years after separation

7.5 years after separation

10.5 years after separation

Reuse of Existing CredentialsSupport for historic investment and existing solutions

Any Employers and educational institutions

Financial institutions

Financial institutions

20

DEA Use of E-Authentication

• DEA rules allowing electronic prescriptions of controlled substances in place of paper or other processes

• Initial risk assessment led to selection of Level 4 assurance– Several areas of high impact due to authentication errors– Resistance from stakeholders to stringent and atypical requirements

• Much attention paid to analysis of burden

• DEA introduces mitigating factors to lower selection to Level 3, including• Separation of duties, system access controls, and certification of

implementations

• DEA decision to accept or mitigate some level of risk in exchange for more practical implementations

• Note: DEA tailored use of E-Authentication to exclude options they viewed as unacceptable

• Difficulty in finding credentialing services that meet the requirements (e.g., are recognized, can scale for the population, and desire to take on the work)

21