HEART Working Group - Specifications
The HEART working group intends to harmonize and develop a set of privacy and security specifications that enable an individual to control the authorization of access to RESTful health-related data sharing APIs, and to facilitate interoperable implementations of these specifications by others. HEART Working Group
OVERVIEW
HEART Working Group
CHARTER
HEART Working Group
SPECIFICATIONS
HEART Working Group
REPOSITORY
The working group has been developing the following specifications:
Specifications
A complete list of HEART specifications produced (including previous Implementer’s Drafts) can be found in the group’s BitBucket repository. There are two types of HEART specifications:
- Mechanical profiles: These specify and tighten security parameters for using OAuth 2.0, OpenID Connect, and UMA, respectively, in the context of patient-controlled health data exchange.
- Semantic profiles: These prescribe usage of OAuth and UMA (for example, defining scopes and flows) in combination with health industry-specific APIs. The first set of APIs to have received this treatment is FHIR.
Implementer's Drafts
- Health Relationship Trust Profile for OAuth 2.0 – This specification profiles the OAuth 2.0 protocol framework to increase baseline security, provide greater interoperability, and structure deployments in a manner specifically applicable to (but not limited to) the healthcare domain.
– Most recent Implementer’s Draft - Health Relationship Trust Profile for Fast Healthcare Interoperability Resources (FHIR) OAuth 2.0 Scopes – This specification profiles the OAuth 2.0 protocol scopes to be used with the FHIR protocol to increase baseline security, provide greater interoperability, and structure deployments in a manner specifically applicable to (but not limited to) the healthcare domain.
– Most recent Implementer’s Draft - Health Relationship Trust Profile for User-Managed Access 2.0 – This specification profiles the UMA protocol to increase baseline security, provide greater interoperability, and structure deployments in a manner specifically applicable to (but not limited to) the healthcare domain.
– Most recent Implementer’s Draft - Health Relationship Trust Profile for Fast Healthcare Interoperability Resources (FHIR) UMA 2 Resources – This specification profiles the resource types and claim types to be used with the FHIR protocol to increase baseline security, provide greater interoperability, and structure deployments in a manner specifically applicable to (but not limited to) the healthcare domain.
– Most recent Implementer’s Draft
Resources
- What Is HEART?
- Emerging Identity Standards in Healthcare presentation by the HEART co-chairs from Identiverse, June 2018 (slides, video)
- Introduction to OAuth and OpenID Connect by Justin Richer
- Introduction to UMA (UMA V2, with some HEART context) by Eve Maler
- UMA Business Model background
- MITRE RHEx and Blue Button Plus profile efforts
- GTRI-Trustmark Presentation April 2015 (downloads a PowerPoint file about the GTRI “trustmark marketplace”)
Use cases from 2018 Work Group effort:
- Alice Shares Clinical Records With Her Spouse
- Alice Shares Health Data With Her Spouse
- Alice Electronically Shares Data From Her PHR
- Patient Shares Data From Her Health IoT Device to Her Clinician
Original use cases (obsolete):
- Use case template (GDoc)
- Alice Selectively Shares Health-Related Data with Physicians and Others [UMA, FHIR] (GDoc)
- Alice Registers with PCP and Sets Up Two-Way Exchange of Personal Data Between EHR and PHR [OAuth Only] (GDoc)
- Elderly Mom with Family Caregiver (GDoc)
- Multiple Portals (wiki)
- Post-MI Implant and Rehab (wiki)
- VA Secure RESTful Profiles use case (wiki)
- Patient Data for Clinical and Research Purposes (wiki)
- PCP First Appointment (wiki) – see also PHR to EHR swimlane
- IdP = identity provider
- RP = relying party
- SSO = single sign-on
- user = human end-user
- RO = resource owner (typically a user) trying to achieve controlled sharing – could be same as SSO user
- AS = authorization server – could be the same as IdP
- RS = resource server – could be the same as AS
- C = client – an application
- RqP = requesting party (typically but not always a user) – could be same as RO