Automate Blue Button Initiative Pull Workgroup Meeting. February 26, 2013. Meeting Etiquette. From S&I Framework to Participants: Hi everyone: remember to keep your phone on mute . All Panelists . Remember: If you are not speaking, please keep your phone on mute
February 26, 2013
From S&I Framework to Participants:
Hi everyone: remember to keep your phone on mute
(Keith) Comments on OAuth Documentation
(Keith) Endpoint API Pieces
BlueButton+ for Pull Summary Discussion
Josh – quick review of demo from Push
Adrian – Mass HIE Slide (ways to build on top of Direct). Why wouldn’t we do this according to BB+ standards?
Update Summary Document on Search / Summary Endpoint
Josh’s idea re: simplifying access for Push
Adrian – on agenda for next time (March 12): Patient directed exchange vs. Patient mediated exchange
Meet up during Interoperability Showcase @ HIMSS face-to-face. ABBI Kiosk # will be sent out to team. ABBI Support Team will coordinate and send out a ‘meet and greet’ possibly during this time next week.
We’ll send link out to the list with the link to the updated Keith doc.
HIMSS is March 4 - 7
Next meeting is March 12
Separate patient alert best practice depending on whether their chosen BB+ endpoint is associated with a Direct Trust Bundle or not. This too applies to both Push and Pull
Other issues: such as Notification and enhancements based on RHEx-style OpenID Connect can be moved to a future release
Appendix – Reference Slides from Previous Meetings
I think most of Keith's proposal is spot-on and represents a tremendous effort in producing a concrete, readable document. So please forgive me for focusing on two points of dispute. But there are two key areas where I would push back (and see my inline comments for more detail):
1. The "registrar" component is a major source of unnecessary complexity. It's a new invention that (as far as I can tell) hasn't been used in the context of OAuth registration before. (Please correct me if I'm wrong here.) And the registrar is necessarily a trusted component that talks to multiple apps, their instances, and authorization servers. At its heart, any added security offered by registrar relies on "mechanisms not described by this specification" to verify "a legitimate instance" of an application. And I have trouble seeing how this would happen in an environment with diverse apps running on multiple platforms. My recommendation is to eliminate the registrar component from ABBI's specification, and simply have each authorization server provide dynamic client registration services per IETF's draft-ietf-oauth-dyn-reg spec.
2. I maintain that ABBI should provide first-class support for pure browser-based apps that are incapable of maintaining a secret. For such apps, security essentially comes from being hosted at pre-registered HTTPS URLs. Browser-based apps should use OAuth 2's "implicit grant" workflow to obtain tokens. For this type of app, implicit grant is not less secure than other workflows -- and to my mind (and no pun intended) it makes *explicit* the fact such apps are operating as public clients.
Notes: We’ve noticed that much of the agreement from the group is around the pattern of access. E.g. OAuth, some mechanism for apps to dynamically access, etc. Area where we are seeing less consensus is actually describing what these endpoints look like. Key question is ‘who is going to build this?’ Although we always want to find a balance between standardization and innovation, one of the ways to maximize those for this effort is to avoid being proscriptive about the endpoints, let the community experiment with the guidance, and see what comes out of the community over the next few months. Push’s success is in part because of the paradigm of assembling things off the shelf in a particular way. Pull only has OAuth on the ‘shelf’, so pointing to endpoints might be difficult. Recommend focusing on the “Pattern of Access” using OAuth and delegation.
Thoughts? Recommend sending out this discussion starter in an email for discussion.
Comment (Adrian): re: Endpoint discovery, I did suggest early on that we link endpoint discovery to DIRECT email addresses at the endpoint. That would in effect bring in the benefits of DIRECT (which are already being worked through on the Push side). This could be used then to boot-strap the OAuth connection. Screen mock-ups were used to demonstrate how that could happen. This remains one possibility if we are willing to discuss endpoints giving themselves a DIRECT address.
Response: It is difficult to prescribe a path that no one is taking yet. Perhaps we could take the endpoint description and keep them, but focus on the OAuth component which we know is going to be the popularized way of making that connection (e.g. like RHex Project). We certainly wouldn’t say using DIRECT to boot-strap is bad, but we need to wait for those innovations to happen.
Comment (Adrian): Agree, however, to the extent that we (ONC) would issue guidance saying that the accounting for disclosures should be part of a patient accessible screen on the portal, the rest sort of falls into place and you don’t have to specify much else, because that brings information about what endpoints will be shared, and with who. I don’t think we need very prescriptive standards beyond OAuth 2.0 and DIRECT; however, what’s missing is specificity around the consent mechanism as reflected in the accounting for disclosures – that policy guidance isn’t standard for implementation issues. This issue of specifying accounting for disclosures for patients has come up in the HIE committee meeting today and remains a problem. [Paul Tang Rule: “If you’re surprising the patient, you aren’t doing a good job”] -- At the HIE meeting today, there was discussion around the problem of consent (opt-in/opt-out) when you try to do health information exchange on a national scale. Everyone has the issue of dealing with a finite number of endpoints within their geographic location. But as soon as you talk about larger regions, like a whole country – people are stuck in terms of adjusting and arriving at common governance and common policy for how to handle it.
Comment (Ryan): If there aren’t answers to question around policy for disclosure, we certainly have the ability to ask them.
Comment (Adrian): If we took the accounting for disclosures and the Paul Tang rule and presented it to the appropriate committee in the right way, then all of the other pieces about defining an endpoint could fall into place.
Question (Ryan): Have you thought about what the disclosure / accountability screen would look at, what are the metadata items on there that would be disclosed?
Comment (Adrian): State level requirements re: not disclosing particular information (e.g. HIV), then there is patient preference – as candidates for authorization (for data segmentation). Any conversations about data segmentation must come from both perspectives.
Comment (Chris B): Data Segmentation is tough. Issue for example, taking HIV history. There are multiple components of the record when considering how/who to allow to look at or not look at pieces of the record. May be a Pandora’s box to open this issue.
Comment (Pierce): Agree and we should keep in scope with our use cases / charter and focus on segmentation on document level and time. Individual providers can define particular pieces and how to assemble those documents.
Comment (Adrian): Agree with document level data segmentation. Not only who and when can be exchanges, but what it was.
Deadline is by next week’s meeting (Tues, Feb 12)