---
url: "https://dfylegitscript.com/blog/clinical-governance-adverse-events-and-complaints"
title: "The governance questions a clinic cannot answer with a policy document"
description: "A LegitScript reviewer asks how a telehealth clinic handles an adverse event, a complaint and a product recall, and the answer that fails is a policy nobody has used, because governance is assessed on the record of decisions rather than on the document describing who would make them."
published: "2026-07-24T14:32:24+00:00"
modified: "2026-07-24T14:32:24+00:00"
---

# The governance questions a clinic cannot answer with a policy document

A LegitScript reviewer asks how a telehealth clinic handles an adverse event, a complaint and a product recall, and the answer that fails is a policy nobody has used, because governance is assessed on the record of decisions rather than on the document describing who would make them.

## Key takeaways

- Governance is assessed on the record of decisions rather than on the document naming who would make them, so a policy nobody has ever used is the answer that fails.
- Four routes have to exist and be findable: a clinical concern, an adverse event, a complaint, and a product quality issue or recall.
- A dated log showing what happened, who reviewed it and what changed is worth more than any written procedure, because it is evidence of use.
- The pharmacy boundary needs deciding in advance, including who owns a quality complaint and how a batch is identified from your own order record.
- Support macros are published copy: patients read them, and they are where clinical guidance gets improvised by whoever answered the ticket first.

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](/blog/pharmacy-partner-requirements-for-telehealth-clinics),
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](/blog/what-a-complete-legitscript-application-file-looks-like)
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.

## Frequently asked questions

### Do I need a named medical director on the website?

Nothing forces you to name one, but a named clinician with credentials is one of the strongest trust signals a telehealth site carries, and governance questions are much easier to answer when there is an identifiable person with the authority to overrule a commercial decision.

### Is an empty adverse event log a good sign?

It is usually read as an absent process rather than a spotless record. Any clinic with meaningful volume receives concerns, and the useful evidence is what was done with them, not that none arrived.

### Who handles a problem with the medicine itself, us or the pharmacy?

Both, and the split should be written into the agreement before it is needed. The clinic owns the patient relationship and the communication, the pharmacy owns the preparation, and somebody has to be able to identify which patients received a given batch.

## Disclaimer

LegitScript is a trademark of LegitScript LLC. VeriScripts is an independent application-preparation service. It is not affiliated with, endorsed by, or certified by LegitScript LLC, and claims no sponsorship or partnership with it. We prepare, submit, and manage the application; LegitScript alone decides whether certification is granted. "LegitScript" is used here only to name the certification these applications are for.