Monday, July 26, 2010
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?
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.
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.
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.
Posted by John Halamka at 3:00 AM