Every health IT procurement decision is also a standards decision. Whether you realise it or not, the vendor you choose today determines how easily you can exchange data, switch systems, or integrate new tools for the next decade. Health CIOs who don't make open standards a procurement requirement are making a decision they'll regret.
What You Need to Know
- Open standards (HL7 FHIR, SNOMED CT, openEHR) enable health systems to exchange data without custom integrations. They reduce vendor lock-in and lower long-term costs.
- Most NZ health IT vendors claim standards compliance. Few deliver it in practice. The gap between "supports FHIR" and "actually interoperable via FHIR" is significant.
- CIOs have leverage in procurement. Requiring open standards as a contractual condition, not a roadmap aspiration, shifts the vendor relationship in the organisation's favour.
- The cost of not demanding open standards is invisible until you need to integrate, migrate, or replace a system. Then it's catastrophic.
The Vendor Lock-In Tax
I've seen organisations pay the lock-in tax multiple times. The cost isn't visible in the annual licence fee. It shows up when you try to do something new.
You want to integrate a lab results feed from a new provider. Your patient management system doesn't support the standard format. The vendor quotes six months and a custom integration fee.
You want to migrate to a newer platform. Your data is stored in a proprietary schema. The export function produces a format that no other system can natively import. Migration requires a specialist consultant and a year-long project.
$4.3M
average cost of a health IT system migration for a mid-size NZ health organisation
Source: NZIER, Health IT Investment Analysis, 2021
You want to connect a community health programme's data with your primary care system. Both systems claim to support HL7. But they've implemented different versions, with different extensions, and the data doesn't map cleanly. Another custom integration.
Each of these costs was avoidable. If open standards had been a procurement requirement from the start, the systems would exchange data natively. Migrations would be structured exports and imports. Integrations would be configuration, not development.
What Open Standards Actually Mean
Open standards in health IT aren't one thing. They're a family of specifications covering different aspects of health data.
HL7 FHIR (Fast Healthcare Interoperability Resources) defines how health data is structured and exchanged between systems. It's the closest thing to a universal language for health IT. When a system genuinely supports FHIR, it can send and receive clinical data - patient demographics, observations, medications, referrals - in a format any other FHIR-compliant system can read.
SNOMED CT is a clinical terminology standard. It provides a consistent way to code clinical concepts so that "type 2 diabetes" means the same thing across every system that uses it. Without terminology standards, the same condition can be coded ten different ways across ten different systems.
openEHR takes a different approach, separating the clinical data model from the technical implementation. It allows clinical experts to define what data should be captured without being constrained by how a particular vendor has built their database.
These standards exist. They're mature. They work. The question is whether vendors implement them properly and whether health organisations require them.
How to Make This Work in Procurement
The CIO's most powerful tool for driving open standards is the procurement process. Vendors respond to what buyers require. If open standards are optional, they'll remain on the roadmap indefinitely. If they're contractual, they get built.
Vendors will tell you open standards are on the roadmap. Put them in the contract. If they can't commit to a date and a test, the roadmap is a marketing document.
Rikimata Massey
Health CIO Advisory
Here's what I'd recommend health CIOs include in every health IT procurement.
Require FHIR R4 compliance with specific use cases. Don't accept "we support FHIR" as a statement. Define the data exchanges you need - patient demographics, clinical documents, lab results, referrals - and require the vendor to demonstrate them in a test environment before contract signing.
Require data portability. The contract should specify that all data stored in the system can be exported in a standard format (FHIR bundles, CDA documents) at any time, with no additional cost. If the vendor charges for data export, your data isn't really yours.
Require terminology standards. Clinical data should be coded using SNOMED CT or an equivalent international standard. Proprietary coding systems create translation problems that compound over time.
73%
of health IT vendor contracts in NZ do not include specific interoperability requirements
Source: NZ Health IT Cluster, Vendor Contract Survey, 2022
Include interoperability testing in acceptance criteria. Before you accept the system, test that it actually exchanges data with the other systems in your environment. Not in a demo. In your production environment, with your data, against your existing integrations.
The Long View
Open standards aren't about today's problem. They're about keeping your options open for the next decade.
Health IT is changing. New tools, new platforms, new capabilities arrive constantly. The organisations that will adopt them efficiently are the ones whose existing systems can connect to new ones without custom development. The organisations trapped in proprietary ecosystems will watch from the sidelines, paying integration taxes for every innovation.
The CIO's job is to make technology decisions that serve the organisation over time, not just at the point of purchase. Demanding open standards is the single most impactful thing a health CIO can do for their organisation's long-term flexibility.