Best Practices Meeting 2011-02-17
Jump to navigation
Jump to search
- Trust Criteria for CA's.
- Pass at Evaluation Criteria for Trust Anchors and CA's. Added (as discussed) objective review policies, renamed document. Those were key aspects agreed upon previously. Think done working at sub-team level. Consensus page open until 2/22.
- Verizon was invited and were on the sub-team discussions. They operate a bridge CA and Registration Authority ID verification infrastructure - interested in participation. Arien to remind Verizon that document is out there for review.
- Members of this group requested to review and endorse. Also to run by Implementation Geographies WGs to review for their needs.
- This group is comprised of fast learners, but we are fast learning, not expert. Appreciate review by Imp Geos.
- WebTrust, ETSI, federal bridge - most CAs certified by these? Not necessarily, annual audit done. Would be an ideal add.
- If federal bridge certified, probably high trust provider.
- Everyone should read/provide additional comments to fix, etc.
- Should send email out to both BPs and ImpGeogs WG and make sure it meets joint needs. Make sure that Rich helps us to get the details right.
- Pass at Evaluation Criteria for Trust Anchors and CA's. Added (as discussed) objective review policies, renamed document. Those were key aspects agreed upon previously. Think done working at sub-team level. Consensus page open until 2/22.
- Relating to consensus approved document, best practices for HISPs - ongoing area of evolving discussion. In preamble, notes that one reason that we're creating BP for HISPs doc is to ensure that individuals can participate with confidence. Because Direct compliant message is a signed/encrypted SMIME content (a HISP who receives a message from another HISP has no access to the underlying PHI). Only in a case where HISP has been delegated access to key, would HISP have access to PII/PHI.
- Delegation is between HISP and receiving party. Belief a need was for a BAA between HISP and receiving party, not between HISP and other HISPs.
- Wanted to re-raise issue (seen with a number of orgs) raising requirements for BAAs between HISPs. Need to make sure at the BPs WG level that were on same page of intent of document and agree on policy. Need to restate that section in stronger terms?
- What is rationale for folks wanting in place?
- Trying to get to bottom, but think there's a general HISP - HISP network to network concern with PHI and BAAs, though it may just be standard reflexive legal policy. Need to remind people that key relationship is not at the HISP level, but at sender/receiver level. That if you trust who you're communicating with, HISPs should be getting in the way. Key privacy/security issues relate between CEs and BAs not with HIPSs, since HISPs only receiv encrypted information. Potentially a case where HISPs are trying to maintain control of ecosystem - want to make sure that doesn’t happen.
- Did we ever get legal opinion on whether BAAs were necessary?
- Arien had discussion with, though did not receive legal opinions from ONC top officials regarding this. OCR-HHS is administrator of HIPAA. Access to encrytped information falls into a category of routing only, not into a category that triggers requirements. This is a general statement, not legal guidance. Logic makes sense, but what's logical is not always true. May need to have it validated as suggested to make sure its truly the right answer. Best way to get at this is to have OCR issue guidance, but not likely in the short term. Would be good to have a good, confident HIPAA lawyer who truly understands the law take a closer look at.
- Suggested then, that the group makes this statement as guidance. Sender shouldn’t even know that receiver is using a third party. Would rather do the lead in that that is the architecture. It's at the end point that relationship needs to be with, because the message and PHI is secured until the end point, if end point is contracting out, they're responsible for the contract.
- Action is to draft a statement as guidance (not as a best practice), and go through the process.
- Did we ever get legal opinion on whether BAAs were necessary?
- Trying to get to bottom, but think there's a general HISP - HISP network to network concern with PHI and BAAs, though it may just be standard reflexive legal policy. Need to remind people that key relationship is not at the HISP level, but at sender/receiver level. That if you trust who you're communicating with, HISPs should be getting in the way. Key privacy/security issues relate between CEs and BAs not with HIPSs, since HISPs only receiv encrypted information. Potentially a case where HISPs are trying to maintain control of ecosystem - want to make sure that doesn’t happen.
- Related regarding trust levels for HISP>HISP communications. Anything happened on front in getting HISPs together? Arien personally thinks It would be a valuable thing for organizations who are starting to provide services in this area to discuss issues amongst industry. Believes that at end of this, we'll end up with a browser bundle like set of health CA's. Fed Bridge, SafeBioPharma like well known CA's that are high-trust providers of ID certificates for HIE. Theer is some concern that has been expressed by some about governance by proxy.
- Brief Status report on Tiger Team conversation: - no real questions answered.
- On the most recent WG call, beginning to delve into questions of assurance levels for authentication of users of EHRs. Moved passed institutional level, now at end users of EHRs. Started with single factor vs two factor authentication. Diverted toward thinking in terms of NIST levels of assurance. Tending toward notion as defined SV800-63 NIST doc, a level 3 would be what they'd shoot for as recommendation. Several on call said didn’t know what a level 3 means, how burdensome, how difficult would be for access. Next steps- NIST to come to Tiger Team meeting to explain how they envision level 3 in these use cases. Challenge is always understanding what a factor of authentication is. If interpret 800-63 in wrong way, may end up w/ blind policy that doesn’t account for physical location, which can be a factor in certain examples. Physical factors of authentication, multiple in place including access to OR, knowledge of other members of surgical team. Simpler, use cases, nursing station. Paul/Deven - confused about what a factor was. Danger of using 800-63 is that NIST gives in one of areas, very specific guidance on interpretation in terms of factors involved or in ID assurance that’s involved, implies or assumes that operation environment of people in the world, and not operation environment that is nuanced for healthcare.
- Rich: How does one get involved in tiger team?
- Tiger team is not a FACA , but a FACA WG. Public comment is welcome. You're asked to be on the workgroup, but likely able to have presentations to discuss relevant issues.
- Conversation with Adam from OCR - Likely to back away from NIST level 3. Is random knowledge challenge a factor? Also workflow things involved. In many cases it gets into the business of local administrative policy. Local policy is the one that needs to determine what are the local environments that should be allowed to query out? If people try to put too much context into their access control decisions it will drive it forever. At some point, we have to say what's acceptable and were not sure about the rest - local policy will need to define.
- Arien has been presenting BP materials back to priv/sec work group. Work doing here, being fed appropriately into that process, as well. Interwoven.
- Action 1 - general call for consensus across the two Workgroups
- Action 2 - inter-HISP agreements question first draft.
- Rich: How does one get involved in tiger team?
- On the most recent WG call, beginning to delve into questions of assurance levels for authentication of users of EHRs. Moved passed institutional level, now at end users of EHRs. Started with single factor vs two factor authentication. Diverted toward thinking in terms of NIST levels of assurance. Tending toward notion as defined SV800-63 NIST doc, a level 3 would be what they'd shoot for as recommendation. Several on call said didn’t know what a level 3 means, how burdensome, how difficult would be for access. Next steps- NIST to come to Tiger Team meeting to explain how they envision level 3 in these use cases. Challenge is always understanding what a factor of authentication is. If interpret 800-63 in wrong way, may end up w/ blind policy that doesn’t account for physical location, which can be a factor in certain examples. Physical factors of authentication, multiple in place including access to OR, knowledge of other members of surgical team. Simpler, use cases, nursing station. Paul/Deven - confused about what a factor was. Danger of using 800-63 is that NIST gives in one of areas, very specific guidance on interpretation in terms of factors involved or in ID assurance that’s involved, implies or assumes that operation environment of people in the world, and not operation environment that is nuanced for healthcare.