-
Notifications
You must be signed in to change notification settings - Fork 14
NamingSystem Examples
ℹ️ 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 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
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
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
NamingSystemUniqueId.type values: uri | oid | other
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
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
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.
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.