HIS / EMR vendor
Produce resources for the selected VN Core profiles and workflows; submit EMR/BHYT data only where the applicable interface requires it.
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
Advertise the read/search interactions, profiles, search parameters, _include/_revinclude behavior, and authorization mechanism it actually supports.
VNCoreServer →BHYT claim gateway
Map XML 4210/3176 ↔ FHIR Claim/Coverage and validate before submitting to the social-insurance portal.
VNBHYTGatewayServer/Client →Citizen app / PHR
Read data within the endpoint and authorization scope actually advertised; apply consent/access policy where the use case requires it.
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
Each implementation derives its security baseline from processing roles, data flows, and its threat model. OAuth 2.0/SMART can provide authorization where the endpoint advertises it; Consent, AuditEvent, and Provenance represent only the choices, events, and origins selected by the applicable policy and event model. These Resources do not by themselves establish compliance with Law 91/2025 or Decree 356/2025.