Why vendors don’t implement CCOW in legacy systems

Wheelybop, A HIStalk reader, recently posed a question:

Can you or your blogger network describe to me what vendors have to do to make their legacy products CCOW compliant and why some refuse to do so, what are pros/cons, etc. Would love a CCOW primer or be pointed to such.

First, lets tackle the primer. The acronym CCOW stands for “Clinical Context Object Workgroup”, a reference to the standards committee within the HL7 group that developed the standard. CCOW is a standard designed to allow information sharing between clinical and health IT applications. It uses a basic technique called “context sharing” that allows multiple clinical applications to “switch contexts” simultaneously. A “context” is a computer science term that could mean a patient’s data screen or an encounter form. Multiple CCOW compliant applications can simultaneously change their screens to see the same patient’s data when any of the other participating applications do so. For example, if a hospital can get their labs, EMR, and CPOE vendors to become CCOW compliant they can share to share patient context instead of the user having to log in and out of each application separately.

Ok, that’s the intro. There’s more at CCOW vendor (like NeoTool, Sentillion, etc) websites you can read but the above is pretty much what you’ll get there as well.

Now, to answer the reader’s original question: why don’t legacy vendors support it? The simple answer is that CCOW provides no real value to them. Legacy vendors rarely benefit from migrating and supporting new standards, regardless of what it is. CCOW is good for new entrants into the health IT field — for example, if I’m a startup and I write a new app I would definitely want to be CCOW compliant because CIOs won’t like me unless I’m interoperable with their legacy systems. However, legacy vendors have neither the inclination nor the customer outcry necessary to become interoperable with new software. They are already in the customer’s shop and don’t need to support the new standard to make more sales. The larger you are, the more entreanched you are in your customers’ shops, the less you need to “play nice” with other vendors.

Of course, there are many benefits to becoming CCOW compliant. However, none of those benefits apply to the vendor itslef. The benefits are all for the user and for the IT shop that can help users streamline their work.

So, don’t expect CCOW compliance from the legacy vendors anytime soon. 🙂

Newsletter Sign Up


2 thoughts on “Why vendors don’t implement CCOW in legacy systems

  1. Regarding Sentillion: I have been doing consulting work with this firm for the past 18 months or so and while they did originally start as a “CCOW Vendor” they have mushroomed into much more. They used their original knowledge of CCOW to develop a robust set of products for healthcare companies to perform identity and access management functions (user authentication, single sign-on, automated user provisioning, single patient selection and more). Their original CCOW work has also lead to the development of an SDK to help companies CCOW-enable their apps. They also have developed a VERY cool wizard-like interface that allows their healthcare customers to develop simple software bridges that link non-CCOW apps into their single sign-on environment in a matter of minutes. (Thus the product name “BridgeBuilder”). This interface works extremely well for web-based and client-server apps where ‘username/password’ are what is required to sign on. For the old legacy “green screen” apps, Sentillion builds bridges for their clients using a scripting language. I don’t believe they’ve ever been confronted with a legacy app they can’t integrate with their stuff.

    I just didn’t want your readers to be left with the impression that Sentillion is just a “CCOW vendor”. They’re much much more than that today.

    /s

  2. Matt Hernandez

    Reply

    “I don’t believe they’ve ever been confronted with a legacy app they can’t integrate with their stuff.”

    You would have to have been with them longer than 18 months to make that statement. We had a lot of problems trying to integrate only 3 major vendor apps at our shop. There was 1 CCOW (Cerner) and Sentillion built 2 bridge products that never quite worked. Also its main desktop context manager was not reliable over wireless. A one second disconnect would hang the system and require a reboot.

    This was a couple of years ago. Hopefully the products are more robust now. It probably works great with CCOW apps, but don’t assume they’ll be able to bridge legacy apps. Every situation is unique.

Add Comment