You are connecting a fifth hospital to the same interface and every one of the first four needed bespoke work. Why does that keep happening?

A standard constrains the structure and leaves the meaning open

The reason this keeps happening is not incompetence at the four hospitals and not a bad choice of standard. It is that healthcare interchange standards are deliberately permissive. They define a structure, name the fields, and then leave a large proportion of those fields optional, repeatable, or typed as a coded value whose code system is a local decision. Two systems can each be entirely conformant and still be unable to work together, because conformance is a statement about shape and interoperability is a statement about shared meaning.

HL7 v2 makes this explicit: most fields are optional, local extension is an accepted part of the standard through custom segments, and the same clinical fact can appear in more than one legitimate place depending on how the sending vendor read the specification. FHIR narrows the structure considerably but moves the same freedom into extensions and value-set binding, which is precisely why the ecosystem grew implementation guides and profiles as first-class artefacts. If your interface is specified as "we accept HL7" or "we are FHIR-based", you have specified almost nothing, and each new site pays for that in bespoke work.

The four things that are local, every time

Once you stop expecting the standard to do the work, the variation sorts itself into categories, and knowing them in advance is what turns a discovery exercise into a checklist.

Identifiers come first and cause the most damage. A patient identifier is only meaningful with the authority that issued it, and sites differ on which identifier they consider primary, whether a national identifier is present, whether it is verified, how they format it, and how they represent a temporary or unknown one. The same applies to clinician identifiers, department and location codes, and order numbers. Two sites sending the same numeric string that means different patients is not a hypothetical.

Code systems come second. A laboratory result is unusable without knowing what was measured, in what units, against what reference range, and whether the code is drawn from a recognised terminology such as LOINC or from a local dictionary that the sending laboratory's information system has accumulated over twenty years. Local codes are the norm, not the exception, and mapping them is clinical work rather than data work.

Third is the structure the site actually populates: fields you rely on left empty, information tucked into free text, repeating fields used to mean things the standard did not intend, custom segments or extensions carrying something you need, character encoding and line-ending quirks, and the perennial question of how corrections and cancellations are represented.

Fourth, and the one candidates skip, is the workflow. The same message name can be emitted at different moments in different hospitals: on order entry or on specimen collection, on preliminary result or only on final, on admission decision or on physical arrival on the ward. A message that arrives at a different point in the clinical process carries different meaning even when every field validates, and this is the class of difference that produces incidents rather than errors.

Stop mapping per site and publish a profile

The change that ends the pattern is to stop treating each connection as an integration project and start treating your side as a product with a specification. Concretely, that means publishing your own constrained profile of the standard: which messages or resources you accept, which fields are mandatory for you regardless of being optional in the standard, which code systems you require and which you will map, what cardinality you support, and what you do with anything you were not expecting. In FHIR terms this is an implementation guide with profiles and value-set bindings, and a capability statement describing what your endpoint supports. In HL7 v2 terms it is a conformance profile plus a table of the segments and fields you consume and ignore.

The profile is only half of it. The other half is executable: a conformance test suite a site can run before anyone books a meeting, seeded with a set of messages covering the awkward cases rather than the happy path — the unknown patient, the amended result, the cancelled order, the identifier that is missing, the code you have never seen. A site that passes the suite has told you something reliable about the connection. A site that fails it has told you what the work is before you commit a date.

Then keep the local knowledge out of your code. Site-specific identifier authorities, code maps and quirks belong in configuration or in a mapping service, versioned, reviewable, and attached to the site rather than to a release. The tell of an estate in trouble is a conditional in the application that names a hospital.

Where compatibility work stops being yours

There is a judgement in every one of these programmes about what to absorb and what to refuse, and being able to state a position is what separates a senior answer from an accommodating one.

Absorb the differences that are genuinely local and stable: identifier authorities, code maps, unit conversions, transport and encoding quirks. Refuse, and escalate to the sending organisation, the differences that make the data clinically unsafe or unprovable — a result with no code you can interpret, an amendment that cannot be distinguished from a new result, a patient identifier with no issuing authority, a message that omits something your safety logic depends on. Each of those, if quietly worked around, becomes an assumption buried in your code that nobody can find later, and the workaround is where the eventual harm comes from.

The corollary is a decision about degradation. When an incoming message is unmappable, the choices are to reject it loudly, to accept it and flag the record as incomplete, or to hold it for human resolution. Choosing silently to drop the unmappable part is the failure that shows up months later as a clinician looking at a record that is missing something they believe is present, and no error anywhere.

Why the second site is the honest estimate

The commercial trap in this situation is having estimated site five from the effort of site one. The first connection includes building the profile, the mapping layer and the test fixtures, so it looks expensive; the second reveals what is actually variable and therefore what the marginal cost really is. If sites two, three and four each cost roughly the same as the first, that is the diagnostic: the reusable asset is not being created, and the work is being redone by whoever is on the project. The metric to watch is not integration duration but the proportion of each connection that is configuration against the proportion that is new code, and driving that ratio one way is the entire point of the exercise.

Conformance is not compatibility. The standard tells you the shape of the message; your own profile, your terminology mapping and your test suite are what tell a new site what you actually mean by it.