The terms integration and interoperability are often used interchangeably, but they are very different creatures, and understanding the impact of an “integration strategy” versus an “interoperability strategy” can have a dramatic effect on your product and business.

Let's start with some definitions: 

Imagine that you are visiting an international conference with people from across the globe, and that everyone speaks a different language. How do you communicate with everybody? There are three basic options:

1. Everyone learns every single language spoken at the conference
2. Hire a translator for every language at the conference
3. Everyone learns ONE common language

Options 1 and 2 are “integrations”, where 1 is a direct integration (everyone learn everyone else’s language) and 2 integrates via “middleware” (i.e., the translator). These options require a custom translation to each participant. Furthermore, each additional participant adds another translation that everybody needs to handle. If 10 people know all 10 languages to speak to one another, what happens when ONE new person joins the group? That one new person now has to learn 10 new languages, or, the translator now needs to learn how to communicate that new language into the 10 other languages. At a certain point, no new person is going to want to join the group, because of how many languages they have to learn. When the number of systems add up, this process is timely, and costly.

If you only ever want a few people at your conference, “integration” will probably work just fine. But, if you want a lot of participants that all interact with each other, “interoperability” is the way to go.

Option 3 is “interoperability” - everybody learns the same ONE common language. The benefits of interoperability in this scenario are clear:

• You only need to learn ONE language, no matter how many people are at the conference
• When a new person arrives, they only need to learn ONE language, and no one else needs to learn anything new

When systems have interoperability, they communicate via a common language with no translation required. Phones, faxes, railroads, AM/FM radio, the web, and email are all examples of technological interoperability. In the world of email, the different products Outlook, Hotmail and Yahoo all use a common data format to transmit emails from one system to another. When Gmail was introduced, it did not add more complexity to the network - and the other systems did not need to do any extra work, because the email ecosystem was interoperable with any platform that used published public email protocols and standards. The interoperability of faxes has incredible value, as every single fax machine is built to communicate with every other fax machine. Despite the method’s shortcomings, fax still dominates the healthcare industry as the preferred method for information exchange because the size and value of the existing network is so big.

In healthcare, there will never be a world where all agencies use all the same software. Primary care clinicians have a unique workflow of client profiles; specialists have specific technology to display their laboratory test results; nursing homes have bed matching algorithms, and home and community care agencies manage transportation and meal delivery requests for a growing number of billable patients across pre-defined coverage areas. But, they all might need to send pieces of client data to one another in the form of referrals. This is becoming increasingly clear as we learn what shape Ontario Health Teams will take, as each partner agency brings their existing systems to the table.

We need a new digital network to enable referrals. For this new network to fully succeed in displacing fax, it needs to be as interoperable as the fax machine. Integrations won’t get us there. The first step towards this goal is - agree on the language. 

Fortunately, there is already a standard and flexible standard for health care data exchange, called HL7 FHIR. This standard provides the core building blocks needed to build a detailed interoperability specification (i.e., “language”) for a specific process such as eReferrals. Once this specification is defined and in use, any new system can simply “learn” this one language to easily join an entire network of eReferral enabled systems.

In Canada, the process of building this HL7 FHIR based specification has been ongoing, with participation from both government and industry. As various systems adopt this specification in full, true interoperability for healthcare referrals emerge from a dream into a reality.

If you are in the early stages of a digital healthcare referral strategy, choose interoperability over integration and ensure that all systems adhere to the FHIR standards, so you aren’t still faxing referrals like it’s 1999.