skip to main content
iatroX JournalClinical AI

Can You Still Use Heidi With Bp Premier? Scribe Connectors, Agents and Permission

Featured image for Can You Still Use Heidi With Bp Premier? Scribe Connectors, Agents and Permission

Map the supported appointment connector, manual note transfer and disputed computer-agent route before changing a working clinical service.

A practice asking whether it can still use Heidi with Bp Premier needs an answer about a particular function. A consultation scribe, an appointment connection and an agent operating another application's screen are different services. A headline about one does not describe the others reliably. Best Practice here means the Australian software supplier, rather than BMJ Best Practice.

The practical answer, checked on 2 November 2026, is that public documentation still describes a Heidi Scribe connection for Bp Premier. That is a starting point for checking your installation, not blanket permission for every Heidi II action. Our dispute explainer covers the news. This article maps the routes a practice might actually use and the evidence needed before extending them.

Start with the documented Scribe route

Heidi's Best Practice setup guide describes practice approval for Heidi Scribe, a Site ID and pairing code, appointment import and selection of an appointment to link a session. Its documented return route is copy and paste into Bp Premier. The guide names a Practice tier; confirm current eligibility rather than assuming a subscription includes the connection. It specifically distinguishes Heidi Scribe from Heidi GP.

That workflow can remain valuable even though the final transfer is manual. A clinician can use familiar note-generation and review tools, then decide what belongs in the record. The receiving application remains a deliberate destination. For a practice whose main problem is preparing a readable consultation note, this may address most of the problem without requiring further automation.

The limitation is equally concrete. Someone must select the destination, transfer the accepted text and verify the result. A busy clinician can still paste an earlier draft, leave the entry unfinished or mistake a prepared note for a saved record. Those are reasons to define the completion step carefully. They do not demonstrate that the workflow has failed in a particular practice.

A partner listing has a scope

Best Practice's public Heidi Health partner page remains visible and identifies compatibility with Bp Premier in a scribe context. A practice should retain the current operational instructions alongside that listing. A logo can identify a relationship; it cannot enumerate the permissions for every later feature launched by either company.

Consider an ordinary analogy within a clinic. Permission for a service to receive appointments does not tell you whether it may alter an observation, send a referral or operate a billing screen. All may concern the same patient, yet involve different data and consequences. The useful procurement unit is the named operation, including its starting point and stopping point.

For an existing service, ask the practice administrator to identify the enabled integration entry and the actual user route. Observe whether clinicians begin from an imported appointment, start a separate session or use a desktop agent. Similar-looking outputs can hide different connections. Do not infer the installed route solely from the text ultimately appearing in the clinical record.

The agent route is a separate question

Heidi's connector guidance distinguishes direct connectors from desktop screen operation and acknowledges that some record suppliers do not permit the latter. Its Home connector list should not be substituted for the separate Bp Scribe instructions.

A computer-using agent could, in principle, remove repetitive navigation that an appointment connector leaves untouched. That is the strongest practical argument for investigating it: preparation, movement between screens and follow-up administration may consume time after the note itself is complete. A practice should be able to describe that missing task precisely rather than request automation simply because it is new.

The counterargument is that a successful demonstration answers only a capability question. It does not establish the permitted production route, the software versions covered, the recovery procedure after an interrupted action or who will investigate a disputed result. Screen navigation also makes the relationship between a requested task and its final effect important. A draft on screen and a completed action are different outcomes.

Heidi II's approval controls need the same specificity. Its approving-actions help describes different modes and saved Routines that generally follow Approve for me, with high-risk steps still pausing. Ask for the exact behaviour of the proposed deployment; the phrase human oversight does not identify every stopping point.

Permission is assembled from several answers

The public Bp Premier EULA recognises customer ownership of Customer Data while separately requiring written consent for third-party software or database access, expressly including bots, scraping tools and robotic process automation. Which agreement governs a particular practice still needs checking. Neither data ownership nor this public page alone resolves the present dispute.

For practical purposes, separate three decisions. The practice decides what it wants a service to do and who may instruct it. The record supplier identifies the access route and operations it permits and supports. The AI supplier explains what its service will actually do, what it needs and how it reports completion. One party's answer cannot silently stand in for the other two.

Clinical governance adds questions about the work itself: who reviews content, who handles an exception and where the authoritative entry is retained. Governance is necessary even when access is permitted. Equally, a well-designed review process does not grant access that a supplier has not authorised. Keeping the questions separate makes a support conversation shorter and the resulting decision more defensible.

Build a route record for the service you use

The following is an original proposed worksheet, not a report of product testing or a legal determination. Complete one record for each actual route. Use fictional material in an authorised test environment when demonstrating an uncertain step.

Route under reviewEvidence to attachDecision that still needs an owner
Appointment-linked Scribe sessionCurrent setup guide and the practice's enabled integration entryWho checks the selected appointment and handles an unlinked session?
Clinician transfers an accepted noteLocal destination and save procedureWho confirms the final text is in the intended record?
Additional chart retrievalWritten description of fields, route and permissionWho confirms the requested scope is supported?
Desktop agent performs a named taskSupplier scope confirmation and task descriptionWho can authorise the deployment and stop uncertain work?
Scheduled or repeated actionRun conditions, approval points and exception routeWho monitors work when the original requester is absent?

For each row, add three dated statements: the practice's requested operation, the record supplier's supported route and the AI supplier's stated behaviour. Mark an unanswered question as unanswered. Avoid filling a gap with a sales demonstration, a colleague's experience elsewhere or the fact that an account can technically connect.

A useful request might be: prepare a draft follow-up document from explicitly supplied fictional material, leave it unsent, and show the review location. A substantially different request would add retrieval from a patient chart or filing into a record. Keep those additions visible. Splitting the request allows a supplier to approve a bounded useful activity without being asked to endorse an undefined collection of actions.

Choose the smallest change that solves the problem

Continuing an already confirmed Scribe workflow can be sensible when clinicians value the notes and the manual transfer is manageable. It preserves a familiar process while the scope of an optional extension is clarified. The case against continuing unchanged is stronger if the remaining manual step is causing a demonstrable local problem that the practice cannot reliably correct.

A deeper supported integration deserves consideration when the actual bottleneck is filing reviewed notes or observations. Our Heidi-Lyrebird Bp workflow comparison examines that narrower choice. A different scribe is not automatically a substitute for an agent's proposed task; equally, an agent may be unnecessary when an established integration already addresses the required destination.

Deferring an uncertain agent extension is reasonable when neither supplier can identify its authorised scope. That decision need not become an opinion about all clinical AI or require changing the central record system. Record the task still performed manually and a reassessment trigger, such as a written scope agreement or a supported connector release.

The weakest reason to expand is that a feature is available in an account. The strongest reason is a named local problem, a supported route, a clear endpoint and an accountable person who can assess whether the change helped after corrections and exception handling are counted.

Keep learning useful while access is resolved

A documentation dispute need not suspend the clinician's separate learning workflow. A question exposed while reviewing a note can be reformulated without patient identifiers, checked against an appropriate source and revisited after the session. Heidi has its own Evidence and Journal Search capabilities; reference and learning tools should be evaluated on their actual merits.

iatroX's Australian educational guidance library offers source-linked summaries with stated boundaries, while Tutor supports reasoning from an answered exam question. This is a useful complementary role: examine the uncertainty, inspect the source's jurisdiction and practise the underlying reasoning. It does not require claiming a Bp Premier integration or asking iatroX to operate the chart. For a practice managing a disputed optional connection, that separation can help keep education productive while access questions receive their own answers.

FAQs

Does the Best Practice dispute mean every Heidi service must stop?

The public sources do not support that blanket conclusion. They distinguish a documented Scribe connector from disputed computer-agent access. Confirm your precise configuration and governing agreements with the relevant suppliers.

Can a clinician's approval settle whether Heidi II may operate Bp Premier?

It establishes the clinician's instruction, but does not by itself settle supplier permission or supported access. Obtain scope-specific answers from the practice, Best Practice and Heidi for the proposed operation.

Does copying a reviewed note mean Heidi has automatic write-back?

No. Manual copy and paste is a distinct return route. Verify the destination and saved record rather than treating a generated draft as a completed chart entry.

For a clinical question raised during note review, explore Ask iatroX and inspect the linked sources and their jurisdiction before applying the answer.

More from the Journal