Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »


Do we want to submit this for any conferences:

  • as a paper for identiverse - separate from the Kantara masterclass (CFP in Jan, pres in June)
  • Identity North is Jan 26, maybe can ready for that (at min for review)


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?)
  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 (Nancy to confirm what transitions we want to discuss)
      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. About this paper
    1. pp2pi and kantara blurbs
  10. References, learn more


Working Draft

(What about a report title and subtitle like this? Then we can have a series of reports with different subtitles. Solving Data Sharing Challenges with UMA: The Julie Adams Healthcare Use Case from PP2PI)

Introduction:

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. Stakeholders include more than 160 representatives from health care organizations, professional societies, standards development organizations, health IT vendors, Health Information Exchanges (HIEs) and Interoperability Frameworks, payers, government, government and nongovernment contractors, privacy law and ethics experts, and patient advocates, among others. (Shorten this, or move to the 'about this paper' section: Eve)

Recognizing that the problem is complex, PP2PI has organized into multiple collaborating working groups as indicated below.

PP2PI has created several use cases to illustrate both the challenges and the solutions to this complex problem.  User-Managed Access (UMA) is one standard that supports PP2PI’s core goal of securely sharing clinical data while protecting patient privacy.  This paper will delve into the specifics of the PP2PI ‘Adolescent’ use case and explain which specific problems can be best solved with UMA, including an explanation of how UMA adds value to this problem.

As can be seen, by the diagram above, the total problem will be solved from multiple directions.  As such, this paper will identify which specific aspects of the user story are ‘out of scope’, with the assumption that they will be solved in other ways.  As an example, this paper will not take a particular stance on what the policy is, but rather given a certain policy, this is how that policy will be enforced.  (It is understood that other workgroups will be exploring/resolving policy issues, etc.)


Notes:

Eve will try to shorten the current text

Can we move the 'what is pp2pi' 'what is kantara' to an end section? or an 'about this paper' 

2. Adolescent User Story

Nancy will add more about what is included and what is not. Note:  I will pull some details that we do not want to address in the body of the paper into appendices.

(Description of concrete use-case (Julie))

Julie Adams is an adolescent girl - 16 years old. Her health journey is unique and complex, however we would suggest that those attributes are typical of many journeys. 



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

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 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 could be an example.
  • 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]

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




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 - NL will continue to edit

Suggestion

  1. Convert this to a user story
  2. Make it simpler
  3. 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. 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. 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. 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. 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. 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. At the end – transition again to Julie as an adult


Appendix A - User story out of scope details

We will address and state why out of scope.  But will be primarily to keep the focus on our core content.


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.

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.

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


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
    5. Counseling for risky behavior
  • 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 3rd 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





  • No labels