Interoperability in the Real World....

Over the past year, I have come to understand and appreciate the value, the importance, and the necessity of tooling in achieving health interoperability objectives. On the one hand, many would suggest that this is obvious, for we cannot build systems and deploy solutions without tools. On the other hand, I would suggest that this is profound. Here's why.

The Real World.
When I speak to folks that are working in the trenches -- the ones that have production systems that are in use and deployed, and are struggling with what new parts to buy, how to choose, and how to make those bits work with what they already have -- it becomes clear that it is all about the tooling. We can discuss the value of standards, which most would agree are good things. We identify target technologies which are the future and hold tremendous promise. We even talk about integration strategies -- the ones that will minimize impacts to the organizations while maximizing value and ROI.

I am coming to realize, though, that the above isn't the real world. [Just to be clear, I'm not denegrading any of the above, and will get into the case for these things momentarily]. What I mean by that is that those of us who need to make IT work in the real world can only do so with pieces that exist. Architecture is important. Strategic direction is important. Standards are important. Having a migration plan is important. Sequencing is important. Ultimately, a whole lot of things are important, but if you cannot touch it, feel it, use it, and deploy it, it isn't real

Standards in the Real World
Standards that go unused are un-useful. Those of you who know me know that I am passionate about standards and their incredible importance in helping Health IT achieve its promise to healthcare organizations the world over. That said, one of the core tenets behind good and useful standards work is the drive to have those standards implemented.

There has been a lot of really good standards work to emerge over the past few years in the Health IT space. One of the challenges that I believe the industry as a whole is facing is that of adoption. The vendors with whom I speak follow standards very closely, but ultimately they must make hard business decisions in terms of where to invest their product development budget, and standards are not always the top of the list. Why not? Us!

As consumers, the responsibility is ours to demand of our suppliers those things that we want and care about. If we say standards are important but continue to make purchasing decisions absent any consideration of which and what standards are supported, the fault is our own. Vendors will provide what the marketplace demands. How does this affect the users, the integrators, and the folks in the trenches? Here's how.

When we pick a new, sexy product that has the bells-and-whistles but not the core architecture, the standards, the interoperability "baked in", the onus falls on the poor systems administrator to make the things fit. The result are internal teams that are asked to perform heroic "one-offs" to glue two things together that were never intended to fit. The integration is brittle, inconsistent, and expensive. Matters are even worse when you consider maintenance releases.

So what about the vendors? Why not just make those investments themselves as a competitive advantage. Well, two reasons surface very quickly. First, if purchasers are not incenting their decisions based upon these factors, then it is pretty reasonable to assume that the competitive advantage is not there. Secondly, infrastructure is expensive. VERY expensive. To get these bits right takes a huge investment of time, cost, resources. There are definitely paybacks (such as improved time-to-market and improved ability to fit into a customer environment), but making the business case for those investments can be very problemmatic.

Moreover, infrastructure has a sustainment cost, particularly as core technologies continue to evolve and as new players enter the market. To many vendors, the business case simply isn't there (or hasn't been effectively made) to invest in the newer standards.

Enter Open Source Software
After a tremendous amount of mentoring and hand-holding over the past year or two (special thanks to Skip McGaughey for getting me straight), I have come to understand that open source software can play an instrumental role in filling this void. How? Open source software provides a platform and a cooperation allowing for this expensive infrastructure to be built via co-investment, where all the players with the need share the burden (and the spoils). The end result is an infrastructure that can support the standards the community cares about, source code that vendors can use (for free!), and most importantly, an engagement model allowing allies and competitors to collaborate on the common bits on which they are not competing.

For example, through open source, HL7 tooling is already available (with more coming soon) that can be picked up and used with no IP [intellectual property] encumbrances. It can be used for free. It can be extended for free. It can be made for-profit without patent violation. Vendors can use it. Hospital systems can use it.

When most folks think "open source", software like Linux comes to mind, or licensing such as GNU, which are not commercially friendly. The key to success in our industry is to marry the commercial and free worlds, allowing vendors to share investments but also allowing them to make a living. Caveat emptor. The code is there to use, however it adds value.

Why do we care? As consumers, we want these standards. We need our systems to interoperate. What better way to get vendors on board than to contribute to a core that the vendors can then use. They can contribute to. Contribution doesn't necessarily mean money. It may mean time -- the time of the poor guy or gal that is glueing systems together today -- only allowing that investment to solve multiple challenges instead of just the problem-du-jour.

So, what do we do?
My recommendation is that there are a few steps that organizations should consider as they embark upon major HIT initiatives:

1) Create a roadmap. You can't get to your target objective without having a sense for where that is. While the 3-5 year vision is not attainable today, there needs to be a path to get there. That path must be paved with tools and technologies that exist, particularly for those objectives you hope to achieve in the next 18 months. Either you're using something that is out there or you're building it yourself.

2) Change your purchasing behavior. If there are no ties between your purse-strings and your plan, you have no hope of incenting the marketplace to meet your needs. While no one organization can do this on its own, collaborating withing the community to drive change is viable and achievable.

3) Engage in Standards. It is really easy to take a back seat and bash the standards for not being useful, and not meeting your needs. It is far harder to be part of the solution. The hidden secret is that the way to influence standards is to show up, and a few committed people can move mountains, particularly when they are trying to achieve a real, tangible objective.

4) Consider Open Source. Open source software is not the be-all, end-all, but there are organizations (such as Open Health Tools) that have the structure to allow for community engagement and vendor participation. These efforts will create shared health IT assets that are real, that can be used, that can be implemented, and that can be deployed.

Until next time...

- Ken