Blue Button Plus (formerly Automate Blue Button Initiative) Pull Workgroup Meeting

1. Blue Button Plus (formerly Automate Blue Button Initiative)Pull Workgroup Meeting April 9, 2013

2. 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

3. Agenda

4. 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

5. Dates: June 3 – 4, 2013 • Location: Omni Shoreham Hotel (Washington, DC) • Health Datapalooza IV (HDP IV) is the fourth annual national conference born from government efforts to liberate health data. The conference 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” • Be a part of it (Deadline April 5) • http://healthdatapalooza.org/present • Panel spots are also open (dataholders & developers) • Registration ends May 24. • $750 Standard • $495 Govt/Academic/Non-profit • More information here: http://healthdatapalooza.org/ • Register here: http://healthdatapalooza.eventbrite.com/

6. Dynamic Registration Overview Documentation on Dynamic Registration & Directory Workflow URL: http://blue-button.github.io/blue-button-plus-pull

7. 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.

8. 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.

9. 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?)

10. 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]

11. Meeting Reminders • Meeting Reminders • Next PULL Workgroup Meeting is Tuesday, April 23, 2013 @ 3:00 pm Eastern. • Agenda: Bring a Friend to the Pull WG!! • Event: Direct Connect-a-thon on 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)

12. Appendix – Reference Slides from Previous Meetings Appendix – Reference Slides from Previous Meetings

13. Previous Meeting Slides Slides from March 26, 2013 Follow

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

15. 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.

16. 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.

17. 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).

18. 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.

19. 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 (?)

20. 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?)

21. 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.!)

22. Previous Meeting Slides Slides from March 12, 2013 Follow

23. Next Steps / Agendas for ABBI Pull • Feb 28 2013 Meeting • (Keith) Endpoint API Pieces [2-28-2013] • BlueButton+ for Pull Summary Discussion [2-28-2013] • Josh – quick review of demo from Push [2-28-2013] • March 12 2013 Meeting • Review Endpoint API Pieces from 2-28 • (Adrian) – Patient directed exchange vs. Patient mediated exchange • (Keith) Comments on OAuth Documentation • https://abbi-motorcycleguy.rhcloud.com/ABBI/api/doc/OAuth2-0.htm

24. HIMSS Summary and Recap • Bill Clinton & Farzad M. had a BlueButton+ mention in their keynote speeches. \o/ • Quest Diagnostics announced that they are going to adopt BlueButton+ [both Care 360 (point of care) and Gazelle (mobile app)] • THIS IS BECAUSE OF YOUR HARD WORK!!!! • Thanks to all great demonstrations at the interoperability showcase (4 kiosks, 100’s of people / traffic through the demonstrations). • BlueButton+ presentations were also conducted on the Interoperability Showcase stage (huge turnout!); leadership (Pierce G-J) also participated in a panel on consumer engagement. • Adrian G. connected with the MITRE consent team about moving BB+ into HIE. • Demonstrations of C-CDA Generation / from the data side was very good. Some were generating ~80% on the C-CDA ScoreCard. • NEW: Keith has additional POCs to add for potential data holders. • FIHR: Some discussion in HL7 booth, but not much activity at that venue. • ACTION: (ABBI Community) Let us know if you are doing follow-up blogs / etc. about HIMSS demo results and we’ll cross post / tweet

25. Endpoint APIs(Summary Endpoint, Search Endpoint) • Assumptions • Focus on the single patient record for view / download • BB with structured data • Format is C-CDA (C-CDA required, plus other options) • Use OAuth Workflows

26. Summary Endpoint Discussion • Summary Endpoint • Definition: The thing that you would get to support the MU requirements for View / Download • Assumption: Document will contain MU core data, in a viewable format, in a the ‘standard’ (C-CDA) format • Question: MU specifies the content of the C-CDA in a TOC situation, that is the C-CDA represented by the summary endpoint? • Response: There is a C-CDA required to give the Pt for V/D (electronically); this doesn’t prevent providers from including all of the content from the TOC document. • “Certified systems need to be able to generate C-CDA for data portability” • Comment (Carlos): Not sure what the summary endpoint does for me? • Response: Record provides the total set of data available, so that it can be explored to find the data relative to the app / search query being used.

27. Search Endpoint Discussion • Search Endpoint • Capability will be based on HL7 FHIR Restful Search API • Group agreed with that specification and has an action to migrate it to the API documentation that has been produced thus far and continue to work out the OAuth details. • Comment: FHIR is also currently working on those ‘better’ endpoints (e.g. query for blood pressure, HW, O2, Rx, etc. but is just a bit behind the ‘give me the whole document’ work) • Format can be specified; C-CDA should be required, but with other options (e.g. I want html, I want C-CDA, I want XML) • Question: What about Data Segmentation? • Response: Recommend looking at what UMA has done with permissions bundling re: scope + authorization. Also – segmentation is under the data holders control and up to them for how they apply their access policies and permissions.

28. Note: Phase 1 is live, and pure Direct. Central HIE will be available via web server. Tech: exchange creates & publishes certificates (acting as a HISP). Propose: 1 – Change the role of the master patient index so that it is populated in a way that is transparent to the user (e.g. no probabilistic component) 2 – Be associated with a Direct email address (regardless of issuerer) Q: Where would the master index reside? A: Utilize infrastructure (@ State HIE) in a way that addresses privacy and does not expose them to high risk.

29. Discussion OAuth tokens are representations of a patients authorization (e.g. a consent) for sharing information. Recommend moving away from policy and instead use the available OAuth 2.0 technology to express ‘patient has consented’. BB+ Pull Scope: define the technical and content standards (in an Implementation Guide) to access and provide patient summary data. Concern: is ability to capture patient consent and send it to a central location out of scope? Yes. Comment: Recommend focus on how OAuth 2.0 will be implemented to support ABBI Pull. Summary: There is interest in adding a patient component (@ State HIE), but we can address again as we move forward through the development of the IG; it is worth having the discussion down the road

30. Discussion (cont’d) • Guidance re: OA 2.0 – work with existing systems that are implementing, etc. • What libraries are people using to implement OAuth 2.0 on the client / application side that might be worth targeting for the authorization piece? • (Josh M.) None – am building static Java apps (nothing that requires a server side library) • (Gordon R.) Using Spring Security • (Adam G.) From IOS end, H-reader (app from HIMSS) doing a similar process to what Josh described -minimal code that forms the request by hand. • ACTION: (Community) Please provide any code samples of using OAuth 2.0 [Send to jenniferbrush@esacinc.com]