What are the three functions of one interface?
A consultation flow does three jobs in one sequence of screens. Almost every design failure comes from optimising one job at another's expense.
As a clinical instrument it must gather what a prescriber genuinely needs. It must draw accurate answers from people with an incentive to present themselves favourably, and route complex cases to something richer than a form. As a conversion surface it must carry an anxious, motivated person from interest to commitment without losing them to confusion, tedium or doubt. And as an evidence generator it must produce a record that reconstructs every decision for the audiences this library keeps naming: inspector, certifier, underwriter and, potentially, court.
The flows this guide argues against pick one job. The marketing-led build optimises conversion until the instrument becomes nominal. The compliance-led build fortifies the instrument until nobody completes it. The developer-led build serves whichever stakeholder was most recently insistent. The proposition inherited from the playbook is that, designed properly, the functions reinforce one another. A visibly genuine assessment is a trust signal, and trust is what converts the patients worth keeping.
What is the standards frame?
The design constraints come from the frameworks this library documents. Here they are compressed to the four that determine the screens.
First, the consultation must be capable of individual assessment: structured questioning that can probe, verify and refuse, not a scored exercise every determined applicant passes. Second, for high-risk categories the strengthened remote prescribing expectations — the post-2025 position the verification article examines — require independent confirmation of the facts prescribing depends on. Weight and history are not accepted on self-report alone, identity is established and age is verified.
Third, the prescriber must be independent and engaged, holding the decision, the reasoning and the record, with the service structurally unable to press toward approval. Fourth, the model must be described honestly to the patient throughout: who assesses, who prescribes and who supplies. That transparency requirement runs from the GPhC standards through the certification frameworks.
None of these constraints dictates unattractive software. All of them dictate what the software must be capable of. That is why the flow belongs in the protective brief as architecture, signed off before the first screen is drawn.
What is the architecture?
Seven stages, each with its own job and its own exit criteria.
Triage. A brief eligibility screen covering age and category-level exclusions. These questions end ineligible journeys within ninety seconds, courteously, before anyone spends ten minutes on a foregone refusal.
Identity. Establish who the person is, to the depth the category requires. That runs from light verification for travel antimalarials to substantially stronger checks for the categories fraudsters and proxies target.
The clinical questionnaire. The instrument proper. It branches so patients answer what is relevant — and everything relevant — and it is sized honestly: long enough to assess, no longer.
Verification. The independent-confirmation layer where the category demands it: records, photographs, measurements and GP correspondence. A later section covers this stage.
Prescriber review. Asynchronous by default where the frameworks permit. Flags, inconsistencies or the prescriber's judgement trigger structural escalation to synchronous contact by message, telephone or video. Where guidance requires synchronous elements, they are mandatory.
Decision and communication. Approval, refusal or a request for further information, each with its own designed experience.
Payment and supply. After the decision, in the lawful order this library repeats, flowing into the dispensing and delivery machinery.
The architecture has one absolute: the order. Everything else varies by category, so a multi-vertical operator should expect one structure carrying several depths of implementation.
When does the flow become synchronous?
Asynchronous assessment is the model's efficiency and its biggest reputational weakness. So synchronous escalation deserves design, not improvisation. Three circumstances require it.
Mandated. Some categories carry guidance that requires real-time interaction, or independent verification only a live channel can deliver. Design this as an unavoidable stage, not an option the flow hopes will prove unnecessary.
Flagged. Inconsistencies, red-flag answers, verification anomalies or free-text content that warrants discussion. These route by rule to message, telephone or video, at the prescriber's choice. Clinical governance sets the threshold, versioned like everything else.
Requested. By the patient, who should always be able to choose a human interaction. And by the prescriber, whose judgement overrides whatever efficiency the queue would prefer.
The escalation's own design decides whether it works. Booking happens inside the flow against genuine availability, not through correspondence. The record travels, so the patient repeats nothing. The discussion is summarised back into the same consultation record, and the flow resumes where it paused rather than restarting. Done that way, the synchronous layer makes the service's depth visible: the point where the mechanism demonstrably contains people. Done as an afterthought, it is a failed handover at exactly the point where both the frameworks and the patient expected a human — the last place to improvise.
How are questions designed to elicit accurate answers?
The central difficulty in online consultation is that a motivated applicant can often spot which answer secures the medicine. A flow whose every question reveals its passing condition is not assessing — it is instructing. The design responses are protective and deserve careful execution. Ask for values, not conclusions: date ranges, measurements and free-text descriptions rather than binary questions that display their consequences. Cross-check by gathering the same fact from different directions at different points, so inconsistency becomes a flag rather than an accusation. Put signal in free text. A mandatory question in each section, answered in the applicant's own words, produces the sentences prescribers actually read, and answers that lack detail are information in themselves. Keep a low reading age and honest stakes: plain-language questions with a visible warning that inaccurate answers endanger the patient. And accept the limit. Question design raises the cost of deception and catches the careless; the determined are the reason the verification stage exists. The two stages are complements, not alternatives.
How does verification function as design?
Verification is where flows lose conversion. Most of that loss comes from placement and framing, not from the checks themselves.
Placement. After provisional clinical fit, before the prescriber decision. Front-loaded, verification spends its heaviest friction on visitors who were never eligible. Placed after payment, it inverts the lawful order and generates refund disputes. Mid-flow, it asks effort only of applicants with something to gain — which is when people comply.
Framing. Every verification screen carries its reason in one patient-facing sentence — for example, that confirmation is needed because the dose depends on it. The frameworks' reasoning genuinely favours the patient, and saying so improves completion. Checks framed as admin get abandoned. Identical checks framed as care get completed.
Effort design. Photograph steps that work on a phone at the first attempt. Document upload that tolerates real-world files. GP-detail capture that autocompletes. And save-and-resume that survives the interruption a records request implies.
Failure handling. A verification that cannot be completed routes to a human channel rather than ending the journey. An applicant defeated by an unclear photograph is a service failure. An applicant who abandons at the request itself has told you something — the funnel metrics should record that as the gate working correctly.
What constitutes the conversion layer?
The legitimate optimisation surface is worth listing in full, so its extent is clear before anyone considers the illegitimate one.
Accurate progress indication, with stages named and duration estimated honestly — unknown length is the main driver of abandonment in long forms. Save-and-resume with a return link that works. Trust indicators at the points of anxiety. Put the prescriber's name and registration where the decision is described. Put the registration and certification marks next to identity capture. Put a plain statement of who accesses the data next to the health questions.
Treat mobile as the primary context: proper touch targets, camera-native uploads and no desktop-only steps. Set expectations at the handover — what happens next, how long decisions take and how the answer arrives. Repeat them at exactly the moment the patient stops controlling the process. Write error states in the pharmacy's voice, not the framework's defaults. And measure: completion by stage, points of abandonment, time in stage and resumption rates, segmented enough to show where genuine patients struggle. That is the basis for the next design iteration.
How is a refusal handled well?
The decline screen is the most commonly skipped design task, and one of the most rewarding. An applicant refused well leaves informed, signposted and without humiliation. They get a clear statement that the service is unsuitable, at whatever level of clinical detail the prescriber thinks right. They get genuine signposting to the GP, NHS services and, for categories where one exists, the in-person route. They get an explicit invitation to return if circumstances change, with the record retained so returning is straightforward. And where the refusal was marginal rather than absolute, they get the offer of a synchronous discussion.
The decline experience must never contain three things. Retry mechanisms that invite fresh attempts with adjusted answers. A tone that reads as accusation. Or the silence of an unexplained ending.
The commercial argument runs alongside the ethical one. Refused applicants review, discuss and return once eligible, and the scorecard records refusal rate as a quality indicator. A service whose refusals are visibly humane has the strongest available witness to the authenticity of its assessments: the person it refused, saying so favourably.
What does the flow record?
Everything, in structured form. The full question and answer set as the patient encountered it rather than a summarised digest, with timestamps and the session's technical context. Verification artefacts and their outcomes, comprising images, documents and check results, retained under the data rules which this library addresses. The prescriber's decision accompanied by reasoning in their own words, together with any messages exchanged.
And the element which most builds omit, namely the questionnaire version identifier. The instrument itself changes, since guidance moves, questions improve and thresholds shift, and each change should be released as a new version carrying an effective date and recorded clinical sign-off, with the version applied to every consultation which it governed. When guidance is next strengthened, the versioned service establishes which cohort was assessed under which version through a single query, whilst the unversioned service reconstructs its own history from deployment records and recollection. Version control of clinical content constitutes governance rendered mechanical, and it is a single development cycle of work which repays itself at the first audit.
What does the prescriber's interface require?
The patient-facing flow determines what may be known, whilst the prescriber interface determines whether it is used. Four principles apply.
The whole record by default, with summaries functioning as navigation rather than as substitute, since a summary-only interface constitutes the mechanism by which services drift honestly into approval by default. Flags which prioritise rather than decide, with inconsistencies, red-flag answers and verification anomalies surfaced prominently whilst the underlying answers remain immediately accessible. Friction where clinical practice requires it, comprising a decision which cannot be submitted without the reasoning field completed, and escalation to message or call available within the same screen. And honest telemetry, comprising decision times, approval rates and caseloads per prescriber, visible to the superintendent, since the decision-mill pattern which regulators have prosecuted announces itself within precisely those figures well before it reaches a hearing.
The interface should render thorough work the path of least resistance and volume work visible, which constitutes the software encoding the service's incentives rather than merely displaying its queue.
How is the flow tested, and where does the ethical boundary sit?
Iterate continuously, upon the appropriate elements, through the appropriate process.
The interface, comprising copy, layout, progress design, reassurance placement, error handling and upload ergonomics, constitutes legitimate experimental territory, measured upon completion, comprehension and support contacts. The instrument, comprising questions, thresholds, branching and verification requirements, changes only through clinical governance, being proposed, reviewed, signed off and versioned, with a change log which an inspector could read.
The boundary between them is distinct and warrants stating as a rule which a team may recite, namely that how a question is asked may be tested, whilst what is asked may not be tested for conversion. Optimising clinical content against approval rate constitutes the prescribing-target failure supported by better tooling, and a service permitting its growth function access to the thresholds has already selected its eventual difficulty.
Within the boundary, iterate against the combined metric set with which this guide opened, placing completion, refusal rate and record quality upon one dashboard, since a three-function interface warrants a three-function definition of improvement, and the flows which succeed over time are those whose every improvement satisfied all three questions simultaneously.
Key takeaways
- The consultation flow constitutes clinical instrument, conversion surface and evidence generator simultaneously, and optimising one function at the others' expense constitutes the standard failure.
- The architecture runs triage, identity, questionnaire, verification, prescriber review, decision and then payment, with the order absolute whilst the depth varies by category.
- Question construction addresses the obvious-right-answer problem through values rather than conclusions, cross-checks, mandatory free text and plain language, with verification identifying what questions cannot.
- Verification converts when positioned mid-flow and framed as care, with every check carrying its patient-facing reason, and abandonment at a genuine gate constitutes the gate operating.
- Refusing well constitutes brand infrastructure, being clear, courteous and signposted, without retry encouragement, and the refusal rate appears upon the scorecard as a quality indicator.
- The record holds everything including the questionnaire version, and version control of clinical content constitutes one development cycle of work followed by every subsequent audit.
- The prescriber interface renders thoroughness the easy path and volume behaviour visible, and the ethical boundary is distinct, in that how a question is asked may be tested whilst what is asked may not be tested for conversion.
Sources and further reading
FAQs
Three jobs, one flow.
Dataforge PMR runs consultation flows built to this guide: versioned questionnaires, mid-flow verification, prescriber interfaces with the whole record and the telemetry, declines handled kindly, everything written to one patient journey. Our publisher designs the patient-facing layer to match. If your consultation is a form wearing a stethoscope, see how it works.
See Dataforge PMR