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

Mon Jul 11 21:40:26 UTC 2016

Attendees:

Debbie Bucci

Glen Marshall

Scott Shorter

Sarah Squire

David Batchelor

Nancy Lush

Tom Sullivan

John Moehrke

Dale Moberg

Thompson Boyd

Jim Kragh

Edmund Jay

Kathleen Connor

Jin Wen

Julie Maas

Justin Richer

Debbie:

Let’s say there are FHIR resource sets that talk about meds and things that
you define. How do you define them if they’re not resource sets?

Nancy:

Everything should be in a FHIR resource. All the clinical data should be
covered. The difficulty is in defining the cases that come out of that.

John:

The way that FHIR is choosing to divy up - this kind of stuff goes into
this kind of resource. They do it based on the data model. That structure
works great for organizing the data into a resource that holds that kind of
data, but when it comes to privacy topics, they are cross-cutting and don’t
align well. For instance, information about abortion or HIV status might
cut across multiple resources.

Debbie:

I’m trying to think simpler. Dr. Bob wants access to some data. Alice
generates an RPT ticket saying that’s the data they can see. However, an
RPT only implies consent, there’s nothing that explicitly expresses consent.

Sarah:

We’re looking at using the id-event standard being developed in the IETF.
That would be a SCIM-based standard. However, it’s not defined yet.

John:

We’re working on getting FHIR consent onto the HL7 ballot this fall.

Glen:

We also have to keep in mind that the consent resource in FHIR needs to be
computable. It needs to be acted on by the security subsystem during
operation. There could be other types of access control involved.

Kathleen:

There’s a lot of history also around CDA consent. There’s another approach.
What Graham did with the information that’s governed by the consent. It’s
good for making resource sets computable. Alice’s consent is what allows
the resource server to describe her permissions to the AS. If there was a
FHIR consent that, for instance, limited disclosure to certain dates. The
resource server could use the description to indicate that to the AS.

John:

The location of the resources and the location of the consent object don’t
have to be in the same place. It’s just an object. It could be in a
resource server dedicated to consent objects.

Debbie:

So you’re saying you would use an authorization server to identify the type
of attributes?

Kathleen:

We’re just saying that consent could live somewhere else.

Debbie:

So there could be a resource set that is the virtual clipboard. You give
the authorization for the resource set, and I might include the location of
my consent and my advanced directives as part of that. Would that be
included as part of the token?

Sarah:

I think John’s idea of having consent as a resource that is also shared
with Dr. Bob is a great idea.

Debbie:

John, how did you envision us using confidentiality codes, and where is
that placed?

John:

Security tags are in the metadata of the resource. You can have rules that
a patient can record that says “Any data relevant to HIV is blocked” then
you use the tag to indicate whether data is hiv-related, allowing it to be
blocked. There is some question as to how the tag gets there, but that’s
more of an operational issue.

Kathleen:

The security labeling service looks at consent and disclosure. The
enforcement system needs to look at those confidentiality codes.

Debbie:

Resources could have metadata associated with them.

Sarah:

UMA resources have no concept of consent metadata at the AS. So, we would
be looking at either changing or extending the UMA protocol. Whereas if we
store consent as an UMA resource, we can work within the existing protocol.

John:

I propose that we use these tags as scope values. So when someone wants an
UMA resource, they may be issued a token that says ‘hiv-blocked’. The name
of the resource is a metadata element.

Debbie:

So if we defined a resource set, could that scope apply to all the
resources in that set? Because you’re saying the same meta is all the
attributes?

John:

The existence of a specific value in the metadata is what defines that.
There is a confidentiality code set that is a range of risk from low risk
to high risk. There’s a different set for things like hiv or alcohol abuse.

Debbie:

So we could add a confidentiality scope.

Sarah:

We could. Scopes are actually “out of scope” for this project as a whole.
Any AS and RP can agree to use whatever scopes they want. Dr. Bob, for
legal reasons, will probably need more information about the consent than
just a binary. He would need to know when it was collected, by whom, in
what jurisdiction, etc. I think it makes more sense to store that as a
protected resource and proactively push information about it to Dr. Bob if
it changes.

John:

I think it’s important to separate access management from Dr. Bob’s ability
to look up consent records for legal purposes.

Debbie:

So how would Alice use confidentiality codes?

Sarah:

Alice would use confidentiality codes to structure her access management
rules at the AS. But this is profiling scopes, which we’re not doing.

Debbie:

Aren’t we making suggestions about how to use FHIR?

Nancy:

I’m concerned about the physician only getting part of the information.

Kathleen:

That’s always been the way it is. Patients withhold information, and
doctors know that.

John:

FHIR also has a return code indicating that information has been withheld
due to policy.

Debbie:

As part of the FHIR API UMA profile, could we require that all resources at
least have a confidentiality code?

Justin:

That would be an implementation decision. We can allow clients to request
that type of access.

Kathleen:

We could have a guide to tell them how to do it if they need to.

Debbie:

I don’t understand why we wouldn’t require it, if the attribute is on all
FHIR resources.

Justin:

Because it’s not necessarily implemented on all resources.

Debbie:

We could make it SHOULD.

Justin:

The best approach is to always allow the client to request it, define what
it means when the client requests it, but don’t require servers to strictly
define their data in terms of this.

Kathleen:

Why would a client ask for “send me something with a confidentiality code”?

Justin:

Why wouldn’t a client ask for “I want information about hiv status”?

Debbie:

Is “confidentiality code” not implemented everywhere?

Sarah:

Yeah, but we’re not necessarily talking about institutional data. We could
be talking about her fitbit information.

John:

Things could be set to “normal” by default.

Debbie:

It may not be consent, but it’s a step in the right direction.

Justin:

Which is why it’s important to allow clients to request it, but not require
it.

John:

FHIR does not require it. Everything is optional.

Justin:

The core charter of this working group is not to profile the FHIR protocol
itself, but to profile security aspects around using FHIR.

Debbie:

We’re talking about using it as a scope, because we don’t have any idea how
to do consent.

Justin:

We could certainly define it. That would allow the client to request
specific access. It also allows Alice to write policies at the AS. But we
shouldn’t require the RS to implement those specific controls universally.
Be liberal in what you accept. Be strict in what you produce. The RS should
be able to handle all FHIR metadata.

Debbie:
So an AS could handle HEART profiles or other profiles, but that AS might
be handling scopes for FHIR-specific APIs. The resource sets are defined by
the resource server, right? So the resource server would use that as part
of the resource set?

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