Introducing the Health Relationship Trust (HEART) Working Group of the OpenID Foundation at the Cloud Identity Summit in Chicago in June 2017

1. Health Relationship Trust
(HEART) Working Group
Eve Maler, WG co-chair
eve.maler@forgerock.com | @xmlgrrl
22 June 2017
http://openid.net/wg/heart/

2. Why?
• Individuals want to gather, control, and share
their health data
– People want to be able to give permission for access
– …and to change their minds
• More and more, this data is sourced digitally
– Such as from mobile apps and smart devices
– This is especially so for complex health conditions
• …and is stored in electronic records
• Clinicians, insurers, and researchers want or need
data access to diagnose, plan care, and pay for
care
• HEART puts the individual back at the center of
the health data-sharing conversation

3. WG goals and scope
• RESTful health data sharing
• Patient-centric, privacy-sensitive
• Internationally applicable
• Primarily profiling existing specs
– OAuth, OpenID Connect, UMA, HL7’s FHIR API
• Foster interoperable implementations
• Not specifying a patient discovery mechanism
• Not specifying trust frameworks

4. Who takes part?
• Health/health IT subject matter experts
– E.g., SAMHSA, VA, HL7, doctors…
• Technology experts
– Implementers
– Spec authors and editors
• Leadership team:
– Co-chair Debbie Bucci (HHS ONC)
– Co-chair Eve Maler (ForgeRock)
– Spec editor Justin Richer (Bespoke Engineering)

5. Use cases collected
• Multiple portals
• Virtual patient registration
• Post-myocardial infarction implant and rehab
• VA secure RESTful use case
• Patient data for clinical and research purposes
• Primary care physician first appointment
• Alice selectively shares health-related data
with physicians and others

6. Deliverables:
All are in Implementer’s Draft status
HEART Profile for UMA
HEART Profile for OAuth 2.0
HEART Profile for OpenID Connect
HEART Profile
for UMA and
FHIR
HEART Profile
for OAuth 2.0
and FHIR
SECURITY
PROFILES
SEMANTIC
PROFILES
UMA-
RELATED
OIDC-
RELATED
OAUTH-
RELATED

7. Confidentiality, sensitivity, and
break-the-glass requirements

8. For confidentiality and sensitivity requirements,
we specified a scope mechanism
• For example, scope sens/ETH = “substance
abuse”
– Available to both OAuth and UMA
• If a resource server is capable of filtering out
substance abuse info with this scope:
– It MUST advertise this fact
– If a client brings it an access token WITHOUT this
scope, if it’s at all possible for it to do so, it
SHOULD redact the substance abuse info out of
the delivered resource

9. For break-the-glass, we similarly
specified a scope mechanism
• The scope is called btg
– Available to both OAuth and UMA
• Scope issuance is out of scope (sorry)
– UX options are of particular relevance in the UMA
case
• The resource server MUST log btg access in an
auditable format available to the resource
owner

10. The Move Health Data Forward
challenges
• Starting mid-2016, HHS ONC challenged
industry to create API solutions to help
individuals authorize the movement of their
health data
• Three phases later, several winners
have won awards, including for
some solutions
based on the
HEART
profiles

11. Questions?
Join us!
Thanks!
Eve Maler, WG co-chair
eve.maler@forgerock.com | @xmlgrrl
22 June 2017
http://openid.net/wg/heart/