NamingSystem Examples

ℹ️ For concepts, the Philippine NamingSystem registry, and the Patient identity use case, see [[An example use case for the NamingSystem resource]]. This page retains the original object diagrams and worked examples below.

---

FHIR NamingSystem in Context

Motivation, Model, and Examples

---

Overview

FHIR relies heavily on globally unique system identifiers (URIs) to distinguish:

• business identifiers (e.g. MRN, NHS number)
• terminology systems (e.g. SNOMED CT, LOINC)

However, a URI alone is not self-describing.

The NamingSystem resource provides a governed metadata layer that explains:

• what a system represents
• which identifiers (URI, OID, etc.) are equivalent
• which identifier is preferred or authoritative

This enables consistent interpretation, mapping, and governance across distributed systems.

---

Why this matters (practically)

Without NamingSystem:

• URIs become opaque strings
• mappings (OID ↔ URI) are ad hoc
• semantics are implicit and fragmented

With NamingSystem:

• identifier systems are discoverable and documented
• mappings are explicit and machine-processable
• governance can be centralised (e.g. IG, registry, terminology service)

---

Conceptual model

At runtime:

• Identifier.system and Coding.system carry a URI

At design/governance time:

• NamingSystem describes that URI and its equivalents

The crucial join is:

Identifier.system == NamingSystem.uniqueId.value

NamingSystemUniqueId captures:

• multiple identifiers for the same system
• preferences (e.g. URI vs OID)
• authority and validity period

---

Object diagram: Identifier example

This example shows a medical record number (MRN) system: a FHIR instance carries minimal data; the NamingSystem adds OID equivalents and governance metadata.

(Diagrams from original page retained below — see raw Markdown for embedded PNG data)