ERPNext for Bangladesh Hospitals: Dhaka Care Medical & Hospital Ltd.

🏥 Hospital Profile: Dhaka Care Medical & Hospital Ltd.

The hospital runs both inpatient and outpatient care alongside its own diagnostic lab and pharmacy, which is exactly the kind of multi-department, multi-revenue-stream organization ERPNext is well suited to model once its core modules are combined with a couple of domain-specific custom modules. Its departments, for the purpose of this case study:

Every section below assumes this department list and reuses the same Part 1 implementation methodology — the base-module-first, custom-module-only-when-necessary discipline this series is built around.

🚶 The Patient Journey

Before mapping anything to ERPNext DocTypes, it helps to see the journey as a patient actually experiences it — one continuous path that later gets split across a custom clinical module, a custom lab module, and several base ERPNext modules:

Each stop on that journey touches a different record. Laid out as relationships instead of a sequence, the same journey looks like this:

Everything in that second layer ultimately references the same Patient record — this is the "reference, don't duplicate" master-data pattern the base course establishes in Part 1's master/transaction table split, applied to a hospital instead of a warehouse.

🧩 Hospital Operations on Base ERPNext

Most of what keeps a hospital's business running — not its clinical work, its business — is already covered by ERPNext's standard modules, exactly as introduced in Part 1 of the base course and detailed per-module in Part 3. Nothing here needs a custom DocType:

What's not in that table — appointments, consultations, admissions, lab requests — is precisely what the two custom modules below exist to cover, following the same Configure → Customize → Custom Module → Integration decision ladder Part 1 establishes.

🩺 Custom Module A: Hospital Clinical Management

Nothing in base ERPNext models a patient, an appointment slot, or a bed — so this is the "need new DocTypes" branch of the customization decision tree. The clinical module's DocTypes:

The relationships branch in two directions from Patient, so they're shown as two focused diagrams rather than forcing one diagram to show both branches at once:

Outpatient branch

Inpatient branch

A compact field-level view of the Patient DocType only, in the same field-level training table shape Part 1 uses throughout that article for training end users field by field:

🧫 Custom Module B: Laboratory & Diagnostic Management

Concretely: Sample Type (blood, urine, swab, CSF, …) and Test Parameter (e.g. hemoglobin, WBC count, platelet count within one CBC Test) are the two additions that make the pattern hospital-grade — a single physical Sample can carry multiple Tests, and a single Test can carry multiple Test Parameters, each with its own reference range and Result row.

🔗 Custom Module ↔ ERPNext Core

Both custom modules exist to model things ERPNext doesn't know about natively — but every one of their key records ultimately drives a base ERPNext DocType, exactly the three-level integration pattern (UI, Data, Business Logic) from Part 1's custom module case study:

💊 Pharmacy

Once a Prescription reaches the Pharmacy counter, nothing about dispensing a medicine is hospital-specific anymore — it's a standard ERPNext Stock + Selling problem: every Medicine is an Item (typically inside an Item Group like "Pharmaceuticals"), tracked by Batch and expiry, held in a pharmacy Warehouse, and moved by whatever document issues it — each such movement writing a Stock Ledger Entry. Where Serial or Batch tracking, pricing, and Sales Invoice generation actually happen mechanically is covered in depth already, rather than re-derived here — see Part 3's Stock module walkthrough and Part 5's Stock Ledger Entry generation section.

The only hospital-specific piece is the front end of that chain: a Prescription (custom DocType) needs to resolve its medicine lines into ordinary Items before the pharmacy's stock/billing documents can pick them up — the same Link-field integration pattern used throughout this module.

🔬 Laboratory Workflow

Who can act at which step is a permissions question, not a workflow-state question alone — both matter together, the same layered idea from Part 1's permission flow:

🧾 Hospital Billing

A single hospital visit routinely bills across several departments at once — this is exactly the "many sources converge on one settlement layer" pattern from Part 1's module interconnection diagram, applied to billing specifically:

The mechanism that makes this possible without a custom billing engine: every billable custom-module concept — a Lab Service, a bed-day, a procedure — is mapped to an ordinary ERPNext Item, so it can appear as one line on a standard Sales Invoice alongside consultation fees and dispensed medicine. The hospital never needs its own invoice format; it needs its custom records to resolve to Items before the Sales Invoice is raised.

Why the Invoice and the Payment stay two separate records even here — a multi-service hospital bill is exactly the case where partial payments, insurance reimbursement delays, and installment settlement make that separation matter most — is the underlying accounting theory covered in full in Invoice vs Payment: The Core Concept and its Allocation model.

🇧🇩 Bangladesh VAT/Tax for Hospital Services

Conceptually — not as guaranteed exact ERPNext behavior — a hospital's tax setup rests on a few pieces: a BIN (Business Identification Number) and VAT registration status recorded against the Company; a decision on VAT-inclusive vs VAT-exclusive pricing per price list; one or more Tax Categories (e.g. standard service, exempt service, corporate/insurance-billed service) that a Sales Invoice's customer or item resolves to; and Tax Templates that attach the actual percentage and the target VAT Payable–type account. Whatever the resolved rate, the tax line ultimately posts through the same GL Entry mechanism as any other accounting impact — see Part 5's GL Entry generation section for how that posting mechanically happens.

🔐 Hospital Role/Permission Matrix

📊 Hospital Dashboards

Management

• Daily Revenue
• Patient Count
• OPD Count
• IPD Occupancy
• Pharmacy Sales
• Lab Revenue
• Outstanding
• Expenses

Lab Manager

• Pending Samples
• Testing Queue
• Pending Verification
• Critical Results
• Turnaround Time

Pharmacy

• Low Stock
• Expired Medicine
• Daily Sales
• Fast Moving Items

🔁 End-to-End Hospital Workflow

Reading that chain against what actually implements each step: Payment and Accounting/GL are pure base ERPNext — no custom code touches them. Appointment, Consultation, Admission, and Lab Request/Result are Custom Module territory — they don't exist in ERPNext core and are exactly what the two custom modules in this article were built to cover. Everything else in the chain (Prescription resolving to Pharmacy stock, Billing resolving to a Sales Invoice) is the seam where the custom modules hand off into base ERPNext via ordinary Link fields.

🧯 Real-World Troubleshooting Scenarios

Scenario 1: Lab result cannot be approved

Scenario 2: Medicine stock is incorrect

Scenario 3: Patient invoice has wrong tax

🛡️ Hospital Data Security

As stated throughout this series: this article uses only fictional patient and company data, and does not represent any real Bangladesh hospital's actual data, systems, or security posture.

✅ Hospital UAT Checklist

Before go-live, walk every one of the following end to end on the actual configured site — not in isolation:

• Patient registration
• Appointment scheduling and rescheduling
• Lab: request through report (including an abnormal/flagged result path)
• Pharmacy: prescription through stock issue
• Billing: a multi-service invoice covering consultation, lab, and medicine together
• Payment: full, partial, and insurance/corporate settlement paths
• Reports: management, lab manager, and pharmacy dashboards render with real data

🗺️ What's Next

This is Part 2 of the 4-part ERPNext Bangladesh Implementation Case Study — a companion series to the 9-part base course, walking one fictional Bangladeshi organization's ERPNext rollout end to end.

Part 4 in particular is where the Clinical Management and Laboratory & Diagnostic modules sketched here stop being a design exercise and become an actual custom Frappe app: repository structure, CI, staging vs production sites, and a deployment pipeline — following the same custom-app architecture the base course establishes in Part 7.