VDT, or View, Download and Transmit, is a set of requirements for 2014 Certified Electronic Health records under Meaningful Use for the EHR to enable the patient to View, Download or Transmit their data. In addition to VDT requirements, the EHR must also use the Consolidated CDA (CCDA) under those regulations, and must support The Direct Protocol, and may support other protocols.
Providers who want to get incentive $$$ for Meaningful Use must use the standard format (CCDA) when enabling patients to Download or Transmit data. They may, but are not required to use the standard protocols the EHR must support for transmission of CCDA documents for referral. This is a rare exception to the general rule that to obtain the incentive, you must use the certified capability. In making this exception CMS understood that some very functional referral networks already had document transmission capabilities and did NOT want to have to replace them with The Direct Protocol just to support the same feature.
Blue Button Plus is an extension of Blue Button that uses the CCD and CCDA formats specified under the 2011 and 2014 Certification and Standards rules to exchange patient data. When the document is transmitted using The Direct Protocol, effectively you have the BB+ Push capability. When it can be downloaded using a pre-draft subset of the HL7 FHIR standard, you have the BB+ Pull capability.
Neither the 2011, 2014, or proposed 2015 certification criteria require Blue Button or Blue Button Plus. Blue Button Plus has been proposed for 2017 certification criteria.
Oh, and finally, Blue Button, Blue Button Plus and Open Notes are very similar. When you can get your Open Notes using the CCD or CCDA format, effectively you are using the same content standards supported by BB+, and then it is all a matter of how you would download or transmit it.
That is the challenge when setting the low bar in VDT. More functional bars like BB+ Push or BB+ Pull aren't required by Meaningful Use, but are perfectly capable of meeting the requirements for it.
Showing posts with label BlueButton. Show all posts
Showing posts with label BlueButton. Show all posts
Monday, June 9, 2014
Thursday, September 19, 2013
How We Got Here is Almost as Important as Where We are Going
I met a man on Monday after the Consumer Health IT Summit who proceeded to explain to me what's wrong with Blue Button, CCDA and Meaningful Use. He was a physician, an anesthesiologist by trade. And for ten minutes I was harangued about how badly broken smoking status and CCDA was in Meaningful Use stage 2. How the value set was useless to him, didn't capture the data he needed, and how of course everyone knew that the right way to measure smoking history was pack-years.
I listened to his story patiently, and stopped to ask him some of the same questions I had asked 2, 3, 4, 5 and more years ago on the same topic. The first question is what about non-cigarette equivalences (e.g., pipe, cigar or chew). I never did get to the next question about what is the unit of measure (because pack is as arbitrary as tablet) because we moved onto a different part of the topic.
I managed to explain that these questions had been asked (by me) as much as seven or eight years ago, when IHE was first developing some of its profiles, and again some 5 or 6 when HITSP was working on some other topics. And that at the time, we never did get consensus among physicians as to what the correct way to represent the result was. So his "everyone knows" didn't come out because what everyone knew was different (Ask the same question of five physicians and you can get six answers, the same is true of lawyers and engineers, the only difference is the question topic).
And then we talked about the fact that the original set of concepts found in Meaningful Use stage 1 came from a CDC Survey Instrument. And that the main use of these was with quality measures about smoking cessation, not assessment of cancer risk. And that while the CDC survey concepts may have been solid, what was recorded in EHRs using those same categories blurred the lines because of course EPs don't ask questions the way that CDC surveyed people. And then how later in stage 2 physicians complained because these concepts didn't fit their workflow because they weren't fine grained enough (light and heavy smoker were subsequently added). I'll note now that this points out that there are multiple uses for this datum. And that implementers complained that a set of concepts without codes wasn't useful, and so the Smoking Status value set was born. And that my friends, is how we come to a value set that it seems the only consensus is that everyone dislikes using it, but have little better to offer.
We also talked about (the new) Blue Button. He complained that it was still stuck on documents, and that that was not useful (I seem to recall he used stronger language). Yes. For now. And had he been involved in the ABBI workgroup (too little). Was he aware how it prepares the way (the route) for being about more than documents, supporting the data elements we want (No). And how it's using the parts of FHIR that appear to be ready now (a bit). Yes he was familiar with FHIR, he's on an HL7 workgroup looking at FHIR now. And have you voted on FHIR (I never got a solid answer). I fear the answer is in the negative, and hope otherwise.
It was an interesting encounter. I felt as if I had somehow managed to explain to one person what is happening and how we got here, and where we are going, and had some success.
I listened to his story patiently, and stopped to ask him some of the same questions I had asked 2, 3, 4, 5 and more years ago on the same topic. The first question is what about non-cigarette equivalences (e.g., pipe, cigar or chew). I never did get to the next question about what is the unit of measure (because pack is as arbitrary as tablet) because we moved onto a different part of the topic.
I managed to explain that these questions had been asked (by me) as much as seven or eight years ago, when IHE was first developing some of its profiles, and again some 5 or 6 when HITSP was working on some other topics. And that at the time, we never did get consensus among physicians as to what the correct way to represent the result was. So his "everyone knows" didn't come out because what everyone knew was different (Ask the same question of five physicians and you can get six answers, the same is true of lawyers and engineers, the only difference is the question topic).
And then we talked about the fact that the original set of concepts found in Meaningful Use stage 1 came from a CDC Survey Instrument. And that the main use of these was with quality measures about smoking cessation, not assessment of cancer risk. And that while the CDC survey concepts may have been solid, what was recorded in EHRs using those same categories blurred the lines because of course EPs don't ask questions the way that CDC surveyed people. And then how later in stage 2 physicians complained because these concepts didn't fit their workflow because they weren't fine grained enough (light and heavy smoker were subsequently added). I'll note now that this points out that there are multiple uses for this datum. And that implementers complained that a set of concepts without codes wasn't useful, and so the Smoking Status value set was born. And that my friends, is how we come to a value set that it seems the only consensus is that everyone dislikes using it, but have little better to offer.
We also talked about (the new) Blue Button. He complained that it was still stuck on documents, and that that was not useful (I seem to recall he used stronger language). Yes. For now. And had he been involved in the ABBI workgroup (too little). Was he aware how it prepares the way (the route) for being about more than documents, supporting the data elements we want (No). And how it's using the parts of FHIR that appear to be ready now (a bit). Yes he was familiar with FHIR, he's on an HL7 workgroup looking at FHIR now. And have you voted on FHIR (I never got a solid answer). I fear the answer is in the negative, and hope otherwise.
It was an interesting encounter. I felt as if I had somehow managed to explain to one person what is happening and how we got here, and where we are going, and had some success.
Tuesday, September 17, 2013
Health IT Week
I spent the day at the Consumer Health IT Summit kicking off Health IT week in DC. The day was packed with activities scheduled down to 5, 10 and 15 minute blocks of time. Even with an unscheduled break built in they still managed to end the day on time.
Farzad was our host du jour. He briefly talked about how many of us in the room were misfits, a quote that Regina Holliday immediately riffed on in her art (see the last image).
ePatient Dave gave the keynote, "How Far We've Come: A Patient Perspective". He ran through 40 slides in 15 minutes, an amazing pace. The deck was remarkable for how many different topics it touched on that we've been through over the past few years, and I even got a starring role in a few slides. A lot of what we heard today I've heard before in other settings, but many of the people in the room were hearing it for the first time.
OCR updated their memo on patient's right to access data just in time for new rules to go into effect Monday of next week (if you need to find that again quickly, it's at http://tinyurl.com/OCRmemo). They also released new model notices of privacy practices. They also added a video (below):
The folks over at OCR have been pretty busy I'd say.
There's some new work, "Under Construction" at ONC around Blue Button, and that's a nationwide gateway into the Blue Button eco-system. Patient's will be able to find out from that site how to access their data from providers and payers using Blue Button. Want to be sure your patients can connect to that? Talk to @Lygeia. We previewed a great video that I would love to be able to use to sign up data holders. It's a shame that at a meetup of several well-connected social media folk, there isn't a list of URLs to redistribute, but well, as Farzad said a few months back, Marketing really isn't the government's forte.
We heard from a number of folks at ONC, CMS, OCR and elsewhere in HHS in the first half of the morning. A couple of key take-aways for me: In recent regulation, CMS proposed paying for coordination of care, a la using meaningful use capabilities like Blue Button. Director of eHealth Standards at CMS Robert Tagalicod was also heard to say that "We are looking at incenting the use of Blue Button for Meaningful Use Stage 3." No surprise to me, but confirmation is always good.
Todd Park (US CTO) popped in for a short chearleading session. If anyone can talk faster about Blue Button than Farzad, it's Todd (I feel comfortable calling him Todd because that's what my daughter calls him).
We had a short unscheduled break because the ONC folk finally realized that four hours in our seats was NOT going to cut it. Someone needs to teach these folks how to run a conference someday. It would also be nice if we didn't have to go through security just to get a cup of coffee (but after GSA and sequestration, what could we expect). Even so, a quick fifteen minute break and we were back in our seats. Lygeia wields a mean hammer.
The Consumer Attitudes and Awareness Session was the first foray I'd seen where ONC started talking about marketing. I'm still a bit disappointed that so far, ONC is only thinking about targeting people who are already sick in their Blue Button marketing efforts, I really think that we need to change our culture, and that means starting with our youth. I'll keep hounding them and anyone else who will listen until I get my way there. I can teach an eight-year-old to write a HIPAA letter. Why shouldn't we start with eighteen-year-olds.
ONC announced the winner of the Blue Button Co-Design Challenge: GenieMD. The app looks good and it has the one main thing I want, it uses an API to access my data. I'll have to take a look at it later.
We heard from a panel of eHealth Investors. I couldn't help but feel that they are still disconnected from patients. The issue of monetization of eHealth seems to have two places to go, either get more revenue dollars from patients, doctors or anyone else who has it to spend, or take a cut of the savings. I don't think any one of these investors realize that the Healthcare market is saturated with places to spend money, and adding one more will only take in a little bit, where as the opportunities for SAVING money are probably a lot more lucrative, and could readily pay for the investment. The more products that are built to deliver patients, patient data, or health data to someone else for bucks, the more silos we simply create in our healthcare delivery system. We've got to think about ways to make money by freeing up things and breaking down barriers. As I tweeted during that session:
And that was retweeted a dozen times.
After lunch we met up again to do some work on Outreach and Awareness to Consumers, including getting into some of the marketing details around the new program, and doing some A/B testing with the audience.
Overall, it was a good day. Now I sit in my hotel room in Philly, writing this post, and preparing for tomorrows ePatient Connections conference where I'm speaking and on a panel. It's not my usual venue, but I have a soft-spot for Philly since my family is from here, and I grew up outside the city. So, I'm taking a personal day for the conference here, and then I'm back home for a few days. After that, it's the worst way to attend an HL7 conference: Drive in every day, and home every night. I'll get to see my bed, but probably not any of my family while they are aware. I'll be at the HL7 Working Group meeting in Cambridge.
And to polish it all off, here is Reggie's art: With Lygeia, ePatient Dave, Farzad, and Leon all getting ready to depart the Island of Misfits.
Fitting I think (or should that be misfitting). Farzad will be leaving ONC on October 5th, and had this advice to offer his successor (I think she'll do just fine).
-- Keith
P.S. I am very sad that today was so marred by the attacks at the Navy Yard. That was about a half mile from where we all were sitting. The Police presence in the city as we headed over to Tortilla Coast was not quite as scary as Boston a week after the bombings, but still close enough. I'm not used to walking around a city where automatic rifles are carried at patrol ready and police are standing on every block.
Farzad was our host du jour. He briefly talked about how many of us in the room were misfits, a quote that Regina Holliday immediately riffed on in her art (see the last image).
ePatient Dave gave the keynote, "How Far We've Come: A Patient Perspective". He ran through 40 slides in 15 minutes, an amazing pace. The deck was remarkable for how many different topics it touched on that we've been through over the past few years, and I even got a starring role in a few slides. A lot of what we heard today I've heard before in other settings, but many of the people in the room were hearing it for the first time.
OCR updated their memo on patient's right to access data just in time for new rules to go into effect Monday of next week (if you need to find that again quickly, it's at http://tinyurl.com/OCRmemo). They also released new model notices of privacy practices. They also added a video (below):
The folks over at OCR have been pretty busy I'd say.
There's some new work, "Under Construction" at ONC around Blue Button, and that's a nationwide gateway into the Blue Button eco-system. Patient's will be able to find out from that site how to access their data from providers and payers using Blue Button. Want to be sure your patients can connect to that? Talk to @Lygeia. We previewed a great video that I would love to be able to use to sign up data holders. It's a shame that at a meetup of several well-connected social media folk, there isn't a list of URLs to redistribute, but well, as Farzad said a few months back, Marketing really isn't the government's forte.
We heard from a number of folks at ONC, CMS, OCR and elsewhere in HHS in the first half of the morning. A couple of key take-aways for me: In recent regulation, CMS proposed paying for coordination of care, a la using meaningful use capabilities like Blue Button. Director of eHealth Standards at CMS Robert Tagalicod was also heard to say that "We are looking at incenting the use of Blue Button for Meaningful Use Stage 3." No surprise to me, but confirmation is always good.
Todd Park (US CTO) popped in for a short chearleading session. If anyone can talk faster about Blue Button than Farzad, it's Todd (I feel comfortable calling him Todd because that's what my daughter calls him).
We had a short unscheduled break because the ONC folk finally realized that four hours in our seats was NOT going to cut it. Someone needs to teach these folks how to run a conference someday. It would also be nice if we didn't have to go through security just to get a cup of coffee (but after GSA and sequestration, what could we expect). Even so, a quick fifteen minute break and we were back in our seats. Lygeia wields a mean hammer.
The Consumer Attitudes and Awareness Session was the first foray I'd seen where ONC started talking about marketing. I'm still a bit disappointed that so far, ONC is only thinking about targeting people who are already sick in their Blue Button marketing efforts, I really think that we need to change our culture, and that means starting with our youth. I'll keep hounding them and anyone else who will listen until I get my way there. I can teach an eight-year-old to write a HIPAA letter. Why shouldn't we start with eighteen-year-olds.
ONC announced the winner of the Blue Button Co-Design Challenge: GenieMD. The app looks good and it has the one main thing I want, it uses an API to access my data. I'll have to take a look at it later.
We heard from a panel of eHealth Investors. I couldn't help but feel that they are still disconnected from patients. The issue of monetization of eHealth seems to have two places to go, either get more revenue dollars from patients, doctors or anyone else who has it to spend, or take a cut of the savings. I don't think any one of these investors realize that the Healthcare market is saturated with places to spend money, and adding one more will only take in a little bit, where as the opportunities for SAVING money are probably a lot more lucrative, and could readily pay for the investment. The more products that are built to deliver patients, patient data, or health data to someone else for bucks, the more silos we simply create in our healthcare delivery system. We've got to think about ways to make money by freeing up things and breaking down barriers. As I tweeted during that session:
I don't want your app, I want MY data in MY choice of apps. I have a dozen apps, they don't talk to each other #BlueButton #HealthITWeek
— Keith W. Boone (@motorcycle_guy) September 16, 2013
And that was retweeted a dozen times.
After lunch we met up again to do some work on Outreach and Awareness to Consumers, including getting into some of the marketing details around the new program, and doing some A/B testing with the audience.
Overall, it was a good day. Now I sit in my hotel room in Philly, writing this post, and preparing for tomorrows ePatient Connections conference where I'm speaking and on a panel. It's not my usual venue, but I have a soft-spot for Philly since my family is from here, and I grew up outside the city. So, I'm taking a personal day for the conference here, and then I'm back home for a few days. After that, it's the worst way to attend an HL7 conference: Drive in every day, and home every night. I'll get to see my bed, but probably not any of my family while they are aware. I'll be at the HL7 Working Group meeting in Cambridge.
And to polish it all off, here is Reggie's art: With Lygeia, ePatient Dave, Farzad, and Leon all getting ready to depart the Island of Misfits.
Fitting I think (or should that be misfitting). Farzad will be leaving ONC on October 5th, and had this advice to offer his successor (I think she'll do just fine).
P.S. I am very sad that today was so marred by the attacks at the Navy Yard. That was about a half mile from where we all were sitting. The Police presence in the city as we headed over to Tortilla Coast was not quite as scary as Boston a week after the bombings, but still close enough. I'm not used to walking around a city where automatic rifles are carried at patrol ready and police are standing on every block.
Monday, June 10, 2013
Patient Access Summit II
Kicked off by Matthew Holt (@boltyboy) of Health 2.0 fame, and hosted by Todd Park and Farzad Mostashari, this meeting was a followup from last year's Patient Access Summit (which I also attended with my daughter).
We reviewed the progress we've made since our first meeting (about a year ago), and identified the things that we still need to work on. As an outcome of this meeting, we identified six separate gaps to address:
- Awareness: More needs to be done to raise awareness among patients, providers and health IT vendors about patient rights and technology available to access data, and Blue Button Plus alignment with Meaningful Use incentive programs.
- Services: Identifying needed services (e.g., data reconciliation and filtering), and prioritizing them was another issue. We expect that industry will develop services as the needs are identified. In other words, the ONC role here is more to shine a light one what is needed.
- Trust. "Trust me", and "I'm here to help" are two statements that get even scarier when you start them off with "I'm with the government". There's a lot that needs to be done to develop trust. Some of that is time, and some of that is awareness.
- Provisioning. This is more about provisioning patients, and/or making it easy to provision patients with a Direct address, or an identity supporting OAuth 2.0. It was focused on workflow and user experience rather than technology.
- Pull. We need data holder participation, and when we asked for it, a number of them (in fact, about 1/4 of the room) raised their hands.
- Payers. There's an interim payer specification that we'd like to see payer's start using, and a need to get that on a standards track.
In reviewing the list of gaps, one thing that Farzad noted was that we didn't have any issues around standards needing to be developed, which was a big different from where we started a year ago.
I did manage to leave Farzad speachless when I asked if we should hold our calendars open for Patient Access Summit III next June. Next year, I think we need to be in the West Wing.
Wednesday, March 6, 2013
Social Interoperability
Every now and then a string of words will get put together, and peoples ears perk up, and you realize that you've created a new meme. That happened to me today at the HIMSS Standards and Interoperability panel presentation. We were talking about how to make it easier for patients and providers to communicate about how to get their data. One nurse in the audience talked about how, when patients ask for their CCD, the person at the other end of the conversation wouldn't know what they are talking about. CCD and CCDA are geek speek. Another audience member explained that giving every provider an EHR shouldn't come with the expectation that they would all become computer geeks. I completely agree. We need a better way to talk about this. A way that grandma, or my 10-year old can understand.
The benficiaries of interoperability are patients, and yet we still haven't given them a way to communicate how to get their data. This is where the notion of social interoperability comes in. It's your data, ask for it is a short commercial I wrote a script for back in 2010. The idea behind it was that we need to educate patients about how to ask for their records in a way that everyone, patients, providers, and vendors understands. What they mean is give me my CCD and/or CCDA, but we geeks don't really need for everyone to understand that's the secret sauce.
It's what marketers would probably call a brand awareness problem. What is the brand for patient engagement? Is it CCD/CCDA? BlueButton? BlueButtonPlus? VDTNow? Meaningful Use? None of the above? We need to agree on, and communicate that to patients and consumers, and then we need to educate vendors and providers what that means.
Social Interoperability, the ability to communicate with normal human beings, will create the demand for and use of technical interoperability. And that will get us all where we want to be. After all, it isn't just providers we want to be meaningful users of data and technology, it's for patients too.
The benficiaries of interoperability are patients, and yet we still haven't given them a way to communicate how to get their data. This is where the notion of social interoperability comes in. It's your data, ask for it is a short commercial I wrote a script for back in 2010. The idea behind it was that we need to educate patients about how to ask for their records in a way that everyone, patients, providers, and vendors understands. What they mean is give me my CCD and/or CCDA, but we geeks don't really need for everyone to understand that's the secret sauce.
It's what marketers would probably call a brand awareness problem. What is the brand for patient engagement? Is it CCD/CCDA? BlueButton? BlueButtonPlus? VDTNow? Meaningful Use? None of the above? We need to agree on, and communicate that to patients and consumers, and then we need to educate vendors and providers what that means.
Social Interoperability, the ability to communicate with normal human beings, will create the demand for and use of technical interoperability. And that will get us all where we want to be. After all, it isn't just providers we want to be meaningful users of data and technology, it's for patients too.
Tuesday, September 25, 2012
Provisioning an Application to automatically find ABBI's BlueButton
One of the challenges for ABBI is how the user (the patient) will be able to find how to access their data from an application. We could send them an e-mail they'd need to copy into their application, but that can often be challenging. My big fingers are challenged typing in on my iPhone, and depending on what account you send the URL to, it might not be one that is accessible on my iPhone.
But I can readily point a browser to my favorite sites. In fact, those are pretty easy to find on any of my devices. So what if we made it possible for the provider website to "provision" the third party application that wants to access my data?
If you view source on this website, you'll find the following links in the HTML header.
These are commonly understood by browsers to be the where the atom and RSS feeds for this web site are found. Because of those, browsers are able to automatically identify the feeds, and allow you to subscribe to the site.
[I'll give you just a brief moment to subscribe to this site...]
Every patient portal that wants to support ABBI should have a similarly easy mechanism to point their users to the search URL that the application needs. That way, third party applications can readily be configured by just pointing them to the patient's portal, and they'll automatically configure themselves correctly.
The <link> tag has several attributes:
HTML defines a number of standard relationships, including alternate, appendix, bookmark, chapter, contents, copyright, glossary, help, home, index, next, prev, section, start, stylesheet, and subsection; but none of these are really appropriate in any case. So, let's just use ABBI as the value for rel. If the portal has a <link rel='ABBI'>, then an application could know to use that as the endpoint for requests.
But I can readily point a browser to my favorite sites. In fact, those are pretty easy to find on any of my devices. So what if we made it possible for the provider website to "provision" the third party application that wants to access my data?
If you view source on this website, you'll find the following links in the HTML header.
<link rel="alternate" type="application/atom+xml"
title="Healthcare Standards - Atom"
href="http://motorcycleguy.blogspot.com/feeds/posts/default" />
<link rel="alternate" type="application/rss+xml"
title="Healthcare Standards - RSS"
href="http://motorcycleguy.blogspot.com/feeds/posts/default?alt=rss" />
These are commonly understood by browsers to be the where the atom and RSS feeds for this web site are found. Because of those, browsers are able to automatically identify the feeds, and allow you to subscribe to the site.
[I'll give you just a brief moment to subscribe to this site...]
Every patient portal that wants to support ABBI should have a similarly easy mechanism to point their users to the search URL that the application needs. That way, third party applications can readily be configured by just pointing them to the patient's portal, and they'll automatically configure themselves correctly.
The <link> tag has several attributes:
- rel
- The relationship between the content and the linked URL
- type
- The mime type of the linked URL
- title
- The title of the content associated with this link
- href
- The URL to go to get the linked content
HTML defines a number of standard relationships, including alternate, appendix, bookmark, chapter, contents, copyright, glossary, help, home, index, next, prev, section, start, stylesheet, and subsection; but none of these are really appropriate in any case. So, let's just use ABBI as the value for rel. If the portal has a <link rel='ABBI'>, then an application could know to use that as the endpoint for requests.
<link rel="ABBI" type="application/atom+xml"
title="Automated Blue Button Download"
title="Automated Blue Button Download"
href="URL to atom search feed" />
This same sort of mechanism is widely adopted not just to associate feeds with a web page, but also stylesheets, icons, and a number of other readily accessible resources. We just use this with ABBI to make it easy for applications (and users) to navigate the their data sources.
-- Keith
This same sort of mechanism is widely adopted not just to associate feeds with a web page, but also stylesheets, icons, and a number of other readily accessible resources. We just use this with ABBI to make it easy for applications (and users) to navigate the their data sources.
-- Keith
Thursday, September 13, 2012
Why Not Both? The Genius of the AND, 2012 Edition
John Halamka's "Genius of the AND" post seemingly reversed a half-decade of progress in the CCR/CDA debate, but unblocked a political log-jam that we can now see has led to a market choice towards CDA. That simple idea, "why not both", came back to me again while discussing the current challenges with content for the ABBI project with Doug Fridsma. I espoused the viewpoint that Consolidated CDA was the mandated format that all providers will have to use, and that I didn't want to see dumbed down ASCII or PDF in downloads. And so he did as he has to me several times, asked a simple question which changed my viewpoint. "Why Not Both?"
And then John Moehrke jumped in. No reason at all. You can negotiate it. In fact, hData, MHD and FHIR all support query parameters that let you ask for what you want.
And I know that their are transforms from the provider mandated Consolidated CDA format to text/html, text/plain (via Corey Spears excellent Blue Button Stylesheet efforts), and from text/html to application/pdf, and also from text/xml to application/json (and potentially from Consolidated CDA to FHIR).
So, my thinking is that my ABBI PULL Implementation will support content negotiations. That data sources will either locate content in the requested format, or transform content in other formats to the requested format.
It should be pretty easy to ensure that the appropriate content negotiation parameter exists in the protocol.
Meanwhile, back at the ranch, John Moehrke, Grahame Grieve and Gerald Beuchelt are out their aligning MHD, FHIR and hData across IHE, HL7 and OMG. No S&I Framework project is necessary. That may in fact be the greatest success of S&I, is the fear that if we do not do it, they'll decide to come along and do it for us.
So, I expected to have an MHD implementation for the IHE Connectathon, and will be using the same code for the HL7 FHIR Connectathon, perhaps with a bit different transforms. And when we are done, we'll be able to pick and choose. And Gerald has offered to be a sounding board. I think I'm psyched.
I love it when a plan comes together.
And then John Moehrke jumped in. No reason at all. You can negotiate it. In fact, hData, MHD and FHIR all support query parameters that let you ask for what you want.
And I know that their are transforms from the provider mandated Consolidated CDA format to text/html, text/plain (via Corey Spears excellent Blue Button Stylesheet efforts), and from text/html to application/pdf, and also from text/xml to application/json (and potentially from Consolidated CDA to FHIR).
So, my thinking is that my ABBI PULL Implementation will support content negotiations. That data sources will either locate content in the requested format, or transform content in other formats to the requested format.
It should be pretty easy to ensure that the appropriate content negotiation parameter exists in the protocol.
Meanwhile, back at the ranch, John Moehrke, Grahame Grieve and Gerald Beuchelt are out their aligning MHD, FHIR and hData across IHE, HL7 and OMG. No S&I Framework project is necessary. That may in fact be the greatest success of S&I, is the fear that if we do not do it, they'll decide to come along and do it for us.
So, I expected to have an MHD implementation for the IHE Connectathon, and will be using the same code for the HL7 FHIR Connectathon, perhaps with a bit different transforms. And when we are done, we'll be able to pick and choose. And Gerald has offered to be a sounding board. I think I'm psyched.
I love it when a plan comes together.
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)
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.
Wednesday, August 29, 2012
Illegitimi Non Carborundum
Illegitimi Non Carborundum
<RANT>
I'm afraid they are, though. Perhaps it's just my exhaustion, what between meaningful use posts, and HL7 balloting, and basically doing all the rest of the stuff I do in standards as a professional "volunteer".
Let's start with closed standards. Define please, what you mean by open standards. You might have even mentioned some organizations like W3C, or IETF. Well, here's what W3C, IETF, IEEE, the Internet Society and others think it means: http://open-stand.org/principles/
Note that free is NOT part of the definition. This stuff has to be paid for. Someone has to build the web site, answer the phones and t-con lines, schedule meetings, and all the rest of that stuff. That costs real money. Many SDOs charge for standards. Some charge for membership. Others charge for testing services. There has to be a business model. It's just like HIE. You cannot just build it for free and expect someone to fund it.
Reasonable is part of the definition, and some would argue that HL7's prices aren't reasonable, or aren't affordable for the little guy, or ... well, they can go on for quite some time about this. Fair enough. Have you looked at the costs to join W3C? More on that below.
If all you ever do is complain from the outside, YOU will never change the organization. Change comes from within. I've been working on change from within in every single one of the organizations that I've been working with from almost the very beginning (including every employer I'v ever worked for). None of them are perfect. All of them make mistakes.
If you want to stand on your soap-box and preach, fine, your audience is in the church, you might consider moving your soap-box inside it. Meanwhile, mine's already been there long enough to get on the board, and whispering into the ears of the people in charge. Which of us do you think will be more effective?
Vested interests? That's laughable. A vested interest is "a personal stake or involvement", especially with respect to financial gain. Few of us are in a position to give away our time and effort, and so ALL of us have vested interests. Go ahead. Declare my vested interests. But declare yours first.
Here are mine: I have vested interests in being able to use CCDA, and IHE XCA standards which I've already invested a great deal of time and effort in. And neither of those are going away anytime soon. One of my interests in the ABBI project is to be able to use the same work I ALREADY HAVE TO DO, for Meaningful Use, and reuse it again to support what I think patients want (and remember, I am one). In this, it would be awful nice to kill two birds with one stone.
At the same time, I ALSO want these content standards to be easier to use. I've worked on two separate projects Documents for Mobile Health in IHE (MHD), and FHIR in HL7, to simplify things. I think MHD is ready for use in the pull situation. HL7 is still working on FHIR, and so am I. I don't want to deal with yet another content standard that nobody can describe in real terms of anything other than what it isn't (HL7 CDA).
If you want to change something, it is much better to offer a suggestion of what to change it to, rather than to just say "I don't like that one". And, BTW a list of requirements for a new standard IS NOT a standard. It won't meet the project deadlines. If you want to work on the next generation XML or JSON content standards, I suggest you go work on the FHIR project with Grahame, Lloyd and others (including me). Because that's where it's happening. There will even be some testing going on in a couple of weeks (and I'll be tweeting out from that event).
Members only club. Well, I have to agree, every organization I've ever known is about its members, and I really don't think there's a reason any of them should ever apologize for it. This particular attack was basically against the principle that you should pay for a product. Frankly, I want all standards to be free, but I also want free gas, food and a house too. It is never free.
People cite W3C and OASIS as ideal models of free standards. But they aren't golden models for me. I cannot afford to be a member of either W3C or OASIS. I cannot vote on their standards, nor can I participate in governance. It would cost my employer more than three times what it spends on HL7 to become of member of W3C. If I personally were to join, it would be thrice what a consultant would paid to HL7. This is how they can manage to make their standards free, by charging big fees to to members. So, I cannot vote on those standards, nominate something to become a standard, or participate much in the development process, vote for committee chairs, or board members. All I get to do is use their standards for free. How's that for members-only?
Do me a favor, show some respect and save politically loaded vocabulary for some other meeting. We've got a ton work to do, and my daughters are counting on us, to make their data available.
</RANT>
Thanks. If you've gotten this far, thanks for listening. That's off my chest now. I can at least go back to address the issue of being tired. Cranky? We'll see what surprises tomorrow holds for me.
Keith
<RANT>
I'm afraid they are, though. Perhaps it's just my exhaustion, what between meaningful use posts, and HL7 balloting, and basically doing all the rest of the stuff I do in standards as a professional "volunteer".
Closed StandardsThese are the politically loaded phrases people are throwing around in recent discussions on the #ABBI project. Most of the time I can just ignore them, even though I find them alienating, but tonight for some reason, I just cracked. I bust my ass doing this work, because I love what I do, and because I really do believe I'm doing the right thing. It's always been about me, my family, my tribe, and my community, first, before I ever get to considerations of my employment, or the organization that I'm doing stuff for. And that's because if it isn't right for them, it isn't right. Period. I get tired and cranky, and right now, I'm probably right at the peak of cranky.
Vested Interests
Members only Club
Let's start with closed standards. Define please, what you mean by open standards. You might have even mentioned some organizations like W3C, or IETF. Well, here's what W3C, IETF, IEEE, the Internet Society and others think it means: http://open-stand.org/principles/
Note that free is NOT part of the definition. This stuff has to be paid for. Someone has to build the web site, answer the phones and t-con lines, schedule meetings, and all the rest of that stuff. That costs real money. Many SDOs charge for standards. Some charge for membership. Others charge for testing services. There has to be a business model. It's just like HIE. You cannot just build it for free and expect someone to fund it.
Reasonable is part of the definition, and some would argue that HL7's prices aren't reasonable, or aren't affordable for the little guy, or ... well, they can go on for quite some time about this. Fair enough. Have you looked at the costs to join W3C? More on that below.
If all you ever do is complain from the outside, YOU will never change the organization. Change comes from within. I've been working on change from within in every single one of the organizations that I've been working with from almost the very beginning (including every employer I'v ever worked for). None of them are perfect. All of them make mistakes.
If you want to stand on your soap-box and preach, fine, your audience is in the church, you might consider moving your soap-box inside it. Meanwhile, mine's already been there long enough to get on the board, and whispering into the ears of the people in charge. Which of us do you think will be more effective?
Vested interests? That's laughable. A vested interest is "a personal stake or involvement", especially with respect to financial gain. Few of us are in a position to give away our time and effort, and so ALL of us have vested interests. Go ahead. Declare my vested interests. But declare yours first.
Here are mine: I have vested interests in being able to use CCDA, and IHE XCA standards which I've already invested a great deal of time and effort in. And neither of those are going away anytime soon. One of my interests in the ABBI project is to be able to use the same work I ALREADY HAVE TO DO, for Meaningful Use, and reuse it again to support what I think patients want (and remember, I am one). In this, it would be awful nice to kill two birds with one stone.
At the same time, I ALSO want these content standards to be easier to use. I've worked on two separate projects Documents for Mobile Health in IHE (MHD), and FHIR in HL7, to simplify things. I think MHD is ready for use in the pull situation. HL7 is still working on FHIR, and so am I. I don't want to deal with yet another content standard that nobody can describe in real terms of anything other than what it isn't (HL7 CDA).
If you want to change something, it is much better to offer a suggestion of what to change it to, rather than to just say "I don't like that one". And, BTW a list of requirements for a new standard IS NOT a standard. It won't meet the project deadlines. If you want to work on the next generation XML or JSON content standards, I suggest you go work on the FHIR project with Grahame, Lloyd and others (including me). Because that's where it's happening. There will even be some testing going on in a couple of weeks (and I'll be tweeting out from that event).
Members only club. Well, I have to agree, every organization I've ever known is about its members, and I really don't think there's a reason any of them should ever apologize for it. This particular attack was basically against the principle that you should pay for a product. Frankly, I want all standards to be free, but I also want free gas, food and a house too. It is never free.
Do me a favor, show some respect and save politically loaded vocabulary for some other meeting. We've got a ton work to do, and my daughters are counting on us, to make their data available.
</RANT>
Thanks. If you've gotten this far, thanks for listening. That's off my chest now. I can at least go back to address the issue of being tired. Cranky? We'll see what surprises tomorrow holds for me.
Keith
Thursday, August 23, 2012
Automate the BlueButton PULL Proposal
I managed to attend the second #ABBI call yesterday. It's pretty clear that there will be at least three workgroups (and possibly a fourth) for this S&I Framework project.
1. PUSH: Direct + CCD/CCDA
2. PULL: They don't have an outline yet, but see below
3. Content: Meaningful Use required content and possibly other stuff.
1. PUSH: Direct + CCD/CCDA
2. PULL: They don't have an outline yet, but see below
3. Content: Meaningful Use required content and possibly other stuff.
The "possible" fourth item deals with security/privacy. However, on the call, it was pretty clear they were focused on the first three, while the WIKI page adds the fourth. It's pretty clear that security/privacy is already being dealt with on many levels in S&I, and I'd hope that we simply reuse that work.
A lot of discussion was around the wording for the scope of the project, and focused on the differentiation between access to data, and control of it. Rather than give you my rant about this, I'd rather you read this excellent post by Fred Trotter.
On PULL, what I think is needed is the following:
- Transport: IHE mHealth Profile
- Privacy/Security: TLS, OAuth and OpenId (see the RHEx Project)
- Content: CCD [MU Stage 1] and/or CCDA [MU Stage 2]
It should be pretty easy to create a connector between an XDS registry and repository (or an XCA Gateway) to support access to content via the IHE mHealth profile. It looks like I'm going to be creating a prototype to demonstrate that capability. I guess I'm going to have to find some OAuth/OpenID Server side code to reuse for this.
The benefit of this approach is that the XCA Query is already included in the Exchange specifications and in CONNECT. So, if I can adapt an IHE mHealth request into an XCA Query, this should provide a great deal of compatibility with many existing NwHIN nodes for the PULL capability.
The IHE mHealth profile DOESN'T require an underlying XDS/XCA infrastructure. The point of developing this prototype is simply to demonstrate what the mHealth profile can do to support patient access. I've found through the Query Health project that demonstrating is much more convincing than talking about it.
I'm planning on starting with the Open Health Tools IHE Project (ppt), and perhaps contributing the code to support the IHE mHealth profile.
Tuesday, August 21, 2012
"Ask for It" The Director's Cut
Usually, one releases the "Director's Cut" after the movie has already had it's run. It contains all the stuff the director had to leave on the editing room floor because it didn't fit into the constraints of the movie. Well, I have about 90 seconds to cut left, and cutting takes time, so, I'm releasing the Director's cut now, and will be entering the edited cut into the ONC Your Record Challenge in a matter of hours.
Here it is for your entertainment:
Here it is for your entertainment:
Thursday, August 9, 2012
Automate the BlueButton
This crossed my desk last night. This is clearly a follow up from Not-So-Secret White House Meetings. If you put this together with the IHE mHealth profile, and perhaps the RHEx OAuth/OpenID profiles, it seems this could get done pretty quickly.
We invite you to join a volunteer effort to “automate the Blue Button” and develop standards and specifications that would allow patients to not only download their health information to their personal computer, but also to privately and securely automate the sending of that data to their preferred holding place. This initiative will kick-off with a webinar on Wednesday, August 15th from 4:00 – 5:00PM Eastern.
To register, go to: http://wiki.siframework.org/ABBI+Kickoff+Meeting+Registration
Why? Consumer Access is A Big Priority
At the Office of the National Coordinator for Health IT (ONC), we have been placing increasing emphasis on consumers and patients--empowering them to be partners in their health through information technology. What can consumers do with their health data?
- Better understand their health and make more informed decisions
- Help to make sure that they and all of their care team members are on the same page
- Improve the accuracy and completeness of the information
- Plug it into apps and tools that promise to make information truly available when and where it’s needed
Underpinning all of these actions is electronic access to health data, which most Americans don’t yet have. But soon access to this information may be a reality for more patients and their family members.
It’s called Blue Button. Two years ago, the Department of Veterans Affairs (VA) added a simple, easy to recognize “Blue Button” to their patient portal (My HealtheVet), which gave individual users the opportunity to download their data to their personal computer.
Since then, the use of Blue Button has grown into a movement – a commitment by many of the country’s largest data holders – including the Federal government – to get personal health information out of proprietary silos and into the hands of the consumers who want a holistic picture of their health and health care.
The Centers for Medicare & Medicaid, TRICARE, United HealthCare, Aetna, and the Department of Defense have all begun offering individual’s own health care data (or will soon offer their data) to their beneficiaries in a printable, downloadable format supported by the Blue Button specifications. Several hundreds of thousands of veterans, members of the military, and Medicare beneficiaries have already downloaded their data through Blue Button.
Many of you have been direct contributors to this effort through the ONC Pledge Program, the Patient Access Summit, and other avenues, and our thanks go to you for making this important tool available to your members .
Join Us Aug 15: Automating Blue Button Initiative Webinar
Now, ONC and VA are collaborating to take this movement one step further, and we’d like you to join us.
We need experts to develop standards, developers to pilot the technology, innovations to push the envelope, and patients and providers to test that it works. For example, this initiative could enable patients to have their doctors or insurance companies automatically “copy them” on any updates to their personal health information. In another scenario, patients could “subscribe” to feeds that privately and securely send them updates to their health information, much as they currently subscribe to podcasts and news feeds.
The new effort will be a key part of the ONC’s Pledge Program in 2012-2013. It will be run through the Standards and Interoperability (S&I) Framework: a self-organizing, open, collaborative community of volunteers from the public and private sectors who are focused on providing the tools, services, and guidance to facilitate the functional exchange of health information.
Please join us for a webinar on Wednesday August 15, 2012 from 4:00 to 5:00 PM Eastern to learn more about the Automate Blue Button initiative, its charter, and timelines. To register for the webinar, go to http://wiki.siframework.org/ABBI+Kickoff+Meeting+Registration
Other Ways to Get Involved
If technical standards aren’t your area of expertise, there will be lots of other opportunities to support consumer engagement via ehealth. Stay tuned for information on a meeting we’re planning in Washington DC on September 10th that will bring together diverse groups of patients, consumer advocates, providers, payers, technology developers and policymakers toward a common goal of empowering patients to electronically access and use their health information to be better partners in their health.
Thanks as always for the great work you are doing and your willingness to collaborate,
Lygeia Ricciardi
Acting Director
Office of Consumer eHealth
Office of the National Coordinator for HIT
Doug Fridsma
Chief Science Officer
Director, Office of Science and Technology
Office of the National Coordinator for HIT
Tuesday, February 28, 2012
HL7 Project Supports the U.S. Office of Personnel Management's BlueButton ® Requirements
I'm co-leading this project with Lenel James (whom I incorrectly reported as John Ritter earlier) in HL7. Essentially, it's a stylesheet that creates a text rendering of a CCD document in the Blue Button format. Corey Spears has already done a great deal of work on the stylesheet. The stylesheet will be made available as freely down-loadable software to HL7 members.
-- Keith
P.S. I'll be back to reviewing Meaningful Use shortly...
-- Keith
P.S. I'll be back to reviewing Meaningful Use shortly...
Contact:
Andrea Ribick
+1 (734) 677-7777
For Immediate Release
Health Level Seven International Project Supports the U.S. Office of Personnel Management’s Blue Button® Requirements
Ann Arbor, Michigan – February 28, 2012 – Health Level Seven® (HL7®) International, the global authority on standards for interoperability of health information technology with members in 55 countries, today announced a response to the U.S. Office of Personnel Management’s (OPM) recent requirement that U.S. Federal Employees Health Benefit Program (FEHBP) health insurance carriers support the U.S. Department of Veterans Affairs (VA) Blue Button® text file format as a means of conveying personal health information to federal employees. In January 2012, HL7 launched a project that defines the conversion of an HL7 Continuity of Care Document (CCD®) to the Blue Button format via an XSLT style sheet tool. Because most Meaningful Use–certified health information exchange systems already possess CCD-export capabilities, the tool will be able to leverage those capabilities as a simple and effective way for many carriers to meet OPM’s new requirement.
The Blue Button, developed by the VA in collaboration with the Centers for Medicare and Medicaid Services (CMS), empowers Veterans to access and download their health information as an ASCII text file or PDF® document. The Blue Button initiative was made nationally available in October 2010. In December 2011, OPM issued a formal request to all carriers in the FEHBP to add Blue Button functionality to their web-based personal health record systems. (See: http://www1.opm.gov/news/blue-button-added-to-health-insurance-carriers-for-federal-employees,1744.aspx )
The Blue Button service participates in the health information exchange continuum by enabling Veterans and consumers to share their data with clinicians and other caregivers via a simple text file. The service is part of the expanding landscape of national and local initiatives such as the Office of the National Coordinator’s Standards and Interoperability Framework and the Beacon Community Programs.
John Ritter, co-chair of the HL7 Electronic Health Record Work Group (EHR WG), noted that HL7 quickly assembled a broad set of industry stakeholders, including vendors, providers, payers, and federal agencies, as part of its ongoing commitment to be responsive to the industry’s needs in a timely manner.
The EHR WG and Structured Documents Work Group, co-sponsors of the project, expect to offer the file conversion tool and User’s Guide in April 2012. Doug Dormer, President of SPINNphr and member of the project team stated, “I am pleased to be involved in this project. This tool will reduce my technical team’s effort to offer a data download channel to consumers in the Blue Button format and help our clients meet OPM’s requirement.”
For more information visit: www.HL7.org/EHR
About HL7
Founded in 1987, Health Level Seven International is the global authority for healthcare information interoperability and standards with affiliates established in more than 30 countries. HL7 is a non-profit, ANSI accredited standards development organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services. HL7’s more than 2,300 members represent approximately 500 corporate members, which include more than 90 percent of the information systems vendors serving healthcare. HL7 collaborates with other standards developers and provider, payer, philanthropic and government agencies at the highest levels to ensure the development of comprehensive and reliable standards and successful interoperability efforts.
HL7’s endeavors are sponsored, in part, by the support of its benefactors: Abbott; Accenture; Allscripts; Booz Allen Hamilton; Centers for Disease Control and Prevention; Duke Translational Medicine Institute; Epic; European Medicines Agency; the Food and Drug Administration; GE Healthcare Information Technologies; GlaxoSmithKline; Hospital Corporation American (HCA); IBM; InterSystems Corporation; Kaiser Permanente; Lockheed Martin; McKesson Provider Technology; Microsoft Corporation; NICTIZ National Healthcare; Novartis; Oracle Corporation; Partners HealthCare System, Inc.; Pfizer, Inc.; Philips Healthcare; Quest Diagnostics Inc.; Siemens Healthcare; Thomson Reuters; the U.S. Department of Defense, Military Health System; and the U.S. Department of Veterans Affairs. For more information, please visit: www.HL7.org
####
Thursday, January 12, 2012
Blue Button
Chris W. brings up Blue Button on the Ask me a Question page, and a few weeks ago it popped up again into my radar screen. In case you've been in hiding for the past year, Blue Button is the name of a VA initiative to enable vets to download their clinical information in an ASCII text format from the VA patient portal MyHealtheVet. It's based on a Markle Foundation specification which has gotten quite a bit of attention.
Recently the Office of Personnel Management sent a letter to health plans participating in the Federal Employee Health Benefit Program (FEHBP). I found an interesting quote in the letter (I underlined the interesting part):
Chris's main point is this (and I quote):
The scope of the project is to:
From my perspective, Blue Button is beneficial to patients, but not as big a step forward as it could be. (my S4PM friends may want to disown me for saying so, but hey, that's the way I feel). I'd much rather spend my energy on CDA Release 3 and HTML 5.
Given the importance of this project, I will be paying attention to it, and Chris is so right. Because of all the work that has already been done in CCD, this will be pretty easy. I just wish I could get some focused time on what will really move things forward.
Recently the Office of Personnel Management sent a letter to health plans participating in the Federal Employee Health Benefit Program (FEHBP). I found an interesting quote in the letter (I underlined the interesting part):
Supplying your members with the simple, low-cost and readily available Blue Button function will strengthen your contractual HIT obligations under FEHBP, align with the Meaningful Use standards laid out by Health and Human Services (HHS), and most importantly, empower your members to know their health information and make informed choices based on that information.According to the letter, you would assume that you could download the records in the electronic standard formats suggested by HHS under Meaningful Use. But wait, the Blue Button specification is just ASCII text. It doesn't follow that standard at all, and many provider and payer organizations have already implemented according the HITSP C32 Version 2.5 (one of the two allowed standards under Meaningful Use Stage 1). Sometimes I wish the left hand and the right hand would communicate a little bit better.
Chris's main point is this (and I quote):
... it occurs to me that the effort is promising (for the intended use cases) precisely because of the standardization that HL7 has been driving behind the scenes. That is, the tag sets and value formats (and vocabularies) will have a fairly high level of consistency across organizations right out of the box because of their prior work on adopting a variety of standards internally, and especially HL7 standardsIn fact, there's an HL7 project which is working its way through channels to create an XSL Stylesheet that will translate the semantically interoperable, Meaningful Use conforming HITSP C32 into the Blue Button format. Structured Documents approved it today, and it goes next to the steering division and then the TSC for final approval.
The scope of the project is to:
... produce a sample XSLT schema and background text on usage that will transform a CDA R2 CCD file into a U.S. Department of Veteran Affairs (VA) Blue Button ASCII text file.It's likely going to have to make some sacrifices to fit within the specifications required for Blue Button, because there's more that you can say and do in CDA and CCD that Blue Button accounts for.
From my perspective, Blue Button is beneficial to patients, but not as big a step forward as it could be. (my S4PM friends may want to disown me for saying so, but hey, that's the way I feel). I'd much rather spend my energy on CDA Release 3 and HTML 5.
Given the importance of this project, I will be paying attention to it, and Chris is so right. Because of all the work that has already been done in CCD, this will be pretty easy. I just wish I could get some focused time on what will really move things forward.
Subscribe to:
Posts (Atom)