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

Wed Aug 3 16:39:21 UTC 2016

Awesome – we can make it real as a technical solution that can be applied across the globe.

I think you are correctly indicating that HEART can do nothing about the variances in regulatory environments and when I spend time pontificating about what should be dilutes the progress towards HEART’s mission.

What I would like to propose is that we – the royal we - meaning whoever has the access to update this web-page: http://openid.net/wg/heart/ 

Add a page called pre-conditions as the fourth page as in: http://openid.net/wg/heart/preconditions/

I think a lot of us are focused on figuring out how to utilize the results of HEART in the context of a US based Data Source that is a Covered Entity that must comply with HIPAA only but that is probably best done in isolation of this activity.

What would be appropriate for setting up a group of folks focused on this aspect – should we talk to someone at OpenID?  Since it is going to be providing guidance relevant policy interpretations should that be housed somewhere else?  Is this something that ONC should facilitate? 

I will be happy to contribute time to get that started.

Aaron Seib, CEO

@CaptBlueButton 

 (o) 301-540-2311

(m) 301-326-6843

cid:image001.jpg at 01D10761.5BE2FE00

From: John Moehrke [mailto:johnmoehrke at gmail.com] 
Sent: Wednesday, August 3, 2016 11:24 AM
To: Aaron Seib, NATE
Cc: Adrian Gropper; HEART List
Subject: Re: [Openid-specs-heart] Alice's health resource set

Thankyou Aaron;

I want to ask that the community move away from HIPAA and any other USA focused regulatory environment. I think it is sufficient for us to indicate that there are various Privacy regulations globally that we set as pre-conditions. These regulatory pre-conditions are necessary to force partners to participate and to act responsibly. BUT there is nothing HEART can do about these regulatory environments. We can make this real by indicating that we 'expect' that the regulatory environment where HEART will be used to have the characteristics of Privacy Principles http://healthcaresecprivacy.blogspot.com/2015/04/privacy-principles.html [inclusive of consumer control]. I think this is all that we need as a basis. We could define more tightly, but we gain nothing. When we try to define more tightly we argue about interpretation of the language; which is the role of lawyers. I am not a lawyer, and know better than to act like I have the authority to interpret law.  For example getting into discussions on TPO, which are useless and circular. 

Those organizations that are covered by HIPAA and must abide by those rules, also have to abide by many other rules (state, region, business, ethical); this is why what they ultimately do is up to their policy writing. By being specific about our pre-conditions; we alert our reader to review our pre-conditions against their actual environment. Where our pre-conditions don't align with their regulatory and organizational policy; they must adjust something. We don't even define what that something is.

Our pre-conditions should be short and simple; leveraging the good work of the privacy principles standards. 

So, we have a basis for the HEART UMA to exist. Consumer has the right to control how their data is used. We can enable constraints that will be found to be unacceptable by some hospitals, we accept this. All that we need to do is focus on reasonable flexibility in a framework that can grow and expand. Where reasonable flexibility is defined today to be rather simplistic, but better than the world without HEART UMA, and along a trajectory that can support more in the future. 

We keep trying to get perfection, and thus get nothing done. I urge an Agile approach.

John

John Moehrke
Principal Engineering Architect: Standards - Interoperability, Privacy, and Security
CyberPrivacy – Enabling authorized communications while respecting Privacy
M +1 920-564-2067
JohnMoehrke at gmail.com
https://www.linkedin.com/in/johnmoehrke
https://healthcaresecprivacy.blogspot.com
"Quis custodiet ipsos custodes?" ("Who watches the watchers?")

On Wed, Aug 3, 2016 at 9:57 AM, Aaron Seib, NATE <aaron.seib at nate-trust.org> wrote:

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

 <http://nate-trust.org> cid:image001.jpg at 01D10761.5BE2FE00

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

 <http://nate-trust.org> cid:image001.jpg at 01D10761.5BE2FE00

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/> 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/> 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/> 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/20160803/96d8067c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160803/96d8067c/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 65902 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160803/96d8067c/attachment-0001.png>