A referral can be beautifully written and still be sitting in the wrong place. The consequential question for Heidi Work is whether it could help move an approved decision through the remaining administrative stages, rather than simply produce the letter. Work-specific referral submission and tracking remain unconfirmed as of 27 September 2026.
This is pre-launch workflow analysis, not a product review. The anticipated Work offering is being discussed ahead of Heidi's 30 September Melbourne reveal. Its public direction supports examining supervised completion of work, but no reviewed source establishes an end-to-end referral service under that product name.
Define the referral before asking whether it is automated
A referral workflow begins with a clinician's decision, but the appropriate administrative endpoint depends on the service. It may involve selecting a destination, assembling supporting information, preparing the required material, obtaining approval, submitting it and tracking the response.
Each stage can contain a separate decision. The intended specialty does not necessarily identify the correct receiving service. A correct letter does not establish that the required form was completed. A form submitted through one route may not meet another service's process.
For procurement purposes, the organisation should define which of those stages it wants the software to perform. A tool that prepares an accurate submission pack could be useful even if a clinician retains the final submission step. The claim becomes misleading only when preparation is described as completed referral management.
The Heidi Tasks documentation, checked on 27 September 2026, already supports a document-generation baseline. The Work hypothesis should therefore concern additional operations or reduced handovers, not the invention of AI-assisted letter writing.
A fictional referral with a polished but unfinished letter
Imagine a clinician who has agreed a referral after an outpatient review. The letter is ready, but the receiving service requires an additional document and a particular submission route. An administrator must locate the attachment, confirm that it belongs to the correct encounter, enter the necessary information and return the pack for approval.
The draft has saved writing time. It has not removed the retrieval, destination checking, review or transfer work. If the team measures only time to produce the letter, those remaining stages disappear from the evaluation even though they still occupy staff time.
Now imagine that the patient's preferred destination changes before submission. The existing letter may still be clinically appropriate, but the route, recipient and supporting requirements need another check. The task should not proceed on the strength of an approval attached to the previous destination.
This is a synthetic administrative scenario, not a treatment recommendation or a report of Heidi behaviour. Its value is that it exposes the work hidden behind the word referral.
What could Work plausibly automate?
Candidate capabilities include filling established forms, assembling approved attachments, preparing a submission, performing an authorised transfer and recording status. These are hypotheses, not announced Work features.
A narrower implementation might prepare the pack while leaving submission to the clinician. A more extensive implementation might submit through a supported connection and record the response. A longitudinal implementation could retain responsibility for identifying an unacknowledged or rejected referral and returning it to the team.
The September announcement describes movement into supervised action, which makes these useful questions to ask. It does not prove that referral destinations, forms or external systems have been implemented. Heidi's announcement, published on 22 September 2026, should be read as strategic context rather than a referral specification.
Submission, acceptance and attendance need separate states
An evaluation should record the furthest verified stage rather than award one tick for referral support. The same applies to the interface presented to clinicians.
| State | Suitable evidence | Remaining question |
|---|---|---|
| Pack prepared | Required draft and attachments are assembled | Has an authorised person approved the current version? |
| Submission authorised | Approval records the content and destination | Has the operation actually occurred? |
| Submitted | The receiving route confirms submission or provides a receipt | Has the service accepted or triaged it? |
| Acknowledged or accepted | The relevant receiving response is recorded | Are further actions required? |
| Appointment arranged | An appointment status is available | Has attendance or subsequent care occurred? |
These proposed states are not universal rules for every service. The organisation must identify its own endpoint and the evidence available through the relevant route. A system should not imply access to downstream status that the receiving service does not provide.
For a bounded submission product, stopping after a verified receipt can be entirely reasonable. For a referral-tracking product, the same endpoint would leave part of the advertised job unfinished. The quality of the claim depends on that boundary.
The exception that matters most may be an uncertain result
Missing information is relatively visible. A more difficult situation occurs when an operation may have succeeded but the sending system did not receive confirmation. Retrying immediately could create a duplicate. Marking the work complete without evidence could leave an unsent referral hidden.
A proposed test should therefore include a connection interruption around submission. Ask whether the system can query the authoritative destination, identify an existing receipt or expose the uncertainty to a named operator. The appropriate response depends on the integration; the interface should not invent certainty to hide that limitation.
Rejected submissions deserve similar attention. A rejection may require a corrected attachment, a different route or a new clinical decision. Those responses should not be collapsed into one automatic retry. The system needs to distinguish an administrative correction it is authorised to prepare from a substantive change requiring professional review.
Who owns the referral when automation stops?
The task owner should remain identifiable even when a process crosses systems or organisations. An internal task assignment does not establish that the receiving service has accepted responsibility. Equally, an external service acknowledging receipt does not automatically remove every local follow-up obligation.
A useful pilot would test absence and handover. Suppose the clinician who approved the pack is no longer working at the practice when a query returns. Can the covering team locate the approved material, understand the status and identify what decision is now needed?
The goal is not to make the software independently answer every question. It is to prevent an exception from becoming ownerless. That would be an important workflow improvement even when a human still resolves the substantive issue.
Measure the whole route to the agreed endpoint
A proposed evaluation should compare like-for-like completed referrals or submission episodes. Record staff time for preparation, review, corrections, transfer and exception handling. Separately record elapsed time from the agreed starting point to the defined endpoint.
Keep tasks held appropriately out of a simplistic success-versus-failure narrative. A referral paused because required information is missing is different from a referral lost after an interface error. Record the reason and who owns the next step.
A fuller comparison would also examine duplicated submissions, missing attachments, inappropriate destination changes and cases requiring manual reconstruction. A reduction in drafting time can be worthwhile, but it should not be presented as proof of end-to-end improvement without those observations.
No referral test was run for this article. Any future numerical claims should come from actual authorised evaluation, with the denominator, workflow, product version and observation period stated.
What a prospective buyer should ask after the launch
Request a demonstration of the exact referral type and receiving route the organisation uses, with synthetic information. Ask which stages are supported, which approvals are required, what evidence confirms submission and how ambiguous outcomes are recovered.
Then confirm availability. The Heidi waitlist, checked on 27 September 2026, excludes the UK and Europe. That makes Work deployment in those markets a future availability question, not an assumption justified by a global demonstration. The restriction should not be extended to existing Heidi documentation products.
Clinical appropriateness remains separate from administrative completion. Per iatroX product information, September 2026, Ask-iatroX offers free source-linked clinical reference. It does not select local referral destinations, submit referrals or operate as an integrated checking layer for Heidi Work.
The most useful launch evidence would show where the letter goes, what confirms its arrival and who receives the work when something does not go to plan. That is the difference between generating a referral document and managing a defined part of the referral process.
Frequently asked questions
Could Heidi Work send referrals?
That is a plausible supervised-workflow use case, but Work-specific referral submission was not established in the public material reviewed on 27 September 2026. A demonstration would need to identify the receiving route, authorisation and confirmation process.
How is referral automation different from generating a referral letter?
Letter generation prepares one output. A broader workflow may also assemble information, obtain approval, submit through an authorised route and track the relevant response.
What should happen when an automated referral cannot be completed?
The workflow should preserve the unresolved status, explain the obstacle and return it to a named person. Where submission may already have occurred, the destination should be checked before a retry risks creating a duplicate.