Strawman on Consent Directive

The Healthcare community continue to struggle with Patient Consent Directives. I assert it is because we have two very different forces:

1. Healthcare Business -- that are under many regulatory, ethical, and business forces. This makes it very hard to change, especially hard to make radical changes. So this community needs very small realistic changes suggested that eventually produce the result desired.
2. Patient Advocates -- that want a very different User Experience. This community wants all of the Privacy Principles implemented. They accept nothing less, likely because of the limited movement so far.

I support both views! But we can't go from one view to the other without taking some small steps.

We can't change Healthcare by writing very complex standards like the current FHIR ConsentDirective, which is fundamentally a "Contract" resource. And the CDA ConsentDirective is even less realistic. First I recommend that FHIR make ConsentDirective a resource rather than just profiles of Contract. I have defended this model so far, but the negatives are more powerful. People simply want a ConsentDirective resource.

Might I suggest that the ConsentDirective project include a "Basic-ConsentDirective" that supports blanket consents without exceptions. Essentially the common HIE policies from BPPC. These would be scoped to sharing beyond the original organization and purpose for which the health information was created. This form of a Consent Directive would need only (identifier, issued, applies, subject, authority, domain, type=consent, subtype=<some vocabulary>, and possibly friendly and legal). This Basic Consent Directive would support the following HIE subtypes:

• Opt-In -- Agree to publish "All" healthcare information. Agree to Use and Disclosure to "any" authorized individual of a "Treatment" or "Payment" organization "For the Purpose" of "Treatment" or "Payment". No Redisclosure allowed without further authorization. This agreement does not authorize other accesses.
• Opt-Out allowing break-glass -- Agree to publish "All" healthcare information. Agree to Use and Disclosure to "any" authorized individual of a Treatment organization for specifically "Emergency Treatment" PurpoeOfUse, and Payment of those treatment. This agreement does not authorize other accesses.
• Opt-In summary access only -- Agree to publish "All" healthcare information. Agree to Use and Disclosure to "any" authorized individual of a "Treatment" or "Payment" organization "For the Purpose" of "Treatment" or "Payment"; to only the medications and allergies summary. No Redisclosure allowed without further authorization. This agreement does not authorize other accesses.
• Opt-In break-glass summary access only -- Agree to publish "All" healthcare information. Agree to Use and Disclosure to "any" authorized individual of a "Treatment" organization "For the Purpose" of "Emergency Treatment" and Payment of those treatment; to only the medications and allergies summary. No Redisclosure allowed without further authorization. This agreement does not authorize other accesses.
• Opt-Out no break-glass -- Agree to publish "All" healthcare information. This agreement does not authorize any accesses.
• Opt-Out completely -- Agree to publish "No" healthcare information beyond originating organization intended use.

I will also note that I think we should look to ‘Creative Commons’, which I explain on my blog.

                http://healthcaresecprivacy.blogspot.com/2014/08/healthcare-patient-consent-lessons.html

More advanced consents can be made once we have this basic vocabulary in place. For example we an then add exceptions, which can be computable rules. For example an "Opt-In" but not to Doctor Bob. All of the Opt-In logic is understood from the reference to Opt-In, the only thing that needs to be added is the exception for Doctor Bob. No need to duplicate the logic of Opt-In in each patient chart.

References:

Patient Privacy controls (aka Consent, Authorization, Data Segmentation)

• 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

Access Control (Consent enforcement)

• What does the SAML assertion mean in a XDS/XCA query/retrieve?
•  Healthcare Privacy and Security Classification System (HCS) 
• Define Atom -- Too many definitions in use today 
• Healthcare access control scope constraints on OAuth tokens
• Advanced Access Controls to support sensitive health topics
• Policy Enforcing XDS Registry 
• Healthcare Metadata
• Texas HIE Consent Management System Design
• IHE - Privacy and Security Profiles - Access Control
• Data Classification - a key vector enabling rich Security and Privacy controls
• Healthcare Access Controls standards landscape
• Handling the obligation to prohibit Re-disclosure
• Access Controls: Policies --> Attributes --> Implementation 

Bagikan Artikel