<div dir="ltr">Thanks, Glen.<br><div><div><div><div><div><br>We now also have the benefit of the recently approved NIH Precision Medicine Initiative (site <a href="http://www.nih.gov/news/health/sep2015/od-17.htm" target="_blank">http://www.nih.gov/news/health/sep2015/od-17.htm</a> and Sept 17 slides <a href="http://bit.ly/pmi-slides" target="_blank">http://bit.ly/pmi-slides</a>
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?<br><br></div>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.<br><br></div>The essential common denominators of the PCOR and PMI cases seem to be:<br><br></div>1 - a copy of the Resource Server (EHR, PHR) data in a searchable database - the Data Aggregator<br><br></div><div>2 - a consent gathering mechanism that controls access to the Data Aggregator and the RSs<br></div><div><br></div>3 - an Authorization Server that controls Aggregator access of data from the Resource Servers (EHR, PHR)<br><br></div>4 - a set of research-specific services associated with the Data Aggregator that include:<br><ol><li>IRB functionality to control access to the data</li><li>credentialing of research access<br></li><li>search and aggregation of results<br></li><li>de-identification of individual-level data</li><li>accounting for disclosures and maybe even notice to research subjects</li><li>re-consent or dynamic consent by the research subject </li><li>access to data in the Aggregator by the research subject or their care team<br></li></ol><p>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.</p><p>Here is my proposal for a diagram:</p><p>1 - The Data Aggregator uses FHIR and UMA to connect with the RSs (EHR and PHR)</p><p>2 - Each RS adds some fields to their <a href="https://docs.google.com/document/d/1biUqGwvOinf9Sj6eyh3hiiDzoccSEaz3ewOTa7WcwoY/edit" target="_blank">ROI Form</a> (section 3) that identifies the Data Aggregator in the context of the patient's record at the RS. <br></p><p>3 - The patient either has an account at the Aggregator or not:</p><ul><li>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. <br></li><li>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.<br></li><ul><li>If the patient doesn't sign the Aggregator's ROI Form, no further data is transferred from the RS to the Aggregator.</li></ul><li>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. <br></li><li>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.
<br></li></ul><p>In summary, here's where this ends up:</p><ul><li>The patient can specify any AS they want.</li><li>The patient can choose to use one or more PHRs or not.<br></li><li>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.<br></li><li>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.</li><li>The Aggregator has a relationship with the
research subject and their proxy that can be used for accountability,
notice, and re-consent.</li><li>The Aggregator is registered with the
patient's AS and can provide UMA-controlled access to the
research-subject's resources via FHIR. <br></li><li>The Aggregator's IRB can decide which research transactions will involve the patient's AS and which ones will not.</li></ul>Adrian</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 18, 2015 at 1:09 PM, Glen Marshall [SRS] <span dir="ltr"><<a href="mailto:gfm@securityrs.com" target="_blank">gfm@securityrs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Team,<br>
<br>
I have updated the use case to reflect last Monday's discussion and
to more clearly align it with the PCORnet concept.<br>
<br>
The edited use case can be viewed here:
<a href="https://docs.google.com/document/d/1BajiGx_68nrKvSUL1raItMwPkSFCZ_m-aSKUsdb9hzY/edit?usp=sharing" target="_blank">https://docs.google.com/document/d/1BajiGx_68nrKvSUL1raItMwPkSFCZ_m-aSKUsdb9hzY/edit?usp=sharing</a><span class="HOEnZb"><font color="#888888"><br>
<br>
Glen<br>
<br>
<div>-- <br>
<p><b>Glen F. Marshall</b><br>
Consultant<br>
Security Risk Solutions, Inc.<br>
698 Fishermans Bend<br>
Mount Pleasant, SC 29464<br>
Tel: <a href="tel:%28610%29%20644-2452" value="+16106442452" target="_blank">(610) 644-2452</a><br>
Mobile: <a href="tel:%28610%29%20613-3084" value="+16106133084" target="_blank">(610) 613-3084</a><br>
<a href="mailto:gfm@securityrs.com" target="_blank">gfm@securityrs.com</a><br>
<a href="http://www.SecurityRiskSolutions.com" target="_blank">www.SecurityRiskSolutions.com</a></p>
</div>
</font></span></div>
<br>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:#1f497d">RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div>
</div>