Page Comparison

Do we want to submit this for any conferences:

...

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
   2. What's not being covered - maybe hard to state at this point
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. what's not being covered about this whole use case
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
   2. how UMA's interacts with other protocols (OIDC, FHIR/SMARTonFHIR/HEART, OAuth, UDAP?)
   UMA application to use-case (steady state) *needs a diagram
   1. 5 values realized through UMA appraoch
5. Delegation state changes,
   1. how the health journey affects state.
   2. concrete events that create changes (Nancy to confirm what transitions we want to discuss)
      1. Visit to asthma sepcialist
         1. simple UMA sharing controlled by Sue → Dr Robert 
      2. Julie turns 13/ come's of age
         1. introduct quadrants and UMA state changes here
      3.  
      4. Julie turns 17,
      5. Julie sees asthma specialist
      6. Father get's invoice from health provider, submits claim to insurance provider
      7. Julie get's medication to treat STI, Provide create Rx, Pharmacist fills Rx and needs access to record (ie to see drug interactions)
6. Discussion? Tough corners, future topics
7. Conclusion
8. About this paper
   1. pp2pi and kantara blurbs
9. References, learn more

...

Status of This Document: This is an Editors' Draft Report produced by the User-Managed Access (UMA) Work Group. See the Kantara Initiative Operating Procedures for more information.

Copyright Notice: Copyright © 2021 Kantara Initiative and the persons identified as the document authors. All rights reserved. This document is subject to theKantara IPR Policy - Option Patent & Copyright: Reciprocal Royalty Free with Opt-Out to Reasonable And Non discriminatory (RAND) (HTML version).

...

Alternate Intro, separating IT from the story (Nancy to review)

This is a story about a young female patient.  As a child, her mother, as her guardian, is responsible for overseeing her health.  

...

Throughout Julie's journey there are many events where health information is accessed by Julie or other specialists. Those events are where Health IT would - or could - be used by Julie and her mother to have more agency and participation in her journey. In addition, there are several policies that must be understood and enforced by both people and technical systems as Julie receive care and transitions between different health providers. The following sections will expand on the complexity of health policy, introduce UMA and FHIR and finally show one way a UMA ecosystem can improve Julie's interaction throughout her journey.

3. Policy that impacts the use-case (WHY IS THIS SO HARD) 

"Policy" covers many different elements, (think about bolts) from data privacy and security requirements to the legal landscape the defines how health systems must operate. For example, who is liable to protect health data. Often the implementation of policy excludes the most important person - the patient who is the subject of the information 

...

• Need to highlight that policy must include the individual, and there have been many regulator changes to change this reality eg ONC info blocking rules(?)
• Can we add a simple picture of the policy stack, and maybe show how it's a continuum not discrete (however needs to be discrete in implementation!)
• Today's challenge is how to extend policy to include the most crucial person, the actual patient or subject of the information. but there are some (biz, operationals, legal,  technology, societal) challenges that... lead into UMA intro. 

4. Overview of UMA and HEART (WHY UMA, WHAT IT IS)

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.

...

Conclusion of this section: what is in/out of scope before we present our UMA application

**

...

5 How UMA is used to accomplish the story (Alec)

UMA in this use-case (ecosystem in place for this story)

• PCP run the AS and a FHIR Server (as the EHR)
• each specialist with their own system, that needs access to the EHR (does the PCP provide this client, or can the specialist bring their own client (BYOC))
  •  respecting original policy as data moves to other systems → can be in the policy section as part of the complexity

We need another section here where Julie's record is shared with Dr Robert her Asthma specialist.

• uma async, Dr Robert access ahead of time 

    In the story I have Julie's Mom doing the sharing since Julie is still a child.  If that is too confusing we can adjust the story to fit.  The reason I defined it that way is so that we can describe UMA from core concepts to more advanced, but we need to start Julie as a child so that we can demonstrate the state changes subsequently.

For the first section, when our use case describes basic UMA, I think this will be a good place to explain what UMA has over oAuth and highlight the increased security.

...

6. (state-diagram) Julie turns 13 - control moves from Sue to Julie (Eve if she can, otherwise Nancy will)

This section present's one possible health IT system, however in reality there is huge variations in technical services available and provided to patients. (addressing the policy and leveraging the features of FHIR and UMA)

...

• We start with Julie as a child, age 10, who’s mother controls access to her health records
• Then at age 13, Julie is an adolescent and has the right to control access to her health data
• Then at age 18, Julie has full control over her data  (Eve, I don't think we need this transition anymore.  In our story, Julie gets full rights when she is 13 - just to keep it simple.)
• Notes: The ages used here reflect the policies in effect in the state where the use case takes place.  But the correct age restrictions can be substituted to match the policies of each state.

...

7. UMA/HEART support for sensitive data (Nancy will try to get something in here)

This is where Julie turns 16 and chooses to keep some data private.

...