Simplification

My how times change.  In 2005, the largest problem facing healthcare IT interoperability in the US was the harmonization of standards.  ANSI/HITSP was formed in October of 2005 with the goal of addressing this particular issue.  It is now four years (and a month) since HITSP was created, and we no longer talk about the "Harmonization" problem.  The problem facing us now is the "Simplification" of standards.  I'm glad to see that we are moving onto the next problem, but hope that in so doing, we don't "unsolve" the previous one.

HITSP's great success in achieving its contract objectives goes largely unnoticed in this new phase because its objectives no longer address the most pressing issue.  I've heard several complaints about how the HITSP specifications are too complex, long and not directive enough for implementors.  These are valid complaints if you are trying to use these specifications as "implementation guides".  They were designed to specify enough to address the harmonized use of standards.  Iimplementation guides are much more than that.  Many of us involved in HITSP have argued that we need to find a better way to communicate.  However, the development of implementation guides requires a great deal more resources that were made available to HITSP under the ONC contract for harmonization, and the scope of the harmonization contract did not include that requirement.

To put this all into perspective, I did a little bit of research into what we (US taxpayers) are paying for with respect to implementation guides for healthcare standards.  See http://www.fedspending.org/ for one place where you can dig up some of this data for yourself. My own survey was anything but scientific, but based on my findings, I will assert that a 50-100 page implementation guide seems to cover from 2 - 4 transactions, and costs anywhere from $175,000 to $350,000 dollars to develop.  It is usally done in anywhere from 6 - 15 months.  The costs don't seem to scale up linearly with complexity either, twice as much complexity results in more than twice the cost.

So, how do we move forward from here?  The next step needs to be forward, towards simplification and education, yet not reject the harmonization that we just spend four+ years and spent tens of millions of dollars of both public and private funds addressing.

There are some concrete actions that we can take:

1. Make simplification of standards an important topic for SDOs and profiling organizations to address.
   The ebXML Reference information model and the HL7 RIM are great information models (of meaning), but what we are hearing from the "Internet" crowd is that we need to be closer to how the information modeled for use (see my ramblings on Synthensis). So, how can we simply go from meaning to use and back again?
   
   
2. Develop tools to make simplification easier (tool development is cheaper in the long run than just throwing more labor at the problem).
   The HL7 Templates workgroup is in the process of starting a project to build a templates registry.  Imaging having an information resource that would pull together all the templates that you need to implement a HITSP construct in one place.  One could readily use that resource to more quicky develop complete implementation guides that wouldn't have some of the challenges that our current HITSP specifications face.
   
3. Move away from linear documents for specifications. 
   We are dealing with the information age, it's about time we moved away from linear documents, and the constraints that they place upon us.  Developers want richly linked media to help them find what they are looking for.  The HL7 V3 Ballot site is an overdone example of what I'm talking about, but it is surely better than a 100 page document to deliver the necessary content.  One of the biggest challenges that HITSP faces is how to take the content that we have now in documents and make it something that would allow us to put together a real implementation guide.
   
4. Figure out how to move away from single-SDO based interchange and vocabulary models
   One thing that the world wide web and XML have taught us is the power of structured information that can be easily transformed.  We have 5-6 different key standards for communication in healthcare, only two of which are in XML.  We have some 7-9 different key vocabularies, with very similar high level models, yet no common terminilogy interchange format.  Can we provide common model across the space of healthcare for both interchange and terminilogy standards. 
   

These are real and concrete steps that will move us in the right direction. Let's not revisit discussions we had 4 years ago, they were far from simple then, and they would be even more complicated now.