Map every system once, not to each other

The question came from the new CTO, twenty minutes into her first architecture review, and it was not a hard one. "How many integrations do we have?" Whiteboard markers came out. The count stalled twice, restarted once, and settled on forty-one, at which point she asked the question she had actually come to ask: "So what does number forty-two cost?"

Six weeks and a specialist contractor, was the answer. For one interface. The room heard it said out loud and finally recognized the shape of the thing they had built: every system wired directly to every system that needed it, lab feed to EHR, EHR to analytics, device gateway to care platform, each connection a bespoke translation lovingly maintained by whoever wrote it. Point-to-point integration grows as a square. Twelve systems talking to each other is sixty-six potential translations, and every new data source multiplies rather than adds.

The deeper cost was semantic. Each interface translated codes its own way, so "type 2 diabetes" arrived as an ICD-10 code from one system, a legacy local code from another, and free text from a third. The analytics team's patient counts disagreed with the care team's, not because either was careless, but because the same clinical fact wore a different costume on every wire.

Point-to-point grows as a square. A canonical model grows as a line.

The architecture that fixes this is neither novel nor exotic; it is simply underadopted below the health-system tier. Map every source once, into one canonical model, and let every consumer read from the hub.

The canonical model problem is already solved in public: FHIR R4, the resource model that modern healthcare APIs and, increasingly, regulators have standardized on. A lab result becomes an Observation, a diagnosis a Condition, a prescription a MedicationRequest, regardless of which system it was born in. Legacy sources that speak HL7v2, and most hospitaladjacent feeds still do, get translated at the boundary by an integration engine; Mirth Connect does this job well and is open source, with HAPI FHIR as the equally open server and validation layer on the other side.

Codes get the same treatment through a terminology service. Conditions normalize to SNOMED CT, labs to LOINC, medications to RxNorm, so the diabetic-patient query is one query, written once, against one vocabulary. The mapping from each source's local dialect is work, no honest person pretends otherwise, but it is bounded work: you do it once per system, at the boundary, instead of once per connection, forever.

Integration forty-two stops costing six weeks of archaeology. It costs one mapping, from the new system's dialect to the canonical model, and every existing consumer receives its data on arrival without a line of new code.

Translate at the boundary, once, or translate everywhere, forever.

(The whiteboard diagram, redrawn as a hub, fit in the corner that the old one had used for arrows alone.)

What tends to get underestimated is how much regulatory surface this one decision retires. Information-blocking rules and payer-interoperability mandates increasingly require FHIR APIs at the edges of health-data businesses; a company whose internal spine is already canonical FHIR exposes those APIs as a router, while a point-to-point shop faces yet another bespoke integration, this time with a deadline attached and a regulator watching. Audit trails consolidate at one hub instead of forty-one wires. And analytics, the thing every health-data company sells eventually, stops being a reconciliation project and starts being a query.

We built this spine for a digital-health platform drowning at eleven integrations: Mirth at the boundary, FHIR R4 in the middle, terminology normalization on ingest. Their twelfth source went live in nine days instead of the usual six weeks, and the two patient counts that had disagreed for a year finally converged, because there was finally one place where a patient was counted.

At TensorLabs we do the unglamorous middle of healthtech data, the mappings, the terminology plumbing, the hub, so the product on top can move at product speed. The forty-second integration is coming either way. The architecture decides whether it is a mapping or a project.