[Openid-specs-heart] Draft HEART Meeting Notes 2016-02-15

Sarah Squire sarah at engageidentity.com
Mon Feb 15 22:29:53 UTC 2016


Attendees:

Debbie Bucci

Thompson Boyd

Sarah Squire

Justin Richer

Glen Marshall

Nancy Lush

Adrian Gropper

Danny van Leeuwen

Eve Maler

Debbie:

The security profile vote has passed. Let’s move on to Glen’s use case.

Does the IRB have to do with patient consent?

Glen:

The IRB does require consent depending on the nature of the studies. How do
you handle the core case, withholding from the EHR data that could be
identified that resides in the CDRN.

Debbie:

One of the things I’ve been focused on is instead of deidentified data sent
to an enclave, there is a push for some of it to have the query cached and
add new participants or take away. There are other models that could
respect a revocation of consent.

Glen:

I think that might be of interest.

Adrian:

Can we recap? The patient is the resource owner? The AS is run by the IRB?
The idea is we are trying to figure out what UMA has to do if the
researcher doesn’t have a patient in mind in order to get deidentified data.

Glen:

The researcher would not have a patient in mind.The patient is known to the
IRB, but the actual request for data would be anonymous.

Adrian:

I have lost the picture of why this is UMA at all. If the patient is not a
resource owner, then somebody else, the CDRN or someone else, is a resource
owner.

Eve:

We’re at step n in philosophy. The CDRN is the requesting party. So the
resource owner is the patient and the data is about the patient.

Adrian:

Isn’t that OAuth?

Eve:

No. The requesting party is a legal party. OAuth doesn’t have a concept of
that.

Justin:

OAuth does have a concept of a legal party.

Eve:

There is sharing going on between two parties.

Adrian:

Why isn’t the CDRN running the authorization server?

Eve:

It’s the requesting party. It’s separable. The requesting party probably
shouldn’t run the AS. One of the things that should be possible to
configure is purpose of use limitations.

Sarah:

So should we have the patient set the policy on the AS, rather than the IRB?

Eve:

We could set standard claims that derive from IRB semantics.

Debbie:

The patient is developing a relationship between themselves and the CDRN.

Eve:

The IRB sounds to me like a trust framework.

Adrian:

What I’m hearing is that the CDRN is the resource server. It’s operating a
directory service because it has to fulfill an anonymizing service. The
requesting party is the researcher.

Sarah:

No, you’ve got that wrong. The CDRN is the requesting party and the EHR is
the resource server.

Glen:

Right.

Eve:

The CDRN could also use UMA. There could be a chained use case.

Glen:

The research client has an OAuth relationship with the CDRN. For the
purposes of a researcher accessing the CDRN, it’s a simple OAuth resource
server.

Adrian:

Should we tackle the simpler case of a directory as a resource?

Glen:

That has nothing to do with this use case?

Debbie:

Who owns the authorization service? If it were PCORNet, a researcher could
request data. Where does the authorization server live?

Glen:

The IRB selects the AS.

Eve:

I sent an email with some questions that might re-align the swimlane
diagram.

Justin:

I would like to point out that the scale problems pointed out earlier were
about scalability of the process, not the technology.

Glen:

What the UK did was standardize the enrollment process.

Justin;

So it was a single domain, so it didn’t have to scale.

Debbie:

So I could have an IRB that asks for one patient or thousands of patients.
It could be aggregated. I don’t think the IRB is presented to the patient.

Glen:

The researchers recruit the physicians and have them ask the patients to
join the study.

Sarah:

Would it be fair to say that the patient’s IRB form is in fact the patient
setting the policy on their AS?

Adrian:

I’m still completely lost. Does the EHR provide anonymized data or
patient-level data?

Glen:

If the EHR is given the burden of anonymizing the data before it is sent,
that’s probably technologically easier than the CDRN  doing it.

Adrian:

I’m completely lost. I think we should think in terms of securing a
directory for anonymization purposes.

Glen:

Maybe you should write that use case.

Debbie:

Is this a use case that could be implemented today?

Glen:

It is, except that how does a patient revoke consent?

Eve:

There’s room to do an analysis paper about all the ways revocation can be
done.

Debbie:

So the IRB selects the AS, then that’s PCORNet? Who is managing those
authorizations? Who manages the IRB? Where are these boards?

Glen:

That’s a policy matter. It’s outside the scope of this use case. The IRB is
managed by the institution that’s sponsoring the research.

Debbie:

So the CDRN has a relationship with that institution?

Glen:

yes

Adrian:

Why isn’t the resource owner able to revoke a token?

Eve:

Revocation could be a lot of things. You might not want to specify it at a
policy or UX level.

Sarah:

We need to anonymize at the EHR so that we can keep discreet records that
UMA can handle as resources and possibly revoke.

Glen:

We can still have discreet anonymized records.

Adrian:

We are talking about a patient-centered UMA transaction. The AS is a
patient level AS, and there’s a directory that handles the anonymization
component.

Glen:

We are merging the anonymization service for the purpose of simplicity.

Adrian:

Where does the patient’s AS come in?

Sarah:

It doesn’t. The IRB’s AS is the only AS relevant to this use case.

Glen:

The patient-centered aspect comes into play with the ability to revoke
access and the ability for notification of use.

Debbie:

Let’s wrap this up, but we can pick it up again next week. Can we clear up
the meetups?

Justin:

There’s a closed FHIR/Argonauts meetup on Monday. There is an informal
HEART meetup Tuesday at 5pm.

Debbie:

Okay, so we’ll cancel the call on the 29th, and we’ll pick up the use case
discussion next week.


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


More information about the Openid-specs-heart mailing list