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 recommended deployment places the FHIR server at the Provincial Department of Health or at a lead provincial hospital, where it serves as the data hub. The commune health station is a thin client calling REST APIs. The province hospital physician's mobile app reads directly from the FHIR server, eliminating the need for a dedicated phone line for every referral. The logical diagram is shown below.

[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>"
      }
    }
  ]
}

The province hospital pushes this Bundle via the same IHE MHD ITI-65 transaction back to the FHIR server. The provincial server then triggers the Subscription that the CHS previously registered, with criteria roughly along the lines of DocumentReference?type=18842-5&subject:Patient.address-state=...&subject:Patient.address-city=.... The PWA at the CHS receives the webhook, pulls the Bundle for offline storage, displays it for the nurse caring for Mrs. Lan, and auto-schedules the follow-up visit from the instructions field.

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 the ITI-65 Provide Document Bundle transaction as the standard mechanism for transmitting clinical documents between two facilities. One important point to remember: ITI-65 is not a POST /Bundle with type=document. ITI-65 is POST [base] with a transaction Bundle that contains at least one List acting as a SubmissionSet, at least one DocumentReference, and (optionally) a Binary carrying the content or a referenced FHIR Document Bundle.

{
  "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 listing the submitted DocumentReferences; the DocumentReference points to the document Bundle that holds the referral Composition (shown in section 4) on the provincial server. If the CHS wants to attach a digitally-signed PDF as legal evidence under Decree 137/2024/NĐ-CP (electronic transactions and digital signatures), add a Binary entry to this Bundle and have the DocumentReference point to both the JSON Bundle and the PDF.

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

A typical commune health station has 1-2 physicians and 2-3 nurses, an unstable internet connection in mountainous and island regions, no on-site IT staff, and hardware that is usually a low-spec desktop or tablet. The solution must be designed around that reality.

Four design principles. First, use a Progressive Web App with offline-first capability, persisting data locally via IndexedDB and pushing it to the FHIR server through a sync queue when connectivity returns. Second, host the FHIR server centrally at the provincial level and keep the CHS as a thin client — do not install a FHIR server at the commune to avoid operational overhead. Third, authenticate physicians via VNeID (Vietnam's national digital identification app) or a digital certificate issued by a licensed certification authority, instead of requiring separate passwords for every hospital system. Fourth, use SMS or Zalo as a fallback channel for critical Subscription notifications when the internet drops.

On hardware: a typical CHS needs one computer running the PWA, a dot-matrix or laser printer for prescriptions, an electronic blood-pressure monitor with a USB or Bluetooth port, and a three-lead ECG with the ability to export an XML or PDF file. The total hardware upgrade cost stays under VND 30 million per CHS, which fits within the budget of the commune-level budget or socialized funding sources. The bigger investment is training: physicians and nurses need 4-8 weeks to become comfortable with the new UI — they do not need to learn FHIR.

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 OmiGroup's international 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 a fallback. When the connection is flaky, rest-hook subscriptions can fail silently. There must be a periodic poll mechanism and an SMS alert for emergency cases.
• ECG attachments via DocumentReference + lightweight DICOM. The original ECG file should be attached as a DICOM Waveform to preserve metadata, alongside a rendered PDF so the province physician can review it quickly on a phone.
• Migrating data from former district health centers. When a former district health center is merged or split, the legacy EMR must be bulk-exported via the $export operation and ETLed into the provincial FHIR server, with a Provenance resource recording the source and the migration timestamp.
• 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 Departments of Health and OmiGroup must answer together in an advisory capacity.

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?

Use FHIR Bulk Data $export by patient group, then ETL into the provincial FHIR server. Each migrated resource carries a Provenance entry recording the original district health center, its legacy facility code, and the migration timestamp. That way, visit history is preserved when the organizational structure changes.

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

Per Decree 188/2025/NĐ-CP and Decree 233/2025/NĐ-CP, the BHYT reimbursement rules have been adjusted to fit the two-tier model. The technical pipeline still uses the XML 4210 format as amended by Decision 3176/QĐ-BYT, until a FHIR-native replacement is issued. A ConceptMap between Composition and XML 4210 should be developed in parallel.

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; healthcare facilities must complete EMR adoption by 31/12/2026.
• 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