Healthcare Interoperability Platform Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does terminology mapping scope always get underestimated?

Because the standards make it look solved. Laboratory results use LOINC, clinical findings use SNOMED, medications use RxNorm, diagnoses use ICD-10, and all of that is written down and freely available. A developer reads it, sees a set of code systems, and prices a mapping table.

What actually arrives from a hospital is a local laboratory code, a local formulary identifier and a department specific result name that has been in use since before the current laboratory information system was installed. Mapping those to standard codes is the majority of the effort in nearly every interoperability project we have delivered, and it is not a one time task. Partners add tests, change formularies and rename panels continuously, so an estate that was fully mapped in March is not fully mapped in September.

The fix is to treat mapping as a governed operation rather than a data structure. Somebody proposes a mapping, somebody with clinical authority approves the ones that matter clinically, the map is versioned, and unmapped codes land in a visible queue that a named person works rather than a log line nobody reads. Then make historical data reprocessable, which is only possible if the raw payload was retained. Ask any prospective developer what happens to a code arriving with no mapping. If the answer does not include a retained payload, a flagged record, a worked queue and reprocessing, the project will stall in year two and nobody will be able to say exactly when it started going wrong.

What goes wrong when you backload historical messages and records?

Historical backload is often the single largest work package in this category and it is the one most reliably left out of the estimate, because during scoping everyone is thinking about the live feed.

The problems are specific. Old messages use segment layouts and local extensions that have since changed at the partner, so a parser written for today's feed silently misreads a 2022 message. Patient identifiers were reissued at some point, meaning the same human appears under two identifiers with no link. Codes that are mapped today did not exist then, and codes that existed then have been retired. And the volume changes the engineering: normalising three years of results is a throughput problem rather than an interface problem, and it will expose every performance assumption in the matching layer.

The fix is to sequence backload after the live feed is stable and after mapping governance exists, never in parallel. Run it as a reprocessing exercise over retained raw payloads rather than as a separate import path, so there is one normalisation code path and one set of rules. Expect to run it more than once, and design for that from the start. A backload that can only be run once is a backload you will be afraid to correct.

Why do partner feeds break after launch?

Partner feeds fail in ways that do not announce themselves. The connection stays up, messages keep arriving, and something inside them has changed.

A hospital upgrades its electronic health record and a local extension segment moves. A laboratory adds three new tests, which arrive as unmapped codes and quietly accumulate. A partner changes how it populates a field, so a value that used to be a department name becomes a location code, and downstream logic that keyed on it now produces nothing rather than an error. The most damaging variant is a match rate change: a partner alters how it sends addresses or names and your matching starts producing duplicates, which nobody notices until a clinician sees a patient with two records.

The fix is monitoring the shape of the data rather than the health of the connection. Track message volume by type and by partner, unmapped code counts, and match rate per source, with alerts on movement rather than on absence. A partner whose match rate drops has usually changed something upstream without telling you, and finding that in a week is a conversation while finding it in a quarter is a data cleanup. Also keep the raw payload, because every one of these situations is recoverable if the original message still exists and unrecoverable if it does not.

What happens when identity matching and consent are treated as features?

Both get scoped as capabilities the platform has, and both are actually organisational risk decisions that happen to need software.

The standard defines a Patient resource. It does not tell you whether the resource arriving from a partner describes the same human as the one already in your database. Real inbound data carries nicknames, transposed dates of birth, addresses two moves out of date and partial identifiers, and payer member identifiers frequently change at renewal. A false match means one patient sees another patient's medication list, which is a serious incident. A false non match means a duplicate record and a care gap nobody closes. Where you set that threshold is a decision with clinical and legal consequences, and a vendor default is not an answer to it.

Consent is the same shape. Most platforms enforce access at the connection level, meaning a partner may read patients, which is far too coarse for anything real. It is why so many integration projects end with a data sharing agreement doing work the software should be doing.

The fix is an explicit master patient index with tunable thresholds, an automatic band, a review queue band and a no match band, plus full lineage so any merge can be reversed. Unmerge is the capability people skip and the one you will need, because merges get made in good faith on bad data. On consent, evaluate policy per request against the requester, the stated purpose of use, the resource category and any recorded patient preference, and log every decision. SMART on FHIR scopes give you a workable framework for application authorization, but category level segmentation for behavioural health, substance use treatment, reproductive health and genetic data encodes your legal posture and has to be built deliberately.

Should you build custom or configure what you already own?

Almost nobody should build the transport layer, and this is the most common expensive mistake in the category. If you are a digital health company connecting a product to hospital electronic health records, Redox exists precisely for that and will get you live in weeks while a build would consume the engineering you need for the product. If you are a payer whose immediate requirement is patient access endpoints and nothing more, 1upHealth addresses that directly.

If you already run Rhapsody or InterSystems HealthShare with a competent integration team, keep it. Protocol handling and connectivity are solved, rebuilding them adds risk with no benefit, and the sensible sequencing is to keep the engine as transport and build the canonical model, master patient index, terminology governance and consent engine above it. Smile Digital Health gives you a serious FHIR server if you need storage and query rather than a data model.

Build the layer above when interoperability has become shared infrastructure rather than one integration: several internal products depend on the same data, partner count is growing and expected to keep growing, and identity, terminology and consent decisions are specific enough to your organisation that no default is acceptable. In our experience organisations cross that line somewhere between fifteen and thirty active partner connections, earlier at high volume and later where connections are simple and stable.

How do hidden costs get into the quote?

Source system diversity is the largest driver and it hides behind a partner count. Each electronic health record vendor and each version behaves differently for the same message type, so five partners on three different products is a bigger job than eight partners on one. Ask which specific systems and versions before anyone estimates.

Regulatory endpoint obligations come second if you are a payer, because patient access and provider directory requirements have a shape you do not get to choose. Bulk data at population scale is third and it is an infrastructure problem rather than an interface problem. Network participation such as a trusted exchange framework connection is fourth and brings conformance work with its own calendar. Historical backload is fifth and is frequently the largest single item.

The fix is to scope a first release deliberately narrow: three source systems, one downstream consumer, no bulk export, and the existing interface engine retained as transport. That release proves the canonical model, the index and the mapping workflow, which are the parts that are genuinely hard, and it leaves every expensive decision available rather than pre-committed.

What separates an interoperability build that works from one that fails?

Working platforms make onboarding a new partner into configuration plus a mapping pass, which is days for a familiar source system and a couple of weeks for an unfamiliar one. That is the whole return on the investment. If a new partner is still weeks of engineering after the platform exists, the canonical model is not doing its job and you have built a nicer version of what you had.

The remaining schedule risk is external and it is worth planning around honestly. Getting through a partner's security review, access request process and test environment scheduling routinely takes longer than the technical work, and no amount of engineering quality shortens it. Start those conversations before the build begins.

Two questions separate developers who have run this in production from those who have read about it. Ask what happens when two records match at a confidence just below the automatic threshold. If there is no review queue and no unmerge path in the answer, they have not operated a master patient index. Then ask which electronic health records they have pulled from, and press for the interface method and the authorisation model rather than accepting a list of names.

Finally, own the code, the cloud accounts and the retained raw data, agreed in writing before kickoff. The point of building this layer is to stop renting your infrastructure, and replacing one dependency with a development agency is not progress. At Digital Heroes the repository is the client's from the first commit.