[Openid-specs-heart] HEART ad hoc meeting notes

Nancy Lush nlush at lgisoftware.com
Mon Apr 9 00:39:03 UTC 2018


Compliments of Eve and Nancy.  Sorry for the delay.

 

HEART ad hoc 2018-03-29

 

Attending:

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
scope.
*	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
server

 

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

www.lgisoftware.com 

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.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.gif>


More information about the Openid-specs-heart mailing list