[Openid-specs-heart] FHIR Client Registration is the existential issue for HEART

Fri Dec 16 21:33:20 UTC 2016

I love you my brother but you can’t drive just any car on the highways that you share with other Americans.

There are state inspections and limitations on what vehicles can be sold to the US market.  If I had my way no one would be able to drive around in a car that gets less than 30 mpg but I have to accept that it is lawful for the Ted Nugent guy that passes me on the highway to drive his yellow Hummer because the governance process authorizes that car to share the highway with me (and emergency response vehicles and the trades and everyone else).

But let me be clear – I don’t think this topic should be a parking lot issue for the entire country.  I think it is an issue that the HEART group should exclude as out of scope because we are not representative of the stakeholder groups that will be affected by our decisions and as a result will be ineffective in addressing this important – perhaps mandatory – element of an adoptable solution set that will result in a fabric that results in consumer directed exchange.

I just finished reading your article and I don’t think we are very far apart personally.  We need to be able to federate ID mgmt and establish a trust mechanism that facilitates this (NCCoE has started a new effort to look into doing just that) if we are to get to the next horizon of consumer access without spending another $30B to Identity proof everyone to the satisfaction of everyone else using traditional methods.  

The recommendation of the API task force – that I was a part of – recommended that the credentials to enable API based transactions shouldn’t be any stronger than those that the institutions accept today when permitting consumers to access their portals.  These are rooted in the F2F encounter of the Patient and the Consumer but technically enabled by the institution.

Much of the current work going on in the country related to APIs relies on the bootstrapping of access based on a consumer authenticating into his or her portal.

A solution could be to figure out how we make it easier to “recycle” a consumer’s ability to authenticate into multiple portals in order to grant them access to a third.  I don’t know if that is remotely a realistic way to harness the antecedent Id proofing that occurs between an individual and their provider for use cases that have a broader scope then the ‘enterprise’ of that provider but there is an aspect of that idea that echoes you battle cry of relying on the extant trust and relationship of the patient and the caregiver.

At the end of the day my point is HEART isn’t the place to develop that kind of idea and the people that are participating – likely the greatest technical minds working in this domain – alone are not sufficient to solve it for all the stakeholders that have to buy in to make it work.

So – I agree with you – relegating these topics to the parking lot for HEART is not a satisfactory answer but having HEART develop a solution is not going to be satisfactory either.  

In your article you reference Block Chain as a contender – Kathleen and I were just talking about that today as well and I saw a lot of merit in exploring that option too – my point is just that HEART isn’t the right home to develop this solution – it needs to be done by a much broader and inclusive group.

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: Friday, December 16, 2016 3:41 PM
To: Aaron Seib
Cc: Glen Marshall [SRS]; openid-specs-heart at lists.openid.net; Justin P Richer; Josh Mandel; Grahame Grieve
Subject: Re: [Openid-specs-heart] FHIR Client Registration is the existential issue for HEART

Aaron,

The state driver's license or US passport authority don't manage any authorization servers. Neither does any medical board. They are credential authorities and the root of trust for individuals and clearly they scale. 

An authorization server or a FHIR / UMA EHR client are just like my car or the bus in this picture. The individual gets to choose their agent and bears the consequences of coming through with a car, a bus, or some EHR. 

This is not a parking lot issue. It's the fundamental issue for both UMA and health information exchange. If UMA and HEART don't deal with it, then it will need to be handled out of band and we will continue the mess that we have with each different patient portal using their own special process for handing out access credentials.

Adrian

On Fri, Dec 16, 2016 at 10:54 AM, Aaron Seib <aaron.seib at nate-trust.org> wrote:

Trust in individuals doesn’t scale though.

This is human evolution your trying to refute.  There is a reason cultures developed different models of governance once our tribes exceeded about 150 people.  

The cost of establishing and maintaining trust at the individual level exceeds the societal value produced in comparison to relying on institutional trust at the individual participant level.

At some point for HEART to be adoptable we have to find a way for there to be trust in “institutions” at least at the Authorization server level.  

Aaron Seib, CEO

@CaptBlueButton 

 (o) 301-540-2311 <tel:(301)%20540-2311> 

(m) 301-326-6843 <tel:(301)%20326-6843> 

 <http://nate-trust.org> 

From: agropper at gmail.com [mailto:agropper at gmail.com] On Behalf Of Adrian Gropper
Sent: Friday, December 16, 2016 10:24 AM
To: Aaron Seib
Cc: Glen Marshall [SRS]; openid-specs-heart at lists.openid.net; Justin P Richer; Josh Mandel; Grahame Grieve

Subject: Re: [Openid-specs-heart] FHIR Client Registration is the existential issue for HEART

http://thehealthcareblog.com/blog/2016/12/16/making-the-physician-patient-relationship-great-again/ is about this issue.

We can't get to longitudinal health records by building on institutional trust and federations. HEART needs to build on trust in individuals. It's what makes us special. 

Adrian

On Tue, Dec 13, 2016 at 4:59 PM, Adrian Gropper <agropper at healthurl.com> wrote:

A number of volunteers have built and released as free software the only example of a standards-based patient-centered health record ever. We are demonstrating FHIR, UMA, and OpenID Connect with running code and the user experience for both the patient and the clinicians is there for all to criticize. By using the HIE and clipboard model we are demonstrating well understood use-cases.

We ask other members of the HEART, SMART, and Sync4Science communities to consider how their projects can interoperate among each other and with the implementation we have released as HIE of One.

If we're to succeed with a patient-centered health record, running code needs to drive the HEART process.

Adrian

On Tue, Dec 13, 2016 at 2:45 PM, Aaron Seib <aaron.seib at nate-trust.org> wrote:

I know that the only opinion that matters is the one that shouts the loudest so I humbly accept that my input is not desired.

Aaron Seib, CEO

@CaptBlueButton 

 (o) 301-540-2311 <tel:(301)%20540-2311> 

(m) 301-326-6843 <tel:(301)%20326-6843> 

 <http://nate-trust.org> 

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Glen Marshall [SRS]
Sent: Tuesday, December 13, 2016 1:56 PM
To: Adrian Gropper
Cc: openid-specs-heart at lists.openid.net

Subject: Re: [Openid-specs-heart] FHIR Client Registration is the existential issue for HEART

Adrian,

My suggestion is to put this issue in the parking lot.  

To keep burdening what should be a simple profile with matters that are not regulatory or market requirements is a good way to kill the project.  I’m sure you want to avoid that.  We instead need to have a sense of “good enough” and a candidate list of incremental improvements over time.

I hope that we would concern ourselves more with the business case.  In particular, I worry about funding AS operation, the apparent co-requisite need for a patient registry (out of scope for HEART core), the need for trusted unique identifiers and their provisioning and management, and the market drivers for adoption by providers and commercial products.  As a patient who may benefit from this, I expect to pay for it, but how much will patients be willing to pay?  I do not expect a government-run or -sponsored operation to make it work.  

Glen F. Marshall

Consultant

Security Risk Solutions, Inc.

698 Fishermans Bend

Mount Pleasant, SC 29464

Tel: (610) 644-2452 <tel:(610)%20644-2452>  

Mobile: (610) 613-3084 <tel:(610)%20613-3084> 

gfm at securityrs.com

From: agropper at gmail.com [mailto:agropper at gmail.com] On Behalf Of Adrian Gropper
Sent: Tuesday, December 13, 2016 13:36
To: Aaron Seib <aaron.seib at nate-trust.org>
Cc: Glen Marshall [SRS] <gfm at securityrs.com>; Josh Mandel <jmandel at gmail.com>; Grahame Grieve <grahame at healthintersections.com.au>; openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] FHIR Client Registration is the existential issue for HEART

The HEART charter is about patient-directed exchange across FHIR APIs. There's no reason to introduce trust federations into HEART, especially since practical trust mechanisms don't yet exist. We can imagine that Sequoia, or DirectTrust, or the FDA will start issuing software statements for apps someday but that's what makes trust federations a parking lot issue today. 

What we do know today is HIPAA and the API Task Force output. 

If we don't provide a mechanism for resource servers to issue a warning and receive a click-through as part of HEART, then we will force patients to register clients manually through a patient portal the same way that you register a client to the Google OAuth API. The usability of that process is likely to doom HEART.

What is the alternate proposal from Glen, Aaron, or anyone else:

(1) Is HEART to assume software statements are going to be issued by someone and federated by all RSs so that HIPAA / API Task Force warnings are irrelevant?

(2) Is HEART to assume that dynamic client registration occurs without a software statement?

(3) ?

Adrian

-- 

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/ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161216/6d5f79be/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 3198 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161216/6d5f79be/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.jpg
Type: image/jpeg
Size: 3204 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161216/6d5f79be/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3208 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161216/6d5f79be/attachment-0005.jpg>