1. Automate Blue Button Initiative Pull Workgroup Meeting
March 12, 2013
DRAFT: Not for distribution

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
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).
From S&I Framework to Participants:
Hi everyone: remember to keep your phone on mute 
All Panelists 2

3. Agenda Topic Time Allotted Welcome and Announcements 5 minutes
HIMSS Summary and Recap
Review Summary Endpoint & Search Endpoint
10 minutes
Patient directed exchange vs. Patient mediated exchange
(Adrian G.)
20 minutes
Next Steps for ABBI Pull
DRAFT: Not for distribution

4. 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
DRAFT: Not for distribution

5. Next Steps / Agendas for ABBI Pull
Feb Meeting
(Keith) Endpoint API Pieces [ ]
BlueButton+ for Pull Summary Discussion [ ]
Josh – quick review of demo from Push [ ]
March Meeting
Review Endpoint API Pieces from 2-28
(Adrian) – Patient directed exchange vs. Patient mediated exchange
(Keith) Comments on OAuth Documentation

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

7. Summary Endpoint Discussion
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.

8. Search Endpoint Discussion
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.

9. 2 – Be associated with a Direct email address (regardless of issuerer)
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 address (regardless of issuerer)
Tying this to ABBI: For Push and Pull, we need to replace the paper form that captures the user’s signature with something that looks like an online form (in the case of ABBI Push) and something that resolves to OAuth in the case of ABBI Pull. Discussions with HIMSS about the MITRE work. Their work was designed to create an electronic equivalent of paper consent forms (signed before tx, signed release of information (ROI) forms) on a web server; and allow consent to be managed as a matter of policy from a central location (instead of point-to-point). Because ABBI Push and Pull both require consent, propose taking into consideration the work that has already been done by MITRE in this space (and they potentially have resources) and their interest, create  Patient Directed Exchange as a part of ABBI. Goal would be a mechanism for managing patient consent that both the HIE and data holders could sign on to. No specific architecture has been identified.
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.
DRAFT: Not for distribution

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

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

12. Next Steps / Actions
ACTION: (All) Send OAuth code samples to Jenny to share with the team
ACTION: Update Summary Document on Search / Summary Endpoint (Keith)
ACTION: Contact POCs from HIMSS after work group has stable API document (e.g. mid-April)
Josh’s idea re: simplifying access for Push
Adrian – on agenda for next time (March 12): Patient directed exchange vs. Patient mediated exchange
Meet up during Interoperability HIMSS face-to-face.
Next meeting is March 26

13. Meeting Reminders Meeting Reminders Useful Links
The next PULL Workgroup Meeting is Tuesday, March 26, 3:00 pm Eastern.
Event: Consolidated CDA telecon/presentation on April 12:00 Eastern
Useful Links
Contact Information
Initiative Coordinator: Pierce Graham-Jones
Presidential Innovation Fellow: Ryan Panchadsaram
Project Manager: Jennifer Brush
S&I Admin: Apurva Dharia

14. Appendix – Reference Slides from Previous Meetings

15. Pull IG Discussion and Updates
Pull Implementation Guidance (IG)
Summary Comments
Facilitators: Josh Mandel & Adrian Gropper
(google doc)
OAuth Workflows (Updated!)
Facilitator: Keith Boone
(embedded doc)

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

17. 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?)
Comment: When you start out from step 0 and you approach the data holder, you are implicitly identifying the patient based on whoever logs into the data holder; we want to be careful that in the case of data holders that have surrogates / family members / agents etc. that we do not cross-connect records by using this implicit contract creation; in Adrian’s example, the patient is identified explicitly relevant to the
DRAFT: Not for distribution

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

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

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

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

22. 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 for discussion.
Comment (Adrian): re: Endpoint discovery, I did suggest early on that we link endpoint discovery to DIRECT 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.

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

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

25. DRAFT: Not for distribution

26. 1st Essential: Data holder (e. g
1st Essential: Data holder (e.g. the VA) the user has to be able to authenticate themselves.
DRAFT: Not for distribution

27. 2nd: patient clicks blue button
DRAFT: Not for distribution

28. Updated with 2 new elements
Updated with 2 new elements. (2) you have to pick who is going to do the Pull (e.g. who is the destination) can happen 1 of two ways. Pick from a list, or enter a destination URI. Note that this is an address of an institution -- an this wold be a Direct message to an administrator / gateway or institution.
3rd essential: at that institution, how do they know you? what identifier is associated with the patient at that institution?
DRAFT: Not for distribution

29. 4th element: Hacked up an existing screen that is used to segment / determine what information will be in scope for the transmission (or in scope for the OAuth / Pull protocol); this includes durations and what sections can be chosen.
DRAFT: Not for distribution

30. See “Normal” PPT view for all meeting notes (in Notes section below)
This is a new screen to explain what's happening behind the scenes from the source (or data holder site). 1. contact destination 2. provide the ID (previous screen) 3. negotiation between the destination/source that may include content. Data holder contacting the App organization somehow.
What is this step and why is it needed? how would it be implemented?
A: One way is in the traditional OAuth where this is already the return leg of the original transaction. Original transaction is not highlighted as essential. You need to be able to contact the destination before you can complete the transaction.
You could use 'already running Direct' it would be easy to convey a message through the same mechanism -- benefiting from the infrastructure / policy already there from Direct.
Comment: this is a little extra that may not be needed; already have an app that has gone to an OAuth endpoint at the dataholder site to request permission; given that permission executes appropriately. Why is there a need in the standard for another, separate message exchange?
Response: May be right. This is not considered essential. It may be implied or not, and is in here as explanatory. Could be subsumed by Oauth
Q: Data transmitted over direct too?
Response: Everything is happening with OAuth. Whatever requests being made for data are accompanied by OAuth 2.0 tokens.
Q: Joe: FB, Google use TLS-mediated endpoints for the data flow. (?...)
A: just means that the data is sent encrypted with SSL / https
Q: Can we transmit this the same way?
A: Yes - OAuth works using TLS/SSL.
How do we get the data from the site to the mobile application? ? Url?
Data is - for example, imaging data where you have to be able to stream. The data is provided by the dataholder as a restful endpoint, protected with an OAuth 2.0 token.
Q: So if i had a mobile app, how do I get the URI and the token?
A: That's part of the OAuth requirements.
A: One critical issue - which flow you are using in OAuth 2.0. If you are using client-side flow, a mobile app could do it. But that is not recommended for mobile -- that is server-side flow and requires a server side app to actually keep the token for a period of time.
comment: what you are saying is a matter of degree, which is why the OA 2.0 threat analysis is important because it addresses these flow by flow.
If the data is large (like an image) the ability to proxy that through a server introduces a huge amount of latency and load; so we want to be careful not to preclude direct connections between the app / browser in the smartphone and the data holder, because it may not work for imaging.
The predominant use case for pull is to get this down to an app to process so that the user can access it.
Why do a regular pull, if you don't have an app that is there and ready to process the pull on behalf of the user.
DRAFT: Not for distribution

31. Download Results: Document format options are presented to the patient; here are the choices of documents that can be offered; this is not an essential -- could be behind the scenes, but it is very similar to what is already happening.
DRAFT: Not for distribution

32. 5th essential element (and last): once you set up a persistent on demand connection, you have to be able to monitor that connection and at some point disable it. this is an example of what it might look like on the Health-eVet site. Important part is that there is a cancel button - a way to disconnect.
DRAFT: Not for distribution

33. See “Normal” PPT view for all meeting notes (in Notes section below)
5 Essentials: Patient authentication at Source Server; Patient specification of Destination Server; Patient ID acceptable to the Destination; Patient authorization of the scope of the link; Ability to audit and CANCEL the link.
Starting point is slightly different from the Pull scenario. In order to enable that capability (3rd party), we would add steps earlier to the process.
If following OAuth, authentication is done at the source server (e.g. Facebook is done on the Facebook server). In OAuth, the first essential doesn't really change.
The Source Server controls the options for access. The requesting app may propose what they want, but it is still the source that controls the access.
Fred M: Slightly difficult for a mobile app to consume a URI. How is the mobile app supposed to receive it? Re: getting the actual record // app may have difficulty reading the record itself, or accessing a regular website.
Gordy: agree and may be technically difficult; however, you still could. Once you get to the data holders site.
Carlos: I think we'd need to detail the solution for a native mobile application for this to be successful. The broad base of developers is not familiar with direct.
Note: in conversations with data holders, they will not implement this without some sort of Trust Bundle; this may be even higher in Pull than Push
Response: be cautious about limiting patient's ability to choose their own destinations
Becky Davis: Wouldn't the ability to cancel the data pulls need to be resident in the third party apps, not the data source?
Carlos Eberhardt: My concern with mobile is about developer adoption. The "customer" for an API is the developer community.
Becky Davis: I would also see the contact request confirmations also coming from the third party apps.
Carlos Eberhardt: This is all about getting the token.. it's a registration process, not the data delivery process.
destination (not the source).
DRAFT: Not for distribution

34. Slides from follow

35. Blue Button + Pull Summary
OAuth 2
Dynamic Discovery
Separate patient alert best practice depending on whether their chosen BB+ endpoint is associated with a Direct Trust Bundle or not. This too applies to both Push and Pull
Other issues: such as Notification and enhancements based on RHEx-style OpenID Connect can be moved to a future release

36. Discussion (Misc) (from 2-28-2013)
Functionality
List of Authorized Data Users
Disclosures
“Portal should have this functionality, within these parameters”
Document it sufficiently to get a Stage I Implementation Guideance.
Endpoints for each? (list of auth data users and disclosures, above)
Q: Are these a Special / administrative scope?
Comment: When a patient logs into their BB+ enabled portal at a dataholder, they should see a unified list of authorized data users and disclosures that don’t differentiate b/w push & pull (no reason to split the list)  functionality of the portal, as opposed to admin API
UMA may address the ‘list’ part; disclosures is not that far behind