What each company is arguing, what the public evidence establishes, and why Scribe connectors and computer agents need separate treatment.
The Best Practice-Heidi II dispute concerns who can authorise an AI agent to operate a clinical software system. It also raises a more immediate question for Australian general practices: does a disagreement about a new agent mean that their existing scribe workflow must change? Those questions deserve separate answers.
Best Practice here means Best Practice Software, the supplier of Bp Premier, rather than the BMJ Best Practice reference product. Heidi II, sometimes searched as Heidi 2, extends Heidi's proposition beyond consultation notes into administrative assistance. This explainer was checked on 2 November 2026. Its central distinction is between a documented Scribe connection and the additional computer-agent access in dispute.
The short chronology and the limits of the evidence
Heidi announced its new Agents and related capabilities in a company release on 28 September 2026. That announcement establishes the launch proposition, rather than independent evidence that a particular practice workflow is permitted or reliable.
On 29 October, The Medical Republic reported that Best Practice CEO Craig Hodges told customers Heidi II lacked the prior written consent required for use with Bp Premier. The reported concerns covered clinical information integrity, patient data protection and regulatory obligations; clearer automation wording was planned for Oxford SP2. Heidi CEO Dr Tom Kelly disputed the criticism and argued that attempts to obtain reasonable access had encountered an opaque process. The report also said Hodges did not offer a view on Heidi II's regulatory classification. This is reporting of the companies' positions: the original customer email, confidential negotiations and a court's interpretation were not independently established for this article.
The live public Bp Premier EULA, checked on 2 November, expressly includes bots, scraping tools and robotic process automation within its third-party consent rule. It separately recognises customer ownership of Customer Data. The page alone does not establish when that wording appeared or which agreement governs an individual practice.
Why an existing Heidi connection changes the question
Best Practice still has a public Heidi Health partner entry describing a scribe compatible with Bp Premier. Heidi's Australian integration overview describes appointment synchronisation and clinician transfer of the note. That documented scope is materially narrower than an agent navigating other software.
An appointment connection does not demonstrate permission for every function sold under the same brand. Conversely, an objection to a computer agent should not be converted into a claim that every Heidi service has disappeared. A practice should identify the precise installed function before deciding what this dispute changes. Our connector and permission guide examines that boundary in more detail.
Consider a fictional practice that uses Heidi to draft a consultation note, checks it and pastes it into Bp Premier. A proposed expansion that asks an agent to inspect several charts and prepare outstanding paperwork introduces different operations and dependencies. The value of the first workflow is not evidence for the permission or reliability of the second. Nor does uncertainty about the second establish that the first should be abandoned.
A claim register for reading the dispute
The following is an editorial reading aid, rather than a legal opinion or a report of product testing. It separates an observable source from the conclusion a practice can reasonably draw.
| Question raised by the dispute | Source to inspect | Practical consequence | What remains unresolved |
|---|---|---|---|
| Which activity is being challenged? | The dated report and the practice's own correspondence | Name the proposed agent operation before changing services | Exact scope of any notice applying to that practice |
| What connection is currently documented? | Heidi's Best Practice setup help | Compare the installed configuration with those instructions | Any separately agreed additional permission |
| Who owns the data? | The applicable Bp agreement | Preserve the practice's data rights in the discussion | Which software access methods are contractually permitted |
| Who supports a failed operation? | Both suppliers' written service descriptions | Allocate investigation and recovery before expansion | Responsibility for failures crossing the two products |
| Does the proposed activity work dependably? | A scoped demonstration and appropriate evaluation evidence | Assess the actual task and destination | Performance beyond the demonstrated conditions |
The table prevents one strong argument from doing work it cannot do. Data ownership is relevant to portability and choice, but does not describe the permitted software interface. A working demonstration shows an action can occur, but does not establish permission. A permitted connection defines an access route, but does not prove that every generated sentence is clinically appropriate.
Best Practice's strongest case
A record platform has a legitimate interest in knowing how third-party software interacts with its application. A computer agent might move among patients, screens and documents rather than submit a single bounded request. When something goes wrong, the practice needs to distinguish an incorrect instruction, a mistaken selection, an unavailable field and a completed action that was misunderstood.
Defined interfaces can make those boundaries easier to document. A supplier can specify supported versions, allowed operations and the information needed to investigate a failure. Controlled change also matters: a routine that depends on an interface should not become an invisible dependency that nobody owns when the host application changes.
This is the strongest argument for control because it concerns a concrete support problem. Its limit is that restricting access does not itself supply a usable alternative. If a useful operation cannot be approved, a practice can reasonably ask for the specific obstacle, the evidence needed to address it and an achievable review process. An indefinite answer leaves customers carrying duplicate work without a decision they can act on.
Heidi's strongest case
The practical need behind agents is credible. Finishing a note does not necessarily finish a consultation's administration. Clinicians still reconcile information, prepare correspondence and move material between systems. A tool that can assist across those boundaries, under an appropriate agreement, could address work that a narrow scribe connector leaves untouched.
A practice may also reasonably prefer one familiar assistant to a separate tool for each application. Reusing well-understood instructions could make repetitive preparation more consistent. Those are arguments for examining the capability carefully, rather than dismissing it because it uses a different technical route.
The limit is equally concrete. A clinician's ability to carry out a task personally does not settle a third party's permission to automate it. A useful draft is different from a correctly filed document; a visible approval is different from a confirmed result. Heidi's own current MSA assigns responsibilities for third-party permissions and consequential actions. The access question therefore persists even when the user actively wants the automation.
How other systems help clarify the trade-off
Lyrebird's Bp Premier instructions describe reviewed notes and observations returning to designated record locations. That offers a useful comparison when the main requirement is the final transfer of documentation. It does not demonstrate unrestricted agent access, and a deeper transfer route should not be treated as a measured accuracy advantage.
The decision is consequently about the missing task. A practice struggling with note transfer should compare the documented scribe workflows. A practice seeking multi-step administration needs answers about those particular operations. Changing the central record system is a much larger intervention and deserves a separate business case. Our Heidi-Lyrebird comparison follows the actual encounter workflow rather than ranking brands in the abstract.
What would make either argument more persuasive?
For the platform supplier, a published description of acceptable access would turn a general objection into a route forward. Useful detail includes the requested operation, the proportionate evidence required, the review owner and the conditions under which access could be reconsidered. The more clearly a restriction maps to a specific unresolved issue, the easier it is for customers to assess.
For the agent supplier, a bounded account of supported behaviour would be more helpful than a broad promise to work anywhere. Practices need to know what happens when the patient context is ambiguous, an operation partly completes or the host changes. Demonstrating a successful path is valuable; demonstrating an understandable exception and recovery process is also necessary for an operational decision.
There is verified commercial context. A joint announcement on 21 September 2026 says Best Practice led Medcast's A$5.4 million capital raise, supporting expansion of MedLuma and planned Best Practice integration. A further announcement on 2 November says MedLuma is now available inside Bp Premier through its latest release. These statements document a partnership and product strategy; they do not establish a motive for the Heidi decision. Customers can reasonably ask how comparable access criteria apply across partners.
Commercial interests deserve scrutiny, but they do not prove a motive for this decision. Similarly, a contractual dispute is not evidence of patient harm or a regulator's adverse finding. Strong criticism should remain attached to the particular evidence supporting it. The constructive test is whether both parties provide a practical, scoped route that customers can understand and compare.
Keep the knowledge and learning decision visible
Record access is only one part of a clinician's tool stack. iatroX provides a separate place for source inspection, structured reasoning and learning, including a source-linked Australian educational guidance library. Its value here is that a question arising during documentation can become an explicit learning task, with the source's jurisdiction and limitations visible.
That is a useful role alongside a chosen record system and scribe. It does not confer permission to operate Bp Premier, and no native Bp Premier-iatroX integration was verified for this article. Heidi also offers research functions, so the comparison should concern which reasoning and learning workflow a clinician finds useful. iatroX's Tutor gives that choice a concrete educational purpose: examining the reasoning behind an answered exam question and retaining the learning.
For a current practice, the next decision should be smaller than choosing a side. Confirm the working scribe route, identify any proposed agent expansion and obtain a written answer about that exact operation. That creates an actionable position while the broader argument develops.
FAQs
Has Best Practice banned all Heidi products?
The public evidence does not establish that. The reported disagreement concerns Heidi II access, while a Best Practice Scribe partner listing and Heidi's appointment-connector instructions remain public. Confirm the precise feature and agreement relevant to your practice.
Does owning patient data permit any AI access method?
Data ownership and permission to use another supplier's software are separate questions. Inspect the applicable agreement and obtain a written answer about the intended operation and access route.
Is Heidi II available in the UK or Europe?
Heidi's current Heidi II page excludes the new capabilities from the UK and Europe. That does not mean every existing Heidi service is unavailable there.
Use iatroX's methodology to examine how source-linked questions and structured learning can complement the documentation workflow you select.