Automate Blue Button Initiative Pull Workgroup Meeting November 27, 2012

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

Announcements and Reminders 3 Meeting Reminders – Dec 6th: Virtual Connect-a-thon for DIRECT / Trust to test sending data from data holders to receivers; NIST tools will also be present – Dec 11th: ONC annual Meeting; ABBI will have a Town Hall from 2:30-4 pm, and more of a casual meeting up that evening for all ABBI folks who are interested. – Pull Workgroup Meetings are Tuesdays from 3:00 – 4:00 pm Eastern. Next meeting is Tuesday, December 4th, – The next Community Meeting will be announced.

Agenda TopicTime Allotted Welcome and Announcements5 minutes ABBI Schedule and Pull WG Status5 minutes Continue Discussion on Pull45 minutes Next Steps / Reminders5 minutes 4

Pre- Discovery Discovery Reference Implementations  Agreed and voted on charter, including  Scope  Timeline  Deliverables  Open call for straw man proposals for PULL scenarios  Review background information from other S&I groups like RHex Project  Discuss advantages and disadvantages of proposed straw men  Identify proposal(s) to invest in  Write draft implementation guide  Identify 1-2 partners that can build proof of concepts for PULL  Have 1-2 partners demonstrate the technical feasibility of the implementations Implementation Guidance Implementations  Refine use cases based on reference implementations  Refine implementation guide based on reference implementations  2-4 full implementations that reflect implementation guidance PULL Current Status Pull Workgroup1 5

Looking Forward ABBI Schedule November – October 22- November 19: Drafting and comment period on ABBI Implementation Guide (Part 1: Send via Direct + Content) – Nov 19 th : BEGIN Comment Period Round 2 on ABBI Implementation Guide (Part 1: Send via Direct, Content) – 26 th : Discuss IG Comments in workgroup calls – 28 th : END Comment Period on ABBI IG (Part 1) December – 3 rd : Review Implementation Guide Comments in Workgroup Calls and Finalize Guide – 6 th : ABBI Participates in Connect-a-thon – 10 th : “Public Release” of ABBI Implementation Guide (Part 1) – 11 th : ABBI Participates in Town ONC Annual Meeting – 21 st : BEGIN Comment Period on ABBI Implementation Guide (Part 2: Send via , Payor Content, and Developer Toolkit) January – ~ 10 th : END Comment Period on ABBI Implementation Guide (Part 2) – ~ 15 th : Release ABBI Implementation Guide (Part 2) – All of January: Testing Period; Identify and Respond to Reference Implementations February – Testing Period; Identify and Respond to Reference Implementations March – Complete Testing Period – HIMMS: Showcase ABBI Implementatiosn – Release Final Automate Blue Button v2 Implementation Guide (Part 1 and Part 2 listed above)

Authentication and Delegation Anatomy of Pull + REST Endpoint Return Objects + All Documents (Search) REST Endpoint Return Objects + Latest (Summary) REST Endpoint Return Objects + Extensible OAuth 2.0

Open Questions / Discussion Areas How is app registration handled? – Keith B: there is a draft spec (out of OpenID Connect) that allows dynamic user registration; Rhex profiled; – OAuth 2.0 dynamic client registration protocol – Scenario: how can we revoke application registration? When you want to authorize, you have to authenticate using the client credentials to the token endpoint; at that point the token endpoint can make a decision about whether or not to accept those credentials. How do you promulgate status (good, bad or otherwise) across a system? App could be responsible for it. But if the app is the rogue entity, then you do need something like a centralized registry. Other option is an ABBI provider dealing with the authorization endpoints; OAuth 2.0 has the ability to support both the resource endpoint and the authorization endpoint and those can be separate. – To Answer: Are there technical solutions to this or are they more policy?  out of time – homework/continue discussion in next meeting Next week: – Boot Strap Slides Overview (Adrian) – APIs Discussion - defined – Questions How is app registration handled? (cont’d) How do data holders restrict “abusive” apps? How do developers discover how to interact with third parties? How can we ensure/validate end-points? Awesome – thank you all!

OAuth Summary Points (from Adrian G) - OAuth is a means of securing RESTful servers based on a secret token communicated over a secure channel. OAuth security applies to a wide range of clients and servers including mobile devices but risk mitigation methods apply to various use-cases. - OAuth uses a two-level authorization mechanism to facilitate scalability. The top level is institutional and analogous to a white-list or federation mechanism. The lower level is individual and corresponds to a time and scope-limited authorization by a specific patient. - OAuth can work both as part of a specified federation and by using a dynamic discovery process without a specified federation. The dynamic process could be useful in support of universal access that does not restrict the patient's choice of pull agent while still allowing for the administrative efficiency of specified federations. - OAuth by itself distributes the authorization management to the edges of the network. This can get confusing for patients that want to manage authorizations at many data holders including labs, specialists, clinics and payers. UMA is a proposed standard protocol on top of OAuth that allows for access authorizations to be managed by a trusted central service that can be independent of any particular data holder. This trusted, independent central service would be analogous to a federated identity provider for Single Sign On and could either be the same or separate from the IDP.

Notes and Discussion on OAuth Summary (from 11/20/2012) Notes / Comments: – UMA is part of Kantara. – UMA is under consideration for replacing Kerberos in academia; there are a few pilot implementations but not commercial adoption yet. – UMA is an Access Manager, analogous to an identity provider. – UMA is an independent entity (e.g. is it domain agnostic). – One of the things that we are proposing in a link between the access manager and the identity provider. – Consider supporting OpenID / Connect in the short term, and when UMA becomes more known/utilized, include it as well (pointing out that it is privacy preserving and user friendly). – Concern: OAuth doesn’t scale because it requires institutional trust relationships with ~N million practices; implementers may prefer Connect, where they are dealing with other institutions that are as large, if not larger than they are and there would only be a few PHRs in the middle (e.g. Google, MS Health V). – OAuth benefits from having established trust relationships but it doesn’t absolutely require them. – Consumer perspective: mitigating risk is important – Developer perspective: ease of use is important

Example “Search” and “Summary” Endpoints (from Keith B.) Click to open

Pull Summary Points (from Josh Mandel) Double-Click to access /open PDF

Next Steps / Meeting Reminders 13 Next Steps – Dec 6 th : Virtual Connect-a-thon for DIRECT / Trust to test sending data from data holders to receivers; NIST tools will also be present – Dec 11 th : ONC annual Meeting; ABBI will have a Town Hall from 2:30-4 pm, and more of a casual meeting up that evening for all ABBI folks who are interested. Meeting Reminders – Next PULL Workgroup Meeting is Tuesday, December 4, 3:00 pm Eastern. – The next Community Meeting will be announced. – For questions, please contact your support leads – Initiative Coordinator: Pierce Graham-Jones (pierce.graham- – Presidential Innovation Fellow: Ryan Panchadsaram – Project Manager: Jennifer Brush – S&I Admin: Apurva Dharia