May 1, 2011
Park defends plain-text format of ‘Blue Button’
Written by: Neil Versel
Todd Park
Well, I guess everything else pales in comparison to the news late Sunday night that Osama bin Laden has been killed and that his body is in U.S. custody, but I had been meaning to bring you something from another part of the government. So now, nearly three hours after I sat down to start writing, here goes.
Remember back in February how I reported that the Blue Button Initiative that HHS, the VA and the Department of Defense had been touting was much ado about nothing because the add-on outputs data in plain, unstructured text that’s essentially useless when imported into an EHR? Well, government officials continue to defend it.
At the Microsoft Connected Health Conference last Wednesday in Chicago, HHS CTO Todd Park extolled the virtues of Blue Button, saying that it was a conscious decision on the part of the people behind the idea—particularly ex-Google and Microsoft star Adam Bosworth and author/Internet scholar Clay Shirky—to export patient information in untagged text format as a quick means of “liberating” data from proprietary systems. It then is up to the patient and his/her providers to decide what do do with the exported record.
“We decided that the burden shouldn’t have to be on the vendor to parse the data,” Park told me offstage.
Well, what do you think of that? Should Blue Button follow some established protocol that organizes data in discrete format like the Continuity of Care Record, Continuity of Care Document or Clinical Document Architecture, or is raw, unorganized text good enough?
UPDATE, 10:50 pm CDT: I found the rest of my notes and see that Park said 270,000 unique users have downloaded data through Blue Button, an average of three times each, even though the government hasn’t done much in the way of marketing. “Simplicity is the key,” he said.
Related Articles:
Look for similar articles under these categories:
7 responses to "Park defends plain-text format of ‘Blue Button’"
Leave a Reply
- » Recent articles
- HIMSS12 sets record for tweets
- $10M settlement in death from medical error
- Poor healthcare quality hits home
- Mastering Health Wonk Review
- TEDMED to healthcare press: pay up
- Sen. Whitehouse, make some more noise, please
- Telemedicine from the 1920s?
- Might as well cash in on fervor over new iPad
- Video: ‘Meet the Bloggers’ panel from HIMSS12
- Video: Dell Healthcare Think Tank at HIMSS12
- » Archive Calendar
isn’t this why XML was invented?
Untagged text was fine in the 1980s when we first started down the EHEALTH path, but in the 21st century it is embarrassing that we are sharing data in this way. In a hospital if I expected a doctor to understand a patients status by just reciting a bunch of numbers without context and identification I would be marched off the ward. With the CCR work started last century there is no reason why data cannot be structured.
Information should be 1) accurate, 2) available, 3) human readable… then we can tag it, add functionality etc. We may want 21st century solution, but we still dont have today the information we should have had in the 80′s. I’m for plain text as a cheap, easy, widely available and imediately useful first step.
Click here to download Sample Blue Button Data Files.
https://www.cms.gov/NonIdentifiableDataFiles/downloads/CMS-Blue-Button-txt-files.zip
I would have preferred XML or JSON for the data files as a technical standard; I would prefer not to use a HealthCare standards (CCD, CCR, etc.) because they need more time to work out, in my opinion. I completely agree with Denis, “widely available and immediately useful” are the most important steps right now.
There are other issues with BlueButton related to when claim data is shown and when it is not that are much larger sources of concern for me, than the data format delivered.
Best wishes!
Pete Gordon
http://www.linkedin.com/in/petegordon
This does seem like an odd choice. XML would have definitely been better. XML is nearly as good as plain text as far as readability, but infinitely more powerful in other regards.
I love simplicity. I am sure converting the data into XML format would be rather trivial. Keep in mind that even though we like to think that everyone should be able to use XML, there are still systems, especially in healthcare, that have difficulty with it. Simply stating that they need to upgrade is naive because there is a lot more to upgrading a system that technology. It is mainly retraining users IMHO.
People attacking Blue Button are a little bit off, for what Blue Button is supposed to be. They are basically saying they want to see data in a text format without any other proprietary or otherwise formatting around it (HTML, MS Office, XML, etc), which, in and of itself, is a fine goal. That is to facilitate the person giving the data to another person to “look at”, and not need any special software.
The criticism should be that the Govt. agencies are not ADDITIONALLY exporting data from their systems in a CCD or CCR format. While you can take the time to craft something to pull data from where it appears the “HealthEVet” files put things, it won’t help you past that, because other than being ASCII, there is no requirements of format for anyone elses BB files, so, the parser you create is effectively only useful for HealthEVet files. This is what “kills” discrete data flow between systems and organizations. Of course, most other vendors will create CCD & CCR anyway, precisely because they have to for Government Meaningful Use measures… funny how a govt. agency doesn’t have to live up to that themselves.
So, it isn’t the Blue Button “format” requirement that is bad by itself… it is that it is the ONLY format that they are releasing the data with.