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.
Monday, January 23, 2012
3:00 AM
dssadsds
No comments
Related Posts:
Building Unity Farm - The CommunityOne of the most important aspects of choosing a farm property is the community around you* What is the zoning?* How will your neighbors react to wandering guinea fowl or an escaped llama?* Are there other farms nearby?Fo… Read More
A Novel Idea for Managing ConsentIn 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 f… Read More
The Patient Experience of EHRs I'm often asked if the use of EHRs diminish clinician-patient interactions in the exam room.At BIDMC, Jan Walker and Tom Delbanco have done focus groups with patients about technology. Generally, they found that patient… Read More
The Next Generation of Entrepreneurs When I was 13 years old, the Altair 8800 appeared on the cover of Popular Electronics. By 16, I was building enough hardware and software that I achieved the Malcolm Gladwell 10,000 hours of competency by age 18. … Read More
Cool Technology of the Week My daughter and one of my blog followers recently told me about a Japanese cultural phenomena that is truly a cool technology.One of the hottest concert pop stars in Japan is an anime hologram with a vocal synthesizer. … Read More
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment