How should an AI patient assistant handle repeat-prescription requests?

The short answer

An AI patient assistant can receive a repeat-prescription request, verify the caller through an approved process, collect the minimum information, create a traceable case in the clinic's source system and tell the patient what will happen next. It should never say that a medicine has been approved, prescribed or sent until the authoritative system confirms that exact state.

The clinical decision remains with an authorised prescriber or another person acting within local law and clinic policy. The assistant does not decide whether treatment should continue, change a dose, recommend an alternative, interpret symptoms or set clinical priority. This article describes an administrative workflow, not medical advice or a universal prescribing rule.

Keep the intake case separate from the prescription

A patient's phone request is evidence that the clinic received a request for review. It is not the same as a prescription order. HL7 FHIR describes MedicationRequest as an order or request for medication and distinguishes it from MedicationDispense. A clinic may use FHIR or a different local model, but the operational boundary should remain clear: an intake case cannot silently become an authorised order.

Use explicit states and display the owner of each transition. A patient-facing message should be generated from the current source-system state, not from a conversational assumption.

Verify the patient and any representative before disclosure

Match the level of verification to the action and information involved. Before confirming that a repeat medicine exists, naming it or discussing a request, link the caller to the correct record with the clinic's approved method. Do not read possible answers aloud, reveal which field failed or treat demographic details as a universal password.

A verified caller is not automatically authorised to act for another person. Proxy status, consent, parental responsibility, capacity and safeguarding need their own rules and a staff route for exceptions. If verification or authority is unclear, stop disclosure, give a neutral official contact route and create a review task instead of guessing.

Collect the minimum information needed for review

Design the form with the clinical and pharmacy team, then collect only fields needed to locate the existing record, understand the administrative request and return an answer safely. Prefer structured selections backed by the source system. Preserve the patient's own words only where a free-text note is necessary, and keep those words separate from system conclusions.

Do not invite the patient to provide a diagnosis or ask the assistant to decide whether a medicine is suitable. If the patient mentions a new symptom, side effect, pregnancy, allergy concern, dose change, lost medicine, early supply or uncertainty about how to take it, capture the statement and follow the clinic's human escalation route.

Write once, reconcile after timeouts and keep one source of truth

Every submission needs an idempotency key or equivalent duplicate control. If a call drops after the write, the assistant should look up the result before retrying. When the result remains unknown, tell the patient that the request is being checked and create a reconciliation task. Do not create a second case or announce success simply because the interface timed out.

The patient record, prescribing system or approved workflow platform remains authoritative for status. A voice platform may retain a narrow reference and audit event, but it should not maintain a separate list of medicines or approvals. Record who supplied information, who entered it, which protocol version ran and which source-system identifier was returned.

Keep prescribing and clinical judgment with authorised people

The assistant must not continue a medicine, choose a quantity, alter dosage, substitute a product, decide that monitoring is current or judge whether an early request is appropriate. It should not infer urgency from a caller's tone or reassure a patient that missing a dose is safe. Those are clinical or professional decisions governed by the applicable jurisdiction and the clinic's procedures.

Define stop conditions before launch. A new symptom, suspected reaction, request for a change, uncertainty about the medicine, safeguarding concern, emergency statement or mismatch in the record should trigger the clinic's approved human route. If the patient describes an emergency, the assistant may play the clinic's approved emergency message, but it should not perform autonomous triage.

Communicate only a verified outcome

Use language that matches the recorded state. 'We have received your request for review' is not 'your prescription is ready.' If staff decline the request or need more information, use approved wording and a clear contact route. If the prescription is created but dispensing is not confirmed, do not say that the pharmacy has supplied it. Order, transmission and dispensing are distinct events.

Voicemail and text need neutral templates because devices may be shared. Avoid naming the medicine, specialty or reason for contact unless the clinic has established that the channel and recipient are appropriate. Record delivery failure as a failure, not as patient notification, and send it to the defined follow-up queue.

Model scenario: the connection drops after submission

This is a model scenario, not a real patient or deployment result. A verified patient asks for staff to review a repeat prescription already visible in the clinic system. The assistant captures the approved fields and sends one intake request. The connection drops before the system returns a response. The assistant reopens the case using the same transaction key and finds that the request exists with the status awaiting clinical review.

The system does not submit again and does not claim approval. It sends the clinic's neutral received message through the patient's approved channel and keeps the case assigned to the clinical queue. Later, an authorised person records the decision. Only then may the workflow communicate that verified outcome, with a route back to staff if the patient has questions.

Run acceptance tests before using the workflow with patients

Test with synthetic records and include failures, not only the happy path. Privacy, clinical, pharmacy, security and operational owners should agree the expected result for each case. A test passes only when the source system, patient message and staff queue show the same truthful state.

Measure repair work and unresolved cases, not automated approvals

Useful measures include complete intake rate, identity failures, duplicate prevention, cases needing repair, time to staff acknowledgement, time to an authorised decision, failed notifications, reopened cases and requests still unowned after the agreed target. Review a sample of records to check that patient wording, source-system status and outbound messages agree.

Do not optimise for the number of requests the AI appears to complete. The safe outcome may be a clear stop and rapid handoff. Begin with a narrow set of repeat requests, named owners and a pause rule. Expand only after the clinic has examined failures and confirmed that staff can see, accept and close every exception.

• See the Anahera Med patient-service workflow
• Map health data and GDPR controls
• Design identity checks for phone actions
• Separate administrative follow-up from clinical review