Pages

Sunday, May 3, 2015

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.

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:

No comments:

Post a Comment