Provider Authentication for Health Information Exchange Presentation to Privacy & Security Tiger Team

1. Privacy and Security TigerPrivacy and Security Tiger
Team MeetingTeam Meeting
Today’s Topic: Provider Authentication for
Health Information Exchange
Strawman Recommendations - For
Discussion Only
November 8, 2010

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

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

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

5. Assumptions
5

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

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

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

9. 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 processes
9

10. Question 3b: What is the process for re-evaluation?
• No requirements
• Periodic credential refresh
• Credential refresh based on occurrence of defined
events
10

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

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

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

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

15. BACKGROUND
15

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

17. Authentication Environment
17

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

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

20. E-Authentication: Summary of Selected
Requirements
Requirements Area Level 1 Level 2 Level 3 Level 4
Registration
The application process for obtaining
identity credentials
In-person or
remote
In-person or remote In-person or
remote
In-person only
Identity Proofing
The 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
Naming
The verification and assertion of
meaningful names for applicants
None Verified name
retained,
pseudonyms
allowed
Verified names
only
Verified names
only
Authentication Token
Technical components used to
electronically prove one’s identity
None Single-factor Multi-factor or
Combined Single-
factors
Multi-factor
Hardware Device
Records Keeping
Preservation of evidence regarding
credentialing operations
None 7.5 years after
separation
7.5 years after
separation
10.5 years after
separation
Reuse of Existing
Credentials
Support for historic investment and
existing solutions
Any Employers and
educational
institutions
Financial
institutions
Financial
institutions
20

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