[Openid-specs-heart] Draft HEART Meeting Notes 2016-10-31

Sarah Squire sarah at engageidentity.com
Tue Nov 1 04:51:31 UTC 2016


Attendees:

Debbie Bucci

Adrian Gropper

Cait Ryan

Eve Maler

Edmund Jay

Glen Marshall

Jin Wen

Julie Maas

Justin Richer

Kathleen Connor

Ken Salyards

Nancy Lush

Sarah Squire

Scott Shorter

Eve:

I’d like to map FHIR semantics to the capabilities that UMA has for
resource sets and scopes. For example, there are FHIR resource types, but
in UMA currently you’re registering instances of resource sets that belong
to a resource owner. FHIR resource types have structures, and Alice might
have many resource sets of a particular structure.

Right now we’re looking at only read and write capabilities. We are looking
at maybe adding delete or stripping identifying details. If you had a
camera, it might have a “move left” or “move right” capabilities.

Glen:

Also the API is stateless, so it might have a query of “where are you?” and
then a “move” command.

Nancy:

These are good ideas, but maybe we should do FHIR first and come back to
this later?

Eve:

These examples came from a company I’m working with and what they want.

Adrian:

We could take something that’s well-understood as a use case and map FHIR
and UMA scopes to it.

Eve:

We don’t have to do scope design right now. We do have to do API structure.
We have read and write, but we might need more.

What I proposed in email is that in SMART on FHIR, there’s a conflation of
resources and scopes. That’s because OAuth is less friendly than UMA is in
separating resources and scopes. What I’m proposing is that when the
resource server registers on Alice’s behalf an instance of a resource set
and that resource set will have various scopes that are applicable to it,
that the way to do that would be to register the resource set and it would
leverage in UMA an optional type, although we could require that in our
HEART profile.

Nancy:

Is this something your clients want? Or did you make this up?

Eve:

It’s something my clients want.

Kathleen:

This is something that’s already been done in FHIR. There’s the idea of
calling out an instance and everything that’s dependent on it. Typically
you want a larger context if you’re looking at a list of medications.

http://build.fhir.org/valueset-consent-data-meaning.html

Eve:

But this is a consent.

Kathleen:

It’s irrelevant that it’s a consent. It’s focusing on an instance of a
resource type.

Eve:

The fact that it’s already done in FHIR doesn’t help that we still need to
do it again in UMA.

Adrian:

In order to do profiling, we have to have a use case.

Eve:

But your paper use case didn’t work.

Ken:

We already have a digital FHIR consent implementation.

Justin:

There’s a more fundamental issue here. We have a preplaced document-style
approach to access control. We also have a transactional approach, which is
the OAuth/UMA style approach. HEART is using the latter way of managing
consents. I think the FHIR consent resource is interesting work, but that’s
not relevant to the work we’re doing here.

Eve:

Part of the challenge is that you can query subsets and supersets in FHIR.
It’s been optimized for providers and not for patients. No one has put any
thought yet into use cases of Alice protecting her stuff.

Ken:

We have done that.

Eve:

We keep getting stuck there, though. If Alice wants to protect her stuff,
her stuff is so infinitely divisible and recombinant that she can’t even
understand how to protect it. I feel like the ROI form has not been helpful
to this conversation. I feel like it might be more productive to look at
the flexibility of FHIR. It might be helpful to translate those into
patient terms and make some use cases around what the patient can get out
of them. Date range might be one, or making subsets of the medication list.

Ken:

If the patient doesn’t know how to classify their medication set, allowing
them to make a sub-set is unhelpful. We solve that problem by doing the
categorization for them.

Adrian:

The VA does categorization for you, but you can look at the file and
clarify that the categorization should be different. Patients do understand
examples of authorization.

Nancy:

There are some FHIR resources that patients are more familiar with. It
might be helpful to start with those.

Adrian:

We could allow patients to choose to release some specific things or choose
to release all things with exceptions.

Eve:

If through UMA, you got read access to a resource set, however it was
structured. If you wanted to drill down into the content and filter for a
subset, you can do that if you have a query parameter capability. But if
it’s more complicated than that - if someone permissions access to the API
call and there’s confusion about overlap, then you’ve got a big question.

Nancy:

The term resource set gets confusing. FHIR and UMA use them differently.

Eve:

I’m talking about UMA resource sets.

Adrian:

Can we start with a few FHIR resources and go from there?

Eve:

Date range is the hardest use case and we have the opportunity to take that
on from a patient point of view.

Debbie:

Are you saying we should write the profile now?

Adrian:

I don’t know

Debbie:

Because I would love for us to have something. Other groups are looking to
us for guidance.

Eve:

I don’t know if we have an Alice-centric view of the universe.

Debbie:

Can we work toward helping Eve with this model? Would that help?

Eve:
Absolutely

Sarah Squire
Engage Identity
http://engageidentity.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161031/fd67b887/attachment.html>


More information about the Openid-specs-heart mailing list