OpenID Foundation Workshop at EIC 2018 - HEART Working Group Update
- 1. Health Relationship Trust (HEART) Working Group Eve Maler, WG co-chair eve.maler@forgerock.com| @xmlgrrl 15 May 2018 http://openid.net/wg/heart/ 1
- 2. Why HEART? • Health data is some of the most personal and private consumer data • It is increasingly digital, either at the source or when transcribed • The Internet of Healthy Things and genomic data are having an impact • Individuals want to be in control of gathering and sharing this data • Including giving permission for access – and revoking permission • Especially if they have complex conditions or have moved frequently • Clinicians, insurers, and researchers seek data access to diagnose, plan care, and pay for care, and need to know it’s authorized for use • HEART puts the individual back at the center of the health data- sharing conversation 2
- 3. What does HEART do? To achieve RESTful, patient-centric, privacy-sensitive health data sharing… • It profiles OAuth, OpenID Connect, UMA, and the HL7 FHIR (Fast Healthcare Interoperability Resources) API • It provides the official FHIR API security mechanism • It is also aligning over time with the SMART on FHIR API effort developed for use with EHR systems, health portals, and Health Information Exchanges 3
- 4. Who is involved? • Health/health IT subject matter experts • Doctors, government health agency reps… • Technology experts • Implementers, health startups, spec authors… • Leadership team: • Co-chair Debbie Bucci (US Health and Human Services Office of the National Coordinator) • Co-chair Eve Maler (ForgeRock) • Spec editor Justin Richer (Bespoke Engineering) 4
- 5. Current state of the deliverables (see https://openid.bitbucket.io/HEART/) 5 • Mechanical = security profile • Semantic = API-specific profile • Considering whether to deprecate the UMA1 profiles
- 6. New white paper and use case work (unpublished as yet) • Focused on new urgency in the quest for patient-mediated health data exchange solutions, e.g., in the US: • MyHealthEData • Promoting Interoperability (was “Meaningful Use”) • White paper: Enabling Patient-Mediated Health Data Exchange • With assistance from Jan Oldenburg of Participatory Healthcare • Use cases under review: • Alice electronically shares data from her PHR • Alice controls sharing of sensitive clinical data • Alice delegates to a personal representative 6
- 7. HEART scope mechanisms Confidentiality and sensitivity • HL7 defines many codes for sensitive data types • E.g., sens/ETH for substance abuse • Similarly, it defines some codes for confidentiality levels • HEART allows an RS to use these as scopes • If such a scope is not associated with an access token, the RS SHOULD filter out the relevant data before delivering it, if at all possible Break-the-glass • HL7 defines a code btg for situations where the resource owner is unavailable • HEART allows an RS to use this as a scope • If such a scope is associated with an access token, the RS MUST log access made on this basis in an auditable format available to the resource owner 7 Note: All policy-setting UX options are “outside the scope of scope mechanisms” (e.g., policy defaulting).
- 8. A potential third scope mechanism: de-identification • We are currently discussing whether to add a similar scope mechanism for enabling a patient to instruct the RS to deliver resources in de-identified form 8
- 9. The Move Health Data Forward challenges (https://www.challenge.gov/challenge/move-health-data-forward-challenge/) • 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 9
- 10. Thank you! Questions? Join us! Eve Maler, WG co-chair eve.maler@forgerock.com| @xmlgrrl 15 May 2018 http://openid.net/wg/heart/ 10