[Openid-specs-heart] Updated Use Case "Alice Consents to Clinical Research [UMA]"
Adrian Gropper
agropper at healthurl.com
Mon Sep 21 20:00:21 UTC 2015
Glen,
I'm glad we're headed in the same direction. To summarize and hopefully
form a bit of an agenda for broader discussion:
- The formation of a patient-ID is probably specific to the
research-study, e.g., a case number. The case number itself could be used
to re-identify pseudonymous records, while not linking to data outside of
the research. I don't think the technical details are essential to the use
case, though.
- Agreed. "Patient ID specific to the research study" or any similar ID
associated with a single institution or governance structure is not a
problem. Any kind of identifier shared across multiple institutions raises
privacy, federation, and governance issues that HEART can hopefully bypass.
- The technical implementation of patient de-identification informed by
the IRB policies and is not essential to the use case.
- Agreed. This need not show up anywhere in HEART.
- The choices of PHRs and AS locations are policy-driven matters, out of
scope for the use case. The possibilities do inform the technical choices,
though, and we may want to assume some constraints. For example, on a
practical level for AS implementation guidance, I would like to see a
complete vulnerability assessment and a specific risk analysis for PCORnet.
- Not sure what you mean. Leaving the choice of AS entirely to the
patient ("build, buy, or outsource") is a technical requirement for HEART .
Implementation guidance can certainly be provided by HEART. Research
projects that do not accept a particular AS would be subject to opt-out by
the patient.
- I would like to assume minimal granularity for patient privacy choices
beyond signing the ROI. While more detailed choices may be possible in a
different use case, I believe that imposing a significant cognitive burden
on a stage 4 cancer patient is unrealistic. Most cognitively able people
are unable to express simple privacy preferences for Facebook, let alone a
more complex health record.
- Agreed.
"Let's focus on the difficult task of encoding the policies so that they
can be represented in a de-referenable form, such as an OID. The
referenced policy needs to be computable. This is may be essential to the
use case. Discussion will determine that."
- I don't see this as a HEART issue. Encoding suggests that HEART must
produce standard language, including legal issues, that would be acceptable
to various research governance structures and IRBs. How can this be a
reasonable task for us?
Adrian
On Mon, Sep 21, 2015 at 12:06 PM, Glen Marshall [SRS] <gfm at securityrs.com>
wrote:
> Adrian,
>
> Thanks for the response. It is close to my thinking on the technical
> aspects of the use case.
>
> Eve Maler has kindly offered to help create the authorization diagrams, so
> our discussions at the meeting can inform that for her.
>
> I intend to use case to be policy-agnostic, i.e., it can communicate
> policies but the creation of them is out of scope. We need to make that
> boundary clear and unambiguous for implementers. Here's my thoughts:
>
> - The formation of a patient-ID is probably specific to the
> research-study, e.g., a case number. The case number itself could be used
> to re-identify pseudonymous records, while not linking to data outside of
> the research. I don't think the technical details are essential to the use
> case, though.
> - The technical implementation of patient de-identification informed
> by the IRB policies and is not essential to the use case.
> - The choices of PHRs and AS locations are policy-driven matters, out
> of scope for the use case. The possibilities do inform the technical
> choices, though, and we may want to assume some constraints. For example,
> on a practical level for AS implementation guidance, I would like to see a
> complete vulnerability assessment and a specific risk analysis for PCORnet.
>
> - I would like to assume minimal granularity for patient privacy
> choices beyond signing the ROI. While more detailed choices may be
> possible in a different use case, I believe that imposing a significant
> cognitive burden on a stage 4 cancer patient is unrealistic. Most
> cognitively able people are unable to express simple privacy preferences
> for Facebook, let alone a more complex health record.
>
> Let's focus on the difficult task of encoding the policies so that they
> can be represented in a de-referenable form, such as an OID. The
> referenced policy needs to be computable. This is may be essential to the
> use case. Discussion will determine that.
>
> Best,
> Glen
>
>
> *Glen F. Marshall*
> Consultant
> Security Risk Solutions, Inc.
> 698 Fishermans Bend
> Mount Pleasant, SC 29464
> Tel: (610) 644-2452
> Mobile: (610) 613-3084
> gfm at securityrs.com
> www.SecurityRiskSolutions.com
> On 9/19/15 14:14, Adrian Gropper wrote:
>
> Thanks, Glen.
>
> We now also have the benefit of the recently approved NIH Precision
> Medicine Initiative (site
> <http://www.nih.gov/news/health/sep2015/od-17.htm>
> http://www.nih.gov/news/health/sep2015/od-17.htm and Sept 17 slides
> http://bit.ly/pmi-slides which are a good summary.) The presentation and
> Q&A spent much time talking about the importance of proxies for subjects
> that cannot give consent and about access to new data created within the
> PMI network by the research subjects themselves. How much of these two
> issues are of concern in PCOR initiatives?
>
> I'm hoping we can take a take a stab at mapping your use-case into FHIR
> and UMA and end up with a diagram like in the other two use-cases.
>
> The essential common denominators of the PCOR and PMI cases seem to be:
>
> 1 - a copy of the Resource Server (EHR, PHR) data in a searchable database
> - the Data Aggregator
>
> 2 - a consent gathering mechanism that controls access to the Data
> Aggregator and the RSs
>
> 3 - an Authorization Server that controls Aggregator access of data from
> the Resource Servers (EHR, PHR)
>
> 4 - a set of research-specific services associated with the Data
> Aggregator that include:
>
> 1. IRB functionality to control access to the data
> 2. credentialing of research access
> 3. search and aggregation of results
> 4. de-identification of individual-level data
> 5. accounting for disclosures and maybe even notice to research
> subjects
> 6. re-consent or dynamic consent by the research subject
> 7. access to data in the Aggregator by the research subject or their
> care team
>
> How much of #4, if any, do we need to map into OAuth or UMA? 4-1 through
> 4-4 have nothing to do with FHIR or OAuth. 4-5 through 4-7 are all
> transactions with the research subject or their proxy that might be
> facilitated by the technology used for 1,2 and 3.
>
> Here is my proposal for a diagram:
>
> 1 - The Data Aggregator uses FHIR and UMA to connect with the RSs (EHR and
> PHR)
>
> 2 - Each RS adds some fields to their ROI Form
> <https://docs.google.com/document/d/1biUqGwvOinf9Sj6eyh3hiiDzoccSEaz3ewOTa7WcwoY/edit>
> (section 3) that identifies the Data Aggregator in the context of the
> patient's record at the RS.
>
> 3 - The patient either has an account at the Aggregator or not:
>
> - A registration process is begun where the Aggregator presents an
> IRB-approved ROI Form and offers to register itself as a RS with the
> patient's AS.
> - If the patient signs the Aggregator's ROI Form, identity attributes
> are transferred via FHIR from the clinical RS (EHR or PHR) that the
> Aggregator uses to search their database for a patient match. The patient
> and/or proxy are issued credentials to access the Aggregator.
> - If the patient doesn't sign the Aggregator's ROI Form, no further
> data is transferred from the RS to the Aggregator.
> - If there's no match at the Aggregator, then the patient is
> automatically enrolled as a new research subject based on the information
> in the ROI Form they just signed.
> - If there is a match at the Aggregator, then the EHR or PHR context
> (step 2 above) is added as another data source to the research subject's
> account at the Aggregator.
>
> In summary, here's where this ends up:
>
> - The patient can specify any AS they want.
> - The patient can choose to use one or more PHRs or not.
> - The Aggregator can offer any policies they want to the patient
> without bothering or federating with the clinical RSs. This can help get
> research data from non-HIPAA wearables or family members resource servers,
> etc... All we need is UMA and a policy of accepting the patient-specified
> AS.
> - There's no universal patient ID needed. Initial patient matching is
> always done with the patient's (or proxy's) cooperation and as much context
> provided by the RS as the patient wants to share. The patient can see or
> set optional discovery parameters they want on the Aggregator's research
> ROI Form in an IRB-approved way.
> - The Aggregator has a relationship with the research subject and
> their proxy that can be used for accountability, notice, and re-consent.
> - The Aggregator is registered with the patient's AS and can provide
> UMA-controlled access to the research-subject's resources via FHIR.
> - The Aggregator's IRB can decide which research transactions will
> involve the patient's AS and which ones will not.
>
> Adrian
>
> On Fri, Sep 18, 2015 at 1:09 PM, Glen Marshall [SRS] <gfm at securityrs.com>
> wrote:
>
>> Team,
>>
>> I have updated the use case to reflect last Monday's discussion and to
>> more clearly align it with the PCORnet concept.
>>
>> The edited use case can be viewed here:
>> https://docs.google.com/document/d/1BajiGx_68nrKvSUL1raItMwPkSFCZ_m-aSKUsdb9hzY/edit?usp=sharing
>>
>> Glen
>>
>> --
>>
>> *Glen F. Marshall*
>> Consultant
>> Security Risk Solutions, Inc.
>> 698 Fishermans Bend
>> Mount Pleasant, SC 29464
>> Tel: (610) 644-2452 <%28610%29%20644-2452>
>> Mobile: (610) 613-3084 <%28610%29%20613-3084>
>> gfm at securityrs.com
>> www.SecurityRiskSolutions.com
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>>
>
>
> --
>
> Adrian Gropper MD
>
> RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
--
Adrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150921/ab319830/attachment.html>
More information about the Openid-specs-heart
mailing list