How to Start an Online Clinic in the UK: The Complete Guide to Building a Prescribing Platform

What is an online prescribing platform, actually?

It's a shop front with a clinical decision wired into the middle of it. A patient chooses a treatment, completes an assessment, and pays, but nothing is supplied until a prescriber has reviewed that assessment and approved the order. Everything that makes these businesses work, and everything that makes them hard, comes from that one structural fact.

This is why an ordinary ecommerce build doesn't translate. A standard online shop is designed to take money and dispatch immediately, because that's what it's for. A prescribing platform has to take the order, hold it, route it to a clinician, let that clinician approve it, reject it, ask the patient a question, or escalate to a consultation, and only then generate a prescription, produce a dispensing label, and release it for dispatch.

The second column is the product. If a build doesn't account for it, what you've bought is a shop that happens to list medicines, and the clinical governance has been left for you to perform by hand. We've also written up the ten mistakes people make when launching an online clinic, most of which happen before a platform is even chosen.

Which model are you actually building?

There are two shapes, and the answer changes your registrations, your suppliers, and a large part of the technology.

Prescribe and dispense in-house. You hold the GPhC-registered premises, employ or contract a superintendent pharmacist, and supply the medicine yourself. You own the full margin and the full obligation. The platform needs prescription generation, dispensing labels, stock and batch tracking, and an audit trail that stands up to inspection.

Prescribe and hand off to a dispensing partner. Your prescribers make the clinical decision and a registered pharmacy dispenses and ships. Lower operational lift, thinner margin, and a hard dependency on how cleanly prescriptions and patient information reach the partner. The integration between you and them becomes a critical piece of infrastructure rather than an afterthought.

Plenty of platforms start with the second and move to the first once volume justifies it. That's a sensible progression, but it's only cheap if the platform was built expecting it. A system where the dispensing step is a manual email to a partner pharmacy will need rebuilding at exactly the moment you're busiest.

What has to be in place before you supply a single item?

Regulation isn't the fun part, but it decides what your platform is allowed to do, and several requirements change the specification rather than sitting alongside it.

• Pharmacy registration. Supplying medicines means GPhC-registered premises and a superintendent pharmacist. The GPhC's guidance for pharmacies providing services at a distance sets expectations specific to online supply, including how you satisfy yourself about the patient and how you handle higher-risk medicines.
• Prescriber standards. Independent prescribers work to their own regulator's framework, and the GPhC publishes standards for pharmacist independent prescribers. Define scope of practice in writing before you build the assessment around it.
• Distance selling logo. Websites selling medicines to the public in the UK are required to display the registered distance-selling logo, linking to the relevant register entry. That's a build requirement, not a marketing decision.
• CQC or equivalent. If your service involves regulated activities, registration may apply, and the CQC's scope of registration is where to check your position for England.
• Data protection. Health data is special category data. The ICO's guidance on health data covers the obligations, and you'll need a lawful basis, retention rules, and role-based access designed into the platform rather than bolted on.
• Advertising limits. Prescription-only medicines can't be advertised to the public in the UK. The MHRA's Blue Guide sets out what that means, and it shapes every treatment page and advert you'll ever write.

Sort these before the build. Identity verification, consent capture, and audit logging are small features when planned and awkward retrofits when they aren't.

What does the patient journey actually look like?

Write this out before anyone designs a page. For each step, note what the patient sees, what your team does, and where the information is stored. Most build decisions answer themselves once this exists.

1. The patient searches for a condition or a treatment
2. They land on a treatment page with price, what's included, and who it's suitable for
3. They choose the treatment, strength, and quantity or plan
4. They create an account
5. They complete the condition-specific online assessment
6. They upload what's required, such as photo ID, a photograph, measurements, or recent readings
7. They pay, and the order is held pending clinical review
8. The order and its assessment land in the clinician review queue
9. A clinician approves, rejects, messages the patient for more information, or books a video consultation
10. On approval, the prescription is generated and checked
11. The dispensing label is produced and the item dispensed against stock and batch
12. The order ships and the patient follows it from their portal
13. Check-in forms, progress logging, and reminders run through the treatment cycle
14. A reorder prompt arrives, the patient re-screens, and the order returns to step 8

Look at step 7 carefully. Taking payment before a clinical decision is normal in this model, but it has to be handled properly, meaning the patient understands they're paying for an assessment and a supply that may not be approved, and your platform can refund a rejected order without somebody logging into a payment dashboard to do it manually.

Then look at step 14. That's the whole business. A patient who completes one cycle and never returns has cost you acquisition spend and returned a single transaction. The clinics that work are the ones where step 14 happens on its own.

Why does everything depend on the Clinical Gate?

Call it the Clinical Gate: the point where an order stops being a purchase and waits for a prescriber. Every serious decision about your platform is really a decision about how that gate behaves.

A well-built gate does more than approve and reject. It gives the clinician the assessment, the patient's history, their previous orders, any uploaded photographs, and the outcome of earlier check-ins on one screen, because a decision made with three browser tabs open is slower and easier to get wrong. It records the outcome with a reason. It notifies the patient in language they understand. And it makes the unsafe path impossible rather than merely discouraged, so nothing can reach dispatch without passing through it.

• Approve. The prescription generates, the label follows, the order releases for dispensing.
• Reject. The patient is told clearly, refunded automatically, and signposted somewhere appropriate.
• Request more information. A message goes to the patient, the order stays held, and the clock on your service standards keeps running.
• Escalate to consultation. The patient books a video or phone slot from their portal, and the consultation attaches to the same order.
• Refer on. Some patients need their GP or a specialist, and the platform should make that a recorded outcome rather than an email.

Where video consultations fit

Video isn't the default in most prescribing pathways, and building as though it is leads to a diary-shaped product that doesn't match how patients actually buy. The assessment carries most of the clinical load. Video is what you reach for when something in that assessment needs exploring, when a treatment or patient group warrants a conversation, or when your own protocol requires it for a first supply.

That makes consultation scheduling a feature of the Clinical Gate rather than the front door. Availability should sit inside the platform, appointments should attach to the order and the patient record, and the consultation outcome should feed the same decision the clinician was already making.

How should your assessment forms be built?

The assessment is not a contact form. It's the clinical instrument that carries the decision, and it's the first thing an inspector will want to see. Treat it as software with clinical requirements.

• One assessment per treatment pathway. Weight management, hair loss, and sexual health ask different questions. A single generic form collects too much from some patients and not enough from others.
• Branching logic. Questions should open and close based on earlier answers, so the patient sees a short relevant form and the clinician gets a complete one.
• Hard stops. Certain answers should end the assessment before payment, with a clear explanation and a signpost. Screening people out early is cheaper than refunding them later.
• Structured answers. Free text is hard to review at volume. Structured fields let the clinician scan a decision in seconds and let you report on patterns across the patient base.
• Flagging. Answers that need attention should surface at the top of the clinician's view rather than sitting on page four.
• Version history. When you update the form, previous submissions must stay tied to the version the patient actually answered. Without this, a decision made in March can't be defended in November.
• Pre-fill on reorder. Returning patients should confirm and update rather than retype, which is what makes the check-in cycle something they'll actually complete.

Form versioning is the detail most builds miss, and it's the one that matters most when something is questioned. You need to be able to show exactly what was asked, what was answered, and which clinician saw it.

What does the patient portal need to do?

For a prescribing platform, the portal isn't a nice extra. It's where the repeat business happens, and a patient who can't log in is a patient whose next order becomes an email somebody has to process by hand.

At minimum it needs to let patients:

• Reorder in a few taps. Repeat orders are placed from the portal, with approvals routed straight to the clinical team rather than through your inbox.
• Complete check-in forms. Short scheduled reviews that keep the pathway safe and give the prescriber something current to approve against.
• Track progress. Weight, measurements, and treatment milestones logged over time and shown as clear charts. Patients who can see progress stay on plan, and the ones who stay on plan reorder.
• Message the clinic securely. Two-way messaging logged against the record, which keeps clinical conversations off personal email and WhatsApp.
• Book consultation calls. Video or phone slots booked directly, with availability synced to the clinical calendar.
• See order history. Every order, payment, and supply in one searchable place, so neither the patient nor your team has to go digging.

The commercial case is simple. Acquiring a patient costs money once. Retaining one costs a portal login and a well-timed prompt, which is why we've written separately about giving patients a reason to keep logging in and how repeat orders become predictable monthly revenue. Our own patient portal is built around exactly these six jobs.

What does your team need on the other side of the screen?

Founders spend most of their planning on the patient experience and almost none on the clinic side, then discover that the clinic side is where the working day actually happens. Your prescribers, pharmacists, and support staff live in this screen.

• A review queue. Pending orders, sorted and filtered, with the assessment, history, uploads, and previous decisions on one view.
• Roles and permissions. A support assistant, a dispenser, a prescriber, and a superintendent don't need the same access. Role-based access is both a governance requirement and a practical one.
• Notes. Clinical notes written against the patient record, attributed and timestamped, with templates for common pathways.
• Patient messaging. Initiated by your team, not only in response to patients, and logged in the same place as everything else.
• Prescription and label generation. The approved decision should produce a compliant prescription and a dispensing label with dosage, directions, and warnings, rather than somebody retyping into a separate system.
• Stock and batch tracking. What was supplied, from which batch, with which expiry, recorded at the point of dispensing.
• An audit trail. Every view, edit, approval, and supply logged immutably and exportable when asked.
• Treatment and product management. You should be able to launch a new treatment, set its price, attach its assessment, and publish its page without booking developer time.

That last point decides how fast you can move. A platform where adding a treatment is a project will hold your business back every time the market shifts, which in this sector is often.

What breaks as the team grows

Run this test on every decision during the build: if a second prescriber joined next month, would this still work? Single-clinician setups fail it in predictable places. Work has to be assignable rather than assumed. Two people must not be able to review the same order at once. Notes need an author. Performance and outcomes need attributing per clinician. And somebody has to be able to see what's sitting unreviewed at four o'clock on a Friday.

None of this is expensive to allow for at design time. Retrofitting permissions into a system that assumed one user usually means rebuilding the record model with live patient data in it.

Which automations actually earn their place?

Automation in a prescribing platform isn't about replacing clinical judgement. It's about making sure nothing waits on somebody remembering. The clinical decision stays with a person, and everything around it should run itself.

The reorder prompt is the one with the clearest commercial return. Timed to when the patient is actually running out rather than to a calendar rule, it turns a decision the patient might delay into one they make on the spot. Our SMS campaigns and automated reminders do this work, and the check-in forms that sit behind them come from the same digital forms engine as the initial assessment.

How do patients find an online pharmacy?

Search, mostly, and the unit of search is the treatment page. One page per treatment, each answering the questions a patient types, is what gets you found and what converts once you are. A single page listing everything you offer will rank for none of it, which we've covered in why your clinic needs separate pages for every treatment.

The constraint that shapes all of it is the advertising restriction. You can't promote prescription-only medicines to the public, so your pages are built around the condition, the service, the assessment, and the price of the consultation and supply rather than around a branded medicine. Google layers its own healthcare and medicines policy on top for paid campaigns, with certification requirements in some categories.

• Condition-led content. Answer the questions patients ask before they're ready to buy, which is also what gets you cited by AI search. We've written about being the clinic AI search recommends.
• Treatment pages. Price, what's included, how the assessment works, delivery, and what happens if you're not suitable.
• Trust signals. Registration details, the distance-selling logo, named clinicians, and real reviews.
• Paid search. Viable where your patient lifetime value supports it, and worth modelling before you spend. Our Google Ads work is built around approved orders rather than clicks.
• Retention. Cheaper than all of the above, and the reason the portal matters.

What does it cost and how long does it take?

Ranges, so you have something to work with. These cover the build, not your registrations, indemnity, stock, or marketing.

Running costs sit higher than an ordinary clinic website because you're paying for messaging, payments, video, hosting, and support against real clinical volume. Budget from your patient lifetime value rather than as a fixed figure.

Three things inflate the number more than anything else. Multiple pathways multiply the assessments, the pages, the protocols, and the testing. Integrations with dispensing partners or wholesalers are rarely as simple as their documentation suggests. And undecided scope is the most expensive of all, because work gets built twice.

The timeline bottleneck is usually not the build. It's registration, protocols, supplier contracts, and your own decisions about who you'll treat.

What should version one contain?

One condition. Three to five treatments. One assessment. A working Clinical Gate. A portal that handles reorders and check-ins. Automations for the moments in the table above. Nothing else.

That's not a compromise, it's the fastest route to a business that works. A platform covering four conditions takes three times as long to launch and teaches you a quarter as much per week, because nothing gets enough volume to tell you anything. Launch narrow, learn from real orders, then widen.

What earns a place in version one is anything a patient touches in their first two cycles. Everything else waits until real patients have told you it matters.

Build your prescribing platform on Clinic Pro

The reason these platforms get assembled from six tools is that no single off-the-shelf product covers a treatment page, a branching clinical assessment, a prescriber review queue, label generation, and a patient portal. Clinic Pro is built for exactly that shape, so the pathway runs as one system.

• Treatment pages that rank. Add a service and the platform produces a launch-ready, SEO-tuned page for approval, with controlled publishing so nothing goes live unchecked. See clinic websites.
• Assessment forms. Branching questionnaires with hard stops, flagging, and version history, feeding straight into the order rather than an inbox. See digital forms.
• Clinician review. Approve, reject, message, or escalate, with the assessment, history, and uploads on one screen and every action logged. See clinical admin.
• Prescription and label generation. Compliant prescriptions and dispensing labels straight from the approved decision, with stock, batch, and audit trail behind them. See the platform.
• In-house video consultations. Scheduling that sits inside the pathway and attaches to the order and the record. See online booking.
• Patient portal. Reorders, check-in forms, progress charts, secure messaging, consultation booking, and order history in one secure account. See the patient portal.
• Automations. Reminders, check-ins, reorder prompts, and review requests that fire from the pathway rather than from somebody's memory. See SMS campaigns.

If you're at the stage of working out what version one should contain, start a conversation and bring your pathway. That's the useful thing to arrive with.

The website sells the treatment. The platform runs the clinic.

Everything patients see is the easy half. The half that determines whether the business works is the clinician looking at an assessment, deciding, and having that decision turn into a supply without anybody retyping a thing.

Design the pathway first. Put a real gate in the middle of it. Make the repeat order effortless for the patient and reviewable for the prescriber.

Then build the smallest version of that you can finish, and let real orders tell you what comes next.