Every day I experience life in the world of healthcare IT, supporting 3000 doctors, 18000 faculty, and 3 million patients. In this blog I record my experiences with infrastructure, applications, policies, management, and governance as well as muse on such topics such as reducing our carbon footprint, standardizing data in healthcare, and living life to its fullest.

Monday, November 19, 2012

A Novel Idea for Managing Consent

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.

5 comments:

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!

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!

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.