Current Draft

Target Outline

Guidlines

• keep it simple, force ourselves to up-level the text to address a wide audience
• keep it short, 6 page limit max (exclus. of diagrams)
• keep it short, 8 lines per paragraph

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

Solving Data Sharing Challenges with UMA: The Julie Adams Healthcare Use Case from PP2PI (draft)

Version: 0.1

Editor: Nancy Lush

Contributors: Alec Laws (Chair), Eve Maler

Abstract: This Draft Report analyzes the "Adolescent" (Julie Adams) use case for granularly segmenting personal health data, developed by Protecting Privacy to Promote Interoperability (PP2PI), and assessing ways the User-Managed Access (UMA) protocol can address this challenge.

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 the Kantara IPR Policy - Option Patent & Copyright: Reciprocal Royalty Free with Opt-Out to Reasonable And Non discriminatory (RAND) (HTML version).

Why Read This Report?

The Protecting Privacy to Promote Interoperability (PP2PI) Workgroup, an interest group of expert stakeholders across the healthcare industry, is working on the problem of granularly segmenting sensitive health data. The opportunity is to improve patient privacy and to promote both interoperability and care equity. PP2PI has developed several use cases to illustrate the many challenges involved in this complex problem, as well as solutions.

User-Managed Access (UMA) standard supports PP2PI’s core goal of securely sharing clinical data while protecting patient privacy. This report delves into the PP2PI "Adolescent" use case, personified by "Julie Adams". We explain which specific problems can be best solved with UMA and the benefits of taking this approach.

Acknowledging that the problem space includes many business, operational, legal, technical, and societal ("BOLTS") aspects, we identify which aspects are in scope or out of scope for UMA. As an example, we won't take a stance on what policy would be appropriate, but rather given a certain policy, this is how that policy will be enforced.

Maybe we can breakout a disclaimer for the reader: this is a simple use case, the impl proposed is one of many viable solutions, the policies discussed are illustrative and with vary by region. 

The "Adolescent" Use Case

** Comments in 'Info' boxes are temporary notes to our team and would be removed later.

This is a story about a young female patient.  As a child, her mother, as her guardian, is responsible for overseeing her health.  Julie’s primary care provider provides a system for their patients to securely share their data.  As her guardian, Julie’s mother can share her data while Julie is still a child.  In the state where Julie lives, at the age of 13, Julie is able to make her own decisions about who has access to her data.  With these constraints in mind, our story unfolds.

These are the people involved with this story

• Julie Adams, female, Black, Hispanic, English speaking
• 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
  • Dr. Erica - PCP
  • Dr. Robert - specialist – asthma
  • Dr. Jones - dermatologist

As a child, Julie visits her PCP annually at a minimum.  At the age of 10, Julie is diagnosed with Asthma. Since Julie is only 10, her mother and guardian, Sue, has the ability to share her health records.  Sue creates a consent to share Julie’s clinical data with Dr. Robert, her asthma specialist.  Using FHIR and HEART, Dr. Robert is able to have immediate access to all of Julie’s data that her mother Sue authorized to share.

In the state where Julie lives, Julie is able to make her own decisions about who has access to her data at the age of 13.  Shortly after her 13^th birthday, Julie visits her PCP.  During that visit, control of her health record is turned over to Julie.  Julie is educated on how to use her portal and has the exclusive right to manage who has access.

Normally in a HEART/UMA system, the patient, or subject, has control of their own data.  There is a process called ‘delegation’ which transfers control to others.  In the case of a young child, that control is typically transferred at birth to one or more parents.  In the case of an adolescent coming of age, we use this ‘delegation’ process again, to return control back to the patient, Julie.  If Julie had the need to see another provider, she could easily share her data as needed.

When Julie is 16, she begins to experience sex and also begins using alcohol socially. Julie thinks her mother might not approve, but Julie does share this information with her pediatrician in confidence during her annual visit.  Her pediatrician discusses these details with her during the annual visit and makes notes in her record.  Her pediatrician provides relevant educational information and discusses safe behavior, as part of her overall evaluation for multiple potential risks of adolescents in transition. During their discussion, Julie and her PCP agree she should be using an oral contraceptive and it is prescribed.  Julie is also tested for STI, which comes back positive.  Julie is prescribed Zithromax to clear the infection.

Several months later, Julie experiences troublesome acne.  Her PCP sends her to a dermatologist.  Julie shares her data with the dermatologist but wishes to keep her sensitive information private.  When Julie creates her consent to share with her dermatologist, she requests that two areas of sensitive data not be shared:

• sexuality and reproductive health information sensitivity
• behavioral health information sensitivity

The system Julie is using to share her data is based on FHIR and HEART and supports data segmentation for privacy.  At the FHIR Resource Server, her data is ‘tagged’ with security metadata to indicate which part of her data has what sensitivity.  When her dermatologist, Dr. Jones, accesses her data, based on the computable consent created by Julie, and clinical data that has either a 'behavioral health' or 'sexual and reproductive health' information sensitivity will be redacted before it is sent to Dr. Jones.

NL - add an ending to the story

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.  Julie’s pediatrician provides a system for their patients to securely share their data. 

While she is still a child, Julie’s mother manages and controls Julie's data as her proxy. In the state where Julie lives, at the age of 14, Julie is able to make her own health decisions, including taking control of her health data. (However this age policy will vary by region, these complexities are discussed further in section policy) Julie's story unfolds over several years, including many health events, and involves many people:

• Julie Adams, female, Black, Hispanic, English speaking
• Sue Adams, Julie’s mother and Proxy, 45 years old
• Providers
  • Dr. Erica - Pediatrician
  • Dr. Robert - specialist – asthma
  • Dr. Jones - dermatologist

There are many events and encounters through her childhood, this report will touch on the following

• As a child, Julie's mother finds her a Pediatrician - Dr Erica
• Julie will attend annual appointments with her Pediatrician, Dr, Erica
• At the age of 10, Julie is diagnosed with Asthma and will visit an asthma specialist, Dr. Robert. Dr. Robert needs access to Julie's health record in order to effectively provide care. At the end of the appointment, he prescribes Julie an inhaler
• At the age of 14, Julie is able to take a greater role in managing her health, including control of her data. At her annual appointment, this new responsibility is discussed between Julie and Dr. Erica.  Julie is educated on how to manage access to her clinical record.
• At 16, Julie begins to experience sex and also begins using alcohol socially. Julie doe not feel comfortable discussing this with her mother, but Julie does share this information with her pediatrician in confidence during her annual visit.  Her pediatrician discusses these details with her during the annual visit and makes notes in her record.  Her pediatrician provides relevant educational information and discusses safe behavior, as part of her overall evaluation for multiple potential risks of adolescents in transition. During their discussion, Julie and her pediatrician agree she should be using an oral contraceptive and it is prescribed.  Julie is also tested for STI, which comes back positive.  Julie is prescribed Zithromax for the infection.
• Several months later, Julie experiences troublesome acne. Her pediatrician sends her to a dermatologist. However, Julie wishes to keep her sensitive information from her previous encounters private.

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/or 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 receives 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 

ref 21 century cures act that is driving a lot of current effort to change this outcome by... regulating that patient must have a simple way to access their information to their benefit

• should be mention HIPPA, CMS rule, or other US health laws? Or more general example, eg apple health? user held credentials
• are their international examples also? 

There has been a lot of work to having meaningful consent, however this is meaningful access and control of your information. As there is more digital access, there is more data and less reason to not have the patient be able to be empowered to participate in their care. 

• managing patient risk by letting the patient manage it

Some of the main challenges that limit sharing and control of information by the person are:
- risk-averse policy, to remain secure it's easier to not give access
- the need to respect many levels of policies. one health organization must respect rules from many levels eg federal, state and organizational. In many cases it's hard to respect them all without narrowing the sharing

Interestingly, on the provider side there is often much more open sharing by default. Access to this information is based on the providers need for information to give effective care, and their professional ethic's standards. In some health systems, this leads to many cases of inappropriate access (such as providers looking up celebrity or public figure's information). Sometimes this can be caught though audit and the provider [sure we can find some good reference to this, eg Rob Ford in ontario ~2017?]

In addition to the many levels of policy that must be interpreted, considered and respected by an organization, there are additional challenges around the appropriate implementation and communication with the person who is affected. For example, when a person gives their doctor access to an external health record or document, does that access extend to other providers in the clinic? If that default policy is no, can the doctor share access with another physician for a consultation, or when being covered by another doctor while going on an extended leave?

Notes:

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

The UMA standard can be used by people and systems to protect and share data of any type, as long as it comes from a web server and has some kind of API. It is designed to enable practical, secure, auditable sharing controls in ecosystems that may involve many services and applications. The HEART profiles tune UMA for use with clinical health data use cases, ensuring security protection to a level appropriate for sensitive personal health data and providing instructions for interoperability with various HL7 value sets, along with the FHIR API and the SMART on FHIR architecture.

Both UMA and HEART share a goal of empowering the person at the center of this picture: she is the "user" in User-Managed Access. One or both may be used to address some of the key data sharing challenges illustrated by PP2PI.

Introducing the Actors in the Standard

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 represents the service provider hosting the data to be shared (or protected). A FHIR server 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 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 

Can we link the different "techy" value up to the reader level can group under the headings: Security, Empowerment, Convenience, Applicability, Scale, - other Availability, Agency, Audibility, Interoperability 

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)

Now that we're familiar with the user case, challenges with policy and UMA/HEART technology, we will show how UMA is able to help accomplish this use case. Please keep in mind, this is one possible application of UMA and the other health IT, in reality there are many way to use the technology. The ability to change to accommodate different IT systems and policy constraints is one reason why UMA and HEART are so powerful.

"As a child, Julie's mother finds her a Pediatrician - Dr Erica"

 Dr Erica's office strives to include patients, and their guardians, in their care plans.  To help achieve this goal, they have selected an Electronic Medical Record (EMR) system that supports UMA, FHIR and HEART. At this first visit, Sue is provisioned i) login credentials and ii) and link the the EMR portal - including the UMA dashboard. Dr Erica educates Sue on how she'll be able to see Julie's health information in this portal, and also how Sue will be able to view, modify and accept anytime Julie's information may be shared with other parts of the health system. As Dr Erica gathers information about Julie, she records it into the EMR record.

After the appointment, Sue logs into the portal at home and is able to see the information captured during that first visit, such as the family history, and height and weight measurements for baby Julie. As Sue and Julie continue to attend annual check-ups, more data is stored in Dr Erica's EMR about Julie. Sue is also able to launch HEART enabled applications directly from the EMR (even if she doesn't know it) to see charts that track Julie's growth and development. 

[ bow tie diagram with UMA, EMR and some HEART apps accessed by Sue? ]

"At the age of 10, Julie is diagnosed with Asthma and will visit an asthma specialist, Dr. Robert. Dr. Robert needs access to Julie's health record in order to effectively provide care. At the end of the appointment, he prescribes Julie an inhaler"

During this annual checkup, Julie and Sue both express some concerns about some shortness of breath when Julie plays with her friends. Dr Erica believe Julie may have asthma and recommends that they visit a specialist to confirm the diagnosis and 

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

"At the age of 14, Julie is able to take a greater role in managing her health, including control of her data. At her annual appointment, this new responsibility is discussed between Julie and Dr. Erica.  Julie is educated on how to manage access to her clinical record."

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

"At 16, Julie begins to experience sex and also begins using alcohol socially. Julie doe not feel comfortable discussing this with her mother, but Julie does share this information with her pediatrician in confidence during her annual visit.  Her pediatrician discusses these details with her during the annual visit and makes notes in her record.  Her pediatrician provides relevant educational information and discusses safe behavior, as part of her overall evaluation for multiple potential risks of adolescents in transition. During their discussion, Julie and her pediatrician agree she should be using an oral contraceptive and it is prescribed.  Julie is also tested for STI, which comes back positive.  Julie is prescribed Zithromax for the infection."

"Several months later, Julie experiences troublesome acne. Her pediatrician sends her to a dermatologist. However, Julie wishes to keep her sensitive information from her previous encounters 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
• btg/ER/advanced directives

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

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.

PP2PI – highlighted data exchange methods

• EHR to Patient Portal (dual access/multi-level access)
• EMR to public Health reporting system (Optional) (Recommend skipping)
• EMR to payer (This is important re EOB – let’s discuss – is this one out of scope?
• Provider to provider (we added - Recommend highlighting)
• EMR to researcher (we added)

Note: This case of addressing just parental access is too limiting.  I think need to consider re sharing with other providers.  And the provider type does matter

                ex: Sharing with referring doc for Asthma is one view, but sharing with a behavioral health specialist or a new PCP might be different.

Privacy and Harm concerns

• Privacy risk -patient: Parents have single level of proxy portal access and can see all information about the visit, including sensitive/private information.
  1. UMA could help here, once the child is of age, they can define what information is available to the parent.
• Privacy risk – proxy: If information about the mother's experience of domestic violence are included in the portal, this could result in the patient learning information the parent does not want to share. 
  1. This seems like it should be a policy/process issue. At what point should this be removed from the child’s chart?
  2. On the other hand, wouldn’t you want a 17-year-old girl to be aware of domestic violence against her mother. I would expect the 17-year-old girl would also be at risk and should be educated.   My thought is that this should go back to the PP2PI policy group to refine prior to resolving with a technical solution.  I would call this out of scope with these notes.  Are we asking for the impossible?
• Harm Risk – Patient: Unknown risk of harm from either parent based on information learned during this visit. History of CPS involvement suggests that this may be a real issue.
  1. This is where UMA comes in. Julie has a right to control access and she can say that she will not share sensitive information
  2. Also note that this is a case where details are just withheld. There should not be any notice to the parent that details are withheld.  (Unlike potential case of sharing with a provider – where they might need to know that not all information is shared.)
• Harm Risk – Proxy: If the parent’s past domestic violence history is known by the patient, this could affect the trust in child's relationship with her father and could erode parental confidence.

This could also result in information being shared with other family members that may have negative consequences.

                See comment above on privacy risk for proxy.

Specific data concerns

• Meds that are confidential
  1. Oral Contraceptive – may not want parents to be aware
  2. Zithromax for infection as a result of STI
• Lab work
  1. Urine Gonorrhea/Chlamydia
• Conditions
  1. Asthma (not sensitive)
  2. STI management
  3. Chlamydia
  4. Pregnancy prevention - this is not a condition but an intervention
  5. Counseling for risky behavior - this is not a condition but an intervention
• Referrals
  1. Pulmonologist – Assume related to asthma – non sensitive
• Family History (How do we want to handle these re sharing?  Should we ask for policy direction?)
  1. Father, on Lipitor
  2. Mother, hx of fibroids, depression, SUD
• Social History/SDOH elements
  1. The mother has a history of being a victim of domestic violence. Her parents separated with an order of protection for the mother that the patient is unaware of.
  2. Patient does not smoke tobacco but drinks every weekend.
  3. Smokes marijuana three times a week. Occasional vaping.
• Insurance Coverage
  1. Commercial via father’s employment.
  2. Payroll deduction for 20% of premiums for family plan.
  3. Cost sharing of 20%.
  4. Father is the policy holder and receives EOBs and other communication from his insurance company.
     1. Think about what this would look like, for instance there may be lab work – but it certainly would not include lab results. The father already does not have access to the clinical data.  What could be in here that could be harmful?
  5. This plan covers the cost of OCP.

Clinical setting notes

• Both reproductive health and primary care provided at one visit, likely within the same EHR note.
• Details
  1. Patient is a 17 years old, almost 18 years old, female with a past medical history of asthma who presents to her pediatrician in an outpatient clinic in California for her Well-Child Check.
  2. Patient is sexually active with 1 male partner, using condoms “most of the time.” She denies any urogenital complaints. 
  3. Patient requests a prescription for an oral contraceptive pill.
• Organizations: Community Health Center EHR, Regional HIE, LAB, Pulmonologist EHR, Insurance Company
• Portal policies:
• Patient policies
  - at age 13, (our center 12yo )patients are given the option to open a portal account and can decide if they want to share information with their parents (parents may or may not be given access).
  
  Concerns & Questions
  Are these choices reviewed regularly?
  Is this all-or-none access, or selective?
  If selective, how granular is selectivity?
  Information about the proxy (order of protection against father) hidden from patient
  
  • Proxy policies
  parent has access until age 13 (at our center 12yo), when it is automatically turned off and child (patient) has to allow access.
  Proxy access identical to adult patient access
  
  Concerns & Questions
  What pressure might there be on a 13 year old to allow access?
  How will that differ at age 17?
  Information about patient (repro history) needs to be hidden from proxy

Triggering Events

• Actions by patient or proxy
  1. Phone call (i.e., to clinician/pharmacy/lab)
  2. Secure communication message (emails, texting, portal, third party)
  3. Goes to pharmacy (picks up medication)
  4. Goes to lab (specimen collected)
  5. Goes to portal
  6. Using a 3rd party app to request information via API
  7. Written request
  8. Patient responds to on-line query (remote checkin, CHADIS, JotForm, etc.)

• Actions by clinician
  1. Phone call (i.e., to patient or proxy)
  2. Secure communication message (emails, texting, portal, third party)
  3. Orders lab
  4. Orders medication
  5. Writes notes
  6. Submit a charge to insurance
  7. Sends statement for personal payment
  8. Make a referral
  9. Manage prior auth requirements
  10. Collects payment from insurance
  11. Recalls patients based on clinical details"
• Actions by 3^rd Party
  1. Request from attorney (subpoena)
  2. Request from law enforcement
  3. QBCDE query (Carequality, etc.)
  4. HIE/CIN report
  5. Insurance EOB sent to father--may include cost sharing amount due for visit about which father is unaware

Access to data

1. Stakeholders Sensitive Information
   1. NL grouped info
   2. Covered under HIPAA
      1. PCP
      2. PCP staff
      3. Specialist
      4. PCP billing department
      5. Specialist billing department
   3. Should not be receiving clinical data – be more specific about what they may receive that is sensitive
      1. Payer
   4. Relationships – should be controlled by UMA
      1. Parental figure
      2. Patient partner(s)
   5. Cross facility sharing – should be up to Patient sharing options at granular level. Or patient could chose to share with an HIE but that system should support patient-mediated sharing.
      1. Members of RHIO and Epic Care Everywhere

OK, so this is my review of everything they presented in their use case.  Also look at my earlier summary overview of Policy, UMA, Delegation.

My gut is to call out what is out of scope and why.  Then state what is in scope and how that is supported under UMA.

NL also address the areas of tensions.  PP2PI responsibility to define what policies need to be in place to decide how these should best be handled.

Add to out of scope for purpose of discussion in this paper

                PCP vs PCP office, individuals vs roles

                                Explain claims