13
HIT Policy Committee HIT Policy Committee Privacy and Security Tiger Privacy and Security Tiger Team Team Deven McGraw, Chair Paul Egerman, Co-Chair Provider Authentication Recommendations November 19, 2010 1

Privacy and Security Tiger Team Authentication Recommendations

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Privacy and Security Tiger Team Authentication Recommendations

HIT Policy CommitteeHIT Policy CommitteePrivacy and Security Tiger TeamPrivacy and Security Tiger Team

Deven McGraw, Chair

Paul Egerman, Co-Chair

Provider Authentication Recommendations

November 19, 2010

1

Page 2: Privacy and Security Tiger Team Authentication Recommendations

Tiger Team Members

2

• Deven McGraw, Chair, Center for Democracy & Technology

• Paul Egerman, Co-Chair

• Dixie Baker, SAIC

• Christine Bechtel, National Partnership for Women & Families

• Rachel Block, NYS Department of Health

• Neil Calman, Institute for Family Health

• Carol Diamond, Markle Foundation

• Judy Faulkner, EPIC Systems Corp.

• Leslie Francis, University of Utah; NCVHS

• Gayle Harrell, Consumer Representative/Florida

• John Houston, University of Pittsburgh Medical Center

• David Lansky, Pacific Business Group on Health

• David McCallie, Cerner Corp.

• Wes Rishel, Gartner

• Latanya Sweeney, Carnegie Mellon University

• Micky Tripathi, Massachusetts eHealth Collaborative

• Adam Greene, Office of Civil Rights

• Joy Pritts, ONC

• Judy Sparrow, ONC

Page 3: Privacy and Security Tiger Team Authentication Recommendations

Objectives and Scope of this Discussion

• Stage 1 of meaningful use includes some requirements to exchange identifiable clinical information among providers for treatment purposes -- we expect that the exchange requirements will increase in Stages 2 and 3

• We focused on a trust framework for information exchange between EHR systems

• We need to validate that the organization is who it says it is (digital credentials)– Does the organization really exist, and how can we gain

assurance that someone else isn’t spoofing or assuming the organization’s identity?

3

Page 4: Privacy and Security Tiger Team Authentication Recommendations

Objectives and Scope continued

• We are evaluating these trust rules at the organizational or entity level, and as such, the scope of this recommendation does not include authentication of individual users of EHR systems  

• With respect to individual users, provider entities and organizations must develop and implement policies to identity proof and authenticate their individual users (already required under HIPAA Security Rule)

4

Page 5: Privacy and Security Tiger Team Authentication Recommendations

Authentication Environment

5

Page 6: Privacy and Security Tiger Team Authentication Recommendations

Authentication Infrastructure

• On the Internet, the identity of an entity is authenticated using a digital certificate– Contains information about the entity– Contains public (freely published) encryption key that, when

used in combination with its paired private key (retained by the entity), can be used to authenticate the identity of the certificate holder

• The process of assigning a digital certificate to an entity is called credentialing

6

Page 7: Privacy and Security Tiger Team Authentication Recommendations

Overall Comments

• We want a high level of assurance that the organization is who it says it is– We also want to ensure an appropriate balance between level

of assurance and cost and burden of implementation

• Entity authentication (through digital certificates) is not the sole measure of security – it is necessary but not sufficient

• We assume that recommendations from the Governance workgroup will form the foundation of an accountability infrastructure for assuring adherence to a framework of privacy and security practices and policies

7

Page 8: Privacy and Security Tiger Team Authentication Recommendations

Recommendation 1: Which Provider Entities Should be Issued Digital Certificates

• All entities involved in health data exchange should be required to have digital certificates – Examples of these entities might include:

• Covered entities • Business associates• PHR providers• Public health entities• PBMs• Retail pharmacies• DME suppliers• Laboratories• Imaging centers• Non-providers--payers, claims clearinghouses, HIOs

[Note: an entity might have multiple entry points]

8

Page 9: Privacy and Security Tiger Team Authentication Recommendations

Recommendation 2: Requirements to be Issued Digital Certificates

9

Page 10: Privacy and Security Tiger Team Authentication Recommendations

Recommendation 3: Process for Issuing Digital Certificates and Process for Re-evaluation

10

Page 11: Privacy and Security Tiger Team Authentication Recommendations

Recommendation 4: Characteristics of Who Can Credential/Issue Digital Certificates

• Any entity willing to assume attendant risks (i.e., be held accountable for achieving a high level of accuracy/assurance) and meet established standards can issue digital certificates

• We recommend that ONC establish an accreditation program for reviewing and authorizing certificate issuers– Annual credentialing of entities is not enough – credential issuers

must be required to operate with transparency so their operations can be monitored and problems are quickly identified

• This requirement for accreditation should be evaluated in the context of recommendations from the HIT Policy Committee’s Governance Workgroup

11

Page 12: Privacy and Security Tiger Team Authentication Recommendations

Recommendation 5: EHR Certification and Standardization of Digital Certificates

• ONC, through the Standards Committee, should select or specify standards for digital certificates (including data fields) in order to promote interoperability among health care organizations.

• EHR certification should include criteria that tests capabilities to retrieve, validate, use, and revoke digital certificates that comply with standards

12

Page 13: Privacy and Security Tiger Team Authentication Recommendations

Recommendation 6: Types of Transactions Requiring Certificates

• Authentication is required on any transaction: – When the content of the exchange must be protected (due to

personally identifiable health information)

– When the identity of the sender and/or receiver must be known and validated

– In some cases may only need to authenticate one end versus both

• Examples of transactions that may require authentication of sender and/or receiver need assurance include:– Transactions that contain personally identifiable health information or

may otherwise pose a risk to the patient if the information is not used in an appropriate manner

– Transactions that would normally be authenticated outside of health care

– Bulk transactions used to transfer multiple patient records

13