Minutes

Interim meeting

We will hold an interim meeting on Apr 2 to discuss the proposed extension(s) in more depth. Eve will put it on the calendar.

Roll call

Quorum was reached.

Approve minutes

• • Approve minutes of UMA telecon 2020-03-12

Minutes APPROVED by acclamation.

AdvCIS liaison report

Report from Mark/Tim on Notice & Consent project and next steps.

Sal is the secretary of the group.

The idea is to take the Consent Receipt work (the early technical working group), and move it forward. There is representation from COEL, DIACC, now UMA, other Kantara work groups, MyData operator groups, and more. There has been outreach to Nat Sakimura regarding relevant ISO specs. The idea is to synchronize it to address interoperability so that consent receipts can be used in the same way. It's a project group of the new ISI Work Group. The old CIS Work Group has been archived. People can see the project and group structure in the table of contents off to the left of the linked project page.

This first meeting mostly consisted of introductions and basics. The idea is to cycle between each spec/use case, and examine spec sections and ensure they sync up. The goal is to publish in the July timeframe. There is some history provided about the initial Consent Receipt spec, since GDPR was published, on the main Notice & Consent page.

A tricky part is the IPR, since the work straddles work groups.

Eve points to the GA4GH Passports work as being relevant; perhaps Carlos Garcia, as an UMAnitarian working on this project, could be a liaison from this perspective.

Our work on the "devices and artifacts" around legal relationships could drive how we attach such "machine-readable licenses" as information-sharing agreements.

The IEEE research that Lisa and Eve did (webinar version here, paper version here) proposed why consent per se – and consent to contract, as in terms of service agreements – is problematic (disempowering) legally and experientially. That's where right-to-use licensing comes in, and these information sharing agreement efforts could solve the interop half of the problem.

IDENTOS Resource Definitions/AS-first flows

See Alec's email and our discussion in the last meeting.

How it works:

This all works because RS's, and clients, and AS's, have figured out ahead of time what RS's and clients are capable of doing and handling, respectively. There is a trust framework that applies. Think of an immunization record. It can live in a whole bunch of places.

The numbers below are from Alec's email.

No. 1. FHIR isn't enough in a lot of ways. It's necessary to tag the scopes to say what the different clients can have access to, for example. And the resources need to be tagged to describe what they mean. What didn't exist that needed to be created? If there are three different FHIR repositories and you have to stand up a FHIR app, there's a lot of data you have to set up. "In Ontario, we're using these codes, and we're using SNOMED..." etc. It's metadata that maps FHIR to the local profiles that are specific to that community.

Nancy notes that there are a lot of profiles of FHIR. She's involved in a lot of work to harmonize FHIR profiles. For example, there are profiles within the Claims area. It sounds like Alec has done similar work in Canada. Yes: Four different provinces have harmonized their profiles.

Why does the AS define these general "resource definitions" vs. RS's? Because the AS is capable of handling these multiple profiles and so it needs to be the one to harmonize across them.

Nancy asks: Most data sources don't contain adequate sensitivity data tagging, so: Does this include sensitivity support? The FHIR server along can't support this, so having a gateway in front of it that understands specific scopes and can edit the data would help.

There is sort of a "well-known" description of metadata. It could be standardized in some fashion.

No. 2a. Any client that can handle whatever subset of these resource definitions and their scopes can be registered for it statically. In their usage of this mechanism it's static, but it doesn't preclude dynamic client registration.

No. 2b. When clients are registered, it's at this time that they receive "capability tickets". This could be static or dynamic. But since the clients can only do very specific things, the tickets are specific too.

No. 3. How would, say, a new FHIR version ripple through a deployment like this? RS's could be versioned and clients that only understand certain versions could interface only with the versions they understand. 

How interdependent is Resource Definitions extension with the other extension? They are relatively separable. See the flow provided; step 8 is where Alec addresses this a bit. He'll try and provide a sequence diagram.

Eve will set up an interim call on Apr 2 to continue diving into the details of this.

Interop

Deferred.

Attendees

As of 17 Feb 2020, quorum is 5 of 8. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike)

1. Domenico
2. Sal
3. Andi
4. Maciej
5. Eve
6. Mike

Non-voting participants:

• Tim
• Anik
• Alec
• Nancy