How to read a VN Core Profile

2. Must Support versus cardinality

Cardinality answers whether an instance must contain an element. If an element is 1..1, a payload missing that element will not validate. If it is 0..1, the payload may omit it and remain valid.

Must Support answers whether systems in the IG scope must understand and handle the element. A 0..1 MS element may be absent in an individual payload, but a conforming VN Core system must not ignore it when present.

3. Identifier slicing: Vietnam Patient example

FHIR base only says Patient.identifier is an array of identifiers. VN Core must distinguish identifier types because each has a different authority, format, and workflow. Slicing lets the same array carry named slices:

Patient.identifier
  ├── identifier[CCCD]  system = .../sid/cccd   value = 12 digits
  ├── identifier[BHYT]  system = .../sid/bhyt   value = BHYT card number
  ├── identifier[BHXH]  system = .../sid/bhxh   value = 10 digits
  ├── identifier[MRN]   system = hospital MRN   value = local medical record number
  └── identifier[GKS]   system = birth certificate value = certificate number

When a HIS adapter sends Patient data, the validator checks not only that identifier exists, but also which slice matches, whether the system URI is correct, whether the value matches the expected pattern, and whether slice cardinalities are satisfied.

4. Binding and terminology

Coded elements such as Condition.code, Observation.code, Patient.gender, or ethnicity extensions are not free-text fields. The profile binds them to a ValueSet with a binding strength. With required, the code must be in the ValueSet. With extensible, systems should use the ValueSet when a suitable code exists and only go outside it for a real gap.

In Vietnam data, binding is especially important because the same display label may appear in multiple code systems. "01", "DN", or "I10" only become unambiguous with the right system. That is why VN Core maintains separate CodeSystems and ValueSets for each domain.