UMA telecon 2016-06-23

Date and Time

Thu Jun 23, 9-10am PT
- Voice: Skype: +99051000000481 or US +1-805-309-2350 (international lines, web calling interface), code 178-2540#
- Screen sharing: http://join.me/findthomas - NOTE: IGNORE the join.me dial-in line shown here
- UMA calendar: http://kantara.atlassian.net/wiki/display/uma/Calendar

Agenda

Roll call
Approve minutes of UMA telecon 2016-06-02
New item: Discuss planned changes to Implementations page
New item: Leadership team elections are overdue
MPD
- Entertain any concrete spec proposals for already agreed-on changes for discovery document and phase 1
- Compare-and-contract exercise for MPD sequence diagram and existing detailed sequence diagram (the latter doesn't call out specific AS endpoints, but could be made to)
- Any further discussion/concrete proposals on client awareness of scopes?
- Any further discussion/concrete proposals on registering multiple resource sets?
AOB

Minutes

Logistics

Did you know that it's possible to join through the TurboBridge website for free????? Thanks to James for discovering this!

Roll call

Quorum was reached.

Approve minutes

Approve minutes of UMA telecon 2016-06-02: APPROVED.

Implementation page and UMA Dev

We discussed the plan of action decided by UMA Dev yesterday. To clarify, we won't question or test their info, just provide it as-is, and we can make that clear.

Leadership team elections

A candidate motion:

MOTION: Moved by Sarah: Approve Eve as Chair, Maciej as Vice-Chair, Domenico as User Experience Editor, and Maciej as UMA Dev WG Liaison for the next year: APPROVED by unanimous consent.

AI: Eve: Sort out editor role elections and update the Leadership Team page.

AI: Eve: Sort out corresponding UMA Dev elections.

Registering multiple resource sets

George's proposal was to use the existing REST path we have and use an array/not-array cue for whether we are registering multiple resource sets or a single resource set. According to his research, this seems to be a somewhat common pattern for indicating that the AS is about to get just one thing. Our previous work on the permission registration extension, while not reflected in our latest draft in the email archives, was going in the direction of assuming that it's more consistent to have the RS always use an array; the only problem at the time was that this was backwards-incompatible.

On what basis should we be making a decision?

Our requirements and design principles say that the AS should bear more complexity than the RS or client; the RS shouldn't have to help the AS with this.
If the RS is registering one thing vs. multiple things most of the time, it shouldn't have to wrap it in an array. (What are the use cases that drive the percentage of the time? Nagesh prefers the certainty of knowing it's going to be an array vs. picking.)
In an extension we have to care about backwards compatibility, but in a new version where we're already doing other backwards-incompatible things, we don't have to care.

Is it really necessary for the RS to explicitly register all of the many resources to give the AS visibility into the structure of an API? Adrian has a vision of informing the AS that the FHIR semantics are in play, and it could know that the relevant sub-resource sets are being protected once the top-level EHR or whatever is registered. FHIR was actually a key motivation for multiple resource set registration in Eve's case. Given that the AS is currently "stupid" with respect to resource set dividing lines, and the RS is authoritative for them, it's important (to her mind) to be sure the RS is actually capable of exploiting the entirety of the currently-flat namespace for resource sets, including experimenting with the possibility of extending resource set description documents.

Kathleen notes that there is work on a FHIR Consent structure, and an RDF-OWL FHIR mapping. These could enhance a registered resource set, e.g. by being included with the description document, so that the relevant policies are bound to labeled resources. A use case for using this would be that if you have to do a notification for Accounting of Disclosures, and it has to go to the patient's endpoint, it could be connected to the correct consent downstream.

We'll see if we can lock down consensus next time; our current leaning seems to be an "all-array" approach.

AI: George: Look at and critique the current permission registration extension text as a candidate for new spec text, from the perspective our current leaning.

Attendees

As of 12 Jun 2016, quorum is 7 of 13. (François, Domenico, Kathleen, Sal, Nagesh, Thomas, Andi, Robert, Agus, Maciej, Eve, Mike, Sarah)

Domenico
Kathleen
Sal
Nagesh
Maciej
Eve
Mike
Sarah

Non-voting participants:

Adrian
Scott S
Scott F
James
George
John W

Regrets:

Justin

Browser not supported