Separate reported earlier wording from the live terms checked on 2 November 2026, and distinguish access to Heidi from access to another vendor's system.
The argument over Heidi II and Best Practice has produced an awkward follow-up question: how does an AI-agent supplier describe automation directed at its own platform? It is a fair consistency test. It is also a question that becomes misleading when an earlier reported clause is presented as if it were the wording a reader can inspect today.
The public terms checked for this article on 2 November 2026 contain specific restrictions on automation rather than a universal prohibition on bots. That observation does not establish when the wording changed, whether an earlier clause governed a particular customer or what Best Practice must permit. The useful analysis compares the exact scope of each rule and asks whether either supplier offers a workable route for authorised access.
What prompted the question?
A 2 November report in The Medical Republic questioned Heidi's own anti-automation wording and reported executives acknowledging it needed refinement. The live primary terms reviewed here are narrower than the blanket wording described in that report. Neither a news date nor a displayed legal-page date identifies the version binding an existing customer.
The underlying Best Practice disagreement is covered in our dated dispute explainer. The present article addresses a different issue: how to read a supplier's rules without confusing criticism of a contract, technical product behaviour and an individual practice's access permission.
A consistency question can be useful even where two contracts are not identical. It can reveal whether a supplier is prepared to state objective requirements for others. But the argument needs the current text, the relevant customer agreement and the requested operation. A screenshot of one sentence cannot supply all three.
What the live Heidi documents actually say
The Master Services Agreement, displayed as dated 29 September 2026 and checked on 2 November, addresses automated access in clause 7.2.9. Its restrictions concern circumventing controls, accessing data outside Customer Data, systematically extracting Heidi Materials, unreasonable load or interference, and exceeding usage controls; it also refers to relevant APIs. This is purpose- and scope-based wording rather than a ban on every bot.
The Australian Terms of Use, also displaying 29 September, express a similar distinction in section 6. The introduction separately explains that an organisation's existing agreement continues to govern unless validly changed or adopted. A web page should therefore be treated as a document to compare with the practice's accepted terms, rather than proof that all customers have acquired the same revised contract.
Those are deliberately limited observations. They establish what the inspected pages say. They do not establish the text presented at an earlier signup, a customer's variation history or the outcome of a contractual dispute. A reader checking this later should repeat the document check, because public legal pages can continue to change.
Why a narrower clause matters
A restriction tied to conduct can support a more useful discussion than a rule triggered solely by the identity of the tool. For example, a request to retrieve a customer's own material through a documented interface raises different questions from bulk extraction of a supplier's proprietary content. A rate-limited administrative process differs from traffic that disrupts other users.
The distinction gives the customer something specific to ask about. Which material can be retrieved? Through which interface? At what rate? For which purpose? If the supplier objects, it can identify the boundary instead of relying only on the word automation. That is an argument for precise rules, not a conclusion that every proposed use is permitted.
There are limits to what the narrower wording settles. A clause does not demonstrate that a suitable export or integration interface exists. Nor does it describe all the other provisions that might apply to a particular activity. A practice still needs an affirmative account of the supported route rather than treating the absence of one broad prohibition as a complete implementation guide.
Access to Heidi and access through Heidi are different directions
The first direction is another tool accessing the Heidi platform. The second is Heidi acting inside a separate record system. Those operations involve different systems and agreements. Permission from the receiving system's supplier cannot be inferred solely from the AI supplier's willingness to perform an action.
Heidi's MSA clauses 7.3 and 7.4 separately address rights for third-party connections and review of consequential actions. Its allocation of responsibility also preserves liability for Heidi's own breach and non-excludable rights. It would therefore be inaccurate to say that the document either grants access to every EHR or removes every possible responsibility from Heidi.
For comparison, the live Bp Premier EULA contains a written-consent requirement for third-party access, expressly including bots and related automation. That is a different drafting approach. Reading the two pages side by side reveals a difference in wording; resolving a particular practice's rights requires the relevant agreements and facts.
A document reading record a practice can actually use
The following is an original proposed worksheet. It records what was inspected and what still needs an answer; it is not a legal determination or a test of either product.
| Entry | What the practice records | Why it changes the decision |
|---|---|---|
| Customer and agreement | Contracting entity, accepted document and any negotiated variation | A public page may not be the governing agreement |
| Document observation | URL, visible date and date checked, with a retained copy | Separates what was observed from assumptions about timing |
| Direction of access | Tool entering Heidi, or Heidi entering another named system | Identifies whose permission is being requested |
| Exact purpose | The task, material involved and expected destination | Prevents a broad product label substituting for scope |
| Requested route | Named interface and the supplier's supporting instructions | Distinguishes an available mechanism from assumed permission |
| Open issue | The precise clause or operation needing clarification | Makes a support response answerable |
| Decision and revisit point | Responsible person, written reply and trigger for review | Stops an unresolved assumption becoming a permanent workflow |
Suppose a fictional clinic wants to retrieve its own completed notes into another application. The useful enquiry would identify the material, destination and supported method, then ask how the relevant agreement treats that operation. It would not ask merely whether bots are allowed. This article does not propose attempting the activity while that answer remains uncertain.
A second clinic might want Heidi to prepare a document using material in Bp Premier. Its enquiry has a different receiving platform and permission question, even if the same people own the records in both examples. The worksheet makes that difference visible before a supplier discussion becomes an argument about slogans.
The strongest case for challenging Heidi
An agent supplier benefits from predictable access to other systems. It is reasonable to ask whether it offers equivalent clarity to customers and developers seeking access to its own platform. A restrictive label without objective criteria could leave others facing the same uncertainty it criticises elsewhere.
The useful challenge is practical: publish the allowed functions, access requirements and review process, then explain how a supplier can satisfy them. Customers should be able to distinguish protection of a service from an unnecessarily difficult route to their own material. That standard can be applied consistently without claiming the two platforms perform identical jobs.
Historical wording can also matter. If a practice accepted a broader clause, a narrower public page does not by itself answer its question. The practice needs to know whether the change applies to its agreement and whether any associated functionality is supported. Precision about the current page should not erase a legitimate enquiry about an earlier contract.
The strongest case against a simple hypocrisy verdict
Every software service needs boundaries around unauthorised access, disruption and extraction of material a customer does not own. Supporting AI agents elsewhere does not logically require accepting those activities on one's own platform. The existence of an automation restriction therefore cannot, by itself, settle whether a supplier's interoperability argument is inconsistent.
The better comparison examines proportionality. Does the rule address a defined problem? Can a legitimate customer task proceed through a supported route? Is there a transparent way to resolve uncertainty? An open-sounding policy with no usable interface may be less helpful than a controlled interface that meets the task. Conversely, an interface limited to irrelevant functions may not address a genuine access need.
These are evaluative questions, rather than findings that either company has passed or failed a common standard. No shared conformance assessment was conducted for this article. The important practical result would be written scope that a practice can rely on when choosing its workflow.
What this means for a clinician's tool stack
The terms debate is a reason to describe each purchase by its actual job. Record software, documentation assistance and structured learning can be selected on their own requirements. A clinician should not have to treat a disagreement over one agent route as a verdict on every useful supporting tool.
iatroX offers a particularly clear role for source inspection and education: use a question arising from clinical work to examine the supporting evidence and retain the reasoning. Its Australian educational guidance library states the source and scope of individual summaries, while its Tutor works in the context of an answered exam question. That provides a concrete complement to documentation, without an assertion that iatroX controls Bp Premier or grants third-party access.
The practical response to the bot-rules story is therefore to retain the distinction between a reported earlier clause, an inspected current page and the practice's own agreement. Then ask each supplier the same precise question: what supported route meets this named task, under which written terms?
FAQs
Does Heidi currently ban every bot or AI agent?
The live MSA clause 7.2.9 and Australian Terms section 6 checked on 2 November 2026 restrict specified uses of automation rather than every bot. Check the version and agreement relevant to your organisation before drawing an operational conclusion.
Does the date on Heidi's legal page show when its wording changed?
No. The inspected pages display 29 September 2026, but that does not establish the timing of an edit or when particular terms took effect for a customer. Retain the accepted documents and request clarification where versions differ.
Do Heidi's terms override Best Practice's access rules?
They do not establish permission from Best Practice. The relevant suppliers' agreements, the particular function and any written approval must be considered separately.
Explore iatroX's approach to source-grounded reasoning when choosing the knowledge and learning component of your clinical workflow.