Best Practices Meeting 2010-10-14

Notes from the Best Practices Workgroup
Date: October 14, 2010
Time: 1:00 – 1:40pm EST
Attendees: Nageshwara (Dragon) Bashyam, Greg Chittim, Rich Elmore, John Feikema, Don Jorgenson Jack Kemery, Kevin McLeod, Patrick Pyette, Susan Torzewski, Laurie Tull, John Williams, Arien Malec, Uvinie Hettiaratchy, Caitlin Ryan

Actions

Actions for This Week

#	Date	Action	Status	Owner	Due Date
15	10/14/10	Send Certificate Pilot Recommendations Consensus link to Implementation Geographies WG	CLOSED	Uvinie Hettiaratchy, Caitlin Ryan	10/15/10
16	10/14/10	Make edits to Best Practices for HISPs document: · Clarify that an organization only needs to sign a BAA with one external HISP, with a chain of connected HISPs allowing for network wide exchange · Add language specifying that this document applies to the HISP as an organizational model, not a function that is internal to a covered entity · Explain that discussion about the individual was left out intentionally because the individual and traffic to/from the individual is well recognized within HIPAA Then send around fro Call for Consensus	Open	Arien Malec	10/18/10
17	10/14/10	Set up Call for Consensus page for Best Practices for HISPs	CLOSED	Caitlin Ryan	10/15/10

Actions from Last Week

#	Date	Action	Status	Owner	Due Date
11	10/7/10	Wants additional edit about clarifying the level of trust in the Certificate Pilot Recommendations Discussion	CLOSED	Arien Malec	10/12/10
12	10/7/10	Post organization’s consensus votes to the wiki by Tuesday, 10/12/10. Go to Discussion tab of Certificate Pilot Recommendations Discussion	CLOSED	Best Practices WG members	10/12/10
13	10/7/10	Can mark Question 8 in Open Questions Tracker for Pilots as transferred and addressed	CLOSED	Arien Malec	10/8/10
14	10/7/10	Form a task force to draft recommendations	CLOSED	Arien Malec	10/14/10

Agenda

1. Certificate Pilot Recommendations move from workgroup call for consensus, next stop Implementation Geographies or full Implementation Group?
2. Review draft Best Practices for HISPs document
3. Assess need and ability to add additional items from the Open Questions Tracker for Pilots to the Best Practices Workgroup backlog

Notes

Uvinie Hettiaratchy
Certificate Pilot Recommendations

• Wrapping up discussion on Certificate Recommendations for Pilots
• Was up for WG Consensus this past week, closed on Tuesday (10/12/10)
• Latest vote: 8 organizations accepted the document, 0 did not accept
• Next step is putting the document up for Implementation Geographies WG Consensus, before putting up for IG Consensus
• Will send link to Implementation Geographies WG to finalize by next week

Best Practices for HISPs

• Last week the WG identified a second priority: guidance around HISPs in terms of security, audit, logging
• Arien Malec drafted an initial proposal, which is now up on the wiki
• The document has gone through a mini review, still working out the details
• Summary
• Defines HISP
• Describes HISP function in terms of management and security
• Explains the organizational model
• The document focuses on HISP organization and implications of privacy, security, and transparency when the HISP exists as a separate business organization from the sending organization, not when the HISP is part of the sending organization
• Covers
• Legal requirements
• Security
• Data retention
• Asked the WG to review the document and give initial reactions

Rich Elmore

• Would be helpful to walk through the document more before forming opinions
• Asked if any of the authors were on the call <no response>
• John Moehrke had said that technically a HISP is not required
• Rich didn’t understand the implications of that statement, and what the BP WG thoughts might be on it
• Didn’t see that anywhere in the document

<Arien Malec joined>

Uvinie Hettiaratchy

• Asked Arien Malec to go through the document

Arien Malec

• Overview of Best Practices for HISPs
• During the last WG meeting, WG identified best practices for HISPs in terms of privacy, security, transparency as a top best practices priority
• He took the work of the Privacy and Security Tiger Team as recommendations to HHS, and re-encoded them back out as best practice recommendations
• HIPAA and Legal Agreements
• Started with HIPAA and legal agreements, HIPAA provides a strong set of privacy and security rules and laws, but not every Direct participant falls under HIPAA coverage
• HIPAA defines the extent of legal breadth as providers or organizations in specific classes that transact using HHS standards
• Usually read out as admin standards
• There is a need for this document because organizations that are not covered entities or business associates don’t have the same levels of protection
• Started by following the HIPAA requirements, noting that HISPs are likely to be business associates and will require Business Associate Agreements (BAAs) with HIPAA Covered Entities, but where BAAs are not explicitly required, there needs to be equivalent contractually binding legal agreements
• Determined that many HISPs may not be a “business associate” defined by HIPAA as revised by the HITECH Act
• Pilot Recommendation: All HISPs must have Business Associate Agreements or equivalent contractually binding legal agreements with the sender or receiver of directed exchange of PHI
• Second agreement recommendation is about holding information flows to organizations that have strong protections under law for individuals, covered entities, business associates, or organizations covered by equivalent contractually binding legal agreements to cover those that aren’t covered by HIPAA
• Essentially the intent of that legal agreement section is that we want to be doing business with organizations already covered by HIPAA or by strong equivalent language
• Pilot Recommendation: Directed exchange where participants have access to unencrypted data or could have access to unencrypted data (because they hold decryption keys for encrypted data) must involve Individuals, Covered Entities and Business Associates (using those terms as defined by HIPAA) OR organizations that have strong legally enforceable contractual obligations that provide equivalent protection for individuals to those provided by HIPAA.
• Security
• Pilot Recommendation: 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.
• Brett Peterson pointed out that we’ve got some HISPs that will be managing separate keys for end points, so we need to do risk assessments for private keys
• Transparency and Data Handling/Retention
• Pilot Recommendations: HISPs must follow HITPC recommendations by including all data use and disclosure policies (including rights reserved but not exercised) in BAAs or other service agreements. Function of exchange may require retention of data, calling out as a need
• But noting that there is no back door for having audit trails; audit trails are not an excuse to have data, use, retention policies that are not covered by the use and disclosure requirements
• “No Side Effect” Rule
• If I’m doing directed exchange, my intent is not to leave a copy for secondary use, the intent is that not be done
• If there is a use for retention of data… all good and valid use cases, have a different set of privacy, security, consent requirements, those have separate functions
• Process
• The document is currently in its first draft
• Did a round of editing with a small group
• Asked WG for questions/comments

John Williams

• Asked about the temporary storage of an encrypted message that is just waiting for pickup by the recipient -- is that subject to the last recommendation, regarding storage of info that is not intended for secondary use?

Arien Malec

• Needs to get some clarification on this issue
• He understands that there is specific legal and regulatory coverage for data that is being routed, particularly when fully encrypted, when the intent is to only call out the data that is potentially PHI, identifiable
• Intent of the recommendation is to say that the best practices are covering access to unencrypted or potentially unencrypted PHI
• Needs to get better clarification for the rules on fully encrypted data, not subject to the same kinds of data

John Williams

• Yes, it is encrypted data, but there is added risk when we also manage the keys

Arien Malec

• As long as minimal requirements are met
• Storing to deliver to an individual recipient, as part of MU, is an appropriate data use that is intended to fulfill the function of exchange, when there is sending/receiving according to provider expectations
• Issue comes up when you take that same data and do other things with it, such as anonymous quality reporting or other secondary uses that may not be intended by the sender/receiver, and may have different security requirements

Don Jorgenson

• How will we handle expectations across the entire Direct community for security, privacy, transparency In a HISP to HISP environment?
  
  

Arien Malec

• The groundwork for that is being established within the Governance WG of the HITPC, which establishes policy for the Nationwide Health Information Network and governance for members of that network
• The idea is that the best practices we are testing out in the Direct Project will be referred over to the Governance WG

Rich Elmore

• Is the requirement for the HISP to have Business Associate Agreements (BAAs) for each party they have connections with?
• Would be ideal if a legitimate healthcare stakeholder only had to sign one BAA with one HISP, so that there is a chain throughout the system that connects them to others

Arien Malec

• That is the intent, so if that isn’t clear, he is happy to do some edits to clear it up
• A covered entity and BA need to have a BAA

Rich Elmore

• So HISP to HISP connections would share BAAs?

Arien Malec

• The policy is in flux, you can find lots of examples in financial transactions, clearinghouses are covered entities from a HIPAA perspective, but in many cases the large claims networks have contracts with the other large claims networks to do transactions
• This is not a scalable model
• Only scalable if you have large aggregators
• Would rather not have a legal arrangement that subverts the technology infrastructure
• The law is reasonably clear—if they are transacting as covered entities to BAs, or BAs to covered entity, they can extend the legal responsibilities through the BAA to the BA
• Becomes confusing if you have PHI going from covered entity to BA to third organization to covered entity, for example
• That gets messy from a policy perspective because there is no clear path of HIPAA coverage
• For encrypted data, if there is clear coverage, once it gets routed and is covered thorough intermediate areas, it is no longer covered
• So there is a safe harbor for fully encrypted data

Rich Elmore

• Great to hear
• People tend to be concerned and cautious on this, so we have to be careful about what we are saying
• Next Question: John Moehrke suggested that a HISP isn’t necessarily required
• He wants to understand what the Best Practices WG thinks about that statement
• What does it mean?
• The issue isn’t addressed in the document

Arien Malec

• In the first section of the Best Practices for HISPs document a distinction is made between a HISP as a function and HISP as an organizational model
• This document is specifically about the HISP as an organizational model
• A HISP could also be a function, working within a covered entity
• Policy is already clear if the covered entity is doing all the work
• Cleanly follows HIPAA guidelines, falls under the covered entity requirements for use and disclosure

Rich Elmore

• Would like to see that made more clear in the document as well, so that all stakeholders could understand

• Next Question: How does this work for individuals, in terms of patient communications?

Arien Malec

• Great question
• He left specific discussion of the individual out of this document
• Using “individual” as defined by HIPAA
• Left out intentionally because the individual and traffic to/from the individual is well recognized within HIPAA and individuals are making a determination about what they want to do
• The issues occur with the BA of the covered entity
• Would be worthwhile to articulate this point more clearly as well
• Best Practices for HISPs Next Steps
• Arien Malec has some work to do, will do another pass on this Best Practices for HISPs document
• Two options
• Given the comments, could do a round of cleanup
• OR
• Could proceed more rapidly and open up for Consensus so that at the next meeting they can discuss after everyone has had a chance to read, give comments

Rich Elmore

• Asked if Arien ran the document by pilot project leads who will actually be implementing HISPs

Don Jorgenson

• Don Jorgenson and Pat Pyette from Inpriva are in both groups

Arien Malec

• Ran by Gary Christensen, Sean Nolan, David McCallie and Brett Peterson
• All have HISP functions they may be running
• Will make edits, open up to Call for Consensus
• Workgroup Next Steps
• One approach is to say we have two best practice documents in flight, so we should focus on those and go through the process to get them closed out as IG best practices before moving on to new projects
• OR
• If there was energy in a sub group to take on an additional area where the implementation geographies seek best practices advice, we can launch a third document
• Last time the two policy areas we thought about were:
  • Limits on attachments
  • Provider directory

Question
Question about provider directories

Arien Malec

• There is a focused HITPC Information Exchange WG sub group working on provider directories, led by Micky Tripathi, who is a member of the Direct Project IG
• The group has been exploring policy for provider directories, meeting regularly
• All public information, can find on the FACA site for ONC
• They have been framing ideas for provider directories, and going back to the Policy Committee with recommendations

Question

• For HISP to HISP exchanges, some certificate distribution issues may fall within the scope of provider registries
• They are facing those issues already through the pilots

Arien Malec

• DNS-based approach can work
• LDAP-based approach will be tried
• Have not thought through universal discovery approach

Question

• One of the things John Moehrke was putting forward for the LDAP approach was that there were organizations who did not want to participate in a fully public way
• That was the rationale behind not making it DNS

Arien Malec

• Right now the spec says we recommend that you participate in the DNS route, or else find something else that works
• It is a tough problem, but we think we have a solution that works
• Anything that works and allows for wide operability exposes certificates

Arien Malec

• Commended the WG on their good progress