Kantara uma webinar july 2020

1. UMA: 21st century health
information interoperability
+ user control
July 21, 2020
Alec Laws & Adrian Gropper

2. Agenda
● Moderator's welcome
● Overview of current challenges in Health Care
● How does UMA address those challenges
● Case Study: US Health Care and Trustee by HIE of ONE
● Case Study: CAN Health Care and FPX by IDENTOS
● Discussion: Presenters offer their views
● Q & A
● Current UMA and Community Activity

3. UMA Implementers Embrace Health Care
ForgeRock – financial, healthcare, IoT, G2C…
Gluu (open source) – API protection, enterprise, G2C…
HIE of One / Trustee (open source) – healthcare
IDENTOS – healthcare, G2C, …
PatientShare – healthcare
HealthyMePHR – healthcare
Pauldron (open source) – healthcare
RedHat Keycloak (open source) – API protection, enterprise, IoT…
ShareMedData – healthcare
WSO2 (open source) – enterprise
(more detail at tinyurl.com/umawg)
~50% of
implementations
have stated
Health Care focus

4. Desired Patient Experience

5. Current problems in our healthcare ecosystem
Data Silos
Key information
not visible
Can’t share
information
Lack of trust:
paper based
records
Have to tell my story
over and over to
different providers
No support for
complex patient
journeys
No digital
access
Can’t remember
ID or password
Unnecessary
duplication of
tests & services
Fear of fraud
and security
breaches
Miscommunication,
missed visits,
inefficiencies
Lack of R&D
innovation in digital
spaces

6. Patient access to
their health data is
limited and
fragmented
across care
settings and
services.
Providers access
patient’s health
data through
different channels.
Home care,
community care,
and non-clinical
providers do not
have access to
Patient’s clinical
data.
Health
Applications are
not connected.

7. How does UMA address
these challenges?

8. The Standard - Isolated User Experiences
Me online x 120!
120 Walled Gardens
Services
Data
Account
Have information
about me
Know who I am
Provide me
with service(s)

9. Outcomes We’ve Learned to Live With
Organizations
normal is also
flawed
Effort & cost to repeatedly
establish, maintain an Identity
Inability to adequately
serve user needs
Friction connecting with
ecosystem partners
Our normal is
fundamentally
flawed
Limited access to our
own data!
Non-transparent consent and
sharing of our personal data
Disconnected user
journeys

10. We Can Do Better
What if… we can create a user centered ecosystem?

11. Interoperability of
Services and Data
Sources
UMA is Built for Wide Ecosystems
User Control, Privacy
and Delegation
One Authorization
Server protects many
Data Sources
Person requesting
access different from
data owner/subject
User can create a
fine-grained
authorization policy
Services are protected
from authorization
details

12. User Centered Data & Authorization
One AS protects many RS
One RS trusted many AS
The AS and RS are decoupled
● Alice can manage many RS’s from a single AS
● An RS can delegate authorization, account
and service management to the AS
● The AS does not need to hold or duplicate
personal data
OUTCOME: scalability and interoperability
Services
Data
Account
Have information
about me
Know who I amProvide me
with service(s)
Data
Data
Data

13. Services
Data
Account
Services are interoperable
Services decoupled from authorization details
● Services don’t need to know about every
authorization domain (eg scopes)
● Services can dynamically discover user
authx requirements
● Services interoperate against data types
(eg images) or standards (eg FHIR)
against many RS
Have information
about me
Know who I amProvide me
with service(s)
Service
Service
Service

14. User Directed Delegation
User requesting access is different from Data
owner
Data owner can create fine-grained policy
● There are many use-cases for
delegation/guardianship
● I am not the only person who needs to see
my data
● UMA models this, but doesn’t overspecify
● Policy can be against an entire API, or a
specific file/path
● Policy can consider both the client and the
Requesting User
Provide me
with service(s)
Have information
about me
Know who I am
Services
Bob’s
Account
Services
Data
Account

15. UMA Puts it All Together
There are still separate
organizations and domains.
However now data and
services are interoperable at
the direction of the person
Alice’s
Account
(AS)
Service
Service
Service
Data
Dara
Data
Bob’s
Services
Bob’s
Account

16. Demo: What might this look like?

17. Demo Scope
Alec’s
Account
(AS)
Health
Portal
Banting
Diabetes
Manager
BC EHR
ON EHR
Google
PHR
Google
Account

18. More Information About UMA
Get more information about the “How” of UMA:
UMA 2:0 Deep Dive: Applying User-Managed Access | Identiverse
2018
https://www.youtube.com/watch?v=0cCXJvJ6GUY
UMA Grant Spec
https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html
UMA Fedz Spec
https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-
authz-2.0.html

19. Case Study: US Health Care & Trustee
by HIE of ONE

20. Case Study: US Healthcare Challenges
(but similar in many countries)
● HIPAA is not based on patient consent
● Un-sustainable
● Health records are not patient-centered
● Un-sustainable
● 80% of outcomes are based on social determinants, not medical treatment
● Patient identity “matching” is a problem unique to US healthcare
● 30% of US health costs (~$ 1T) are unwarranted
● US racial & wealth disparities in survival are unmatched in the rich world

21. Imagine: A Universal Health Record
● Self-sovereign to the individual
● Global, like medical science
● Open source and peer reviewed, like medical science
● Standards-based
● No institutional lock-in
● Easy to spot disparities across zip-codes and nations
● A human rights economic and sustainability model

22. Imagine: UMA as the Core of a
Universal Health Record
● UMA 2.0 enables a self-sovereign Authorization Server
● No need to copy information through a “personal data store”
● No worry about loss of provenance
● Subject’s policies are never shared, just the decisions
● No patient matching issues
● Leverages self-sovereign identifier and verifiable credentials work
● Authorization policies are inherited from the community one
chooses
● HIE of One influenced and builds around UMA 2.0

23. Example Implementation:
Trustee® by HIE of One
● A self-sovereign authorization server enabled by standards
● Standards
● UMA 2.0 - for provenance and consent
● OAuth 2 - for legacy EHRs and Medicare
● OpenID Connect - for federated single sign-on
● W3C Verifiable Credentials - for self-sovereign single sign-on
● DID - W3C Decentralized Identifiers for non-repudiable signatures
● Public Blockchain (ETH) - decentralized timestamps for accountability
● Trustee Community - initializes the policies; competes for patients
● NOSH - A self-sovereign health record that doctors can sign-into with their
credentials

24. Ontario Identity, Authentication,
& Access by IDENTOS FPX

25. Case Study: Canadian Healthcare Challenges
(key similarities & differences to the US)
● PHIPA does have provisions for patient consent
● However access is still limited as:
● Health records are not patient-centered
● Un-sustainable
● Patient identity “matching” is a less of a problem
● Due to Provincially issued health insurance and identifiers

26. What impact will patient digital access have?
Digitally access personal health information (e.g.
lab test results, prescription information), book
appointments and track referrals.
Interact virtually with a health care provider via
video visit or secure messaging.
Digitally share important information with their
health care provider(s).
Digitally ensure that patients control access to
their data through consent and access controls.

27. Connecting Healthcare Journeys in Canada
Digital
Service
Providers
Identity
Providers
Data
Resource
Servers
Digital
Service
Providers
Data
Resource
Servers
Identity
Providers
FPX
Digital
Service
Providers
Data
Resource
Servers
Identity
Providers
FPX
FPX
National Health
Ecosystem
Regional Health
Ecosystem
Provincial Health
Ecosystem
UMA
Authorization
Hospital Ecosystem
Digital
Service
Providers
Data
Resource
Servers
Identity
Providers
FPX

28. Discussion

29. Q&A

30. Closing Remarks & Current Activity

31. Current UMA Working Group
● Interested? Join the working group! Meet every Thursday
● Formalizing interop test suite
● Profiles and extensions
● AS first flows
● General resource definitions
● UMA “wallet”

32. Important Current Work
● TxAuth / OAuth 3
● AS first
● Avoid client registration
● OAuth2 and UMA 2 are hard
● HEART
● Consent-based interop without “personal data stores” as intermediaries
● Influence TEFCA
● SIOP (Self-issued identity provider)
● Harmonize SSI and OpenID Connect