[Openid-specs-heart] Openid-specs-heart Digest, Vol 147, Issue 1

Morgan,Hope (HHSC) Hope.Morgan at hhsc.state.tx.us
Wed Apr 11 14:19:37 UTC 2018

Is the HEART group participating on the Healthcare Directory project led by Daniel Chaput at the ONC?


Hope Morgan
Interim Director Office of eHealth Coordination, Medical and Social Services
Director Health Information Technology and Interoperability, Chief Technology Office - HHSC IT
Texas Health and Human Services Commission
512 438 4675

-----Original Message-----
From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of openid-specs-heart-request at lists.openid.net
Sent: Monday, April 09, 2018 7:00 AM
To: openid-specs-heart at lists.openid.net
Subject: Openid-specs-heart Digest, Vol 147, Issue 1

Send Openid-specs-heart mailing list submissions to
	openid-specs-heart at lists.openid.net

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
	openid-specs-heart-request at lists.openid.net

You can reach the person managing the list at
	openid-specs-heart-owner at lists.openid.net

When replying, please edit your Subject line so it is more specific than "Re: Contents of Openid-specs-heart digest..."

Today's Topics:

   1. HEART Agenda 2018-04-09 (Debbie Bucci)
   2. HEART ad hoc meeting notes (Nancy Lush)


Message: 1
Date: Sun, 8 Apr 2018 19:58:47 -0400
From: Debbie Bucci <debbucci at gmail.com>
To: openid-specs-heart at lists.openid.net
Subject: [Openid-specs-heart] HEART Agenda 2018-04-09
	<CAG6zQ1Y1b+cVUP=ufKXngpLmbxTacLE4Lk5GQ5GENVcB6OeesQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

*When:* Monday 1PM PST - 4PM EST
*Where:* GoToMeeting: https://global.gotomeeting.com/join/785234357
*US phone number:* +1 (619) 550-0003 <(619)%20550-0003>. Access Code

   - *Continue to work on use cases*
   - *AOB*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20180408/fb00ce36/attachment-0001.html>


Message: 2
Date: Sun, 8 Apr 2018 20:39:03 -0400
From: "Nancy Lush" <nlush at lgisoftware.com>
To: <openid-specs-heart at lists.openid.net>
Cc: <nancy.lush at lgisoftware.com>
Subject: [Openid-specs-heart] HEART ad hoc meeting notes
Message-ID: <163601d3cf9b$29132f40$7b398dc0$@lgisoftware.com>
Content-Type: text/plain; charset="us-ascii"

Compliments of Eve and Nancy.  Sorry for the delay.


HEART ad hoc 2018-03-29



Nancy Lush

Justin Richer

Eve Maler

Debbie Bucci

Catherine Schulten

Julie Maas


Eve shared a candidate simple HEART positioning message that she derived from a writeup of Danny van Leeuwen's. People generally liked the direction.


AI: Eve: Put this material in a GDoc and share for refinement.


Nancy presented some key assumptions:


*	Use HEART only where appropriate
*	HEART supports more robust identity assurance, but identity
assurance as such is outside the scope of HEART
*	HEART assumes oAuth2 and OpenId Connect, but as such is out of
*	Federated trusted IdP with a provider directory would enhance many
use cases and we may refer to in examples, but it's not in our scope to specify.
*	HEART contributes more to a wide-ecosystem use case.  Our
demonstration use cases should have at least one node of the interoperability exchange external to a closed healthcare network.
*	Avoid edge cases for the first pass
*	An external trusted consent server would enhance several use cases.
(Outside of scope of HEART but would be nice.)


Discussion: Is this meant to suggest an InCommon style of federation? Or not suggesting any particular topology? Maybe all the hospitals will end up trusting each other, the way InCommon's institutions trust each other. So we could discuss in a non-normative way how this could be a desirable outcome in health IT, but not commit to providing the solution ourselves.


Nancy has sketched how this might look in her "Building Block - External trusted IdP" diagram with steps, and imagined which parts of HEART they would need to especially conform to. Others have talked about building this, and a larger organization could be in a position to host one of these.
Graeme was alluding to this sort of thing in the recent private email thread. InCommon has a central metadata registry. So this is a powerful design pattern that has become quite automated (largely for SAML, but also increasingly for OIDC) and could be used in the healthcare world. 


Julie notes: DirectTrust has a placeholder for a provider directory with FHIR endpoints!


*	Wide ecosystem


Discussion: What are the use cases we want to support? It's more than just partner ecosystems that are "loosely coupled". So this does seem to meet the UMA definition of a wide ecosystem. If a patient wants to share data with a specialist outside the network, the AS doesn't know who that specialist is yet.


*	(Eve suggests a new assumption that comes before wide ecosystem:)
Loosely coupled services


Discussion: AS and RS may be in different (security) domains. Nancy suggested exploring how an external trusted consent server might exchange consents with trusted parties while protecting Alice's privacy in the process. 


*	Avoid edge cases for this first pass
*	Nice to have: Providing Alice with an external trusted consent


Discussion: This would enhance several use cases. Can we then define what "consent" (FHIR consent) means wrt authorization policy in this case? Yes, and perhaps we can simplify things by reference to HIPAA. This touches on Consent2Share.


Key HEART examples:


A. Alice selectively shares data with others

B. Alice is in her PCP office and wants to share data with a specialist

Suggestion: Break out sharing de-identified data for research.


C. Shares with a specialist (choosing wide ecosystem because without that, HEART isn't really required) This is the case of a provider sharing data with an external provider based on an electronic consent created by Alice.


D. First Appointment with a new physician.  

E. Tele Health Services

F. IOT data

G. Long term care facilities


Eve pointed out that while there may be some overlap, we should write the use cases and then evaluate to determine if they are the same.  They may have subtle differences we may discover in the process. 




Regarding sharing data for research: There's the question of long-term access. There are actually a lot of edge cases. E.g., does the RS have the ability to de-identify data that it sends out?  Do we need another scope for the ability to de-identify? What parts of this does Sync4Science do?


Five folks each agreed to write one use case, which will be used to demonstrate the power of HEART.  We will try to keep them simple and to one page.  





Nancy Lush          

nancy.lush at lgisoftware.com

Lush Group, Inc

Office: (401) 423-9111

28 Narragansett Ave

PO Box 651


Cell:(401) 965-9347

Jamestown, RI 02835





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20180408/8e648732/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 3006 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20180408/8e648732/attachment-0001.gif>


Subject: Digest Footer

Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net


End of Openid-specs-heart Digest, Vol 147, Issue 1

More information about the Openid-specs-heart mailing list