A fair assessment of platform governance, clinician choice and the evidence both sides should provide.
The Best Practice-Heidi II disagreement raises a useful question beyond the immediate headlines: who should decide how a new clinical tool interacts with a practice's record system? Best Practice Software supplies Bp Premier, an Australian clinical and practice-management platform. Heidi supplies a scribe, evidence tools and newer computer agents. This article concerns that software relationship, rather than the similarly named BMJ reference service.
There is a persuasive case for a record-system supplier controlling supported access. There is also a persuasive case for clinicians choosing tools that improve work across systems. Neither principle settles the terms of a particular connection. The practical issue is whether the requested operation can be defined, assessed and supported on proportionate terms.
Our dated dispute explainer covers the reported disagreement. Here, we examine the arguments and propose a shared conformance request. The proposal below is original analysis, not an industry standard, a conducted product test or an agreement accepted by either company.
Start with the access route, rather than the brand
Heidi's Australian Bp Premier integration overview describes schedule linkage and copying the completed note to the record. That is a different proposition from a computer agent operating another application's interface. Treating them as one undifferentiated integration obscures what needs permission and what needs evidence.
The public Bp Premier EULA sets a written-consent boundary for third-party access. The constructive discussion concerns the actual requested operation: what data moves, what software action occurs and which permission covers it. Data portability and software access deserve explicit scopes in that discussion. An access restriction does not itself establish clinical harm or justify every possible limit. The agreement governing an individual practice still needs checking.
The strongest case for controlled integration
A clinical platform has to keep working across upgrades, different installations and competing third-party products. A supported interface can make the boundary explicit: which information may be retrieved, which fields may change, which identity is recorded and which errors return to the caller. That gives a practice something more specific than a demonstration in which a tool successfully completes one task.
The value is particularly clear when software changes. If a record platform alters a field, an approved interface can expose a version or a defined failure response. With a screen-based route, a visual change may require a different compatibility process. That is an architectural argument, not evidence that Heidi has made a particular error. Both routes need maintenance; they distribute the maintenance burden differently.
Support is another legitimate concern. When a note appears twice or in the wrong destination, the practice needs a way to determine whether the problem arose in capture, mapping, transmission or filing. A controlled connection can specify which supplier investigates each boundary. Approval alone does not guarantee this clarity, but a documented support arrangement can require it.
Best Practice's Halo Connect FAQ describes an integration layer for approved partners, with practice-level enablement. That establishes a supported route; it does not prove every partner has the same permissions or that every useful operation is available through it. The strongest defence of control therefore includes explaining the actual scope offered, not simply pointing to the existence of a partner programme.
The strongest case for broader access
Clinicians rarely work inside a single application all day. A useful task may involve the patient record, a referral form, a document and a separate service. Waiting for each pair of suppliers to build a dedicated connection can leave repetitive work with the practice indefinitely. Where authorised, computer interaction may offer a way to address a gap without replacing the record system.
The attraction of a broader route is understandable: the clinician can describe the work they need done rather than wait for a platform's product roadmap. That is a case for considering a proposal, not proof that any requested access should be granted. A useful proposal should make the task concrete enough for the platform supplier to assess it.
There is also an accountability question for the platform. If permission is required, the application process should ideally explain the permitted operations, necessary evidence, likely timetable and reasons for refusal. Otherwise, the practice cannot distinguish a remediable technical gap from a permanent policy boundary. Uncertainty itself has a cost when a team must plan staffing or decide whether to buy a tool.
Broader access has limits too. The fact that a doctor can perform a task personally does not make every delegated implementation equivalent. The doctor may notice ambiguity that a workflow specification omits. Conversely, an implementation with narrow, inspectable operations may be easier to assess than a broad request to access everything. The useful unit of negotiation is the defined task, not an unrestricted promise of automation.
Compare supported ecosystems without pretending they are interchangeable
Different products show that integration can be organised in more than one way. They do not establish that the same commercial or technical terms should apply everywhere.
| Documented example | What it helps a buyer assess | What it does not establish |
|---|---|---|
| Lyrebird's Bp Premier setup describes reviewed notes and observations returning to named record areas. | Whether the supported route removes a specific transfer step in the installed configuration. | That any other product may use the same route, or that all agent actions are included. |
| MedicalDirector Smart Scribe offers an embedded scribe model with named providers. | Whether a host can offer supplier choice inside a defined documentation workflow. | That changing the practice's core system would be worthwhile, or that arbitrary computer agents are permitted. |
| Accurx Scribe's overview describes reviewed documentation and record saving through Accurx Desktop for EMIS or SystmOne. | A UK example of product-specific transfer requirements. | Availability in Bp Premier or equivalence to Australian general practice. |
A useful comparison asks which required operation each route completes. A long integration list is less informative if the practice still has to perform the missing step manually. A deeply embedded workflow can also be unsuitable when the required operation lies outside its documented scope.
A shared conformance request both sides could answer
Instead of asking who is more open, a practice or professional group could request the same evidence from both parties. The following template makes room for legitimate restrictions while requiring a clear path for a useful proposal.
| Requested item | Evidence proportionate to the request | Acceptance and change responsibility |
|---|---|---|
| One named operation, such as placing a reviewed draft in a specified notes field. | Exact source, destination, permitted account and excluded operations. | Both suppliers identify the supported route or explain the unresolved obstacle. Broad future capabilities do not count as completion. |
| Correct destination and bounded access. | A demonstration using authorised fictional records, including similar patient names and an unavailable destination. | The task reaches the specified location or reports an explicit non-completion. The parties agree who handles mapping changes. |
| Traceable completion. | A description of the evidence available to the practice: request, intended output, final status and receiving record reference where supported. | The practice can distinguish a prepared draft from a filed item. Suppliers identify missing visibility before deployment. |
| Compatibility after an update. | Supported versions, notice arrangements and a method for checking a changed interface or connector. | Each supplier names its maintenance responsibility and when the practice will be told that support has changed. |
| Proportionate commercial access. | An actual quotation covering setup, recurring charges, included operations and support. | The practice can compare total cost for its task. No assumption about a supplier's motive substitutes for the quotation. |
| A reviewable refusal or limitation. | The unmet requirement, evidence that could resolve it and the person or process receiving a revised proposal. | A dated decision separates a permanent policy boundary from a temporary evidence gap. The practice retains an intelligible explanation. |
The burden should scale with the operation. A narrow appointment read and a change to an existing clinical record raise different questions. Demanding every conceivable control for a limited request can obstruct useful work. Accepting a broad capability statement for a consequential action can leave the actual implementation unexamined.
What would change the balance of the argument?
The case for control strengthens when the platform offers a usable route, explains limitations and applies stated requirements consistently. It weakens when a practice cannot obtain a clear scope or a practical path to assess a bounded proposal. That is a standard for judging the response, not an allegation about what has happened privately between these companies.
The case for broader access strengthens when the AI supplier can define its actions, demonstrate boundaries and accept maintenance and support responsibilities. It weakens when the proposal relies on a clinician's enthusiasm or one successful demonstration while leaving third-party permission unresolved. Patient consent, practice approval and supplier access permission each answer different questions; none should silently stand in for the others.
For a practice, the conditional choice is straightforward. Prefer a supported route when it completes the required work on acceptable terms. Seek a bounded, written proposal when an important gap remains. Defer that additional operation when its scope or permission is still unresolved, while assessing existing services on their own documented basis.
Keep the clinical question visible
An integration dispute should not turn into a contest over every part of clinical work. Heidi already offers Evidence and Journal Search. A practice can nevertheless choose a separate tool for deliberate source inspection, structured reasoning and education. iatroX's Australian guidance library provides clinician-facing educational summaries with stated source boundaries; its AMC, RACGP and Tutor pathways support learning.
That is a useful, modest role in the stack: take a specific uncertainty, inspect the relevant source and jurisdiction, then practise the reasoning. It does not require an asserted Bp Premier connection. The advantage is being clear about the job each tool is being asked to do.
FAQs
Does customer ownership of data mean any AI tool can access Bp Premier?
Data rights and software-access permission are separate questions. Check the agreement, proposed operation and written permissions for the practice rather than treating either ownership or technical capability as a complete answer.
Does a partner listing settle the Heidi II dispute?
A listing can establish a documented relationship for a named product or connection. It does not automatically establish permission for every newer feature, particularly a different computer-agent access route.
Which approach should a practice prefer?
Prefer the supported route that demonstrably completes the required task with clear scope and support. If an important gap remains, request a proportionate written proposal rather than deciding from openness claims or brand preference alone.
Use iatroX's methodology to explore how source-linked answers and structured learning can complement the documentation workflow you choose.