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.
In addition to his CIO role at BIDMC, Dr. Halamka blogs at GeekDoctor.blogspot.com.
MassDevice Network
@MassDevice
LinkedIn
YouTube
Leave a Reply
You must be logged in to post a comment.