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

Fri Dec 16 20:41:21 UTC 2016

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 <(301)%20540-2311>
>
> (m) 301-326-6843 <(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 <(301)%20540-2311>
>
> (m) 301-326-6843 <(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
>
> Mobile: (610) 613-3084
>
> gfm at securityrs.com
>
>
>
> *From:* agropper at gmail.com [mailto:agropper at gmail.com <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/
>
>
>
>
> --
>
>
>
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161216/33cda747/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3198 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161216/33cda747/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 3204 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161216/33cda747/attachment-0001.jpg>