Heidi may be preparing to launch a supervised workflow product that helps complete the work generated by a consultation, rather than simply documenting it. Heidi Work is the anticipated name, not a confirmed specification. Its Melbourne product reveal is scheduled for 30 September 2026; the precise functions, packaging and release terms remain unconfirmed.
This is pre-launch analysis dated 27 September 2026, based on public announcements and documentation, not a product test. The central hypothesis is specific: Heidi could move further from identifying an action towards carrying out an authorised step and showing what happened afterwards. That interpretation fits the direction of its current waitlist and September announcement about supervised action.
What is expected at the Melbourne launch?
The public listing for Heidi Handover: Live in Melbourne, checked on 27 September 2026, describes a first public look at a new product on Wednesday 30 September. It identifies Handover as a launch event series. Handover should therefore not automatically be treated as the product name, and an event date should not automatically be treated as the date every customer receives access.
The event material foregrounds preparation before appointments, follow-ups and care plans. Those examples support a hypothesis about work surrounding an encounter. They do not establish that all three workflows will be available at launch, which systems they will connect to, or how much of each process the software will perform.
There is also an immediate regional qualification. As checked on 27 September, Heidi's waitlist excludes the UK and Europe, while its September financing release says the coming capabilities will not be available in the UK and EU. Neither statement means that Heidi's entire existing platform is unavailable there. The reason for the limitation is not established in those sources.
Three plausible shapes for Heidi Work
The first possibility is an execution layer for existing tasks. A clinician could review an identified action, approve a prepared next step and allow the system to perform a bounded operation. The important addition would not be another generated document. It would be an action outside the document editor, followed by an intelligible status.
The second possibility is a workspace coordinating unfinished work. Its value would lie in bringing related actions, responsible people, dependencies and exceptions into a coherent view. Existing Heidi Tasks already includes a cross-session task list, so persistence alone would not establish a new category. The stronger version of this hypothesis would connect that list to additional actions and clearer evidence of completion.
The third possibility is a broader assistant spanning preparation, the encounter and follow-through. It might assemble relevant information before an appointment, help prepare outputs afterwards and coordinate what remains outstanding. This would be a larger product scope, but a broad scope is not necessarily a better initial release. A dependable, narrow workflow could be more useful than an extensive interface with many manual handovers.
These are alternative product interpretations, not three confirmed components. The launch could combine elements of them, or reveal a narrower proposition. The useful question is which interpretation the demonstrated work actually supports.
Which workflows look most plausible?
Preparation, follow-up and care-plan administration deserve attention because Heidi itself has placed them in the event narrative. A pre-consultation workflow could assemble a relevant brief. A follow-up workflow could coordinate an agreed communication and its unresolved responses. A care-plan workflow could keep track of actions across more than one appointment.
The evidence is weaker for more ambitious possibilities. Autonomous patient conversations, independent clinical decisions and prescribing are not established Work capabilities in the public material reviewed for this article. Nor does mentioning patient communication establish whether a product sends approved messages, conducts administrative dialogue or responds to new clinical information. Those would be materially different behaviours.
A useful demonstration should therefore show the boundary of the proposed assistance. Is the system working from an explicit clinician instruction? Is it suggesting an action for consideration? Can it proceed only after approval? What information is it allowed to use? Describing all of these possibilities as an agent would conceal the practical differences.
What would make it more than a scribe update?
Consider a fictional consultation in which a clinician agrees to provide a referral. The note records the decision. A task makes the work visible. A document generator prepares a letter. A submission workflow transfers the approved material through an authorised route. A tracking workflow records whether the receiving service has acknowledged it.
Each stage has value, but each finishes a different job. A letter can be complete while the referral remains unsent. A submission can succeed while acceptance remains unresolved. Acknowledgement does not mean an appointment has occurred.
| Stage of work | What has actually happened | What may still remain |
|---|---|---|
| Identified | A potential or agreed action is visible | Review of whether it should proceed |
| Prepared | The required material has been assembled | Approval and transfer |
| Authorised | A responsible user has approved a defined action | Execution through the permitted route |
| Executed | A specified operation has occurred | Confirmation of its result and any subsequent steps |
| Followed through | The relevant outcome or exception has been recorded | Further work if the endpoint was only one stage |
This is an analytical framework, not a Work feature table. It also prevents unfair comparisons with existing tools. Heidi's Tasks documentation, checked on 27 September 2026, already describes document generation and task management. The novelty would have to be assessed against that baseline, not against an imaginary transcription-only product.
The most informative demonstration may be an exception
A straightforward task can conceal the supervision required. A more revealing example would include a changed instruction, a missing document or a destination that does not return a clear receipt. The question would be whether the system identifies the unresolved state and returns it to the appropriate person.
A particularly useful test would involve an encounter that creates no follow-up work. A system should not need to generate an action merely to look productive. Correctly leaving the record without an unnecessary task would be a valid outcome in that proposed evaluation.
Likewise, a clinician changing their mind should not have to hunt through multiple prepared outputs to prevent an outdated instruction from proceeding. The product would need to make clear which approvals remain valid and which work has stopped. These are design questions for the launch, not reports of observed defects.
What remains unknown before the reveal?
As of 27 September 2026, the reviewed public material does not establish a Work-specific tariff, an exact list of supported operations, a complete integration matrix, or the access terms for existing subscribers. It also does not establish a universal approval model or general availability outside the stated excluded regions.
A successful demonstration would answer some of those questions; release documentation would still need to answer others. A feature shown in a controlled environment may require an organisational contract, a particular integration or a restricted pilot. Conversely, a capability not shown on stage should be described as not demonstrated, not assumed absent.
The strongest pre-launch conclusion is therefore about direction, not performance. Heidi appears to be addressing the work left after an encounter. Whether Work meaningfully reduces that burden will depend on what it completes, how it handles uncertainty and what remains for the team.
Where clinical knowledge still fits
Completing an instruction and deciding that the instruction is appropriate remain different activities. Per iatroX product information, September 2026, Ask-iatroX provides free source-linked clinical reference grounded in NICE, CKS, SIGN and SmPC information from emc. It is not an announced integration with Heidi or a replacement for workflow software.
iatroX's separate articles on existing Heidi Tasks, the launch demonstration watchlist and patient follow-up examine those distinctions in more detail. The central question remains simple: after the software says the work is done, what has actually happened?
Frequently asked questions
What is Heidi Work expected to do?
The strongest pre-launch hypothesis is supervised assistance with work surrounding consultations, potentially including preparation and follow-through. Its exact capabilities and final product packaging are not confirmed in the public material reviewed on 27 September 2026.
When is Heidi's next product announcement?
The public Heidi Handover listing schedules the Melbourne reveal for 30 September 2026. That is an announcement event, not confirmation of general availability for every region or subscription.
Is Heidi Work available yet?
A public waitlist was visible on 27 September 2026, but the reviewed material did not establish general Work availability or purchase terms. The waitlist excludes the UK and Europe, without implying that all existing Heidi services are unavailable there.