[Openid-specs-heart] Alice's health resource set

Robert Horn robert.horn at agfa.com
Thu Aug 4 19:35:52 UTC 2016


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.

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.

This system is well established now, with 300-500 million DVDs being 
delivered annually around the world.

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.)

There are also disadvantages. Many patients are unable to provide proper 
security and storage for their DVDs.

Kind Regards,

Robert Horn | Agfa HealthCare
Interoperability Architect | HE/Technology Office
T  +1 978 897 4860

Agfa HealthCare Corporation, Gotham Parkway 580, Carlstadt, NJ 07072-2405, 
USA
http://www.agfahealthcare.com
http://blog.agfahealthcare.com
Click on link to read important disclaimer: 
http://www.agfahealthcare.com/maildisclaimer 



From:   "Aaron Seib, NATE" <aaron.seib at nate-trust.org>
To:     "'Adrian Gropper'" <agropper at healthurl.com>
Cc:     openid-specs-heart at lists.openid.net
Date:   08/03/2016 10:58 AM
Subject:        Re: [Openid-specs-heart] Alice's health resource set
Sent by:        "Openid-specs-heart" 
<openid-specs-heart-bounces at lists.openid.net>



Good.
 
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.
 
Below, where you say:
 
·         “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.”
 
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.
 
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..
 
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.
 
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.
 
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.
 
This is the way that I simplify it so that I can keep it straight.  I 
welcome everyones feedback.
 
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.  
 
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.
 
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.
 
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 magic 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?
 
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).
 
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…
 
a) All resources [AS1] 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. 
   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[AS2] .
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. 
   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.[AS3] 
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[AS4] 
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.
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.
If I am alone I will remove myself from the list serve and you guys can 
continue in peace without me.
 
Aaron Seib, CEO
@CaptBlueButton 
 (o) 301-540-2311
(m) 301-326-6843

 
From: agropper at gmail.com [mailto:agropper at gmail.com] On Behalf Of Adrian 
Gropper
Sent: Wednesday, August 3, 2016 9:35 AM
To: Aaron Seib, NATE
Cc: Maxwell, Jeremy (OS/OCPO); openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] Alice's health resource set
 
Aaron,
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. 
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.
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.
 
Here's my summary of the discussion AND HIPAA as far as HEART is 
concerned:
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. 
   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.
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. 
   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.
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.)
A MUST and two MAYs. Can we move on to discussing scopes in this context 
now?
 
Adrian
 
 
On Wed, Aug 3, 2016 at 7:48 AM, Aaron Seib, NATE <
aaron.seib at nate-trust.org> wrote:
Regardless of how it makes me feel – my question earlier is how do we 
actually address it.
 
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.
 
Does anyone disagree with that? 
 
There are providers that will argue that they have an ethical 
responsibility to share with other doctors that may treat you.
 
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.
 
Anyone have an authoritative answer?
 
 
Aaron Seib, CEO
@CaptBlueButton 
 (o) 301-540-2311
(m) 301-326-6843

 
From: Openid-specs-heart [mailto:
openid-specs-heart-bounces at lists.openid.net] On Behalf Of Adrian Gropper
Sent: Tuesday, August 2, 2016 5:27 PM
To: Maxwell, Jeremy (OS/OCPO)
Cc: openid-specs-heart at lists.openid.net

Subject: Re: [Openid-specs-heart] Alice's health resource set
 
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." 
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.
Adrian
 
 
On Tue, Aug 2, 2016 at 5:12 PM, Maxwell, Jeremy (OS/OCPO) <
Jeremy.Maxwell at hhs.gov> wrote:
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.
 
 
 
From: agropper at gmail.com [mailto:agropper at gmail.com] On Behalf Of Adrian 
Gropper
Sent: Tuesday, August 02, 2016 5:01 PM
To: Maxwell, Jeremy (OS/OCPO)
Cc: Debbie Bucci; openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] Alice's health resource set
 
Jeremy, 

Sorry, I should have said HIPAA TPO "consent".
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.
Adrian
 
On Tue, Aug 2, 2016 at 2:22 PM, Maxwell, Jeremy (OS/OCPO) <
Jeremy.Maxwell at hhs.gov> wrote:
Also, want to clarify what “typical of HIPAA TPO consent” means?  TPO is a 
permitted use under HIPAA that does not require consent.
 
 
 
From: Openid-specs-heart [mailto:
openid-specs-heart-bounces at lists.openid.net] On Behalf Of Debbie Bucci
Sent: Tuesday, August 02, 2016 2:17 PM
To: Adrian Gropper
Cc: openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] Alice's health resource set
 
Lost me again Adrian - 
 
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?
 
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.
 
 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 (?)
 
 
 
 



-- 
 
Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/ 



-- 
 
Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/ 



-- 
 
Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/ 

 [AS1]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.  
 
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.  
 
Being inaccurate here will just degrade the audiences ability to know what 
we are really saying here.
 
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).
 [AS2]These 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.
 [AS3]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.
 
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.
 [AS4]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.
_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-heart


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160804/e7993ded/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160804/e7993ded/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160804/e7993ded/attachment-0001.jpe>


More information about the Openid-specs-heart mailing list