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
...
- Intro/Scope statement - what this report will cover
- overall objective of the document, what we will cover, what the reader should understand by the end
- 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
- understanding UMA's unique value to aid this use-case (why can't it just be OAuth??)
- don't have to use all of UMA, parts can be used to address different challenges
- how to make hard problems easier though UMA
- how UMA's interacts with other protocols (OIDC, FHIR/SMARTonFHIR/HEART, OAuth)
- What's not being covered
- What's not being covered - maybe hard to state at this point
- overall objective of the document, what we will cover, what the reader should understand by the end
- Description of concrete use-case (Julie)
- actors, data, systems (Primary care EMR, Specialist EMR, Pharmacy system, Payer system), identities *needs a diagram
- capabilities and responsibilities of actors (Julie, HCP, Organization) eg link to Policy?
- what's not being covered about this whole use case
- Policy that impacts the use-case
- risk/liability vs patient agency (
- tension between policies (eg obligations to protect data vs obligation to enable sharing)
- Core UMA/HEART overview
- why were even talking about UMA in this context
- how UMA's interacts with other protocols (OIDC, FHIR/SMARTonFHIR/HEART, OAuth, UDAP?)
- UMA application to use-case (steady state) *needs a diagram
- Delegation state changes,
- how the health journey affects state.
- concrete events that create changes Julie turns (Nancy to confirm what transitions we want to discuss)
- Julie turns 17,
- Julie sees asthma specialist
- Father get's invoice from health provider, submits claim to insurance provider
- Julie get's medication to treat STI, Provide create Rx, Pharmacist fills Rx and needs access to record (ie to see drug interactions)
- Discussion? Tough corners, future topics
- Conclusion
- About this paper
- pp2pi and kantara blurbs
- References, learn more
Working Draft
...
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.
...
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.)
2. Adolescent User Story
Nancy will add more about what is included and what is not. NoteNotes:
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.
...
3. Policy that impacts the use-case
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
"Policy" covers many different elements, 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.
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?]
...
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 "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
...