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

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.

Drafts

Resources

  • 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