Automate Blue Button Initiative
Pull Workgroup Meeting
March 26, 2013
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
From S&I Framework to Participants:
appropriate).
Hi everyone: remember to keep your phone
on mute 
All Panelists
2
Agenda
Topic
Time Allotted
Announcements, Meetings & Event Reminders
C-CDA Scorecard Presentation (April 2)
Direct Connect-a-thon (May 9)
Health Datapallooza IV (June 2)
10 minutes
OAuth Workflows Status (from Keith B)
http://wiki.siframework.org/ABBI+OAuth+Workflows
10 minutes
Discussion
Dynamic Registration
ABBI Pull Guidance (Process & Timeline)
34 minutes
OAuth Code Samples on Wiki
http://wiki.siframework.org/ABBI+Pull+Code+Samples
1 minute
ABBI Pull Best Practice Guide (for OAuth & Pull)
Next Steps
5 minutes
3
C-CDA Scorecard Presentation – April 2, 2013
• Tuesday, April 2, 2013 @ 12:00 Noon Eastern
• “Getting SMART about C-CDA: Faster Meaningful Use with
Clinical Benefits”
• Description: Presentation on generating high-quality C-CDAs
put on by SMART Platforms / Harvard Medical School.
• Register here:
– http://www.eventbrite.com/event/5835539255/mcivte?utm_source=ABBI
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)
• Register
– http://wiki.directproject.org/May+2013+Connect-A-Thon
• 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
– Panel spots are also open (dataholders & developers)
• Registration ends May 24.
– $750 Standard
– $495 Govt/Academic/Non-profit
• More information here: http://healthdatapalooza.org/
• Register here: http://healthdatapalooza.eventbrite.com/
OAuth Workflows are on Wiki
(Keith Boone)
• http://wiki.siframework.org/ABBI+OAuth+Workflows
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-couldhave.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.
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.
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).
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.
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 (?)
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?)
Homework Review: OAuth2 Code Samples
• OAuth2 Code Samples / Help on Wiki
– http://wiki.siframework.org/ABBI+Pull+Code+Samples
– (Thank you Adam G., Josh M. and Carlos E.!)
Next Steps / Actions
• 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.
• ACTION: Contact POCs from HIMSS after work group has stable API
document (mid-April)
• ACTION: (All) Send OAuth code samples to Jenny to share with the team
(jennifer.brush@esacinc.com) [DONE]
• ACTION: Update ABBI API Documentation (Keith) [DONE]
• Josh’s idea re: simplifying access for Push (done) [DONE]
• Adrian (March 12): Patient directed exchange vs. Patient mediated
exchange [DONE]
• Meet up during Interoperability Showcase @ HIMSS face-to-face (March
3). [DONE]
Meeting Reminders
• Meeting Reminders
– Next PULL Workgroup Meeting is Tuesday, April 9, 2013 @ 3:00 pm Eastern.
• Agenda: Josh Mandel & Keith Boone, cohesive dynamic registration protocol proposal
–
–
–
–
Tuesday, April 23 is “Bring a Friend to Pull WG Day
Event: Consolidated CDA telecon/presentation on April 2, 2013 @ 12:00 Eastern
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
• Contact Information
– 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)
16
Appendix – Reference Slides from Previous Meetings
• Appendix – Reference Slides from Previous
Meetings
March 12 Meeting Slides
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
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
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
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.
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.
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)
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.
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
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]
Feb 28 Slides
Pull IG Discussion and Updates
• Pull Implementation Guidance (IG)
– Summary Comments
• Facilitators: Josh Mandel & Adrian Gropper
• (google doc) https://docs.google.com/document/d/1ZPeZfVf-qa_8CdPx2oXXCxc9jZ0NxYcdYZv3J7LSzo/edit
– OAuth Workflows (Updated!)
• Facilitator: Keith Boone
• (embedded doc)
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
– 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.
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?)
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
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.
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.
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.]
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.
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.
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)
See “Normal” PPT view for all
meeting notes (in Notes
section below)
See “Normal” PPT view
for all meeting notes (in
Notes section below)
• Slides from 2-28-2013 follow
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
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