[Openid-specs-heart] (no subject)

Sat Sep 19 18:09:34 UTC 2015

Thanks, Glenn.

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.
   - 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
> Mobile: (610) 613-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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150919/941f26ad/attachment.html>