<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
It appears that we are discussing a five-part problem:<br>
<ul>
<li>The technical aspects, driven by use cases, of how to secure,
communicate, and assure identity, authentication,
authorizations, and obligations.</li>
<li>The technical aspects, also driven by uses cases, of how to
express, communicate, and assure patients', and their
delegates', disclosure preferences at sufficient (TBD)
granularity.<br>
</li>
<li>The human engineering aspects of how to minimize the effort
and technical knowledge required for the end-users - both
patients and providers.<br>
</li>
<li>The technical, business, and legal aspects of federating the
participants and their automated systems.<br>
</li>
<li>The economic aspects of how to minimize costs while allocating
those costs equitably. <br>
</li>
</ul>
I'm sure there may be other ways to slice and dice the problem
space. However, the first two points above seem to be well within
our immediate capabilities. The human engineering aspects require
additional expertise as well as end-user input. And the last two
points need policy-level resolution, i.e., out of this group's
scope. <br>
<br>
I'd recommend we revisit these points before we engage in the next
use case, but after we finalize the current one.<br>
<br>
Thanks,<br>
Glen<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 8/6/15 19:05, Adrian Gropper wrote:<br>
</div>
<blockquote
cite="mid:CANYRo8hbbReQa8f15-xa0igaziv2dX5r1s0SfL1mgJXchQ6vZw@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr">
<div>The only information Alice should have to give to her
provider is the URL of her UMA Authorization Server (if she
has one) or something else that resolves to her UMA
Authorization Server. In many cases, this pointer to her UMA
AS could be accessible as part of a federated IdP service but
we may not be able to count on federation being readily
acceptable to the providers.<br>
<br>
</div>
Adrian<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Aug 6, 2015 at 5:00 PM,
Maxwell, Jeremy (OS/OCPO) <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:Jeremy.Maxwell@hhs.gov" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:Jeremy.Maxwell@hhs.gov">Jeremy.Maxwell@hhs.gov</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">This
thread began when I asked what does this look like
for the patient? What information does Alice need
to give her provider?</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<div>
<div style="border:none;border-top:solid #b5c4df
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Moehrke, John (GE Healthcare) [mailto:<a
moz-do-not-send="true"
href="mailto:John.Moehrke@med.ge.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:John.Moehrke@med.ge.com">John.Moehrke@med.ge.com</a></a>] <br>
<b>Sent:</b> Thursday, August 06, 2015 4:51 PM<br>
<b>To:</b> Adrian Gropper; Maxwell, Jeremy
(OS/OCPO)<br>
<b>Cc:</b> Josh Mandel; <a
moz-do-not-send="true"
href="mailto:openid-specs-heart@lists.openid.net"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a></a></span></p>
<div>
<div class="h5"><br>
<b>Subject:</b> RE: [Openid-specs-heart] HEART
2015-08-05 meeting notes</div>
</div>
</div>
</div>
<div>
<div class="h5">
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Those
of us that are not in Mass, have great
healthcare interoperability through the
NwHIN… I agree that it is not patient
directed, but my records are available anywhere
in the NwHIN. I am not trying to disagree with
you, but when you say that “</span>Apple has
shown us how patient-directed interoperability can
work in a highly integrated system.<span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">â€
is just way too argumentative. A walled-garden
is always well manicured.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I
too have lost track of what the argument is…
all this discussion around ‘technical savvy’
vs not is irrelevant to the work that we can
accomplish in HEART. </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">John</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a moz-do-not-send="true"
href="mailto:agropper@gmail.com"
target="_blank">agropper@gmail.com</a> [<a
moz-do-not-send="true"
href="mailto:agropper@gmail.com"
target="_blank"><a class="moz-txt-link-freetext" href="mailto:agropper@gmail.com">mailto:agropper@gmail.com</a></a>]
<b>On Behalf Of </b>Adrian Gropper<br>
<b>Sent:</b> Thursday, August 06, 2015 3:06 PM<br>
<b>To:</b> Maxwell, Jeremy (OS/OCPO)<br>
<b>Cc:</b> Josh Mandel; Moehrke, John (GE
Healthcare); <a moz-do-not-send="true"
href="mailto:openid-specs-heart@lists.openid.net"
target="_blank">openid-specs-heart@lists.openid.net</a><br>
<b>Subject:</b> Re: [Openid-specs-heart] HEART
2015-08-05 meeting notes</span></p>
<p class="MsoNormal"> </p>
<div>
<div>
<div>
<div>
<p class="MsoNormal"
style="margin-bottom:12.0pt">I'm not sure
what we're negotiating here. The current
approach to interoperability does not work
for many, maybe most people. Part of the
reason it doesn't is that privacy
approaches that work at a scale of 10K or
100K people don't work when the scale is
100 Million people. I've been a party to
four or five generations of attempts at
interoperability (IHE, NwHIN, CONNECT,
DIRECT, BlueButton Plus) and we still
don't have a clear solution. We've also
seen that even completely centralized
systems like the UK NHS can't deal with
this problem very well so I can't see why
CommonWell or Carequlality or Epic
everywhere would succeed.</p>
</div>
<p class="MsoNormal"
style="margin-bottom:12.0pt">The one thing
we haven't tried is patient-driven
interoperability. Apple has shown us how
patient-directed interoperability can work
in a highly integrated system. UMA is the
only standard we have that has the potential
to introduce patient-driven interoperability
to healthcare. </p>
</div>
<p class="MsoNormal"
style="margin-bottom:12.0pt">We have to give
patients that understand UMA the option to use
it. Patients who don't care will see no
difference at all because the Resource Server
will offer a default AS. <br>
<br>
Once patients have the option to specify the
AS the other interoperability issues,
including scopes, will incrementally get
fixed. But the first step is to agree that
there's only one Alice and she has an AS. That
is the only scalable and non-coercive
solution.</p>
</div>
<p class="MsoNormal">Adrian</p>
</div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">On Thu, Aug 6, 2015 at 9:51
AM, Maxwell, Jeremy (OS/OCPO) <<a
moz-do-not-send="true"
href="mailto:Jeremy.Maxwell@hhs.gov"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:Jeremy.Maxwell@hhs.gov">Jeremy.Maxwell@hhs.gov</a></a>>
wrote:</p>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">How
many patients do we expect to have the
technical savvy to say this to their
provider? In practice, where will these
authorization servers reside?</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="background:yellow">"Dear Dr.
Jones: please treat my authorization
server, at <a moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=https-3A__authz.alice.org&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=cpoRMhQHerIlja_ffVTQNKS7xUf9tRDFgogzkp23Ycs&s=YNb7HB0fsZmQTY8glywsqyEBVsXi88kGWmzbLaDQU9U&e="
target="_blank">https://authz.alice.org</a>,
as representing my wishes for disclosure
of my health data. Use the decisions
that server renders to guide your access
control decisions about my data."</span></p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Openid-specs-heart [mailto:<a
moz-do-not-send="true"
href="mailto:openid-specs-heart-bounces@lists.openid.net"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:openid-specs-heart-bounces@lists.openid.net">openid-specs-heart-bounces@lists.openid.net</a></a>]
<b>On Behalf Of </b>Josh Mandel<br>
<b>Sent:</b> Thursday, August 06, 2015
9:19 AM<br>
<b>To:</b> Moehrke, John (GE Healthcare)</span></p>
<div>
<div>
<p class="MsoNormal"><b>Cc:</b> <a
moz-do-not-send="true"
href="mailto:openid-specs-heart@lists.openid.net"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a></a><br>
<b>Subject:</b> Re:
[Openid-specs-heart] HEART 2015-08-05
meeting notes</p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">As to the
division between "gross ceremony"
and "finer-grain adjustments", I
want to suss out whether the
following model (which readily
applies to UMA, though not to
vanilla OAuth) is consistent with
you have in mind, or whether this
model is addressing a different
question entirely:</p>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">1. <b>Gross
ceremony</b> consists of Alice
introducing her resource server
to an authorization server of
her choice. For example, she
might sign a document saying
(effectively): "Dear Dr. Jones:
please treat my authorization
server, at <a
moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=https-3A__authz.alice.org&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=cpoRMhQHerIlja_ffVTQNKS7xUf9tRDFgogzkp23Ycs&s=YNb7HB0fsZmQTY8glywsqyEBVsXi88kGWmzbLaDQU9U&e="
target="_blank"><a class="moz-txt-link-freetext" href="https://authz.alice.org">https://authz.alice.org</a></a>,
as representing my wishes for
disclosure of my health data.
Use the decisions that server
renders to guide your access
control decisions about my
data." This document is easily
comprehensible, could serve as
evidence in court, etc. </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">2. And then
the <b>finer-grain adjustments</b> would
be made by Alice in concert with
her authorization server (for
example, establishing specific
policies about who can access
her data, and which data, and
for what purposes, and under
what conditions).</p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">On Thu, Aug 6,
2015 at 9:06 AM, Moehrke, John (GE
Healthcare) <<a
moz-do-not-send="true"
href="mailto:John.Moehrke@med.ge.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:John.Moehrke@med.ge.com">John.Moehrke@med.ge.com</a></a>>
wrote:</p>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I
agree with your proposal for
‘Authorize for
Disclosure’ and to
de-emphasize
‘Consent’… (although
this problem with
‘Consent’ is only a USA
problem)… </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><br>
But I don’t think that a
UMA/OAuth ‘token’ will
be seen as legitimate
evidence in a court. It
would be quickly shown to be
not intelligible by the
layperson, I can barely read
them. Thus it is not
evidence of the act of
‘authorizing for
disclosure’ ceremony.
This is indeed a
practice-of-law problem that
we all hope changes, but I
have little hope that it
will change in the coming 10
years. This is why I want
the gross ceremony to be a
pre-condition, with the
UMA/OAuth technology be the
fine-grain solution. I
expect that a gross ceremony
can be shown in a court as
evidence that all parties
understood the use of the
technology would be used for
fine-grain. Note that if the
courtroom antics change,
then this pre-condition
simply goes away. But by
putting it there we enable
it to be used, and thus make
our solution more palatable
to the legal folks at those
custodian organizations that
are afraid to release
information today.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">John</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<div>
<div
style="border:none;border-top:solid
#b5c4df 1.0pt;padding:3.0pt
0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Aaron Seib [mailto:<a
moz-do-not-send="true"
href="mailto:aaron.seib@nate-trust.org" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:aaron.seib@nate-trust.org">aaron.seib@nate-trust.org</a></a>]
<br>
<b>Sent:</b> Thursday,
August 06, 2015 7:58 AM<br>
<b>To:</b> Moehrke, John
(GE Healthcare); 'Adrian
Gropper'; 'Debbie Bucci'<br>
<b>Cc:</b> <a
moz-do-not-send="true"
href="mailto:openid-specs-heart@lists.openid.net" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a></a><br>
<b>Subject:</b> RE:
[Openid-specs-heart]
HEART 2015-08-05 meeting
notes</span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><a
moz-do-not-send="true"
name="14f04d104ae033cf_14f045134f09176f_14f031f41371de48__MailE"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I
tend to agree with
John’s
recommendation with a
friendly amendment.</span></a></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">We
should not mis-use the
word consent. We should
use the term –
authorize for
disclosure.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The
primary reason being
that the term consent
has a lot of baggage and
is defined in law for
Human research
protections and
authorize for disclosure
is more accurate to me.
Consent – as pointed
out by the Kind Sir from
Boston (Adrian) to point
out – meant something
before 2002 that it
doesn’t mean anymore.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">In
my opinion the notion of
authorize for disclosure
also conveniently aligns
with my understanding of
what ab “UMA/OAuth
token†would represent
on a per transaction
basis.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">In
court we would expect
the entity accused of
unauthorized disclosure
to be able to produce a
valid UMA/OAuth token as
a sufficient defense
from mis-representations
of trial lawyers.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Aaron
Seib</span></p>
<p class="MsoNormal"><a
moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.nate-2Dtrust.org_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=87vCtxeoEunALdecDlNur8aIU5qcY6YWTAxWw6j34cs&s=PU_01do09mzHBYjfdhFvZCLDAP7Tpxnm1P001w-6AlU&e="
target="_blank"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif"">NATE</span></a><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">,
CEO</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">@CaptBlueButton</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">(o)
<a
moz-do-not-send="true"
href="tel:301-540-2311" target="_blank">301-540-2311</a></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">(m)
<a
moz-do-not-send="true"
href="tel:301-326-6843" target="_blank">301-326-6843</a></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
</div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<div>
<div
style="border:none;border-top:solid
#b5c4df
1.0pt;padding:3.0pt 0in
0in 0in">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Openid-specs-heart [<a
moz-do-not-send="true"
href="mailto:openid-specs-heart-bounces@lists.openid.net"
target="_blank"><a class="moz-txt-link-freetext" href="mailto:openid-specs-heart-bounces@lists.openid.net">mailto:openid-specs-heart-bounces@lists.openid.net</a></a>]
<b>On Behalf Of </b>Moehrke,
John (GE Healthcare)<br>
<b>Sent:</b>
Thursday, August 6,
2015 7:27 AM<br>
<b>To:</b> Adrian
Gropper; Debbie
Bucci<br>
<b>Cc:</b> <a
moz-do-not-send="true"
href="mailto:openid-specs-heart@lists.openid.net" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a></a><br>
<b>Subject:</b> Re:
[Openid-specs-heart]
HEART 2015-08-05
meeting notes</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">At
the federal level, under
HIPAA alone, there is no
need for consent for
purposes of using the
data within the Covered
Entity for Treatment,
Payment, and Normal
operations.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">BUT,
there are plenty of
states that require
consent… Ignoring
reality of states
regulations is not
useful.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">AND,
there are some
institutions that would
rather have a consent
that authorizes them to
share beyond their
Covered Entity boundary.
Not everyone reads HIPAA
‘Treatment’ as an
authorization to share
with any treating
provider.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">AND,
there are some
‘sensitive’ health
topics covered by
federal money that do
come with a requirement
for consent for sharing.
This was the main focus
of the DS4P efforts.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">So,
let’s not focus on
HIPAA alone. Let’s
expect that ‘for
whatever reason an
organization wants to
have positive evidence
that the patient desires
sharing to happen’ as
the trigger to allow it
to happen (otherwise
deny it from happening.
This would seem more
helpful to the community
we are doing this work
for. </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">An
important aspect of all
of this is how will the
organization holding the
data be able to legally
defend that a UMA/OAuth
token was valid evidence
of consent that would
hold up in a
courtroom… We can’t
address this in HEART,
but it should not slow
us down. We again,
document this as a
precondition to our
work. One way this is
done is that a paper
trail is a part of the
initial setup of a
patient engaging with
the system.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">John</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Openid-specs-heart [<a
moz-do-not-send="true"
href="mailto:openid-specs-heart-bounces@lists.openid.net"
target="_blank"><a class="moz-txt-link-freetext" href="mailto:openid-specs-heart-bounces@lists.openid.net">mailto:openid-specs-heart-bounces@lists.openid.net</a></a>]
<b>On Behalf Of </b>Adrian
Gropper<br>
<b>Sent:</b> Wednesday,
August 05, 2015 11:49 PM<br>
<b>To:</b> Debbie Bucci<br>
<b>Cc:</b> <a
moz-do-not-send="true"
href="mailto:openid-specs-heart@lists.openid.net" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a></a><br>
<b>Subject:</b> Re:
[Openid-specs-heart]
HEART 2015-08-05 meeting
notes</span></p>
<p class="MsoNormal"> </p>
<div>
<div>
<div>
<div>
<p class="MsoNormal"
style="margin-bottom:12.0pt">I have never heard the term "simple
consent". There's
nothing like
"consent" in the
context of data
sharing that I can
think of. HIPAA
removed the
patient's right of
consent in 2002 <a
moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=https-3A__patientprivacyrights.org_-3Fs-3DHIPAA-2BConsent&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=QPfpP6tNPhNn0uCYFnfBuRqSH5IVEwKw_Jqp3j4NGRQ&s=u1OCcH7ZkX-4jzmNs_eIhVZUi0lQOy0npXd30zYGE8I&e="
target="_blank"><a class="moz-txt-link-freetext" href="https://patientprivacyrights.org/?s=HIPAA+Consent">https://patientprivacyrights.org/?s=HIPAA+Consent</a></a></p>
</div>
<p class="MsoNormal"
style="margin-bottom:12.0pt">There
are consent forms
for research but
that's not part of
the use cases we're
tackling these days.</p>
</div>
<p class="MsoNormal"
style="margin-bottom:12.0pt">Does
anyone have an example
of consent for
clinical data sharing
to share with us?</p>
</div>
<p class="MsoNormal">Adrian</p>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"
style="margin-bottom:12.0pt"> </p>
</div>
</div>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">On
Thu, Aug 6, 2015 at
12:10 AM, Debbie Bucci
<<a
moz-do-not-send="true"
href="mailto:debbucci@gmail.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:debbucci@gmail.com">debbucci@gmail.com</a></a>>
wrote:</p>
<div>
<div>
<p class="MsoNormal">@Eve
- yes I know its
client but I'm
really hung up on
the token
generation/choices.
Thanks for the
tweaks.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">I
know we clarified
that the release
form is NOT
consent in one of
our earlier
meetings but is
this (release of
information) what
I have heard
others refer to as
simple consent?
During this
process would
access to
problems/meds/allergies
be included in
that
authorization/consent flow?
I visualized more
than demographics
in the
conversation.</p>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
<div>
<p
class="MsoNormal"> </p>
</div>
<div>
<p
class="MsoNormal"> </p>
<div>
<p
class="MsoNormal">On
Wed, Aug 5,
2015 at 9:21
PM, Justin
Richer <<a
moz-do-not-send="true" href="mailto:jricher@mit.edu" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:jricher@mit.edu">jricher@mit.edu</a></a>>
wrote:</p>
<div>
<p
class="MsoNormal">Thank
you, Adrian,
this is a
great
reference! I
think your
annotations
make sense as
well, things
should map
pretty plainly
to the OAuth
process. The
tricky part
(that we got a
start on
today) is
going to be
the scopes
bits and
getting those
right.<br>
<br>
For an UMA
flow, it's
also similar,
except that
the "who can
see it" is a
set of claims
instead of the
client
application.<span
style="color:#888888"><br>
<br>
-- Justin</span></p>
<div>
<div>
<p
class="MsoNormal"
style="margin-bottom:12.0pt"> </p>
<div>
<p
class="MsoNormal">On
8/5/2015 9:12
PM, Adrian
Gropper wrote:</p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<p
class="MsoNormal"
style="margin-bottom:12.0pt">I've attached a very typical Release of
Information
authorization.
I've annotated
the 5 elements
common to all
such documents
that I have
ever seen. The
stuff outside
if the
rectangles is
more or less
optional. </p>
</div>
<p
class="MsoNormal"
style="margin-bottom:12.0pt">This form covers one direction of the
EHR-PHR Use
Case. It is
presented to
the Custodian
(the patient
or their
designate )
and approved
by them by the
Resource
Server and
pre-filled
with
information
supplied by
the Client, if
available. <br>
<br>
In some cases,
the Client
information is
not available
at the time
the
Authorization
form is
signed. In
that case, it
will be up to
the
Authorization
Server to
consider the
Client and
User
information
and provide
the
authorization
to the
Resource
Server.</p>
</div>
<p
class="MsoNormal"
style="margin-bottom:12.0pt">The Resource Server has the final say in
all cases and
could decide
to ignore the
authorization
based on local
or
jurisdictional
policy. This
is outside the
control of the
Resource Owner
and likely to
be out of
scope for
HEART in all
use-cases.</p>
</div>
<div>
<p
class="MsoNormal">This
ROI
Authorization
Form is the
only "consent"
that I'm aware
of in clinical
IT. Patients
are asked to
sign other
documents,
including:</p>
</div>
<div>
<p
class="MsoNormal">Registration
Form, Notice
of Privacy
Practices, and
Treatment
Consent but
none of these
has anything
to do with
sharing of
health data
(except for
HIPAA TPO
which we will
not get into
here.)</p>
</div>
<div>
<p
class="MsoNormal"> </p>
</div>
<p
class="MsoNormal">Adrian</p>
</div>
<div>
<p
class="MsoNormal"> </p>
<div>
<p
class="MsoNormal">On
Wed, Aug 5,
2015 at 8:27
PM, jim kragh
<<a
moz-do-not-send="true"
href="mailto:kragh65@gmail.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:kragh65@gmail.com">kragh65@gmail.com</a></a>>
wrote:</p>
<div>
<p
class="MsoNormal">Thanks
for
sharing,...
informative
and
constructive
in reaching
the patient
end point. </p>
<div>
<p
class="MsoNormal"> </p>
</div>
<div>
<p
class="MsoNormal">May
all have a
nice evening!</p>
</div>
</div>
<div>
<p
class="MsoNormal"> </p>
<div>
<div>
<div>
<p
class="MsoNormal">On
Wed, Aug 5,
2015 at 3:26
PM, Debbie
Bucci <<a
moz-do-not-send="true"
href="mailto:debbucci@gmail.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:debbucci@gmail.com">debbucci@gmail.com</a></a>>
wrote:</p>
</div>
</div>
<blockquote
style="border:none;border-left:solid
#cccccc
1.0pt;padding:0in
0in 0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<p
class="MsoNormal">Attendees:</p>
</div>
<div>
<p
class="MsoNormal">Eve
Maler</p>
</div>
<div>
<p
class="MsoNormal">Justin
Richer</p>
</div>
<div>
<p
class="MsoNormal">Josh
Mandel</p>
</div>
<div>
<p
class="MsoNormal">Adrian
Gropper</p>
</div>
<div>
<p
class="MsoNormal">Thomas
Sullivan </p>
</div>
<div>
<p
class="MsoNormal">Debbie
Bucci</p>
</div>
<div>
<p
class="MsoNormal"> </p>
</div>
<div>
<p
class="MsoNormal">We
have decided
to delineate
between
mechanical and
semantic scope
docs.</p>
</div>
<div>
<p
class="MsoNormal"> </p>
</div>
<div>
<p
class="MsoNormal">For
the PCP
<-> PHR
use case:</p>
</div>
<div>
<p
class="MsoNormal"> </p>
</div>
<div>
<p
class="MsoNormal">The
pre determined
choice token
confidential
token choice
and exactly
what
information
needs (example:
PHR's authorization
endpoint) to
be shared in
advance
between the
PCP's EHR and
Alice's PCP
was left out
of the
discussion for
now.</p>
</div>
<div>
<p
class="MsoNormal"> </p>
</div>
<div>
<p
class="MsoNormal">There
is one
basic mechanical
Oauth generic
flow that
occurs twice
in the use
case.</p>
</div>
<div>
<p
class="MsoNormal"> </p>
</div>
<div>
<p
class="MsoNormal">Given
the group has
generally
agreed that
the SMART
specifications
are a good
place to <strong><i>start
</i></strong><em>...
</em>for this
particular use
case the only
semantic FHIR
scope that is
necessary is
the
patient/*.read
scope that
grants
permission to
read any
resource for
the current
patient.</p>
</div>
<div>
<p
class="MsoNormal"> </p>
</div>
<div>
<p
class="MsoNormal">During
the
registration
process Alice
should be able
to select at a
fine grain
level which
resources she
is willing to
share with the
PHR. This
mimic's a
specific
process
- Adrian
please
provide. This
information
will be used
to generate
the access
token.</p>
</div>
<div>
<p
class="MsoNormal"> </p>
</div>
<div>
<p
class="MsoNormal">The
one thing left
at the end of
the discussion
is whether the
patient record
is implicit or
explicitly
stated. This
is a design
decision that
may make a
difference as
we move
towards our
next use case
in
which delegation
is a factor.</p>
</div>
<div>
<p
class="MsoNormal"> </p>
</div>
<div>
<p
class="MsoNormal">Corrections/updates
appreciated.
</p>
</div>
<div>
<p
class="MsoNormal"> </p>
</div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
<pre> </pre>
</blockquote>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
<p
class="MsoNormal"
style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
Openid-specs-heart
mailing list<br>
<a
moz-do-not-send="true"
href="mailto:Openid-specs-heart@lists.openid.net" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a></a><br>
<a
moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=QPfpP6tNPhNn0uCYFnfBuRqSH5IVEwKw_Jqp3j4NGRQ&s=rCzIAK2qBPKQaibR7Ns2AF69bEcf2hFBrgPF6wgZ0i4&e="
target="_blank"><a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-heart">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a></a></p>
</div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<br>
-- </p>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
<div>
<p
class="MsoNormal">Adrian
Gropper MD<br>
<br>
<span
style="font-family:"Arial","sans-serif";color:#1f497d">RESTORE
Health
Privacy!<br>
HELP us fight
for the right
to control
personal
health data.<br>
DONATE: <a
moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=QPfpP6tNPhNn0uCYFnfBuRqSH5IVEwKw_Jqp3j4NGRQ&s=5EO5dh5y1O7CjbbjqdwxTBcdii8ABtLHO2waj3VDYfw&e="
target="_blank"><span style="color:#0563c1"><a class="moz-txt-link-freetext" href="http://patientprivacyrights.org/donate-2/">http://patientprivacyrights.org/donate-2/</a></span></a></span>
</p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"
style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a moz-do-not-send="true"
href="mailto:Openid-specs-heart@lists.openid.net"
target="_blank">Openid-specs-heart@lists.openid.net</a><br>
<a moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=cpoRMhQHerIlja_ffVTQNKS7xUf9tRDFgogzkp23Ycs&s=xfS-FhCWnt8T2azGqiQ9w0j0r8gsr_Wq5e1DFqr6j2c&e="
target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a></p>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"
style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a moz-do-not-send="true"
href="mailto:Openid-specs-heart@lists.openid.net"
target="_blank">Openid-specs-heart@lists.openid.net</a><br>
<a moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=cpoRMhQHerIlja_ffVTQNKS7xUf9tRDFgogzkp23Ycs&s=xfS-FhCWnt8T2azGqiQ9w0j0r8gsr_Wq5e1DFqr6j2c&e="
target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a></p>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<br>
-- </p>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">Adrian Gropper MD<br>
<br>
<span
style="font-family:"Arial","sans-serif";color:#1f497d">RESTORE
Health Privacy!<br>
HELP us fight for the right to
control personal health data.<br>
DONATE: <a moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=cpoRMhQHerIlja_ffVTQNKS7xUf9tRDFgogzkp23Ycs&s=gMoU7Tc7dOq204V3ITLDRXfW91DvOUFqkOKkdBgG4Y8&e="
target="_blank"><span
style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span>
</p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-heart mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-heart">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a>
</pre>
</blockquote>
<br>
</body>
</html>