Picture a small group of clinics. Appointments live in one program, lab results arrive as PDF attachments by email, invoices are prepared in a third tool, and patients get reminders from a fourth. Every morning someone on the front desk copies a name, a date of birth and a phone number from one screen into another. Nobody planned it that way. It simply grew, one sensible purchase at a time.
If that sounds familiar, you have met the interoperability problem. It has a technical name, but the cost is very human: retyping, mistakes, and staff time spent being the cable between two programs.
Why healthcare systems don't talk to each other
Most systems were built by different companies, at different times, for different jobs. Each one stores a patient in its own way, with its own field names, its own formats and its own idea of what an "appointment" contains. Two programs can both be perfectly good and still have no shared language.
The usual fix is a custom connection between each pair of systems. It works, until one side changes something. Then the connection breaks, usually on a busy Monday, and nobody remembers who built it.
What HL7 and FHIR are, without the jargon
HL7 is an organisation that publishes standards for exchanging health information. FHIR, short for Fast Healthcare Interoperability Resources, is one of its standards. HL7's own site describes it as a standard for health care data exchange.
The key idea is the word "resources". In FHIR, everything that can be exchanged is defined as a resource: a patient, for example, has an agreed definition that covers basic administrative information about an individual receiving care. If two systems agree on what a "Patient" looks like, they need far less private translation for every pair.
Think of it as a shared form that both sides agree to fill in the same way.
What "we have a FHIR API" means for you
An API is a doorway that lets one program talk to another without a person in between. FHIR's RESTful API describes a standard set of operations for that doorway on its resources: read one record, search for records that match some criteria, create a new one, update an existing one.
In plain terms, a system with a FHIR API can answer a question such as "find this patient" in a way that another FHIR-capable program already understands, instead of you paying for a one-off translation.
Two honest caveats. First, a FHIR API does not mean everything is connected. HL7's own documentation notes that each server declares which interactions it supports, so one product may only let you read data while another also lets you write it. Second, the standard has numbered releases, so "supports FHIR" is an incomplete statement until you know which one and for which data.
What a custom system does about it
A well-built custom system does not need to bend its whole design around a standard. A sensible approach is the opposite: keep an internal model that fits how your practice works, and add a translation layer at the edge. That layer converts your data to and from a standard format when you need to exchange it with a lab, a hospital or another provider's system.
The benefit is that the rest of your software is not tied to someone else's format. When a partner moves to a different release or a different format, you change one layer, not the whole system.
It also means you decide what leaves the building. The layer can be set to share only what a given partner needs, with a record of who asked for what. For health data that is not a nicety.
I'd also be careful not to promise more than the standard does. Whether a particular lab, insurer or authority in your country can or must exchange data through FHIR depends on local rules and on that organisation's own systems. Ask them. Don't assume.
Questions to ask a vendor or developer
You don't need to understand the specification to ask good questions:
- Which FHIR release do you support, and which kinds of records (patients, appointments, results...)?
- Can I only read data through it, or also add and change data?
- Who can use the connection, and how is access controlled and logged?
- Is there a test environment where we can try a connection with fake patients first?
- What happens when a message fails: do we hear about it, or does it disappear?
- Who maintains the connection when either side upgrades, and what does that cost?
- If we leave you, can we still get all of our data out in a usable format?
Vague answers to these questions tell you more than any brochure.
Start with the retyping
You don't need an interoperability strategy to begin. For one week, note every moment someone copies information from one program into another: a result, a referral, a patient's details. Count how often it happens and how long it takes.
That list is your real requirement. Usually two or three of those handoffs account for most of the pain, and they are the ones to connect first, in the simplest way that is safe and stays maintainable.