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

...

NL - add an ending to the story

3. Policy that impacts the use-case

"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

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. UMA application to use-case (steady state) *needs a diagram

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, Julie 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.

...

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

    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.

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

Is delegation in this section?  Yes, this would be the delegation section where we show control moving from Julie's mother to Julie.  But she is still only 13, so she is educated and the state changes, but no information is shared here.

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

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

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

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.

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

Parking Lot

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

...