A shared care record across an Integrated Care System sounds, on paper, like a solved problem once the technical plumbing is in place: every provider's data flows into one place, clinicians across the system can see it, done. In practice, the plumbing is rarely the hard part. The hard part surfaces the first time a GP practice's diagnosis code, a community provider's locally authored code, and the acute Trust's SNOMED CT concept all describe the same clinical reality in three different vocabularies, and the shared record has no way of knowing they agree.
That's the terminology problem an ICS inherits by design, and it's worth taking seriously before the shared care record's usefulness gets quietly undermined by it.
In brief
An ICS brings together providers, acute Trusts, community services, GP practices, mental health providers, each with its own systems and often its own coding history, and asks them to contribute to one shared clinical picture. Cross-organisation terminology mapping is the discipline that makes that picture coherent: establishing concept maps between the value sets each provider actually uses, so a clinician viewing the shared record sees one consistent clinical language regardless of which organisation originated a given piece of data. Done correctly, in FHIR terms, mapping happens between value sets, the specific, governed shortlists each context actually draws from, not between whole code systems, because that scoping is what keeps the resulting maps finite, testable and maintainable across as many providers as the ICS contains.
The shared care record that isn't actually shared
An ICS typically inherits a genuinely varied terminology landscape: an acute Trust with a mature SNOMED CT implementation, a community provider still carrying legacy local codes for reasons that made sense a decade ago, a mental health trust with its own historical coding conventions, and GP practices whose Read or SNOMED CT usage varies by system supplier and by how thoroughly any given practice has migrated. None of these providers did anything wrong; each simply evolved its own coding practice independently, long before anyone asked them to contribute to a single shared view.
When a shared care record aggregates data from all of them without addressing this, it produces something that looks unified on screen and isn't underneath: the same condition appears as three superficially different entries depending on which provider's data a clinician happens to be looking at, and any analytics or clinical decision support built on top inherits that fragmentation silently.
Why an ICS inherits a terminology problem by design
This isn't a failure of any individual organisation; it's the structural consequence of asking previously independent providers, each with a legitimate, separately evolved coding history, to suddenly present as one coherent clinical picture. A single Trust solving its own internal terminology governance is hard enough. An ICS is being asked to solve the same problem across organisational boundaries, different IT systems, different supplier relationships, and often different paces of standards adoption, none of which any single provider can unilaterally fix.
What cross-organisation mapping actually requires
The technically correct approach starts with a detail that's easy to get wrong: mapping happens between value sets, not between whole code systems. You are never really building "a map from Provider A's codes to SNOMED CT" as an abstract, unbounded exercise; you're mapping the specific, governed set of codes Provider A actually uses in a defined context to the specific set of codes the shared record expects in that same context. That scoping, established elsewhere in this series' terminology basics piece, is precisely what makes a map across five, ten, or twenty providers a tractable, maintainable body of work rather than an open-ended crosswalk with no natural finish line.
Practically, this means the ICS needs a defined target vocabulary for the shared record, usually SNOMED CT-based and aligned to UK Core where FHIR is the exchange mechanism, a value set defined for each clinical context the shared record cares about, and a concept map from each provider's relevant value set into that target, maintained as a versioned artefact rather than a one-off translation exercise.
Governance: who owns a map that spans organisations
The technical mapping is usually more tractable than the governance question sitting behind it: who owns a concept map that spans two independent organisations, each with its own clinical safety and information governance processes? This needs an explicit answer before the mapping work starts, not after a disagreement surfaces. In practice, the workable pattern is a named ICS-level terminology function, whether that's a small central team or a nominated lead organisation, that owns the target value sets and the maps into them, while each contributing provider remains accountable for the accuracy of its own source codes. A terminology platform hosting these mappings as governed, versioned artefacts, which is precisely the role WeHub Term is designed to play, gives that ICS-level function somewhere concrete to hold the maps rather than leaving them scattered across individual point-to-point integrations.
Where this breaks down in practice
A few patterns account for most of the failures worth watching for. Mapping against a whole code system instead of a scoped value set, which turns a tractable, bounded task into an open-ended one that never quite finishes. No clear escalation path when a provider's code genuinely has no good equivalent in the target vocabulary, leaving individual integrators to quietly invent ad hoc translations that nobody else knows about. And treating the mapping as a one-off migration project rather than a maintained artefact, so it quietly goes stale the first time any provider's coding practice evolves, which, across five or more independent organisations, is a matter of when, not if.
The bottom line
A shared care record's usefulness is capped by how coherent its underlying vocabulary actually is, and that coherence has to be built deliberately; it doesn't emerge from aggregating data alone. The technical discipline, mapping value set to value set rather than code system to code system, is well understood and tractable. The governance question, who owns a map spanning independent organisations, needs an explicit, named answer before the technical work starts. If your ICS's shared record has been live for a while and nobody can name who owns its terminology mappings, that's this quarter's most consequential governance gap to close.
