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 3 Next »

  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
      3. how UMA's interacts with other protocols (OIDC, FHIR/SMARTonFHIR/HEART, OAuth)
    2. What's not being covered
  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. 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 - why were even talking about UMA in this context
  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
      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. References, learn more


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


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