Attendees:

Debbie Bucci

Casey Quinlan

Danny van Leeuwen

Sarah Squire

Thompson Boyd

Glen Marshall

Salvatore D’Agostino

Catherine Schulten

Eve Maler

Abbie Barbir

Adrian Gropper

Mark Russell

Josh Mandel

Jeff Shultz

Justin Richer

Tom Sullivan

Elvar

William Kinsley

Obi Ogbanufe

Corey Spears

Ishmal Bartley

Edmund Jay

Jim Kragh

Don Cameron

Action Items:

Eve will rewrite the “Alice Enrolls with PCP” use case to use OAuth language exclusively and color code it to indicate core and peripheral requirements.

Eve (and Justin?) will brainstorm to see if they can come up with anything that is not captured by the planned semantic profiles.

Next week:

discuss and close what semantic profiling should consist of

discuss and close Eve’s rewrite of the use case

discuss scope structure

Notes:

We want to make progress on the OAuth Semantic Profile. We have three basic security and interoperability profiles. We have two other semantic profiles with FHIR-specific stuff. Do we need another bucket for things that don’t fit into these five profiles?

For example, is identity proofing core? The fact that some proofing has been done is core. We just need a way to express that.

What would appear in a profile? If you think about what appears in a technical specification, implementers have to go by imperative statements like “must,” “should,” “may,” or “must not.” It’s especially good when we can turn a “should” into a “must,” because then it becomes a testable assertion.

Can we take this use case and build a general list of what the profile should contain? We have three security profiles already written, so we have a good start on that. However, there are interoperability nuances may be missing from our existing profiles.

Do we need multiple semantic profiles? Do we know what they should contain? In this use case, we know that we have two OAuth-protected resources.

In trying to define interoperability, should we separate interoperability into a phase where information moves between a server and a client and a phase where there is semantic understanding of the information that is moving between the server and the client? We aren’t talking about moving human-readable documents, we’re talking about moving structured data. The reason we split out the security profiles from the semantic profiles was so that we could talk to FHIR or other APIs there are a set of things you need to do first - those are the security profiles. We don’t have the semantic profiles yet.

Is the role of the use cases to inform the FHIR API? Or is it something else? It is something else. We will be looking at how we can using the existing FHIR API (or not) to solve the issues presented in the use cases. Josh will be monitoring the working group and taking any lessons learned back to the FHIR project.

The use case documents are here to inform the HEART project, but they are not a deliverable of the HEART project. The use cases represent our health SME’s inputs, and the interface between technical and health SMEs.

If this is going to be an OAuth-only use case, we need to clarify the use case to use OAuth terms. Eve is willing to do that work. She will also add color-coding to indicate core and peripheral requirements.

What do we think the FHIR OAuth semantic profile would contain? OAuth scopes? Anything else?

OAuth scopes tied to FHIR resources.

We are identifying gaps like the audience parameter. Are we going to include them if the root spec doesn’t include that? Perhaps we should list the gaps we identify?

Format for identifier structure for attributes. If we are doing SSO, you have to negotiate the format of identifiers. With OAuth and OIDC, that negotiation is unnecessary. Extension claims may need to be specified. We don’t have a profile for extension claims in a health context.

There is another working group spinning up inside OIDF also working on profiles.

At the IETF meeting last week, the OAuth working group considered the notion of having an audience parameter, and it was met with general agreement.

Adrian does not understand the meaning of “general audience profile.” The audience parameter takes the notion of “which resource am I trying to access?”

Adrian is hoping that when there is a resource server with a policy about how it releases information that there be a way of grading, probably on a linear scale, its interoperability. He would like to see HEART servers have letter grades. Justin thinks it might be better to have a “pass” or “doesn’t pass” grading system.

What is a semantic profile?

If you look at these diagrams:

http://openid.net/wordpress-content/uploads/2015/03/Venntechnologydecisiontree.pdf

We are working with three technologies - UMA, OIDC, and OAuth. We are working with a health API called FHIR. We have three profiles - one based on each technology. We have two semantic profiles that include the FHIR API that can talk semantically about healthcare data.

Adrian is imagining levels of patient-centricity that specify how much choice we give patients around what technologies they are allowed to use. You could think of it that way, but you have to think of it in terms of ecosystems. Anyone considering which profile to deploy may not be able to choose which technology to use - they may be limited by the technology in use by the ecosystem within which they are operating.

A claim in OIDC is a piece of information that is attached to a user. FHIR attributes are attributes about a patient. However, OIDC handles login. FHIR should never handle login.

Back-channel discussion:

Casey Quinlan (to All):

From the patient perspective, we (patients) are still the last group to be "invited in," i.e. the ecosystem is set by all other players having their requirements met before a person/patient is asked "how would you like to access your data, and certify your credentials?"

Casey Quinlan (to All):

IOW, I have yet to hear anything that flips the current "system sets security" into "patient is in control of his/her data as primary actor."

Eve Maler (to All):

An OAuth-based system is not patient-centric :-) - it does, however, preserve a patient's ability to consent to flow of data a run time, though...

Eve Maler (to All):

When we get to UMA-enabled use cases, that's when a patient moves to the center

Eve Maler (to All):

The reason OAuth is relevant as a real use case is that it's widely implemented, deployed, and understood (and is part of the technical basis of OpenID Connect and UMA!)

Casey Quinlan (to All):

I'm gon' sound like a simpleton, but AFAIC patient data conversations, which to date have not included patients/end-users in active development of the infrastructure/UI/UX at all, are almost pointless if the phrase "patient centric" is in use. Ain't patient centric if patient is not primary assigner of rights to use of said data.

Eve Maler (to All):

You make a good point - however, profiling use of OAuth on its own is, in fact, in scope...

Eve Maler (to All):

it's a stepping stone

Eve added: Thanks as always for the awesome notes.

Re this item: "Eve (and Justin?) will brainstorm to see if they can come up with anything that is not captured by the planned semantic profiles." I was actually hoping Justin (and possibly Josh) might put some thought into "semantic profile" topics that go beyond OAuth scopes prior to next week's meeting and send thoughts around in email. I'm happy to contribute to such a thread, and/or to get on a 2/3-way brainstorming call if desired.