Monday, November 19, 2012

A Novel Idea for Managing Consent

In 2008, I wrote about representing privacy preferences in an XML form that I called the Consent Assertion Markup language (CAML).

At the November HIT Standards Committee we discussed the draft Meaningful Use Stage 3 Request for Comment (RFC), which includes a measure relating to query for a patient's record.  The RFC suggests an exchange of authorization language to be signed by the patient in order to allow retrieval of the requested information.    Discussion elicited the suggestion that perhaps patient consent preferences might be included as metadata with the data exchanged so that the patient approved uses of the data - treatment/payment/operations, clinical trials, transmission to a third party - could be respected.

After the meeting, Dixie Baker proposed a simple, scalable and powerful approach to avoiding the necessity of either exchanging authorization language for signature, and the complexities involved in exchanging patient preferences as metadata.  Her suggested approach draws from both the CAML idea with the metadata idea, but simplifies privacy-management for both consumers and providers, while offering the kind of scalability needed for the dynamic, collaborative healthcare environment we envision.

Imagine that instead of having to fill out a new privacy-preferences form at each encounter, the consumer could select and manage her preferences with a single entity, and at every other encounter, would need only provide the URI to where her preferences were held.   Then, upon receipt of a request for her health information, an EHR would only need to query the privacy-management service at the URI she provided to determine whether the request could be honored.  Her preferences would be captured as structured, coded data to enable query, without having to exchange a complete "form" in order to adjudicate an access request.  Per the CAML idea, this XML could include queryable preferences about what data the patient consents to exchange with whom and in what circumstances.   This set of privacy preferences could be maintained by the patient and would include such concepts as institution-level permission to share data with partner insitituions, permission to send data using a health information exchange organization, and approval to use data for certain types of research.  

Instead of sending these preferences with the data itself, the metadata header in  Consolidated CDA summary exchange would include a Uniform Resource Identifier (URI) that points to the privacy-management service where the patient's privacy preferences are held.

This simple idea - represent patient's privacy preferences/consents in query-able XML at a specific URI - enables an entirely new approach to health information exchange, while making it easier for consumers to make meaningful choices, and manage them over time.

For example

1.   A hospital is "pushed" a patient record from a primary caregiver.   The hospital wants to push that data to a specialist.   Before any data transfer is done to an outside organization, the URI is retrieved from the metadata and the patient's current consent preferences are applied to the data exchange.

2.   An emergency department wants to pull data from multiple data sources to ensure safe, quality, efficient care of an unconscious patient.   The URI of service holding the patient's privacy preferences is available from the state HIE, and the data is retrieved from various sources per the patient's preferences.

3.  At discharge, the patient's information is to be pushed to the patient and the primary caregiver/referring clinician per meaningful use stage 2 requirements.   Before the push happens, the patient's URI is checked for current data exchange preferences.

As we continue to work on a variety of "meaningful consent" approaches and support complex state privacy policy variants, the notion of recording patient privacy preferences in a place that is under the control of the patient and is query-able via a simple XML makes great sense.

I look forward to continued discussion of Dixie's ideas at the next Standards Committee meeting.

5 comments:

  1. I couldn't agree more. The vision you articulate in this post is an idea whose time has finally come! I salute you and others on the Standards and Policy Committees, and in the ONC, in putting us within striking distance of achieving this vision. It’s time to take this across the goal line!

    ReplyDelete
  2. I agree this si a useful approach. I think this kind of things has been kicked around, but never taken seriously at such a high policy level, so bravo on having the dialogue.

    ReplyDelete
  3. John--
    First, Happy (Vegan) Thanksgiving! Second, what would the challenges be in using the PayPal infrastructure to carry this idea to execution?

    ReplyDelete
  4. Certainly if we can come to some agreement on things like how to identify the players accurately, etc. --- this is a fantastic idea, and (with admitted bias) I'd suggest that one obvious home for the patient's URI would be their PHR --- just like there is value in hanging a Direct Project address there.

    We'd be excited to collaborate on piloting such a service, so if the conversation progresses towards concrete experiments, just let us know!

    ---S

    ReplyDelete
  5. Indeed, patient consents should be stored in one place, and accessed via the Internet. That approach provides two major benefits: A patient can (potentially) write a consent that applies to many providers, e.g., “Any data may be shared with any member listed in my (stored) list of critical partners”; this list could contain doctors, social workers, and family members, as long as each recipient address was stored by the consent system. Second, it avoids a huge burden when consent is stored with data – being able to find and update all copies of the consent, when the patient changes his mind.

    MITRE’s Kairon Consents research projecthttp://kaironconsents.sourceforge.net/ has been exploring these issues. Below, I list some of the lessons we learned: While the project has considered other releasability tasks (e.g., eliciting preferences from naïve patients, gaps in record holders’ tagging, government policies) we focus here on expressing and managing the patient preferences.

    • Yes, record holders should de-reference a URI to get the correct, current consent information. A PHR’s URI is one good option. Our overview paper identifies several subtleties – ensuring that the URI really represents the patient, and allowing patients to avoid creating a global patient identifier.

    • A formal language for expressing consents, as rules, is recommended. However, it should not be specified from scratch, via an XML schema. Instead, take a general purpose rule language, from the computer science community, perhaps subset it for simplicity, and then attach a vocabulary of attributes and predicates suitable for patient consents. This way one gets documentation, solid semantics (e.g., when some inputs are unknown, possibly value taxonomies, conflict resolution), and perhaps syntactic conveniences (e.g., reusable subexpressions) and an execution engine. A good example of this approach is XSPA, which is based on XACMLhttp://docs.oasis-open.org/xacml/xspa/v1.0/xacml-xspa-1.0-cs02.html,. (We lean toward Drools rather than XACML as a basis, for reasons too lengthy to describe here).

    • It is important to query a rule set, but XML syntax only finds explicit mentions of a search term. To better understand behavior, substitute values (e.g., purpose, sensitivity code, recipient, or record holder) into the ruleset, and then simplify according to the language logic. However, this approach requires more software, not just generic XML tools.

    ReplyDelete