Provider Authentication for Health Information Exchange


Published on

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

  • Be the first to comment

  • Be the first to like this

Provider Authentication for Health Information Exchange

  1. 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. 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. 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. 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. 5. Assumptions 5
  6. 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. 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. 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. 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. 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. 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. 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. 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. 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. 15. BACKGROUND 15
  16. 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. 17. Authentication Environment 17
  18. 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. 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. 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. 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