Page Comparison

...

1. Intro/Scope statement - what this report will cover
   
   1. overall objective of the document, what we will cover, what the reader should understand by the end
      
      1. Julie's use-case... how it is complex but typical. how to solve it in a way that's: technically feasible, respects Julie's rights to privacy and access to her information, respects the legal/regulatory policy requirements of the health system
      2. understanding UMA's unique value to aid this use-case (why can't it just be OAuth??)
         1. don't have to use all  of UMA, parts can be used to address different challenges
         2. how to make hard problems easier though UMA
      3. how UMA's interacts with other protocols (OIDC, FHIR/SMARTonFHIR/HEART, OAuth)
   2. What's not being covered
2. Description of concrete use-case (Julie)
   1. actors, data, systems (Primary care EMR, Specialist EMR, Pharmacy system, Payer system), identities *needs a diagram
   2. capabilities and responsibilities of actors (Julie, HCP, Organization) eg link to Policy?
3. Policy that impacts the use-case
   1. risk/liability vs patient agency (
   2. tension between policies (eg obligations to protect data vs obligation to enable sharing)
4. Core UMA/HEART overview
   1. why were even talking about UMA in this context
5. UMA application to use-case (steady state) *needs a diagram
6. Delegation state changes,
   1. how the health journey affects state.
   2. concrete events that create changes
      1. Julie turns 17,
      2. Julie sees asthma specialist
      3. Father get's invoice from health provider, submits claim to insurance provider
      4. Julie get's medication to treat STI, Provide create Rx, Pharmacist fills Rx and needs access to record (ie to see drug interactions)
7. Discussion? Tough corners, future topics
8. Conclusion
9. References, learn more

Working Draft Draft

(What about a report title and subtitle like this? Then we can have a series of reports with different subtitles. Solving Data Sharing Challenges with UMA: The Julie Adams Healthcare Use Case from PP2PI)

Introduction:

The Protecting Privacy to Promote Interoperability (PP2PI) Workgroup is a national multidisciplinary interest group of expert stakeholders across the industry assembled to address the problem of how to granularly segment sensitive data to protect patient privacy and promote interoperability and care equity. Stakeholders include more than 160 representatives from health care organizations, professional societies, standards development organizations, health IT vendors, Health Information Exchanges (HIEs) and Interoperability Frameworks, payers, government, government and nongovernment contractors, privacy law and ethics experts, and patient advocates, among others. (Shorten this)

...

In addition to the many levels of policy that must be interpreted, considered and respected by an organization, there are additional challenges around the appropriate implementation and communication with the person who is affected. For example, when a person gives their doctor access to an external health record or document, does that access extend to other providers in the clinic? If that default policy is no, can the doctor share access with another physician for a consultation, or when being covered by another doctor while going on an extended leave?

4.

...

Overview of UMA

...

and HEART

The User-Managed Access (UMA) standard and its companion Health Relationship Trust (HEART) profiles address some key challenges related to digital data sharing, including health data. It works by enabling a patient to specify which of her records, and even partial data sets, she would like shared with other parties. In essence, it allows her to state her precise policies for data sharing and have those policies adhered to by the various service providers and applications handling her data.

The UMA standard can be used by people and systems to protect and share data of any type, as long as it comes from a web server and has some kind of API. It is designed to enable practical, secure, auditable sharing controls in ecosystems that may involve many services and applications. The HEART profiles tune UMA for use with clinical health data use cases, ensuring security protection to a level appropriate for sensitive personal health data and providing instructions for interoperability with various HL7 value sets, along with the FHIR API and the SMART on FHIR architecture.

Both UMA and HEART share a goal of empowering the person at the center of this picture: she is the "user" in User-Managed Access. One or both may be used to address some of the key data sharing challenges illustrated by PP2PI.

Introducing the Actors in the Standard

Just like most standards, UMA lays out a number of actors, or "entities", in different roles, in order to specify how they need to interact so they can work successfully together. UMA is based on OAuth, the standard already used in SMART on FHIR, so it mostly uses names for these entities that come from OAuth.

• resource owner: This is the patient (or other data subject), or possibly a person who has special duties to act on her behalf in setting her sharing policies (for example, a legal guardian).
• requesting party: This is the person trying to get access to the data in question. When the resource owner specifies a sharing policy, she indicates her desired requesting parties as the target. (This concept isn't part of OAuth, only UMA.)
• client: This word stands for "client application", some web or mobile app that the requesting party is using to attempt access to the data.
• resource server: This represents the service provider hosting the data to be shared (or protected). A FHIR server could be an example.
• authorization server: This is a special kind of server whose job is to assess and mediate data access requests, on behalf of the resource owner.

Parking Lot

Julie Story - NL will continue to edit

...