HEART Use Case: Alice Selectively Shares Health-Related Data with Physicians and Others [UMA, FHIR]

Problem Statement

This use case highlights the business, individual, and environmental benefits of enabling patients to share selective access to a variety of online health-related resources with medical professionals and others in a User-Managed Access (UMA) and FHIR API context. This use case also draws attention to a baseline set of technical issues involved in these interactions so that the HEART Work Group can consider appropriate semantic profiling solutions for these issues.

Benefits

This use case aims to demonstrate the following benefits:

• Individual control of health-related data sharing: The scope of the HEART work takes into account a patient as an actor in a widening context, with providers, other caregivers, family members, and consumer interactions all playing roles. As stated by the JMIR mHealth and uHealth article Privacy-Related Context Information for Ubiquitous Health (citations elided): "In ubiquitous health, trustworthiness and privacy are key challenges. There are privacy threats created by autonomous and hidden processing of information and rich contextual metadata. There is no predefined trust between participants, and the business objectives, needs, interests, and policies of stakeholders may be unknown to the individual. .... The lack of predefined trust and privacy risks emphasizes the importance of an individual's ability to control his or her privacy."
• Data quality and accuracy: There are many consequences of bad data; an automated feed vs. a manual source can fix that data. From a recent New York Times article called Let Patients Read Their Medical Records: “One study found that there’s complete agreement between medications listed in the electronic health record and what patients actually take only in about 5 percent of patients. Another study found that 43 percent of medications listed in the electronic health record were inaccurate — with 29 percent having been stopped and 14 percent changed. Many allergies and adverse drug reactions aren’t recorded. Research from the Veterans Health Administration found that 60 percent of patient records had at least one error. From 2013 to 2014, the percentage of lawsuits related to electronic health record issues doubled and is expected to rise.” Additionally, there are cost, inefficiency, and satisfaction consequences of having to re-input the same data over and over again, especially when it’s both a patient filling in forms by hand and an assistant keying that data into a computer system. Using the example of medication record data, here is a summary of benefits:
  • Reduce prescribing errors and concomitant safety errors (e.g. related to contra-indications and allergies) through availability of an up-to-date medication list
  • Reduce delays in comparing medication lists across systems
  • Updates as needed by the querying system when medications change even if asynchronous to a patient visit
  • More efficient staff procedures and improved patient satisfaction involved in patient visits; no time wasted in medication review or keying new data
• Improved clinical research data sets: As the new NIH and ONC pilot program Sync for Science (S4S) demonstrates, individual data donation is a key method for supporting the US Precision Medicine Initiative. Note that success of this benefit relies in large part on successful delivery of the prior two. First, data needs to be accurate to be useful. Second, data donation in a free society needs to be willing. Recent research in the UK showed that 53% supported the use of their data by commercial organizations for research, that people generally preferred health data not also be used for purposes such as marketing, and that 17% were not willing to share data at all.
• Better care: Assume that Alice’s mother Diane had a long-ago incidence of breast cancer and currently has hypertension; Alice thus has various risk factors and would like to take an early detection approach to her own care, as well as being in a caregiver position to her mother. Cross-family-member data sharing for this purpose would therefore be valuable. From the New York Times article: “Research suggests that only about 40 percent of patients are offered online access to their medical records. Of those given access, only half choose to view them — but 80 percent of those who do find it useful. A quarter of patients remain unaware of their right to an electronic copy of their medical records. But patients who frequently access their medical records may be more motivated to take control of their health — and in a better position to correct outdated or erroneous information.”
• Architectural scalability in patient-provider situations: The architecture of prior provider-to-provider technologies have not been able to scale naturally to patient and consumer environments. This is where an API-first approach has an edge.

Characters

This use case involves the following cast of characters (check against choice of sharing scenarios ultimately chosen):

• Alice is an adult.
• She is a patient of primary care physician Bob and ophthalmologist Erica.
• She is married to Carl.
• She has an elderly mother Diane.
• She becomes a donor of health data to clinical research data network RNet.

Data and services

Alice's will hold a significant subset of PGHD, Common Clinical Data Set, and virtual clipboard data in a FHIR-enabled PHR system (PHR A):

1. Virtual clipboard
2. Basic patient profile /Patient)
3. Medication history (/MedicationDispense, /MedicationAdministration)
4. Immunizations (/Immunization.vaccineCode , /Immunization.status)
5. Allergies (/AllergyIntolerance)
6. Problem list /Condition.code, /Condition.status)
7. Labs (/DiagnosticReport.code - LOINC /DiagnosticReport.codedDiagnostics - SNOMED)
8. Basic insurance info? EOB?
9. (what else? Keep it simple)

Alice will put her PHR data under the protection of a sharing console A. Dr. Bob and Dr. Erica use FHIR-enabled EHR systems EHR B and EHR E, respectively.

A clinical data research network called Aggregator has an app (app CDRN) that is able to use Alice's donated data in deidentified form, and ultimately contribute it to a third-party research app or service that uses the deidentified data.

Alice shares some of her PHR data with Carl, through an app he uses for the purpose (app C). Similarly, her mom Diane shares some of her own PHR data with Alice through an app Alice uses (app A).

Flow goals

Following are technical goals of the flows included in this use case that demonstrate particular UMA capabilities:

• Enabling the patient to choose to share data differentially to two different requesting parties
• Enabling the patient to manage sharing and revocation from one PHR to multiple EHRs from one place
• Showing an audit trail of what data the patient shared and what consents the patient revoked

Challenges

This use case specifically highlights the need for profiling solutions to the following challenges:

• Can we anticipate what type(s) of identity ecosystem(s) are likely to arise given this use case? Knowing this will impact the trust elevation scenario.
• How does Alice express her wishes to selectively share device data and other data with doctors and others? What information does she have to supply about those parties in order for trust in them to be successfully elevated? What other information is required?
• What are the exact subject (grantee) constraints Alice would need to specify? What are the correct "non-person entity" patterns at play?
• What other constraints might Alice want to impose on sharing her data? Might she realistically impose purpose-of-use limitations? Length of access limitations? Other limitations?
• In what cases might each resource server reasonably want to override on Alice’s sharing wishes due to liability concerns? (The UMA WG calls this #RSctrl.)
• • In what cases might Alice reasonably want to doubly override each resource server’s wishes in those cases and why? (The UMA WG calls this #ROctrl.)
• Privacy concerns about patient-to-patient health concern/family history data sharing
• • When does history sharing cross a line?
• • Can purpose-of-use limitations make a difference in practical terms? (data for Alice’s use vs. for Diane’s use)

Summary of sharing scenarios

We are documenting one sharing scenario (or "flow") at a time.

• (Proactive flow?:) Alice setting up provisioning of basic data prior to first visits to Dr. Bob (and Dr. Erica for extra credit?): PHR A to EHR B and EHR E.
• Alice being able to monitor and control access by Dr. Bob: Alice interacting with sharing console A.
• (Proactive flow?:) Alice sharing her medication list with her spouse: PHR A to app C.
• (Reactive flow?:) Agreeing to do data donation under certain conditions: EHR A to Aggregator
• (Proactive flow?:) Sharing mother’s medical concerns with daughter: PHR D to app A
• (Proactive flow:) Consent directives: Rules set ahead of time for EHR access by family members and others?
• (Reactive flow:) Alice approves access to physician requests for records?
• (lots of other flows possible...)

Setup

Where this use case reflects a choice intended to inform the HEART WG’s profiling deliverables that may vary against use cases that reflect other choices, the notation [CHOICE: description] appears. This choice should appear in the title of the use case in brackets to help distinguish it from other close variants.

Where this use case reflects a discussion point for the HEART WG’s profiling efforts, the notation [PROFILING] appears.

Where this use case contains detail that is believed to be peripheral to the HEART WG’s profiling deliverables, the notation [PERIPHERAL] appears. The point of this detail is to give real-life “color” to the use case.

Technical preconditions

TODO: Move the "hard prerequisites" up to this section.

• As noted below, various systems are FHIR-enabled. [CHOICE: FHIR]
• As noted below, various systems serve in UMA entity roles. [CHOICE: UMA]
• The same technical preconditions obtain here regarding Alice's registration at the EHR systems as for the original OAuth-based "Alice Registers with PCP" use case (original GDoc, bitbucket).
• The same technical preconditions obtain here regarding Alice's account at the PHR system and the data associated with it as for the original OAuth-based "Alice Registers with PCP" use case.

Ecosystem parties and entity mappings

• Alice is an UMA resource owner (RO) when sharing her health data with others, and an UMA requesting party (RqP) when her mother Diane's health data is being shared with her.
• Her mother Diane is an UMA RO when sharing her health data with Alice.
• Bob, Carl, and Aggregator are UMA RqPs when Alice's health data is being shared with them. Aggregator is likely a "legal person" rather than an individual ("natural person").
  • QUESTION: Is Bob actually the party with whom Alice should be sharing, or should she share with his department, institution, or some other "identity unit"?
• Alice's sharing console A, is an UMA authorization server (AS) when it is protecting her health data residing in one or more resource servers (RS's).
• Alice's FHIR-enabled PHR A (at an untethered PHR system) is an UMA RS when it is prepared to serve up her protected health data to others, and her FHIR-enabled EHRs B and E (the patient/provider portal system at Bob's and Erica's institutions at which she has an account) and Diane's FHIR-enabled PHR D are in similar roles. She is the RO of the PHR and EHRs.
• Bob's FHIR-enabled EHR B (the provider/patient portal system accessing her record, among others, at his institution at which he has an account) and Erica's FHIR-enabled EHR E are UMA clients when they are prepared to interact with UMA-enabled services to seek access to Alice's protected data at PHR A.
• Aggregator's CDRN app is an UMA client when it is prepared to interact with UMA-enabled services to seek access to Alice's protected data at PHR A.
• Apps C and A are UMA clients when they are prepared to interact with UMA-enabled services to seek access to Alice's and Diane's protected data at PHR A and D, respectively.

Sharing scenarios

Sharing scenario 1: Alice gives Dr. Bob access to basic data before her first visit

TODO: Step 1 should be the introduction of Alice's PHR system to her sharing management hub. Step 2 should be the introduction of Dr. Bob's EHR system to Alice's sharing management hub. Both of those could leverage the original OAuth-based use case. They should have some OAuth wireframes and maybe some diagrams from that use case. Step 3, finally, should be the current Step 1 below.

[COMMENT] If a PHR is part of a personal data store - or perhaps stand-alone do we really believe (in the next 3-5 years) that Alice would know the sharing management hub is separate?

Step 1. Initial Patient-Physician Contact: Not in Person

Alice calls Dr. Bob's office over the phone [PERIPHERAL] (or she contacts the office in another fashion, or another "grantor" acting on her behalf sets up the appointment for her) to begin enrollment and book her first appointment. Dr. Bob's office creates a patient record for Alice in the EHR system and schedules an appointment for her. This patient record is a protected resource.

The office administrator asks Alice if she would please fill out a raft of paper enrollment forms, printable from the practice's website, before coming in for her first visit with Dr. Bob, or alternatively give selective access to PHR A so that EHR B can fill in what it needs to know about her and gain an ongoing connection with that source of data as long as she and Dr. Bob have a patient-doctor relationship. The administrator tells Alice the "information" (resources and scopes) they will need and the desired "target" (any identity or claim information needed). This gives Alice enough information to set up a "share" ("directive"?).

[COMMENT]These terms in quotes are an attempt to come up with a paradigm for how a patient might understand that's going on. A number of methods could be used for this, including passing one-time codes, using webfinger-type discovery methods, and so on. Here we're assuming that the Dr. Bob side requests access in a "human" way and the Alice side shares access proactively in a "computer" way (Share button paradigm), but another option is for the Alice side to share the location of the resource(s) in a "human" way (provide url of FHIR based PHR resource) and the Dr. Bob side to attempt access in a "computer" way (http://fhirserver/conformance) -- and then for the Alice side to field the request in a "computer" way (access approval paradigm). This seems to be longer all around, however. (Would this by dynamic registration?)

Share approach (don't count raw pros and cons!):

• Pro: More direct towards getting access
• Con: Alice needs to know more information before getting started

Access approval approach (don't count pros and cons!):

• Pro: Alice only needs to provision something simple (we need to figure that out)
• Con: Requires the Dr. Bob side to know more up front
• Con: Requires Alice to act after the fact

Hard prerequisites for the interaction, regardless, would include (should this list be moved to Technical Preconditions?):

• EHR B (the system/service) has client credentials at Alice's sharing console A
• Dr. Bob can get an AAT at sharing console A
• Alice can understand what is required of her to share access with Dr. Bob -- and Dr. Bob and his office can understand what is required of them when Alice calls them looking to register as a patient and share data in this fashion (whatever the exact method)
  • This gets into scope design questions and their UX impact
• Dr. Bob and his client can satisfy Alice's policies

Sharing scenario 2: Alice takes control of her EHR that Dr. Bob created

HIPAA stipulates that a medical professional does not have freedom to do anything they wish with the data in an EHR that they created. We are assuming here that Alice, by contrast, is the correct resource owner because she is the data subject. Therefore, she needs to be able to onboard the EHR (the record) created about her by Dr. Bob.

Step 1: Registering for and Logging In to the EHR System

Once Dr. Bob has begun to populate EHR B (the record) about her (which could even happen before she has been seen), she registers for an account at the patient/provider portal (see the Alice Registers with PCP use case for detail) and logs in to the EHR system.

Step 2: Joining the EHR System with Alice's Authorization Server

She then uses EHR B (the system)'s capability for choosing and joining up with her sharing console A (an UMA AS) [PERIPHERAL: the EHR interface may or may not give her a choice of sharing consoles, or even be integrated with the sharing console], and authorizes the issuance of an UMA protection API token. This enables EHR B to begin working with the sharing console. She selects the EHR resource(s) that she wants to put under the sharing console's central protection [PERIPHERAL: the EHR and sharing console interfaces may give her various choices or no choice in how to do this].

Sharing scenario 3: Alice gives Dr. Erica access to basic and EHR data before her first visit

Note that this sharing scenario is similar to Argonaut Use Case 5, with the addition of the patient consenting to the flow of data.

Step 1. Dr. Bob Refers Alice to Dr. Erica

Having seen Alice, Dr. Bob recommends that she see specialist Dr. Erica.

[COMMENT] There are four flow options here. The first option is proactive and the last three are reactive. Is there a "right answer"?

• Share approach: Dr. Erica's staff asks Alice to proactively share the necessary information from her sharing console A, through either the sharing console or the PHR A and EHR B systems.
• Access approval approach: Dr. Bob (or his staff) could forward some sort of Google Docs-style email or other notification that contains links that Dr. Erica (or her staff) could try to access; Alice could then go through a reactive consent flow as above in scenario 1.
• Access approval approach: Dr. Bob could send some sort of request to Alice to share access with Dr. Erica.
• Dr. Bob could share the resource with Dr. Erica directly using UMA. This would be covered under TPO rules if he makes an actual referral. (He could share the data using non-UMA methods under TPO as well, but that is less interesting for this use case.) Note that if Alice and Dr. Bob share an AS as resource owners, Alice can potentially gain visibility into "chained delegation" of that resource, in Google Docs-like fashion (think "Shared with me" chains).