<font size=2 face="sans-serif">Adrain, I was asked about what is the state
of affairs, not about hopes for the future. I think understanding
what is happening now is crucial. Changes should be improvements,
not merely different. What we've already accomplished should not
be lost.</font>
<br>
<br><font size=2 face="sans-serif">I reacted to the incorrect claim that
patients should have the same access as physicians. I'm in the unusual
position of having access to the latest fanciest workstations, and also
helping friends and family with their radiology records. The DVD
with a FLOSS viewer is actually more in tune with the patient functional
needs than those workstations and archives, although I do wish I had those
display systems on my personal computer.</font>
<br>
<br><font size=2 face="sans-serif">As for security methods, you're reacting
to a mis-understanding of security systems. We are moving to multi-layered
defense in depth, with internal separation of systems and function, and
with internal security partitioning. In that environment you see
much more use of portals, functional isolation, partitioned independent
systems, etc. In that environment systems fully trust no one, and
all access grants funnel through functional isolation channels. It's
a more challenging system design world. Portals make it easier because
they can enforce a simpler logic: "Only transactions that perform
function X are allowed through this portal. All other access attempts
indicate potential hostile activity." It makes access controls
like OAuth easier, since they only need to deal with individual functional
subsets. I expect that a portal will cheerfully refuse to perform
functions authorized by an OAuth transaction but not consistent with the
portal function. And it will likely flag a potential hostile penetration
of the external systems.</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 +1 978 897 4860<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/><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/><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><font size=1 color=#8f8f8f face="Verdana">http://www.agfahealthcare.com/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">Adrian Gropper <agropper@healthurl.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">Robert Horn/MOPOO/AGFA@AGFA</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">"debbucci@gmail.com"
<debbucci@gmail.com>, "openid-specs-heart@lists.openid.net"
<openid-specs-heart@lists.openid.net></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">08/05/2016 06:52 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">agropper@gmail.com</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3>Hi Robert,</font>
<br>
<br><font size=3>We've known each other in the imaging PACS standards
business for maybe 20 years and I completely disagree with you from two
perspectives: performance and security. Doctors deserve the same image
speed and quality no matter where they are. The imaging network doesn't
stop at some firewall of the imaging center. Second, the security has to
accommodate tablets and other personal devices that are owned by the physician
and the patient. Perimeter defenses around some hospital silo are less
important day-by-day. Eve calls it the "hard shell, soft center"
defense approach.</font>
<br>
<br><font size=3>At one of the venerable PACS businesses I worked
relatively recently the project was to secure and stream high performance
imaging under the protection of standard OAuth. There's no particular reason,
HIPAA or global, why streaming an imaging study in the order the physician
wants to review it is any different from streaming the genome or the health
record in the OAuth Client's chosen order. Visualize telemedicine.</font>
<br>
<br><font size=3>Adrian<br>
<br>
On Thursday, August 4, 2016, Robert Horn <</font><a href=mailto:robert.horn@agfa.com><font size=3 color=blue><u>robert.horn@agfa.com</u></font></a><font size=3>>
wrote:</font>
<br><font size=2 face="sans-serif">If I understand correctly the answer
is "it depends".</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
Almost all tertiary providers are well prepared to handle DVDs as part
of admission. This is sometimes the case with primary and secondary
providers. All it takes is some software, a DVD reader, and simple
procedures. There is an IHE profile that gets routinely tested at
connectathon for integrating this process into the internal PACS facility
at the provider. This is the default baseline process, since it can
handle admissions from anywhere in the world, regardless of network connectivity
or capacity issues.</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
There are also many directly negotiated inter-ties that go from PACS to
PACS between providers. The primary barrier that I've seen to these
inter-ties is the substantial administrative costs of setup. The
operational PACS is a highly sensitive bit of equipment from much more
than the privacy point of view. Interference with the PACS can bring
radiology, cardiology, radiation therapy, and pathology to a grinding halt.
So the administrative staff is very cautious about connections to the outside.
They will happily use privacy, security, and any other buzzword as part
of their justification for extreme caution about outside connections.</font><font size=3>
<br>
</font><font size=2 face="sans-serif"><br>
These sorts of connections certainly exist. In large networks like
Kaiser or the UK NHS there is a hierarchy of PACS archives, etc.
There are many such connections between affiliated organizations. These
are typically designed to withstand network outages, provide redundancy,
etc. The NHS has all the database recovery issues to deal with split
system operation restoration for patients that have been treated on both
sides of a split system, with the resultant mutual contradictory information
that needs to be reconciled and combined properly. They do not expect
to maintain continuous network connectivity between all NHS sites at all
times. They expect significant connectivity failures and build in
the ability to ride through them.</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
Privacy, consent, and security are all part of the administrative concerns
that do need to be addressed as part of such an inter-tie. It's one
reason things like OpenID are interesting. When connections exist
there needs to be a way to bridge between the internal privacy and security
models of the different organizations. The DVD model is much simpler.
The patient either provides the DVD or they don't. (Realistically,
they always provide the DVDs. It makes no sense to go for treatment
and then refuse to provide the imaging results. Those who don't want
to reveal the imaging data also refuse to go for treatment at that organization.)</font><font size=3>
<br>
</font><font size=2 face="sans-serif"><br>
Extending this kind of connection to the general public terrifies people.
The discussions are all around portals of various sorts, not direct access.
The portals will be given highly limited access to the internal operational
PACS system, so that when the portal is penetrated by a hostile actor,
the hostile actor will not be able to penetrate further. Please note,
it is "when" the portal is penetrated, not "if".
The extent to which the portal presents the appearance of FHIR, DVD, DICOM,
or whatever is a matter of discussion. But the public interaction
would be with the portal, not the internal system.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
<br>
Kind Regards,</font><font size=2 face="Verdana"><b><br>
<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 +1 978 897 4860<br>
<br>
Agfa HealthCare Corporation, Gotham Parkway 580, Carlstadt, NJ 07072-2405,
USA</font><font size=3 color=blue><u><br>
</u></font><a href=http://www.agfahealthcare.com/ target=_blank><font size=1 color=#8f8f8f face="Verdana"><u>http://www.agfahealthcare.com</u></font></a><font size=3 color=blue><u><br>
</u></font><a href=http://blog.agfahealthcare.com/ target=_blank><font size=1 color=#8f8f8f face="Verdana"><u>http://blog.agfahealthcare.com</u></font></a><font size=3><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"><u>http://www.agfahealthcare.com/maildisclaimer</u></font></a><font size=3>
<br>
<br>
<br>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
From: </font><font size=1 face="sans-serif">Debbie
Bucci <</font><a href="javascript:_e(%7B%7D,'cvml','debbucci@gmail.com');" target=_blank><font size=1 color=blue face="sans-serif"><u>debbucci@gmail.com</u></font></a><font size=1 face="sans-serif">></font><font size=3>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
To: </font><font size=1 face="sans-serif">Robert
Horn/MOPOO/AGFA@AGFA</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>
Cc: </font><a href="javascript:_e(%7B%7D,'cvml','openid-specs-heart@lists.openid.net');" target=_blank><font size=1 color=blue face="sans-serif"><u>openid-specs-heart@lists.openid.net</u></font></a><font size=1 face="sans-serif">,
Aaron Seib <</font><a href="javascript:_e(%7B%7D,'cvml','aaron.seib@nate-trust.org');" target=_blank><font size=1 color=blue face="sans-serif"><u>aaron.seib@nate-trust.org</u></font></a><font size=1 face="sans-serif">></font><font size=3>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
Date: </font><font size=1 face="sans-serif">08/04/2016
05:37 PM</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>
Subject: </font><font size=1 face="sans-serif">Re:
[Openid-specs-heart] Alice's health resource set</font><font size=3> <br>
</font>
<hr noshade><font size=3><br>
<br>
<br>
Hi Robert </font>
<br><font size=3>Curious ... is this the same for a provider that do not
have access to the PACS internal system? </font>
<p><font size=3>On Aug 4, 2016 3:46 PM, "Robert Horn" <</font><a href="javascript:_e(%7B%7D,'cvml','robert.horn@agfa.com');" target=_blank><font size=3 color=blue><u>robert.horn@agfa.com</u></font></a><font size=3>>
wrote: </font><font size=2 face="sans-serif"><br>
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><font size=3> </font><font size=2 face="sans-serif"><br>
<br>
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><font size=3> </font><font size=2 face="sans-serif"><br>
<br>
This system is well established now, with 300-500 million DVDs being delivered
annually around the world.</font><font size=3> </font><font size=2 face="sans-serif"><br>
<br>
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><font size=3> </font><font size=2 face="sans-serif"><br>
<br>
There are also disadvantages. Many patients are unable to provide proper
security and storage for their DVDs.</font><font size=3> </font><font size=2 face="sans-serif"><br>
<br>
Kind Regards,</font><font size=2 face="Verdana"><b><br>
<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 </font><a href=tel:%2B1%20978%20897%204860 target=_blank><font size=1 color=blue face="Verdana"><u>+1
978 897 4860</u></font></a><font size=1 face="Verdana"><br>
<br>
Agfa HealthCare Corporation, Gotham Parkway 580, Carlstadt, NJ 07072-2405,
USA</font><font size=3 color=blue><u><br>
</u></font><a href=http://www.agfahealthcare.com/ target=_blank><font size=1 color=#8f8f8f face="Verdana"><u>http://www.agfahealthcare.com</u></font></a><font size=3 color=blue><u><br>
</u></font><a href=http://blog.agfahealthcare.com/ target=_blank><font size=1 color=#8f8f8f face="Verdana"><u>http://blog.agfahealthcare.com</u></font></a>
<br>
<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"><u>http://www.agfahealthcare.com/maildisclaimer</u></font></a><font size=3>
<br>
<br>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
<br>
From: </font><font size=1 face="sans-serif">"Aaron
Seib, NATE" <</font><a href="javascript:_e(%7B%7D,'cvml','aaron.seib@nate-trust.org');" target=_blank><font size=1 color=blue face="sans-serif"><u>aaron.seib@nate-trust.org</u></font></a><font size=1 face="sans-serif">></font><font size=3>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
To: </font><font size=1 face="sans-serif">"'Adrian
Gropper'" <</font><a href="javascript:_e(%7B%7D,'cvml','agropper@healthurl.com');" target=_blank><font size=1 color=blue face="sans-serif"><u>agropper@healthurl.com</u></font></a><font size=1 face="sans-serif">></font><font size=3>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
Cc: </font><a href="javascript:_e(%7B%7D,'cvml','openid-specs-heart@lists.openid.net');" target=_blank><font size=1 color=blue face="sans-serif"><u>openid-specs-heart@lists.openid.net</u></font></a><font size=3>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
Date: </font><font size=1 face="sans-serif">08/03/2016
10:58 AM</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>
Subject: </font><font size=1 face="sans-serif">Re:
[Openid-specs-heart] Alice's health resource set</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>
Sent by: </font><font size=1 face="sans-serif">"Openid-specs-heart"
<</font><a href="javascript:_e(%7B%7D,'cvml','openid-specs-heart-bounces@lists.openid.net');" target=_blank><font size=1 color=blue face="sans-serif"><u>openid-specs-heart-bounces@lists.openid.net</u></font></a><font size=1 face="sans-serif">></font><font size=3>
<br>
</font>
<hr noshade><font size=3><br>
</font><font size=2 color=#004080 face="Calibri"><br>
<br>
Good.</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
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><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
Below, where you say:</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=3 face="Symbol"><br>
· </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><font size=3> </font><font size=3 face="Times New Roman"><br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
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><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
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><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
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><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
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><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
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><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
This is the way that I simplify it so that I can keep it straight.
I welcome everyones feedback.</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
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. <br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
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><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
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><font size=3>
</font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
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><font size=3>
</font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
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><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
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><font size=3>
</font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=3 face="Times New Roman"><br>
a) All resources </font><a href="#m_3516374923822591767_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. <br>
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_3516374923822591767_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><font size=3> </font><font size=3 face="Times New Roman"><br>
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_3516374923822591767_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><font size=3 face="Times New Roman"><br>
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_3516374923822591767_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><font size=2 color=#004080 face="Calibri"><br>
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><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
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><font size=3>
</font><font size=2 color=#004080 face="Calibri"><br>
If I am alone I will remove myself from the list serve and you guys can
continue in peace without me.</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
Aaron Seib, CEO</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
@CaptBlueButton <br>
(o) </font><a href="tel:301-540-2311" target=_blank><font size=2 color=blue face="Calibri"><u>301-540-2311</u></font></a><font size=3>
</font><font size=2 color=#004080 face="Calibri"><br>
(m) </font><a href="tel:301-326-6843" target=_blank><font size=2 color=blue face="Calibri"><u>301-326-6843</u></font></a><font size=3>
</font><font size=3 color=blue><u><br>
</u></font><a href="http://nate-trust.org/" target=_blank><img src=cid:_2_0A1ED77C0A1E80C00054BF0F85258009 alt=cid:image001.jpg@01D10761.5BE2FE00 style="border:0px solid;"></a><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 face="Tahoma"><b><br>
From:</b> </font><a href="javascript:_e(%7B%7D,'cvml','agropper@gmail.com');" target=_blank><font size=2 color=blue face="Tahoma"><u>agropper@gmail.com</u></font></a><font size=2 face="Tahoma">
[</font><a href="javascript:_e(%7B%7D,'cvml','agropper@gmail.com');" target=_blank><font size=2 color=blue face="Tahoma"><u>mailto:agropper@gmail.com</u></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); </font><a href="javascript:_e(%7B%7D,'cvml','openid-specs-heart@lists.openid.net');" target=_blank><font size=2 color=blue face="Tahoma"><u>openid-specs-heart@lists.openid.net</u></font></a><font size=2 face="Tahoma"><b><br>
Subject:</b> Re: [Openid-specs-heart] Alice's health resource set</font><font size=3>
</font><font size=3 face="Times New Roman"><br>
</font><font size=3> </font><font size=3 face="Times New Roman"><br>
Aaron,</font><font size=3> </font><font size=3 face="Times New Roman"><br>
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. <br>
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><font size=3>
</font><font size=3 face="Times New Roman"><br>
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><font size=3> </font><font size=3 face="Times New Roman"><br>
</font><font size=3> </font><font size=3 face="Times New Roman"><br>
Here's my summary of the discussion AND HIPAA as far as HEART is concerned:</font><font size=3>
</font><font size=3 face="Times New Roman"><br>
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. <br>
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><font size=3>
</font><font size=3 face="Times New Roman"><br>
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><font size=3>
</font><font size=3 face="Times New Roman"><br>
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><font size=3> </font><font size=3 face="Times New Roman"><br>
A MUST and two MAYs. Can we move on to discussing scopes in this context
now?</font><font size=3> </font><font size=3 face="Times New Roman"><br>
</font><font size=3> </font><font size=3 face="Times New Roman"><br>
Adrian</font><font size=3> </font><font size=3 face="Times New Roman"><br>
</font><font size=3> </font><font size=3 face="Times New Roman"><br>
</font><font size=3> </font><font size=3 face="Times New Roman"><br>
On Wed, Aug 3, 2016 at 7:48 AM, Aaron Seib, NATE <</font><a href="javascript:_e(%7B%7D,'cvml','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><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
Regardless of how it makes me feel – my question earlier is how do we
actually address it.</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
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><font size=3>
</font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
Does anyone disagree with that? </font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
There are providers that will argue that they have an ethical responsibility
to share with other doctors that may treat you.</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
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><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
Anyone have an authoritative answer?</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
Aaron Seib, CEO</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
@CaptBlueButton <br>
(o) </font><a href="tel:301-540-2311" target=_blank><font size=2 color=blue face="Calibri"><u>301-540-2311</u></font></a><font size=3>
</font><font size=2 color=#004080 face="Calibri"><br>
(m) </font><a href="tel:301-326-6843" target=_blank><font size=2 color=blue face="Calibri"><u>301-326-6843</u></font></a><font size=3>
</font><font size=3 color=blue><u><br>
</u></font><a href="http://nate-trust.org/" target=_blank><img src=cid:_2_0A1E255C0A1E80C00054BF0F85258009 alt=cid:image001.jpg@01D10761.5BE2FE00 style="border:0px solid;"></a><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 face="Tahoma"><b><br>
From:</b> Openid-specs-heart [mailto:</font><a href="javascript:_e(%7B%7D,'cvml','openid-specs-heart-bounces@lists.openid.net');" target=_blank><font size=2 color=blue face="Tahoma"><u>openid-specs-heart-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="javascript:_e(%7B%7D,'cvml','openid-specs-heart@lists.openid.net');" target=_blank><font size=2 color=blue face="Tahoma"><u>openid-specs-heart@lists.openid.net</u></font></a><font size=3>
</font><font size=3 face="Times New Roman"><b><br>
<br>
Subject:</b> Re: [Openid-specs-heart] Alice's health resource set</font><font size=3>
</font><font size=3 face="Times New Roman"><br>
</font><font size=3> </font><font size=3 face="Times New Roman"><br>
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." <br>
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><font size=3> </font><font size=3 face="Times New Roman"><br>
Adrian</font><font size=3> </font><font size=3 face="Times New Roman"><br>
</font><font size=3> </font><font size=3 face="Times New Roman"><br>
</font><font size=3> </font><font size=3 face="Times New Roman"><br>
On Tue, Aug 2, 2016 at 5:12 PM, Maxwell, Jeremy (OS/OCPO) <</font><a href="javascript:_e(%7B%7D,'cvml','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><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
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><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3> </font><font size=2 face="Tahoma"><b><br>
From:</b> </font><a href="javascript:_e(%7B%7D,'cvml','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="javascript:_e(%7B%7D,'cvml','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="javascript:_e(%7B%7D,'cvml','openid-specs-heart@lists.openid.net');" target=_blank><font size=2 color=blue face="Tahoma"><u>openid-specs-heart@lists.openid.net</u></font></a><font size=2 face="Tahoma"><b><br>
Subject:</b> Re: [Openid-specs-heart] Alice's health resource set</font><font size=3>
</font><font size=3 face="Times New Roman"><br>
</font><font size=3> </font><font size=3 face="Times New Roman"><br>
Jeremy, <br>
<br>
Sorry, I should have said HIPAA TPO "consent".</font><font size=3>
</font><font size=3 face="Times New Roman"><br>
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><font size=3>
</font><font size=3 face="Times New Roman"><br>
Adrian</font><font size=3> </font><font size=3 face="Times New Roman"><br>
</font><font size=3> </font><font size=3 face="Times New Roman"><br>
On Tue, Aug 2, 2016 at 2:22 PM, Maxwell, Jeremy (OS/OCPO) <</font><a href="javascript:_e(%7B%7D,'cvml','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><font size=3> </font><font size=2 color=#004080 face="Calibri"><br>
Also, want to clarify what “typical of HIPAA TPO consent” means?
TPO is a permitted use under HIPAA that does not require consent.</font><font size=3>
</font>
<p><font size=2 color=#004080 face="Calibri"> </font><font size=3>
</font>
<p><font size=2 color=#004080 face="Calibri"> </font><font size=3>
</font>
<p><font size=2 color=#004080 face="Calibri"> </font><font size=3>
</font>
<p><font size=2 face="Tahoma"><b>From:</b> Openid-specs-heart [mailto:</font><a href="javascript:_e(%7B%7D,'cvml','openid-specs-heart-bounces@lists.openid.net');" target=_blank><font size=2 color=blue face="Tahoma"><u>openid-specs-heart-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="javascript:_e(%7B%7D,'cvml','openid-specs-heart@lists.openid.net');" target=_blank><font size=2 color=blue face="Tahoma"><u>openid-specs-heart@lists.openid.net</u></font></a><font size=2 face="Tahoma"><b><br>
Subject:</b> Re: [Openid-specs-heart] Alice's health resource set</font><font size=3>
</font>
<p><font size=3 face="Times New Roman"> </font><font size=3> </font>
<p><font size=3 face="Times New Roman">Lost me again Adrian - </font>
<p><font size=3 face="Times New Roman"> </font><font size=3> </font><font size=3 face="Times New Roman"><br>
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><font size=3> </font>
<p><font size=3 face="Times New Roman"> </font><font size=3> </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><font size=3> </font>
<p><font size=3 face="Times New Roman"> </font><font size=3> </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><font size=3> </font>
<p><font size=3 face="Times New Roman"> </font><font size=3> </font>
<p><font size=3 face="Times New Roman"> </font><font size=3> </font>
<p><font size=3 face="Times New Roman"> </font><font size=3> </font>
<p><font size=3 face="Times New Roman"> </font><font size=3> </font><font size=3 face="Times New Roman"><br>
<br>
<br>
<br>
-- <br>
</font><font size=3> </font><font size=3 face="Times New Roman"><br>
Adrian Gropper MD</font><font size=3 color=#004080 face="Arial"><br>
<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.org/donate-2/</u></font></a><font size=3 face="Times New Roman">
<br>
<br>
<br>
<br>
-- <br>
</font><font size=3> </font><font size=3 face="Times New Roman"><br>
Adrian Gropper MD</font><font size=3 color=#004080 face="Arial"><br>
<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.org/donate-2/</u></font></a><font size=3 face="Times New Roman">
<br>
<br>
<br>
<br>
-- <br>
</font><font size=3> </font><font size=3 face="Times New Roman"><br>
Adrian Gropper MD</font><font size=3 color=#004080 face="Arial"><br>
<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.org/donate-2/</u></font></a><font size=3 face="Times New Roman">
</font>
<p>
<hr><font size=1 face="Times New Roman"><br>
</font><a href="#m_3516374923822591767_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. <br>
</font><font size=3> </font><font size=2 face="Times New Roman"><br>
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. <br>
</font><font size=3> </font><font size=2 face="Times New Roman"><br>
Being inaccurate here will just degrade the audiences ability to know what
we are really saying here.</font><font size=3> </font><font size=2 face="Times New Roman"><br>
</font><font size=3> </font><font size=2 face="Times New Roman"><br>
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><font size=3>
</font><font size=1 face="Times New Roman"><br>
</font><a href="#m_3516374923822591767_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><font size=3> </font><font size=1 face="Times New Roman"><br>
</font><a href="#m_3516374923822591767_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><font size=3>
</font><font size=2 face="Times New Roman"><br>
</font><font size=3> </font><font size=2 face="Times New Roman"><br>
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><font size=3> </font><font size=1 face="Times New Roman"><br>
</font><a href="#m_3516374923822591767_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>_______________________________________________<br>
Openid-specs-heart mailing list</font></tt><font size=3 color=blue><u><br>
</u></font><a href="javascript:_e(%7B%7D,'cvml','Openid-specs-heart@lists.openid.net');" target=_blank><tt><font size=2 color=blue><u>Openid-specs-heart@lists.openid.net</u></font></tt></a><font size=3 color=blue><u><br>
</u></font><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target=_blank><tt><font size=2 color=blue><u>http://lists.openid.net/mailman/listinfo/openid-specs-heart</u></font></tt></a><font size=3><br>
<br>
<br>
_______________________________________________<br>
Openid-specs-heart mailing list</font><font size=3 color=blue><u><br>
</u></font><a href="javascript:_e(%7B%7D,'cvml','Openid-specs-heart@lists.openid.net');" target=_blank><font size=3 color=blue><u>Openid-specs-heart@lists.openid.net</u></font></a><font size=3 color=blue><u><br>
</u></font><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target=_blank><font size=3 color=blue><u>http://lists.openid.net/mailman/listinfo/openid-specs-heart</u></font></a><font size=3><br>
</font>
<p><a name="m_3516374923822591767_m_-4742296256565409933__msocom_1"></a><a name="m_3516374923822591767_m_-4742296256565409933__msocom_2"></a><a name="m_3516374923822591767_m_-4742296256565409933__msocom_3"></a><a name="m_3516374923822591767_m_-4742296256565409933__msocom_4"></a><font size=3><br>
<br>
-- </font>
<br>
<br><font size=3>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.org/donate-2/</u></font></a><font size=3>
</font>
<br>
<br>