Heidi II's Memory should be assessed by the scope of information it retains and the effect of correcting it, not by the label alone. Clinician preferences, practice instructions and patient-specific interpretations are different kinds of information. A useful system must make their boundaries clear before remembered content becomes a basis for future action.
The public documentation provides two distinct starting points: an earlier note-personalisation feature and the broader Memory proposition described at the September 2026 launch. Neither should be silently substituted for the other.
What the earlier documentation actually describes
Heidi's Memory and Defaults guide dated 21 July 2026 describes preferences for note generation, replacements and reusable snippets. It says users can update or delete those settings and distinguishes changes applied to an output, a session or future occurrences.
That is useful documentation of a specific customisation function. It is not evidence of unrestricted longitudinal patient memory, nor a complete specification of every capability subsequently announced under the Memory name.
In the 29 September 2026 Heidi II introduction, the company describes learning from direct instructions and corrections, including practice rules, clinical standards and formatting preferences. That is a broader published design claim. The practical questions below concern how its scope and correction behaviour should be demonstrated, not an assumption that every form of information is stored identically.
Separate preferences from facts and interpretations
A spelling preference is not a patient fact. A practice's preferred document layout is not a clinical rule. A temporary instruction for one case is not necessarily a standing instruction for the organisation.
A proposed evaluation should therefore identify the category of each remembered item. It should establish whether the item came from an explicit user instruction, an approved organisational process or an inference drawn from previous activity. The user should know where it is expected to apply and who can change it.
The same wording can have different consequences depending on scope. An instruction to use a particular destination for one patient should not automatically become a rule for every referral of that type. Conversely, an approved change to a practice process may need to reach more than the current output.
A fictional process that changes after being remembered
Imagine a practice that previously sent a particular type of administrative request to one team. Responsibility moves to another team, and the approved process changes. A clinician corrects the destination in the latest prepared letter.
Has the correction changed only that letter, the saved preference or every pending routine using the old destination? The answer determines whether the system has learned the current process or merely produced a correct-looking output once.
This is a fictional implementation scenario, not evidence that Heidi II has misrouted correspondence. It illustrates why correction needs an explicit scope. The clinician should be able to distinguish a one-off exception from an instruction intended to govern future work.
Historical information can remain true but no longer govern action
A previous instruction does not become false merely because it has been superseded. It may remain relevant for understanding why earlier actions occurred. The system nevertheless needs to distinguish that historical record from the instruction that applies now.
A useful design would preserve the ability to inspect the earlier version without continuing to treat it as current authority. The date of entry alone may not settle this, because a later note could describe an older event or an exception rather than a replacement rule.
We would therefore ask how the system identifies supersession, handles conflicting instructions and requests clarification when scope is uncertain. These are proposed assessment questions, not claims about a verified Heidi II version-management interface.
Follow the correction through its dependencies
Correcting a remembered item is only the first step. The important operational question is what depends on it. Pending tasks, prepared summaries, saved routines and previously generated material may each contain the old assumption.
A practice should establish which of those items update automatically, which require renewed review and which cannot be changed because an external action has already occurred. The system should not imply that editing the latest answer reverses a message already received or a decision already communicated.
The appropriate response may include cancelling pending work, flagging completed work for review or notifying a responsible person. Different consequences require different recovery mechanisms. An evaluation should report them separately rather than describing everything as a successful memory update.
Make the basis of future behaviour inspectable
A proposed inspection view would show the remembered content, originating source, date, intended scope and approval status. It would distinguish user-provided information from inferred preferences and make the effective current instruction clear.
The objective is not to expose every internal technical representation. It is to let the user understand the basis of consequential future behaviour. Someone should be able to answer why the system is applying a rule and whether that rule belongs to this clinician, this practice or this particular case.
This also matters when staff change. A new team member should not need to discover hidden preferences by repeatedly correcting outputs. The organisation should know which rules are personal conveniences and which are shared operational instructions.
Test forgetting as carefully as remembering
A controlled evaluation could establish a fictional preference, apply it to a test task and then change or remove it. Evaluators would inspect a fresh task, a previously prepared task and a scheduled routine to see where the change takes effect.
Another test could introduce conflicting instructions with different scopes. A third could remove the user's authority to change an organisational rule. The desired response should be defined beforehand, including when the system should ask for clarification rather than choose silently.
The assessment should distinguish deletion of a preference from deletion of clinical records. Those are different operations, and Heidi's September 2026 launch materials should not be interpreted as authorising unrestricted record deletion. We have not run these tests against Heidi II, so no correction-propagation results are claimed here.
A useful memory is a governable memory
The strongest case for Memory is not that the clinician never needs to repeat an instruction. It is that repeated work becomes more consistent while its governing assumptions remain understandable and correctable.
For a formatting preference, a simple editable setting may be sufficient. For a practice instruction affecting future actions, source, scope and change management matter more. For patient information, buyers must establish the actual data and access arrangements rather than infer them from a familiar product term.
As of Heidi's September 2026 launch, the new capabilities are not available in the UK or EU. Eligible organisations elsewhere should evaluate the specific implementation offered to them. A name such as Memory describes a proposition; inspectable behaviour determines whether it can be relied upon.
Frequently asked questions
Is Heidi II Memory just the earlier snippets feature?
The July 2026 guide describes note-personalisation settings, while the September launch describes a broader learning-from-instructions proposition. The earlier guide should not be treated as a complete specification of Heidi II.
Does Memory imply unrestricted access to a patient's entire history?
No, that cannot be inferred from the name. The actual data scope, connections, permissions and retention arrangements need product-specific confirmation.
Does editing an output correct every future action?
Not necessarily, because a local edit, a saved preference change and an update to pending workflows are different operations. Their relationship should be demonstrated rather than assumed.