[Openid-specs-heart] HEART ad hoc meeting notes
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
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
* 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
* 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
* (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
* 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
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
nancy.lush at lgisoftware.com
Lush Group, Inc
Office: (401) 423-9111
28 Narragansett Ave
PO Box 651
Jamestown, RI 02835
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3006 bytes
Desc: not available
More information about the Openid-specs-heart