Two clinical AI products can both describe themselves as integrated while doing very different things. One may open from an electronic record. Another may receive selected patient information. A third may generate a proposed order or document for review. Treating these as equivalent obscures the work required to evaluate them.
The Doximity-UpToDate partnership is a useful prompt to make those distinctions explicit. The announcement explainer concerns access to another clinical knowledge source within Ask. The broader market includes products that combine evidence with information from the encounter itself.
Five levels that should not be collapsed
The simplest level is navigation: a user can launch one service from another. The next is authentication: the user arrives signed in through an approved account relationship. These changes can remove friction without transferring clinical information.
A third level is reference integration, in which a source or answer becomes available within the existing interface. A fourth is contextual integration, in which patient information affects the question or response. A fifth is action integration, in which the system can prepare or initiate a change in another clinical system.
This is an analytical framework, not an official classification or a ladder where higher always means better. A reference task may require no patient data. Adding context or action can increase capability while introducing additional failure modes and governance work.
Suki illustrates the patient-context distinction
Suki's October announcement describes a conversational interface combining patient information with UpToDate Expert AI. It reports that clinician evaluators preferred context-aware responses 83% of the time in its early evaluation. That is a reported preference result, not proof of improved patient outcomes.
The distinction is important. Context may make an answer more relevant and convincing. It can also make an incorrect answer more persuasive if the context is stale, incomplete or misinterpreted. Preference and correctness need separate assessment.
A meaningful evaluation would show which patient information was used, whether it was current and how the response changed when a relevant item was absent. It would also examine whether clinicians noticed incorrect context rather than simply appreciating the apparent personalisation.
Abridge describes a broader encounter-based approach
Abridge's platform announcement describes clinical decision support shaped by the patient record and ongoing clinical conversation. This is a different proposition from opening a reference alongside the encounter.
The potential benefit is that important context need not be re-entered manually. The challenge is determining which parts of the conversation are reliable, clinically relevant and correctly associated with the current decision. A tentative statement, historical fact and confirmed finding should not become interchangeable inputs.
The evaluation burden grows with the number of transitions. Information must be captured, interpreted, linked to evidence and presented in a form the clinician can review. An error at an early stage can influence an otherwise well-supported recommendation later in the process.
EHR access is not proof of record understanding
OpenEvidence's Northwestern deployment describes launch from Epic with existing credentials. That is a useful access improvement. It should not be expanded into a claim of complete chart interpretation unless the documentation establishes that capability.
This illustrates a wider reporting problem. The phrase "inside the EHR" can refer to location, authentication, data access or execution. A comparison should identify which meaning is intended each time it uses the phrase.
For clinicians, the practical question is simple: what does the system actually know without being told? The answer should be visible and bounded. Assuming that an integrated tool has seen the entire record can be as problematic as assuming it has seen none of it.
More context creates a freshness problem
Clinical knowledge has an update cycle. Patient information has another. A system can retrieve a current recommendation while relying on an outdated medication list or an earlier clinical status. The two forms of freshness must be considered separately.
A useful interface would identify the provenance and timing of important contextual facts. It would make missing or contradictory information visible. It would avoid presenting an inference from a conversation as though it were a verified structured record entry.
These are design requirements to assess, not claims that a named product currently fails them. They explain why patient-context integration should be evaluated as a distinct capability rather than treated as a free enhancement to reference search.
Action changes the consequences of an error
A proposed paragraph and an initiated clinical action have different consequences. The ability to prepare an order, update a record or transmit information requires clear review boundaries, permissions and recovery procedures.
The relevant question is not whether automation is intrinsically good or bad. It is whether the particular action is appropriate to automate, what the clinician sees before authorisation and how mistakes can be detected and corrected.
An institution should therefore map the complete pathway, including failure. A product demonstration that ends with a successful action does not show what happens when the source system is unavailable, the patient context conflicts or the user rejects the proposal.
Why standalone reference remains useful
Not every valuable clinical question requires patient-level integration. A clinician may be reviewing a concept, preparing teaching or examining a fictional case. In those settings, a focused reference or learning tool can be appropriate precisely because the task is bounded.
iatroX's reference and learning design fits that category of work. It should not be presented as an ambient scribe or a substitute for an enterprise record integration. Its positive role is to help with the clinical question and the understanding that follows.
The market is therefore not a race in which every product must absorb the complete record and every possible action. The better question is which degree of integration serves the task with a proportionate level of complexity. Clear boundaries can be a product strength.
Frequently asked questions
Does launching a tool from an EHR mean it can read the chart?
No. Launch access and authentication do not establish the scope of clinical data access. The enabled configuration should specify which information, if any, is transferred.
Is a preferred context-aware answer necessarily more accurate?
No. Preference can reflect relevance, fluency or convenience. Accuracy, omissions and the correctness of the supplied context require separate evaluation.
When is a standalone tool the better fit?
For a bounded reference, teaching or learning task that does not require patient-record integration. The appropriate choice depends on the work, not on maximising the number of connected systems.
Explore iatroX Brainstorm for structured educational reasoning around a clinical question.