Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Health Relationship Trust (HEART) Working Group 22 June 2017


Published on

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

Published in: Technology
  • Be the first to comment

Health Relationship Trust (HEART) Working Group 22 June 2017

  1. 1. Health Relationship Trust (HEART) Working Group Eve Maler, WG co-chair | @xmlgrrl 22 June 2017
  2. 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. 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. 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. 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. 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. 7. Confidentiality, sensitivity, and break-the-glass requirements
  8. 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. 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. 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. 11. Questions? Join us! Thanks! Eve Maler, WG co-chair | @xmlgrrl 22 June 2017