FHIR and Vietnam's Personal Data Protection Law — Law 91/2025

1. The 2026 legal framework

Vietnam's personal data protection framework changed fundamentally in the second half of 2025. Previously, Decree 13/2023/NĐ-CP was the primary instrument. From 01/01/2026, Decree 13/2023 is repealed and entirely replaced by Decree 356/2025/NĐ-CP, which sits under Law 91/2025/QH15. Every legal reference in internal documentation, data processing agreements (DPAs), and privacy policies needs an update.

Five key documents that hospitals and EMR vendors need to track:

2. Personal data classification — health data is sensitive

Law 91/2025 distinguishes two categories: basic personal data and sensitive personal data. The annex to Decree 356/2025 lists each in detail.

Basic personal data

• Full name, date of birth, gender, place of birth, place of residence.
• Phone number, email address.
• National ID number (CCCD), passport number, driver's license.
• Marital status, education, occupation.
• Personal photographs (excluding the photo on a national ID card).

Sensitive personal data — highest requirements

• Health data: medical records, prescriptions, lab results, medical imaging, allergies, mental health status, genetic data.
• Biometric data: fingerprints, iris, face, voice.
• Financial transaction history, credit information.
• Ethnic origin, religion, political opinion.
• VNeID account information, photos of national ID cards.
• Sexual life and sexual orientation.

Implications for FHIR systems: any clinical resource tied to an identified patient (Patient, Encounter, Condition, Observation, MedicationRequest, DiagnosticReport, AllergyIntolerance, Procedure, etc.) is sensitive personal data. By contrast, infrastructure resources (CodeSystem, ValueSet, StructureDefinition) and properly anonymized or aggregated data are not automatically classified as sensitive — but the organization must run its own assessment and document the rationale.

Law 91/2025 recognizes the principle that data anonymized to the point where the subject can no longer be identified is no longer personal data. This is the legal basis for hospitals to share datasets for research, AI model training, or epidemiological reporting — provided the anonymization technique meets the standard and a DPIA documents the assessment.

3. Eight data subject rights — mapped to FHIR

Law 91/2025 enshrines eight core rights for the data subject. Each right requires a concrete technical mechanism in the EMR and FHIR server.

4. Consent — representing patient consent

The Consent resource in FHIR R4 encodes consent in a structured form: who consents, who is allowed to do what, within what scope and time period, with the right to withdraw at any time. This is the primary surface where legal and technical concerns meet.

A concrete example: patient Nguyễn Thị Lan (12-digit national ID) consents to Bach Mai Hospital using her medical record for treatment, and additionally permits a summary to be shared into the personal health record on VNeID — Vietnam's national digital identification app — for five years. These two purposes should be recorded as two separate Consent resources, so that withdrawing consent for VNeID sharing does not affect treatment.

Note on VNeID flows: the technical specification for the VNeID Health API (push, pull, signing, withdrawal) has not been published publicly by the Ministry of Public Security or Ministry of Health as of April 2026. Consent flows for VNeID sharing described here are reference architectures based on common patterns (Apple HealthKit, Google Health Records). Final implementation details depend on the official integration contract.

{
  "resourceType": "Consent",
  "status": "active",
  "scope": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/consentscope",
      "code": "patient-privacy"
    }]
  },
  "category": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/consentcategorycodes",
      "code": "treatment"
    }]
  }],
  "patient": { "reference": "Patient/nguyen-thi-lan-001" },
  "dateTime": "2026-04-30T10:00:00+07:00",
  "performer": [{ "reference": "Patient/nguyen-thi-lan-001" }],
  "organization": [{ "reference": "Organization/bv-bach-mai" }],
  "policy": [{ "uri": "https://bachmai.gov.vn/policy/quyen-rieng-tu-v2" }],
  "provision": {
    "type": "permit",
    "period": { "start": "2026-04-30", "end": "2031-04-30" },
    "purpose": [{
      "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason",
      "code": "TREAT"
    }]
  }
}

When a patient withdraws consent, the system does not delete the Consent resource — it updates status to inactive and simultaneously records an AuditEvent and Provenance to capture the action. Consent history must remain retrievable for at least the medical record retention period required by the 2023 Law on Examination and Treatment.

5. AuditEvent — logging every access

Law 91/2025 requires the data processor to be able to demonstrate who accessed what data, at what time, and for what purpose. The AuditEvent resource is FHIR's standardized logging mechanism, compatible with IHE ATNA and RFC 3881.

Every read, write, search, or export of clinical data must produce an AuditEvent. The system should write the log synchronously with the transaction (in the same database transaction) so that nothing is lost when the server fails. This log is legal evidence when reporting a breach or responding to a regulator's inquiry.

{
  "resourceType": "AuditEvent",
  "type": {
    "system": "http://dicom.nema.org/resources/ontology/DCM",
    "code": "110100",
    "display": "Application Activity"
  },
  "subtype": [{
    "system": "http://hl7.org/fhir/restful-interaction",
    "code": "read"
  }],
  "action": "R",
  "recorded": "2026-04-30T17:30:00+07:00",
  "outcome": "0",
  "agent": [{
    "type": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/v3-ParticipationType",
        "code": "AUT"
      }]
    },
    "who": { "reference": "Practitioner/bs-tran-van-an" },
    "requestor": true,
    "network": { "address": "10.0.1.42", "type": "2" }
  }],
  "source": {
    "observer": { "reference": "Device/emr-bachmai" },
    "type": [{
      "system": "http://terminology.hl7.org/CodeSystem/security-source-type",
      "code": "4"
    }]
  },
  "entity": [{
    "what": { "reference": "Patient/nguyen-thi-lan-001" },
    "type": {
      "system": "http://terminology.hl7.org/CodeSystem/audit-entity-type",
      "code": "1"
    }
  }]
}

A practical recommendation: separate the AuditEvent store from the primary FHIR server and forward it to the hospital's SIEM (Splunk, ELK, Wazuh). Doing so makes anomaly analysis easier, simplifies retrieval during incident investigations, and helps preserve the immutability of the log.

6. Provenance — chain of custody and digital signatures

Where AuditEvent answers the question "who accessed this," Provenance answers "where did this data come from, who created it, who modified it, and who signed it." The two resources complement each other; they do not substitute for one another.

Under Decree 137/2024/NĐ-CP on electronic transactions, electronic medical records and other important documents must be digitally signed. FHIR Provenance.signature carries the digital signature as base64Binary, most commonly a PKCS#7 detached signature. The example below shows a Provenance for a discharge summary Composition signed by the attending physician:

{
  "resourceType": "Provenance",
  "target": [{ "reference": "Composition/ra-vien-comp-001" }],
  "occurredDateTime": "2026-04-30T17:00:00+07:00",
  "recorded": "2026-04-30T17:00:01+07:00",
  "activity": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/v3-DataOperation",
      "code": "CREATE"
    }]
  },
  "agent": [{
    "type": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
        "code": "author"
      }]
    },
    "who": { "reference": "Practitioner/bs-tran-van-an" },
    "onBehalfOf": { "reference": "Organization/bv-bach-mai" }
  }],
  "signature": [{
    "type": [{
      "system": "urn:iso-astm:E1762-95:2013",
      "code": "1.2.840.10065.1.12.1.1",
      "display": "Author's Signature"
    }],
    "when": "2026-04-30T17:00:00+07:00",
    "who": { "reference": "Practitioner/bs-tran-van-an" },
    "sigFormat": "application/pkcs7-signature",
    "data": "MIIE+wYJKoZIhvcNAQcCoIIE7DCCBOgCAQExDzANBglghkgBZQ..."
  }]
}

A technical note: the data field inside signature must be a valid base64 string (not a placeholder like <base64>). Use a public certification authority (CA) licensed by the Ministry of Information and Communications — Viettel-CA, FPT-CA, BKAV-CA, VNPT-CA — or the government's dedicated CA.

7. meta.security — security classification labels

Every FHIR resource has a meta.security field for tagging sensitivity. This is a declarative mechanism so that the FHIR server and downstream consumers can apply matching access control policies.

"meta": {
  "security": [
    {
      "system": "http://terminology.hl7.org/CodeSystem/v3-Confidentiality",
      "code": "R",
      "display": "Restricted"
    },
    {
      "system": "http://fhir.hl7.org.vn/core/CodeSystem/vn-bvdlcn-cs",
      "code": "sensitive-medical",
      "display": "Sensitive PII — Health"
    }
  ]
}

Recommendation for VN Core: define a dedicated CodeSystem vn-bvdlcn-cs (proposed; not yet in the official corpus) to encode the classifications in Decree 356/2025 — for example sensitive-medical, sensitive-genetic, sensitive-mental-health. When the FHIR server sees this label, it can automatically require stronger authentication (MFA), restrict source IPs, and write more detailed AuditEvent entries.

8. Encryption in transit and at rest

Decree 356/2025 requires processors of sensitive data to apply appropriate technical measures to ensure confidentiality. Two minimum encryption layers:

• Encryption in transit: HTTPS with TLS 1.2 or higher is mandatory (TLS 1.3 recommended); HSTS configured; HTTP fallback prohibited. Internal connections between microservices must also use mTLS or an encrypted service mesh.
• Encryption at rest: full-disk encryption for the database server (LUKS, BitLocker), with additional application-level encryption for highly sensitive fields (national ID number, health insurance card number, HIV results, genetic data). Encryption keys are managed through an HSM or a KMS hosted in Vietnam.

For digital signatures, Decree 137/2024 recognizes the PKCS#7 detached signature widely used for electronic medical records and electronic prescriptions (e-prescriptions). The system should preserve both the signature and the certificate at signing time to support long-term validation (LTV).

9. DPIA — Data Protection Impact Assessment (Form 10)

The Data Protection Impact Assessment (DPIA) is a risk analysis document that the data controller must prepare before launching any processing of sensitive personal data. Decree 356/2025 designates Form 10 as the standard DPIA template.

Hospitals deploying a new EMR, an AI-assisted diagnostic system, or a VNeID integration each need their own DPIA per project. The core fields:

• Purpose, scope, and context of processing.
• Type of personal data and the expected number of data subjects.
• Legal basis: consent, contract, legal obligation, public interest.
• Risk assessment: likelihood and severity of harm if a breach occurs.
• Mitigation measures: technical (encryption, access control) and organizational (training, contracts).
• The DPO's opinion and the plan to notify data subjects.

A DPIA is a living document — review it at least annually and whenever there is a significant change in scale or technology. Store it in the hospital's document management system and provide it to authorities on request.

10. DPO — the Data Protection Officer

The Data Protection Officer (DPO) is a mandatory role for organizations that process sensitive personal data at scale. Provincial public hospitals and above, private hospitals running a full EMR, and HIS/EMR vendors with multiple customers all fall into the mandatory category.

The DPO's main responsibilities:

• Advising the leadership on compliance with Law 91/2025 and Decree 356/2025.
• Supervising data processing, reviewing DPIAs, and assessing vendors.
• Acting as the point of contact with the state authority on personal data protection.
• Receiving complaints from data subjects and coordinating responses.
• Reporting directly to the highest level of leadership, with no conflict of interest from operational departments.

The DPO can be an internal hire or outsourced (DPO-as-a-Service). For small and mid-sized hospitals, a part-time DPO or a shared DPO across hospitals in the same group is feasible — there is precedent for this model in Europe under GDPR.

11. 72-hour breach notification (Form 08)

When a personal data breach is likely to harm national security, public order, or the life, health, honor, dignity, or property of the data subject, the data controller must notify the regulator within 72 hours of detection. Article 23 of Law 91/2025 and Article 28 of Decree 356/2025 set out the specifics; Form 08 is the notification template.

The technical procedure tied to FHIR:

1. Early detection through anomaly monitoring on AuditEvent: after-hours access, unfamiliar IPs, unusually large record volumes.
2. Scope containment: use AuditEvent.entity to enumerate affected Patient resources.
3. Assess whether the harm meets the mandatory notification threshold under Article 23 of Law 91/2025.
4. Prepare the report on Form 08 and submit it to the personal data protection authority (the lead body sits within the Ministry of Public Security per Decree 356/2025).
5. Notify the affected data subjects via the channel registered in Patient.telecom.

12. Cross-border data transfer (Form 09)

Decree 356/2025 requires that any transfer of personal data out of Vietnamese territory be supported by a separate impact assessment dossier on Form 09, in addition to the general DPIA on Form 10. This is critical because many hospitals and vendors use international cloud services.

Real-world situations that require Form 09:

• An EMR deployed on AWS Singapore, GCP Tokyo, or Azure Hong Kong.
• Use of international SaaS (analytics, email, document storage) that touches health data.
• Research collaborations that share a dataset with an overseas institute.
• Cross-border care (telemedicine with physicians abroad).

Recommendation from OmiGroup and EMR partners deploying in Vietnam: prefer a Vietnam-resident architecture — the primary servers stay in-country, and only anonymized or aggregated data leaves the border. Major cloud providers either operate a Vietnam region or have a clear roadmap to one. Law 24/2018 on Cybersecurity and Law 116/2025 (effective 01/07/2026) reinforce in-country storage requirements for information systems considered critical to national security.

13. 30-point compliance checklist for Law 91/2025

A quick audit checklist for CIOs, DPOs, and EMR development teams to self-assess readiness before 01/01/2026. Each item should have either a documented record or a system configuration as evidence.

Identity and access control (1–6)

1. RBAC with standard roles (physician, nurse, technician, pharmacist, BHYT accountant) configured on the FHIR server.
2. SMART on FHIR scopes implemented for client applications.
3. Multi-factor authentication (MFA) required for every account that touches sensitive data.
4. Account lifecycle management: creation, renewal, and deactivation when staff leave.
5. Encryption keys managed through an HSM or KMS hosted in Vietnam.
6. Environment separation: production, staging, and development isolated; real data never lands in staging.

Consent management (7–11)

7. A consent signing UI with digital signature or VNeID confirmation.
8. Versioned Consent storage, time-stamped and signed.
9. Easy withdrawal mechanism for the patient (via VNeID or at the front desk).
10. A Consent check before every data sharing operation outside the organization.
11. AuditEvent recorded for every change to Consent.status.

Data lifecycle (12–16)

12. Retention policy: electronic medical records retained per the Law on Examination and Treatment; AuditEvent retained for at least 5 years.
13. An archival workflow for closed outpatient/inpatient records.
14. Erasure procedure when the legal retention period expires.
15. Anonymization techniques meeting the standard for research datasets.
16. Incident response procedure for data breaches, including periodic tabletop exercises.

DPIA and DPO (17–21)

17. DPIA on Form 10 for the EMR and every major integration (BHYT, VNeID, AI).
18. DPIA review schedule: at least annually and whenever a significant change occurs.
19. A formally appointed DPO reporting directly to leadership.
20. Periodic personal data protection training for every employee with EMR access.
21. Access policies and employment contracts containing clear confidentiality clauses.

Cross-border data transfer (22–25)

22. A data flow map enumerating every point where data leaves Vietnam.
23. A Form 09 dossier for each cross-border data flow.
24. Data processing agreements (DPAs) with every cloud, SaaS, and analytics vendor.
25. Monitoring of access from outside the country, with alerts on anomalies.

Vendor management (26–30)

26. A vendor security assessment process for HIS, EMR, LIS, and RIS vendors before contract signing.
27. Audit rights in vendor contracts that allow the hospital to inspect vendor systems.
28. Sub-processor management: a public list and the hospital's right to object.
29. Vendors required to comply with ISO 27001 or equivalent, with public certification.
30. An exit plan for changing vendors so that data is returned and securely erased.

14. Frequently asked questions

How does Law 91/2025 differ from GDPR?

The two frameworks share much in common: a legal basis requirement for processing, the data subject rights, mandatory DPO and DPIA, and the 72-hour breach notification. The main differences are geographic scope, the penalty calculation (Law 91/2025 uses Vietnam revenue; GDPR uses global revenue), and the in-country data residency requirements that come with the accompanying Cybersecurity Law.

Do small and mid-sized hospitals need a DPO?

Decree 356/2025 requires a DPO whenever sensitive personal data is processed at scale. In practice, any hospital running a full EMR falls into that group. A part-time DPO or a shared DPO across a hospital group is a feasible way to manage cost.

Can we use international cloud for our EMR?

Yes, but you need a Form 09 dossier for each data flow and you must satisfy Vietnam's in-country data storage requirements under the Cybersecurity Law. Practical recommendation: choose a cloud provider with a Vietnam region, or use a hybrid architecture where the primary servers remain in-country.

Is FHIR enough to comply with Law 91/2025?

FHIR provides the necessary technical resources (Consent, AuditEvent, Provenance, meta.security) but it does not replace governance. Compliance is the sum of legal process, contracts, staff training, internal audit, and correct technical implementation. FHIR is the tool; compliance is the outcome of the whole organization.

How long should we retain AuditEvent?

Decree 356/2025 does not yet set a specific minimum retention period for medical access logs. Practical recommendation: at least 5 years (matching the retention of certain core medical records under the Law on Examination and Treatment), preferably 10 years and aligned with the medical record retention cycle. Law 116/2025 (effective 01/07/2026) may add specific requirements — keep watching.

15. Further reading

Other knowledge hub pages directly related to health data protection:

Official legal references

• L-91-2025 — Law 91/2025/QH15: Personal Data Protection (passed 26/06/2025, effective 01/01/2026).
• ND-356-2025 — Decree 356/2025/NĐ-CP: Implementing the PDP Law, Forms 08/09/10 (issued 31/12/2025, effective 01/01/2026).
• L-24-2018 — Law 24/2018/QH14: Cybersecurity (in force).
• L-116-2025 — Law 116/2025/QH15: Cybersecurity Law (amended) (passed 10/12/2025, effective 01/07/2026 — future-effective).
• ND-137-2024 — Decree 137/2024/NĐ-CP: Electronic transactions and digital signatures.

FHIR R4 technical references

• FHIR R4 — Consent Resource
• FHIR R4 — AuditEvent Resource
• FHIR R4 — Provenance Resource
• FHIR R4 — Security & Privacy Module
• FHIR R4 — Signature datatype