On October 5, the Office of the National Coordinator released the Consumer Preferences Draft Requirements Document which highlights the policy and technology requirements to ensure that all data exchange - PHRs, EHRs, HIEs, Public Health, Quality, and Research - protects confidentiality by following the preferences of the consumer for data sharing. It's an important document and definitely worth reading.
On October 13, HITSP held a Town Hall Meeting on Consumer Preferences to discuss the requirements document and collect public comments for submission to ONC. You'll find the audiocast here (as MP3) and the presentation here (as PDF).
At the October 14 HIT Standards Committee meeting, David Blumenthal emphasized that we need to expand the scope of our NHIN thinking to include consumer health information platforms in addition to the provider and government organizations that have been the focus to date.
What does this all mean? The focus on consumer consent, privacy, and security as the foundation of data exchange will accelerate interoperability.
A few thoughts:
1. As the Chairman of NEHEN, a Health Information Exchange in Massachusetts, I know that consent management (policy and technology) is a very important first step to implementing interoperability. To coordinate care, improve quality, and measure population health, we need data and patients need to trust our HIEs so that we can share data for their benefit.
2. Policymaking can constrain technological complexity. If every possible permutation of consent (opt in, opt out, segmentation of the record, approval for sharing at the institution level, approval for sharing at the provider level, approval based on the situation - emergent care or not, etc.) needs to be supported by every stakeholder exchanging data, then the number of standards needed will be significant. Ensuring comformance with a large number of standards at every point of data exchange will be challenging. In my experience, something simple such as opt-in consent for data sharing at the institution level, will result in much more privacy because the security technologies required to support it are simple and easy to understand.
3. Although provider to provider data sharing will always be important, the notion of sharing data with the patient who then shares it with others per their consent preferences is a viable alternative approach. However, we need to maintain the integrity of the data from its source to its use by ensuring the data is not modified or the context of the data changed along the way. Jamie Ferguson from Kaiser Permanente wrote a great blog about this issue.
My ideal plan for consumer preferences would be
1. We develop national policy which clearly delineates the types of consents we need to support. Ideally, this will be a short list. I prefer consumer opt-in at the institution level. To be compliant with ARRA and state laws I can imagine this being expanded a bit to include very basic segmentation of the record into mental health, HIV results, and everything else.
2. This consent will be recorded electronically and made available via a health information exchange, the PHR of the patient's choice, or via a mobile storage device such as a USB drive. When a patient presents for care, the consent is queried, and all data exchanges follow this declaration of confidentiality preferences.
3. The standard for recording consent would be XML-based and not require a "wet signature" or an image of a signature. I realize that some state laws still require handwritten consents, so policy work is needed here.
Given all this activity regarding consumer preferences, control, and empowerment, let's hope the policymaking gets done by 2011 and the standards to support the policy can be simple to deploy and manage. The more complex meaningful use data exchanges in 2013 and 2015 depend upon it.
Addendum: John Moehrke has published an excellent blog outlining how current HITSP standards can support this vision.
8 comments:
I very much agree with your points on needing consent in order to engender patient trust. I like your approach for starting simple. I would point out that what HITSP has already selected in TP30 meets every requirement you have.
I am concerned with understanding your last requirement for XML format. The TP30 solution does encode the consumer consent as a CDA document, which is XML. It also optionally supports a scanned image of a wet-signature for those regions that need it. But I am not sure if this is what you are referring to. Given that you have asserted that initially we need only a singular policy for OPT-IN (or more likely a small number), why does a binary decision need to be encoded in XML?
The underlying IHE-BPPC profile was designed to fill the gap in privacy-policy encoding standards, while emulating and encapsulating what is done with paper today.
I would like us to understand TP30 well enough that we can start implementing it as you describe. Implementing TP30 does NOT mean we don't continue to develop privacy-policy XML schema and vocabulary.
I found Jamie's post interesting enough to comment on here: Making it Possible for Doctors to Trust your Electronic Health Data
Great post John.(and John and Keith)
From a overtly technical standpoint, the notion of expressing and transmitting a consent is very doable.
However, conspicuously absent from the discussion of consumer preferences is the the ownership rights of the legal owner of the data.
My professional experiences in the practicalities of consumer determinism is the notion that they explicitly have the legal right to the ownership of the data, not simply access to their information. In many states - I'll use Virginia as an example - physicians and providers physically own the record but patients have a right to request reasonable access to the information contained in the record. Further, the physical record has tangible value to the physician's practice where it considered an asset, further reinforcing the legal tenant of ownership.
Ipso facto, as a consumer, what preferential rights can I assert to a record that I don't own? (further, that the provider can legal disregard or over-ride).
A national policy will carry us but so far considering the myriad of state laws that address, partially address or do not address these complex issues. The uniformity of application is crucial to moving data across jurisdictions.
I could type all day on this, but I'll stop here.
Now the tiny type: the opinions expressed here are my own, not of that of my employer or clients.
As usual John, thoughtful post oa critical tech policy issue, consumer preferences.
While I understand the desire to apply the KISS principle to consumer preferences, believe that allowing a simple construct wih options such as full opt-in, partial opt-in etc and ltd choices therein is required to insure that consumer preferences are truly reflected, shared and preserved.
In my own review of the Consumer Preferences Draft, http://chilmarkresearch.com/2009/10/15/consumer-preferences-sharing-phi/ one of the biggest failings is lack of addressing the extension of consumer preferences beyond the first clinical stakeholder. This creates a loophole a mile-wide.
And as Chris rightly states, at the end of the day, PHI does not belong to any hospital, IDN, physician etc., it is the consumer's.
A distributed, XML-encoded (XACML?) consumer-controlled consent model is the "holy grail" that we seek, but I fear that this is far too complex for the short run, and may in fact be unnecesary.
A much simpler solution would be to aggregate patient data ONLY at the consumer's chosen PHR (accessed via the NHIN.) The consumer can then manage his or her data consent policy via a simple (?) user interface provided by the chosen PHR, just like you can manage access to your photographs at Smugmug or Picasa or Flickr.
Provider-to-provider messaging, via the local HIE or via the NHIN or via vendor-to-vendor gateways would continue to operate under existing consent-for-care policies as mandated by HIPAA.
I'll fo out on a limb and suggest that there is no real need to aggregate patient data in a local HIE other than for mandated public health and quality reporting needs -- uses that are outside of patient consent management anyway.
All other PHI aggregation should occur only at the patient's chosen PHR, where consent is easy(er) to manage.
David McCallie, MD
I like David's suggestion of the PHR being the point of patient-centered data aggregation. I hear John's point about chopping up the record into three basic consent categories (mental health, HIV, and the rest), but this is not so simple to do.
How do you handle the family practice diabetes management note that includes a mention of bipolar disorder and the fact that the patient is on Symbyax?
Also, what about legal requirements to release only the information necessary? Is there a standard for consent-based or conditional redaction?
These are complex but solvable challenges.
This thread has made me think more about how consumers interact with the NHIN and the notion that the PHR becomes a central point of clinical data aggregation. I tend to agree with the dialog here around consumers and their participation in this process. I believe consumers are the owners of their personal health information. I believe healthcare organizations that provide services for patients are entitled to a "copy" of the data, but are not the "owners" of that data. They can use the data for quality measure, research, general patient profiling, and care purposes, but the patient owns that data at the end of the day.
I think the thing that has changed the ballgame is the release of Personal Health Records. I believe solutions like DOSSIA, MS HealthVault, and GoogleHealth will take off in popularity once a critical piece of the exhange puzzle is solved. The piece missing is the real-time exchange between EMR systems and PHRs. There is limited success today in this space, but I'd like to see a mandate for all EMR systems to send a copy of the data around services performed to the patient's PHR (assuming the patient has an account) so the patient does indeed house and keep the aggregate of their data.
Similarly, and pulling the PCMH concept into the mix, the patient's Primary Care Physician should also get a copy of the data so they have an aggregate view of the patients they manage. If the PCP is truly expected to manage their patients then they need access to all the data.
Let me ask a question because I'm curious to know what this group thinks...
The question has to do with concerns around sharing mental health and other sensitive information. I'd like to use Steve's diabetes example. Let's say bipolar disorder is part of the patient's FP note. Why is it a good idea to suppress that data when the patient visits a specialist or other healthcare provider? Isn't the entire patient story important for caregivers to know and understand? I'm not on Symbyax, although my wife may argue that I should be, nor do I have a mental health disorder (none that I'm aware of anyway), but if that's part of my health record then isn't that information important for others to know as I'm being treated elsewhere?
I get the overall notion here that people do not want the world to know their business, but there seems to be a fine line between "hiding" information and protecting patients from misuse of data.
I work in the healthcare IT field and have for several years. I get the feeling that patients are allowed to "hide" information very easily which only makes it tougher for caregivers to provider optimal care. I'd like to know if others feel the same or feel differently and why?
Again, I enjoy reading what others think on topics related to HIE so I appreciate the feedback...
I agree with John O on EMRs and PHRs needing to exchange data real time. However, the question is how would this be done, ideally? Right now, it seems that the approach is building point to point connections from a health system to Google Health or Health Vault. A slight improvement is that the EMR would build this link but that is still point to point. There should be something that sits in the middle and if you send medical records to it, they can be routed to a PHR of your choice. And I don't think that the NHIN will be this delivery mechanism (any time soon) although PHRs are being discussed in this fashion. I don't think the NHIN will be this mechanism because of the requirements to get on it (RHIOs talking to RHIOs). If it was provider talking to provider, then maybe.
Google Health (and other PHRs) have so much potential, but who actually uses them? Only a handful of health systems have coded the point to point bridge to talk to Google Health (or other PHRs). As John mentioned, there is a missing middle piece here. And I know this comment will have many that disagree, but again, I don't think the NHIN is going to be that piece any time soon.
Go easy on me guys, I am not trying to start a "religion and politics" war but I did want to share my honest thoughts.
Post a Comment