Page Comparison

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

...

5. UMA application to use-case (steady state) *needs a diagram

6. UMA/HEART support for sensitive data

8. Conclusion

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 - This is just the outline of the story - we can keep until we are happy with what we have above

Suggestion

1. Done - Convert this to a user story
2. Done -Make it simpler
3. Done - Start with an overview of PP2PI and share that other groups are addressing policy issues
   1. Insert their diagram
4. 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.
5. Discuss patient policy trumping organizational policy
6. Outline simpler story for illustration
   1. Done - Start with Julie as a child and her mother controls access to her record
      1. Demonstrate a simple use case of her mother sharing records with another physician on her behalf (straight UMA)
         1. 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.
   2. Done - Julie turns 13
      1. She is educated on how to use her portal and has exclusive right to manage who has access.
      2. (For now – skip the issue of multi-subject data in one record. We will assume this is not the case in our user story.)
   3. 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.
      1. 1. Add the specifics per the PP2PI user story
      2. 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
      3. Done - Continue story with her sharing her data, removing sexually and behave health sensitive data
      4. Discuss how UMA/HEART manages the transition from the consent to the protocol
      5. Discuss what gets redacted
      6. Describe the FHIR scope call
      7. Describe what is exchanged.
   4. Will skip this as already have a transition - At the end – transition again to Julie as an adult

Appendix A - User story out of scope details

We have based our user story on the PP2PI adolescent use case.  For the purpose of this paper, we intentionally simplified the story so that we could focus on the key value-adds UMA brings to solving this problem.  The intent was to keep the story simple so that the focus was on the solution.  In subsequent updates to this story, it is the intent to expand how additional details can support the more nuanced details.  For this whitepaper, we took the liberty of organizing the story so that we could build on the UMA/delegation functionality in a way that allowed the story to flow.

NL - will expand here.  Include some of the details we skipped.

Appendix B - Additional UMA Features

UMA features that would apply but were eliminated from the core paper to keep the message focused.

Example - claims.  Support for not only sharing with Dr. Bob, but roles within Dr. Bob'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)

Description of use case – Adolescent Use Case

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:

1. Protect elements of reproductive health information in the EHR with flexible protection for varying jurisdictional differences and adolescent preferences consistent with state and federal laws. Example - provide a means with which to limit sharing of the STI history with the asthma specialist, unless medically necessary.
2. Protect elements of reproductive health information in the EHR with flexible protection for varying jurisdictional differences and adolescent preferences consistent with state and federal laws. Example - provide a means with which to limit sharing of the STI history with the asthma specialist, unless medically necessary.
3. Ensure that the lab or pharmacy does not call the proxy with test results or prescriptions and that the billing/EOB information does not disclose reproductive health information to the parent.

People:

• Julie Adams, adolescent female, age 17, Black, Hispanic, English, Sex: Female, Gender Identity: Female, heterosexual (Sexual orientation is actually sensitive data)
• Sue Adams, Julie’s mother and Proxy, 45 years old
• Father does not have access to her clinical data, but pays the health bills
• Providers
  • PCP
  • specialist – asthma
  • Pharmacy

About This Report

This report is produced by the User-Managed Access (UMA) Work Group of the Kantara Initiative. It is intended to be the first of a series of short informative reports. Kantara Initiative, Inc. is an international ethics based, mission-led non profit industry ‘commons’ focusing on growing and fulfilling the market for trustworthy use of identity and personal data. UMA is an award-winning OAuth-based protocol designed to give an individual a unified control point for authorizing who and what can get access to their digital data, content, and services, no matter where all those things live.

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.

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.Is delegation in this section?

Transitions:

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

6. UMA/HEART support for sensitive data

8. Conclusion

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

Appendix A - User story out of scope details

We have based our user story on the PP2PI adolescent use case.  For the purpose of this paper, we intentionally simplified the story so that we could focus on the key value-adds UMA brings to solving this problem.  The intent was to keep the story simple so that the focus was on the solution.  In subsequent updates to this story, it is the intent to expand how additional details can support the more nuanced details.  For this whitepaper, we took the liberty of organizing the story so that we could build on the UMA/delegation functionality in a way that allowed the story to flow.

For the purpose of this whitepaper, we have simplified Julie's story;  She starts as a child, then transitions to an adolescent where she is old enough to make certain decisions. We describe the simple UMA process of sharing data at a granular level,  Then later, when Julie's sharing needs become more complex, we demonstrate how she can control her data at a granular level. We also explain how delegation is used to transfer who has the right to make those access decisions.

We have omitted these details, simply to keep the story simple:

• The PP2PI story focuses on Julie's portal access.  We broadened the story to assume any health data repository that allows the patient to control who has access to their health records. (Patient-mediated exchange.)  We also address the broader use case where unrelated individuals have access.  UMA could certainly be used for portal access as well.
• There may be some states where the parent and child have different levels of access.  We reduced our story for simplicity, showing those rights transferring completely as of a certain age.
• We illustrate patient policy only, but in fact, most UMA implementations combine some level of additional policy with patient-defined policy.
• 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.
• UMA can be used to share data with many types of organizations (public health, research, etc) but our story is limited to patient-to-provider, to keep it simple.

We have omitted these details because they are out of scope:

• We do not explicitly describe how labs, pharmacies, or payers manage sharing of sensitive data.  Certainly, UMA could be used to help these organizations.  Best practices should have policies in place to eliminate this risk.  (Ex:  A pharmacy might call to say an Rx is ready but should not ever say what the Rx is to anyone but the patient.  There are currently edge cases that need to be defined by other PP2PI workgroups.)
• There are elements in the PP2PI story that will be addressed by the policy/ethics workgroups.  We consider these out of scope for this paper at this time.
• There are inherent tensions around the idea of not sharing all clinical data with a clinical provider.  We will consider this out of scope for this whitepaper.  It is the right of the patient to withhold information if they desire.  Frankly, that has been the state of medicine forever. Some implementations tell the receiver that they are not seeing full information and in such cases, that process is explained to the patient before they use the system.  There are other solutions to solve this dilemma, which are out of scope for this paper.

NL - will expand here.  Include some of the details we skipped.

Appendix B - Additional UMA Features

UMA features that would apply but were eliminated from the core paper to keep the message focused.

Claims:  For the sake of simplicity, our user story covers sharing data with individuals like Dr. Robert and Dr. Jones.  There are times when the intent is to share with just one individual and other times when the intent is to share with anyone in a particular practice.  UMA can support sharing with either individuals or groups of individuals that have certain roles.  In the authentication layer, claims can be used.  When an individual is authenticated, they can also be verified that they meet certain 'claims', such as they are a type of physician, they are an administrative assistant to Dr. Jones at a particular organization, they are an ER doc at a specific hospital with rights to 'break the glass', or an EMR, and that list goes on.  Then the data subject might share with specific roles.

• add more delegation examples
• Multi-data subjects

Temporary Appendix - Julie's use case full details for reference (Will omit from final paper)

Description of use case – Adolescent Use Case

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:

1. Protect elements of reproductive health information in the EHR with flexible protection for varying jurisdictional differences and adolescent preferences consistent with state and federal laws. Example - provide a means with which to limit sharing of the STI history with the asthma specialist, unless medically necessary.
2. Protect elements of reproductive health information in the EHR with flexible protection for varying jurisdictional differences and adolescent preferences consistent with state and federal laws. Example - provide a means with which to limit sharing of the STI history with the asthma specialist, unless medically necessary.
3. Ensure that the lab or pharmacy does not call the proxy with test results or prescriptions and that the billing/EOB information does not disclose reproductive health information to the parent.

People:

• Julie Adams, adolescent female, age 17, Black, Hispanic, English, Sex: Female, Gender Identity: Female, heterosexual (Sexual orientation is actually sensitive data)
• Sue Adams, Julie’s mother and Proxy, 45 years old
• Father does not have access to her clinical data, but pays the health bills
• Providers
  • PCP
  • specialist – asthma
  • Pharmacy

About This Report

This report is produced by the User-Managed Access (UMA) Work Group of the Kantara Initiative. It is intended to be the first of a series of short informative reports. Kantara Initiative, Inc. is an international ethics based, mission-led non profit industry ‘commons’ focusing on growing and fulfilling the market for trustworthy use of identity and personal data. UMA is an award-winning OAuth-based protocol designed to give an individual a unified control point for authorizing who and what can get access to their digital data, content, and services, no matter where all those things live.

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.

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.

Parking Lot

Julie Story - This is just the outline of the story - we can keep until we are happy with what we have above

Suggestion

1. Done - Convert this to a user story
2. Done -Make it simpler
3. Done - Start with an overview of PP2PI and share that other groups are addressing policy issues
   1. Insert their diagram
4. 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.
5. Discuss patient policy trumping organizational policy
6. Outline simpler story for illustration
   1. Done - Start with Julie as a child and her mother controls access to her record
      1. Demonstrate a simple use case of her mother sharing records with another physician on her behalf (straight UMA)
         1. 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.
   2. Done - Julie turns 13
      1. She is educated on how to use her portal and has exclusive right to manage who has access.
      2. (For now – skip the issue of multi-subject data in one record. We will assume this is not the case in our user story.)
   3. 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.
      1. 1. Add the specifics per the PP2PI user story
      2. 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
      3. Done - Continue story with her sharing her data, removing sexually and behave health sensitive data
      4. Discuss how UMA/HEART manages the transition from the consent to the protocol
      5. Discuss what gets redacted
      6. Describe the FHIR scope call
      7. Describe what is exchanged.We 
   4. Will skip this as already have a transition - At the end – transition again to Julie as an adult

Transitions:

• To really demonstrate UMA, it would be beneficial to start with Julie as a child, say age 8, 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
• 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.

...