FHIR R4 or wait? A practical answer for programme managers

Programme managers ask me whether to build on HL7 FHIR R4 now or wait for the next release, and the question is a proxy for a different anxiety: that a standards decision made today will strand the programme tomorrow.

The short answer is build on R4. It is the version with production implementations, tooling, published implementation guides and people who have already made the mistakes. Waiting for a newer release buys refinements you will not use in year one and costs you a year of the work that actually determines success.

What actually strands programmes

Not the version. Three other things.

• Identity. If you cannot reliably decide that two records refer to the same person, every downstream promise of the exchange fails. Nigerian data makes this hard: name order and spelling vary between encounters, dates of birth are approximated, phone numbers are shared within households. You need a client registry, a deterministic-plus-probabilistic matching strategy, a manual review queue and a published tolerance for false matches — because a false match in clinical data is a safety event, not a data-quality issue.
• Terminology. Somebody must own the value sets, and "own" means a named team with a change process, not a spreadsheet from the design phase. Diagnoses, drugs, labs and facilities all drift. Unowned terminology is how a working exchange degrades into a pile of free text over two years.
• Governance. Who may query, on what basis, with what consent model, and who audits it. This is a policy artefact that must exist before the first production query, not after the first complaint.

Solve those three and a version migration is an engineering exercise. Skip them and no version saves you.

Profile narrowly, and write it down

The most common technical failure I see is treating FHIR as self-describing. Two systems can both be conformant and still fail to exchange anything useful, because the standard is permissive by design. Constrain it: publish an implementation guide with profiles, cardinality, required extensions and bound value sets, and validate against it in CI. If your programme cannot produce that document, it does not have an interoperability specification — it has an aspiration.

Sequencing that works

Start with two or three resources that carry real clinical value — typically Patient, Encounter and Observation — and get them flowing end to end between a small number of facilities. Resist the temptation to model the whole domain first. An exchange carrying three resources between ten facilities is worth more than a complete model carrying nothing, and it teaches you the operational problems while they are still cheap.

Then add resources in the order that the clinical use case demands, and let facility onboarding run continuously alongside rather than as a phase at the end.

The honest cost line

Standards work is perhaps a fifth of an exchange programme. The rest is onboarding facilities, cleaning data, training people, and answering the phone. Budget accordingly, and stop asking about versions.