That remains unconfirmed. The useful launch question is which operations Heidi Work can perform in a particular clinical system: reading context, preparing content, submitting an authorised action or checking the result. A broad integration claim cannot establish where the clinician's final manual step will sit.
This is pre-launch analysis dated 27 September 2026. Work is the anticipated name, and its operation-level integration specification has not been established in the reviewed public material. Heidi's September announcement describes deeper EHR connections and supervised work, but those statements should not be expanded into an invented list of supported Work integrations.
Integration is a sequence of operations, not a single feature
An electronic health record connection can support one useful operation without supporting the next. Reading a patient identifier does not establish access to the full record. Writing a note does not establish the ability to prepare an order. Preparing an order does not establish permission to submit it.
The organisation should therefore start with an operation-specific specification. What information must be read? What output is written? Which action changes something outside the drafting interface? What information comes back to confirm that change?
The answer should also identify the user and deployment. An operation available to one authorised role may be unavailable to another. A connection implemented in one organisation may not describe the configuration purchased by a different practice.
Heidi's pricing page, checked on 27 September 2026, separately lists an EHR integration add-on within its existing platform information. That is a reason to clarify implementation and entitlement, not evidence that Work includes every connection or operation automatically.
Three possible approaches to execution
A vendor-supported interface could allow software to exchange defined information or request an operation through a structured connection. The relevant questions would concern the supported operations, permissions, response information and behaviour when the request fails.
A browser-based approach could interact with a clinical system through its web interface. Here, a buyer would need to understand how the product identifies the correct page, detects interface changes and confirms that the intended action occurred. A browser extension alone does not establish that those functions exist.
A supervised desktop approach could operate through software visible on the clinician's computer. That raises practical questions about which application is active, whether the user can interrupt the operation and what happens when a dialogue or unexpected window appears.
These are alternative architectural possibilities, not identified components of Heidi Work. A product could combine approaches or use a different design. The launch should make the user-facing operation clear even where the underlying implementation remains proprietary.
Follow the final-click problem through a fictional workflow
Imagine a clinician has approved an administrative letter. In the existing process, the document is generated in one application, copied into another, checked for formatting, attached to the appropriate record and transmitted through a separate route.
A preparation-focused assistant might save drafting time but leave every transfer step intact. That can still be worthwhile. The correct description would be assisted preparation, not completed communication.
A more connected system might place the approved document in the correct record but still leave transmission to the clinician. Another might perform the authorised send operation and return a receipt. Those are different integration depths, and each should be assessed against the task the practice wants to simplify.
The number of remaining clicks is not the whole story. One final click may be a deliberate and useful approval boundary. The problem is an unclear handover that forces the user to reconstruct context, repeat data entry or guess whether anything happened.
Ask for an operation-level demonstration
A meaningful demonstration should begin with a synthetic task in the intended test environment. The supplier should show the starting record, proposed action, required permission, external operation and resulting status.
| Operation | Question to resolve | Evidence to request |
|---|---|---|
| Read context | Which records and data types are accessible? | A demonstration of the actual retrieved information and its source |
| Prepare content | Where does the draft exist before approval? | The draft and the information used to create it |
| Write into the record | What is saved, under whose identity and in which location? | The resulting record entry and approval history |
| Submit an action | Which operation is authorised and which remains manual? | The receiving workflow, not only a generated confirmation sentence |
| Receive status | What proves the operation succeeded? | The relevant system response, receipt or explicitly unresolved state |
This is a proposed buyer checklist. It is not a Work feature matrix, and no operation in it should be treated as confirmed for the anticipated product.
Correct information still needs the correct destination
A document can be accurate yet attached to the wrong encounter. A recipient can be valid yet inappropriate for the current instruction. The integration assessment therefore needs to examine identity and destination, not only content quality.
A proposed synthetic test could include similarly named records, a changed destination and an attachment selected from an earlier encounter. The aim would be to assess whether the interface makes the relevant identity checks clear before an operation proceeds.
The system should also distinguish information in a source document from instructions it is authorised to execute. For example, an imported letter may describe a previous plan or contain administrative directions intended for a different organisation. A sensible test would ask whether those statements are treated as context requiring review rather than automatically becoming permission for a new action.
These are design and evaluation questions. They are not allegations that Heidi has encountered or failed those tests.
What happens when the connection becomes uncertain?
An external operation may be interrupted at an awkward moment. A clinician needs to know whether it definitely failed, definitely succeeded or has an unresolved outcome. Those states imply different next steps.
A useful recovery process would retain enough information to check what occurred without repeating the action blindly. The organisation should ask how duplicates are prevented, which identifiers or receipts are retained and when the issue returns to a human operator.
The same applies to changed content. If a clinician revises an approved document before transmission, the system should be clear about which version the approval covers. If the earlier version has already been transmitted, the response is a correction workflow, not an imaginary reversal of an external event.
A demonstration that includes these cases would provide more useful implementation evidence than a long list of EHR names. It would show how the system handles the boundary between its own state and the receiving system's state.
The supported system is only the beginning of procurement
Ask for the exact product version, operation scope, required configuration and support responsibilities in the intended organisation. Clarify what changes when permissions, templates or the clinical system itself change. Identify who monitors an integration that stops working and how staff revert to a manual process.
A practice should also know whether information must be re-entered during recovery. Saving a few steps in the routine case may still be useful, but frequent manual reconstruction changes the total operating burden.
No Work integration test was performed for this article. Any later claims of reliability should identify the workflow, environment and product version tested. Support for one operation in one deployment cannot be generalised automatically to every clinical system.
What the regional restriction means for this question
As checked on 27 September 2026, Heidi's waitlist excludes the UK and Europe. A demonstration inside an EHR elsewhere would not establish UK availability, and existing Heidi integrations should not be confused with Work access.
For an eligible prospective buyer, the final-click question should remain pragmatic. Leaving approval with the clinician may be appropriate. Leaving repetitive transfer and uncertain status with the clinician may indicate that the product solves only part of the intended problem.
Per iatroX product information, September 2026, Ask-iatroX offers clinical reference with linked sources. It is not claimed to perform the EHR operations discussed here or to inspect Heidi Work automatically. Evidence retrieval and operational integration should be purchased and evaluated for their distinct purposes.
Frequently asked questions
Will Heidi Work integrate with my EHR?
The public material reviewed on 27 September 2026 did not establish a Work-specific operation and integration catalogue. Confirmation should cover the exact clinical system, deployment, permissions and action required.
Is writing a note into the record the same as workflow automation?
It automates or assists a particular documentation step, but it does not establish that other operations are supported. Submitting an action and receiving its outcome require separate verification.
Could it work without a direct integration?
In principle, software can support preparation or supervised interaction through other interfaces. Whether Work uses such an approach, and what it can reliably complete, remains unconfirmed.
Explore clinical evidence separately from record automation →