Skip to content

NamingSystem Examples

jg edited this page Jun 4, 2026 · 6 revisions

ℹ️ For concepts, the Philippine NamingSystem registry, and the Patient identity use case, see NamingSystem in PH Core. This page has the class and object diagrams.


FHIR NamingSystem — Model and Examples


Overview

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

  • business identifiers (e.g. MRN, PhilHealth PIN, PhilSys ID)
  • 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

Conceptual model

At runtime, Identifier.system and Coding.system carry a URI. At governance time, NamingSystem describes that URI and its equivalents. The critical join is:

Identifier.system == NamingSystem.uniqueId.value

Class diagram

classDiagram
    class Identifier {
        +URI system
        +string value
        +CodeableConcept type
    }

    class NamingSystem {
        +string name
        +code status
        +code kind
        +string publisher
        +string description
        +dateTime date
    }

    class NamingSystemUniqueId {
        +code type
        +string value
        +boolean preferred
        +Period period
        +string comment
    }

    Identifier ..> NamingSystemUniqueId : system == value
    NamingSystem "1" *-- "1..*" NamingSystemUniqueId : uniqueId
Loading

NamingSystemUniqueId.type values: uri | oid | other


Object diagram: PhilHealth PIN example

This shows how a Patient identifier in a FHIR instance links to its governing NamingSystem entry.

classDiagram
    class `Patient.identifier` {
        type.code = NH
        system = "http://philhealth.gov.ph/fhir/Identifier/philhealth-id"
        value = "12-345678901-2"
    }

    class PhilHealthIDNS {
        resourceType = NamingSystem
        name = "PhilHealthID"
        kind = identifier
        status = draft
        publisher = "PhilHealth"
        jurisdiction = PH
    }

    class UniqueId_URI {
        type = uri
        value = "http://philhealth.gov.ph/fhir/Identifier/philhealth-id"
        preferred = true
    }

    `Patient.identifier` ..> UniqueId_URI : system == value
    PhilHealthIDNS *-- UniqueId_URI : uniqueId
Loading

Object diagram: Layered identifiers (Patient CR scenario)

A single Patient can carry multiple identifiers from different agencies simultaneously — all valid under the open-sliced PHCorePatient profile.

classDiagram
    class `Patient (FHIR instance)` {
        identifier[0].system = philsys-id
        identifier[0].value = 1234-5678-9101-1213
        identifier[1].system = philhealth-id
        identifier[1].value = 12-345678901-2
        identifier[2].system = hospital-mrn
        identifier[2].value = MRN-00001
    }

    class PhilSysIDNS {
        name = PhilSysID
        publisher = PSA
        uniqueId.type = uri
        uniqueId.value = "http://philsys.gov.ph/fhir/Identifier/philsys-id"
    }

    class PhilHealthIDNS {
        name = PhilHealthID
        publisher = PhilHealth
        uniqueId.type = uri
        uniqueId.value = "http://philhealth.gov.ph/fhir/Identifier/philhealth-id"
    }

    class HospitalMRN_NS {
        name = HospitalMRN
        publisher = Facility
        uniqueId.type = uri
        uniqueId.value = "http://example-hospital.ph/fhir/Identifier/mrn"
        <<open slice — no NamingSystem required>>
    }

    `Patient (FHIR instance)` ..> PhilSysIDNS : identifier[0].system
    `Patient (FHIR instance)` ..> PhilHealthIDNS : identifier[1].system
    `Patient (FHIR instance)` ..> HospitalMRN_NS : identifier[2].system
Loading

The third identifier has no PH Core NamingSystem entry — it is still valid because PHCorePatient uses open slicing. Adding a NamingSystem entry for it later is a non-breaking improvement.


Why not embed diagrams as base64 PNGs?

GitHub wiki strips data: URIs for security. Images must either be hosted files in the wiki repo or Mermaid diagrams (natively supported). Mermaid is preferred — it stays in sync with the model and is diffable.

Clone this wiki locally