Best Practices Meeting 2011-03-10

Notes:

• A number of best practice documents up for review and Consensus.
  • Evaluation for HISP-HISP Agreements:
    • Attracted some comments - "no" vote by EPIC.
    • David: looks like a reasonable suggestion saying there may be other valid reasons why not to accept. Strong statement to say "should not be based on subjective criteria." Likely to always be somewhat subjective when it comes to trust.
      • Arien: Concern raised in using trust anchors to create proprietary lock-in. Not sure the right way to word in a way that's going to get cleaned up concerns appropriately.
      • Perhaps changing "musts" to "shoulds" would be sufficient remedy? Have to think through - or propose alternate wording that would turn away from "must".
      • Market demand will dictate - likely get market forces to not lock out - hard to do in a best practices statement.
      • Perhaps should word as "should be open/transparent" something a little less strong - less constraining. Try to re-word. Re-circulate re-worded version with group.
  • Best Practices for HISP-HISP Agreements
    • BP WG members should review by next week's meeting (3/17).
  • Work in Progress: Best Practice for Content and Workflow
    • Up for Group Discussion - focuses on notions of lower bounds of information exchange - what low bar Is set for expectations? This is coming directly from Dixie's concerns and Carol's concerns.
      • David: Concern w/ language implies couldn't host address that wouldn't accept text. Carve out for CMS that was allowed. Inconsistency.
      • Arien: Intent was to say provider best practice was to have at least one address that can accept text/pdf. Not that all must, but best practice for at least one to accept. Also recognized some organizations may have no business interest in receiving text.
      • Need to reword to make sure spirit is clear - if accept text today, and shift to Direct, they should still accept text. Doesn’t preclude special purpose address that accept specific structured data. (lab feed or PQRI submission to CMS). Spirit is clear, should design service to accommodate lowest common denominator.
    • Other comments from group on this one?
      • Put any comments/issues in the discussion section on the wiki.
    • Being able to point to recognized best practices as a point of reference will help alleviate concerns.
  • Rich: Topic came up of communicating what Direct means for patients on this week's Communications WG call. Had previously prioritized certain user stories around patients involving Direct for provider>patient communication. Had not prioritized patient>another stakeholder. Tech enables this, but we do not have best practice guidance around it. Appropriate to start to address that issue. Need to get arms around before we have lots of messaging to patients which creates a gap in what we have out there today as far as Best Practices.
    • In a way, covered most of what's involved with provider>patient direction, the challenges are in return. That kind of definition on return - think we need to get arms around and provide some guidance.
      • Dave: Have we anywhere posed question of extending trust circle out to PHR around ID proofing and authentication?
      • Arien: At one point, noted outbound patient, get proxied on provider-patient relationship. Have not at all addressed inbound. A lot of discussion about a year back, in terms of white listing, etc, that we could re-use. Agree with Rich, hasn't been addressed and will come up as an issue fairly soon.
        • Tiger Team will be focusing on consumer authentication next couple meetings. At a policy level, issues are just now getting attention. Direct will likely be a use case that is discussed. Perhaps we get there in parallel with tiger team. Recommend letting a few meetings happen and begin to create. Direct has been doing a great job identifying questions, FACAs have not been doing a lot to answer all of them yet.
        • John: On the other hand, throwing back to HITSC is not a good idea. This is a policy decision, though it doesn’t have to be a policy decision made as cut and dry. Can defer policy decision until transaction time and have service say -good ID given, but if don’t have high enough level of assurance, then reject. Such an attitude, that unless we lock down policy that assures no one will ever be denied because of level of assurance issues, is not a reasonable expectation. Some transactions are asking for high sensitivity information for which high level of assurance makes sense, but other requests for information of low level of sensitivity where low level of assurance would be sufficient. Deferring decision through enabling technology could be right decision.
        • Circle of decision making, if let it work can come to a conclusion that works for all. Market will inevitably settle on reasonable set of compromises that will inevitably become de facto policy. Best practice can emerge on its own based on what's good enough.
          • Start with thinking through this at level at which we ensure trust to allow communication with consumers in first place. Secondly, what do you do about replies to messages? Third, unsolicited messages.
            • 1 and 2 might go together. But again, not sure. Do agree with point that there's some broader policy points here, but actually had in September call with Deven where agreed that this is something had to come back together around from HITPC and tiger team. Not a bad structure laid out, but caution some are intertwined.
            • This group can help tease out differences - difference between trusted ID and authorizing trusted ID to do something- and having something be manual vs automated. Think it'd be useful for Best Practices WG to look at it. Simplified workflow - Direct - when we look at how a patient would use to interact with a provider, have a constraint already. Easier to separate out fact that ID has to have some trustability to it, with fact that some mechanism by authorization of entity - is there a relationship? Think by being able to say in best practices that can tease different things apart and hand them more well scoped to policy decision than just asking for policy on how patients talk to provider.
            • David: Wonder whether we think of PHR as the HISP for consumers? Is there a best practice around what it means to be a HISP for consumers
              • Arien: concern with PHR holding certificate - good high assurance credential and that does nothing for any level of assurance for patient.
              • Need best practice to say if using institutional certificate.
              • Certificates need to be in name of organization or of individual
              • Why not have HealthVault be organization? If have provisioning requirements for level of assurance for provisioned ID - why wouldn't it be any different?
                • Exactly issue - people look at organization ID and make carryover level of assurance for organization to individual. If can't hold to that constraint at same level as vouchingfor self, then shouldn’t assert organization identity. That’s why teasing apart is necessary.
                • At minimum, best practice document, maybe more.
                • Rich: Not a PHR question - consumer/patient innovation will be huge. Assume that whatever's on other side of Direct transmission is secured/encrypted. Haven't made assumption that PHR or other particular technology.
                  • If genericized as consumer facing HISP , need for special policy since it's consumer and not provider facing.
                  • Might not need to be that delineation. For provider to send to consumer, don’t need a consumer facing HISP. Patients don’t need to reply.
                  • Level of ID attributes - one critical is HIPAA covered entity - different set of policies for HIPAA CA's than for non-HIPAA CA's than an individual. May need to think how we use separate ID for different attributes. If can assume know individuals ID, may have different trust considerations for non CA's and CA's. Struggle how to do in a way that’s simple and ubiquitous
                  • On a call discussing certificates with HITSC, multiple trust routes model that Direct has as opposed to traditional hierarchical. Possible that given provider with respect to other providers, may hold to a higher trust level than he does with consumers but using same tools to communicate. Model allows for this, but figuring out what that practice is defined as is next challenge. Some certificates are trusted at a higher level , and some at less assured level and cant afford higher level assurance. Model allows, but no policy implementation. How do we frame question?
                  • MU gives great use case for providers need to push data to consumer - think as we've all discussed. It's relatively easy, as sender is responsible for saying they want to send to receiver. HealthValut has means for assuring that identified receiver owns the account. It's the other way. Think its something we can tease apart and get everything involved in.
                  • Think we need something concrete about that best practice - measured against microsoft, for example. Don’t suggest documenting existing process today. Document how we get to a best practice. Microsoft has done something that many consider reasonable, but in absence of a best practice framework. We shouldn't take as template that others follow without writing it up. Presentation of request by consumer to physician in way that practice validates, captures consumers address, uses that address - many steps that we should form as a first step at provider>consumer best practice. Then craft unsolicited consumer>provider in context of solicited provider>consumer. The former is less clear. Start with easier one.
                  • Struggle with separating identity and authorization. How do you separate ID and one ID attribute is patient or provider? Not sure now how receiver would be able to tell on an inbound transaction.
                    • You can get same info needed out of a certificate. Know it’s a patient when certificate reads that it’s a PHR. Can know it’s a patient, but how do you verifiably relate that to one of your own IDs of patients?
                    • If have a patients' ID to send to patient, its just a reverse lookup. Source address is x - reverse lookup on who it is. Have to have trusted came from trusted is going to encode correctly, but it’s a cross reference domain. Equivalent of patient.
                    • Suggesting that it should always start with outbound provider>patient. If not, need to go to a human bucket - large organizationss are afraid of this. Landing spot for everything spam and beyond. Organizations may solicit that - send information and we'll contact you back and proceed. Think organizations could want that kind of input - but that's a sidenote. Like notion that who we know more, Best Practice is that conversation should start with providers proofing of consumer via mechanisms in practice, such as a consumer providing provider w/ Direct address. Provider initiates conversation outbound, then inbound understand and have cross reference and consumer has provided that address is correct.
                    • W/ John's assumption that trust anchor IDs as patient - all that works. Whitelisting for inbound. Should be a local policy and that should work. Critical assumption is that organizations have a way to identify and segregate. Need to specify how to communicate that in trust anchor. Don’t have to have necessarily be attribute, but Best Practice could be here. Don’t have to invent, just specify. Would need something to mark it - could white list. Organizations are consumer organizations to verify via trust anchor. Would likely have multiple trust organizations in store. Put some in provider, some in patient stores.
                    • Better off trusting self to have trust store and say that there needs to be a person in trust to approve certificate.
                    • Just worry in a large scale HISP (surescripts model), how is information communicated to provider?
                      • Out of bounds of spec - up to and including trust verification.
                    • Saying we know of at least one way it can be done is important for people to know. Specification doesn’t cover, but one way can be done. Groups can do however they want, but if we provide at least one way can be done, then should be successful.
                    • For a fully trusted HISP model , HISP is responsible for saying signed and come from address in certificate that signed. Forwards to message to you with security stripped. Should be sure HISP hasn't mashed from someone else.
                    • Can be solved in many ways -why its out of spec bound.
                      • 1 - HISP can send to specific inbound address regardless of where sender sent to.
                      • 2 - if using RFC 253.22 - can put custom header. If using XDR can put custom attribute. Proprietary - allow whatever. Has to be some means for HISP doing trust services to flow information appropriately back.
                      • Default case is that you trust HISP not to mangle name - you should trust name hasn't been spoofed. Best Practice document covering this space is a good idea.
                      • Suggest method of distinguishing between healthcare stakeholders. Think if providers think about how thy interact w/ vendors w/ patients, w/payers, probably look at and treat different. If have to deal with problem, maybe think about this as well.
                      • The name communicates source -says a lot. This is a Best Practice in and of itself. Name should be as specific as possible.
                        • If don’t recognize the name, apply different level of scrutiny to that transaction. Lookup from address as patient ID - assuming already established outbound relationship.
                        • Still needs a best practice, but don’t need to go to the Nth degree to define. Can be very simple. Don't let perfection get in the way of good enough.
                        • Needs to have cross reference, need to make its sure not limited. Patients will likely have multiple direct addresses.
              • Actions:
                • Wordsmithing on HISP-HISP Agreements
                • WG to review other docs
                • Arien to help get started on BP for patient communication draft. Rich happy to contribute at later time. David anxious to help contribute feedback here.