If you're building or customizing a CRM for a healthcare client in India, "medical centre" clients are a category that trips up a lot of generic implementations — and it's worth understanding why before you scope the project.
The Three Tiers of Healthcare Facilities (and their CRM needs)
TierStructureCRM complexitySingle clinic1-2 doctors, 1 calendarLow — basic scheduling + remindersMedical centreMultiple departments, outpatient only, no bedsMedium — multi-calendar, cross-department data modelHospitalInpatient, ER, wardsHigh — full HIS, bed/ward management
Most off-the-shelf CRM products are built for tier 1 or tier 3. Tier 2 — the medical centre — gets handled by either over-scaling a clinic tool (department silos, no cross-department data) or under-scaling a hospital system (paying for ward/bed modules that go unused).
The Core Data Model Problem
The thing that actually breaks in tier 1 tools when applied to tier 2 clients is the patient-to-department relationship. A single-clinic CRM typically models:
Patient -> Appointments -> Doctor
A medical centre needs:
Patient -> Appointments -> Department -> Doctor
|
-> Internal Referrals -> Other Department
Without that referral edge in the data model, internal referrals between departments (dermatology → dietitian, for example) are invisible to reporting — even if they're happening constantly in practice. This is usually the single biggest gap when a clinic-tier CRM gets stretched to cover a medical centre.
Communication Layer: Centralize, Don't Fragment
A related but separate issue: each department often ends up with its own outbound communication channel (separate WhatsApp Business numbers, for instance), because that's the path of least resistance when departments are onboarded one at a time.
If you're architecting this from scratch, route all patient-facing messaging (confirmations, reminders, follow-ups) through one WhatsApp Business API integration, with department as a field on the message/template — not a separate integration per department. This keeps the patient experience consistent and keeps your messaging costs/quotas manageable as departments scale.
Reporting: Two Levels, Not One
Build reporting views at both the department level (for department heads) and the centre level (for administrators/owners) from the start. Retrofitting a centre-wide rollup after department-level reporting has already been built independently per department is more painful than it sounds — mostly due to inconsistent status/taxonomy across departments that nobody standardized upfront.
Where This Matters for Scoping
If a client describes themselves as a "medical centre," "polyclinic," or "multi-specialty centre" — ask early whether they currently have separate systems/numbers per department. If yes, the migration/data-consolidation work is often a bigger chunk of the project than the CRM build itself.
I wrote a more business-oriented (less architecture-y) version of this with a vendor evaluation checklist here, if useful for client-facing conversations: CRM Systems for Medical Centres: Choosing the Right Fit
Curious if others building in this space have run into the same tier-2 gap — feel free to share war stories in the comments.
Top comments (0)