This slide deck deep dives into UPMC's use of WSO2 and the uncommon technical design decisions that have been necessary in order to make an industry status quo a thing of the past. Watch video: https://wso2.com/library/conference/2018/07/wso2con-usa-2018-the-power-of-one/

1. Senior Manager, Engineering
The Power of One:
Bringing Single User Design
into the Healthcare World
Chris Venturini

2. Prologue
Technology in Healthcare is Hard

3. UPMC
$16 billion global Integrated Delivery and Finance System (IDFS)
nonprofit health enterprise.

4. Healthcare has Multiple Persona Disorder
I am Chris Venturini.
I am a payer.
I am a PCP patient.
I am a potential customer.
I am a sleep patient.
I am a consumer.I am a radiology patient.
I am...
I am...
I am...
I am...
I am...
I am...
I am...
I am...

5. Personas:
Similar
But Different
As a parent of a child in healthcare...
You’re a patient.
You’re a payer.
You have a dependent on your insurance.
You’re a proxy for your child’s medical
records.

6. Master Data Management (MDM) or Master Patient/Person Index
(MPI) systems use fuzzy logic based on how similar records are be
able to associate records as the same person.
● Keyed on unique identifiers that are tied to a particular person’s persona
for each system.
Heavy Reliance on Fuzzy Matching

7. A User = The Patient = The Person
SteelersFan7

8. Chapter 1
This Scares the Hell Out of Me,
But I Like a Challenge
The Concept

9. 4 problems in Identity Management that we wanted to address:
● Attestation: Confirm that the remote user is the person is who
they claim to be
● Authentication: Give system access to a user based on some
input, e.g. password
● Authorization: Allow the user to perform actions within a
system based on a criteria
● Persona Alignment: Crosswalk the same person across multiple
organizational contexts
Problem Spaces

10. Given I’m a parent, when I login to the portal, I should see my
child’s records.
Your Personas = Your Authorization
As a payer, you have a dependent.
(Stored in a mainframe)
As a patient, you’re a proxy for your child.
(Stored in an EMR)

11. The Primary
Challenge
How do we create a centralized user
identity system that allows for all the
different lines of business maintain their
individual nuances, requirements, and
systems?
Is this even possible?

12. Chapter 2
Planning the Impossible
Discovery/Evaluation

13. Evaluated Four
Approaches
1. One persona to rule them all
2. Centralized store of all personas
3. A federated network of personas
4. Real-time resolution of a persona

14. Difficult to maintain business policies and manage conflicts.
In the previous example:
One Persona to Rule Them All?
Given I’m a parent, when I login to the portal I should see my child’s records.
What do you do when one is missing?
How do you enforce the integrity of the business policy?
As a payer, you have a dependent.
(Stored in a mainframe)
As a patient, you’re a proxy for your child.
(Stored in an EMR)

15. Will be problematic with data problems:
● Data eventually will be consistent
● Maintaining indexes
● Etc...
One Persona to Rule Them All?

16. Could quickly grow too large and unwieldy as integration systems
continue to increase.
One Persona to Rule Them All?

17. Maintain Siloed Personas?
More acceptable for the different lines of business requirements.
✓ Maintains policies
✓ Allows for current operational workflows
✓ Allows for the continued use of their systems

18. Maintain Siloed Personas?
Do we maintain central store of these personas?
Or create a federated network of identity providers, each with their
own persona store?
Master
Provider
Clinical
Provider
Insurance
Provider

19. Maintain Siloed Personas?
Do we fetch the personas in real time?
Identity
Provider
Clinical App
Clinical System

20. Maintain Siloed Personas?
The authentication system would need to be context aware to be
able to fetch the correct persona.
Identity
Provider
Clinical App

21. The Task
How do we create a centralized user identity system
that allows for all of the different lines of business
maintain their individual nuances, requirements, and
systems?

22. The Path Chosen
We chose…
One persona to rule them all
Centralized store of all personas
A federated network of personas
Real-time resolution of a persona

23. The Reason
✓ Allows for line of business ownership of the persona
✓ Maintains policies
✓ Allows for current operational workflows
✓ Allows for the continued use of their systems
✓ Scalable

24. Chapter 3
Building the Impossible
Execution

25. Platform Components
1. Identity Provider
2. Provisioning
3. Persona Alignment
4. Persona Retrieval

26. 1. Identity Provider
We identified the core requirements of solution.
● All common authentication/authorization protocols and
frameworks (SAML, OAuth, OIDC, etc)
● Customizable User Interface
● Strong custom development support with user authentication
lifecycle hooks
● Customizable data store

27. 2. Provisioning
Some downstream systems required that the user needed to be
provisioned in their system, either for persona retrieval or system
authentication.
● Cerner®, for example, required a record that associated an
authenticated user to a patient

28. 3. Persona Alignment
Once a user is created, we need to be able to associate that user to
all the different personas that exist within the health system’s
“ecosystem.”
System Name Name ID
Identity_Sys John Smith 123
Payer_Sys Jon Smith 456
Clinical_Sys John Smith 789

29. 4. Persona Retrieval
During the life cycle of user authentication, we need to:
● Retrieve the persona for that user based on the calling
application’s context
● Translate and package the persona into the user-based
assertions required for the leveraged protocol
● All in real-time

30. Chapter 4
It’s Alive
Actual Workflows

31. User Creation
Workflow

32. 1. Registration
The app directs the user to the registration page where the user
enters the required information to create an account. The client ID of
the app is used to identify the context of the line of business.
Registration
User
Interface
WSO2
IS

33. 2. User Creation
The registration user interface creates a new user within WSO2
Identity Server.
Registration
User
Interface
WSO2
IS
Outbound
Provisioner

34. 3. Downstream Provisioning
Our Outbound Provisioner creates the required personas in
downstream systems, including the master person index.
WSO2
IS
Outbound
Provisioner
Clinical
System
MPI

35. User Authentication
Workflow

36. 1. Authentication
The application directs the user to the login page where the
consumer’s credentials are validated.
WSO2
IS
Claims
Augmentation
Service

37. 2. Additional Claims Retrieval
If the consumer’s credentials are confirmed, WSO2 Identity Server
queries the Claims Augmentation Service passing the user’s unique
ID and the client ID of the App.
WSO2
IS
Claims
Augmentation
Service
MPI
Context
Specific
Claims
Service

38. 3. Personas IDs Crosswalk
The claims augmentation service queries for the all IDs related to the
consumer from the master person index.
WSO2
IS
Claims
Augmentation
Service
MPI
Context
Specific
Claims
Service

39. 4. Persona Retrieval
Based on the client ID of the originating application and the
collection of persona IDs, the Claims Augmentation Service queries
specific business services to retrieve the context specific persona.
WSO2
IS
Claims
Augmentation
Service
MPI
Context
Specific
Claims
Service

40. 5. Claims Augmentation
Once the persona for the particular line of business context is
returned, the existing WSO2 claims are augmented with the data
that was retrieved from the Claims Augmentation Service.
WSO2
IS
Claims
Augmentation
Service
MPI
Context
Specific
Claims
Service

41. 6. Application Authorization
The complete set of authorization based claims are returned to the
application. The app can now provide access to the user’s resources
based on its particular line of business needs.
WSO2
IS
Claims
Augmentation
Service

42. Multiple Contexts and Personas,
Centrally Authenticated
This platform allows for multiple lines of business to build applications
centrally authenticated while allowing for each line of business to
maintain their individual needs.
WSO2
IS
Claims
Augmentation
Service
MPI
Insurance
Services
Clinical
Services

43. Chapter 5
The Payoff
Mission Complete

44. User = = The PersonThe Patient
The Radiology Patient
The Payer
The Customer
The Lab Patient
…
AThe

45. THANK YOU
wso2.com

46. Keep In Touch!
ChrisV.me
@ChrisMVenturini
UPMCEnterprises.com
@upmcenterprises