Monthly Archive for August, 2008

There’s a lively discussion on HIStalk (Readers Write 8/27/08) regarding the merits of CCHIT. The Jim Tate piece isn’t long, or even that informative. It simply touts CCHIT as an

.. organization that is helping level the playing field and make it safer for clinicians to take the plunge into electronic records.

This seems innocuous enough. Judging by the negative responses though, some people have real problems with CCHIT. In particular, the Al Borges, MD Response to “CCHIT: the 800-Pound Gorilla” is a detailed point-by-point rebuttal (“CCHIT is simply not necessary.”).

I guess it’s not surprising that the biggest issue seems to revolve around money. The cost of obtaining CCHIT certification has stratified EMR companies (big vs. small) and makes it even more difficult for practices to see a ROI.

Are lab standards an issue one of the various work groups is addressing? Are the labs on board?

When you say “lab” what you’re really talking about are the large number of medical devices commonly found in both hospitals and private practice offices. As you note, the need for interfaces to these devices is so the data they generate can be associated with the proper patient record in the EMR. This not only allows a physician to have a more complete picture of the patients’ status, but the efficiency of the entire clinical staff is vastly improved when they don’t have to gather all of this information from multiple sources.

The answer to your second question is yes, many “labs” — medical device companies, are actively in involved in the development of interoperability standards. The EMR companies are also major participants.

There are two fundamental problems with “standards” though:

A standard is always a compromise.

A standard is always evolving.

By their very design, the use of a standard will require the implementer to jump though at least a few hoops (some of which may be on fire). Also, a device-to-EMR interface you complete today will probably not work for the same device and EMR in a year from now — one or both will be implementing the next generation standard by then.

Nobody dislikes standards. Interoperability is usually good for business. There are two primary reasons why a company might not embrace communications standards:

The compromise may be too costly, either from a performance or resources point of view, so a company will just do it their own way.

You build a proprietary system in order to explicitly lock out other players. This is a tactic used by large companies that provide end-to-end systems.

The “standards” problem is not just a Healthcare interoperability issue. The IT within every industry struggles with this. The complexity of Healthcare IT and its multi-faceted evolutionary path has just exacerbated the situation.

So, the answer is that everyone is working very hard to resolve these tough interoperability issues. Unfortunately, the nature of beast is such that it’s going to take a long time for the solutions to become satisfactory.

A post today by Jeremy Miller has a (late) Tribute to George Carlin which lists words and phrases that should not be used when discussing software development. I don’t think the list was meant to be comprehensive but it’s a good read anyway. One of them does a good job of backing up my contention that analogies are evil:

“Software as Construction” – … I feel perfectly qualified to say that the “Software as Construction” analogy is an extremely poor fit.

It’s good to see that Mort is also on the list, and the first one too! That one really struck a nerve for me when I first heard it last year, so it should be at the top.

I’m not so sure about the “refactoring” items. Bad design and refactoring are two different things. Code duplication is bad design and should never be tolerated. But adding unneeded (and worse, untested) complexity for the sake of generality alone isn’t a smart use of resources either. I think the term “refactoring” has essentially become synonymous with “rewriting” anyway — nobody’s fooled by that jargon any more.

Is a picture of a computer program really worth a 1000 words? HP seems to think so.
Making Sense of Spaghetti Code discusses the visual representation of source code as a marketing tool for their consulting services. Being from California, the budget cutting complaint:

because there aren’t enough programmers who know the Cobol language used in the state’s payroll software

is pretty scary. The urban (programming) myth that there are still more lines of Cobol in use than any other language may actually be true. Scarier still!

The Health Guide stores and displays the collected information on a touch screen and sends to a secure host server, where health care professionals can review the information. Patients using the Health Guide can monitor their health status, communicate with care teams and learn about their medical conditions.

There are many health conditions that would benefit from improved remote monitoring capabilities, but heart disease is certainly at the top of the list and has been shown to reduce hospital re-admissions. Holter monitoring has been around for a long time, but this type of embedded ECG hardware and software technology along with interactive devices like the Intel Health Guide, could significantly raise the bar for ambulatory patient heart monitoring. Companies like CardioNet are already counting on this trend.
It’s a good bet that PHR providers like Google Health and Microsoft HealthVault will start to incorporate similar interactive technologies into their offerings. Also, Microsoft offers a device certification program that will draw in more devices. Google has similar developer and branding policies in place (see here).