The governance questions a clinic cannot answer with a policy document

Clinical governance is the part of a telehealth operation that generates no revenue, appears on no dashboard, and is the first thing an experienced reviewer probes. Not because it is likely to be broken, but because it is the fastest way to tell whether there is a clinical organisation behind the website or a marketing organisation with clinicians attached.

The distinguishing question is simple: when something went wrong, what happened?

The four routes that have to exist

A clinical concern. A patient who is worried about a symptom, a dose or an interaction needs a way to reach a clinician that does not run through a sales inbox. It needs a stated response time, and somebody has to own it out of hours.

An adverse event. A structurally different thing from a complaint. It needs its own intake, a clinician review, a record, and a decision about onward reporting. A business that routes adverse events into a support queue and resolves them with a refund is describing a shop.

A complaint. About the service, the billing, the delivery or the clinician. It needs an owner, a timescale and an outcome that is recorded.

A product problem. A quality issue with a dispensed preparation, or a recall from the pharmacy. This one crosses the boundary to your partner, and the plan for it has to exist on both sides.

What makes an answer credible

Not the policy. Every business can produce a policy. What separates a real function from a documented intention is evidence of use.

• A log. Dated entries, what happened, who reviewed it, what was decided, what changed afterwards. A log with nothing in it is a claim that nothing has ever gone wrong, which is not credible at any scale.
• A named clinician with authority. A medical director who reviews events, can overrule a commercial decision, and is identifiable on the website.
• A closed loop. Somebody looked at the pattern across events and changed something: an intake question, a dosing instruction, a support macro, a page.
• A route that a patient can actually find. In the footer, in the post-purchase email, and in the portal, not buried in terms.

The pharmacy boundary

Half of what can go wrong involves the preparation rather than the prescription, and that sits with your partner. Both sides need to know, before it happens, who does what.

Establish it in the agreement: how a quality complaint reaches the pharmacy, who contacts the patient, who decides on replacement or refund, how a recall is communicated to affected patients, and who holds the dispensing records needed to identify them. That last one catches people. A clinic that cannot identify which patients received a particular batch cannot execute a recall regardless of who is at fault, which is a governance failure with your name on it.

The diligence questions that surface this are the same ones in your pharmacy partner is part of your application, and they are cheaper to ask before signing.

Where governance and marketing collide

Support macros. This is the specific, unglamorous place where a well-run clinic generates a claims problem: an agent reassuring a nervous customer, in writing, with a comparison to the brand-name drug or a promise about results.

Macros are copy. They should be written against the claims allowlist, reviewed when the allowlist changes, and owned by somebody. The same applies to whatever the chat widget says, whether a human or a script is saying it.

What to have ready before you file

A short governance pack, and it is short by design.

• The four routes above, with owners, timescales and where a patient finds each.
• The medical director, named, with credentials and scope of authority.
• The event log, with the last twelve months of entries.
• The pharmacy responsibilities, as agreed rather than as assumed.
• The support macro library, read against the claims allowlist.
• One example, anonymised, of an event that changed something.

That last item does more work than the rest combined. A business that can show a loop closing has demonstrated the function exists, and a complete file is the place it belongs rather than being reconstructed during correspondence.

Sizing it to the business you actually are

None of this implies a compliance department. A clinic with two prescribers and four hundred patients does not need a committee, and building one produces documents nobody uses, which is the failure mode this article is about.

What it needs is small and real: one named clinician with authority, one inbox that is monitored with a stated response time, one spreadsheet that records events and what was decided, and a quarterly half hour where somebody reads the last quarter's entries and asks whether anything should change.

Scale it by adding people rather than by adding process. At a few thousand patients the inbox needs cover at weekends and the log needs categories. At scale it needs somebody whose job it is. The shape stays the same throughout, which is why starting it early is cheap: a governance function that grew with the business has a history, and one bolted on at the point of a certification review has a policy document dated last month.

The version that fails at every size is the one where the routes exist on the website and the events are resolved commercially, because a refund closes a ticket and answers nothing about whether the clinical model needs to change.

Why this is worth doing regardless

Certification is the occasion, not the reason. Adverse event handling is the part of a telehealth business where the gap between a good operation and a careless one is measured in patient harm rather than in revenue, and it is the part that a growing company most reliably outgrows without noticing.

The clinic that can answer these questions in an afternoon is not better at compliance. It is better run, and it happens to be easier to certify.