1. Automate Blue Button Initiative Pull Workgroup Meeting February 12, 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 Welcome and Announcements5 minutes Reminder: Direct Connect-a-thon on Feb 20 Pull Implementation Guidance - Discuss Summary Comments (Josh & Adrian) - Discuss Updated OAuth Workflows (Keith) 20 minutes Next Steps for ABBI Pull5 minutes 3

4. Direct Connect-A-Thon Reminder Wednesday, February 20, 2013 @ 11:00 am – 5:30 pm Eastern – POC: Greg Meyer (gmeyer@cerner.com) If you plan on participating in the message exchange and interop testing portion of the event, please fill out the information on the Wiki [1] and submit your anchor to the appropriate trust bundle on the ABBI bundle site [2]. For Java participants, a new SNAPSHOT/RC [3] has been published with release versions of all the components (include the first iteration of trust bundle support) along with updated documentation on trust bundle configuration [4]. – [1] http://wiki.directproject.org/Feb+2013+Connect-A-Thon – [2] https://secure.bluebuttontrust.org/ – [3] https://oss.sonatype.org/content/repositories/snapshots/org/nhind/d irect-project-stock/2.1-SNAPSHOT/direct-project-stock-2.1- SNAPSHOT.tar.gz – [4] http://api.nhindirect.org/java/site/gateway/2.1/users-guide/smtp- depl-wsconfig.html#Trust_Bundles

5. Pull IG Discussion and Updates Pull Implementation Guidance (IG) – Summary Comments Facilitators: Josh Mandel & Adrian Gropper (google doc) https://docs.google.com/document/d/1Z- PeZfVf-qa_8CdPx2oXXCxc9jZ0NxYcdYZv3J7LSzo/edithttps://docs.google.com/document/d/1Z- PeZfVf-qa_8CdPx2oXXCxc9jZ0NxYcdYZv3J7LSzo/edit – OAuth Workflows (Updated!) Facilitator: Keith Boone (embedded doc)

6. ABBI Pull Challenge ABBI Pull Challenge: We need dataholders to commit to being reference implementers of Pull. – Comment (Keith): Organizations are focused on meeting requirements for MU II; find it difficult to tie it to ABBI Pull, AND they need it ‘yesterday’. Makes it difficult to find organizations with the capacity to be reference implementers. – Solution: Consider additional messaging/marketing language to promote ABBI Pull as facilitating MU II (e.g. V/D/T). “5% of patients need to V/D/T their data.” – How to make Pull + Authorization ‘easy’? – Comment (Adrian): ‘Hang-out’ summary – the concerns that Keith has expressed hearing from his customers was similar to what was expressed during the meeting earlier today. They are focused on meeting increasingly difficult MU requirements and what is ONC doing to help. Recommend presenting ABBI as a way to create effective ACO’s. – Comment (Keith): ABBI Pitch from last week (as a source for language / marketing material): http://motorcycleguy.blogspot.com/2013/02/abbi-pitch.html http://motorcycleguy.blogspot.com/2013/02/abbi-pitch.html – Challenge: Recruit and identify dataholders to participate as RI in Pull  what do we tell them they need to be able to do / implement? What is the ask? (Adrian) PPR’s ask to data holders is to put the decision of V/D/T in the hands of the physician and the patient, rather than the institution and the EHR vendor. (Josh) When we talk about data holders, we are talking about vendors [too]. Consider the hook of programmatically extracting a C-CDA from their systems. (Ryan) Some vendors have APIs that they have opened up OAuth as Pull. (Pierce) Greenway announced they have a consumer API they are providing access to. (Keith) There are more vendors that support CDA than C-CDA right now. Perhaps we can ask them to focus on CDA (now) and C-CDA in the future. Provide a patient with a way to pull their current medical summary or search for the documents they have available. (Adrian) Mass gave $1M for vendors to create the APIs into the HIE; some vendors kept their interfaces proprietary instead.

7. Next Steps for ABBI Pull Next Steps – Define our ask for dataholders for ABBI Pull – Refine / update the OAuth workflows based on feedback received so far Upload the latest version of the word doc to the wiki

8. Meeting Reminders 8 – Pull WG has moved to a bi-weekly schedule. The next PULL Workgroup Meeting is Tuesday, February 26, 2013 @ 3:00 pm Eastern. 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

9. Appendix – Reference Slides from Previous Meetings

10. Pull Implementation Guide – Outline DRAFT 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 – Date ranges (Send me everything, send me info for last 3 years, send me only the latest, etc.) – Frequencies and triggers Comment: potentially confusing? Our original scope statement was on-demand (~n times) – 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?)

11. OAuth Workflows (Keith Boone) OAuth 2.0 with ABBI – Locating Endpoints – Registering Your Application – Obtaining the Authorization Token – Obtaining an Access Token – Making ABBI Requests

12. Comments / Feedback (Carlos Eberhardt 20130128) 1) Are we only allowing dynamic client registration for OAuth? The doc gave me that impression. It's not used much in the wild as far as I know and is fairly complex. I realize it is an attempt to solve the many apps/many providers problem, and for that purpose is as good as anything I've come across (although I haven't looked far and wide). But, should we also consider a non-dynamic client registration and allow developers to deal with the OAuth they are used to if they choose? This might make their apps less flexible but I believe that should be the developer's choice, not someone else's. I would start with instructions on attaining keys that way, then introduce the dynamic registration. 2) I think we should make the doc a bit friendlier. I realize it's an early draft so perhaps I'm jumping the gun on this. Getting adoption is a big goal, so making the documentation as accessible as possible should be a priority. That means no word docs, no "download and read." Here are a couple of examples of friendlier developer documentation. – http://developer.github.com/v3 – https://developers.tradeking.com/documentation/getting-started – http://developer.wordnik.com/docs (not much auth-related, but a fancy UI) I would suggest using the wiki to start the documentation rather than working in an offline doc format, just to get used to it. It's easier than trying to convert it later, in my experience.

13. Comments / Feedback (Josh Mandel - 20130122) I think most of Keith's proposal is spot-on and represents a tremendous effort in producing a concrete, readable document. So please forgive me for focusing on two points of dispute. But there are two key areas where I would push back (and see my inline comments for more detail): 1. The "registrar" component is a major source of unnecessary complexity. It's a new invention that (as far as I can tell) hasn't been used in the context of OAuth registration before. (Please correct me if I'm wrong here.) And the registrar is necessarily a trusted component that talks to multiple apps, their instances, and authorization servers. At its heart, any added security offered by registrar relies on "mechanisms not described by this specification" to verify "a legitimate instance" of an application. And I have trouble seeing how this would happen in an environment with diverse apps running on multiple platforms. My recommendation is to eliminate the registrar component from ABBI's specification, and simply have each authorization server provide dynamic client registration services per IETF's draft-ietf-oauth-dyn-reg spec. 2. I maintain that ABBI should provide first-class support for pure browser-based apps that are incapable of maintaining a secret. For such apps, security essentially comes from being hosted at pre-registered HTTPS URLs. Browser-based apps should use OAuth 2's "implicit grant" workflow to obtain tokens. For this type of app, implicit grant is not less secure than other workflows -- and to my mind (and no pun intended) it makes *explicit* the fact such apps are operating as public clients.

14. Notes (Page 1) General Discussion Note: Keith found out more about dynamic app registration and will be editing that section to reflect the new information. – Comments about app registration? – Assumes a collection of endpoints WG Admin – Suggestion to move this group to Bi-weekly? (once every two weeks) – No objections. Comment (Chris B): Would like to suggest that the group also consider Notifications (similar to comment from Push WG 1-28-2013 – will copy comment from other meeting); don’t currently have known examples. Comment (Fred): Doesn’t seem like the structured endpoints need to change; you are pushing a very small bit of content and we should have a discussion about what that content looks like, but for now it’s a small amount of data. Notification may say nothing more than a change has occurred and you might want to go pull it. Push notification would necessarily go to a server, then that server would dispatch individual push notifications to each device. Comment (Ryan): ACTION – research the equivalent somewhere. Agree that notification should be discussed and on the table. Comment (Adrian): Alternative way to look at notification (not to surprise the patient) when pull is set up and someone (provider) uses it, it would be pleasant for all of us to be notified as patients that the on-demand pull authorization has been exercised. [Similar to being told someone has changed / attempted to change your password for a given secure site? Message via email.]

15. Notes (Page 2) OAuth Endpoints Document Notes: We’ve noticed that much of the agreement from the group is around the pattern of access. E.g. OAuth, some mechanism for apps to dynamically access, etc. Area where we are seeing less consensus is actually describing what these endpoints look like. Key question is ‘who is going to build this?’ Although we always want to find a balance between standardization and innovation, one of the ways to maximize those for this effort is to avoid being proscriptive about the endpoints, let the community experiment with the guidance, and see what comes out of the community over the next few months. Push’s success is in part because of the paradigm of assembling things off the shelf in a particular way. Pull only has OAuth on the ‘shelf’, so pointing to endpoints might be difficult. Recommend focusing on the “Pattern of Access” using OAuth and delegation. Thoughts? Recommend sending out this discussion starter in an email for discussion. Comment (Adrian): re: Endpoint discovery, I did suggest early on that we link endpoint discovery to DIRECT email addresses at the endpoint. That would in effect bring in the benefits of DIRECT (which are already being worked through on the Push side). This could be used then to boot-strap the OAuth connection. Screen mock-ups were used to demonstrate how that could happen. This remains one possibility if we are willing to discuss endpoints giving themselves a DIRECT address. Response: It is difficult to prescribe a path that no one is taking yet. Perhaps we could take the endpoint description and keep them, but focus on the OAuth component which we know is going to be the popularized way of making that connection (e.g. like RHex Project). We certainly wouldn’t say using DIRECT to boot-strap is bad, but we need to wait for those innovations to happen.

16. Notes (Page 3) OAuth Endpoints Document Comment (Adrian): Agree, however, to the extent that we (ONC) would issue guidance saying that the accounting for disclosures should be part of a patient accessible screen on the portal, the rest sort of falls into place and you don’t have to specify much else, because that brings information about what endpoints will be shared, and with who. I don’t think we need very prescriptive standards beyond OAuth 2.0 and DIRECT; however, what’s missing is specificity around the consent mechanism as reflected in the accounting for disclosures – that policy guidance isn’t standard for implementation issues. This issue of specifying accounting for disclosures for patients has come up in the HIE committee meeting today and remains a problem. [Paul Tang Rule: “If you’re surprising the patient, you aren’t doing a good job”] -- At the HIE meeting today, there was discussion around the problem of consent (opt-in/opt-out) when you try to do health information exchange on a national scale. Everyone has the issue of dealing with a finite number of endpoints within their geographic location. But as soon as you talk about larger regions, like a whole country – people are stuck in terms of adjusting and arriving at common governance and common policy for how to handle it. Comment (Ryan): If there aren’t answers to question around policy for disclosure, we certainly have the ability to ask them. Comment (Adrian): If we took the accounting for disclosures and the Paul Tang rule and presented it to the appropriate committee in the right way, then all of the other pieces about defining an endpoint could fall into place. Question (Ryan): Have you thought about what the disclosure / accountability screen would look at, what are the metadata items on there that would be disclosed? Comment (Adrian): State level requirements re: not disclosing particular information (e.g. HIV), then there is patient preference – as candidates for authorization (for data segmentation). Any conversations about data segmentation must come from both perspectives.

17. Notes (Page 4) OAuth Endpoints Document Comment (Chris B): Data Segmentation is tough. Issue for example, taking HIV history. There are multiple components of the record when considering how/who to allow to look at or not look at pieces of the record. May be a Pandora’s box to open this issue. Comment (Pierce): Agree and we should keep in scope with our use cases / charter and focus on segmentation on document level and time. Individual providers can define particular pieces and how to assemble those documents. Comment (Adrian): Agree with document level data segmentation. Not only who and when can be exchanges, but what it was. Deadline is by next week’s meeting (Tues, Feb 12)

23. See “Normal” PPT view for all meeting notes (in Notes section below)