Forwards on ABBI

In this, I'm going to respond to some comments by Alan Viars on use of CCDA in the ABBI Project:

HL7 is fine for HIE, provider-to-provider, and provider-to-payer communication. For Blue Button however, the goal is to break from business as usual.

I was there when ABBI was first brainstormed, I get the vision.  If we really want to talk about breaking from business as usual, well, that's a whole 'nother post.  ABBI is very much like any other S&I Framework project in the last two years.

It seems that his main concern you have is that CCDA is hard for patients (and developers) to manage or deal with.  I won't even argue that point.  FHIR would be much easier.  The reality for me, is that my doctor today, could produce a CCD, and will in the very near future, be able to produce a CCDA, and I even have an App on my iPhone that understands CCD today enough to produce it.  I want it to be able to consume it, and I think they could do it.  And I know HealthVault can deal, and so can others.  There are at least three pieces of open source software available to you today to parse a CCD, and at least one supporting CCDA. There's even a stack you can use to get the content from CCD into JSON.  And all of that is freely available and unencumbered by HL7 licenses.

I understand the intent of the ABBI project is aimed at being something new and something very simple for people to manage their own data. I'm not sure what the answer is just yet, but I'm not of the option that CCDA is a good starting point. I say that because it is a overly-complex, closed standard and is the intellectual property of HL7. Its specification is not in the public domain.

Very few standards are in the public domain, and there are good reasons for organizations who publish them to maintain copyright.  We talked about overly complex, and I agree with that point.  Closed vs. Open is a struggle with definitions.  I think he means open as free of cost and redistributable to others, as he describes below:

I'd define an "open data standard" with the following meaning:
The standard is in the public domain. The specification, in its entirety, is free and public. There is no license or restriction to redistribute the standard's text in whole or in part. Any related schema, such as an XSD, is also open in the same way.

That's not the same thing as open in my book.  Open has to do with access.  Access to the standard is one part of this, but another part is access to governance over it (e.g., voting).  But if you don't assert copyright, you've lost a key tool in governance.  But he may mean public domain in the full sense, which implies that there is no governance over the standard.  If so, we'll have to agree to disagree.

Somewhere along the way, HL7 and many other organizations have lost the distinction between innovation, and standards, and so now we use standards to innovate.  It's kind of funny, because the whole point of standards is to pick one way to do things that everyone does, and has already figured out, and innovation is about picking the best way that nobody else has figured out yet.  But, I diverge.

Nothing wrong with clubs with memberships. I used to have a gym membership. But some people want to go just go to the park instead. It wouldn't be very nice if the people from the gym all got together and tried to prevent folks from opening a park as an alternative. That's kind of what it sounds like when we are at the beginning of a new effort and the tone is "it must be CCDA and DIRECT". 

Battles over content are a HUGE distraction from the real need for ABBI.  Give me My DAMN Data. You can use a CCR, but I'd prefer a CCD.  I wrote that song at the point in time when CCR and CCD were the two options.  I want what providers can give me, with as little work as possible.  That's a CCR or CCD (in fact, both are CCRs), and in the near future that's going to be CCDA.  And hopefully after that, something like FHIR will be available.

One of the missing content pieces that is still important to discuss, is the fact that we don't have financial data accessible in the same way.  I want an EOB statement that can be parsed by an App.  I could actually care less now, but later, well, after a few million of these are available to patients, we can surely do something about the pricing transparency issue.  We don't have ANY content standards for that.

I can see how open source standards groups can work with memberships, but their work products should be open using the definition I gave above. HL7 does not meet the definition. If HTTP was like Hl7, I'd have to join and pay a bunch of money just to know that 404 means "not found" and 200 means "OK". I'd agree W3C and OASIS might not be good models either. I'd offer GeoJSON, as a good example.

I think we agree in principle in this.  We'd all like HL7 to make their IP free.  Open Source isn't an option for their business model.  That's an over beer discussion, but the short version is that open source works for one, but not for many, and HL7 has (Too) MANY standards.

I do not work for a company with HL7-based solutions. My vested interest and/or personal mission is to lower the bar for developers, reduce complexity, and increase market competition. I believe this is the best thing for me and my family as a patient and for the American taxpayer.

For this, I need to ask what else other than IP makes people avoid collaborating with, and helping to fix what is wrong in HL7?  If IP weren't an issue, would you work with someone like Grahame Grieve to help HL7 reduce its own complexity?  Or is it simple a need to compete with HL7?  I've been down both roads with SDOs, and I can tell you that I'd rather work with than against them when I can.

I've already shared my deepest, most personal and most selfish motive with Alan, here it is for the rest of you:

My doctor has a system that can produce a CCD today.  In a year or so, he'll have a system that can produce CCDA.  And it will be able to send it out via Direct, and through the NwHIN Exchange.  I want that data.  Personally. On my own computer.  Updated automatically after every visit.

If we don't use the standards that are mandated now, who will connect me to my doctor using those standards, and what will incent my doctor to use that technology?  That is what ABBI is supposed to about, connecting us to our data.  It's what I want for me and for my kids.  If it was CCR that he was going to have, and not CCDA, then I'd be a little bit upset about the standard being used, but still calling for it.  I'm not a Direct fan-boy by any stretch of the imagination.  But you better believe that if ABBI PUSH doesn't support Direct, I'm going to be hugely upset.  If ABBI doesn't support CCDA, I'm also going to be hugely upset.  Why?  Because doctors will have Direct, and ABBI should make it possible for Doctors to cc: me using it, with very little in-between.  Maybe even nothing.  Wouldn't that be awesome?

I sincerely believe we are on to something with this project.  I think content is mostly a distraction right now.  ABBI should support ANY content Alan, Grahame, myself, or anyone else can dream up.  All we should have to do, ever, is just Ask for it.

-- Keith

P.S. If you liked the short video in that last link the director's cut is a three minute ad for ABBI