Do we want to submit this for any conferences:
...
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).
...
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 normally 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 This represents the service provider hosting the data to be shared (or protected). A FHIR server could be is an example of a resource server.
- 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.
Notes on section 4:
\[Together the RqP + UMA AS add a lot of new bredth and capability to the system, compared to OAuth]
...
| Info |
|---|
For AS, can we state that it also can support more traditional policy in addition to its work on behalf of the resource owner? Or it may be more detail than we need here. |
Notes on section 4:
\[Together the RqP + UMA AS add a lot of new breadth and capability to the system, compared to OAuth]
Eve has a good slide comparing the two (although somewhat "techy") There are also some points from recent (past 2 month) WG calls that we can
...
There is more to consider in step with the technology capability of UMA, groups needs to consider all the BOLTS when designing solutions and not 'leave it to the reader' to sort out themselves
Parking Lot
Julie Story - NL will continue to editThis is just the outline of the story - we can keep until we are happy with what we have above
Suggestion
- Done - Convert this to a user story
- Done -Make it simpler
- Done - Start with an overview of PP2PI and share that other groups are addressing policy issues
- Insert their diagram
- Add 2 paragraphs on the fact that there are tensions in the HC community around certain issues. Those need to be addressed and resolved by the Policy WGs. We will make these assumptions.
- Discuss patient policy trumping organizational policy
- Outline simpler story for illustration
- Done - Start with Julie as a child and her mother controls access to her record
- Demonstrate a simple use case of her mother sharing records with another physician on her behalf (straight UMA)
- Note to Eve: 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. If we can nail that part of the message it may help in all healthcare UMA implementations.
- Demonstrate a simple use case of her mother sharing records with another physician on her behalf (straight UMA)
- Done - Julie turns 13
- She is educated on how to use her portal and has exclusive right to manage who has access.
- (For now – skip the issue of multi-subject data in one record. We will assume this is not the case in our user story.)
- Done - When Julie is 16, she begins to experience with Sex and also begins using alcohol socially. Julie knows her mother would not approve but does share it with her pediatrician in confidence. Her pediatrician discusses these details with her during annual visit and makes notes in her record. Her pediatrician provides relevant educational information, discusses safe behavior, as part of her overall evaluation for multiple potential risks of adolescents in transition.
- Add the specifics per the PP2PI user story
- Add some policy to the stack - ex default policy sexual status not shared with her mother. Julies decides either sticking with that or overriding and sharing with her mother
- Done - Continue story with her sharing her data, removing sexually and behave health sensitive data
- Discuss how UMA/HEART manages the transition from the consent to the protocol
- Discuss what gets redacted
- Describe the FHIR scope call
- Describe what is exchanged.
- Will skip this as already have a transition - At the end – transition again to Julie as an adult
- Done - Start with Julie as a child and her mother controls access to her record
...
Example - claims. Support for not only sharing with Dr. Bob, but roles within Dr. Bob's organization.s organization.
Add to out of scope for purpose of discussion in this paper
PCP vs PCP office, individuals vs roles
Explain claims
Temporary Appendix - Julie's use case full details for reference (Will omit from final paper)
...
The adolescent use case is focused on protecting the patient's reproductive health private from the parent who is financially responsible for the patient. - This was only one small part of the original use case and I omitted it from the user story so that we could focus on key points where we provide the most value.
Priorities of Objectives:
...
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." It develops use cases, serves as the steward of a terminology value set (system of codes or keywords), provides implementation guidance, and works towards adoption.
| Info |
|---|
remove phrase 'serves as the steward of a terminology value set (system of codes or keywords),' - they realize it is a problem and recommend that a steward be found |
Although some members of the UMA Work Group take part in the PP2PI effort as well, this report has no formal relationship with PP2PI. We seek feedback from PP2PI and others on this report.
...