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

2. Meeting Etiquette 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 o Hold = Elevator Music = frustrated speakers and participants This meeting is being recorded o 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. o Send comments to All Panelists so they can be addressed publically in the chat, or discussed in the meeting (as appropriate). From S&I Framework to Participants: Hi everyone: remember to keep your phone on mute All Panelists 2

3. Agenda TopicTime Allotted Announcements, Meetings & Event Reminders Direct Connect-a-thon (May 9) Health Datapallooza IV (June 2) 5 minutes Dynamic Registration Overview (Josh Mandel) 30 minutes April 23: “Bring a Friend to the Pull WG” Next Steps5 minutes 3

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)GMEYER@cerner.com Register – http://wiki.directproject.org/May+2013+Connect-A-Thon 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 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/http://healthdatapalooza.org/ Register here: http://healthdatapalooza.eventbrite.com/http://healthdatapalooza.eventbrite.com/

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

7. Pull Best Practices Guide DRAFT 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?)

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

9. Meeting Reminders 9 – 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 http://wiki.siframework.org/Automate+Blue+Button+Initiative Contact Information – Initiative Coordinator: Pierce Graham-Jones (pierce.graham- jones@hhs.gov)pierce.graham- jones@hhs.gov – Presidential Innovation Fellow: Ryan Panchadsaram (ryan.panchadsaram@hhs.gov)ryan.panchadsaram@hhs.gov – Project Manager: Jennifer Brush (jennifer.brush@esacinc.com)jennifer.brush@esacinc.com – S&I Admin: Apurva Dharia (apurva.dharia@esacinc.com)apurva.dharia@esacinc.com

10. Appendix – Reference Slides from Previous Meetings

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

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

13. 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)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.http://smartplatforms.org/2013/03/bluebutton-tech-and-policy/

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

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

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

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

18. Pull Best Practices Guide DRAFT 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?)

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

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

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

22. 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 HIMSS Summary and Recap

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

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

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

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

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

28. 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] jenniferbrush@esacinc.com