Privacy and Security in the Direct Context Session 6 April 12, 2010.

Privacy and Security in the Direct Context

Session 6

April 12, 2010

2

Agenda

A review and discussion of privacy and security as approached by the Direct Project, including consent and encryption issues

• Presenter– David McCallie Jr., MD, VP Medical Informatics, Cerner

Corporation

• Q&A

• Poll

3

Direct Project High-Level Overview• Specific privacy and security needs of the Direct Project:

– Understanding patient consent– Relationship to HISPs– Build trust framework– Identity assurance– Certificate management

• Developed Pilot Privacy & Security Standards based on the HIT Policy Committee’s Recommendations to ONC– These standards are not final – “NwHIN Governance” NPRM soon– “Best practice,” rather than regulation– ONC/HHS is in the process of vetting the HIT Policy Committee

Recommendations to reach HHS policy decisions on these issues

4

HIT Policy Committee(Privacy and Security Tiger Team) Consent & Directed Exchange Recs to ONC (2010)

“Directed” exchange between providers treating the patient does not require patient consent beyond what is required in existing law.

• Assumptions:– “Push” exchange model – originated by provider treating the patient– The provider is in control of the decision to share the data– Information is exchanged for treatment purposes (TP&O)– Adherence to Fair Information Practice Principles– Messages are encrypted, so that no intermediary has access to PHI– Patient data is not retained for purposes other than processing and delivering

the message

• Implications:– If these conditions are not met, additional patient consent would be needed

(“meaningful” choice must be offered to the patient)

5

Direct Project and Health Information Service Providers (HISPs)

• When the HISP functions are wholly contained within the organizational boundaries of a HIPAA Covered Entity, the issues discussed in following slides do not generally apply, because the data use, retention, and disclosure decisions are made by the Covered Entity itself, under the full protections of HIPAA.

• Directed exchange where an external HISP could have access to unencrypted data (managing the private keys of the address holder) should operate under a standard Business Associate Agreement if the Direct address holder is part of a Covered Entity.

• If the address holder is not covered under a CE, then the HISP should have strong legally enforceable contractual obligations that provide equivalent protection for individuals to those provided by HIPAA.

• HISP to HISP Business Associate Agreements are not required when content is properly encrypted.

Source: Direct Project, Best Practices for HISPs, http://wiki.directproject.org/Best+Practices+for+HISPs.

6

Direct Project Security Overview

• Enabling Message Handling Trust between Participants: – Authenticate the sender & validate that you trust the receiver– Validate the identity & trust of sender when information is received – Provide non-repudiation service that assures the origin of information – Allow a Direct Project participant to specify which participants they trust

to exchange information • Protecting the Information Exchanged:

– Ensure information including PHI that is exchanged between Direct Project participants is encrypted during transit.

– Verify that information exchanged between Direct Project participants was not altered in transit.

• Policy – Ensure that the technology choices enable different policy and trust

frameworks that might co-exist across various organizations.

Direct security guiding principle: Messages go where they are meant to, are not altered during transmission, and are not seen by anyone for whom they are not intended.

7

Digital Certificate Trust Models

8

Direct Project Privacy and Security Best Practices for HISPs - Security

• Regardless of legal requirements, all HISPs will hold themselves to the provision of the HIPAA Security Rule, and, to the extent that it is relevant and consistent with the Security Rule, will follow the guidelines of PCI-DSS.

• HISPs that manage private keys must perform specific risk assessment and risk mitigation to ensure that the private keys have the strongest protection from unauthorized use.– That risk assessment must address the risk of internal personnel or

external attackers gaining unauthorized access either to the keys or to the health information functions for which the keys enforce trust.

• HISPs that manage trust anchors on behalf of their customers must have well defined, publicly available policies for evaluating the certificate issuance policies of those trust anchors, in accordance with the Certificate Pilot Recommendations.

9

Privacy and Security BP for HISPs: Transparency and Data Handling/Retention

• HISPs must include all data collection, use, retention and disclosure policies (including rights reserved but not exercised) in BAAs or other service agreements.

• HISPs must minimize data collection, use, retention and disclosure to that minimally required to meet the level of service required of the HISP.

• Minimal use may require retention of data for security, audit, logging and other required operation; such use must be included in BAAs and service agreements, and must capture the minimal amount of data to fulfill those requirements.

• To the extent that HISPs support multiple functions with different requirements for data use, they must separate those functions such that more extensive data use or disclosure is not required for more basic exchange models.

10

Certificate Management Recommendations in the Direct Context

Who should be the Trust Anchor for a community?

Some entity must have the power to decide the criteria for which certificates are issued for the purpose of message exchange within their community -- PHRs, HIOs, distributed IDN, etc.

Recommendation Post-Pilot for Direct Project Implementations• Watch for the NwHIN Governance NPRM due out soon

• Contract with an entity that already has in place processes and procedures for validating conformance to governance policies and issuing certificates

• Communities that wish to exchange data with Federal providers and agencies must have certificates that chain to the Federal Bridge Certification Authority.

11

Certificate Management Recommendations in the Direct Context

Organization or end-user certificates? Or both?

Direct supports a model where certificates can be unique to individual addresses ([email protected]) or the domain for the collective organization (hospital.com).

Pilot Recommendation: Implementations may use organization-level certificates to minimize the complexity of provisioning and management. If participating organizations wish to use address specific certificates, take one of two approaches:

• Using new certificates for Direct issued by the community authority will simplify overall configuration (rather than re-use existing certificates)

• If the organization would like to issue new certificates for each endpoint, the community should make the organization a registration authority

12

Certificate Management Recommendations in the Direct ContextWhat should be minimum identity-proofing and authorization requirements for providers and staff in a community?

Hospital credentialing and authentication required to gain access to EHR systems or EHR modules often provide sufficient levels of assurance and authentication to issue certificates and private keys. In cases where such pre-existing methods do not exist, we recommend the following best practice for identity assurance for providers:

• Verify the place of practice, through means such as by contacting the practice or provider through independently sourced contact information (e.g., white or yellow pages directories) or through knowledge based methods

• Verify government issued IDs and licensure, including looking up licensure

information in public registries

• Authentication standards may be addressed by NwHIN Governance NPRM

13

Direct Context Consumer Addresses• PHRs have already begun to issue Direct

compatible addresses• Identity proofing:

– By the provider, in person or equivalent– Or from a trusted PHR process– The consumer should provide his/her address to provider

to initiate the linkage

• Authentication– Tiger Team leaning towards single-factor consumer

authentication for provider portals; probably should also apply to PHR/Direct users?

• Watch for the NwHIN Governance NPRM

14

Certificate Management Recommendations in the Direct Context

What should be the expiration policy for certificates?

Policy should balance the value of regular refreshing of anchors and certificates with the operational burden of doing so.

Pilot Recommendation: Eighteen months seems a reasonable expiration policy for anchors and certificates, with an intent to refresh after 12 months.

Q&A

16

Poll