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

[Adrian Gropper]

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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161213/727e7ac9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3204 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161213/727e7ac9/attachment.jpg>