FHIR Platform Development: Why Every New Partner Becomes Another Bespoke Integration

Why the integration layer becomes the bottleneck for everything else

The pattern is always the same and it always arrives quietly. The first integration is a one off. A health system partner sends admission, discharge and transfer messages over a virtual private network, someone writes a parser, it works. The second partner sends the same message type with a different segment layout and a local code set, so the parser grows conditionals. The third wants FHIR. The fourth is a payer sending claims in an X12 file. By the fifth, one engineer is the only person who understands why partner three's messages are dropped on Sundays, and every product roadmap conversation now begins with how long the integration will take.

What makes this specific to healthcare is that none of the parties can be told to standardise. A hospital's interface engine reflects twenty years of decisions by people who left. A payer's member identifier is not the same as the identifier on the member's card. Standards exist and are genuinely useful, but the standard describes the envelope, not the local vocabulary inside it, and the local vocabulary is where the work is.

The vendors here are good at real things. Redox removes the pain of connecting a digital health product to many hospitals. 1upHealth is strong on payer facing patient access and bulk data. InterSystems HealthShare and Rhapsody are mature engines with deep protocol support. Smile Digital Health gives you a serious FHIR server. What none of them removes is the part that is about your organisation: which patient is which, what your local codes mean, and who is allowed to see what. That work does not transfer, and it is most of the project.

Problem 1: HL7 version 2 did not go away because FHIR arrived

Any platform plan that assumes FHIR endpoints on both sides is a plan for a future that has not arrived at your partners. Real estates run admission, discharge and transfer feeds, order and result messages and scheduling messages over HL7 version 2 with local Z segments, and they will for years because replacing a working interface has no clinical benefit and real risk.

Packaged FHIR servers assume resources arriving as resources. Interface engines handle version 2 well but treat FHIR as one more output channel rather than as the data model. Neither posture is right for an organisation that has to live in both worlds for a decade.

What a custom build does: accept that ingestion is polyglot and normalisation is the product. Version 2 messages, FHIR resources, X12 transactions and flat files all land in one internal canonical model, and everything downstream reads the canonical model rather than the wire format. That single decision is what stops a new partner from being a new codebase. It also means when a partner upgrades from version 2 feeds to a FHIR API, nothing downstream changes, which is the payoff you are actually buying.

Problem 2: identity is the hard part, and the standard does not solve it

FHIR gives you a Patient resource. It does not tell you whether the Patient resource arriving from a partner is the same human as the one already in your database. In practice you get a name that may be a nickname, a date of birth that may be transposed, an address that is two moves old, a partial identifier and sometimes nothing else. Payers face the same problem in a different shape: a member whose identifier changed at renewal is a new person to most systems.

Every packaged product has a matching feature. What they do not have is your risk tolerance. A false match in a care coordination product means one patient sees another patient's medication list, which is a serious incident. A false non match means duplicate records and a care gap that nobody closes. Where you set that threshold is an organisational decision with clinical and legal consequences, and it has to be revisited as your data changes.

What a custom build does: an explicit master patient index with probabilistic matching, tunable thresholds, an automatic match band, a review queue band and a no match band, plus full lineage so any merged record can be unmerged. Unmerge capability is the one people skip and the one you will need, because merges get made in good faith on bad data and reversing them without lineage is data loss. Match rates should be monitored per source, since a partner whose match rate drops usually changed something upstream without telling you.

Problem 3: terminology mapping is where projects quietly die

The standards name the vocabularies. Laboratory results use LOINC, clinical findings use SNOMED, medications use RxNorm, diagnoses use ICD-10. What arrives from a hospital is a local laboratory code, a local medication formulary identifier and a department specific result name that has been in use since before the current laboratory information system. Mapping those to standard codes is the majority of the effort in almost every interoperability project we have delivered, and it is not a one time task because partners add tests and change formularies continuously.

Engines will hold mapping tables. What they do not give you is a mapping operation: who proposes a mapping, who approves it clinically, what happens to data that arrived before the mapping existed, and how you find the unmapped codes that are silently falling on the floor.

What a custom build does: treat mapping as a governed workflow with a versioned map, an approval step for clinically significant codes, and an unmapped code queue that is visible and worked rather than logged. Data that arrived before a mapping existed should be re-processable, which means keeping the raw payload alongside the normalised record. Storage is cheap. Re-deriving a year of results you already received is not.

Problem 4: consent and authorization at the resource level

Once data flows, the question shifts from can we get it to who may see it. That is not one rule. It varies by data category, since behavioural health, substance use treatment, reproductive health and genetic data carry different handling expectations and in some cases different legal regimes. It varies by relationship, since a treating clinician, a care manager, a researcher and a partner application are different requesters. It varies by patient choice where the patient has expressed one.

Most platforms enforce access at the connection level. Partner A may read patients. That is far too coarse for anything real, and it is the reason so many integration projects end with a data sharing agreement doing work the software should be doing.

What a custom build does: policy evaluated per request against the requester, the purpose of use, the resource category and the patient's recorded preferences, with every decision logged. SMART on FHIR scopes give you a workable framework for application authorization, but the category level segmentation and purpose of use logic is yours to build, because it encodes your legal posture and your state law exposure.

Problem 5: per connection pricing turns your roadmap into a budget conversation

Integration vendors price per connection, per partner or per volume. That is a fair commercial model and it works well when you have a few connections. It works badly when interoperability becomes a shared platform capability, because now every product decision carries a marginal integration cost and product managers start avoiding integrations that would be good for users.

The tipping point is easy to identify in your own numbers. Add up annual integration vendor spend, multiply your planned connection growth, and compare against a build plus two engineers for ongoing operation. In our experience organisations cross that line somewhere between fifteen and thirty active partner connections, earlier if volumes are high, later if the connections are simple and stable. Below the line, buying is correct. Above it, you are renting something you use as infrastructure.

What a FHIR interoperability build costs and how long it takes

A first release covering polyglot ingestion for HL7 version 2 and FHIR, a canonical model, a working master patient index with review queues, terminology mapping with an unmapped queue, and a FHIR facade for internal consumers runs $100,000 to $200,000 and ships in 14 to 20 weeks in our delivery experience. A full platform adding bulk export, payer facing patient access and provider directory endpoints, X12 claims ingestion, consent and purpose of use enforcement, partner onboarding tooling and operational monitoring runs $300,000 to $750,000 phased over 9 to 18 months.

What drives cost up here specifically: the number and diversity of source systems, since each electronic health record vendor and each version behaves differently even for the same message type. Regulatory endpoint obligations if you are a payer, because patient access and provider directory requirements have shapes you do not get to choose. Bulk data at population scale, which is an infrastructure problem rather than an interface problem. Network participation such as a trusted exchange framework connection, which brings its own conformance work. And historical backload, which is often the largest single item and the one nobody scopes.

What keeps it down: three source systems, one downstream consumer, no bulk export in phase one, and a deliberate decision to keep the existing interface engine running as a transport while the canonical model and index are built above it.

Build versus buy, and when a vendor is the right call

Buy if you are a digital health company whose product connects to hospital electronic health records and integration is a means, not the product. Redox exists precisely for that and will get you live far faster than a build. If you are a payer whose immediate need is regulatory patient access endpoints and nothing more, 1upHealth solves that problem directly. If you have an existing engine estate and a competent integration team, Rhapsody or InterSystems HealthShare with your own logic on top is a sensible path that keeps the protocol handling you already trust.

Build when interoperability is infrastructure rather than a feature. That means several internal products depend on the same data, partner count is growing and expected to keep growing, and identity, terminology and consent decisions are organisation specific enough that no vendor default is acceptable. Build also when data residency, cost at volume or the ability to reprocess historical payloads matters to you, since those are the areas where hosted products constrain you most.

Our position: almost nobody should build the transport layer. Plenty of organisations should build the canonical model, the index, the terminology governance and the consent engine, and let a vendor or an existing engine move bytes. Confusing those two decisions is the most common and most expensive mistake in this category.

How to choose a developer for healthcare interoperability work

Ask them to describe 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 run a master patient index in production.

Ask what they do with a code that arrives with no mapping. The right answer is that the raw payload is retained, the record is flagged, the code lands in a worked queue and the data becomes reprocessable once the mapping exists. Silently dropping it is common and it is how you lose a year of results.

Ask which electronic health records they have actually pulled from, and press for specifics on the interface method and the authorisation model. The gap between reading a specification and getting a real access request through a hospital's process is measured in months, and experience there is worth more than framework familiarity.

Ask who owns the code, the cloud accounts and the retained raw data, and get it in writing before kickoff. At Digital Heroes the client owns the repository from the first commit and everything runs in the client's own cloud accounts. In a category where the point is to stop renting your infrastructure, replacing one dependency with another is not progress.