Potentially, but only if it coordinates what happens after an agreed message or action leaves the consultation. Sending a summary is not the same as confirming delivery, arranging a review or resolving a reply. As of 27 September 2026, those are questions for the anticipated Heidi Work product, not established capabilities.
This pre-launch analysis examines patient follow-up as a possible workflow. Heidi's 30 September event material explicitly foregrounds follow-up work, but it does not establish whether Work will offer one-way messages, administrative conversations, telephone calls or clinically contextual dialogue. Those possibilities must remain separate.
Begin with the plan the clinician and patient actually agreed
Consider a fictional consultation ending with three agreed actions. The patient will receive a written summary of the discussion. The practice will arrange a review. An administrator will check whether an external document has reached the practice before that review takes place. These are illustrative administrative arrangements, not a treatment protocol or an observed Work session.
The actions are related but not interchangeable. Producing the summary does not book the appointment. Booking the appointment does not establish that the external document arrived. A useful follow-up workflow would represent each obligation and the dependencies between them.
It would also preserve the distinction between a suggestion and an agreement. A clinician mentioning that a review might be useful does not necessarily authorise the system to book one. If the patient declines an offered arrangement, the next step should reflect that decision rather than continue an earlier draft plan.
Outbound communication is already part of the baseline
Heidi's Ask Heidi documentation, checked on 27 September 2026, already describes email summaries sent from a session. That establishes an existing outbound capability in the documented product context. It does not establish a universal patient-messaging service, availability on every plan or a Work-specific communication channel.
This matters because a launch demonstration that sends an email is not, by itself, proof of a new follow-up category. The meaningful addition would need to concern the scope, context or continuation of the workflow: what triggers the communication, who approves it, where replies go and how outstanding work is resolved.
Existing regional and account restrictions also matter. Public descriptions of Ask Heidi should not be transferred automatically to the anticipated Work product or to every national deployment. The new offering has its own unresolved access questions.
Closing the loop requires more than a sent label
A sent message records an action by the sender. Delivery information, where available, records something about transmission. Neither proves that the intended person read, understood or acted on the content. Those distinctions should shape the workflow rather than appear only in a disclaimer.
For the fictional review arrangement, the endpoint might be a confirmed appointment rather than an email dispatched. For the missing document, it might be receipt of the correct information rather than a reminder sent to another service. For the patient summary, the intended endpoint may simply be approved information delivered through the agreed route, with a separate process for questions.
A useful system would let the organisation define the endpoint for each task and show what evidence supports it. It should not create a reassuring global completion status by combining several different meanings of done.
| Follow-up event | What it establishes | What it does not establish |
|---|---|---|
| Summary prepared | Content is available for review | Approval or transmission |
| Message sent | A sending operation occurred | Successful delivery or comprehension |
| Patient replies | A response has been received | That every agreed action is complete |
| Review booked | An appointment arrangement is recorded | That the patient attended |
| Required information received | The specified document or information arrived | That a clinician has reviewed and acted on it |
This is a proposed interpretation framework, not a description of Work's status labels.
Three possible patient-facing boundaries
The narrowest model is approved one-way communication. A clinician checks the content and recipient, then authorises transmission. Replies might remain in an existing organisational inbox. This could still save effort if it removes repeated copying and preserves a clear record of what was sent.
A second model is administrative two-way communication. The system might help clarify appointment preferences, request an agreed document or record whether a logistical action was completed. That would require rules for recognising when a reply no longer concerns the authorised administrative task.
A third model would allow a more clinically contextual interaction. That is a materially wider product scope, because a new message can introduce information that changes the original plan. The reviewed pre-launch material does not establish that Work will provide this model, and the word follow-up should not be used to imply it.
Heidi's September supervised-action announcement supports analysing work beyond documentation. It does not resolve which of these patient-facing boundaries the forthcoming product will adopt.
What happens when the patient does not reply?
Non-response should be an explicit state, not silently equated with success. The organisation needs to decide which tasks require further contact, who owns that decision and what happens when the preferred communication route is unavailable. A software reminder can implement an agreed process; it should not invent the clinical significance of silence.
A fictional pilot might include an outdated contact detail, a patient who cannot use the proposed channel and a response received after the responsible clinician has finished work. The evaluation would ask whether each case reaches an identified person with enough context to act.
The patient-facing wording should also make the service boundary understandable. Who will read a reply? During which operating period? Is the channel suitable for questions, administrative responses or only receipt of information? These are implementation questions, not assumptions that a particular supplier has already answered them.
Changed circumstances require a new decision
Suppose the fictional patient replies that the previously agreed review arrangement no longer suits them and adds a new concern. An administrative workflow can identify the need for human attention without being treated as authorised to resolve the concern independently.
The system would need to preserve the original plan, the new information and the fact that further review is pending. It should not quietly rewrite the clinician's instructions or mark the entire sequence complete because a response has arrived.
A useful demonstration would show where that handover occurs. Does the reply enter an existing monitored queue? Is the original task paused? Can the responsible team see that the patient has supplied new information? A realistic test would assess those transitions, not merely whether a conversational response sounds empathetic.
Evaluate communication and completion separately
A proposed pilot should record eligible follow-up episodes, approved messages, delivery information where available, responses requiring review and unresolved actions at the agreed endpoint. It should also record manual work that remains, including correcting contact details and reconciling responses in another system.
The denominator matters. Reporting messages generated cannot establish follow-up completion. Reporting completed administrative episodes cannot establish improved clinical outcomes. A patient satisfaction response is useful feedback, but it answers a different question again.
No such pilot was conducted for this article. Any future results should come from an actual authorised evaluation with defined workflows, access conditions and outcome definitions, not extrapolation from launch-stage examples.
What UK readers should take from the hypothesis
On 27 September 2026, Heidi's waitlist excluded the UK and Europe. This article is therefore not a recommendation that a UK practice can deploy Work now. The workflow questions remain useful for assessing follow-up software generally, while existing Heidi services need separate consideration.
Clinical reference and professional learning also remain distinct from patient communication. Per iatroX product information, September 2026, free Ask-iatroX provides linked clinical sources; its learning tools support structured practice. There is no claimed integration with Heidi Work or automatic monitoring of patient replies.
The potential advance is not that an AI can produce another patient-facing paragraph. It is that the practice can see which agreed actions have happened, which have not and who is responsible for the difference.
Frequently asked questions
Could Heidi Work contact patients?
Patient follow-up is a plausible area of the anticipated product, but Work-specific communication capabilities were not established in the public material reviewed on 27 September 2026. Existing Ask Heidi email-summary documentation should not be treated as confirmation of a new patient-contact service.
Would it make phone calls or send messages?
The reviewed pre-launch sources do not establish Work's supported communication channels. Telephone calls, approved messages and two-way conversations should be assessed as separate functions rather than inferred from the term follow-up.
What should happen when a patient does not respond?
The workflow should retain an unresolved state and follow an organisation-approved process with a named human owner. Lack of a reply should not automatically be treated as understanding, agreement or completion.