Did you know that it's possible to join through the TurboBridge website for free????? Thanks to James for discovering this!
Quorum was reached.
Approve minutes of UMA telecon 2016-06-02: APPROVED.
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.
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.
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?
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.
As of 12 Jun 2016, quorum is 7 of 13. (François, Domenico, Kathleen, Sal, Nagesh, Thomas, Andi, Robert, Agus, Maciej, Eve, Mike, Sarah)
Non-voting participants:
Regrets: