Nine Keys to Fearless Interoperability
Data Exchange — from Liability to Asset

Interoperability can be defined as, “the ability of different information technology systems and software applications to communicate, exchange data, and use the information that has been exchanged.” In my line of business, functional interoperability is key to providing quality healthcare, but the same principles below could be applied to any market where the exchange of data is required. I decided to move away from patient care fifteen years ago and have dedicated a good portion of my life toward this pursuit; I enjoy what I do and take this seriously. Below are some of the lessons I have learned over the years.
Interoperability in healthcare is often considered a liability. New companies offering innovative solutions and even long-standing, experienced companies in this space often struggle to grapple correctly with the complexity. Almost every solution out there needs both incoming and outgoing data and yet these tasks are often relegated to the groups that are not fully equipt and less than thrilled to do the work. Product Management often does not want the overhead and has to pull technical experts into their groups to maintain it. Engineering usually does not have the market expertise and struggles with data context. If you give it all to Implementation you will end up with custom code for every install, which is expensive to support and maintain.
How can you turn this liability into an asset?
Here are Nine Keys to Fearless Interoperability.
1. Interoperability is Strategic
When I started one of my more recent adventures, one of the business goals was combining five newly acquired companies together, each with different best-in-class capabilities. We were looking to capture a piece of the market amidst the excitement associated with a large regulatory change. The changes in the market promised significant resource drain and increased cost to our existing and potential customers. We had a set of fantastic products and the pace was frantic — we needed a solid game plan.
I was tasked with creating a sustainable interoperability model to bring these solutions to market as we were aggressively combining technology at the user experience level and consolidating architecture behind the scenes. The first thing to do was to get a handle on the value of quality interoperability. So, like any good entrepreneur, I spun up a business plan. Figure 1 is part the scorecard that was created.
We were able to make the case that quality interoperability increases revenue and productivity, leading to increased profit. We focused on building a team directed toward these “Internal” and “Learning” areas, setting clear objectives, metrics, and created initiatives to meet goals in each area. The “Customer” section was tackled by working closely with our Product Management team.
2. Define and Live Your Culture
Vision: “We create a culture that enables the meaningful exchange of data.”
Note that the vision we created was about creating and enabling a meaningful change. It’s not a directive towards making money or improving technology. While they certainly are goals under the mission and vision, you can’t create a movement around them.
When thinking through business problems and discussing them with prospects and customers, consider the strength of your data exchange as an asset that will improve an offering versus a liability that has to be overcome to realize the core value. The market will feel the difference and your company will rise to the task.
3. Interoperability is a Product
Nothing is more exasperating to leadership than when something goes wrong and everyone in the boardroom points to someone else. I cannot stress this enough, make interoperability its own vertical with one strategic owner. That leader should organize like a product offering, with ties into infrastructure, engineering (both in and out of specific product lines), implementation, support, and each product leader in the organization. Interoperability is not a top-down endeavor, it is a network of relationships as well as technology — find someone who can build these bridges, foster involvement in standards organizations, and keep the team up to date.
Internal interoperability should be as critical to the organization as customer-facing data interfaces. The same level of effort on standards, reproducibility, governance, etc. If you do it wrong, customers won’t differentiate and will only see that the technology you offer, “does not work.” Don’t be the company with solid customer-facing specifications and a slop of “still draft” internal documents for those critical intra-company interfaces.
Implementation teams are not software development teams. Draw the lines around where the external delivery of interoperability (implementation) meets product-level engineering. Don’t mess this up. Any programming code that is involved with writing to product data tables needs to be handled by product management, engineering-created schemata should align with the standards created by an interop committee (see below) and there should be communication throughout all products’ lifecycles, from approval of integration-related enhancements, grooming, and release coordination (including release note drafting). The more complicated the interoperability feature, the more tightly the business coupling.
4. Standards Require Cross-team Review
One thing that really helps make quality standards that evolve with each release of software is the organization of cross-functional committees for review and approval of changes. This includes representatives from product, support (all tiers), engineering (both product and integration), production control, and implementation. Only with this group can you be assured that you don’t break anything for customers when changing the standards. The largest of these committees in our company is our HL7 Committee and it meets weekly, chaired by our HL7 strategist.
5. Build Vendor Relationships, Maintain a Library
One of the questions that always comes up during the sales cycle is, “How does your solution work with my existing systems?” What a healthcare customer is really asking is, “I just paid half a billion dollars for this EMR system last year and we have been square-peg-round-holing till our hands bleed, does your stuff work with what I bought?” This usually results in a call where the sales team pulls in a technology expert — the sales rep usually afraid of what someone junior from implementation might say that will sabotage the deal.
The key to move this experience from a liability to an asset is to be prepared.
First, be curious. When you run into a vendor you have not integrated with before, especially pre-sale, give them a call, fill out an online form, email support@{thevendor}.com, and get to know them. Relay the fact that you would love to talk about a potential mutual customer and align the story of how the systems will work together before you two get into a triangularly challenging phone call (which will happen at some point). Customers will REALLY appreciate this, the other vendor as well, and you reduce the risk to your business.
Second, create detailed documentation on how your systems interoperate with any vendor you have connected with successfully, and keep it up to date. The sales rep will love the formality and can send the documents along to prospects for review. The customers will appreciate that your company understands the importance of leveraging their other investments.
6. Enforce Standards During the Contracting Process
This is not an easy one. If you have not taken the time to think through why your customer (who usually hold the final source of truth data) should be responsible for data transformation, take the time to get your pitch down. Now, read that last sentence again. The only way to scale your business without significant sustainability overhead is to have your customers do this work. If any data changes are required to their many systems that feed yours (upgrades, etc.), the customer should have the capability to make their feeds compliant with your standards without bringing a large team in from your organization to do custom code rework. While they may grumble about the upfront cost, in the long run it will save both organizations time and money.
7. Delivery Assurance
Before any deal gets signed, the operational team must understand the scope and effort and be involved in the pricing for professional services. Period. Not doing so puts your business at risk; a bad implementation, regardless of the strategic nature or total contract value, can damage the reputation of your company. There will be resistance — educate sales leadership on why the market perception of the company’s ability to execute is key to reducing the friction for future deals.
Create a small team that focuses on the work to define standard processes for communicating standards, capturing information for scope and pricing, and delivering the right scope-of-services contract language to protect your organization.
8. Reproducibility and… Reproducibility
Once you land a contract, providing simple and fast delivery is key. Creating interoperability models with strong, enforced standards backed by solid technology will enable successful implementation because at the point data enters your technology it will look the same across your customer base.
If you expend more resources on interfaces after they are up and running than on the initial build and implementation, then you may have a problem with reproducibility. Look carefully at the standards vs flexibility balance that you have built and create tools around this to lower the costs. If you have done everything recommended above, then the implementations should not be impeded with custom code and should all feel close to the same from a data exchange perspective, with standards being met by the customer.
9. Interoperability Can be Thankless, and That’s OK
We in the interoperability space are often unseen. We are considered the “plumbers” of healthcare. If we do everything right, data gets where it needs to, when it needs to, with the right context, in the fight format — then we go unnoticed. Even with the years of education to leaders, product, sales, and others, we are often only called-out is when something goes wrong. We are often missed in strategic meeting invites and then when data exchange failures occur they wonder why. When the pipes break the occupants run around, arms flailing, screaming.
A thousand good deeds go unremembered, but that one time you fat-fingered the IP address from the test to the production domain…? They will use it to roast you at your retirement party.
We who work interoperability may never have our day in the sun, but if we focus on the fundamentals outlined above we can make a positive impact to the companies we serve. *salute*
Please feel free to let me know what you think and what has worked for you.
This article is my personal opinion and not my employer’s.
