[Openid-specs-heart] HEART stepping stones

Mon Apr 20 12:29:58 UTC 2015

Hi Adrian,

I hope others respond because we need consensus, not two voices…

(See answers below)

From: agropper at gmail.com [mailto:agropper at gmail.com] On Behalf Of Adrian Gropper
Sent: Sunday, April 19, 2015 8:48 PM
To: Moehrke, John (GE Healthcare)
Cc: Eve Maler; openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] HEART stepping stones

Then this is an excellent discussion. It suggests that there's a roadmap and some metric for achievability.

For example:

With regard to UMA Authorization Servers, are you suggesting that we consider a mix of personally-controlled and institutionally-controlled Authorization Servers or just one or the other?

Seems to me it would be more realistic to constrain to personally-controlled, and leave the institution to control their own business. Not that this won’t change, but it is a more likely success path.

With regard to interface scopes, are there particular scopes that should be considered before others?

I don’t know. I am not even sure I understand the question, or more specifically the ramifications of the answer.

With regard to identity management and identity federation, would we consider patient ID before or after provider ID?

I think we need to separate concerns here. There are too many conflated concepts to solve them all at the same time. First, we recognize that there are federated identities, commonly referred to as user-identity, though in federated-IDM space they are entities or subjects. It is really unfortunate that all of these words have overloading, so picking one will cause trouble too, but I pick ‘user-identity’. Then we recognize a few roles, for which patient-as-themselves is one. This is not the same thing as “Patient ID”; and this comes into the picture later when the healthcare-provider-institution does an identity-proofing-process to a level-of-assurance that is acceptable to them, to bind the user-identity to what they understand as the Patient ID. I say this comes in later as scoping our efforts first to patient controlled data allows us to not really need to bring in the concept of “Patient ID”; as from this perspective the data being controlled by the patient. Thus there is a user-identity that is acting in the role of the patient-themselves, and there are data that this user controls. Which is a more complete approach that avoids much of the arguments around ‘patient’ vs ‘client’ vs ‘subject’ etc.

With regard to patient matching and discovery, would we try to keep these in or out of scope for the early parts of the roadmap?

As I showed above, this is deferred given the initial scope focused on the patient and the data they directly control. The result is that the patient matching is a problem of the healthcare provider organization; as they are the ones that need to have a high assurance that the user they are interacting with is indeed the patient they know. This LoA is a big struggle.

Is there a class of providers or data holders (hospitals, payers, labs, public facilities, etc...) that we could prioritize? 

This seems like a use-case analysis. I don’t think you can solve these in broad strokes. You need to have very specific use-cases, with clear roles-and-responsibilities, and clear stake-holders. Coming at this with broad bushes will eventually happen, but to make it achievable and consumable it needs to be actionable. It also needs all stake-holders directly involved with clear roles-and-responsibilities. You have rallied against dictates before, as will any stake-holder that is not involved.

I’m sorry I couldn’t make RSA to see your talks. 

John

Adrian

On Sun, Apr 19, 2015 at 9:33 PM, Moehrke, John (GE Healthcare) <John.Moehrke at med.ge.com> wrote:

I am not trying to limit the destination. I am trying to define the next achievable step.  

John

From: agropper at gmail.com [mailto:agropper at gmail.com] On Behalf Of Adrian Gropper
Sent: Sunday, April 19, 2015 5:13 PM

To: Moehrke, John (GE Healthcare)
Cc: Eve Maler; openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] HEART stepping stones

Hello John,

There's no need for you to take my perspective personally. 

"Data created fully by the patient" seems to be urging us to down-scope HEART to the non-HIPAA domain.

Adrian 

On Sun, Apr 19, 2015 at 5:21 PM, Moehrke, John (GE Healthcare) <John.Moehrke at med.ge.com> wrote:

Hi Adrian,

Interesting misrepresentation of what I said. I am disappointed that you feel it necessary to misrepresent what I said. I am also disappointed that you feel it necessary to bring in other negative topics that I said nothing about. I am trying to find ground that we can progress forward on; while you seem to be just wanting to make personal assaults.  

Looking for the constructive message in your comment, I think you are suggesting that we scope our efforts to the flow of information from the patient possession to points-elsewhere. I am fine with that kind of a scope. It also avoids the issues I was bringing up.  I very much agree that data created fully by the patient is, and should be, totally controlled by the patient.  This scope also avoids the concerns that encumber healthcare provider environments:  Medical Ethics concerns, Safety concerns, and concerns of wrongful disclosure.  

John

From: agropper at gmail.com [mailto:agropper at gmail.com] On Behalf Of Adrian Gropper
Sent: Sunday, April 19, 2015 12:42 PM
To: Moehrke, John (GE Healthcare)
Cc: Eve Maler; openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] HEART stepping stones

John, I find your perspective both paternalistic and unscalable. 

US healthcare is awash in lack of transparency and the result is $1Trillion of unwarranted care. It's paternalistic and incredibly self-serving to presume that just because the institution has been given a right to use patient data without any accountability as long as the data is for Treatment, Payment, or Operations or De-Identified, or "Break the Glass", or prescription drug monitoring, or just plain lack of segmentation for access, that it's good policy. The current regulations are the result of heavy and effective lobbying by a very well organized industry trying to protect its secrets by avoiding the HIPAA accounting for disclosures and and patient right of access because they're "too hard". Think of HEART as trying to fix the "too hard" problem.

Your perspective is also unscalable as more and more health-related data originates in wearables as well home and environmental monitors, and then ends-up in trans-national analytics completely outside of the HIPAA regs. It's also unscalable as patient data such as genomes can no longer be collected under informed consent because nobody has any idea of how your genomic information will be interpreted three years from now and how that interpretation might affect you or your children. It's also unscalable as the ability to promise de-identification for research becomes less and less realistic.

The simple fact is that surveillance, data processing, and data storage is now effectively free compared to the economic value of the patient data. Rent-seeking-behavior by politically astute institutions has been effective for the past few years but the natives are getting restless. If you want to read more: http://thehealthcareblog.com/blog/2015/04/16/last-chance-for-meaningful-use/ and I hope you make the comments above on the blog.

Adrian

-- 

Adrian Gropper MD
Ensure Health Information Privacy. Support Patient Privacy Rights.
http://patientprivacyrights.org/donate-2/  

-- 

Adrian Gropper MD
Ensure Health Information Privacy. Support Patient Privacy Rights.
http://patientprivacyrights.org/donate-2/  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150420/c5b57d74/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6966 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150420/c5b57d74/attachment-0001.p7s>