A practical response built around the features you use, the records you must preserve and the written answers each supplier can provide.
If a practice already uses Heidi alongside Bp Premier, a dispute about Heidi II should prompt a precise service check. Start with the functions staff actually use. A scribe session, appointment import, copied note and computer-agent action may involve the same brand while depending on different permissions and technical routes.
Best Practice Software is the Australian supplier of Bp Premier, rather than BMJ Best Practice. Our dispute explainer separates the reported positions. This article turns that background into an operational response for the practice manager, clinical lead and IT contact. It does not assume the status of an unseen installation or tell every Heidi user to abandon a working documentation service.
The immediate aim is a short, defensible record of what remains supported, what is uncertain and what work staff must complete themselves. A dependency register and two focused supplier enquiries are more useful than a general discussion about whether AI is good for general practice.
Establish what is in use, not merely what has been purchased
Ask one clinician and one staff member to describe an ordinary encounter from appointment selection to the finished patient record. Record the actual application, button or transfer step used at each boundary. A subscription name is insufficient: unused features can appear in an account, and the presence of an integration logo does not show how yesterday's note reached the chart.
Use the current Australian Heidi Best Practice overview as one reference point. It describes schedule sync and copying the completed note to the record. Record whether that matches the practice's workflow. Do not infer that a different on-screen automation route is included because appointment linkage is working.
Be equally specific about clinical knowledge features. An Evidence question is not the same operation as an agent accessing a record. If the practice uses Heidi II, identify the named task, the relevant account and region, and whether it uses a direct connector or computer interaction. The Heidi connector guide is a starting point for that distinction, not permission for a particular Bp deployment.
Check whether staff descriptions agree. A manager may believe every reviewed note is automatically filed while a clinician routinely copies it. Resolving that misunderstanding has immediate value regardless of the dispute: it identifies the human work that currently completes the service.
Build a dependency register for this week's service
The following is an original practice worksheet, not a report of tested vendor behaviour. Populate it from the installed configuration, current instructions and written answers. Keep patient information out of supplier enquiries unless a separately agreed support process requires it.
| Function in actual use | Dependency and supporting evidence to record | Owner and ordinary fallback | Next decision |
|---|---|---|---|
| Appointment selection in Heidi Scribe | Named Bp third-party entry, practice identifier, connection method and dated setup reference. | Practice IT contact owns connection questions; staff can select the appointment in the normal record workflow. | Confirm the existing scope, rather than extending it by assumption. |
| Consultation capture and draft generation | Exact scribe product, account, capture setting and local documentation procedure. | Clinician owns the encounter note; use the practice's ordinary documentation method if capture is unavailable. | Assess this service separately from any agent proposal. |
| Reviewed note reaching Bp Premier | Whether staff copy text or use a documented transfer command; receiving location and who checks completion. | The treating clinician confirms that the finished record is present. | Resolve any mistaken assumption that a draft is already filed. |
| A proposed Heidi II computer task | Named operation, access route, current supplier statements and written permission status. | Named proposer retains the task until a supported route is agreed. | Defer this additional operation if permission or scope remains unresolved. |
| Evidence lookup or educational work | Tool used, source jurisdiction and whether the question includes identifiable information. | Clinical lead defines the appropriate reference process; staff can consult the relevant original source. | Keep the useful knowledge function distinct from record access. |
| Support and configuration changes | Current Bp version, relevant application version, practice contact and supplier case references. | One coordinator links the supplier responses and keeps staff informed. | Recheck affected functions when a supplier's written scope or installed configuration changes. |
This is a status record, not a wholesale software migration plan. Give each uncertain row one person and a date for the next answer. Avoid assigning ownership to an unnamed group such as IT or the doctors. A short unresolved entry is more honest than marking a whole product approved because one connection works.
Keep documentation completion observable
For the next ordinary service review, inspect the practice's normal evidence of completed documentation. Ask whether a finished note is in the intended patient record, whether any additional observations belong in separate fields, and whether an amendment is visible to the next clinician. This is a check on the workflow the practice already relies on, not a request to try an uncertain agent on live charts.
Likewise, preserve the distinction between a service interruption and a feature proposal that has never been authorised. The latter may require deferring expansion rather than changing today's clinic. A team can avoid unnecessary disruption by naming the exact affected step in its internal message.
Draft enquiry one: ask Best Practice about the proposed boundary
The following is a draft to adapt through the practice's usual support channel. It has not been sent. Replace brackets with configuration details and omit patient information.
We use Bp Premier [version] at [practice identifier]. Our present Heidi workflow is [appointment connection, scribe and actual note-transfer method]. We are separately considering [one named Heidi II operation] through [proposed route].
Please identify which of these specific functions your current support and access arrangements cover. If the proposed operation needs additional written consent, please explain the applicable process, evidence required and whether a supported alternative route exists. Please identify the agreement or policy version relevant to your answer, any configuration limits and who would investigate a failure at the Bp boundary.
We are seeking a feature-specific answer so we can preserve confirmed services and defer uncertain expansion appropriately. Please distinguish the existing Scribe connection from the proposed computer-agent activity.
This asks the platform supplier to define its boundary rather than to endorse an entire AI brand. The Best Practice partner network provides context, but the answer needs to address the practice's actual arrangement. Do not treat a patient consent form or a successful technical demonstration as the missing supplier permission.
Draft enquiry two: ask Heidi what the feature actually does
Send a separate, equally specific request to the AI supplier through the established support channel. This draft has not been sent either.
Our installed workflow is [product, account, application version and Bp Premier version]. Please confirm the exact operations supported by the appointment connector and how reviewed content reaches the record in this configuration.
For the separate proposed task [one named operation], please identify whether the route is a direct connector, supplied-document preparation or computer interaction. What third-party permissions must our practice obtain, and what written support can you provide for that requirement? Please identify the final output and the normal evidence that the task has completed.
Please also identify account or regional limits, the relevant usage terms and the support owner if the operation cannot complete. If your public pages describe different action boundaries, please provide the current deployment-specific scope rather than a general product statement.
The Australian Heidi terms place responsibility for third-party connection rights on the customer. That makes the permission question practical, rather than a task to infer from a product demonstration. For this enquiry, the practice needs a concrete scope answer, rather than another broad review of agent controls.
Make the smallest decision that resolves the actual problem
Once the replies arrive, classify the affected function. Continue a confirmed, supported service according to its documented procedure. Defer an uncertain new operation while seeking the missing answer. Consider a bounded evaluation only where the relevant suppliers and practice have agreed the route and scope. An ambiguous reply should remain an open entry; elapsed time does not convert it into permission.
If the unmet need is the final transfer of a note, compare that task directly. Lyrebird's current Bp setup guide documents return to named note and observation areas, with deployment prerequisites. That makes it a relevant supported option to investigate, not proof that switching scribes will improve every encounter. Our Heidi-Lyrebird workflow comparison examines the difference in more detail.
MedicalDirector Smart Scribe illustrates another host's embedded model, but moving the central patient-record system is a much larger decision than resolving one optional capability. Do not turn a supplier disagreement into an assumed business case for migration. Identify the service gap first and compare the least disruptive supported ways to address it.
Measure the work the team actually retains
A proposed improvement should be judged across the practice, rather than from the person who starts it. Count preparation, checking, correction and support time alongside the apparent time saved in generating text. A faster first draft may still be useful, but it should not be reported internally as a completed record if someone else performs the final transfer and reconciliation.
Keep the measurement simple: one defined task, the staff roles involved, the completion evidence and the period observed. Separate everyday workload from one-off setup. Do not invent a saving for a feature the practice has not used. This gives the next purchasing decision a practical basis without pretending it is a controlled comparison between suppliers.
Preserve a useful place for reference and learning
The knowledge task can remain explicit even while the access question is unresolved. Heidi has Evidence and Journal Search; iatroX offers another deliberate route for source inspection, reasoning and education. Its Australian educational guidance library states source and jurisdiction boundaries, while AMC, RACGP and Tutor pathways can turn a recurring uncertainty into structured revision.
For example, a clinician can frame a general question from a documentation problem, inspect the relevant original guidance and revisit the reasoning afterwards. Check the source's applicability rather than transferring a recommendation across jurisdictions automatically. iatroX does not need an asserted Bp connection to serve that educational role, and this article does not claim one.
FAQs
Should every practice stop using Heidi because of this dispute?
A broad brand-level instruction would ignore different products and access routes. Identify the actual function, confirm its current support and permissions, and address uncertain activity separately from the documented Scribe workflow.
What if the two suppliers give different answers?
Record the precise disagreement against the named operation and ask each to respond to the same configuration and task. Keep that operation unresolved until the relevant boundary is clear; do not infer permission from silence or technical success.
Should we switch the scribe or the whole record system?
Start with the unmet task. A supported connector, documented manual step or different scribe may address it. Changing the central record system requires a broader case than dissatisfaction with one proposed AI feature.
Explore iatroX's Australian educational guidance and Tutor when the next useful step is checking a source or strengthening the clinical reasoning behind a recurring question.