The notion of interoperability as envisioned by all of us, is not interoperability inside one office. It is interoperability with other providers. That is where the value is. I really don’t quite understand where the idea of breaking EHRs into various sub-modules is coming from or what its purpose is. It’s not like there are hundreds of little apps like that floating around looking to break into the big, bad “monolithic” market.

BTW, I think it’s probably a good idea for a clinic to start using their EHR in phases. Starting with ePrescribe is always easier, particularly for large clinics.

Now to the standards, you are mixing and matching protocols, terminology and data specifications. There are three interoperability standards that are extremely well supported by everybody in the industry: HL7, X12, NCPDP, and CCR is gaining some traction as well.
CPT and ICD9 are supported by every single vendor.
As to internet protocols, HTTP, SFTP and others, you can’t really be in the software business without supporting those.
The other terminologies that you mention like SNOMED and LOINC are not really ready for prime time, but are being adopted nevertheless. I can tell you from recent personal experience that LOINC is not even close to being what it’s touted to be.

And, Mark, whatever my presumed motives are, I think CCHIT is a major distraction and even a barrier to what’s in the best interest of the customer and health care in general.

As to technology, first the existing “hodge-podge” array of applications and lack of integration is bemoaned, followed by a suggestion to adopt bits and pieces of technology.

Implementing plug-and-play pieces of functionality is never as simple as the very enticing term of plug-and-play, which really belongs to the hardware world. Having disparate registries and lab modules for example, begs the question of where does the data reside. Do we have multiple data stores across the disparate systems, each storing fragments of data? Do we have one master vendor with a master data store that the other (smaller) suppliers of plug-and-play extensions access? These extensions will be vendor specific.
As opposed to the iPhone or the iGoogle page, which are hosting completely disparate applications, EHRs are transactional applications that must combine information from all parts and pieces in order to offer a useful tool to the practice.
The term “platform” when it comes to software has very different meaning then when applied to iPhone firmware. In software it means something like salesforce.com or IBM Websphere portal. These are proprietary applications (not platforms) that allow users to write their own extensions and trade or sell them to other users of the same application. I’m pretty sure that this is not what you had in mind here.

Regarding dis-integration, the hardware industry cannot really be compared to the software industry in this way. Hardware is basically a manufacturing sector, where specialization brings production cost reductions. Even then, note that consumers are not buying motherboards and sound cards and putting together their computers. It takes a Dell to do that and the consumer still buys a complete product.

Software, on the other hand, is more like a service. No one buys software because they want to own a shiny disc and a big box. They want their accounting done or their word processing done, etc. Indeed the software industry is moving towards the service model, instead of the off the shelf box model. All the “cloud” and web 2.0 talk and all the SaaS companies mushrooming out there indicate just that. Software is moving from being a product to being a service.

So how about the service industry? Is it subject to the same dis-integration trend as manufacturing?
A few years ago, when you took the afternoon off to “run some errands”, you went by the bank, got some stamps at the post office, picked up some milk at the grocery store and maybe splurged on a new camera lens. You had to drive and stop at 4 different places to get all these services. Today it’s one stop.
Service companies benefit from consolidation, particularly if the services are very similar and can be performed by the same resources. This will drive prices down and provide convenience to the customer. Just imagine that you would need to hire one person to do your windows, another to wash floors, a third for bathrooms….

Software is the same. The resources required to write registry code are exactly the same that can write ePrescribe code. There is no need for a differentiated assembly/production line. Thus, a company that offers integrated services, can do so at much lower prices than a specialized vendor and with much less discomfort to the customer and with higher quality, since it has more resources to move around and much more opportunity and ability to innovate.

Now, should these integrated applications be able to communicate with each other, or be interoperable? Absolutely! I think that is where our focus should be and it is much easier to have the “cleaning service” as a whole coordinate schedules with the “home security” service, instead of having the window washer call, and the floor washer call with a different time, and the bathroom person forget to call at all…….

Ideally, your e-prescribing application would be able to find your master patient index, your drug lists, your medication history, etc. Likewise for point of care decision applications. This can be done with interoperability standards but not with current models of the EHR which are ‘integrated’ systems. There is a big difference between integrated systems and interoperable systems.

Unfortunately, CCHIT certification is focused on integrated monolithic systems, not interoperable components. CCHIT needs to adopt an interoperable component approach to certification or it will only impede adoption of HIT.