I spent the last several months on a project connecting patient records across two countries' hospital systems — call it a cross-border EHR integration. Our lead Business Analyst had spent over a decade in clinical informatics before moving into BA work, and pairing with her fundamentally changed how I think about healthcare software. Here are the five things that actually stuck.
- Terminology mapping is a harder problem than data mapping
As engineers, we tend to think of integration as a schema problem: map field A to field B, write a transform, done. That mental model breaks almost immediately in healthcare.
The two health systems we connected used different diagnostic coding standards — one was still primarily on ICD-10-CM, the other had partially migrated to ICD-11. Neither maps cleanly onto the other; ICD-11 restructured entire chapters and introduced post-coordination (the ability to combine codes to represent a more specific clinical concept) that has no direct ICD-10 equivalent. The same problem showed up with lab results: one side used LOINC consistently, the other had years of legacy data coded with internal lab identifiers that predated LOINC adoption.
Our BA built what she called a "concept crosswalk" before we wrote a line of integration code — a living spreadsheet, later a proper terminology service, mapping local codes to a canonical set (SNOMED CT for clinical findings, LOINC for observations, RxNorm for medications). Skipping that step and mapping database fields directly would have silently corrupted clinical meaning, not just data format.
Lesson: In most software integrations, a broken field mapping produces an obviously wrong value. In healthcare, a broken terminology mapping produces a plausible but clinically wrong value — which is far more dangerous and far harder to catch in QA.
- Data residency law shapes the architecture before a single API is designed
I came in assuming we'd design the data model first and figure out compliance around it. That's backwards for cross-border health data.
Patient data crossing a border touches multiple regulatory regimes simultaneously — HIPAA if U.S. data is involved, GDPR-style data protection rules if EU or adjacent jurisdictions are in play, plus whatever local health-data-sovereignty law applies to the source country's records. Some jurisdictions restrict health data from leaving the country at all except under narrow conditions (research consent, direct patient request, specific treatment continuity exceptions). Our BA sat with legal and compliance early to determine which fields could replicate across the border, which required de-identification first, and which couldn't leave the source system's jurisdiction under any circumstance.
That produced constraints that reshaped the whole architecture: a federated query layer instead of a single replicated database, per-field data classification tags baked into the schema, and an audit trail granular enough to prove exactly which fields crossed the border, when, and under what legal basis.
Lesson: For cross-border health projects, get compliance and a BA who understands regulatory nuance into the room before the data model exists, not after. Retrofitting data residency controls onto an already-designed schema is significantly more expensive than designing around them from day one.
- Interoperability standards are necessary but nowhere near sufficient
Both hospital systems technically supported HL7 — but one was still running on HL7 v2 messaging (ADT feeds, ORU results messages) from its core legacy EMR software, while the other had adopted FHIR R4 for newer services but kept HL7 v2 running underneath for older modules. "Both support HL7" turned out to mean two systems that couldn't talk to each other without a translation layer.
We ended up building a FHIR-facing integration layer with HL7 v2-to-FHIR adapters on the legacy side, since rewriting the older EMR software's messaging interface wasn't on the table. Even within FHIR, we hit profile mismatches — both systems claimed FHIR R4 compliance, but used different implementation guides (US Core vs. a regional equivalent) with different required fields and different extensions for locally significant data like national health identifiers.
Lesson: "We support HL7/FHIR" is a starting point for a conversation, not confirmation that integration will be straightforward. Always ask which version, which profile, and which implementation guide — and budget real time for an adapter layer even between two "standards-compliant" systems.
- A BA's workflow diagrams catch edge cases engineers structurally miss
Early on, I treated our BA's clinical workflow diagrams as documentation overhead — nice for stakeholders, not essential for building the thing. I was wrong.
She mapped out cross-border patient transfer scenarios in detail: what happens when a patient is referred mid-treatment, what happens to an active medication order when care crosses jurisdictions with different prescribing rules, what happens when a lab result returns after the patient has already been discharged back across the border. None of these are edge cases from a clinical standpoint — they're Tuesday. But they're exactly the scenarios engineers miss when we design against the happy path of "patient exists in System A, gets copied to System B."
Several of these workflows directly changed our data model — for example, we added an explicit "care episode" concept spanning both systems, rather than treating each system's encounter records as independent, because the clinical reality was one continuous episode of care crossing a border partway through.
Lesson: Workflow diagrams from someone who actually understands clinical operations aren't a documentation nicety — they're a requirements-gathering technique that surfaces edge cases no amount of engineering-side analysis will find on its own.
- A shared glossary should exist before the first requirements doc, not after the first miscommunication
This sounds obvious in retrospect, but it cost us real time before we fixed it. Words like "encounter," "episode," "active patient," and even "discharge" meant subtly different things in each health system's source EMR software and in each country's clinical documentation conventions. An "active" patient in one system meant currently admitted; in the other, it meant open in the record system regardless of admission status. We had at least two requirements documents reviewed and signed off on with each side interpreting a shared term differently, which surfaced only during integration testing.
Our BA eventually built a shared glossary as a living document, reviewed jointly by both sides' clinical and technical stakeholders, with every ambiguous term defined explicitly and versioned alongside the requirements. Every subsequent requirements doc referenced it directly instead of re-defining terms inline.
Lesson: In any project spanning two organizations — let alone two countries and two regulatory regimes — assume every domain term is ambiguous until it's explicitly defined in a document both sides have actually agreed to, not just skimmed.
Closing thought
None of these lessons are really about EHR systems specifically — they're about what happens when domain complexity (clinical workflows, regulatory law, terminology standards) outpaces what a typical engineering requirements process is built to handle. A strong BA doesn't just translate stakeholder requests into tickets; on a project like this, she was closer to a systems architect for everything outside the codebase — regulatory constraints, clinical semantics, and cross-organizational communication. If you're building or integrating EMR software across borders, budget real time and real headcount for that role. It's not overhead — it's the thing that keeps a technically correct integration from becoming a clinically wrong one.
Top comments (1)
Excellent insights! One of the biggest lessons in healthcare interoperability is that preserving clinical meaning is just as important as moving data. Terminology mapping, compliance with data residency regulations, and standardized frameworks like SNOMED CT, LOINC, and RxNorm are essential for building reliable cross-border EHR systems. At Dev Technosys, we believe successful healthcare software goes beyond API integration—it requires secure architecture, regulatory compliance, and accurate semantic interoperability to ensure patient data remains consistent, meaningful, and trustworthy across healthcare ecosystems.