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

[Sarah Squire]

Attending:

Debbie Bucci

Sarah Squire

Eve Maler

Justin Richer

Glen Marshall

Tom Sullivan

John Moehrke

Edmund Jay

Jin Wen

Adrian Gropper

Josh Mandel

Kathleen Connor

Thompson Boyd

Glen’s use case

Glen:

The IRB is key because they make sure that everything is compliant with
policy. They are the keeper of the keys. They have a trust relationship
with the AS for this use case.

Tom:

Does this use case involve pseudonymous research data?

Glen:

It does, but it is peripheral.

Eve:

Should that be something we take into a account later?

Glen:

Yes, but that’s policy. Those technologies exist, but they are outside the
scope of our work.

Debbie:

Wouldn’t the IRB be expressed somewhere? In an authorization?

Glen:

IRBs make sure that all of the participants are consistent with
regulations.

Technical preconditions and entity roles have not changed. Entity mappings
have not changed.

The use case steps are intended to be in line with UMA standard flows.

The sequence diagrams assume that the messages are sent according to the
UMA profile for HEART.

Tom:

When do the OAuth credentials get assigned? I think we should recommend
two-factor authentication.

Glen:

The research client system would be the one I would like to supply with
those credentials.

I’m expecting the CDRNs to use the data model established by PCORNet. And
FHIR somehow gets into this. Reidentification of the patient is required in
order to send a notification of disclosure to the patient.

Eve:

Do the disclosure bits exist today?

Glen:

It does for some things, but not yet for the CDRN.

Debbie:

The EHR never knows the researcher who gets the data, right?

Glen:

Yes, that’s why I established a reidentification loop, because all it knows
is that it sent data to the CDRN. That’s why the CDRN also needs to have a
disclosure report.

Debbie:

Would someone be authorized to audit who exactly is looking at the records?

Glen:

Wishfully, I would like the CDRN to report any disclosure to the patient
right away.

Debbie:

Could that data be requested?

Glen:

Right now, it could be, but I’m not sure that would be core to the use case.

Kathleen:

Are you basing this on consent directives? Or authorizations under HIPAA?
Are you looking at role?

Glen:

It could be, the terms consent and authorization are ambiguous. I am using
them in an IRBish way.

Kathleen:

If there were fine grained authorization under HIPAA, that part could name
the specific person to whom you’re disclosing, but that’s not available
under current approaches.

Glen;

I would think that a fine-grained authorization would show up in the IRB’s
policy.

Debbie:

I’m worried about the bad actor. Would anyone know the full path?

Glen:

I haven’t delved into the contents of the audit log from the AS. I don’t
know that that plays into this use case.

The resource owner in this case, which I’m presuming is still the patient,
would want to review the accumulated disclosure logs and if what’s being
done is out of concert with their understanding, they should be able to
modify or cancel their consent.

Eve:

The UMA legal subgroup is working on these sorts of use cases to develop
UMA model clauses. If you’re using UMA flows, if the RO said ‘give access’
and there was some regulation in place saying they can’t give access, we
want the resource owner to be notified.

John:

There’s two topics relevant here. There are two different ways of proving
that you have integrity of your audit log - one is technical, and one is
pattern-based. Both have been used in legal cases.

Glen:

If there are regulations that would interfere with this use case, I would
like to know.

Debbie:

Where would be AS live?

Glen:

The IRB would stand up the AS.

Josh:

Which IRB are we talking about? If we’re talking about the study’s IRB, why
do we have an UMA flow? They don’t require the consent of the patient.

John:

I thought we were trying to let the patient self-enroll in research.

Kathleen:

People could release their own information directly from their PHR to
different studies and trials.

Glen:

I would like to have a use case where the PHR is the source of truth, but
that’s not this use case.

John:

Whose AS is this?

Glen:

It’s the IRB’s AS

Debbie:

There are use cases where patients are encouraged to donate their data.

Eve:

I sent a note to the list about some party to entity mappings. The AS
question seems like a business level question. If Alice is our resource
owner, and Alice finds the IRB’s AS acceptable, and she uses it, then
that’s the answer for this ecosystem.

Glen:

One of the problems we have is that the IRB has established policies of its
own. There is no good way to combine those base level permissions and other
permissions into a baseline set of policies.

Adrian:

The IRB is always going to prefer to have the patient-centered policy
domain.

Glen:

I disagree. I haven’t seen an IRB take that position.

Josh:

>From the perspective of a researcher who wants to run a study, I’m trying
to understand what the workflow would be like. Would I have to give claims
to each of a thousand UMA servers?

Glen:

We’d have to have some sort of registry that doesn’t exist now.

Debbie:

Isn’t it the CDRN you would query against? And that entity would have the
relationship to the patient data.

Josh:

The flow you are talking about is having a CDRN as a resource server, not a
client.

If the CDRN is an RP, they have to find the resources and register with all
of them. How does that scale?

Glen:

It would have to be out-of-band provisioning.

Josh:

But I’m talking about the enrollment process. How does that scale?

Debbie:

The AS policies may be distributed, so when I new patient comes on, they
are just added to the flow.

Glen:
If I have multiple ASs closely associated with patients, it might be
possible to reidentify the patient. So it’s important to be careful not to
allow use of that as an identifier.


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