skip to main content
iatroX JournalClinical AI

When a Patient's Muse Meets Their Doctor's Heidi II, Who Keeps the Plan Straight?

Featured image for When a Patient's Muse Meets Their Doctor's Heidi II, Who Keeps the Plan Straight?

The plan should remain an agreement between the patient and the responsible clinical team, not an accidental compromise between two automated task lists. Agents could help communicate and organise it, but a requested change, an operational update and an agreed clinical revision need to remain distinct. Clear ownership and visible versions matter more than apparently seamless conversation.

This is a proposed future scenario based on documentation checked on 29 September 2026. It is not a description of a confirmed Heidi-Muse integration. iatroX publishes this comparison and includes its own reference and learning tools as complementary resources, not as a service synchronising either company's agents.

Two agents may start with different versions of the truth

HealthEx's announcement of 8 September 2026 describes patient-controlled sharing of health records with Muse in the United States. Heidi's 28 September 2026 announcement concerns agents acting around practice workflows. Those starting positions make overlapping coordination plausible without establishing that the products currently communicate with each other.

A patient's account might include a practical constraint that has never been entered into the practice record. The practice's account might include the reason an appointment needs a particular format, while the patient only sees the date. A summary on either side could be accurate as far as it goes and still omit what the other needs to understand.

The resulting disagreement would not necessarily be a hallucination. It could arise because two systems optimise different instructions using different information. A useful design should make that mismatch visible rather than quietly resolve it in whichever direction allows the task to finish.

A changed circumstance is not simply a refusal

Consider a fictional patient who agreed to an in-person follow-up because the clinician wanted to reassess a finding through examination. The patient's transport arrangement subsequently falls through, and they ask their personal agent to seek a remote appointment instead.

From the patient's side, that request is practical: they are trying to obtain care in a form they can access. From the practice's side, the original format has a purpose that may not be satisfied by automatically changing the appointment type.

A poor handover would compress the situation into "declined appointment" or "patient prefers remote". The first could imply a decision the patient has not made. The second preserves a preference but loses the reason it matters and the clinical purpose that needs reconsideration.

A more useful message would distinguish the existing plan, the transport problem and the requested alternative. It would leave the clinical team and patient able to discuss an appropriate revision rather than treating the exchange as a scheduling problem with a single obvious answer.

This is a hypothetical test case, not advice about the management of a particular patient and not a claim about either product's current behaviour.

The plan needs more than a due date

A proposed shared plan should identify the intended outcome, the current action, the reason for that action and who is responsible for the next step. It should also distinguish the patient agreeing with a plan from a system merely recording that a message was delivered.

The version matters. A change request should refer to the plan it seeks to amend, rather than silently overwriting an instruction in another system. If the clinical team accepts a revision, both sides need a clear account of what changed and what remains unchanged.

Uncertainty should survive the handover. A provisional interpretation should not become a confirmed finding because one agent compressed the text. Likewise, an action discussed as a possibility should not become an instruction simply because it appears in a task list.

None of this requires patients to read technical logs. The aim is a short, intelligible account: what we agreed, why, what has changed and what happens next. The more technical record can preserve supporting sources and timestamps without forcing every user to reconstruct the entire exchange.

Acknowledgement is not agreement

An automated reply saying a request has arrived may be useful, but it does not establish that someone has reviewed its clinical implications. A system that treats that acknowledgement as acceptance could update the patient's expectations before the practice has made a decision.

The reverse problem is also possible. The practice could update an internal task without communicating a meaningful answer, leaving the patient to assume the request is still outstanding. Both systems might display progress while neither person understands the same current plan.

An evaluation should therefore distinguish receipt, allocation, review and agreement. Where the next step depends on a person, the system should show who is expected to respond and avoid claiming the decision has already been made.

In the fictional transport scenario, the useful endpoint might be a revised appointment arrangement or a discussion about alternatives. It should not be defined merely as closing the original request. Closing a task while the patient remains unable to proceed would conceal the problem rather than resolve it.

Authority has to travel with the message

A patient-generated request is evidence of what the patient wants to discuss. It is not automatically a clinician-approved instruction. A practice-generated plan is an account of the clinical team's proposal or agreement, but it should not erase a patient's subsequent objection or changed circumstances.

Proxy arrangements add another reason for clarity. Where a family member or carer participates, the receiving side needs to know who is speaking and what authority they hold in that context. An agent should not infer broad permission merely because it can access a shared account or has previously handled another task.

The GMC's decision-making and consent guidance, checked on 29 September 2026, emphasises exchanging information and listening to patients so they can make informed decisions. The design implication here is to preserve that exchange rather than treating a completed automated interaction as its equivalent.

This is a professional principle informing the proposed design, not a claim that a specific technical format satisfies every jurisdiction's legal requirements.

Preserve disagreement rather than smoothing it away

The difficult information in an exchange may be its most important part. A patient who says the proposed action was not what they understood might be identifying a genuine misunderstanding. A statement that circumstances have changed may mean the original task needs reassessment rather than another reminder.

An agent should not be evaluated only on whether it produces a polite, coherent summary of the conversation. A stronger test asks whether it preserves the substantive disagreement and routes it to someone who can resolve it.

For example, a summary might report that the patient requested remote follow-up while omitting that they cannot travel at all. Another might preserve the transport difficulty but omit that the original visit was intended to include examination. Each version hides part of the problem from the next person.

The proposed handover should retain both. That need not make the message lengthy. It requires selecting the information that changes the decision, rather than optimising only for a clean status label.

Test the handover without pretending the integration exists

An educational or development team could simulate the two sides using fictional records and separate interfaces. The evaluation would concern the handover requirements, not a claim to reproduce a live connection between Heidi II and Muse.

Cases could include a corrected patient preference, a message referring to an older plan, withdrawal of permission, an unacknowledged revision and an interrupted exchange after one side has already updated its task. Raters could assess whether the current instruction, source of the change and unresolved decision remain clear.

A recovery case should test what happens when the original clinician is absent. Can another team member establish what has been agreed without repeating an action or treating an unapproved request as a settled plan? A concise handback should expose what was completed, what was only proposed and what needs human attention.

These are proposed tests, not results from either product. Findings would need to be published from an actual run with the simulated environment and scoring method identified.

Regional availability is not a technical detail

Heidi's launch documentation excludes its new capabilities from the UK and EU, while the HealthEx connection described here is US-focused. This September 2026 comparison must not be read as a deployment recipe for an NHS organisation.

The scenario remains useful because clinicians can already be asked to interpret patient-prepared information from many sources. The professional question is how to handle the content and authority of that information, not whether a recognisable technology company produced it.

As described by iatroX in September 2026, Socratic Tutor supports reasoning around attempted questions, while CPD tools help learners review and record professional learning. Those tools can support reflection on communication and interpretation; they are not a Heidi-Muse handover system or certification for supervising one.

Verdict by reader scenario

For patients, the useful personal agent is one that helps express the real obstacle and preserves access to a person, rather than simply maximising convenience within an outdated plan. For clinicians, the useful practice agent is one that distinguishes a requested change from an agreed revision and keeps the reason for disagreement visible.

For developers and buyers, the important integration test is not whether two systems can exchange messages. It is whether the people relying on them retain a shared, current understanding of the plan and know when human discussion is still required.

Frequently asked questions

Does this article describe a launched Heidi II and Muse integration?

No: the documentation reviewed on 29 September 2026 does not establish a direct integration. The article develops a future coordination scenario and requirements that could be tested independently.

Should a personal agent automatically optimise a clinical plan around convenience?

It can help communicate practical preferences and obstacles, but those should not silently override the purpose of an agreed clinical action. A material change needs an appropriate conversation and a clear revised plan.

What information is most important when the two sides disagree?

The current plan, its rationale, the patient's actual concern and the authority behind any proposed change should remain visible. A generic label such as "declined" is not a sufficient substitute for that information.

Turn communication and reasoning gaps into reviewed CPD learning →

More from the Journal