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

[Adrian Gropper]

The experiment to fragment the address space into trusted and untrusted
clients has been tried many times starting with Markle Common Framework,
NHIN, state HIEs, and DirectTrust. There's a reason the HEART charter says
"build, run, or outsource."

Patients and physicians need a system where trust is rooted in people, not
institutions.

Adrian

On Tue, Dec 13, 2016 at 8:52 AM, Glen Marshall [SRS] <gfm at securityrs.com>
wrote:

> I prefer this be a parking lot issue for HEART.  We have enough on our
> plate to deliver a profile for the core HEART functions.  The API Task
> Force recommendations do not have the force of current regulations.  I
> expect a marketplace solution for them, outside of HEART, should the
> recommendations find their way into regulations.
>
>
>
>
>
> 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
>
> www.SecurityRiskSolutions.com <http://www.securityrisksolutions.com/>
>
>
>
> *From:* Openid-specs-heart [mailto:openid-specs-heart-
> bounces at lists.openid.net] *On Behalf Of *Adrian Gropper
> *Sent:* Monday, December 12, 2016 20:03
> *To:* openid-specs-heart at lists.openid.net; Josh Mandel <jmandel at gmail.com>;
> Justin P Richer <jricher at mit.edu>
> *Cc:* Grahame Grieve <grahame at healthintersections.com.au>
> *Subject:* [Openid-specs-heart] FHIR Client Registration is the
> existential issue for HEART
>
>
>
> This summer's API Task Force had, arguably, only one major conclusion:
>
> *"A Resource Server can warn a patient if the RS believes that a client
> requesting patient-directed exchange is un-trusted AND the patient can
> choose to click-through that warning and grant access to the resource
> anyway." *
>
> The API Task Force acknowledged situations where an RS could still block a
> client but these are limited to denial of service attacks and other threats
> against the integrity of _other_ patients' data on a system.
>
> There are efforts now underway to establish trust audits for FHIR clients
> which could be presented as part of a "software statement" in order to
> avoid the API Task Force warning.
>
> Regardless of whether these software statement efforts are successful and
> can be used to bypass the the API Task Force "warning", HEART has to deal
> with the API Task Force outcome and profile how a warning is issued when a
> patient-specified client does not come with a "trusted" software statement.
>
> As far as I can tell, the only way for HEART to enable the API Task Force
> conclusion is for us to specify a way for the RS to communicate the
> "warning" to the AS when a software statement is deemed inadequate by the
> RS AND to accept a "click-through" message back from the AS.
>
> As an alternative, the RS could bypass the AS and send the warning
> directly to the resource owner and expect a direct reply by secure message
> or via the patient portal that was used to register the resource with the
> AS in the first place. This alternative does not involve either HEART or
> UMA and could be considered a parking lot issue.
>
>
>
> 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/9bdcb563/attachment.html>