Automate Blue Button Initiative Pull Workgroup Meeting

1. Automate Blue Button InitiativePull Workgroup Meeting November 20, 2012

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. Announcements and Reminders • Meeting Reminders • Pull Workgroup Meetings are Tuesdays from 3:00 – 4:00 pm Eastern. • The next Community Meeting will be announced. 3

4. Agenda

5. Looking ForwardABBI Schedule • November • October 22- November 19: Drafting and comment period on ABBI Implementation Guide (Part 1: Send via Direct + Content) • Nov 19th : BEGIN Comment Period Round 2 on ABBI Implementation Guide (Part 1: Send via Direct, Content) • 26th : Discuss Comments in workgroup calls • 28th : END Comment Period on ABBI IG (Part 1) • December • 3rd : Review Implementation Guide Comments in Workgroup Calls and Finalize Guide • 6th :ABBI Participates in Connect-a-thon • 10th :“Public Release” of ABBI Implementation Guide (Part 1) • 11th : ABBI Participates in Town Hall @ ONC Annual Meeting • 21st : BEGIN Comment Period on ABBI Implementation Guide (Part 2: Send via Email, Payor Content, and Developer Toolkit) • January • ~ 10th: END Comment Period on ABBI Implementation Guide (Part 2) • ~ 15th : 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)

6. Pull Workgroup1 • PULL Current Status Pre-Discovery • Agreed and voted oncharter, including • Scope • Timeline • Deliverables Discovery • 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 Reference Implementations • 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 • Refine use cases based on reference implementations • Refine implementation guide based on reference implementations Implementations • 2-4 full implementations that reflect implementation guidance 6

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

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

9. Anatomy of Pull Authentication and Delegation REST Endpoint Return Objects + +

10. Anatomy of Pull Authentication and Delegation REST Endpoint Return Objects + + OAuth

11. Anatomy of Pull Authentication and Delegation REST Endpoint Return Objects + + Will the same REST endpoints and return objects be used across the industry?

12. Anatomy of Pull Authentication and Delegation All Documents Summary Others REST Endpoint REST Endpoint REST Endpoint Return Objects Return Objects Return Objects + + + +

13. Outstanding Issues / Questions • Question: OAuth 1.0, and there is OAuth 2.0. We didn’t have a discussion about which to use and that will be pertinent later. • Slides from Adrian • Managing multiple applications • Strawman for Search • Strawman for Summary • RE: Other • Concern: payers learned from HIPPA if you have an ‘other’, there is an assumption that both parties have to also be able to do the ‘other’ (because it is linked to this project, e.g. Blue Button)

14. Oauth 1.0 vs. Oauth 2.0 • Question: OAuth 1.0 vs OAuth 2.0. • RHex is using 2.0 – is that the path we should take? • Comment (Keith B): # of challenges with 2.0. Original creator is no longer participating, in part because 2.0 creates a framework, not an interoperable mechanism. RHex specified a number of those details, although they did not solve all the issues (namely the 1,000,000 issue). How credentials pass two applications was out of scope. • Comment (Josh M.): RHex is using a set of profiles on top of 2.0, called Open ID Connect. Used to provide access to protected resources as well as resource holder (e.g. BB provider, identity provider). Use the specifications facing in 2 directions 1) authentication and 2) identity management. There are many, complex specifications involved. • Comment (Adrian): RHex recommended a potential solution to the 1M problem, when they reference the use of Kantara UMA (User Managed Access) as an extension to their work. When we make this decision, we should be sure to retain compatibility with UMA going forward, as it is an important component of scalability and patient engagement. 2. the slides that I provided may help inform this decision. If we can agree on the user interaction, we can make a good decision on whether 1.0 or 2.0 meet our requirements. • Comment (Debbie B.): OAuth is the Authorization, the credential is a layer of scope that was written for Open ID / Connect. Don’t forget that these are two separate things. • Comment (Keith B.) UMA does have a mechanism that solves the 1M registration issue, that comes out of the Open ID Connect work. IATF draft of UMA that addresses this issue. The challenge for providers is the assumption that providers want to be identity providers. Based on discussions with some of these folks, they perceive this as costly and don’t want to invest in becoming one themselves; would prefer to rely on 3rd party identity providers. (Adrian) Doesn’t prevent them from doing this, if they want to. Health Information Exchange could choose to do the UMA piece without taking on the identity provider role. • Comment (Josh M.): BB provider needs to authenticate users, at some level. The mechanism doesn’t matter. As long as each of them provides a way for the user to log in and give them access to apps. The API needs to be consistent. • Clarification (Ryan): Is there any reason not to be using 2.0? • Response (Keith B.): I think we need to investigate. People are behind 2.0 (to some degree) but there may be questions about how easy it is to implement. 1.0 is fairly easy to implement. • (Ryan): Is there any concern about just using 1.0 and not 2.0? Is focus on 1.0 more manageable for the community? • (Adrian): The reason 2.0 was invented was to make the client side implementation easier; e.g. asymmetrical. We do want the implementation to be as easy as possible for the services that are pulling information from the data holders. • (Josh M): 2.0 does make it easier clients; but can make it harder to write servers. Again, it is a framework for writing these protocols. Social network applications have started to coalesce around simple solutions. However, looking at security from 2.0 may offer a bit less depth than 1.0. RHex prototyped something a bit more complicated than that. • Comment (Debbie B.): Facebook 2.0 does use OAuth 2.0. So the industry, in some form, is supporting 2.0 • Comment (Keith B): 1.0 issue is that there is no solution the 1M registration problem; it is likely that we solidify around 2.0 but our solution may not be as complex as what RHex implemented.

15. 1M Registration problem • Also: Example of industry that also has this problem. • Challenge: create an environment where there are 1000s of providers who are able to enable people to use applications via OAuth; and 1000’s of applications who can access those providers. • In order for an app to access, it typically has to provide a credential to a resource holder (e.g. this is the application that I am, and here is my patient authorization). • MU II perspective: Patients need to be able to see logs of who a provider has send their information to (e.g. 3rd party application, cloud, etc. – but distinctly identify those apps/platforms/ “where”) • Credentials must be exchanged in order to accomplish this. Data holder must give a token/key to the application developer. • Example: Gmail, Yahoo – all of the email service providers have to provide you with the user name and password used to access the account. Mechanism is “the web”. • There are general features of how to solve this problem, and those are described in part in UMA. • Application name, email, website, picture, description • In exchange, you get back a credential • Every application has a different credential/token for each data holder it accesses; very important; • Comment: there is something called dynamic client registration, part of OAuth 2.0 and there is a link between this and the consent for authorization that the Pt uses to authorize the pull. It should be possible to have the patient authorize the destination; to the extent that we use the 2.0 dynamic client registration mechanism to do that, then we can solve this problem. • Is there another example of another industry facing this same problem, who is approaching it using UMA-like solution? • 1 – fan out from the center of gravity to the app (e.g. same app to same app) • 2 – wanting to connect to 1000 different providers (e.g. MINT.com web interface or app on your phone; “password scraping”, endpoints, login on your behalf) • Issue: there is no central, “if this app is doing malicious behavior, how do you block it” • Dynamic client registration solves this issue; requires you to supply information about the application itself (name, address, contact, etc. – e.g. registration information); challenge is someone registering millions of apps and the resulting vulnerability. • Q: At what level does a data holder want to enforce a white list? If we look at what it takes to establish a pull link (regardless of the white list) it will help us frame the question of what the appropriate level is. I’m not convinced that the data holder is exposed to any particular risk if we do our job right. • Not ever BB provider needs to offer this as the path forward for every patient who wants to add an app. Not sure we have to specify all of the details up front; just need to basics in place. 2.0 recognized that some apps are public and cannot keep a secret, and some are secure and can. • 2 use cases: patient identity; application registration – identifying the requirements around each of these (required and optional) • Homework! :D – Adrian, Josh, Keith (& others): draft short summary / strawman (few sentences) that addresses this discussion.

16. Strawman for Search & Strawman for Summary There are two paths that we described last week. Do these two still work? Yes :D Comment (Josh M.): For summary documents, have a good sense where summary encounter docs come from (e.g. MU II), but when it comes to whole patient summary to date, it is unclear that this will exist (or where it will come from?). Ryan: This is why search should be pretty easy (up front); while the summary is not required in MU II, both are still important, based on the conversations that have happened over the past few weeks in the WGs. Issue is likely one of priority and not difficult to put together. Humetrix: it is a really big deal to have an overall health summary; can have an encounter summary and that is very important and relatively straight-forward. However, when patient has other additional conditions, there are purposes and great utility to an overall health summary.

17. “Other” Category • RE: Other • Concern: payers learned from HIPPA if you have an ‘other’, there is an assumption that both parties have to also be able to do the ‘other’ (because it is linked to this project, e.g. Blue Button) • Endpoints should not be limiting or restricting. Right now our BB endpoints are search and summary; however, anything that allows the vendor/developer to be creative is good and not intended to brand as BB. • Concern: whenever ONC / HHS does (says) something, they frequently forget that a ‘nice to have’, becomes interpreted as ‘we must do’. • The link to BB is unavoidable, but can be managed by explicitly identifying requirements in the specifications (e.g. MUST, SHALL, SHOULD vs. ‘not required’ language). • Adrian: For stakeholders concerned about privacy, we would insist that patients not be coerced into sharing information that they themselves cannot have access to. Mechanisms for ABBI should be as broad as possible. Can envision an situation where some policies are written ‘I will not opt into the exchange unless I can also have “cc:Patient” or I can have ABBI access to that same information, regardless of whether or not I use that information’. Enables a disclosure policy that is not coercive. • “Other”: while we are spending all of our effort on Search and Summary, there is the opportunity for innovation to happen outside of this effort; e.g. another endpoint that is meaningful and useful to the community.

18. Next Steps / Meeting Reminders • Next Steps • Homework: Strawman for Summary; Strawman for Search • Homework: Strawman for OAuth for next week’s discussion • Dec 6th: Virtual Connectathon 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-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, November 27, 2012 @ 3:00 pm Eastern. • The next Community Meeting will be announced. • http://wiki.siframework.org/Automate+Blue+Button+Initiative • For questions, please contact your support leads • 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)