The Blue Button idea is simple - a large visible button on payer, provider, lab, or pharmacy websites enables patients to download their records in plain text.
The Veterans Administration has used it extensively. The Office of Personnel Management asked all health insurance carriers in the Federal Employees Health Benefit Program (FEHBP) to add Blue Button functions to personal health record systems. OPM administers health benefit programs for the civilian sector of the federal government, including all executive agencies, Members of Congress and their staffs, and the federal judiciary on their websites.
The Blue Button is one of several models of health information exchange being implemented.
I've summarized HIE models as:
View - a website or web service enables authorized patients, providers or payers to view data in plain text or HTML. A modest amount of programming is needed, but significant attention to security issues is important to protect the website and data sources.
Push - an EHR sends data to another EHR via the Direct standard. Since this is secure email, a modest infrastructure investment is needed to create directories, certificate management, and gateways.
Pull - an EHR queries a master patient index/record locator service to identify a patient and the locations of their records. The EHR then queries all the data sources to assemble a comprehensive medical history. NwHIN Exchange is an example of such an approach. Significant infrastructure must be built to support and maintain a pull architecture.
Since Push and Pull models require HIEs, which are still evolving, some organizations, including BIDMC and its affiliates have temporarily implemented View approaches inside Epic, Meditech, eClinical Works and self built applications.
Here's how it works:
1. The clinician clicks on a button inside their EHR. This click launches a query containing Name, Gender, Date of Birth, and Zip Code to a responding EHR. The physician does not need to respecify the patient or log in to a separate portal since the patient identity information and security credentials are sent from the querying EHR automatically.
2. The responding EHR checks the security, looks up the patient, and responds with a medical record number if the patient is found.
3. The querying EHR sends a new query incorporating the returned medical record number.
4. The responding EHR launches a web-page which displays clinical data for that medical record number.
5. All transactions are audited in the responding EHRs.
Since this approach works like magic, requires no HIE, and is fast/inexpensive to implement, our clinicians have described it as the "Magic button"
In effect, it serves as a web-based single sign application that retains patient context and enables clinicians to view data from any EHR that adheres to the Magic button implementation guide.
We see it as a temporary solution because it does not result in persistent exchange of semantically interoperable data. It simply enables a clinician to see data such as problem lists, medication lists, allergies, labs, radiology studies, EKRs, reports, and notes in remote systems without requiring a lot of training. It's better than having silos of data and sending faxes.
As HIEs come on line, push and pull models will enable the same kind of data exchange but will incorporate data from sending EHRs into receiving EHRs, enhancing workflow and improving the integrity of the record.
One other problem with the Magic button is that it does not scale very well - we now have buttons for Atrius, Needham, Milton, and eClinicalWorks practices. Clinicians ask the patient where they've received care, get their consent to view the data, and click on the appropriate magic button. As we add more affiliates, the number of Magic buttons will be hard to manage.
In future pull models, record locator services will keep an index of all the locations where patients have consented their data to be accessed.
But for now, having a kind of Blue Button that enables clinicians to view each other's records with patient consent is truly magic for those who use it.
The Veterans Administration has used it extensively. The Office of Personnel Management asked all health insurance carriers in the Federal Employees Health Benefit Program (FEHBP) to add Blue Button functions to personal health record systems. OPM administers health benefit programs for the civilian sector of the federal government, including all executive agencies, Members of Congress and their staffs, and the federal judiciary on their websites.
The Blue Button is one of several models of health information exchange being implemented.
I've summarized HIE models as:
View - a website or web service enables authorized patients, providers or payers to view data in plain text or HTML. A modest amount of programming is needed, but significant attention to security issues is important to protect the website and data sources.
Push - an EHR sends data to another EHR via the Direct standard. Since this is secure email, a modest infrastructure investment is needed to create directories, certificate management, and gateways.
Pull - an EHR queries a master patient index/record locator service to identify a patient and the locations of their records. The EHR then queries all the data sources to assemble a comprehensive medical history. NwHIN Exchange is an example of such an approach. Significant infrastructure must be built to support and maintain a pull architecture.
Since Push and Pull models require HIEs, which are still evolving, some organizations, including BIDMC and its affiliates have temporarily implemented View approaches inside Epic, Meditech, eClinical Works and self built applications.
Here's how it works:
1. The clinician clicks on a button inside their EHR. This click launches a query containing Name, Gender, Date of Birth, and Zip Code to a responding EHR. The physician does not need to respecify the patient or log in to a separate portal since the patient identity information and security credentials are sent from the querying EHR automatically.
2. The responding EHR checks the security, looks up the patient, and responds with a medical record number if the patient is found.
3. The querying EHR sends a new query incorporating the returned medical record number.
4. The responding EHR launches a web-page which displays clinical data for that medical record number.
5. All transactions are audited in the responding EHRs.
Since this approach works like magic, requires no HIE, and is fast/inexpensive to implement, our clinicians have described it as the "Magic button"
In effect, it serves as a web-based single sign application that retains patient context and enables clinicians to view data from any EHR that adheres to the Magic button implementation guide.
We see it as a temporary solution because it does not result in persistent exchange of semantically interoperable data. It simply enables a clinician to see data such as problem lists, medication lists, allergies, labs, radiology studies, EKRs, reports, and notes in remote systems without requiring a lot of training. It's better than having silos of data and sending faxes.
As HIEs come on line, push and pull models will enable the same kind of data exchange but will incorporate data from sending EHRs into receiving EHRs, enhancing workflow and improving the integrity of the record.
One other problem with the Magic button is that it does not scale very well - we now have buttons for Atrius, Needham, Milton, and eClinicalWorks practices. Clinicians ask the patient where they've received care, get their consent to view the data, and click on the appropriate magic button. As we add more affiliates, the number of Magic buttons will be hard to manage.
In future pull models, record locator services will keep an index of all the locations where patients have consented their data to be accessed.
But for now, having a kind of Blue Button that enables clinicians to view each other's records with patient consent is truly magic for those who use it.
Comments
Post a Comment