FHIR for clinicians: understanding data standards without writing code

1. Do clinicians need to know FHIR?

Short answer: no, it isn't required. Clinicians don't need to read technical specifications, learn programming, or memorize the names of data resources. The EMR software handles all of that.

Three concepts are useful in clinical practice:

• What FHIR is. It's a set of conventions that lets healthcare software exchange data in a standardized way — much like how banks agreed on shared account numbers and transaction codes.
• Codes do not replace all clinical narrative. Select a code from the current catalog and retain necessary context such as severity, timing, site, or certainty. Structured codes support BHYT checks and machine processing, but do not by themselves guarantee reimbursement or correct AI interpretation.
• What the personal health record on VNeID is. Patients will ask about it. The standard answer is in section 7 below.

Think of FHIR like electricity. A clinician doesn't need to know how current flows through the wires to switch on the exam light. But knowing which outlet is for the ventilator and which is for the suction pump prevents accidents.

2. If you do understand FHIR, what do you gain?

When source systems, receiving systems, and governance workflows all support it, FHIR can enable the following capabilities:

1. Display structured transfer data. Conditions, allergies, medications, and laboratory results from the sending organization can appear in the same chart when both systems are connected and their mappings are compatible. The clinician still confirms identity, source, timing, and completeness.
2. Compare outside laboratory results in one interface. Trend charts may be appropriate when LOINC/CLS codes, specimen, method, UCUM units, and reference ranges are compatible; results should not be aggregated merely because their display names match.
3. Provide structured inputs to decision support. Standard codes can help a system identify fields consistently, but AI performance also depends on data quality, the model, the target population, and local validation.
4. Exchange electronically signed documents. A prescription or discharge summary may enter an electronic-signature workflow when the system meets applicable requirements for identity, authority, integrity, and retention. FHIR alone does not establish the legal effect of a signature.
5. Support social health insurance record checks. Structured data and dual coding can support validation rules before export. Any reduction in errors must be measured on real data and also depends on reimbursement rules, mappings, and other required fields.

3. A day in the life with a FHIR-ready system

This story features a fictional patient: Mrs. Nguyễn Thị Lan, 65 years old, from Hải Phòng, holds a social health insurance (BHYT) card, with a history of hypertension. She has been transferred from a provincial hospital to a Grade-I hospital in Hà Nội. The scenario below describes a workday for Dr. Minh in the Internal Medicine department. It illustrates capabilities a system may provide, not default behaviour for every FHIR implementation; each step depends on connectivity, authorization, data quality, and local configuration.

This scenario is useful only if the interface fits the clinical workflow. Usability testing should measure task-completion time, code-selection errors, cognitive load, and rework; adopting FHIR does not by itself demonstrate a reduction in workload.

4. Five implementation areas to evaluate

FHIR does not prescribe the interface elements below. Clinical and design teams should evaluate them in the real workflow:

1. Select codes while retaining clinical narrative. The interface may offer the Vietnam ICD-10 catalog and keyword search while preserving necessary text and context. Result ranking, labels, and task time should be tested with representative users and cases.
2. Display personal health record data when authorized. History, allergies, and medications may appear with provenance. Clinicians still confirm the information with the patient and should not treat the display as complete without knowing the sync scope.
3. Present decision support appropriately. If the system includes allergy alerts, interaction checks, or AI suggestions, the interface should expose priority, source data, dismiss or escalation actions, and suitable explanatory information. The layout requires usability testing.
4. Integrate the electronic-signature workflow. Prescriptions and discharge summaries may be signed using a method accepted by the approved workflow. Legal effect and permitted form depend on all applicable legal, business, and technical requirements; using FHIR alone is insufficient to validate a signature.
5. Patients receive notifications via VNeID. When lab results, prescriptions, or follow-up schedules are ready, the patient may receive a notification if the provider has an authorized integration. The effect on call volume should be measured.

5. The clinician's role in terminology standardization

Software can suggest codes, but an authorized user must confirm them in the clinical and organizational context. A code should not stand alone: retain the description, certainty, timing, and source. Three commonly encountered code systems are:

Vietnam ICD-10 — primary disease coding

Used for primary diagnosis and comorbidities in current BHYT output fields. The Ministry of Health published this code set under Decision 4469/QĐ-BYT (28/10/2020), with COVID-19 codes added under Decision 98/QĐ-BYT (14/01/2022).

Rule of thumb: when the catalog has a more specific child code, use it. For example, "Gastritis, unspecified" maps to K29.7, which is more precise than the parent K29. But do not add your own suffix to a code if the catalog doesn't list it. The code I10 for essential hypertension is already a complete leaf — there is no I10.0 in ICD-10. Use only codes present in the catalog version currently in force; a user must still review interface suggestions before confirming them.

Vietnam SNOMED CT — detailed clinical description

The Ministry of Health is rolling out Vietnam SNOMED CT in waves: anatomical structure (Decision 2427/QĐ-BYT), morphologic abnormality (Decision 2493/QĐ-BYT), and allergies plus clinical findings (Decision 2805/QĐ-BYT). SNOMED CT can express detail that ICD-10 is not designed to store directly, including specific allergens, anatomical sites, severity, and non-disease findings (such as "atypical chest pain").

LOINC — laboratory test codes

In many workflows, LOINC mappings are governed in the LIS or integration layer rather than entered by clinicians. When comparing results across laboratories, clinicians still need to consider specimen, method, units, and reference ranges, not only the LOINC code.

Dual coding and context. A diagnosis may carry SNOMED CT for clinical expression and Vietnam ICD-10 for reporting; a test may carry LOINC together with a CLS or LIS code. Both codings must refer to the same validated concept, while text preserves the clinician's or source system's expression. Two codes are not necessarily equivalent merely because they appear in the same CodeableConcept.

6. AI assistants — what every clinician must know

AI may be designed for screening, alerts, or information prioritization. Benefits and risks must be evaluated for the intended use, target population, input data, and local workflow; coded data alone does not establish safety.

Five things every clinician must know

1. AI is a suggestion, not the final decision. The final decision belongs to the clinician.
2. Override and escalation must be governed. The system should record actions and reasons in accordance with the provider's clinical-governance policy.
3. AI can be wrong. False positives and false negatives occur. Clinicians must still follow the applicable professional standard and clinical pathway.
4. A suggestion needs information for evaluation. The interface should expose relevant inputs, model version, uncertainty, and known limitations; the appropriate explanation depends on model type and risk.
5. Legal duties depend on classification and intended use. Vietnam's AI Law (Law 134/2025/QH15) uses risk-based governance. The provider must determine the applicable duties and human oversight for each system rather than assuming all medical AI has one classification.

Three things clinicians should not do

• Trust AI absolutely — skipping clinical examination because "AI says it's fine."
• Use AI output without checking inputs, the intended-use statement, and the escalation pathway.
• Accept or dismiss suggestions reflexively; apply a consistent clinical review process.

7. When patients ask about their personal health record

Patients increasingly ask things like: "Doctor, I opened VNeID and there's a Health / Personal Health Record section — what is that? Does the hospital send my data up there?"

Clinicians do not need to explain the technical architecture. The wording below is only an example and must be adapted to the provider's policy, integrations, and data-protection contact:

"That's your personal health record. Which data the hospital sends, when it is sent, and who may access it depend on the connection programme, lawful basis, and authorization currently in place. You can check the information in VNeID and contact the hospital's data-protection point of contact if it appears incomplete or incorrect. Under the Personal Data Protection Law (Law 91/2025/QH15), you have the right to know, to consent or withdraw consent, and to demand data protection. In some specific cases, medical data may still be processed under the law — for example during emergencies when the information is needed to save a life, or when required by competent authorities."

That answer balances the patient's rights against the legitimate exceptions. Saying "only people you consent to can read it" would be incorrect — Law 91/2025 (Article 19) permits processing personal data without consent in specific situations such as life-saving emergencies, statutory obligations, or requests from competent state authorities.

If a patient wants more detail, direct them to the data-protection contact or patient support function published by the provider.

8. Frequently asked questions

Do clinicians have to take a FHIR course?

No. Clinicians only need to use the new EMR software properly. Mastering the FHIR specification is the job of the hospital's technical team and the software vendor.

Doesn't picking an ICD-10 code each time slow me down?

This cannot be concluded without testing the interface and workflow. The provider should measure task-completion time, wrong-code selections, rework, and cognitive load with representative users. Keyword search, favorites, and dual coding can help, but structured codes do not by themselves eliminate BHYT errors, make AI accurate, or remove statistical bias.

Can AI replace a clinician?

AI should be used only within an intended use and workflow approved by the provider. Decision, oversight, and accountability roles must be defined for the system type, sector-specific law, and local policy; not every case can be reduced to one rule.

I don't trust AI — am I forced to use it?

Acceptance, rejection, and escalation should be defined for each alert type. Clinicians should inspect the source data and relevant rationale before acting and should not assume a suggestion is correct or incorrect merely because AI generated it.

Does BHYT accept SNOMED CT diagnoses?

Current BHYT output specifications include fields that use Vietnam ICD-10. SNOMED CT may be retained in parallel for clinical detail, but it does not replace an ICD-10 field when the receiving schema and rules require one. Check the specification version in force.

When does my hospital have to have an EMR?

Under Circular 13/2025/TT-BYT (effective 21/07/2025), hospitals must complete EMR implementation by 30/09/2025; other healthcare facilities by 31/12/2026. Each provider's scope and compliance status should be checked against the regulation, implementation guidance, and the competent authority.

9. Further reading

Related pages in the HL7 Vietnam knowledge hub: