[Openid-specs-heart] Draft HEART Meeting Notes 2016-11-07

[Sarah Squire]

Attending:

Debbie Bucci

Adrian Gropper

Alex Mense

Cait Ryan

Edmund Jay

Glen Marshall

Hope Morgan

Jim Kragh

Ken Salyards

Luis Maas

Nancy Lush

Sarah Squire

Scott Shorter

Walter Kirk

Debbie:

We’re working on a visualization of UMA resource set and scope design
profiling for HEART

Do we have agreement on what Alice might want to protect?

Adrian:

We have use cases that demonstrate what Alice might want to protect. I
don’t find the diagram helpful.

Jim:

The diagram is helpful, but you have to look at the use case first to
understand it.

Nancy:

Eve wrote a document saying what we need in order to build a profile. That
might be a more helpful starting point.

Debbie:

Is that the use case document?

Nancy:

It was sent October 3rd, titled UMA semantic profile, what might it contain?

I don’t know if we have said what resource sets are going to be, but we
should try to do that.

She makes a couple of points that I think are worth discussing.

I had proposed a list of 17 that argonauts had worked on. We don’t have to
do all 17, but I think we need to start somewhere.

Eve also talks about having names for individual resources and resource
types.

Adrian:

I don’t see how we could do this without Eve or someone who is familiar
with implementing UMA. If you look at the five use cases, there are five
statements that involve scope and resources. We could also put in the 17
things that FHIR does and map them to the labeled resource names, but it
still wouldn’t help us to figure out how we use UMA to register everything.

Debbie:

I think it would be helpful to decide resources, and then we can talk about
claims and how it all fits together.

Nancy:

I think if we list the resource types and scopes for each one, and then we
expand it, that’s a good exercise, but in terms of what she wants to
profile, I think the use cases are examples of the profile.

Adrian:

We don’t know enough with the people on the call. Maybe Sarah can tell us
where we should start?

Sarah:

I’m with Nancy on this one. I think we need to talk about resource and
resource sets, and then move onto UMA permissions and how to scope them
specifically to FHIR.

Debbie:

This is what I asked her about what elements should be in the profile.

Jim:

Can we break this down into phases?

Nancy:

Do we want to start with the full 17?

Sarah:

I think starting with the full 17 is fine.

Adrian:

We should start with everything.

Debbie:

I’m assuming that we’re starting with the 17 because most implementations
are starting with that.

Nancy:

Right. The resource server will support whatever they support. They don’t
have to do all 17. We can frame it, and then people can innovate on
whatever is framed.

Adrian:

I don’t know how to figure out what argonaut is doing. There are five use
cases that are real world use cases. We can certainly add more.

Debbie:

We keep blurring the distinction between FHIR resources and resource sets.
But there are subsets that don’t need all FHIR resources to be defined.

Ken:

Even if you say “I want to share everything” you still may bound that with
a date range.

Debbie:

Resources and resource sets are two different concepts. Early suggestions
were immunizations, medication lists, allergies, problem list, contact
info, insurance.

Scott:

Date range could be applicable to any of these.

Sarah:

Date range and exclusions would be UMA permissions, not resources. That’s a
different conversation.

Nancy:

We’re having a nomenclature issue with UMA and FHIR resources. We can give
examples of UMA resource sets in terms of FHIR nomenclature.

Adrian:

All UMA knows about is that there’s a resource, it doesn’t define resource
sets.

Debbie:

There’s a whole chapter on it in the spec. The resource servers themselves
define it.

Adrian:

We don’t have the expertise with how FHIR does things.

Glen:

FHIR doesn’t “do” anything, it’s an API definition.

Ken:

I’m trying to understand what the question is.

Sarah:

The question is how we translate FHIR resources into UMA resource sets in a
way that is meaningful and helpful to administrators of UMA resource
servers.

Jim:

Looking at all the FHIR medication options, I don’t think Alice would
really understand all of them. I agree with Nancy that we should start with
a few and build from there. I think we should start somewhere rather than
continuing to talk about the nuances of FHIR medication resources.

Debbie:

Okay, where do we go from here?

Adrian:

Let’s talk about allergies. Can we do Allergyintolerance.html?

Luis:

No, there are a variety of allergy intolerance statuses. What do you mean?

Adrian:

I mean it in the clipboard sense.

Luis:

Specifying isn’t required, but if it is specified, it has a very specific
meaning.

Nancy:

I don’t think we need to solve all of this in HEART.

Debbie:

But we should have examples to relate to.

Jim:

When you think of allergies, you have many different kinds of allergies.

Sarah:

So to be clear, we are not defining the API itself. FHIR defines the API,
and they’re doing a great job of that, we’re defining a profile of UMA to
protect the API so that patients can use it to share access to the API in a
secure manner.

Luis:

If we all agree with that, that actually simplifies things.

Debbie:
So the profile is only going to use three examples - condition, medications
and allergies.

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