<p dir="ltr">Hi Robert</p>
<p dir="ltr">Curious ... is this the same for a provider that do not have access to the PACS internal system? <br><br></p>
<div class="gmail_quote">On Aug 4, 2016 3:46 PM, "Robert Horn" <<a href="mailto:robert.horn@agfa.com">robert.horn@agfa.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font size="2" face="sans-serif">As a specific example, the normal practice
in radiology is that while the patient's images (X-ray, CT, etc.) will
be available internally from the PACS by network, this option is not made
available to the patient. The patient is offered a CD/DVD with the
DICOM images. These are two completely different technical mechanisms.
HIPAA is entirely satisfied. The internal use and external delivery
need not be the same mechanisms.</font>
<br>
<br><font size="2" face="sans-serif">The CD/DVD has full fidelity complete
DICOM images, and the interoperability of these media is excellent. There
are annual connectathons, plus other verification. The feed back
that I have from tertiary hospitals (where the patient frequently arrives
carrying their DVDs) is that well over 95% of external media are useable.
The primary issue is physical damage to the media due to poor storage.</font>
<br>
<br><font size="2" face="sans-serif">This system is well established now,
with 300-500 million DVDs being delivered annually around the world.</font>
<br>
<br><font size="2" face="sans-serif">It also reflects a very different set
of tradeoffs and expectations than the network centric discussions here.
With media the patient has total control and complete responsibility
for proper security and storage. There are advantages, in that there
is no infrastructural or organizational barrier to patient access and patient
makes all decisions about what to share and with whom. It has become
the norm for the patient to bring their images to a selected provider as
part of the admission process. (A chronic patient can easily
accumulate 100+ GBytes of images. Delivering these by DVD is often
more convenient than managing the huge network transfers.)</font>
<br>
<br><font size="2" face="sans-serif">There are also disadvantages. Many patients
are unable to provide proper security and storage for their DVDs.</font>
<br><font size="2" face="sans-serif"><br>
Kind Regards,<br>
</font><font size="2" face="Verdana"><b><br>
Robert Horn | </b></font><font size="2" color="red" face="Verdana"><b>Agfa
HealthCare</b></font><font size="1" face="Verdana"><br>
Interoperability Architect | HE/Technology Office<br>
T <a href="tel:%2B1%20978%20897%204860" value="+19788974860" target="_blank">+1 978 897 4860</a><br>
<br>
Agfa HealthCare Corporation, Gotham Parkway 580, Carlstadt, NJ 07072-2405,
USA</font><font size="1" color="#8f8f8f" face="Verdana"><br>
</font><a href="http://www.agfahealthcare.com/" target="_blank"><font size="1" color="#8f8f8f" face="Verdana">http://www.agfahealthcare.com</font></a><font size="1" color="#8f8f8f" face="Verdana"><br>
</font><a href="http://blog.agfahealthcare.com/" target="_blank"><font size="1" color="#8f8f8f" face="Verdana">http://blog.agfahealthcare.com</font></a><font size="1" face="Verdana"><br>
</font>
<hr><font size="1" face="Verdana">Click on link to read important disclaimer:
</font><a href="http://www.agfahealthcare.com/maildisclaimer" target="_blank"><font size="1" color="#8f8f8f" face="Verdana">http://www.agfahealthcare.com/<wbr>maildisclaimer</font></a><font size="3">
</font>
<br>
<br>
<br>
<br><font size="1" color="#5f5f5f" face="sans-serif">From:
</font><font size="1" face="sans-serif">"Aaron Seib, NATE"
<<a href="mailto:aaron.seib@nate-trust.org" target="_blank">aaron.seib@nate-trust.org</a>></font>
<br><font size="1" color="#5f5f5f" face="sans-serif">To:
</font><font size="1" face="sans-serif">"'Adrian Gropper'"
<<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>></font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Cc:
</font><font size="1" face="sans-serif"><a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.<wbr>openid.net</a></font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Date:
</font><font size="1" face="sans-serif">08/03/2016 10:58 AM</font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Subject:
</font><font size="1" face="sans-serif">Re: [Openid-specs-heart]
Alice's health resource set</font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Sent by:
</font><font size="1" face="sans-serif">"Openid-specs-heart"
<<a href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank">openid-specs-heart-bounces@<wbr>lists.openid.net</a>></font>
<br>
<hr noshade>
<br>
<br>
<br><font size="2" color="#004080" face="Calibri">Good.</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">Before I jump into responding
to your summary I think it would be helpful to unpack the statement you
make about the other important aspect of HIPAA that is relevant.</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">Below, where you say:</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="3" face="Symbol">· </font><font size="3" face="Times New Roman">“when
a HIPAA Covered Entity (e.g. typical EHR) has an electronic means for sharing
data available, it MUST offer that method to the patient as well. This
means that if FHIR is used for sharing data under TPO, regardless of what
the NPP say or don't say, Alice has a HIPAA right to request her data on
FHIR.”</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="2" color="#004080" face="Calibri">I think this is in the right
vein but is imprecise and if we are going to make any progress we have
to be more precise – if those on this thread are having a hard time parsing
what is said we can be sure external stakeholders think we are talking
gibberish.</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">This ascertain “When a HIPAA
Covered Entity (CE) has an electronic means of sharing data it must offer
that method to the patient as well.” is a reasonable sound bite but I
think since some of the folks that are part of this work group are relatively
healthcare neophytes and it would be valuable to unpack that a bit because
there are two qualifiers under HIPAA for covered entities..</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">The two qualifiers that apply
from HIPAA are “readily producible” and the notion that the discloser
is not required to do anything that would expose their system to additional
risk. We shouldn’t gloss over these pre-conditions because I think
it will only result in heart-ache and disappointment for those who set
their expectations on the notion that ‘if they can do it with providers
they should be able to do it with consumers’. I agree that this
is the intuitive expectation but there is enough wiggle room in the preconditions
to pass a container ship through and if we are serious about making progress
we need to figure out how to address or constrain the qualifiers IMHO.</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">If our work doesn’t address
what it means for a consumer facing disclosure to be readily producible
in a way that does not expose the RS to new security risks we will be creating
a false expectation on the part of the families that are depending on us
to get this right – so for me I feel we have a responsibility to speak
to it.</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">Adrian – I am not trying
to say that you meant to side step these qualifiers in any way – but I
think it is important for us to document them somewhere as part of the
preconditions that need to be true before we create inaccurate expectations.
Like the policy related issues that Oliver was bringing to the table yesterday
– I think it is important for a technical only solution to point out these
“policy” constraints so that we don’t fool ourselves into thinking we
solved the problem of patient access without actually solving anything.</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">This is the way that I simplify
it so that I can keep it straight. I welcome everyones feedback.</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">I believe that in the real
world the API’s that will be exposed to extra-enterprise users (other
providers, consumers and the apps that either give authority to act on
their behalf) are going to be striated by the type of user accessing them.
I believe this is true because the applicable law differs based on whether
the API is being used by a Covered Entity or a Patient or by Joe’s Credit
Worthiness algorythm or what have you. I may have an API that I expose
that allows a provider to use an API that provides all the clincal data
I have for a patient based on a partial match search criteria. Because
I know that theprovider is also covered by HIPAA and should have a policy
about what they do when they see PHI for someone they shouldn’t I may
feel that the risk is tenable (this is what RLS based HIE relies on in
some ways). I can’t expose this same API to a patient\consumer because
I have an obligation to prevent non-professionals from inadvertently (allegedly)
seeing the data of others. </font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">I am not trying to be a nay-sayer
– I just think it is important that we don’t gloss over these facts of
life before we have documented them and – as John M. said earlier last
week clearly delineated what is in scope and what is out.</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">Before an API that exposes
FHIR Resources (and possibly resource sets or scopes of same such as ‘Immunization’)
to a consumer they need to have some reason to believe that the remote
system accessing the API has a right to see the PHI of the subject of the
PHI that is being disclosed.</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">In the Direct world we rely
on the face-to-face encounter of the consumer and the Provider to associate
consumer’s Direct Address with the right medical records held by the Provider.
For the API task force we made reference to the use of the patient portal
and its authentication of the remote user (conditioned on there being an
encounter between the Family Caregiver or Patient first) to allow access
to the appropriate PHI for the person who authenticated into the portal.
There is still some <b>magic</b> that we assume exist that allows the consumer’s
chosen Client to receive a token from the EMR before we even start talking
about the rest of the workflow and perhaps that is a gap we can address
but I don’t know if anyone has gottent to the point of actually doing
this yet – does anyone know? Does SMART or the Argonauts have a
solution for this already or are we all relying on the same magic to occur?</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">I think it is at this point
– after the consumer has authenticated into the Patient Portal of the
EMR – that you could realistically start to talk about binding a consumers
chosen AS to the data held by a CE. Just like we have proposed for
allowing a user to supply their Direct Address I assume that a widget on
the portal could be provided that allowed the patient to navigate to the
URL for their chosen AS – is that true? Let me assume that this
is how the RS can find out what the consumer’s prefered AS is for the
sake of getting my head around this. There may be equivalents that
emerge in the future but I think this is probably the shortest path to
getting things off the ground and running in the current eco-system.
(If a user doesn’t provide a preferred AS the Provider would be expected
to comply with applicable law and where law allows them to decide their
local policy decisions).</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">At least for me I have to
picture a realistic path to getting to your bulleted list below before
I can respond in line as follows…</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="3" face="Times New Roman">a) All resources </font><a href="#m_-4742296256565409933__msocom_1"><font size="1" color="blue" face="Times New Roman"><u>[AS1]</u></font></a><font size="1" face="Times New Roman">
</font><font size="3" face="Times New Roman">available as FHIR resources
MUST also be provided for registration with a HEART resource server even
if the RS decides to bypass the AS or override the AS authorization. </font>
<br><font size="3" face="Times New Roman"> a1) The HIPAA CE can
choose to notify the patient as to whether they bypass or override in the
NPP but it makes only a slight difference</font><a href="#m_-4742296256565409933__msocom_2"><font size="1" color="blue" face="Times New Roman"><u>[AS2]</u></font></a><font size="1" face="Times New Roman">
</font><font size="3" face="Times New Roman">.</font>
<br><font size="3" face="Times New Roman">b) HIPAA has a data minimization
requirement for some transactions that don't strictly require patient authorization
so HEART MAY want to consider how data minimization would be handled using
scopes in the cases where an RS is using a HEART AS for all sharing. <br>
b1) In theory, a HIPAA CE could register two paths to the patient's
resources with two separate HEART ASs. One AS would bypass the patient-specified
AS for Clients that were not subject to patient authorization. The other
AS would be specified by the patient. Maybe this is the kind of thing Justin
has in mind when he talks of an RS buying an AS from a separate vendor.</font><a href="#m_-4742296256565409933__msocom_3"><font size="1" color="blue" face="Times New Roman"><u>[AS3]</u></font></a><font size="1" face="Times New Roman">
</font>
<br><font size="3" face="Times New Roman">c) Any resource server, HIPAA covered
or not, MAY choose to register sets of resources in order to improve the
user experience at the AS. These resources may or may not all be specified
by FHIR. These bundling and definition of these resource sets may be done
by HEART or by standards organizations like the HL7 DAF. (Debbie says that
HEART must use only accepted standards so it seems to me that HEART getting
into the resource bundling business is a bit of a slippery slope</font><a href="#m_-4742296256565409933__msocom_4"><font size="1" color="blue" face="Times New Roman"><u>[AS4]</u></font></a><font size="1" face="Times New Roman">
</font>
<br><font size="2" color="#004080" face="Calibri">I may be wasting my breath
but I am concerned that the real nay-sayers in the eco-system are well
supported when they say what we are talking about is unintelligible to
them.</font>
<br><font size="2" color="#004080" face="Calibri">I could be completely off
base and all of these assumptions are documented and I need to do more
homework but I am feeling beat up trying to assert that there is some there
there when doubters ask me about HEART.</font>
<br><font size="2" color="#004080" face="Calibri">If I am alone I will remove
myself from the list serve and you guys can continue in peace without me.</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">Aaron Seib, CEO</font>
<br><font size="2" color="#004080" face="Calibri">@CaptBlueButton </font>
<br><font size="2" color="#004080" face="Calibri"> (o) <a href="tel:301-540-2311" value="+13015402311" target="_blank">301-540-2311</a></font>
<br><font size="2" color="#004080" face="Calibri">(m) <a href="tel:301-326-6843" value="+13013266843" target="_blank">301-326-6843</a></font>
<br><a href="http://nate-trust.org" target="_blank"><img src="cid:_2_0D9B4FAC0D9B4C4C0063D63885258005" alt="cid:image001.jpg@01D10761.5BE2FE00" style="border:0px solid"></a>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" face="Tahoma"><b>From:</b> <a href="mailto:agropper@gmail.com" target="_blank">agropper@gmail.com</a> [</font><a href="mailto:agropper@gmail.com" target="_blank"><font size="2" face="Tahoma">mailto:agropper@gmail.com</font></a><font size="2" face="Tahoma">]
<b>On Behalf Of </b>Adrian Gropper<b><br>
Sent:</b> Wednesday, August 3, 2016 9:35 AM<b><br>
To:</b> Aaron Seib, NATE<b><br>
Cc:</b> Maxwell, Jeremy (OS/OCPO); <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.<wbr>openid.net</a><b><br>
Subject:</b> Re: [Openid-specs-heart] Alice's health resource set</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">Aaron,</font>
<br><font size="3" face="Times New Roman">I think you are accurately describing
HIPAA and that should allow us to re-center this thread on the core subject
of Alice's resources. </font>
<br><font size="3" face="Times New Roman">The key point for this thread is
that HEART needs to enable patient-directed exchange for the full set of
FHIR resources with other subsets as options. The reasons for this include
the fact that some providers will choose to differentiate themselves by
giving the patient a voice in sharing for Treatment, Payment, and Operations
even though HIPAA does not force them to do so.</font>
<br><font size="3" face="Times New Roman">The other important aspect of HIPAA
that has not been discussed yet is that when a HIPAA Covered Entity (e.g.
typical EHR) has an electronic means for sharing data available, it MUST
offer that method to the patient as well. This means that if FHIR is used
for sharing data under TPO, regardless of what the NPP say or don't say,
Alice has a HIPAA right to request her data on FHIR.</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">Here's my summary of the discussion
AND HIPAA as far as HEART is concerned:</font>
<br><font size="3" face="Times New Roman">a) All resources available as FHIR
resources MUST also be provided for registration with a HEART resource
server even if the RS decides to bypass the AS or override the AS authorization.
</font>
<br><font size="3" face="Times New Roman"> a1) The HIPAA CE can
choose to notify the patient as to whether they bypass or override in the
NPP but it makes only a slight difference.</font>
<br><font size="3" face="Times New Roman">b) HIPAA has a data minimization
requirement for some transactions that don't strictly require patient authorization
so HEART MAY want to consider how data minimization would be handled using
scopes in the cases where an RS is using a HEART AS for all sharing. <br>
b1) In theory, a HIPAA CE could register two paths to the patient's
resources with two separate HEART ASs. One AS would bypass the patient-specified
AS for Clients that were not subject to patient authorization. The other
AS would be specified by the patient. Maybe this is the kind of thing Justin
has in mind when he talks of an RS buying an AS from a separate vendor.</font>
<br><font size="3" face="Times New Roman">c) Any resource server, HIPAA covered
or not, MAY choose to register sets of resources in order to improve the
user experience at the AS. These resources may or may not all be specified
by FHIR. These bundling and definition of these resource sets may be done
by HEART or by standards organizations like the HL7 DAF. (Debbie says that
HEART must use only accepted standards so it seems to me that HEART getting
into the resource bundling business is a bit of a slippery slope.)</font>
<br><font size="3" face="Times New Roman">A MUST and two MAYs. Can we move
on to discussing scopes in this context now?</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">Adrian</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">On Wed, Aug 3, 2016 at 7:48 AM,
Aaron Seib, NATE <</font><a href="mailto:aaron.seib@nate-trust.org" target="_blank"><font size="3" color="blue" face="Times New Roman"><u>aaron.seib@nate-trust.org</u></font></a><font size="3" face="Times New Roman">>
wrote:</font>
<br><font size="2" color="#004080" face="Calibri">Regardless of how it makes
me feel – my question earlier is how do we actually address it.</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">I think the NPP is one way
for providers to convey that they will or won’t acknowledge what your
Privacy Preferences are – indicated via a AS.</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">Does anyone disagree with
that? </font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">There are providers that
will argue that they have an ethical responsibility to share with other
doctors that may treat you.</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">My question comes down to
– is a provider obligated to share for Treatment purposes or is it just
that they are permitted to despite a patient like Adrian’s preferences.</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">Anyone have an authoritative
answer?</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri">Aaron Seib, CEO</font>
<br><font size="2" color="#004080" face="Calibri">@CaptBlueButton </font>
<br><font size="2" color="#004080" face="Calibri"> (o) </font><a href="tel:301-540-2311" target="_blank"><font size="2" color="blue" face="Calibri"><u>301-540-2311</u></font></a>
<br><font size="2" color="#004080" face="Calibri">(m) </font><a href="tel:301-326-6843" target="_blank"><font size="2" color="blue" face="Calibri"><u>301-326-6843</u></font></a>
<br><a href="http://nate-trust.org/" target="_blank"><img src="cid:_2_0D9AE7240D9AE3C40063D63885258005" alt="cid:image001.jpg@01D10761.5BE2FE00" style="border:0px solid"></a>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" face="Tahoma"><b>From:</b> Openid-specs-heart [mailto:</font><a href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank"><font size="2" color="blue" face="Tahoma"><u>openid-specs-heart-<wbr>bounces@lists.openid.net</u></font></a><font size="2" face="Tahoma">]
<b>On Behalf Of </b>Adrian Gropper<b><br>
Sent:</b> Tuesday, August 2, 2016 5:27 PM<b><br>
To:</b> Maxwell, Jeremy (OS/OCPO)<b><br>
Cc:</b> </font><a href="mailto:openid-specs-heart@lists.openid.net" target="_blank"><font size="2" color="blue" face="Tahoma"><u>openid-specs-heart@lists.<wbr>openid.net</u></font></a>
<br><font size="3" face="Times New Roman"><b><br>
Subject:</b> Re: [Openid-specs-heart] Alice's health resource set</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">If an organization wants to be
nice to their patients and also reduce the scope of data breaches they
would notify patients when their data was shared the way my bank and Apple
do when they use my data in a third-party context. We can hope that FHIR
and HEART become so much standard practice that every respectful organization
adopts the Society for Participatory Medicine motto: "Nothing about
me without me." </font>
<br><font size="3" face="Times New Roman">The "consent for TPO"
you seem to be describing however is just another contract of adhesion
that gives no meaningful choice to the patient at all. I, for one, am insulted
when presented by such a thing and I've never met any patient that appreciates
it.</font>
<br><font size="3" face="Times New Roman">Adrian</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">On Tue, Aug 2, 2016 at 5:12 PM,
Maxwell, Jeremy (OS/OCPO) <</font><a href="mailto:Jeremy.Maxwell@hhs.gov" target="_blank"><font size="3" color="blue" face="Times New Roman"><u>Jeremy.Maxwell@hhs.gov</u></font></a><font size="3" face="Times New Roman">>
wrote:</font>
<br><font size="2" color="#004080" face="Calibri">Not sure I follow. HIPAA
does not require consent for TPO—it is a permitted use. An organization
may still choose to collect consent for TPO, either because of their own
organizational policy or because another law requires it. But this
is not “HIPAA TPO consent.” In ONC parlance, we call this “basic
choice for TPO” in both our Interoperability Roadmap as well as our Patient
Choice Technical Project. Of course others may call this by a different
term, but calling it a “HIPAA TPO consent” is imprecise and can perpetuate
existing misunderstandings about what HIPAA actually requires.</font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" color="#004080" face="Calibri"> </font>
<br><font size="2" face="Tahoma"><b>From:</b> </font><a href="mailto:agropper@gmail.com" target="_blank"><font size="2" color="blue" face="Tahoma"><u>agropper@gmail.com</u></font></a><font size="2" face="Tahoma">
[mailto:</font><a href="mailto:agropper@gmail.com" target="_blank"><font size="2" color="blue" face="Tahoma"><u>agropper@gmail.com</u></font></a><font size="2" face="Tahoma">]
<b>On Behalf Of </b>Adrian Gropper<b><br>
Sent:</b> Tuesday, August 02, 2016 5:01 PM<b><br>
To:</b> Maxwell, Jeremy (OS/OCPO)<b><br>
Cc:</b> Debbie Bucci; </font><a href="mailto:openid-specs-heart@lists.openid.net" target="_blank"><font size="2" color="blue" face="Tahoma"><u>openid-specs-heart@lists.<wbr>openid.net</u></font></a><font size="2" face="Tahoma"><b><br>
Subject:</b> Re: [Openid-specs-heart] Alice's health resource set</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">Jeremy, <br>
<br>
Sorry, I should have said HIPAA TPO "consent".</font>
<br><font size="3" face="Times New Roman">If access to the FHIR resources
does not require Alice's authorization and the RS wants to keep Alice in
the dark because HIPAA's accounting of disclosures is seldom implemented
as well, then HEART is not involved. I would not call the TPO loophole
consent except sarcastically.</font>
<br><font size="3" face="Times New Roman">Adrian</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">On Tue, Aug 2, 2016 at 2:22 PM,
Maxwell, Jeremy (OS/OCPO) <</font><a href="mailto:Jeremy.Maxwell@hhs.gov" target="_blank"><font size="3" color="blue" face="Times New Roman"><u>Jeremy.Maxwell@hhs.gov</u></font></a><font size="3" face="Times New Roman">>
wrote:</font>
<p><font size="2" color="#004080" face="Calibri">Also, want to clarify what
“typical of HIPAA TPO consent” means? TPO is a permitted use under
HIPAA that does not require consent.</font>
<p><font size="2" color="#004080" face="Calibri"> </font>
<p><font size="2" color="#004080" face="Calibri"> </font>
<p><font size="2" color="#004080" face="Calibri"> </font>
<p><font size="2" face="Tahoma"><b>From:</b> Openid-specs-heart [mailto:</font><a href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank"><font size="2" color="blue" face="Tahoma"><u>openid-specs-heart-<wbr>bounces@lists.openid.net</u></font></a><font size="2" face="Tahoma">]
<b>On Behalf Of </b>Debbie Bucci<b><br>
Sent:</b> Tuesday, August 02, 2016 2:17 PM<b><br>
To:</b> Adrian Gropper<b><br>
Cc:</b> </font><a href="mailto:openid-specs-heart@lists.openid.net" target="_blank"><font size="2" color="blue" face="Tahoma"><u>openid-specs-heart@lists.<wbr>openid.net</u></font></a><font size="2" face="Tahoma"><b><br>
Subject:</b> Re: [Openid-specs-heart] Alice's health resource set</font>
<p><font size="3" face="Times New Roman"> </font>
<p><font size="3" face="Times New Roman">Lost me again Adrian - </font>
<p><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">We should also not ignore the Client-to-AS
first flow. This is the preferred flow from a privacy engineering perspective.
(see other thread with Justin). In the majority of cases of HIE, the Client
has a relationship with Alice already (this is typical of HIPAA TPO consent)
or the Client has found Alice via a "Relationship Locator Service"
which is a directory operated by the state or some private entity like
CommonWell. When the Client matches with Alice in the RLS, does the RLS
return a list of RSs or a pointer to Alice's AS?</font>
<p><font size="3" face="Times New Roman"> </font>
<p><font size="3" face="Times New Roman">The most privacy-preserving thing
would be for RLSs to return pointers to Alice's AS and in the future this
is what Alice might insist on if she is still given a choice to opt-in
or opt-out of HIE. Alice does have that choice today in the US. In other
countries, not-so-much.</font>
<p><font size="3" face="Times New Roman"> </font>
<p><font size="3" face="Times New Roman"> Are you suggesting the AS
is some sort of proxy for all data - I don't think you were saying that.
At some point the Client would need a relationship with the RS as
well - correct? Is the Client to AS flow a separate spec? Would
you please provide the link? Looking at UMA 1.01 - client needs
a permission ticket first - that is generated from AS - to RS to client
(?)</font>
<p><font size="3" face="Times New Roman"> </font>
<p><font size="3" face="Times New Roman"> </font>
<p><font size="3" face="Times New Roman"> </font>
<p><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman"><br>
<br>
<br>
-- </font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">Adrian Gropper MD<br>
</font><font size="3" color="#004080" face="Arial"><br>
PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>
HELP us fight for the right to control personal health data.<br>
DONATE: </font><a href="http://patientprivacyrights.org/donate-2/" target="_blank"><font size="3" color="#0082bf" face="Arial"><u>http://patientprivacyrights.<wbr>org/donate-2/</u></font></a><font size="3" face="Times New Roman">
</font>
<br><font size="3" face="Times New Roman"><br>
<br>
<br>
-- </font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">Adrian Gropper MD<br>
</font><font size="3" color="#004080" face="Arial"><br>
PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>
HELP us fight for the right to control personal health data.<br>
DONATE: </font><a href="http://patientprivacyrights.org/donate-2/" target="_blank"><font size="3" color="#0082bf" face="Arial"><u>http://patientprivacyrights.<wbr>org/donate-2/</u></font></a><font size="3" face="Times New Roman">
</font>
<br><font size="3" face="Times New Roman"><br>
<br>
<br>
-- </font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="Times New Roman">Adrian Gropper MD<br>
</font><font size="3" color="#004080" face="Arial"><br>
PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>
HELP us fight for the right to control personal health data.<br>
DONATE: </font><a href="http://patientprivacyrights.org/donate-2/" target="_blank"><font size="3" color="#0082bf" face="Arial"><u>http://patientprivacyrights.<wbr>org/donate-2/</u></font></a><font size="3" face="Times New Roman">
</font>
<p>
<hr>
<br><a name="m_-4742296256565409933__msocom_1"></a><font size="1" face="Times New Roman"> </font><a href="#m_-4742296256565409933__msoanchor_1"><font size="1" color="blue" face="Times New Roman"><u>[AS1]</u></font></a><font size="2" face="Times New Roman">This
is inaccurate. There may well be FHIR resources that describe the
availability of a hospital asset (lets’ say an Operating Room) one day.
An API that can access a resource that knows when an OR is in use is very
useful to the Enterprise users but there is no reason that this should
be shared with a Consumer. </font>
<br><font size="2" face="Times New Roman"> </font>
<br><font size="2" face="Times New Roman">I think you have to qualify what
you are saying here to be All resources that are specific to the consumer’s
care – I think HIPAA has a term for it – something like the Common Data
Set. </font>
<br><font size="2" face="Times New Roman"> </font>
<br><font size="2" face="Times New Roman">Being inaccurate here will just
degrade the audiences ability to know what we are really saying here.</font>
<br><font size="2" face="Times New Roman"> </font>
<br><font size="2" face="Times New Roman">The RS would be able to decide
if they need to check the AS based on whether or not the resource set had
data that was part of the Common Data Set (if they were committed to supporting
the patient’s preferences).</font>
<br><a name="m_-4742296256565409933__msocom_2"></a><font size="1" face="Times New Roman"> </font><a href="#m_-4742296256565409933__msoanchor_2"><font size="1" color="blue" face="Times New Roman"><u>[AS2]</u></font></a><font size="1" face="Times New Roman">T</font><font size="2" face="Times New Roman">hese
kind of qualitative subjective opinions will only frustrate the audience.
It may be slight to you but it may be mission critical so some Foster Parents
who need to explain to the state why their ward’s private health information
was still shared even though the Judge ordered them to take steps necessary
to ensure that it wasn’t.</font>
<br><a name="m_-4742296256565409933__msocom_3"></a><font size="1" face="Times New Roman"> </font><a href="#m_-4742296256565409933__msoanchor_3"><font size="1" color="blue" face="Times New Roman"><u>[AS3]</u></font></a><font size="2" face="Times New Roman">I
think this is a horrible idea. I think there are better ways to handle
policy enforcement when the Client isn’t subject to the AS.</font>
<br><font size="2" face="Times New Roman"> </font>
<br><font size="2" face="Times New Roman">Ken Salyard’s work comes to mind.
I think trying to do it this way is possible but it seems like we are treating
every Policy Enforcement need like it is a nail. Sometimes a Philips
Head is what you should really be using.</font>
<br><a name="m_-4742296256565409933__msocom_4"></a><font size="1" face="Times New Roman"> </font><a href="#m_-4742296256565409933__msoanchor_4"><font size="1" color="blue" face="Times New Roman"><u>[AS4]</u></font></a><font size="2" face="Times New Roman">I
don’t know if this is right or wrong but I do know that I am going insane
talking about this in the abstract and even if it is just for discussion
purposes – in my opinion - we are on the right track trying to find a
reference case like Immunization or the Patient Registration example.
The simpler the better in my opinion.</font><tt><font size="2">______________________<wbr>_________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.<wbr>openid.net</a><br>
</font></tt><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank"><tt><font size="2">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>heart</font></tt></a><tt><font size="2"><br>
</font></tt>
<br>
</p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p><br>______________________________<wbr>_________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.<wbr>openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>heart</a><br>
<br></blockquote></div>