[Openid-specs-heart] Updated Use Case "Alice Consents to Clinical Research [UMA]"
Glen Marshall [SRS]
gfm at securityrs.com
Mon Sep 21 16:06:09 UTC 2015
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 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.
> o 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 <mailto: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 <tel:%28610%29%20644-2452>
> Mobile: (610) 613-3084 <tel:%28610%29%20613-3084>
> gfm at securityrs.com <mailto:gfm at securityrs.com>
> www.SecurityRiskSolutions.com <http://www.SecurityRiskSolutions.com>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> <mailto: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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150921/ba5a39cc/attachment.html>
More information about the Openid-specs-heart
mailing list