Cardiac sciences and the digital referral loop

The first cardiac sciences plan I was handed had a patient on every slide. Chest-pain awareness, a heart-check package, doctor videos, a cath lab timing promise, a campaign for the festival season when the admissions dip. It was a competent plan. It was also aimed at the wrong person, and it took a medical director about four minutes to show me why.

He pulled up the previous year’s angioplasty and bypass volumes and sorted them by source. A minority had walked in, searched, or called. The rest had been sent — by physicians in Tier 2 towns two hundred kilometres out, by cardiologists running echo clinics who did not have a cath lab, by nursing homes that stabilised a patient and needed somewhere to move him by morning, by a handful of general practitioners who had trusted one surgeon for fifteen years. Forty or fifty doctors accounted for most of the elective book. None of them appeared in my plan.

That is the structural fact about cardiac sciences in an Indian hospital group. It is the most referral-dependent high-margin specialty you run, and almost all of the digital effort goes into the smaller pool. The patient-facing product matters. But if you only build that one, you have built half a loop.

Who actually sends a cardiac patient

Map the senders before you build anything. In every group I have looked at, the list is short and it has a shape.

• The non-interventional cardiologist. Runs an OPD and an echo machine in a district town or a suburban clinic. Diagnoses, medicates, and sends the patient who needs a procedure. Wants the patient back afterwards, and resents it when he does not get him back.
• The physician or general practitioner. Sees the breathlessness, the abnormal ECG, the diabetic with chest discomfort. Refers on trust, not on data. Rarely receives a report unless the family carries it.
• The small hospital or nursing home. Has an ICU but no cath lab. Refers emergencies, at night, by phone, to whichever number answers.
• Your own network. Physicians and emergency departments at other units in the group who should be sending to your cardiac centre and are sometimes sending elsewhere because it was easier.

Each of these has a different job to be done, and a portal designed for one is useless to the others. The nursing home at two in the morning does not want to log in. The cardiologist wants his patient’s angiogram report and discharge summary by the afternoon, addressed to him, so that he keeps the follow-up. The GP mostly wants to know his patient was seen and is alive. Build for those jobs, not for a generic ‘referring physician’.

Report turnaround is a product feature

Ask a referring cardiologist why he stopped sending patients to a particular centre and the answer is rarely clinical. It is that he heard nothing. The patient came back to him three weeks later with a plastic folder, or did not come back at all because the tertiary centre quietly absorbed the follow-up.

The single most valuable thing the digital function can do for the cardiac programme is to make the return of information reliable, fast and addressed. That is a product problem, not a courtesy. It has a specification:

• The referring doctor is captured as a structured field at registration, not as a free-text remark in the notes. If you cannot record who sent the patient, nothing downstream works.
• The angiogram report, the procedure note and the discharge summary go to that doctor automatically, on the channel he actually reads — which in most of India is a messaging app, with a secure link behind it, not an email he will never open.
• The turnaround is measured. Hours from procedure to report delivered to the referrer. Put it on the same dashboard as enquiry-to-appointment. It is the referral-side equivalent of that number.
• The follow-up is explicitly handed back. The discharge communication says which visits happen at the tertiary centre and which go back to the sender. This is the sentence that keeps a referrer for a decade.

Getting this built requires the medical records team, the cath lab coordinator and the discharge desk to change how they work. None of them report to you. The way I have got it done is by putting the turnaround number in front of the cardiac programme head with the referrer list next to it, and letting him see which of his senders were waiting eleven days for a summary. He fixed the workflow faster than any project plan of mine would have.

The portal nobody logged into

The first referring-physician portal I was involved in was a proper piece of software. Secure login, patient status, report download, a form to refer a new patient, appointment booking on the doctor’s behalf. Adoption was close to nothing. Doctors who had been trained on it went back to calling the surgeon’s mobile.

The mistake was treating the portal as the product. The product is the loop — send, acknowledge, treat, report, return — and the portal was one possible interface to it, chosen because it was the one we knew how to build. The referrers already had an interface: their phone. The version that worked was less impressive to demonstrate. A dedicated referral number and messaging line, answered by a named coordinator who was measured on acknowledgement time; a status message when the patient was registered, when the procedure was done, and when the summary was ready; the reports delivered to the same thread. The web portal survived as the place a clinic’s staff could look up history, and the doctors used it about as much as you would expect.

If you are going to build a doctor-facing product, start with the messaging workflow and the CRM behind it. Add screens later, for the users who ask.

The emergency pathway online

Elective cardiac demand is referred. Emergency cardiac demand is decided in a panic, usually by a family member, sometimes by a nursing-home duty doctor, and the decision is made on whichever number is at hand. This is where the patient-facing and doctor-facing products meet, and it is where a group with several units can either look like a network or like a set of unrelated buildings.

The digital piece of an emergency pathway is unglamorous. One number for cardiac emergencies across the city, published everywhere, answered by people who know which unit has a free cath lab tonight. A page that a frightened relative finds in one search and that tells them, in the regional language, what to do in the next ten minutes and which door to drive to. Ambulance dispatch that is visible to the receiving unit before the vehicle arrives. A protocol for the nursing homes in your referral map that says: call this line, send the ECG on this thread, and the lab will be ready.

The commercial argument for this is straightforward and it is the one I have used in the capital conversation. Emergency cardiac admissions are the least price-sensitive, the least shopped and the most reputation-forming admissions the hospital takes. A family whose father was in the lab within the hour tells the story for years. The cost of the pathway is a contact-centre line, a dispatch integration and a set of standing agreements with senders. Against a cath lab that sits idle on the nights the phone goes to voicemail, it is not a difficult case.

Why the referral relationship is a CRM problem

Here is the reframing that took me longest to accept. The referring doctor is an account. He has a history with you, a share of his patients that he sends to you versus elsewhere, a churn risk, a set of unresolved complaints, and a lifetime value that dwarfs any patient’s. Every sales organisation on earth manages that relationship in a system. Hospitals manage it in the surgeon’s head.

That works until the surgeon leaves, and then the referral book leaves with him, and the group discovers that it never owned the relationship at all. I have sat in a unit P&L review where a cardiac programme lost a meaningful share of its elective volume in a quarter because one interventionalist moved across town, and nobody could produce a list of the doctors who had been sending to him.

The CRM you already run for patient enquiries can hold referring doctors as accounts with almost no additional software. What it needs is discipline:

• Every referrer as a record, with specialty, location, the units he sends to, and the surgeons he trusts.
• Every referred patient linked to that record, so that volume, procedure mix and outcome-communication status roll up to the doctor.
• A view that shows senders whose volume has dropped, so that somebody visits before the reason becomes permanent.
• Ownership. A physician-liaison team that carries the accounts, sits inside the growth function, and is measured on active referrers and turnaround, not on gifts distributed.

The medical director’s objection to this is predictable and legitimate: doctors do not want their relationships put into a marketing database. The answer that has worked is that the record exists to serve the referrer — faster reports, guaranteed hand-back, one number to call — and that the surgeon sees it and shapes it. The system is not there to replace the relationship. It is there so the group still has one when the surgeon retires.

The line you do not cross

Any conversation about referral in Indian healthcare arrives, eventually, at money. Referral fees exist in the market. They are unethical under the professional code, they are increasingly a legal risk, and they are corrosive in a way that shows up in the P&L years later as a book of business that evaporates the moment someone pays more.

The digital referral loop is the defensible alternative, and I would put it to a board in exactly those terms. A programme that wins referrers on turnaround, acknowledgement, hand-back and emergency access is competing on service. It builds a relationship the group owns, that survives audit, and that a competitor cannot buy away in an afternoon. If the physician-liaison team’s incentives are ever tied to anything other than service metrics, you have built the wrong thing and you should say so before someone else does.

What tells you the loop is closing

The vanity metric is total cardiac admissions, and it will be pulled by pricing, by seasonality and by whichever surgeon is in form. The numbers that show the loop working are narrower.

• Active referrers per quarter — doctors who sent at least one patient — and how many are new versus returning.
• Report turnaround to the referrer, in hours, by procedure.
• Follow-up hand-back rate — the share of discharged patients whose follow-up went to the sender as promised.
• Acknowledgement time on the referral line, day and night.
• Emergency response — call to arrival, arrival to lab, tracked as a product number and not just a clinical one.
• Concentration — how much of the elective book sits with the top ten senders and with the top two surgeons. High concentration is the risk you are managing.

When these move, admissions follow within two or three quarters. When admissions move without these, something else moved them and you should not take the credit.

If you’re starting this next quarter

The order matters, because the temptation is to start with the software.

1. Pull twelve months of cardiac procedures and attribute each to a sender. Expect the data to be poor. The exercise is what tells you how poor.
2. Make the referring doctor a mandatory structured field at registration for the cardiac programme. Fight for this one; it is the foundation.
3. Stand up the referral line and the messaging thread with a named coordinator and an acknowledgement standard. No portal yet.
4. Automate report and summary delivery to the referrer. Measure turnaround from day one.
5. Write the hand-back sentence into every cardiac discharge communication, and agree it with the programme head so it is honoured.
6. Load the referrers into the CRM as accounts. Assign owners. Build the falling-volume view.
7. Publish the emergency pathway — one number, one page, in the languages your catchment speaks — and take it to the nursing homes in your referral map.
8. Only then decide whether a portal earns its build cost, based on what the users have asked for.

Two quarters of this and you will have something the patient-facing plan never gave you: a list of the people who actually decide where the cardiac patients go, and a reason for each of them to keep deciding in your favour.

The patient chooses the hospital once. The referring doctor chooses it every week. Build for the one who keeps choosing.

Questions people ask