BlueButton+ Pull Workgroup Meeting

BlueButton+Pull Workgroup Meeting April 23, 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 • Do not put your phone on hold. If you need to take a call, hang up and dial in again when finished with your other call • Hold = Elevator Music = frustrated speakers and participants • This meeting is being recorded • Another reason to keep your phone on mute when not speaking • Use the “Chat” feature for questions, comments and items you would like the moderator or other participants to know. • Send comments to All Panelists so they can be addressed publically in the chat, or discussed in the meeting (as appropriate). 2

Agenda

Direct Connect a Thon – May 9, 2013 • Thursday, May 9, 2013 @ 11:00 am Eastern • 20-30 minute presentation slots available • Contact Greg Meyer (GMEYER@cerner.com) • Register • http://wiki.directproject.org/May+2013+Connect-A-Thon

Dates: June 3 – 4, 2013 • Location: Omni Shoreham Hotel (Washington, DC) • Health Datapalooza IV (HDP IV) is a forum that features the newest and most innovative and effective uses of health data by companies, startups, academics, government agencies and individuals. • Sessions of Interest • “Powering Applications Using Consumer Data: Blue Button + For Developers. “ • “Unlocking Clinical & Claims Data by Giving Consumers Access: Blue Button + For Data Holders” • Registration ends May 24. • $750 Standard • $495 Govt/Academic/Non-profit • More information here: http://healthdatapalooza.org/ • Register here: http://healthdatapalooza.eventbrite.com/

Update Documentation on BlueButton+ Pull API URL: http://blue-button.github.io/blue-button-plus-pull

Discussion (from April 9) Text

Discussion (page 2 from April 9) Text

Pull Best Practices GuideDRAFT Outline • Giving a patient a web address to PULL from • Unique URL for pull functionality • Authentication • Existing login credentials, using OAuth • Authorization • OAuth • How long do authorizations last / ability to cancel • Synchronization of request / granting access • What does a sample patient consent to PULL look like • API guidelines • Generalize across APIs presented to the group • Triggers & Automation • Document types • Trusting third parties with PULL access • Trust framework necessary for a dataholder to implement PULL. What are criteria for being included in trust group? How is it governed and managed? • Audit Capability (based on BB logging?)

Next Steps / Actions April 23: ACTION - “Bring a Friend to WG Day” Ask everyone in ABBI community to identify and see who could participate. ACTION: Contact POCs from HIMSS after work group has stable API document (end-April) April 9: ACTION - Josh to describe/present layering in bearer tokens into dynamic registration (based on smart reference implementation example) to the work group ; coordinate with Keith via email and incorporate Keith’s specification into a single, cohesive protocol. (yay! Thank you thank you!) ACTION: Update ABBI API Documentation (Keith) [DONE]

Meeting Reminders • Meeting Reminders • Next PULL Workgroup Meeting is Tuesday, May 7, 2013 @ 3:00 pm Eastern. • Event: Direct Connect-a-thon on Thursday, May 9, 2013 @ 11:00 Eastern • Event: Health Datapallooza June 3-4, 2013 (in Washington, DC) • Useful Links • http://wiki.siframework.org/Automate+Blue+Button+Initiative • Contact Information • Initiative Coordinator: Pierce Graham-Jones (pierce.graham-jones@hhs.gov) • Presidential Innovation Fellow: Ryan Panchadsaram (ryan.panchadsaram@hhs.gov) • Project Manager: Jennifer Brush (jennifer.brush@esacinc.com) • S&I Admin: Apurva Dharia (apurva.dharia@esacinc.com)

Appendix – Reference Slides from Previous Meetings Appendix – Reference Slides from Previous Meetings

Previous Meeting Slides Slides from April 9, 2013 Follow

Discussion & Response to Dynamic Registration(from April 9) Question (Chris): How does the trust bundle determine what characteristics the apps need in order to become part of the bundle? And I realize this is out of scope. Response: (Josh) Yes, those details are out of scope, but they are trust bundle specific. Different trust bundles might have different kinds of local policies. We are focused primarily on the functional requirements (e.g. publish a list of providers and apps that are trusted). Comment (Chris): There is a concept called a trust framework – the idea is that it combines in a single, binding policy document the technical rules (which we have here, in Pull), the business rules and the legal rules all together. So here in Pull we are only concerned with the technology slice, but we agree that there also need to business rules and legal rules, and agree that this will be different between different trust bundles. Question (Bart): If there are multiple trust bundles, what’s the vision? 10? 100? 1000’s? Response: (Justin): I believe it is hard to predict that, although there should be significantly fewer trust bundles than there are providers and applications. What that will look like and who will stand them up and run them – I don’t think we know yet. No one actually envisions the providers becoming trust bundles (but some large ones might). Comment (Adrian): I can give you 2 real world data points. In Mass, the SHIE invented a protocol for creating a provider directory for use with the DIRECT-based messaging, because they didn’t feel that there was anything out there simple enough and practical enough to use. I think we will find that SHIEs are already doing some of this. The second point is that ONC gave 200+ thousand to another HIE operation to work on the directory problem (NY eHealth Collaborative) and don’t know how long that work is going to go on – they are explicitly granted to work under a provider directory piece. Comment (Bart): At some point we might need a directory to point to all the trust bundles. Although it could be pretty light weight and is out of scope for this document.

Discussion & Response to Dynamic Registration(from April 9) (Page 2) • Comment (Chris): My concern is about how the technology gets used; are we in fact enabling dataholders to decide what the criteria are for apps to get certified by trust bundles so that they can access data from that dataholder? I’m trying to understand where that discussion is supposed to take place amongst the various parties that are part of BB+. • Response (Josh): Agree that what we are doing here does let providers describe the level of trust that they need, and its implicit in the list of bundles that they allow. However, an important part of this specification is open registration and it would be a shame to see providers only do the trusted part and not the open part. We’re going to figure out how the policy works when someone agrees to implement this. • Comment (Adrian): In the Push call yesterday, we determined this might be a call by the office of civil rights. • Question (Josh): So do we need a group to talk about the policy? Or can we go ahead and have someone implement this and test it out? My biased is that working through the policy issues in the abstract is difficult, but if we have the technology implemented then those discussions become more concrete. • Next steps • Community homework is to review the specs. • Look for a committed data holder entity to implement this guidance. • Begin the policy discussions that have arisen because of this implementation. • Need good reference implementations of this guidance.

Next Steps / Actions April 23: ACTION - “Bring a Friend to WG Day” Ask everyone in ABBI community to identify and see who could participate. ACTION: Contact POCs from HIMSS after work group has stable API document (end-April) April 9: ACTION - Josh to describe/present layering in bearer tokens into dynamic registration (based on smart reference implementation example) to the work group ; coordinate with Keith via email and incorporate Keith’s specification into a single, cohesive protocol. (yay! Thank you thank you!) ACTION: Update ABBI API Documentation (Keith) [DONE]

Previous Meeting Slides Slides from March 26, 2013 Follow

OAuth Workflows are Updated on Wiki http://wiki.siframework.org/ABBI+OAuth+Workflows

Discussion (Dynamic Registration)page 1 Question (Adrian): Dynamic registration – consider physician’s ability to prescribe an app to a particular patient (his, and his alone); how would that work with the dynamic registration trust bundle? Specific concern is that the policy concern is focused on the physician, rather than the technology or the institution. Policy (definition): when we create a guide / documentation for the technical implementation, there should be no restriction on the physician prescribing an app; there can be policy restrictions at the institution (e.g. conditions under which the institution will take action). Response (Keith): Interesting – in terms of the scope of what we are trying to accomplish, it would enable it but would not be all that is required. If patient had that app, either mechanism would enable them to get to their data. May table this for later discussion. Question about trust bundles – is what the technology of the trust bundle would enable, then there is the policy that would enable certain behaviors. The mechanations of how to go through the steps to implement the technology must also be considered. Would prefer the concern be focused on the patient. Not sure this is the right forum for addressing policy issues with respect to ABBI Pull. There needs to be some place to have those questions asked and addressed. If we named physicians specifically, we would be implying policy. (see blog post: http://motorcycleguy.blogspot.com/2013/03/the-journey-of-4000-miles-could-have.html) Comment (Josh): http://smartplatforms.org/2013/03/bluebutton-tech-and-policy/ ; the kinds of technology decisions / guidance that we are providing do imply some level of policy; goal is to provide patients with the choice to pick whatever app they want. E.g. when you make the decision to use a trust bundle, there will inherently be policy decisions made down the way because of that decision.

Discussion (Dynamic Registration)page 2 Registration Endpoint: intended to be an open registration endpoint / open listener. And still must make a decision about whether or not to accept (based on format, etc.) Authorization Endpoint: makes the decision based on the certificate /validation chain. Comment (Justin): The two approaches that have been suggested do work nicely together. Initiation registration request that it allow for open registration (to allow for a wide variety of different things); but also allow for authentication to the registration endpoint with an OAuth bearer token (e.g. if it were a signed assertion). If the registration happens using something that the trust bundle issues; then the registration can be verified. And certain aspects of the clients profile can be communicated and we can say things like your re-direct URI must be registered with the trust bundle (for example). This is extensible to many parameters. It would be up to individual implementers of ABBI (or up to the group) whether you allow both the protected registration AND the open registration at a provider. Comment (Ryan): Justin’s comment is interesting – combines the best of both worlds. It also lets providers (if needed) close off open registration. Comment (Keith): Planned obsolescence is good. Comment (Josh M.): In the long term, there is a role for apps with a higher level of trust, but we don’t want to make this a barrier to entry.

Discussion (Dynamic Registration)page 3 Comment (Adrian): Agree with the goal of making sure the apps interoperate with one another, but be wary of merging the two layers with one another. The interoperability layer is different than the authorization layer. Be careful of using the trust bundle layer in that way. Summary: If the technical guidance covers both of these optoins, we can provide some clarity on how / when they would be used in the guidance document. Question (Ryan): Open registration allows access to some of the endpoints; but if you are part of one of the protected registration bundles, you get ‘more’ access? Response (Adrian): The only people who legally have standing to make authorization decisions are the physician and the patient. The institution following the guidelines and installing whatever is created, has no legal standing. Just like a medical device or pharmaceutical, in order to have a system that scales and evolves, we have to understand that the authority to connect an app or interact with a patient with those two parties (physician & patient). Comment (Josh M): one implication of that is that being part of certain trust bundles, may lead to different authorization warnings etc., but in the end the patient should be able to authorize the app to do whatever it is they (the patient) want. Comment ( ): In order for the user to make an informed decision, must solve that first part. In response to Ryan’s question, yes you can implement different classes of registration / access permissions. You can also split the world into authorized registered clients, and admin registered clients. Recommend allowing for all of these cases to co-exist in parallel (technically).

Discussion (Pull Guidance Draft & Process)page 4 • “Best practice approach for using OAuth in Healthcare Systems / ABBI Pull” • Recommend getting a specification out the door focused on a spec, for a single endpoint and build on it over time. • What are the gaps between what we have documented on the workflows and API documentation and what we need to have a working spec. • The major gap is an open dynamic registration process. • Notional process for generating spec • Set a date for the draft spec (~ May 7, 2013 for DRAFT Complete) • Volunteers to write each section / contribute • Volunteers to present the document to the community for comment / review. • After draft guidance has been made, we can put it through consensus; or do a pilot and react / revise the guidance, then put it through consensus. • Once we have the guidance, we want to put it on a website, similar to bluebuttonplus.org.

Discussion (Pull Guidance Draft & Process)page 5 • Need a payer / provider (or vendor) to do a test case & reference implementation • VA (ACTION: Contact Glen Crandall, Prog Mgr for Direct @ VA – glen.crandall@va.gov) • CMS (ACTION: Contact in progress) • Humetrix is also interested in participating • ‘Bring a friend to the Pull WG’ for April 23 • Approach: Ask state HIEs (like in Maine) because they are working on a much shorter time table of decision-making. • Approach (if no dataholder identified): Propose writing the documentation as “could be part of MU X” and once written, consider that as the endpoint of the group. • Plan for upcoming Pull WG Meetings: • April 9: ACTION - Josh to describe/present layering in bearer tokens into dynamic registration (based on smart reference implementation example) to the work group ; coordinate with Keith via email and incorporate Keith’s specification into a single, cohesive protocol. (yay! Thank you thank you!) • April 23: ACTION - “Bring a Friend to WG Day” Ask everyone in ABBI community to identify and see who could participate. • May 7: Target for Draft Documentation Complete (?)

Homework Review: OAuth2 Code Samples • OAuth2 Code Samples / Help on Wiki • http://wiki.siframework.org/ABBI+Pull+Code+Samples • (Thank you Adam G., Josh M. and Carlos E.!)

BlueButton+ Pull Workgroup Meeting