<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Adrian,<br>
<br>
Thanks for the response. It is close to my thinking on the
technical aspects of the use case.<br>
<br>
Eve Maler has kindly offered to help create the authorization
diagrams, so our discussions at the meeting can inform that for her.<br>
<br>
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:<br>
<ul>
<li>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.</li>
<li>The technical implementation of patient de-identification
informed by the IRB policies and is not essential to the use
case. </li>
<li>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. </li>
<li>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. </li>
</ul>
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.<br>
<br>
Best,<br>
Glen<br>
<br>
<div class="moz-signature">
<p><b>Glen F. Marshall</b><br>
Consultant<br>
Security Risk Solutions, Inc.<br>
698 Fishermans Bend<br>
Mount Pleasant, SC 29464<br>
Tel: (610) 644-2452<br>
Mobile: (610) 613-3084<br>
<a class="moz-txt-link-abbreviated" href="mailto:gfm@securityrs.com">gfm@securityrs.com</a><br>
<a class="moz-txt-link-abbreviated" href="http://www.SecurityRiskSolutions.com">www.SecurityRiskSolutions.com</a></p>
</div>
<div class="moz-cite-prefix">On 9/19/15 14:14, Adrian Gropper wrote:<br>
</div>
<blockquote
cite="mid:CANYRo8jUenUUaQoWAnb+um2GAxuABWaavvv+SSKzUzFA2ws2bw@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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
moz-do-not-send="true"
href="http://www.nih.gov/news/health/sep2015/od-17.htm"
target="_blank"><a class="moz-txt-link-freetext" href="http://www.nih.gov/news/health/sep2015/od-17.htm">http://www.nih.gov/news/health/sep2015/od-17.htm</a></a>
and Sept 17 slides <a moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="tel:%28610%29%20644-2452"
value="+16106442452" target="_blank">(610)
644-2452</a><br>
Mobile: <a moz-do-not-send="true"
href="tel:%28610%29%20613-3084"
value="+16106133084" target="_blank">(610)
613-3084</a><br>
<a moz-do-not-send="true"
href="mailto:gfm@securityrs.com" target="_blank">gfm@securityrs.com</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>