[Openid-specs-heart] Draft HEART Meeting Notes 2016-06-20

Sarah Squire sarah at engageidentity.com
Mon Jun 20 21:05:59 UTC 2016


Attending:

Debbie Bucci

Sharice George

Glen Marshall

Sarah Squire

Dale Moberg

Adrian Gropper

Celestin Bitjonck

Luis Maas

Scott Shorter

Edmund Jay

Hope Morgan

Thompson Boyd

Walter Kirk

Jim Kragh

Debbie:

Let’s start with Eve’s use case. I’ve been looking at that FHIR, and the
spec for OAuth Scopes. I am making the assumption that an OAuth scope can
be in the UMA profile, is that right?

Sarah;

They can be in both.

Debbie:

When I look at the resource types, I don’t see the scopes.

Sarah:

The scopes apply to the resources, but the resources themselves aren’t
scopes.

Debbie:

So a resource set isn’t a scope set. If this is an initial visit based on
the profile, there are sets of FHIR resources that Dr. Bob would get. I
thought maybe defining resource sets for this use case might be helpful.

Adrian:

What problem are you hoping to solve in doing this?

Debbie:

Ideally, we eventually get to a profile for UMA.

Adrian:

What is a profile? I can only think in terms of a compatibility label.

Sarah:

The work group as a whole is developing a standard language that systems
can speak in order to earn that “compatibility label.”

Glen:

We’re taking the UMA and OAuth standards and restricting their use to a
limited and well-defined set of problems. These profiles lend themselves to
testing.

Adrian:

It would make this exercise a lot easier if we decided that we’re testing
against a FHIR-based EHR.

Debbie:

Right now we’re working on a use case.

Glen:

Ultimately we’re testing against an API. What’s behind it is a black box.
It doesn’t matter whether it’s an EHR.

Debbie:

In UMA, we could define resources because we need to have permissions
around them. We just need to cover the basics. Do we think patients will
know they have authorization services? Or will they just know that they
have a service? Does the patient need to know where to send Dr. Bob?

Sarah:

Since this is an UMA flow, Dr. Bob just needs to know the location of the
resource. The resource knows the AS that is protecting it and will redirect
Dr. Bob to the correct AS.

Debbie:

It’s understood that the information the administrator needs will be
available in a resource set?

Sarah:

I would consider administrative data to be an UMA-protected resource just
like clinical data.

Debbie:

So we can come up with a list. Would this be part of a resource set? I’m
trying to pull together a list of scopes

Glen:

We can look at the list from SMART. We may need to add resource types.

Debbie:

So we will need to add the resource types that are in this use case like
allergies and immunizations.

So we could define a resource set for this profile.

Adrian:

Why do we need to do this as opposed to just referencing all patient-level
resources?

Debbie:

What if I don’t want to give Dr. Bob everything?

Adrian:

But the scopes can’t exceed FHIR. We can profile FHIR or we can profile
privacy.

Debbie:

Maybe you’re in a doctor’s office and you just want to send your
medications and nothing else. Why shouldn’t you be able to do that?

Adrian:

Does the patient manage all their data?

Debbie:

Yes

So I’m thinking we could define a resource set for Alice and add it to the
use case.

Adrian:

When the patient registers a resource, is she registering a specific list?
At registration time, she doesn’t know who the clients might be. So in
terms of the logic of what we’re profiling, why doesn’t she register
everything?

Sarah:

She would register everything, but she has to be able to taxonomize it
according to FHIR scopes so that she can share some things with some
specialists or providers, but not everything.

Debbie:

Not all providers need access to all information.

Adrian:

So you’re saying you don’t trust the authorization server.

Debbie:

No. I’m just releasing limited information.

Scott:

The function is access control as much as privacy.

Adrian:

So we’re trying to profile the things that Alice can choose from when she
sets policy. Why would we pick a subset of FHIR?

Debbie:

I think she would have the availability of all FHIR resource types, but she
would pick a subset.

Adrian:

So in this use case, the universe of resources is the FHIR patient
resource.

Debbie:

So, with a few minutes left, in order for Bob’s client to interact, it
would have to register?

Sarah:
Yes, that’s right.

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


More information about the Openid-specs-heart mailing list