Gathering Privacy Consent is never easy. A Patient, when they are healthy, has no interest in giving Consent for future actions. Mostly because they don't want to admit they might get sick in the future. Secondarily because they don't want to do unnecessary paperwork. Realistically, they just want healthcare to work, and not get in the way of them getting the best treatment. This is why many exchanges are moving toward an 'implied consent' that allows a patient to explicitly withdraw their authorization, but in the absence of any action by the Patient the data would be shared for "Treatment" purposes. This default behavior is only applied to "Treatment", not "Research" or other.
That said, Consent is still sometimes needed. It might be needed because the organization uses a Default of not sharing. It might be because the patient has sensitive health topics that require explicit consent to release. It might be because the patient has Withdrawn their authorization, but now wishes to enable one provider organization access for a visit, careplan, or episode of care.
Given XDS and XCA interactions that are often used in an Health Information Exchange (HIE), or a National Health Information Exchange (NHIE); there is no standards/profiled way to enable a
point-of-care consent gathering workflow. So today, if Consent is not already captured, and needed, then data access is blocked. Today the patient must go to the custodian organization and fulfill their consent workflow needs. This might be easy, through a web tool or phone call, but no matter how easy it is difficult when the Patient is not feeling well.
The basics are shown in the following interaction diagram. It starts with a normal XCPD or XCA request. The Responding Gateway will check if Authorization(AuthZ) is already enabled. In this case everything is okay, except that a Consent is needed. I say 'everything else is okay' because one needs to make sure the requesting organization is authorized to even ask, and are authorized to get point-of-care consent.
The new thing, highlighted in YELLOW, is that the Responder can inform the Requester that getting specific consent types would allow more information to be exposed. This can be detected by the Requesting organization, it is also backward compatible so that a Requesting organization that doesn't know about this new capability can continue as today with no data available. A Requesting organization can look at the policy choices offered, it can get one of them from the patient, it stores the result locally, and tries the same transaction again with an Assertion that they have achieved the specific consent. The Responding gateway would now see the Assertion and allow disclosure of the data according to the asserted policy. From that point forward that partner would include this Assertion in all requests, and the Responder would continue to disclose under that policy.
This works on a Partner-by-Partner basis. This also relies on the Partner that gets a consent to maintain that consent onbehalf of the Responding organization.
An augmentation being discussed is to somehow get the Consent paperwork back to the Responding organization. This might be through the exchange, this might be by postal mail or FAX. CareQuality is going to enable a the exchange based pathway, through adding additional elements to indicate that the paperwork is available online. This additional element might be false to begin, and change to true a day or a week later.
It also easy to Query for consent documents. The Provider X might set a timer and query each day until it appears.
Once this is received by the Responding organization it is possible for that organization to record the consent and have it affect ALL partners. This is not part of the CareQuality system, but rather is a potential policy decision a Responding organization could make.
This is a developing system, so it is not fully defined. I expect it to continue to develop this winter and spring. I would hope it is then brought to IHE for standardization next year.
Given XDS and XCA interactions that are often used in an Health Information Exchange (HIE), or a National Health Information Exchange (NHIE); there is no standards/profiled way to enable a
point-of-care consent gathering workflow. So today, if Consent is not already captured, and needed, then data access is blocked. Today the patient must go to the custodian organization and fulfill their consent workflow needs. This might be easy, through a web tool or phone call, but no matter how easy it is difficult when the Patient is not feeling well.
Consent Negotiation
So... there is a need to enable negotiation between a Custodian that needs a consent, and the Requesting organization that is at the Point-Of-Care... This is the problem that CareQuality is trying to enable. My understanding is that much of this comes from the experience of Epic in their CareEverywhere system. This is getting designed in CareQuality now. The approach should become a standard that anyone can use, hopefully through IHE XDS/XCA/XUA.
The basics are shown in the following interaction diagram. It starts with a normal XCPD or XCA request. The Responding Gateway will check if Authorization(AuthZ) is already enabled. In this case everything is okay, except that a Consent is needed. I say 'everything else is okay' because one needs to make sure the requesting organization is authorized to even ask, and are authorized to get point-of-care consent.The new thing, highlighted in YELLOW, is that the Responder can inform the Requester that getting specific consent types would allow more information to be exposed. This can be detected by the Requesting organization, it is also backward compatible so that a Requesting organization that doesn't know about this new capability can continue as today with no data available. A Requesting organization can look at the policy choices offered, it can get one of them from the patient, it stores the result locally, and tries the same transaction again with an Assertion that they have achieved the specific consent. The Responding gateway would now see the Assertion and allow disclosure of the data according to the asserted policy. From that point forward that partner would include this Assertion in all requests, and the Responder would continue to disclose under that policy.
Closing the Loop
An augmentation being discussed is to somehow get the Consent paperwork back to the Responding organization. This might be through the exchange, this might be by postal mail or FAX. CareQuality is going to enable a the exchange based pathway, through adding additional elements to indicate that the paperwork is available online. This additional element might be false to begin, and change to true a day or a week later.
It also easy to Query for consent documents. The Provider X might set a timer and query each day until it appears.
Once this is received by the Responding organization it is possible for that organization to record the consent and have it affect ALL partners. This is not part of the CareQuality system, but rather is a potential policy decision a Responding organization could make.
This is a developing system, so it is not fully defined. I expect it to continue to develop this winter and spring. I would hope it is then brought to IHE for standardization next year.
Past articles on Patient Privacy controls (aka Consent, Authorization, Data Segmentation)
- Basic Consent - a necessary first step
- Aiding Online Informed Consent using Social Commentary
- Consent Process
- Controlling Big-Data feeding frenzy with Privacy Consent Authorization
- Vectors through Consent to Control Big-Data Feeding frenzy
- Consent Basis in Controlling Big-Data Feeding frenzy
- Privacy Constraints in Controlling Big-Data Feeding Frenzy
- electronic Privacy Consent -- Patient choice
- Privacy-by-Design Data-Analytics Platform on FHIR
- Simplified #FHIR Privacy Consent Directive resource
- Consent given to authorized representative
- Patient ID is critical to Enabling Privacy
- electronic Privacy Consent -- Patient choice
- BPPC is not just for XDS/XCA
- Consent to grant read access to a specific types of FHIR Resources
- How to set the ConfidentialityCode
- Strawman on Consent Directive
- Privacy Principles
- Break-Glass on FHIR
- Healthcare Patient Consent -- Lessons learned from Creative Commons
- Enabling Patients to Delegate Healthcare Information Access Authority
- Define Atom -- Too many definitions in use today
- Defining Privacy
- Safety vs Privacy
- Privacy Consent State of Mind
- Universal Health ID -- Enable Privacy
- Texas HIE Consent Management System Design
- Simple and Effective HIE Consent
- IHE - Privacy and Security Profiles - Basic Patient Privacy Consents
- Data Segmentation - now I know where the term comes from
