If it ain't broke, don't fix it

A very long time ago, during the start of my software development carear, I had two quotes from my boss written on the chalkboard in my office at the University.

“	Two rules of software development Just get it to work If it ain't broke, don't fix it.

These became a sort of test for people walking into my office.  If they looked at these two statements and questioned the implications of them on the software generated in that office, they passed. More than 70% of the cost of software is not in the development of it, rather, it is in the maintenance and support of it.  Applying these two rules might get it done quick, but won't result in something that you (or I for that matter) want to maintain.

In the realm of laboratory ordering and reporting, we are in a situation that is the result of applying these two rules.  We have numerous laboratory order and reporting interfaces installed across the country that "work", and since they aren't "broken", there are concerns that we shouldn't be spending a great deal of time fixing them.  This results in debates in the HIT Standards and Policy committees over the need to specify standards now or later, or allow early adopters a "buy" for the first round.

The question is whether you want to drive a more expensive vehicle that is reliable, or if you just want a clunker that spends a good bit of time in the body shop. The just get it to work attitude results in driving around a lot of lemons that have high maintenance costs, but the other approach is expensive in the short term. And if you've already got a lemon that's running, you may not be ready to purchase that new car just yet.  It might require some planning and adjustment, but when that lemon dies, you should be ready to get something that will last.

My thoughts in this are fairly straightforward. 
1.  If it ain't broke, don't fix it. 
2.  When it does break, fix it right, or get a new one that won't break like that again.

The same principle was applied to Federal Health IT infrastructure under the Bush administration via Executive Order 13410, and should be applied to laboratory standards for meaningful use.  In essence it says that new, upgraded or newly developed HIT, use the recognized standards.  Basically, if it isn't being replaced, don't change it.  I know, telling this adminstration to pay attention to what the last one did probably won't fly, even if it was a good idea.  So, instead, look to what section 13111 of ARRA has to say about federal spending on HIT.  What's good for the gander in this case, should be good for the rest of the geese.

If a provider has a working electronic laboratory interface, let it count for the first two years, but ensure that they are planning to update it to support the required standards by 2013.  That will avoid unnecessary expenditures on fixing what "isn't broken", but it will also indicate that we are serious about the use of standards.  It won't leave early adopters out in the cold over what is needed for laboratory interfaces.

Laboratory results are very important in quality measures and clinical decision support.  Avoiding standardization of the laboratory results interface will delay other factors of meaningful use that aren't being debated.  So, it's important to push for standardization and make it clear that we will move forward.

One of the key features of CDA that makes it so implementable is "incremental interoperability".  Let's use that principle for laboratory interfaces as well.