HIS / EMR vendor
Produce resources conforming to VN Core profiles; submit electronic medical records and BHYT claim data.
VNCoreEMRServer →Conformance
VN Core conformance is profiles + API + testing, not just valid JSON.
This page summarises how to demonstrate that a system conforms to VN Core and links to the detailed technical pages in the Implementation Guide. Conformance is defined by ROLE (sender, receiver, server, client) and by the PACKAGE you implement.
Which actor are you?
Each role has its own CapabilityStatement stating interactions and searches at SHALL/SHOULD/MAY. Pick the role closest to your system.
Hospital FHIR server
Serve read/search by profile, support _include/_revinclude, enforce SMART/OAuth security.
VNCoreServer →BHYT claim gateway
Map XML 4210/3176 ↔ FHIR Claim/Coverage and validate before submitting to the social-insurance portal.
VNBHYTGatewayServer/Client →Citizen app (VNeID / PHR)
Read the IPS $summary, render the health record, honour Consent.
VNCitizenAppClient →Regulator / standards architecture
Set minimum conformance thresholds and assess implementer readiness evidence.
Conformance by actor →What Must Support means
Must Support is a role-based obligation, not a mandatory cardinality. Misreading this is the most common conformance mistake.
| Role | Must Support obligation |
|---|---|
| SENDER (Producer) | Must populate Must Support elements when the source has a value. When absent, use Data Absent Reason instead of fabricating a placeholder. |
| RECEIVER (Consumer) | Must be able to process/store Must Support elements on receipt; must not silently drop them. Not required to generate data. |
| FHIR Server | Declares supported profiles via supportedProfile and SHALL/SHOULD/MAY expectation per interaction/search in its CapabilityStatement. |
| Client | Follows its role CapabilityStatement: rely only on interactions/searches marked SHALL; treat SHOULD/MAY as optional. |
Conformance verification recipe
Six reproducible steps to go from "valid JSON" to "evidenced VN Core conformance".
1
Install the right package
Pick by scope: hl7.fhir.vn.core.base, hl7.fhir.vn.bhyt.submission, hl7.fhir.vn.terminology.clinical / traditional-medicine, hl7.fhir.vn.device. Download from the IG Downloads page.
Download packages →2
Validate with $validate
Run the official HL7 FHIR Validator with the VN Core package. Every instance must pass Tier-1 FHIRPath invariants (e.g. vn-cccd-format, vn-addr-province) before considering Must Support.
3-tier validation →3
Check Must Support by role
Producers must populate Must Support elements when data exists; consumers must process them on receipt. Must Support is not the same as a 1..1 mandatory cardinality.
Must Support guidance →4
Test search + operations
Server: exercise key search parameters/combinations (Patient/MPI, Encounter, Claim by MA_LK, Coverage/BHYT) plus _include/_revinclude per CapabilityStatement; test applicable operations: $summary (IPS), $validate, BHYT submission.
Search & interactions →5
Reconcile OperationOutcome
On validation failure the OperationOutcome codes must match the IG rule registry (Tier 2/3). This is reproducible conformance evidence, not just "valid JSON".
OperationOutcome rules →6
Self-assess & submit a report
Use the pilot readiness checklist as conformance evidence. Submit an implementation report (including real gaps) to feed the community roadmap and maturity progression.
Pilot readiness checklist →Security & privacy
Every implementation must meet the security baseline: SMART on FHIR / OAuth 2.0 for authorization, and Consent + AuditEvent + Provenance for health data (sensitive personal data under Law 91/2025 and Decree 356/2025).