Template
Match the identifier together with its issuing namespace
Record 123 in one system has not introduced itself to record 123 in another.
When it fits
- Two systems use the same-looking number for potentially different entities.
When to avoid it
- Identifiers may be merged or reassigned. Record validity periods and ambiguous matches instead of forcing a one-to-one mapping that the domain does not support.
A template to use
Source namespace: [source system]. Source value: [source id]. Target namespace: [target system]. Target value: [target id]. Mapping authority and validity: [basis].
Why it matters
Treat an identifier as a value inside an issuing namespace. Use an authoritative crosswalk when matching across namespaces, and preserve both original identities. A shared name or number is a candidate match, not sufficient proof of equivalence.
An example
Customer 123 in a legacy system maps to partner 900123 in the new system. An unrelated target customer numbered 123 must not capture the relationship.
Check your result
Every accepted cross-system match has a namespace-aware rule or traceable mapping decision.
Keep this limit in mind
- Identifiers may be merged or reassigned. Record validity periods and ambiguous matches instead of forcing a one-to-one mapping that the domain does not support.
Connected ideas
Useful withName what one row means before joining two tables
Evidence and sources
Supports
FHIR Identifier separates the namespace in system from the identifier string in value, avoiding reliance on the value alone for identity.
A crosswalk still needs an authoritative mapping and rules for reassignment, merges and validity periods.
FHIR datatypes: Identifier · Identifier.system and Identifier.value