NamingSystem Examples

ℹ️ For concepts, the Philippine NamingSystem registry, and the Patient identity use case, see NamingSystem in PH Core. 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)