Dr. Sharma ran the diagnostic. He now knows what is standing between his Mohali hospital and its next patient.
Three gaps: awareness among GPs in Sector 70 and 71 who have not yet been introduced to the hospital; a belief gap among GPs who are aware but have received no structured communication about his outcomes; and a reach gap for the CGHS patient segment, where the empanelment application has not yet been filed.
Now he knows what to fix. The question is how to fix it in a way that does not require his daily attention once it is set up.
This distinction — between doing something once and building a system that does it continuously — is perhaps the most under-discussed problem in the management of small / early stage clinics and hospitals in India.
A critical distinction
Most practitioners in Dr. Sharma’s position — having identified the gap — move immediately to action. They may call five GPs the same week. They may send one batch of discharge summaries. They may ask a staff member to create a Practo profile. And two months later, when the referrals have not meaningfully moved, they may conclude that the action did not work.
This is not the conclusion they should be drawing. Because the action, done once, was never likely to work.
The question is not whether the action was right. The question is whether a system was built to do it continuously.
A system is not a task done once. It is a defined process, owned by someone, triggered by an event, producing a specific output, at a set cadence, with a mechanism for knowing whether it ran.
- The GP who receives one discharge summary from a hospital will not change his referral pattern.
- The GP who receives a structured clinical communication after every procedure begins to perceive the hospital as a functioning, accountable institution.
- The GP who receives a structured clinical communication after every procedure and a follow-up note at six weeks — for six months in a row — now trusts the hospital enough to confidently refer patients.
This trust takes months to form. It is the cumulative product of a system running repeatedly, not of a single well-intentioned action.
This is the fundamental error in small clinics and private hospitals alike — trying to build patient volume by treating business growth or operations activities as a series of one-time events rather than as systems with a defined operating rhythm. Each event is evaluated on its own merits. And when it does or does not immediately produce results, it is intensified or abandoned — neither of which is the right response.
The right response is to build the system, confirm it is running the way it was designed, and then ask the right question.
The right question, for the first several months, is not “are referrals going up?” It is: “is the system running?”
The trust system
For Dr. Sharma, the most consequential gap — and the one with the longest gestation period — is the belief gap.
GPs in his catchment are aware of his personal reputation from Sector 22. They are not aware of the hospital’s clinical record. And for a referring GP, those are different things. A surgeon’s personal reputation is abstract. A documented clinical record — here is the procedure, here is the discharge summary, here is the six-week outcome — is evidence.
Building that evidence, and making it visible to the referral network, requires two distinct systems running in parallel.
- The first is GP-facing: a structured discharge summary and follow-up communication process that runs after every procedure.
- The second is patient-facing: a visible online presence — surgeon profiles with procedure volumes, a managed listing on Practo and JustDial, and a proactive Google review programme for patients who have had good outcomes.
Neither system produces results immediately. Yet both are essential. And both require the same discipline: build them correctly, confirm they are running, and resist the temptation to evaluate results before the system has had enough cycles to produce them.
What a system actually requires
A system that works is not a policy or a checklist stapled to the wall. It has seven components, each of which must be present for the system to be self-sustaining.
- A named owner. Not a department. A person. The discharge summary process does not belong to “the clinical team.” It belongs to a specific individual — the medical coordinator, the head nurse on the surgical floor, whoever is designated — who is accountable for it running on time after every case. Without a single named owner, a system degrades quickly under the pressure of daily clinical operations.
- Defined steps. Knowing who is responsible and when to start is not enough. The system owner must know exactly what to do, in what sequence, each time the cycle runs. For the discharge summary process, this means: retrieve the OT notes, complete the summary template, confirm the referring GP’s contact details in the log, send the summary within 48 hours, and record the send date. Without a defined sequence, the output varies by person and by day — which means the system produces inconsistent results even when it is, technically, running.
- A defined trigger. What event starts each cycle of the system? For the discharge summary process, the trigger is patient discharge. The moment a patient leaves the ward after a joint replacement, the clock starts. The trigger must be unambiguous and observable; if there is any doubt about when the cycle starts, the cycle will often not start at all.
- A defined output. What, specifically, does each cycle produce? For the GP communication system, it is a structured document — not a generic letter, but a clinical summary that includes the procedure performed, the intraoperative findings, the post-operative status, and the follow-up plan. The output should be templated for consistency and brief enough that a GP will actually read it.
- A cadence. How often does the system run? The discharge summary goes out within 48 hours of patient discharge. The follow-up note goes out at six weeks. The medical liaison visits each GP in the catchment once a month. Cadence makes the system predictable — to the team running it and to the GPs receiving its output.
- A tracking mechanism. How do you know the system ran? This does not need to be sophisticated. A shared log — a column in a spreadsheet, a note in a patient management system — that records when each discharge summary was sent and to whom. A system that cannot be audited will quietly stop running when no one is watching.
- A feedback loop. How does the system learn? The medical liaison who visits GPs should be bringing back information: which GPs are receptive, what questions they ask, what objections they raise. That information should feed back into the system — adjusting the discharge summary template, updating the liaison’s talking points, identifying GPs who are ready to begin referring. Without a feedback loop, the system runs but does not improve.
All of this must be written into a standard operating procedure (SOP). The SOP is what ensures everyone on the team is working from the same playbook, regardless of who is on shift or how long they have been in the role.
Crucially, it is the SOP that gets evaluated and improved over time. As the system encounters the real world and real-world evidence accumulates, the SOP is updated to reflect what works better. The system improves not through instinct or memory, but through a document that carries the learning forward.
The right question to ask
Once the system is built and running, most hospital administrators make the same mistake: they evaluate it too early.
In the first month of a structured discharge summary programme, referrals will not increase. In the second month, they may not increase. The GPs receiving structured clinical communications for the first time are recalibrating their perception of the hospital — and that process takes time. Trust, in a referral network, is accumulated in small increments over repeated interactions. There is no shortcut.
The question for the first three to four months of a new trust-building system must be: is the system running the way we designed it? For instance
- Is every discharge summary going out within 48 hours?
- Is the follow-up note reaching the referring GP at six weeks?
- Is the liaison visiting each catchment GP once a month, with a structured message and clinical data to share?
- Is the Practo profile being maintained, and is someone responding to the enquiries that come through it?
These are the questions that matter in the early period.
The result — GP referrals going up, online enquiries increasing — will come. But it will come as a consequence of the system running consistently, not as a substitute for that consistency.
Checking the result too early is not just premature; it is actively counterproductive, because it leads to interventions and modifications before the system has had the cycles to show what it can actually do.
The Pareto problem: why leaders get stuck
There is one more pattern I have observed in clinics and small private hospitals that have begun to take their systems seriously.
Consider the first few months of building a medical liaison programme. Initially, the progress is rapid. The GPs who were previously unaware of the hospital become aware. A few begin sending referrals. The discharge summary process is running. The Practo profile is active. The team is energised. The leader can see progress every week.
And then, around month four or five, the pace slows. Not because the system is failing — the system is doing exactly what it was designed to do. But the early gains were the easy gains: the GPs most open to a new referral relationship, the patients most likely to leave a Google review, the enquiries that converted without friction. The next increment of progress requires more effort for less visible return. And leaders, accustomed to the pace of month two, begin to feel that something is broken.
This is the Pareto Principle applied to system efficiency:
- Roughly 70 percent of a system’s efficiency is achieved in roughly 30 percent of the time it takes to reach full optimisation.
- The remaining 70 percent of the time is spent closing the final 30 percent of the gap.
The early progress is fast because the easiest improvements are available first. The later progress is slow because it requires precision — identifying the specific GPs who have not yet converted, figuring out why, adjusting the liaison’s approach, improving the discharge summary template.
The right response to this slowdown is not to invest more energy in the same system. The right response is to direct that energy toward another system that has not yet been built.
Most hospital leaders do the opposite. They intensify. They add a second medical liaison. They start calling GPs who have not responded. They revise the discharge summary template repeatedly. The system that was running reasonably well absorbs more and more of the leadership’s attention — and the other systems that needed to be built sit untouched.
I call this “the tunnel vision of leadership”.
The tunnel vision that follows
When a leader develops tunnel vision on one system — focusing all their energy on maximising it due to early promise — the team typically does as well.
- The medical coordinator who runs the discharge summary programme is spending more time on format and follow-up cadence than on any other operational priority.
- The medical liaison is visiting the same five GPs repeatedly instead of expanding to new ones.
- The entire organisation is optimising for a single system while leaving the others underdeveloped.
And it tends to happen with the systems that produce the most visible short-term results.
- Tele-calling campaigns that book consultations.
- Paid digital advertising that generates enquiries.
- Health camps that bring in new contacts.
These systems are easy to intensify because the feedback loop is fast: call more people, get more bookings. Spend more on ads, get more clicks. The results are legible and immediate.
The systems with a long gestation period get deferred:
- Building a GP referral network through consistent clinical communication
- Developing SEO and content presence that earns search visibility over twelve months
- Building a brand that patients associate with a specific clinical outcome
- Having robust patient intake, communication, and billing systems.
Unfortunately, it is these very systems that help a practice during challenging times.
These systems do not get formally stopped. No one decides NOT to do them. But the leaders are busy with the systems that are showing results, and the long-gestation systems require upfront investment with no visible return for several months, which makes it easy to say “we will focus on that when things are steadier.”
Things are rarely steadier. The long-gestation systems get started late, started inconsistently, or never started at all. And the hospital remains dependent on the quick-result systems — tele-calling, health camps, advertising — which are expensive to run and which stop producing results the moment they stop running.
The sequence that actually works
Build the essential systems. Get each one to a reasonable level of efficiency — not perfect, not fully optimised, but functional and self-sustaining. Then move to the next.
For Dr. Sharma’s Mohali hospital, that means:
- first, the discharge summary and GP follow-up system.
- Once that is running consistently, the medical liaison programme for catchment GPs.
- Then the online presence — Practo listing, surgeon profiles, Google review programme.
- Then the CGHS empanelment application, which has a defined process and a defined timeline.
None of these require full optimisation before the next one can begin. They require a named owner, defined process, a defined trigger, a defined output, a cadence, a tracking mechanism, and a feedback loop. Once those deven elements are in place, the system can run with limited daily oversight. The leader checks whether it is running — not whether it has produced the desired result — and moves on to the next system.
The result comes later. Not as fast as most hospital administrators would like. But with a reliability that a series of one-time actions can never match.
A good system that runs for twelve months is worth more than a perfectly designed system that ran for three months before a leadership team lost patience and redirected the effort elsewhere.
One last thing
The discipline of letting a system run — without constantly adjusting it, intensifying it, or second-guessing it — is harder than it sounds.
Many leaders are trained to associate frenetic action with progress, they mistake activity for achievement. A system running quietly in the background, producing incremental output with no dramatic week-on-week movement, does not feel like progress. It feels like stagnation.
It is not stagnation. It is compounding. The distinction is only visible in retrospect — which is exactly why most leaders never see it.
Put a good system in place, and then — let it run.
Leave a Reply