Claude Pre-Appointment Triage for Healthcare Websites

Adding AI pre-appointment triage to a healthcare website, with Claude doing the reading and drafting, addresses a problem that multi-site clinic groups feel more sharply than single practices: the same enquiry gets handled six different ways in six locations. A dermatology group with clinics in Manchester, Leeds and Sheffield might receive a message about a changing mole through the website, a GP referral by email and a follow-up question through the patient portal, all for the same person. Each site's coordinator books what seems sensible, asks for whatever documents come to mind, and the consultant walks in with a name, a time and very little else.

The gap between "booked" and "prepared" is where clinics lose money and clinicians lose patience. A 20-minute new-patient consultation whose first eight minutes go on establishing what the patient came for, whether they brought a medication list and whether the referral has arrived is running at 60 per cent capacity. Claude closes that gap on the administrative side. It reads the enquiry, the questionnaire and any referral, produces a consistent clinician-facing summary, identifies which appointment type the group's rules call for, and lists what is still missing. It does not assess the patient, does not suggest what the mole might be and does not decide who is seen first. Clinicians make every clinical call; the model makes sure they start from a complete picture.

Where Traditional Pre-Appointment Preparation Falls Short

Across a group, preparation depends on the individual coordinator. One site sends a detailed pre-consultation questionnaire; another sends a two-line confirmation. Some coordinators read the GP referral and flag it to the consultant; others attach it and move on. Consultants at different sites have very different experiences of the same service, and the group cannot promise patients a consistent standard because it does not have one.

The second failure is timing. Most preparation happens the day before, when a coordinator works through tomorrow's list and finds three unreturned questionnaires, one referral missing the requested imaging and one 15-minute follow-up booked for what is plainly a new problem. By then the slots are fixed and the fixes are phone calls at 5 pm. Nothing looks at each booking at the moment it is made, when a correction costs nothing.

What Claude Adds to a Healthcare Triage Website

• Claude reads long, mixed material in one pass, including a rambling enquiry, a structured questionnaire and a scanned referral letter, and produces a single consistent summary.

• Every summary follows the same structure the group's clinicians agreed, so a consultant in Leeds sees exactly what a consultant in Sheffield sees.

• The output includes an appointment recommendation, a missing-items list and a routing decision that coordinators confirm before anything is booked.

Reading Whole Referral Packs, Not Just Form Fields

Referral letters arrive as PDFs, photos of printed letters and pasted email text, and rarely follow a template. Claude handles long documents comfortably, which matters when a GP referral runs to three pages with a medication list, previous correspondence and a paragraph of history. It picks out the reason for referral, the requested specialty, the history the GP chose to include and practical details such as whether imaging has already been done.

The instruction set makes the boundary explicit. Claude reports what the referrer wrote and does not interpret it. If the GP says "query melanoma", the summary records that the GP raised that question, with no opinion on likelihood. When the referral is unclear, the summary says so and suggests the question a coordinator should ask, rather than filling the gap with a guess.

Consistent, Clinician-Designed Summaries

The summary format is designed with the clinical leads, not by the developers. A typical dermatology version has the presenting concern in the patient's own words, the duration, the referrer's stated question, medications as listed, flags such as immunosuppression the patient mentioned, and what the patient wants from the appointment. Claude fills that structure from whatever exists and marks each field as stated by the patient, stated by the referrer or not provided.

Because the structure is fixed and returned as JSON, the backend validates it, stores it against the booking and renders it identically at every site. Consultants stop reading three sources before each patient and read one page that always looks the same. That consistency is what lets the group audit its own preparation quality.

Recommending Slot Type and Routing the Booking

The group's scheduling rules are written down: a new mole check is a 20-minute slot with a dermatoscopy room; a post-biopsy follow-up is 10 minutes with the same consultant; a patient who mentions pregnancy needs a consultant, not a nurse-led clinic. Claude applies those rules and recommends slot type, duration, room and clinician category, with the reason.

The coordinator sees the recommendation next to the calendar and confirms or changes it. Anything outside the rules, such as a child under 16 or a patient describing rapid change, goes to the site's clinical lead for a same-day look before a booking is offered. The model highlights; a person decides.

Best Use Cases for Claude Pre-Appointment Triage

• Multi-site specialist groups such as dermatology, orthopaedic or ENT clinics where consultants rely on referral letters and imaging arriving before the appointment.

• Fertility and reproductive health clinics where the first consultation depends on a long history and a specific set of prior test results from both partners.

• Occupational health providers who handle employer referrals with their own forms, consent requirements and reporting deadlines.

Multi-Site Specialist Groups

A specialist group lives or dies by the quality of its first consultation, and that depends on preparation more than slot length. Claude reads each referral pack as it arrives, produces the standard summary, checks that imaging or histology mentioned in the letter has actually been received, and drafts the request for anything missing. Coordinators at every site work from the same checklist for the first time.

The operations director gains data that was previously invisible: the share of referrals arriving complete, the time from enquiry to a fully prepared booking, and which referring practices most often omit key items. Those numbers drive conversations with referrers and staffing decisions, and none required a clinician's time.

Fertility and Reproductive Health Clinics

Fertility consultations are long, expensive and dependent on prior results: hormone panels, semen analysis, previous cycle records from another clinic, and both partners' histories. Patients often send these as a batch of photographed documents. Claude organises the batch into the clinic's intake structure, notes which standard tests are present, older than the validity window or absent, and drafts the pre-appointment message listing what to bring.

The model does not interpret any result. A hormone value is recorded as a value with a date, never as normal or abnormal; that judgement belongs to the consultant. What the clinic gains is a consultation that starts with the complete file open and the gaps already known, rather than a first visit spent discovering which tests need repeating.

Occupational Health Providers

Occupational health referrals come from employers, not patients, and arrive with a management referral form, questions the employer wants answered and a consent process that must be completed before the clinician sees anything. Claude reads the form, extracts the questions asked, checks that consent is signed and dated, and confirms the appointment type matches the request, whether a fitness-for-work assessment, a sickness absence review or a health surveillance check.

Timing matters commercially because employer contracts carry turnaround SLAs. Flagging an unsigned consent on the day the referral arrives rather than the day of the appointment protects the SLA and avoids a wasted clinician hour. The physician still conducts the assessment and writes the report; the model only makes sure the paperwork is ready.

Core Features of a Claude Pre-Appointment Triage Website

• An intake layer that accepts enquiries, questionnaires and documents from patients, referrers and employers, with consent captured per source.

• A preparation layer where Claude produces the standard summary, the completeness check and the slot recommendation as validated JSON.

• A coordinator and clinician workspace that shows the summary, tracks missing items and records who confirmed each booking decision.

Intake for Patients, Referrers and Employers

The website offers three routes in. Patients complete a short enquiry and, once a booking is provisionally held, a specialty-specific questionnaire and document upload. Referrers use a secure upload page. Employers use a referral form aligned with occupational health consent requirements. Each route records its own consent wording and stores documents in the group's encrypted storage, with only extracted text passed to the model where the clinic has decided that is proportionate.

Identity matching against the patient administration system happens in the backend before anything is summarised, so the model works with a booking reference rather than a full identity, and duplicate records across sites are caught at the door.

The Preparation Layer and Its Rules

For each booking, the backend assembles the enquiry text, questionnaire answers and document text, adds the specialty's summary structure and scheduling rules, and calls Claude once. The system prompt defines the fields, the boundary between reporting and interpreting, the situations that must go to a clinical lead and the exact JSON shape. The response is checked against the schema, and any field the model could not populate is left as "not provided" rather than inferred.

The rules and structures live in configuration owned by the clinical leads. When a specialty adds a field or changes a slot duration, the change is made once and applies to every site the next day, which is largely why groups prefer this to site-by-site process documents.

Coordinator and Clinician Workspace

Coordinators see upcoming bookings with a preparation status: ready, missing items, or needs clinical review. Opening a booking shows the summary, the source documents and the draft message requesting whatever is missing. Confirming a slot, sending a request or escalating to the clinical lead is a single action, each logged with user and timestamp.

Consultants see the same summary in their clinic list on the morning of the appointment, with unresolved items clearly marked. Reporting draws on the same records: preparation completeness by site, specialty and referrer, and the number of bookings the clinical lead reviewed before they were offered.

Step-by-Step Integration Process

• Write the summary structure, scheduling rules and clinical-review triggers with the clinical leads before anything is built.

• Build one backend service that every site's website, portal and email intake feeds into, with validation and fallbacks around the Claude call.

• Run the first specialty in parallel with the existing process for a month, compare preparation quality, then extend to the next specialty.

Step 1: Define Preparation Goals, Categories and Business Rules

The clinical leads for the first specialty define what a prepared appointment looks like: which fields the summary must contain, which situations need a clinician's look before booking, and how each enquiry type maps to a slot. Operations adds the measures, typically the share of bookings fully prepared 48 hours ahead, consultant time lost to incomplete preparation, and enquiry-to-booking time.

That document is reviewed by the group's clinical safety officer and data protection lead, because it is both the system prompt and the basis of the DPIA. Getting it agreed first means the build phase is about software, not about clinical policy.

Step 2: Design the User Journey for Patients, Referrers and Coordinators

Patient-facing pages are short and plain: what to expect, what to upload and what happens next. The questionnaire asks only what the specialty's summary structure needs. Referrer and employer routes are designed with a few real referring practices and HR teams, since they will use them weekly.

The coordinator workspace is prototyped with real anonymised referral packs from each site so that differences in local practice surface early and can be resolved in the design rather than discovered after launch.

Step 3: Connect Your Website Backend to Claude

A Node.js service on the group's existing infrastructure receives each intake event, gathers the material for the booking, calls the Claude API with the specialty's prompt and schema, validates the JSON and stores the result. Timeouts, retries and a fallback to a "needs manual preparation" status are built in so a delayed API response never blocks a booking.

Prompts and schemas are versioned per specialty. Every change is tested against a held-back set of historical referral packs with known correct summaries before it is deployed, and the results are kept as evidence for governance reviews.

Step 4: Save Results, Trigger Workflows and Keep Humans in Control

Validated summaries are attached to the booking record and surfaced in the coordinator workspace. Missing-item requests are generated as drafts for the coordinator to send. Bookings flagged for clinical review are held, not offered, until the site's clinical lead has looked at them.

No summary reaches a consultant without a coordinator marking the preparation complete, and no message reaches a patient or referrer without a person sending it. Those two rules are enforced in code, which is what keeps the system administrative rather than clinical.

Step 5: Measure Preparation Quality and Improve Over Time

Each month the group compares prepared bookings against the baseline, reviews a sample of summaries against the source documents, and records how often coordinators changed the slot recommendation or clinical leads overrode a routing decision. Patterns feed prompt refinements, which go through the same test-and-review cycle.

When the first specialty is stable, the next one is added by writing its structure and rules rather than by building anything new, which is how the approach scales across a group.

Security, Privacy, Cost Control and Long-Term Scalability

• Referral packs and questionnaires are health data under UK GDPR Article 9, so lawful basis, DPIA, data minimisation and processor agreements are settled before any data flows.

• The model is called once per booking with bounded input, so cost is proportional to bookings and does not grow with conversation length.

• Configuration per specialty and per site means the same service supports a group's growth without re-engineering.

Governance is built around the group's existing obligations rather than added to them. UK GDPR treats health information as special category data, so the group records its lawful basis and Article 9 condition, completes a DPIA describing exactly what the model receives and returns, and signs processor terms with each provider, including API settings that keep data out of training. Groups delivering NHS-funded work align with the Data Security and Protection Toolkit and the Caldicott principles, keep data within agreed regions, and log every access to a summary so the audit trail satisfies both CQC and commissioners.

The line between administration and clinical decision-making is protected deliberately. Because the system reports what patients and referrers said and applies the group's own booking rules, it does not perform a clinical function and stays outside medical device territory; the clinical safety officer reviews any change that could blur that, and where NHS patients are involved the group applies its DCB0160 clinical risk process. Cost is easy to forecast: one Claude call per booking, with input capped, typically costs less per month than a single coordinator shift across six sites, and adding a site changes configuration, not architecture.

Davydov Consulting designs and builds pre-appointment triage on the stack a healthcare group already has, whether that is a Wix Studio site with Velo, a Node service on Google Cloud or Firebase, a WordPress patient portal or a mobile app. We begin with the clinical and data-protection conversation, keep coordinators and clinicians confirming every decision, and integrate the result with your patient administration system. If your clinics prepare appointments six different ways, we would be glad to discuss a first specialty to start with.