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 that data anonymized so the subject can no longer be identified is no longer personal data. Before using a dataset for research, AI training, or epidemiological reporting, a hospital must still evidence the method and re-identification risk, check sectoral and contractual duties, and reflect the conclusion in the impact dossier where the processing activity is in scope; a dataset is not freely shareable merely because it is labelled “anonymized.”

3. Data-subject right groups — a technical mapping

Article 4 of Law 91/2025 states right groups in six lettered points (a, b, c, d, đ, e); one point may include several actions, such as viewing/rectifying or requesting provision/erasure/restriction/objecting. The table is an implementation aid, not a one-to-one legal mapping, and no single FHIR interaction completes a statutory right by itself.

4. Consent — representing a consent decision

The FHIR R4 Consent resource can represent a structured directive: subject, scope, organization, policy, period, and permit/deny provisions. It can serve as evidence or policy-engine input when designed that way; it neither proves that consent satisfies Article 9 of Law 91/2025 nor enforces access control by itself.

SMART on FHIR/OAuth scopes describe what an access token may request from an API. A token, scope, login, or OAuth “Allow” action is not the same as legal consent, which must be voluntary, informed, and specific to each purpose. The access decision point should combine the processing basis, purpose, applicable policy, any relevant Consent directive, client identity, and client permissions.

The example assumes consent is an applicable basis or condition for the particular flow; it does not imply that every treatment activity can rely only on consent. Patient Nguyễn Thị Lan (12-digit national ID) consents to a central 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: Decision 1551/QĐ-BYT (31/05/2026) established the synchronization programme; Decision 2062/QĐ-BYT (07/07/2026) replaced Annexes 01–03 and added Annexes 04–05, so the two decisions must be read together. Citizen-facing VNeID Health read/display, withdrawal, and app-side authorization flows remain separate integration contracts. Consent flows described here are therefore reference architectures beyond the published synchronization envelope.

{
  "resourceType": "Consent",
  "status": "active",
  "scope": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/consentscope",
      "code": "patient-privacy"
    }]
  },
  "category": [{
    "coding": [{
      "system": "http://fhir.hl7.org.vn/core/CodeSystem/vn-consent-category-cs",
      "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": {
    "period": { "start": "2026-04-30", "end": "2031-04-30" },
    "provision": [{
      "type": "permit",
      "purpose": [{
        "system": "http://fhir.hl7.org.vn/core/CodeSystem/vn-consent-purpose-cs",
        "code": "TREAT"
      }]
    }]
  }
}

When a subject submits a withdrawal request, the system may set the corresponding directive to Consent.status=inactive. The change needs auditable evidence appropriate to the deployment event model; use FHIR AuditEvent or Provenance only where the architecture assigns the proper purpose to each Resource. Consent history follows the retention schedule established in the organization's legal and records-governance analysis; this page does not set a universal duration.

5. AuditEvent — defining audit scope

Accountability requires records sufficient to reconstruct events within the scope defined by legal analysis, the threat model, and access-control policy. AuditEvent is FHIR's Resource for representing security and privacy events; using it does not replace an immutable log store, monitoring, or incident response.

The organization should define an auditable-event matrix covering, as applicable, login, record access, modification, export, permission changes, and administrative actions. Logging needs reliable delivery, correlation identifiers, integrity controls, and failure-path tests; putting the log in the same data transaction does not inherently prevent loss. Evidentiary value also depends on integrity, chain of custody, and operating procedures.

{
  "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.

Where a workflow requires electronic attestation, FHIR Provenance.signature can carry signature data as base64Binary, for example PKCS#7/CMS or another agreed format. Placing a signature in a Resource does not itself establish legal validity: the system must also validate the certificate, signing time, signed content, and applicable signature policy. The example below illustrates one technical option for a discharge-summary Composition.

{
  "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 trust-service or digital-signature certification provider licensed under Vietnamese law, or the government's dedicated CA when the system is in the public-sector trust domain.

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 technical measures appropriate to the processing and its risks. A project may use the following controls as a security baseline and then tailor them to its threat model, data classification, and deployment architecture; the legislation does not prescribe one identical configuration for every system:

• Encryption in transit: a project baseline should use HTTPS with a TLS version still supported by organizational security policy (commonly at least TLS 1.2), prefer TLS 1.3, apply HSTS to appropriate web surfaces, and prevent downgrade to HTTP. For internal links, choose mTLS, an encrypted service mesh, or an equivalent control where the risk assessment and trust boundary require it; the law does not mandate one technology for every microservice.
• Encryption at rest: select disk, database, or application-level encryption according to the threat model and field sensitivity. HSM/KMS use, key location, and in-country storage requirements follow the system classification, contract, and applicable legal duties rather than applying automatically to every deployment.

For personal data in cloud computing specifically, Article 12(4) of Decree 356/2025 requires encryption at rest and in transit together with strict access controls. That cloud-context requirement does not prescribe the same cipher suite or key-management product for every system.

Decree 137/2024 does not prescribe PKCS#7/CMS, JOSE, detached mode, or an LTV profile for electronic medical records or e-prescriptions. PKCS#7/CMS in the Provenance example above is only one technical option. The signature format, exact signed content, certificate, timestamp, and retained evidence must be agreed under the applicable electronic-transaction/signature law, sectoral rules, trust framework, and integration contract.

9. Personal-data processing impact dossier (Form 10)

Article 21 of Law 91/2025 distinguishes roles: a controller and controller-processor prepare, retain, and file a dossier within 60 days from first processing; a processor prepares and retains one under its agreement with the controller. Article 19(1) and (4) of Decree 356/2025 additionally provide for the listed roles to prepare/retain from the start of processing and file an original under the 60-day procedure. Competent state authorities have the Article 21(6) exemption. Form 10 is a report within the dossier, not the whole dossier, and a new dossier is not required for every API by default.

A new EMR, AI-assisted diagnosis, or VNeID integration must be compared with the existing dossier: update it when a purpose, processing party, or other change in Article 20 of Decree 356/2025 occurs; use a separate dossier only where the processing activity and accountability boundary are genuinely separate. Core fields include:

• Identity and contact details of the processing parties and any data-protection function/personnel or service provider.
• Purposes, data types, processing activities, and the data-flow diagram.
• Consent-capture approach where applicable and the retention, erasure, and destruction policy.
• Security measures, system-design diagram, and applied data-protection standards.
• Compliance-assessment result; impact, risk, potential harm, and mitigation/elimination measures.
• Copies of processing contracts/agreements and related policies, procedures, forms, and dossier materials.

The dossier must remain available for inspection. Under Article 20 of Decree 356/2025, a new purpose or change in processing parties is updated on the six-month cycle measured from the first filing; listed changes to the organization, data-protection service provider, or registered business/service must be updated immediately within 10 days. An organization may add risk-based internal review, but it does not replace those statutory update points.

10. Data-protection function/personnel (DPO)

“DPO” is familiar shorthand; the Vietnamese statutory terms are personal-data-protection function/personnel and organizations or individuals providing personal-data-protection services. Article 33(2) of Law 91/2025 requires an agency or organization to appoint a qualified function/person or engage a qualified service provider. The Law does not limit this duty by hospital class or patient count.

Article 13 of Decree 356/2025 requires a written internal appointment and sets qualification conditions. Article 14 assigns the principal tasks:

• Developing or advising on compliance policies, procedures, rules, and forms.
• Organizing or participating in data-subject rights fulfilment and periodic compliance assessment.
• Preparing processing/cross-border impact dossiers and receiving/reporting breaches within the assigned scope.
• Training personnel and implementing technical measures, standards/regulations, and incident-response plans.

Articles 15–16 permit qualified individual or organizational service providers, and Article 16(4) permits combining internal appointment with outsourced services. GDPR requirements such as direct reporting to the highest level, absolute independence, or its conflict-of-interest model should not be presented as Vietnamese statutory rules without a separate legal basis.

11. Conditional 72-hour breach notification (Form 08)

When a detected breach may harm national defence, national security, public order/safety, or the life, health, honor, dignity, or property of a data subject, a controller, controller-processor, or third party must notify the specialist authority no later than 72 hours after detection. A processor that detects the breach must promptly notify its controller or controller-processor. Article 23 of Law 91/2025 sets the threshold and roles; Article 28 of Decree 356/2025 sets the content and Form 08.

An incident workflow may use FHIR data where the deployment recorded enough context:

1. Early detection through anomaly monitoring on AuditEvent: after-hours access, unfamiliar IPs, unusually large record volumes.
2. Scope with inventories, application/database/SIEM logs, and the incident record; use AuditEvent.entity only where the event model captured complete references and reconcile it with other sources.
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. Assess the separate data-subject notice duty. Article 29 of Decree 356/2025 requires notice within 72 hours for breaches of location or biometric data; use a verified channel under the incident process, not Patient.telecom as a mandatory or sole source.

12. Cross-border data transfer (Form 09)

Article 20(1) of Law 91/2025 defines three cross-border groups: moving data stored in Vietnam to an overseas storage system; transferring it from Vietnam to a foreign organization or person; or using an offshore platform to process data collected in Vietnam. If a flow is in scope and no exemption applies, the dossier containing the Form 09 report is filed within 60 days of the first transfer. The assessment is made once for the period of operation and updated under Article 22 of the Law and Article 20 of Decree 356/2025 — not once per request or endpoint.

Article 20(6) exempts impact assessment for transfers by a competent state authority, storage of an organization's own employee data on cloud services, and a data subject transferring their own data. Article 17(3) of Decree 356/2025 adds cases including lawful journalism/media, data lawfully made public, genuine emergencies protecting life/health/property or fulfilling a legal duty, cross-border workforce administration, and listed contract/transport/payment procedures. Record the exact provision for each exemption; the employee-cloud exemption does not extend to patient records. Truly anonymized data may fall outside personal-data scope, but encryption or pseudonymization alone does not create an exemption.

Real-world situations that require a scoping review to determine whether Form 09 is triggered:

• 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).

A Vietnam-resident architecture may reduce some transfer paths, but an in-country region does not eliminate cross-border processing where remote administration, telemetry, backup, support, or a sub-processor remains overseas. Verify the provider's region/data-residency documentation, contract, and actual data-flow diagram; only genuinely anonymized data may fall outside personal-data scope. Any in-country storage duty under cybersecurity law must be determined from the specific system's scope and classification.

13. 30-point implementation review checklist

This is a project baseline for CIOs, DPOs, and EMR teams reviewing a design. The 30 controls are not all statutory duties that apply identically to every organization; confirm each item against the processing basis, role, risk, and system scope, then retain evidence of the decision or configuration.

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. Apply MFA according to risk, prioritizing privileged accounts, remote access, and high-impact actions; document exceptions and compensating controls.
4. Account lifecycle management: creation, renewal, and deactivation when staff leave.
5. Manage the key lifecycle through a KMS/HSM or equivalent risk-based control; determine key location from system classification and applicable duties.
6. Environment separation: production, staging, and development isolated; real data never lands in staging.

Consent management (7–11)

7. Where consent is the applicable basis or condition, provide a capture experience that meets information, expression, and evidence requirements; use digital signatures or VNeID only where that channel is authorized and integrated.
8. When FHIR Consent is used, retain the necessary timestamp, scope, subject, policy, and version history; signature requirements depend on the transaction and applicable policy.
9. Provide a withdrawal mechanism through an operating, verifiable channel; do not assume a VNeID API exists for this use case.
10. Evaluate processing basis and authorization policy before sharing; check Consent when consent is the applicable basis or condition.
11. Record an auditable event for consent-status changes; use FHIR AuditEvent where the deployment event model specifies it.

Data lifecycle (12–16)

12. Retention policy: electronic medical records follow applicable record-retention rules; the project sets AuditEvent retention from legal analysis, threat model, and records policy rather than assuming one universal duration.
13. An archival workflow for closed outpatient/inpatient records.
14. Erasure procedure when the legal retention period expires.
15. Assess re-identification risk and apply proportionate anonymization or pseudonymization before sharing research datasets; pseudonymized data is not automatically anonymous.
16. Incident response procedure for data breaches, including periodic tabletop exercises.

Impact dossiers and data-protection personnel (17–21)

17. Maintain the Form 10 processing-impact dossier for in-scope activity; reflect BHYT, VNeID, and AI integrations through an update or a separate dossier according to the processing boundary.
18. Track the six-month update cycle for new purposes/parties and the 10-day deadline for changes listed in Article 20 of Decree 356/2025.
19. Appoint a qualified data-protection function/person in writing or contract with a qualified service provider; retain qualification evidence and disclose provider/personnel information where the rules require it.
20. Periodic personal-data protection training for personnel whose roles process or access the EMR, calibrated to their risks and responsibilities.
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. For in-scope transfer activity, file the Form 09 dossier within 60 days of the first transfer and update it on change; document any out-of-scope flow or exemption and the governing provision.
24. Use a DPA or suitable processing terms when a vendor actually processes personal data and the parties' relationship requires them; do not assume every vendor contract needs the same DPA.
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. Manage sub-processors according to contract and processing role; determine disclosure and objection mechanisms where law or agreement requires them.
29. Require assurance evidence proportionate to vendor risk; a current ISO/IEC 27001 certificate is one option, not a universal duty to publish 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 address similar themes such as processing basis, data-subject rights, data-protection staffing, impact assessment, and breach notification. Their triggers, exemptions, deadlines, and penalty rules are not identical; compare the applicable provisions rather than importing the GDPR model wholesale into Vietnam.

Do small and mid-sized hospitals need a DPO?

They need data-protection capability: Article 33(2) of Law 91/2025 requires an agency or organization to appoint a qualified function/person or engage a qualified service provider. A small hospital is not exempt merely because of size; it may use an internal, outsourced, or combined model under Articles 15–16 of Decree 356/2025 if it meets the applicable conditions and procedure.

Can we use international cloud for our EMR?

Potentially, but an offshore cloud processing patient data collected in Vietnam will commonly fall within Article 20(1) of Law 91/2025. Map the flows and assess the exemptions, Form 09 dossier, contracts, and any in-country storage duty applicable to the specific system; the exemption for storing an organization's employee data in cloud services does not cover patient records. A Vietnam region or hybrid architecture may reduce risk, but is not a universal legal conclusion for every EMR.

Is FHIR enough to comply with Law 91/2025?

FHIR offers relevant representations (Consent, AuditEvent, Provenance, and meta.security) but does not replace governance. Compliance combines legal process, contracts, staff training, internal audit, and correct technical implementation; no Resource creates compliance by itself.

How long should we retain AuditEvent?

Decree 356/2025 sets no universal retention period for every medical access log. The five-year minimum in Article 29 applies to the incident record for a location/biometric-data breach, measured from remediation, not to every AuditEvent. Set log retention from applicable cybersecurity/sectoral law, system classification, evidentiary purpose, threat model, and records policy; do not infer five or ten years solely from medical-record retention.

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: Detailed implementation of the PDP Law, Forms 08/09/10 (issued 31/12/2025, effective 01/01/2026).
• L-24-2018 — Law 24/2018/QH14: Cybersecurity (superseded by Law 116/2025/QH15 since 01/07/2026).
• L-116-2025 — Law 116/2025/QH15: Cybersecurity Law (amended) (passed 10/12/2025, in force since 01/07/2026).
• ND-137-2024 — Decree 137/2024/NĐ-CP: State-agency electronic transactions and information systems supporting electronic transactions.

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