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
Subscribe to:
Post Comments (Atom)
3 comments:
John -
Your locator service is something hData has been thinking about in the context the Discovery and Authntication Service (DAS). We had a presentation up there at the 5th SCAP conference in 2009 - see here. This is - conceptually based on the Kantara UMA profile on top of OAuth 2.0.
The multiple-button problem is precisely the problem described in the single sign-on world as "NASCAR". Since data about people will always reside in a plethora of places, and data services might be separate from authentication services, the NASCAR problem is inherent as long as people have choices about which services to use. In fact, a NASCAR appears on your own blog commenting interface!
A lot of work has been done on optimizing interfaces around this; see Account Chooser and WAYF.
Gerry's mention of UMA is on point. The UMA, OAuth, and OpenID Connect technologies can help to solve different slices of the problem. The UMA group is working specifically to try and enable patient-authorized healthcare record sharing, among other use cases.
(The above is written with my UMA group chair hat on!)
John -
Many of my clients are looking into HIEs as a way to facilitate the 'magic button'. Problem is many of them have interpreted their role in 'push' (where one EHR sends data to another via secure e-mail) as license to configure their technology to physically ship records into one EHR from another based on non-real time business rules, thus eliminating the need for a 'magic button' (after all, the other EHRs info is now physically in the requesting EHR). Seems like they ought to find a way to solve single signon and context management as opposed to creating a data management (and potential legal) nightmare for their technology and their clients.
Post a Comment