FHIR and Vietnam's AI Law 134/2025 in healthcare

1. Context — why Vietnam passed an AI Law

The 15th National Assembly enacted the Artificial Intelligence Law 134/2025/QH15 on 10/12/2025, with effect from 01/03/2026. Decree 142/2026/NĐ-CP, effective 01/05/2026, specifies classification, notification, and conformity-assessment procedures. This page reflects the legal corpus reviewed as of 18/07/2026.

Scope and duties depend on the actor's role — developer, provider, deployer, or user — and the AI activity conducted in Vietnam. A foreign provider must also assess the contact-point or local-presence requirements that Article 14 applies to certain high-risk systems supplied in Vietnam.

Law 134/2025 does not displace sector-specific law. Depending on the product and activity, an implementation may also need to address the Law on Examination and Treatment 2023, Circular 13/2025/TT-BYT on electronic medical records, medical-device rules, the Personal Data Protection Law 91/2025/QH15, and Decree 356/2025/NĐ-CP.

2. The three AI risk tiers under Law 134/2025

Article 9 of Law 134/2025/QH15 defines three risk tiers. A provider classifies its system before use; only medium- and high-risk systems require a classification dossier and notification to the Ministry of Science and Technology under Article 10.

Decree 142/2026/NĐ-CP provides detailed criteria. If the tier remains uncertain, a provider may request classification guidance from the Ministry of Science and Technology on the basis of a technical dossier; the Law does not prescribe an automatic one-tier escalation.

3. How to assess healthcare AI risk

The label “healthcare AI” is not enough to determine a tier. Decree 142/2026/NĐ-CP calls for assessment of the particular system, intended purpose, automation, impact, scale, and the ability of a person to oversee and intervene.

Decision 33/2026/QĐ-TTg issues the high-risk list, but it was not yet effective on this page's review date (effective 15/08/2026). Its health section lists AI-assisted surgery and surgical robots subject to stated conditions concerning integration, automation, and confirmation by health personnel; it does not classify all diagnostic AI or CDS as high-risk.

The following use cases require assessment of their actual configuration and intended purpose; their names alone do not determine a tier:

• Imaging diagnostic support on X-ray, CT, MRI, and ultrasound.
• Disease screening — cancer, cardiovascular, diabetic retinopathy.
• Treatment-plan recommendations, dose calculation, and drug-interaction checking.
• Emergency triage and prediction of inpatient deterioration.
• Clinical decision support (CDS) that influences laboratory orders or medication choices.
• Chatbots delivering general health information to the public.
• AI suggesting appointment slots, room scheduling, or other non-clinical operational optimization.
• Speech recognition for chart entry.

Under Decree 142/2026/NĐ-CP, a system that only collects, processes, standardizes, classifies, translates, or improves data quality without directly creating a decision affecting lawful rights and interests may be excluded from a high-risk-list proposal. Substantive human oversight that permits independent review, intervention, rejection, or change before a decision takes effect is also material. A change in purpose or integration that creates new risk triggers review and possible reclassification.

4. Five control groups for high-risk AI

The groups below summarize Article 14 of Law 134/2025/QH15 and Articles 15–16 of Decree 142/2026/NĐ-CP. Each organization must identify whether it is acting as provider or deployer and also assess sector-specific law.

4.1 Risk and data governance

A provider must maintain risk management appropriate to intended purpose and deployment scope; training, test, and evaluation data must have the quality, suitability, and representativeness necessary to limit data-related risk. Decree 142 permits technical material prepared under international standards where it satisfies the required dossier, but does not require disclosure of all raw training data or model parameters.

4.2 Context-specific transparency and accountability

Information duties depend on purpose, context, and risk. For high-risk systems, providers and deployers make available functional descriptions, operating information, limitations, and risk warnings; accountability to a competent authority applies on request. The Law does not require every output to carry a particular explanation technique such as feature importance or a heatmap.

4.3 Human oversight and intervention

A high-risk system must be designed and operated with human oversight and intervention appropriate to its risk. This may involve prior approval, stop controls, independent review, or rejection mechanisms; the Law does not prescribe a FHIR Resource or one workflow for every healthcare use case.

4.4 Safety and security

Technical and organizational measures must be proportionate to identified risks. Version controls, adversarial testing, or drift monitoring may be appropriate controls, but the selection is system-specific. Where personal data is processed, Law 91/2025 and Decree 356/2025 apply according to the actor's role and processing scope.

4.5 Technical records and activity logs

A high-risk-system provider must prepare, update, and retain technical records and activity logs to the extent necessary for conformity assessment and post-market inspection. This does not mean that every inference must become a FHIR AuditEvent or use a fixed medical-record retention period; logging policy must follow the control purpose, sector rules, and applicable retention schedule.

5. How FHIR may support AI governance

FHIR R4 (4.0.1) can exchange clinical data and represent selected decision-support artifacts. It does not natively cover the full model lifecycle, conformity-assessment dossier, government system register, or risk-management system; those records may remain outside FHIR.

End-to-end integration diagram:

[FHIR Server (EMR / VN Core)]
        │
        │ Bulk Data $export → NDJSON (de-identified)
        ↓
[Training Pipeline]            ← diverse, structured, audited data
        │
        │ Trained model + governance records outside FHIR
        ↓
[AI Inference Service]
        │
        │ CDS Hook trigger (patient-view, order-sign…)
        ↓
[FHIR Server] ← may write clinical resources + suitable Provenance
        │
        ↓
[Clinician UI] reads → use-case-appropriate review/approval workflow

Structural standardization can make data easier to inspect and compare, but it does not make data complete, representative, or unbiased. Provenance may record data lineage; AuditEvent may record selected security or privacy events; clinical Resources may record outputs and assessments. Compliance depends on the overall configuration, operating process, and evidence, not on the presence of these Resources alone.

6. Illustrative FHIR patterns for healthcare AI

FHIR R4 has no AI-specific Resource, and HL7 has not specified a universal pattern that combines Device, GuidanceResponse, Provenance, AuditEvent, and ClinicalImpression. The examples below are possible choices only when their semantics fit; a real implementation must define them in its IG or profiles and must not treat them as legal requirements.

6.1 Device — one option for software represented as a device

Device may fit where AI software is managed as a device or technical actor in the clinical system. The identifier issued by the national AI portal under Decree 142/2026 is a system identifier following classification notice, not necessarily a “model registration.” The namespace below is illustrative and is not a VN Core canonical.

{
  "resourceType": "Device",
  "id": "ai-cardio-v2",
  "identifier": [{
    "system": "https://example.org/fhir/sid/ai-system",
    "value": "cardio-risk-v2"
  }],
  "type": {
    "coding": [{
      "system": "https://example.org/fhir/CodeSystem/ai-system-type",
      "code": "clinical-decision-support",
      "display": "Clinical decision support AI"
    }]
  },
  "manufacturer": "Example Health AI Vendor",
  "modelNumber": "CardioRiskNet-v2.1",
  "version": [{ "value": "2.1.0" }]
}

6.2 GuidanceResponse — where output is a clinical-reasoning response

GuidanceResponse is one option when the output is genuinely the response from evaluating a guidance or clinical-reasoning module. It is not a generic container for every AI inference. In R4, module[x] is required; outputParameters is a Reference(Parameters); and result references a CarePlan or RequestGroup. For other use cases, Observation, RiskAssessment, DiagnosticReport, or a non-FHIR artifact may fit better.

{
  "resourceType": "GuidanceResponse",
  "id": "gr-001",
  "status": "success",
  "moduleCanonical": "https://example.org/fhir/PlanDefinition/cardio-risk-v2",
  "subject": { "reference": "Patient/vn-001" },
  "encounter": { "reference": "Encounter/enc-001" },
  "occurrenceDateTime": "2026-04-30T14:00:00+07:00",
  "performer": { "reference": "Device/ai-cardio-v2" },
  "outputParameters": { "reference": "Parameters/gr-001-out" },
  "result": { "reference": "RequestGroup/rg-cardio-001" }
}

In this example, Parameters/gr-001-out holds output values and RequestGroup groups recommendations. The structure of explanatory content must be defined by the system's profile or Implementation Guide; base FHIR does not define a general AI-explanation structure.

6.3 Provenance — Resource lineage

Provenance may record the person or agent that produced a Resource, related source entities, and recording time. The recorded field is required in R4. Its presence alone does not establish a complete chain of controls or compliance.

{
  "resourceType": "Provenance",
  "target": [{ "reference": "GuidanceResponse/gr-001" }],
  "occurredDateTime": "2026-04-30T14:00:00+07:00",
  "recorded": "2026-04-30T14:00:05+07:00",
  "agent": [{
    "type": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
        "code": "performer"
      }]
    },
    "who": { "reference": "Device/ai-cardio-v2" }
  }],
  "entity": [
    { "role": "source", "what": { "reference": "Observation/ecg-001" } },
    { "role": "source", "what": { "reference": "Observation/troponin-001" } }
  ]
}

6.4 AuditEvent — security and privacy events

AuditEvent represents auditable security, privacy, or operational events. An inference call should become an AuditEvent only where the implementation's audit policy and event model define it that way; many technical logs may remain outside FHIR. An AuditEvent does not by itself satisfy Law 134/2025 logging duties or personal-data obligations.

6.5 ClinicalImpression — where a clinical assessment fits

ClinicalImpression may fit where a clinician actually performs an assessment matching that Resource's semantics. The AI Law does not require a clinician to create a ClinicalImpression as evidence of human oversight; depending on the workflow, review may be represented in Task, ServiceRequest, Observation, a signature, order approval, or another log system.

{
  "resourceType": "ClinicalImpression",
  "status": "completed",
  "subject": { "reference": "Patient/vn-001" },
  "encounter": { "reference": "Encounter/enc-001" },
  "date": "2026-04-30T14:15:00+07:00",
  "assessor": { "reference": "Practitioner/bs-001" },
  "supportingInfo": [{ "reference": "GuidanceResponse/gr-001" }],
  "summary": "AI flagged high cardiovascular risk. Clinician concurs based on ECG and elevated troponin. Ordered 24h Holter and a repeat CK-MB at 6 hours."
}

6.6 meta.tag for AI-generated data

An implementation may use local meta.tag values to help downstream systems identify AI-generated data or pending-review status. The codes below are examples and are not currently published by VN Core; an implementer must govern its own namespace, definitions, and code lifecycle.

"meta": {
  "tag": [
    {
      "system": "https://example.org/fhir/CodeSystem/ai-data-tag",
      "code": "AI-GENERATED",
      "display": "Data generated by an AI system"
    },
    {
      "system": "https://example.org/fhir/CodeSystem/ai-data-tag",
      "code": "PENDING-CLINICIAN-REVIEW",
      "display": "Awaiting clinician review"
    }
  ]
}

7. CDS Hooks — the real-time integration pattern

CDS Hooks is an HL7 specification that lets an EMR call decision-support services at defined hooks such as patient-view or order-sign. It is one integration option; each system must declare supported hooks, authentication, context data, and result-recording behavior.

[Clinician opens patient chart in the EMR]
        ↓
[EMR] -- POST /cds-services/cardio-risk + FHIR context --> [AI Service]
        ↓
        ←------- CDS Card (text + suggestion + explanation link) --------
        ↓
[EMR UI] displays the card; clinician accepts, dismisses, or asks a question

Where the relevant transparency duties apply, a CDS Card may show purpose, limitations, warnings, and a link to suitable technical information. Acceptance of a card does not require the EMR to write GuidanceResponse, Provenance, and AuditEvent together; the Resources recorded depend on workflow design and audit policy.

8. Bulk Data API for training data

FHIR Bulk Data Access is a separate Implementation Guide for $export and NDJSON; a server supports it only when implemented and declared. Exported data may be used for analytics or training where purpose, authorization, and safeguards are valid. Basic request shape:

GET [base]/Patient/$export?_type=Patient,Observation,Condition,DiagnosticReport
Accept: application/fhir+json
Prefer: respond-async

→ 202 Accepted
  Content-Location: https://server/.../status/abc

→ Poll the status URL → 200 OK + list of NDJSON URLs

Before training, the organization must establish lawful basis, purpose, data minimization, access controls, and security measures. De-identification may take data outside personal-data scope where the resulting data can no longer identify or help identify a person; encoded or tokenized data that can still be linked back remains personal data. Under Article 21 of Law 91/2025, controllers and controller-processors prepare an impact-assessment file, while processors do so under their agreement; clause 6 provides an exception for competent state authorities.

9. Bias assessment — supported, not solved, by FHIR

Fairness, lack of bias, and non-discrimination are principles in Law 134/2025. Model performance may vary across facilities, devices, periods, and population groups; the magnitude must be measured with suitable evaluation data rather than inferred from the geographic origin of the training set.

VN Core may help represent some stratification variables consistently, including age, sex, ethnicity, geography, and clinical terminology. Local terminology does not ensure representative sampling, accurate labels, adequate sample size, complete data, or freedom from selection bias. Sensitive variables also require a valid purpose and lawful basis.

An evaluation plan should predefine clinically meaningful groups, assess data quality and missingness, and report measures such as discrimination, calibration, and error with uncertainty. FHIR can exchange variables and results; statistical methods and bias-mitigation controls are outside the FHIR specification.

10. Interplay with Law 91/2025 and Decree 356/2025

Where a healthcare AI system processes personal data, AI Law 134/2025 applies according to the system's tier, while Law 91/2025 and Decree 356/2025 apply according to the actor and processing activity. Data de-identified within the meaning of the Law must be distinguished from data that is merely encoded or separated from direct identifiers but remains linkable.

• Training data containing health information is sensitive personal data under Article 4 of Decree 356/2025. Consent must clearly cover the AI-training purpose, unless another lawful basis under Law 91/2025 applies.
• Each inference on patient data is a personal-data processing activity and must remain within the established purpose, lawful basis, and safeguards; the law does not require each inference to create a FHIR AuditEvent.
• The processing impact-assessment file in Form 10 applies to controllers and controller-processors under Article 21 of Law 91/2025; a processor prepares and retains one under its agreement. Clause 6 provides an exception for competent state authorities.
• The personal data protection unit or officer (DPO) participates in producing, retaining, and submitting the DPIA file under Decree 356/2025; this role does not displace the data controller's legal responsibility.
• The 72-hour period in Article 23 of Law 91/2025 applies where a responsible actor detects a breach that may cause one of the listed types of harm and must notify the specialist authority. The separate 72-hour notice to data subjects in Article 29 of Decree 356/2025 has the narrower scope of location or biometric data.

If AI is integrated into an electronic medical record system within Circular 13/2025/TT-BYT's scope, the deployer must also assess the applicable record, identity, retention, security, and clinical-workflow requirements.

11. Frequently asked questions

Does running a cardiovascular-screening AI on a foreign cloud violate Law 91/2025?

Cloud location alone is not enough to decide. If the activity is a cross-border personal-data transfer under Article 20 of Law 91/2025, the transferring party must have a proper processing basis, apply safeguards, and prepare and submit the Form 09 dossier within the statutory period unless an exemption in clause 6 applies. The processing impact-assessment file is determined separately by role under Article 21. Data that is encoded or separated from direct identifiers but remains linkable is still personal data.

Can AI sign a Composition (clinical report) on its own?

Law 134/2025 requires human oversight and intervention capability for high-risk systems, but it does not directly set the cardinality or actor type of Composition.attester. Whether AI may draft a report, who may sign or attest it, and which signature is valid must follow healthcare, electronic-transaction, professional-workflow, and profile rules. In FHIR R4, Composition.attester is 0..* and base FHIR permits several actor types; an IG may constrain this where justified.

Which agency must AI models be registered with?

The Law does not call this “model registration.” Under Article 14 of Decree 142/2026/NĐ-CP, a provider of a medium- or high-risk system notifies the Ministry of Science and Technology of the classification result through the national AI portal before use; the portal records the notice and assigns a system identifier. If the portal has not been officially launched, Article 46 permits an electronic information system, online public service, or another channel announced by the Ministry.

Does FHIR have a native Resource for AI?

FHIR R4 has no Resource specifically named for AI, and HL7 has not specified one Resource combination for every AI system. Device, GuidanceResponse, Observation, RiskAssessment, Provenance, AuditEvent, or ClinicalImpression may be selected according to semantics. The implementation IG must define profiles, links, capabilities, and the records that remain outside FHIR.

Do patients have the right to ask for an explanation of an AI result?

Two rights must be distinguished. Law 134/2025 requires high-risk providers and deployers to make available functional descriptions, operating information, and risk warnings; accountability to a competent authority applies on request and within the statutory scope. Law 91/2025 gives a data subject information rights concerning personal-data processing, but does not itself create a right to a particular explanation technique for every AI output. Any use-case-specific right of access or explanation also depends on sector law and need not be delivered through GuidanceResponse.

12. References and further reading

Vietnamese legal documents

• Artificial Intelligence Law 134/2025/QH15 — passed 10/12/2025, effective 01/03/2026 (VN Core code: L-134-2025).
• Decree 142/2026/NĐ-CP — implements the Artificial Intelligence Law, effective 01/05/2026.
• Decision 33/2026/QĐ-TTg — high-risk AI system list, effective 15/08/2026 (not yet effective on the 18/07/2026 review date).
• Personal Data Protection Law 91/2025/QH15 — effective 01/01/2026 (L-91-2025).
• Decree 356/2025/NĐ-CP implementing the Personal Data Protection Law — effective 01/01/2026 (ND-356-2025).
• Circular 13/2025/TT-BYT on electronic medical records — effective 21/07/2025 (TT-13-2025).
• Law on Examination and Treatment 2023 — currently in force.
• Decision 4469/QĐ-BYT issuing the Vietnamese version of the International Classification of Diseases ICD-10 — 28/10/2020.

The full list of referenced legal documents is maintained in the VN Core legal corpus.

HL7/FHIR specifications

• FHIR R4 (4.0.1) Specification — the standard version for VN Core.
• GuidanceResponse Resource (R4).
• Provenance Resource (R4).
• Clinical Reasoning Module.
• CDS Hooks Specification.
• FHIR Bulk Data Access (Flat FHIR).

Further reading in the knowledge hub

Glossary

• Risk class — the risk tier of an AI system under Law 134/2025 (high, medium, low).
• Model card — a document describing a model, purpose, scope, limits, data, and evaluation results; what must be public depends on the applicable duty.
• CDS Hooks — an HL7 specification that lets the EMR call clinical decision-support services in real time.
• Explainability — the ability to provide information that helps the recipient understand an output or system operation within the appropriate technical and legal scope.
• Human oversight — human monitoring and intervention proportionate to risk; it does not always imply one fixed approval workflow.
• DPIA — Data Protection Impact Assessment, per Form 10 of Decree 356/2025.
• DPO — the personal data protection unit or officer under Decree 356/2025.