Clinical AI users should not have to infer the permitted purpose of a product from a collection of promotional phrases. The intended use should be understandable from the product, the applicable agreement and the institution's deployment instructions.
Doximity offers a concrete document-reading exercise. Its partnership announcement describes Ask using clinical decision-support language. Section 2C of its public terms, effective 20 July 2026, includes a restriction on using its AI tools as clinical decision support. That textual tension deserves clarification.
It does not, by itself, establish illegality, determine liability or disclose the contents of an enterprise contract. The useful task is to identify exactly which agreement governs which use.
Describe the discrepancy before interpreting it
There is a difference between saying that two public descriptions are difficult to reconcile and saying that a company has acted unlawfully. The first can be established by reading the documents. The second would require facts and legal analysis that a marketing comparison does not supply.
The discrepancy matters because users form expectations from product positioning. A clinician may reasonably understand a service advertised for clinical questions differently from a general writing assistant. Clear documentation should explain what the user may do with the output and what the service is designed to support.
A vague instruction to exercise judgement does not fully answer that question. Almost every clinical reference requires professional interpretation. The more specific issue is whether the proposed task falls within the service's stated purpose and the applicable agreement.
Several documents may govern one experience
A consumer-style account agreement, an enterprise contract, a partner's terms and a local organisational policy can each address different parts of the workflow. They should not be assumed to be identical.
For an institution, the practical exercise is to build a document map. Identify the supplier, the contracted product, the enabled features and the terms governing each relevant data flow. Then compare that map with the training given to users.
This is not a request for every clinician to become a procurement lawyer. It is an argument for the organisation deploying the tool to provide a clear, operational explanation: what the approved use is, what information may be entered, what must be checked and how concerns are reported.
Human review needs equally clear scope
Another public distinction concerns review. Doximity's terms state that not every generated output is individually human-reviewed and refer to specific designations where review applies. That is more precise than assuming that a clinician-review programme certifies every response.
Users should be able to tell whether a label refers to source authorship, a previously reviewed answer, a current output or feedback used to improve future generations. These activities can all be valuable, but they provide different kinds of assurance.
A reviewed source can still be summarised inaccurately. A reviewed answer can become unsuitable when the user's context changes. A platform-wide improvement programme can reduce errors without guaranteeing the particular response on the screen. Documentation should help users recognise these boundaries.
The interface should reinforce the intended use
A product's design can either clarify or undermine its written explanation. An answer framed as a suggestion for reference review creates a different expectation from an instruction presented as ready for execution.
Source visibility, uncertainty labels, missing-information prompts and explicit review steps can make the intended workflow clearer. A long legal document hidden behind a small link cannot carry the entire burden of explaining how a clinician should use the service.
This is a product-design observation, not a claim about the regulatory status of any platform. The practical question is whether ordinary users receive a consistent message from the agreement, interface and training.
What an institutional clarification should cover
An organisation considering the integration should seek a concise account of the permitted clinical-reference tasks, any excluded uses and the relationship between the general terms and its negotiated agreement. It should identify the responsible contact for content concerns and technical incidents.
It should also establish how partner-generated material is labelled. When several services contribute to one answer experience, the clinician needs to know which part came from which source and where to report an apparent error.
Finally, the organisation should consider continuity. If a partner feature becomes unavailable, users should know the approved fallback. A reliable clinical workflow includes what happens when the preferred interface does not work.
What an individual clinician can do
The individual user's most useful question is specific: "Is this task covered by the version and agreement my organisation has approved?" That is easier to answer than a general debate about whether all AI constitutes clinical decision support.
Where the answer is unclear, the appropriate next step is clarification through the institution or supplier. Quietly treating promotional language as permission, or assuming that a general disclaimer settles every practical issue, would both be weak approaches.
The clinician can also distinguish reference use from delegation. Looking up an explanation, drafting educational material and allowing a system to initiate an action are different activities. A tool approved for one should not automatically be treated as approved for all.
The same expectation applies to iatroX
A focused platform benefits from a clear purpose. iatroX's account of how it works is relevant because users should be able to understand the relationship between clinical reference, learning and their own judgement.
The positive principle is transparency. A product that clearly explains what it supports and makes evidence inspectable gives clinicians a more usable basis for deciding how to incorporate it. That is stronger than using uncertainty in a competitor's documentation as a shortcut to claiming one's own superiority.
The Doximity wording deserves a precise question and a precise answer. Clear intended use is part of a good clinical product, not an administrative detail to be left until something goes wrong.
Frequently asked questions
Does the wording prove Doximity Ask is unlawful to use clinically?
No. The public documents identify a question about scope, not a complete legal conclusion. The relevant contract, deployment and jurisdiction would need to be considered before making that kind of claim.
Does physician involvement mean every output has been reviewed?
No. Source authorship, selected-output review and system-improvement feedback are different activities. A particular output should only be described as individually reviewed when the product identifies it that way.
What should a hospital ask before deployment?
It should clarify permitted tasks, applicable agreements, data handling, user training, partner attribution and incident reporting. The result should be understandable to the clinicians expected to use the service.
Read iatroX's methodology to examine its stated approach to reference and education.