Wednesday, September 12, 2012

The Magical Little BlueButton

John Moore over at Chilmark Research writes on "The Promise of a Little Blue Button" yesterday.  I wish I could have been in Washington, DC to help him interpret what is going on (we know each other pretty well).  I understand why he was disappointed; ONC isn't always the greatest communicator.

Anyone who knows how Blue Button started [like John], and what the VA current implementation is, would certainly be disappointed to see ONC perpetuate the distribution of ASCII text files to patients.  It used to be I wouldn't wear a Blue Button, because I had already worked on providing doctors and their patients with access to a much richer data set.  ePatientDave was so disappointed with me when I refused the Blue Button he offered me at HIMSS12.  But, I understand John's confusion.

I proudly wear a Blue Button now.  That was the day that ONC announced to a rather select group that Blue Button was no longer a noun (the ASCII Text File), but rather a verb, representing access to data.  And detailed data, just like providers have.  At that meeting, I asked Dave for the Blue Button he had offered me before, and put it on my Jacket.

The Blue Button I will use, and my daughter will use, will be a nicely formatted, quite usable [204(a)], Consolidated CDA Document [205(a)(3)] when we view [314(e)(1)(i)(A)] it.  When we download [314(e)(1)(i)(B)] it, I expect we'll have a couple of options.  We could get the Woolly Mammoth Era ASCII Text file.  We could also get the decently formatted HTML.  But, we will also be able to download to our personal devices, the detailed clinical data that appears in a HL7 Consolidated CDA document [see reference to 205(a)(3)] .  That's what we'll use.

I know of PHR vendors that will be able to import that data on apps we can (or do) use on our i* devices.  And every provider with a Meaningful Use Certified EHR will be able to support View and Download, and unless they have the broadband exception, will be able to support it for at least 5% of patients.  I'll be able get it on my iPad, and my daughter on her iPhone, and others, on their Android, or home computer.

Those same portals and apps will enable us to make available, via the transmit [314(e)(1)(i)(C)] capability, that same data to other providers we've been referred to. Their EHRs will support receipt of that data, if they are Meaningful Use Stage 2 Certified.  They'll get nicely laid out report containing meds, problems, allergies, and results (Images will likely come in Stage 3), and more.

They will contain, at the very minimum [314(e)(2)(i)], the MU Common Data Set [102], comprised of the following data elements:
1) Patient name.

2) Sex.
3) Date of birth.
4) Race
5) Ethnicity
6) Preferred language
7) Smoking status
8) Problems
9) Medications
10) Medication allergies
11) Laboratory test(s)
12) Laboratory result(s)
13) Vital signs
14) Care plan field(s), including Goals
15) Procedures
16) Care Team Member(s)

Beyond that it will also include [314(e)(2)(iii)]: 
  • Reason for Visit, 
  • Encounter Diagnosis, 
  • Immunizations, 
  • Pending Tests, 
  • Clinical Instructions, 
  • Future Appointments, 
  • Referrals to Other Providers, 
  • Future Scheduled Tests, and 
  • Recommended Patient Decision Aids.
That's a pretty complete record, by any stretch of the imagination.  Printed on paper, it could go for three pages or more.

This isn't some futuristic dream, but it almost surely sounds magical.  Trust me on this one John, it's in the rules, and it's in #ABBI.


  1. thanks for clarity. However, I reccomend adopting "gender" over "sex." When talking about patient matching data you get a lot of snickers when you mention "sex is mandatory."

    1. Gender was the term originally used. There was a lot of discussion at the highest levels on the use of the term sex vs. gender. The change from "gender" to "sex" was made after that debate occurred.

      My own personal opinion is that if we are to continue to make progress, your last statement is indeed correct.

  2. Good update Keith. Yes I agree the consumer gets easily confused with all of this and what format is their Blue Button going to be. ASCII is for sure a great start but you are right we need to move up the next level. We barely have CCR out there in some areas and now CDA. We can't expect the consumers to understand all of this either and almost best to wait until the prototype is built so we have a show and tell and consumers get a visual, otherwise, yes it confuses folks unless you are in the field and working it day in and day out:)

  3. Verb or noun, would your mother really care? My mother and probably yours does not know the difference between an ASCII file, a text file, CCD, or CDA?

    Blue Button started simple. To provide the patient with a readable Medical or claims record. Let's get the first step done before you make it complex.

    1. Bad assumption. My mother does know the difference, and so does my 10-year old daughter. The first step, enabling the download is there, what we need is to enable the ecosystem, and encourage app developers to use it. They DO care. The better data they get, the more value they can provide to patients. And that value is what my mother (and my daughters) do care about.

  4. Are you proposing that the MU Common Data Set is minimum BB standard or are you reporting that it is?