Hospitals are built to last decades. They are designed to accommodate changing populations, evolving models of care, new medical equipment and technologies that haven't even been invented yet. We would never expect a hospital building to become obsolete simply because the equipment inside it changes. So why do we accept that risk with the technology running it?
I've heard the conversation more times than I can count: a hospital is considering a new electronic health record (EHR), and someone points out that a neighbouring hospital, or another organization they work closely with, uses a particular platform. Choosing the same system would make information sharing easier.
There are legitimate reasons to consider the same system. Standardization can simplify workflows, reduce integration costs, make staff training easier and create efficiencies when organizations share resources. There is real value in consistency, particularly across networks of hospitals.
The problem is when we mistake that convenience for lasting interoperability. What happens when the hospital down the road changes its mind?
Five years from now, that hospital might replace its EHR. Suddenly, the two organizations are back to figuring out how to connect different systems. The very thing that made the original decision attractive has disappeared.
Why should a hospital's ability to exchange information depend on another organization's choice of software?
We should expect more from the technology we invest in. Systems should be able to communicate across vendors, adapt as organizations evolve and allow hospitals to change platforms without losing the connections they depend on.
Interoperability should outlast the technology choices organizations make today. Otherwise, every technology update risks starting the same cycle all over again.
The real test comes when you try to leave
Through my work in healthcare technology and data migration, I've seen firsthand how different a successful demonstration can be from actually moving years of accumulated information into another system.
On paper, a system can appear to tick all the right boxes. It has an export function. It offers APIs. It supports FHIR. But these are capabilities, not proof that information can move between systems easily, completely or without losing its meaning.
There is an important distinction here: moving data is not the same as making it usable.
Data must be harmonized and validated, with clinical terminology, relationships and context preserved so information remains meaningful in the receiving system.
An interface can be technically successful while the information it delivers is incomplete, inconsistent or clinically misleading. Information that cannot be trusted or interpreted correctly is not much more useful than information that never arrived at all.
Then there are the practical questions. Can the organization retrieve everything in bulk? Are there additional fees? Can an independent third party access the information, or does the original vendor control the process?
A system that lets you put data in but makes it difficult to get data out is not an open system.
The cost of a system isn't just what you pay to buy it. It's what it costs to operate, connect, maintain and, eventually, leave it.
That is why interoperability cannot be treated as just another technical feature. It is a question of data ownership, operational resilience and long-term purchasing risk.
Stop buying the green checkmark
If you ask a vendor whether its system supports interoperability, the answer will almost certainly be yes.
But a green checkmark beside "FHIR compliant" tells a buyer very little about what the system can actually do.
Which resources are supported? Which version and implementation guide? Has it been independently tested? Can another system use that information without extensive custom development?
FHIR support is a starting point, not a certificate of interoperability.
Healthcare buyers need evidence, not assurances: representative data exports, independent validation, demonstrated Canadian implementation requirements and clear contractual rights to API access and data portability.
What data can be retrieved? In which formats? At what cost and within what timeframe? These shouldn't be questions an organization has to negotiate after it has already decided to leave. Data portability should be tested throughout the contract, not simply assumed at implementation.
A successful migration should be a technical exercise, not a hostage negotiation.
Control doesn't end with the EHR
The question of who controls healthcare data becomes even more important as organizations adopt more cloud services, analytics platforms and AI tools.
Information moves between systems, platforms and service providers, often crossing organizational and jurisdictional boundaries. Every new connection creates questions about who can access that information, where it is processed and how it can be used.
Can a cloud provider or subcontractor access it? Which jurisdictions apply? Can patient information be used to train or improve AI models? What happens to that information when a service agreement ends?
Data sovereignty is not a pin on a map. It's control over what happens to your information.
Keeping data in Canada is important, but location alone does not establish control. Healthcare organizations need to understand and define their rights around access, secondary use, AI training, data retrieval and deletion.
When systems fail to communicate, patients feel it
For healthcare facilities leaders, interoperability extends well beyond the EHR. Hospitals depend on diagnostic imaging, bedside monitoring, infusion pumps, medical devices and clinical applications. These systems all play a role in delivering care, and they need to work together.
When they cannot communicate reliably, the consequences can reach the bedside. Missing information, delayed results and disconnected clinical records can affect clinical decisions, continuity of care and patient safety. Time that should be spent caring for patients can be lost tracking down information, repeating processes or working around technology that doesn't connect.
Technology should help clinicians make better-informed decisions, give them access to the information they need and support safer, more coordinated care. It should not create another barrier between a patient and the people looking after them.
A hospital is built to last decades. Its technology decisions need to be made with the same horizon in mind, with patient safety and quality of care at the centre.
We need to change what we buy
Canada has already done important work to establish a foundation for interoperability. Standards and specifications, including PS-CA, Ca:FeX and CA Core+, provide a framework for more consistent health information exchange. We have spent years defining how healthcare data should move.
But standards don't change the market simply because they exist.
Hospitals and provincial health authorities have considerable purchasing power. If conformance, data portability and data sovereignty become meaningful procurement requirements, vendors have a commercial reason to deliver them.
We cannot build the future of healthcare around the technology we happen to buy today. We need systems that can evolve, organizations that remain free to choose, and information that keeps moving regardless of what comes next.