As we all implement Meaningful Use stages 1, 2, and 3 from 2011-2015, we will increasingly share data among payers, providers and patients. Protecting privacy is foundational and we should only exchange data per patient preference. How will we achieve that in Massachusetts?
Stage 1
In the first stage of meaningful use, there are limited data exchanges - ePrescribing, a demonstration of pushing data from provider to provider, and public/population health exchanges for lab, immunizations, and syndromic surveillance.
These can be achieved using the consent mechanisms we have in place today i.e.
A clinician asks a patient (or the patient signs a paper-based general consent in the office or hospital) if the clinician can retrieve their national medication history from Surescripts during the course of e-prescribing.
A clinician asks a patient if the clinician can push a summary of their care to another clinician such as a primary caregiver/specialist or hospital/primary caregiver data exchange.
Aggregating de-identified data for public health purposes is permitted by HIPAA and ARRA without consent. Since no patient identifiers are involved there is a reduced risk for privacy breaches.
In our community EHR rollout of eClinicalWorks via our private cloud (a physically secure, environmentally controlled, generator supported co-location facility that is professionally operated and provides all the inbound interfaces needed for meaningful use), we've designed our infrastructure to support consent for Stage 1 exchanges.
1. Every practice has its own virtual server, separate eCW software, and isolated database instance. The data is owned and controlled by the practice
2. De-identified data is used for pay for performance and quality reporting, but BIDMC/BIDPO has no access to your EHR or billing system
3. Data can flow from provider to provider with NEHEN or the eCW push product (P2P), but that is at the provider's discretion after consent of the patient is obtained.
Stage 2
Although Stage 2 of Meaningful Use is still in the design stages, it is likely that increased provider to provider data sharing will be included. There will need to be a consent mechanism for providers to pull patient data from multiple data sources as needed for care. Push is great for some workflows, but pull is needed for emergency rooms to obtain critical treatment data in a timely fashion to ensure safe, quality care.
A push architecture supports provider initiated consent - the clinician can ask the patient before pushing data. Pull requires a different approach. The patient's data sharing preferences must be stored somewhere so that when data is pulled, only those data elements consistent with patient privacy preferences for that type of clinical encounter are shared.
In Stage 2, I expect that such consent will be federated, stored in various EHRs and community exchanges. At the moment there is no plan for a national health identifier or patient controlled national consent infrastructure.
In Massachusetts, we have legislation (Chapter 305) and a community standard which requires an opt-in consent for data sharing between healthcare organizations.
Some EHR vendors have created consent functionality within their produces to support the recording of consent for information exchange. Some community HIEs have created city-wide databases to record consent preferences.
In our community EHR rollout of eClinicalWorks, we've designed our infrastructure to support consent for Stage 2 exchanges.
We use the EHX product from eClinicalWorks which includes an opt in consent database, a clinical summary data store, and means for clinicians to pull data across practices if a patient opts in to support it.
This works great for the 1700 clinicians in BIDPO, but does not support pull transactions across competing organizations.
For that, we need to look to stage 3.
Stage 3
I believe that Stage 3 which include several community, state, and national data exchanges to support care coordination and population health. It will require master patient indices (given that a national identifier is unlikely). It will require a centralized patient controlled consent framework.
To ensure we are ready for patient controlled, centrally managed consent, the state of Massachusetts HIE ad hoc workgroup recommended that we begin work building a central consent management framework now using our ONC HIE funds.
Thus, we'll use provider initiated consent and patient opt in via EHRs and community exchanges for stage 1 and 2, but we hope to have a patient controlled state wide consent infrastructure ready for Stage 3.
Opt in consent that is patient controlled is the right approach and we need to build the infrastructure to support it. In the meantime we'll protect patient privacy preferences using the best technology available.
On Wednesday, I'll write about the July HIT Standards Committee meeting at which we'll discuss the latest ONC Privacy and Security Tiger Team work. Hopefully, our local, state and Federal policy and technology will converge to support the patient centric consent that ensures we support everyone's preferences for data exchange.
4 comments:
Thanks for the detailed map of how to balance interoperability and meaningful use. The "opt-in" function is critical, but there's also permission fatigue to consider. I'd think the patient could sign a general waiver when first checking in with the primary care provider, and then could decide on levels of permission for those in the outer fringes of service (specialists, hospitals, etc.)
"Aggregating de-identified data for public health purposes is permitted by HIPAA and ARRA without consent. Since no patient identifiers are involved there is minimal risk of privacy breach."
The regulations haven't caught up with reality. Practically any data that is useful can be re-identified. This appears to be recognized at DHHS because they have people like Latanya Sweeney and Cynthia Dwork talking to them about these issues (see March 8-9, 2010 HHS Workshop on the HIPAA Privacy Rule's De-Identification Standard: http://www.hhshipaaprivacy.com/).
For more on this issue see:
Narayanan, Arvind, and Vitaly Shmatikov. 2010. “Myths and fallacies of "personally identifiable information".” Commun. ACM 53:26, 24. http://www.cs.utexas.edu/users/shmat/shmat_cacm10.pdf
Ohm, Paul. 2009. “Broken Promises of Privacy: Responding to the Surprising Failure of Anonymization.” SSRN eLibrary. http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1450006.
What if the patient changes their mind on their choice of permissions after awhile? Are they stuck with the original permissions? Is there an easy opt-out function?
Congratulations on your statement that “Opt in consent that is patient controlled is the right approach and we need to build the infrastructure to support it.” (I assume you mean patients should be able to segment sensitive information too.) I thought you would never support patient control over PHI from your opposition to consent at HITSP. I am glad to see you have changed and now support patients' rights.
But you are dead wrong about the need for master patient indices (MPIs), there is actually no need to use them.
MPIs are a MAJOR threat to patient privacy because MPIs identify all patients who have been treated in a facility and list the medical record or identification number associated with each name.
So if you were at a cancer treatment center or a psychiatric hospital, the MPI would allow thousands searching for your records without your consent to see that you were treated there, revealing information you did not want them to know.
Instead, ONLY health professionals you authorize to search for your records at a certain facility should be able to find out that you were treated there and be able to use your PHI.
Each data holder should have its own patient ID system, and only patients should be able to authorize searches and disclosures of PHI to desired recipients by specifying that location A send PHI to location B.
Post a Comment