Province hospital ↔ commune health station interoperability under the two-tier model

1. Legal context — Resolution 202/2025 and Law 72/2025

Two foundational documents define the new model and should be read separately. Resolution 202/2025/QH15 (issued 12/06/2025, formally in effect from 01/07/2025) reorganized Vietnam's provincial-level units, reducing the country from 63 provinces and centrally-administered cities to 34 units — 28 provinces and 6 cities. Local Government Law 72/2025/QH15 (issued 16/06/2025, effective 01/07/2025) established two tiers of local government: the provincial level and the commune level (which includes wards, communes, and special zones), totaling roughly 3,321 commune-level units after reorganization.

Public healthcare follows the same rhythm. The central level still sits at the top of the pyramid, the provincial level handles regional specialty care, and the commune health station (CHS) is the primary care touchpoint closest to the population. The district level is no longer a standalone administrative tier, so the former district health centers and district hospitals must be reorganized as each locality decides. Some units have become branches of provincial hospitals; others have become regional polyclinics attached to commune health stations; this transitional phase will likely take several quarters. The implication for information systems: organization identifiers and administrative-division codes used across every clinical transaction must support both the legacy and new codes side by side for many quarters.

Consolidated document 06/2026/VBHN-BYT (Ministry of Health) details the functions and responsibilities of commune, ward, and special-zone health stations under the new model. It is the legal basis allowing the CHS to provide consultations, write outpatient prescriptions, refer patients, and conduct post-discharge follow-up — exactly the FHIR scenarios this page describes.

2. A concrete problem through the story of 65-year-old Mrs. Lan

Mrs. Lan, age 65, lives in commune H. On the morning of 30/04/2026 she experiences severe chest pain and goes to the commune health station. The on-call physician at the CHS records a blood pressure of 170/100 mmHg, a heart rate of 110, runs a three-lead ECG, and detects ST elevation in V2-V4. The CHS has only enough capacity for a preliminary diagnosis and initial stabilization — the physician decides to immediately refer her to Province Hospital K., 28 km away. This is the canonical situation that FHIR interoperability must serve.

Four information requirements appear simultaneously. First, the province hospital must see the three-year history of hypertension treatment at the CHS, without having to re-take the history from scratch. Second, the ECG image and vital signs must reach the emergency department before the ambulance arrives — so the cath-lab team can prepare the catheterization room. Third, Mrs. Lan's current medication list must travel with her so the team can avoid drug interactions and decide whether to hold her antiplatelet agents before the procedure. Fourth, when Mrs. Lan is discharged after stenting, Commune Health Station H. must receive a complete discharge summary so they can monitor her blood pressure daily, titrate medications, and schedule a one-week follow-up.

Each requirement above maps to a specific FHIR resource or workflow. The rest of this page walks through each mapping, with sample payloads and implementation notes.

3. FHIR architecture for province ↔ commune interoperability

The architecture below is one reference option: a FHIR server may be operated at provincial level or by a lead hospital, while commune health stations use clients against an agreed CapabilityStatement. The digital channel supports data exchange but does not replace clinical communication, especially in emergencies. The logical diagram is illustrative.

[CHS (PWA, FHIR R4 client)]
       │  POST Bundle ITI-65 (referral)
       ▼
[FHIR R4 server at the Provincial Department / hospital]
       │  Subscription notification (rest-hook)
       ▼
[Province hospital physician app / emergency department]
       │  POST Bundle ITI-65 (discharge summary)
       ▼
[FHIR R4 server (same hub)]
       │  Subscription rest-hook → CHS
       ▼
[CHS PWA: displays discharge summary, schedules follow-up]

A note on versions. VN Core is fixed at FHIR R4 (4.0.1). In R4, real-time push uses the Subscription resource with a search-string criteria and channel.type = rest-hook. The SubscriptionTopic mechanism exists only in R4B/R5, or in R4 via the R5 Subscription Backport IG; if the project wants topic-based subscriptions, it must declare that backport IG as a dependency in sushi-config and validate carefully.

For patient identification, use the national ID card number (CCCD, 12 digits) as the primary identifier under the system http://fhir.hl7.org.vn/core/sid/cccd, with the social health insurance (BHYT) card number as a secondary identifier. For organization identification, use the healthcare facility code issued by Vietnam Social Security (BHXH); for administrative-division codes, use the 34-province and 3,321-commune lists per Decision 19/2025/QĐ-TTg.

4. Scenario 1 — commune health station refers up to the province hospital

The workflow has four steps. Step one: the CHS creates an Encounter for the visit, generates Observation resources for blood pressure, heart rate, and ECG, files a Condition for the suspected myocardial infarction, records a MedicationRequest for the patient's current medications, and aggregates everything into a Composition that represents the referral note. Step two: the CHS packages the Composition along with the related resources into a document Bundle and sends it via the IHE MHD ITI-65 transaction. Step three: the provincial FHIR server receives the Bundle, persists the resources, and pushes a notification to the province hospital via Subscription. Step four: the province hospital system creates a new Encounter and back-references the original referral Composition to maintain a two-way link.

The referral Composition must populate every required FHIR R4 field: status, type, subject, date, author, title. If a section carries both entry and text, then text must be a Narrative object { status, div } with div as valid XHTML — never a plain string.

{
  "resourceType": "Composition",
  "id": "comp-referral-lan-001",
  "status": "final",
  "type": {
    "coding": [
      { "system": "http://loinc.org", "code": "57133-1", "display": "Referral note" }
    ]
  },
  "subject": { "reference": "Patient/lan-001" },
  "encounter": { "reference": "Encounter/tyt-001" },
  "date": "2026-04-30T08:30:00+07:00",
  "author": [{ "reference": "Practitioner/bs-tyt-001" }],
  "title": "Referral note — Commune Health Station H. → Province Hospital K.",
  "section": [
    {
      "title": "Reason for referral",
      "text": {
        "status": "generated",
        "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Acute chest pain, ECG shows ST elevation in V2-V4, suspected myocardial infarction — exceeds the commune health station's capacity.</div>"
      }
    },
    {
      "title": "Past medical history",
      "entry": [{ "reference": "Condition/htn-001" }]
    },
    {
      "title": "Vital signs and diagnostics",
      "entry": [
        { "reference": "Observation/bp-001" },
        { "reference": "Observation/hr-001" },
        { "reference": "Observation/ecg-001" }
      ]
    },
    {
      "title": "Current medications",
      "entry": [{ "reference": "MedicationRequest/mr-001" }]
    }
  ]
}

5. Scenario 2 — province hospital returns the discharge summary to the commune

After Mrs. Lan receives a stent in her right coronary artery and stabilizes, the attending physician at Province Hospital K. produces the discharge summary. The Composition structure is identical to the referral note, but its type switches to LOINC 18842-5 (Discharge summary), and the section list is reorganized into discharge diagnosis, procedures performed, continuing medications, and follow-up instructions for the commune level.

{
  "resourceType": "Composition",
  "id": "comp-discharge-lan-001",
  "status": "final",
  "type": {
    "coding": [
      { "system": "http://loinc.org", "code": "18842-5", "display": "Discharge summary" }
    ]
  },
  "subject": { "reference": "Patient/lan-001" },
  "encounter": { "reference": "Encounter/bv-tinh-001" },
  "date": "2026-05-05T14:00:00+07:00",
  "author": [{ "reference": "Practitioner/bs-bv-tinh-001" }],
  "title": "Discharge summary — Province Hospital K.",
  "section": [
    {
      "title": "Discharge diagnosis",
      "entry": [{ "reference": "Condition/dx-001" }]
    },
    {
      "title": "Procedures performed",
      "entry": [{ "reference": "Procedure/proc-001" }]
    },
    {
      "title": "Continuing medications",
      "entry": [{ "reference": "MedicationRequest/mr-002" }]
    },
    {
      "title": "Follow-up instructions for the commune health station",
      "text": {
        "status": "generated",
        "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Follow-up visit at Commune Health Station H. in 1 week. Monitor blood pressure twice daily. Notify Province Hospital K. if chest pain recurs or systolic BP &gt; 160 mmHg.</div>"
      }
    }
  ]
}

In this illustrative architecture, the province hospital registers the document through ITI-65 if the environment has selected MHD; otherwise, the parties use FHIR interactions defined by their integration contract. The server may notify the CHS through Subscription when its CapabilityStatement and subscription policy allow it. The client retrieves the document after authorization and presents the instructions for staff confirmation; it should not auto-schedule from free narrative unless a tested CarePlan/Task or transformation rule is available.

The follow-up instructions section deliberately uses Narrative rather than entry — because the instructions are free-text Vietnamese prose written by the physician, and forcing them into a CarePlan at the moment of discharge is inappropriate. If the CHS later wants to upgrade to a CarePlan with structured Goal and Activity entries, the same narrative can be transformed into structured data downstream.

6. Resource pattern and LOINC codes

The table below summarizes the FHIR R4 resources required for both directions of interoperability.

7. Packaging with IHE MHD ITI-65 correctly

IHE Mobile access to Health Documents (MHD) defines ITI-65 Provide Document Bundle for a Document Source to register content with a Document Recipient. It is a profiled option, not the default for every FHIR connection. ITI-65 sends POST [base] with a transaction Bundle whose SubmissionSet, DocumentReference, and options must conform to the declared MHD version. A clinical Bundle with type=document is distinct from the transaction Bundle used to register it.

{
  "resourceType": "Bundle",
  "id": "bundle-iti65-lan-001",
  "type": "transaction",
  "meta": {
    "profile": [
      "https://profiles.ihe.net/ITI/MHD/StructureDefinition/IHE.MHD.Comprehensive.ProvideBundle"
    ]
  },
  "entry": [
    {
      "fullUrl": "urn:uuid:list-submissionset-001",
      "resource": {
        "resourceType": "List",
        "status": "current",
        "mode": "working",
        "title": "Referral note — Mrs. Lan",
        "subject": { "reference": "Patient/lan-001" },
        "entry": [
          { "item": { "reference": "urn:uuid:docref-referral-001" } }
        ]
      },
      "request": { "method": "POST", "url": "List" }
    },
    {
      "fullUrl": "urn:uuid:docref-referral-001",
      "resource": {
        "resourceType": "DocumentReference",
        "status": "current",
        "type": {
          "coding": [
            { "system": "http://loinc.org", "code": "57133-1", "display": "Referral note" }
          ]
        },
        "subject": { "reference": "Patient/lan-001" },
        "author": [{ "reference": "Practitioner/bs-tyt-001" }],
        "content": [{
          "attachment": {
            "contentType": "application/fhir+json",
            "url": "Bundle/doc-referral-lan-001"
          }
        }]
      },
      "request": { "method": "POST", "url": "DocumentReference" }
    }
  ]
}

In the payload above, the List serves as the SubmissionSet and DocumentReference describes the registered content. If a PDF or FHIR document Bundle is included, its attachment, Binary, URL, and signature representation must follow the selected MHD profile, the signature policy, and both actors' capabilities. Adding a PDF alone does not establish legal effect or integrity.

If the project does not require strict IHE conformance — for instance, an internal pilot in one province — it is also acceptable to send a document Bundle directly via POST /Bundle or persist it through the /DocumentReference endpoint. Just clearly document in the system specification that this is a FHIR-native approach rather than IHE MHD ITI-65, to avoid confusion when partners run an audit.

8. Deploying at the commune health station under real-world constraints

Staffing, connectivity, local IT support, and devices vary materially across commune health stations. Design must begin with a survey of facility groups instead of assuming one national staffing or hardware profile.

Four decisions require evaluation. First, offline storage and sync queues are appropriate only when device encryption, conflict handling, revocation, and the threat model are designed. Second, centralized versus distributed hosting follows operational responsibility, availability, and data boundaries. Third, authentication must use mechanisms authorized by the participating organizations; VNeID integration should be claimed only where an API and agreement exist for that scope. Fourth, fallback channels must not expose sensitive clinical data through SMS or messaging platforms without a lawful basis, data minimization, and suitable security controls.

Hardware scope should follow a survey of each commune health station: a PWA workstation, printing, and measurement devices belong in scope only when the workflow requires them and their export interfaces have been tested. Cost depends on the installed base, procurement, connectivity, and support, so one budget figure cannot apply to every commune. Training should likewise be planned from usability tests and task-completion measures; clinical users need not learn FHIR internals, while integration and operations teams must understand the applicable data contract.

9. Implementation lessons and risks

As of May 2026, no public pilot has fully implemented the province ↔ commune interoperability pattern on FHIR R4. The lessons in this section are extrapolated from comparable EMR and HIE projects in Vietnam, combined with Omi HealthTech's international implementation experience. The page will be updated when a real pilot is available.

• Train on the UI, not on FHIR. CHS physicians do not need to know what a Composition is; they need a three-step interface: enter symptoms, choose a referral reason, click send. All FHIR resources are generated on the back end.
• Subscriptions need recovery behavior. Depending on SLA and risk, use retry, durable queues, dead-letter handling, reconciliation, or polling; emergency cases still follow an approved clinical communication channel.
• ECG attachments follow device capability. Use DICOM Waveform where the device and PACS support it. For PDF or other formats, DocumentReference must describe the content type, source, and integrity accurately.
• Migrating former district-center data. Bulk Data $export is one option when the source supports it; a custom ETL may be necessary. Provenance records only the source events actually tracked and required by policy.
• Cross-tier patient matching. A patient seen at a different province using their CCCD must resolve to the correct Patient resource in their BHYT-registration province — this requires either a $match operation or an inter-provincial Patient Master Index.

The biggest risk is governance, not technology: who is responsible for operating the provincial FHIR server, who pays for the CHS's bandwidth, who runs the periodic training. These are questions that the Provincial Department of Health, hub hospitals, and implementation advisors need to settle in the pilot design.

10. Frequently asked questions

Does the commune health station need its own FHIR server?

No. The recommended model centralizes the FHIR server at the Provincial Department of Health or at a lead provincial hospital. The CHS is a client calling REST APIs. This approach reduces operational and maintenance costs and prevents data fragmentation.

What if the CHS's internet is unstable?

An offline-first PWA persists transactions temporarily in IndexedDB and pushes them to the server when connectivity returns. For emergency cases like Mrs. Lan's, an SMS or voice-call fallback remains essential — FHIR does not replace direct phone communication between the CHS physician and the province hospital's emergency department.

How do we migrate data when former district health centers are merged?

Bulk Data $export is one option when the source advertises the applicable IG/version; otherwise a custom ETL may be needed. Provenance records tracked origin, but does not guarantee lossless migration. Inventory, backups, reconciliation rules, discrepancy reports, and acceptance tests are required before retiring the source system.

How does BHYT cross-tier reimbursement work in the new model?

Benefit and reimbursement rules must be determined from the BHYT Law and current implementing instruments for the applicable beneficiary, service, and professional-care level; this architecture page is not a substitute for Vietnam Social Security operational guidance. Current KCB output data follows the Decision 130/QĐ-BYT, 4750/QĐ-BYT, and 3176/QĐ-BYT chain. Mapping a complete XML submission to FHIR requires a field- and structure-level transformation specification with test fixtures; ConceptMap is for relationships between code systems/value sets, not an end-to-end document transformation.

Do we need to use SubscriptionTopic?

Not required for R4. Traditional FHIR R4 Subscription (criteria + rest-hook) is sufficient for most cases. If the engineering team wants topic-based subscriptions, they must declare a dependency on the R5 Subscription Backport IG in sushi-config and validate carefully — do not invent a custom schema.

11. Legal and technical references

Vietnamese legal documents

• Resolution 202/2025/QH15 dated 12/06/2025 — Reorganization of provincial-level administrative units, effective 01/07/2025.
• Law 72/2025/QH15 dated 16/06/2025 — Local Government Law, two-tier model (province + commune).
• Circular 13/2025/TT-BYT dated 06/06/2025 — Electronic medical records, effective 21/07/2025; hospitals had a 30/09/2025 deadline and other medical examination and treatment facilities have a 31/12/2026 deadline.
• Consolidated Document 06/2026/VBHN-BYT — Functions and responsibilities of commune, ward, and special-zone health stations.
• Decision 19/2025/QĐ-TTg dated 25/06/2025 — Administrative-division codes for the 34 reorganized provinces.
• Decree 188/2025/NĐ-CP — Implementing the BHYT Law under the new model.
• Decree 137/2024/NĐ-CP — Electronic transactions and digital signatures for EMR.

International standards and technical specs

• FHIR R4 Composition resource — required fields and Narrative structure.
• FHIR R4 Bundle resource — type document and transaction.
• FHIR R4 Subscription — criteria, channel rest-hook.
• R5 Subscription Backport IG — for using SubscriptionTopic on R4.
• IHE ITI-65 Provide Document Bundle — the standard transaction for sending clinical documents.
• LOINC 57133-1 — Referral note.
• LOINC 18842-5 — Discharge summary note.
• VN Core IG — canonical http://fhir.hl7.org.vn/core/.

12. Further reading