UMA telecon 2021-12-09

Owned by Alec Laws
Last updated: Dec 09, 2021

UMA telecon 2021-12-09

Date and Time

Agenda

Minutes

Roll call

  • Quorum: No

Approve minutes

Deferred



Working Session on BLT Use-Case Report

Please find the new working document here: Notes, drafts, and WIP 


https://kantarainitiative.org/confluence/pages/viewpageattachments.action?pageId=17760302 


Goal for today:

  • Focus on one healthcare use-cases → outline for content we want to create 
  • Use first pp2pi use case and apply to UMA and UMA legal.
  • Be empathetic in the language


Notes:

  • we should always try to qualify the word "policy" to disambiguate (eg insurance policy, sharing policy)


Once you describe the relationship between people and technical systems (AS, RS), it becomes much easier to define what policy exists and where is can be applied. 

There is a tension between a patient's right to privacy and a providers (doctor's) need to have a complete medical history. 

There are many levels of policy, from federal (state, region, city, organization) and finally down to the individual patient. Also many types of policy (legal, compliance...

UMA enables patient driven policy, while other levels of policy are about risk management and liability. UMA is able to provide human rights enforcement. 

There has been recent shift and regulation to patient driven consent, wth the hope of giving them greater access and control over their data

UMA can align the incentives of people and organization at all of these policy levels, between those who have the most risk and liability to manage, and the lack of control given to the patient because of those risks.

Things are not fine-grained enough to enable sharing in safe ways, resulting in NO access. This is what info-blocking rules are starting to address, organizations have to do better to give control of the data to the subject 9patient)


"architecture of the future of consent, we need to rectify the asymmetry that exists today through peer based, asynchronous and human consent"

the pyramid: data protection, transparency, control. Only the middle layer is maybe appropriate to hold on a blockchain...

Notice of risk and proof of notice is required before consent can be meaningfully gathered.



Use-Case (initial state):

  • Julie is a adolescent woman, age 16
  • She has a GP, and also see's an asthma specialist at a health organization
  • The health organization provide a patient portal, including proxy access features
  • The health organization provides a provider portal, with greater access to the data
  • The health organization provides a HCProvider identity provider/directory services, includes roles and patient roster
  • Julie has given her mother proxy access to this health portal
  • Julies' mother tells the provider about her history with abuse, this is noted in the record, but should be hidden from Julie be default
  • Julie wants to hide reproductive health data from her mother (eg STI test history) in the portal, and her asthma specialist who can also access the record
  • Her fathers insurance covers most of her medical care
  • The insurance invoices should redact specific health information about Julie from her father, while he has a want(need?) to know what he's paying for (was the service even performed?!)


Examples of sensitive/conf health information areas, relevant to some providers - depending on role, hidden by default to th parent

  • social status (hungry, safe at home?)
  • sexual status (active? using condoms? STI?)
  • smoking and drug status 
  • mental health status



Technical Approaches:

  • HEART based sensitivity and confidentiality tagging. Different coding is mapped and tagged with this information (eg STI history observation get's tagged as sensitive)
    • to a proxy, can have default policy (share by default, hide by default)
  • use of the btg code, can turn an 'out of scope' access into a auditable and appropriate type of access
  • audit through 'privacy log' 


Out of scope:

  • big ad-tech and unintentional disclosure of information (eg Alice searches for X, and my parent starts seeing ads for dX)
  • multiple data subjects involved (parent, child) eg parent information sharing policy towards the child (history of domestic violence)
  • non-techinical data flows, eg phone calls etc where the human needs to make a fuzzy policy decision
  • (future) in the bow tie today, the AS 'licenses perm granting to' the RS, however isn't it the RS that is delegation the PDP to the AS? The RS is the responsible custodian of the data



Design Pattern of state changes:

  • specific to the resource, the RS is responsible to track resources, the resource subject(s) and other tagging



Outline of proposed document


  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 - 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


Who will take the responsibility to create a draft?

  • Nancy to take a run at section 2/3
  • Eve will work on the 16th ahead of the meeting

When can we meet next?

  • we want a draft for next session (Dec 16) and use it as a working session
    • start an hour earlier and have a 2hour call

How much can we use graphics vs paragraphs?

Do we want a page budget to limit scope?

  • yes 3-5 pages, try to not explain completely, just enough for the reader to understand

How specific do we want to be around policy (eg HIPPA, CCPA)?

  • can we refer to other docs, and pull the most relevant observations out


Future ideas:

  • exact same outline applied to financial services


AOB


  • Should we cancel some of the meeting at the end of the month, eg Dec 23 and Dec 30? 
    • Who would attend those sessions?
    • Alec to send a proposed meeting schedule for the rest of the year


Attendees

As of October 26, 2020, quorum is 5 of 9. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve, Steve)

Voting:

  1. Eve
  2. Steve
  3. Alec
  4. Sal
  5. Andi

Non-voting participants:

  1. Scott
  2. Nancy
  3. George

Regrets: