provider authentication for health information exchange
Post on 10-Jun-2015
1.300 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related