<div dir="ltr"><div><div><div><div><div>Thanks, Glenn.<br><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><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">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><p>Adrian<br></p><p><br></p></div><div><div><div><div><div><br></div></div></div></div></div></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>