Patient identity
Start with VNCorePatient, NamingSystems for CCCD/BHYT/BHXH, the patient-cccd SearchParameter, and ethnicity/address extensions. The BHYT identifier has two formats: the current 10-digit number or the legacy 15-character card number.
VN Core Deep Dive
VN Core v0.9.0 artifact map: what to read before the IG
Within the VN Core trial-use package, the IG is the authoritative technical source for validation; it is not an officially recognized national standard. This page is a reading map for CIOs, developers, and domain teams: what each artifact type is for, how to read them in order, and when to jump into the corresponding IG page.
TL;DR
- Do not read the IG alphabetically. Read by workflow: identity, EMR, BHYT, terminology, server capability, then individual profiles.
- Profiles define data shape; CodeSystems and ValueSets define the allowed meaning of coded elements; CapabilityStatements define API capability.
- Examples and Bundles are the bridge between constraints and real data. Read them before writing adapters.
- The Knowledge Hub explains how to read; the IG is normative within the trial-use package for StructureDefinitions, package artifacts, and validation—not a claim of national-standard recognition.
1. VN Core is more than a profile list
New readers often open the IG, see a long artifact index, and assume VN Core is a profile library. That misses the design intent. A profile such as VNCorePatient only makes sense together with NamingSystems for CCCD/BHYT/BHXH, ethnicity CodeSystems, address ValueSets, search parameters, Vietnam examples, and CapabilityStatements describing what servers must support.
Read VN Core as three layers. The conformance layer answers "what is valid data". The terminology layer answers "what does this code mean and where did it come from". The implementation layer answers "what API capability, operation, validation, and bundle behavior must a system support". The IG contains all three; this hub gives the orientation before deep reading.
2. Artifact table and roles
| Artifact | Count | Read it to understand | FHIR type |
|---|---|---|---|
| Profiles | 86 | Constraints on FHIR Resources for Vietnam: Patient, Coverage, Claim, EMR, health checkups, IPS, device, and clinical data. | StructureDefinition |
| Extensions | 56 | Fields missing from FHIR base: ethnicity, ward/commune, BHYT, and Vietnam-specific data elements. | StructureDefinition |
| CodeSystems | 165 | Source code systems: demographics, legal references, BHYT, administrative divisions, ICD-10 VN, shared terminology. | CodeSystem |
| ValueSets | 168 | Allowed code sets bound to specific elements; they define which codes are valid in context. | ValueSet |
| ConceptMaps | 17 | Directional mappings between codes or concepts in identified code systems or value sets. | ConceptMap |
| NamingSystems | 36 | Registered URIs for identifiers: CCCD, BHYT, BHXH, facility codes, MRN. | NamingSystem |
| SearchParameters | 19 | API contracts for searching by CCCD, BHYT, MA_LK, MA_CSKCB, and Vietnam identifiers. | SearchParameter |
| CapabilityStatements | 5 | Minimum capability statements for servers, EMRs, BHYT gateways, and citizen apps. | CapabilityStatement |
| OperationDefinitions | 4 | Explicit operations: validate/submit/reverse BHYT claims and generate IPS summaries. | OperationDefinition |
| LogicalModels | 27 | Intermediate models for BHYT XML, health checkups, legal datasets, and forms before mapping to FHIR. | StructureDefinition |
3. Read by Vietnam workflow
BHYT and output data
Read Coverage, Claim, ClaimResponse, EOB, Invoice, 16 logical models (Check-in plus XML1–XML15), and three validate/submit/reverse operations. The logical models carry element-level ^mapping annotations for adapters; no published ConceptMap artifact spans and validates all XML1–XML15 ↔ Claim/EOB transformations end to end.
EMR and health summaries
Read Composition, DocumentReference, DiagnosticReport, Observation, Provenance, and document Bundles for EMR/IPS/VNeID workflows.
Terminology and legal traceability
Read CodeSystems and ValueSets before constraints: many FHIR errors are not JSON-shape errors but code-system errors.
4. Recommended reading order
- Read narrative pages first. The home page, Profiles, Terminology, and package architecture pages set the release boundary.
- Read examples before profiles. Real examples show workflow context and reference links.
- Read differential to see what VN Core added. Snapshot is long because it includes all inherited FHIR base content.
- Check terminology after the profile. Production errors often come from using the right element with the wrong system/code/version.
- Run the validator last. A payload is not compliant just because an application can parse the JSON.
5. Go deeper in the IG
Profiles
The normative source for StructureDefinitions, differentials, and snapshots.
Terminology
CodeSystems, ValueSets, ConceptMaps, and NamingSystems.
Artifact Index
The complete artifact index generated by the IG Publisher.
Next: how to read a Profile
Must Support, slicing, binding, extensions, and examples.
VN Core Deep Dive Series
Move from overview to the IG in the right order.
These four pages orient readers before opening the trial-use technical IG: understand the artifact map, read Profiles, govern terminology, then validate Bundles and workflow payloads.
Artifact map
CurrentProfiles, terminology, capability, operations, examples, and package boundary.
How to read a Profile
Differential, snapshot, Must Support, slicing, binding, and extensions.
Terminology
CodeSystems, ValueSets, ConceptMaps, NamingSystems, and Coding.display.
Bundles and validation
Bundles, examples, CapabilityStatements, OperationDefinitions, and go-live checks.