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

Moehrke, John (GE Healthcare) John.Moehrke at med.ge.com
Mon Feb 15 22:37:16 UTC 2016


Also discussed on the call

 

Ongoing standards developments 

* ISO TC215 (Healthcare Informatics) 

** ISO/IS 25237 – Health Informatics, Pseudonymization

** ISO/TS 17975 – Principles and data requirements for consent

* HL7

** CDA Privacy Consent Directive

** FHIR Privacy Consent Directive -- http://hl7-fhir.github.io/pcd/pcd.html

* IHE

** Advanced Patient Privacy Consents – a profile of the above CDA Privacy Consent Directive for use in Document Sharing exchanges

 

 

 

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Sarah Squire
Sent: Monday, February 15, 2016 4:30 PM
To: HEART List
Subject: [Openid-specs-heart] Draft HEART Meeting Notes 2016-02-15

 

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

 <https://urldefense.proofpoint.com/v2/url?u=http-3A__engageidentity.com_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=tfQk8bTujXnofbBRpMOu5JAVtB31GqZTlVBymtVlOMQ&s=-oj7IEGl-WGXtBnUps7DwpSitbRB9TAZbMBYc7_nans&e=> http://engageidentity.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160215/45a92c95/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6966 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160215/45a92c95/attachment-0001.p7s>


More information about the Openid-specs-heart mailing list