Anthropic and OpenEvidence are collaborating on a free, regionally adapted medical AI service, with a rollout covering approximately 100 countries, according to Reuters on 22 September 2026. The reported division of work gives Anthropic responsibility for back-end technology and OpenEvidence responsibility for adaptation to regional healthcare infrastructure. Financial terms were not disclosed. Reuters' reporting is the source of the announcement.
For clinicians, the important development is the proposed combination of wider access and local adaptation. Those are different achievements. A service can become reachable in a country before its answers are demonstrably appropriate for a particular clinic, professional group or referral network.
This article separates the announcement from the questions a clinician or healthcare organisation still needs answered. Public information was checked on 23 September 2026; country-by-country onboarding and clinical performance were not independently tested.
What is confirmed, and what is not yet independently verified?
The following distinction concerns the strength of the available information. "Reported" means that the announcement is documented, not that every intended deployment has been observed in practice.
| Question | Documented position | What remains to be established for a particular user |
|---|---|---|
| Is this an announced collaboration? | Yes, reported on 22 September 2026 | The implementation applicable to the user's organisation |
| What is the stated access proposition? | Free, with regional adaptation | Eligibility, onboarding requirements and the applicable service terms |
| Is a country list sufficient to prove access? | No individual onboarding was tested for this article | Whether an eligible clinician can complete registration and use the intended functions |
| Are local recommendations independently evaluated? | No such evaluation is established by the announcement reviewed here | Which tasks, settings and populations have been assessed |
| Are language and feature entitlements established for every market? | Not by the information reviewed here | Supported languages, functionality and limitations in the intended deployment |
| Does access establish organisational permission? | An announcement cannot answer that local question | The organisation's approved use, information handling and review arrangements |
The distinction is practical rather than sceptical for its own sake. An eligible doctor could have a working account but lack permission to enter patient information. A service could answer general evidence questions without being integrated into the clinical record. A translated interface could coexist with a source collection that needs further adaptation.
These possibilities should be checked separately rather than compressed into a single "available" label.
The announcement does not describe every OpenEvidence product
A partnership involving a platform does not automatically establish the architecture, access conditions or behaviour of all the platform's offerings. OpenEvidence's separate model-family announcement, published on 3 September 2026, names Osler, Sackett and Snow as production offerings and describes Darwin as a research preview. That is a product taxonomy, not a complete disclosure of the underlying technology. The company's model-family release supplies those names and categories.
Readers investigating technical identity should use iatroX's updated article on what AI model OpenEvidence uses. The question there is narrower: what explicit documentation identifies the components behind a particular service? Neither a partnership headline nor a familiar model name should be stretched into an answer it does not provide.
For a practising clinician, meanwhile, the first question is often less architectural: can this particular product help with the task in front of me, within the conditions under which I am permitted to use it?
What clinicians should establish before relying on access
Begin with professional eligibility. Find the current registration route, the professions included and the evidence requested during verification. Do not assume that eligibility for a physician in one country establishes eligibility for a nurse, pharmacist, student or physician associate elsewhere.
Next, establish the scope of the service. A general evidence-search account, a research preview and an organisation-specific integration are not interchangeable. Ask which functions are actually included, whether limits apply, and whether the answers draw on the source collections relevant to the intended task.
Language deserves its own check. It is possible to translate a question accurately while missing the meaning of a local abbreviation, service name or professional role. A useful assessment therefore includes ordinary local phrasing and checks the cited material, not just whether the interface accepts a language.
Finally, distinguish educational use from patient-specific work. A fictional revision question does not create the same information-handling requirements as a consultation containing identifiable details. A clinician should establish the approved use before entering information, rather than treating a successful login as permission.
Local adaptation needs to be visible in the answer
A country selector is an input. It is not evidence that the system understands what can be done in a particular setting.
Consider a fictional clinician asking about an unfamiliar investigation pathway. The relevant national guidance may be identifiable, but the clinical question could still depend on whether the investigation can be arranged locally, whether specialist advice is available and whether the suggested referral route accepts that patient's circumstances. The system should distinguish these supplied facts from assumptions.
A useful answer might explain the evidence-based pathway, identify the setting information that has actually been provided, and make unresolved practical dependencies explicit. It should not invent a local service or silently reinterpret an unavailable investigation as an unnecessary investigation.
This is an assessment proposal, not a report of how the new service behaves. It supplies a more demanding meaning of localisation: the answer changes appropriately when verified context changes, while important clinical uncertainty remains visible.
The companion article on medical AI's local-resources problem develops that distinction through fictional examples. The separate article on WHO SMART Guidelines explains why source selection, digital implementation and local adaptation are different pieces of work.
What would demonstrate that the rollout is useful?
The first milestone is usable access. That means more than the number of countries named in a release. A deployment report could describe which professional groups successfully onboarded, which functions they used and which barriers prevented others from participating. A transparent denominator matters: invitations, approved accounts and sustained users answer different questions.
The next milestone is task performance. A local evaluation could test whether the system finds relevant evidence, avoids unsupported assumptions about services and recognises when the information supplied is insufficient. Cases should include ordinary questions and difficult boundary conditions, not only examples selected because the answer looks convincing.
A further milestone is usefulness in work. Does checking the output take a manageable amount of effort? Does the answer resolve the clinical question or merely generate another search? Are corrections captured and acted on? Those questions concern the combined performance of the clinician and the system.
Patient benefit requires a different level of evidence again. Faster retrieval, a positive satisfaction response and a correct answer to a test question are not interchangeable with safer care or better outcomes. An evaluation should name the outcome measured and resist promoting an intermediate result into a clinical conclusion.
The published DECIDE-AI reporting guideline, introduced in 2022, provides relevant context for reporting early clinical evaluation of AI decision-support systems. It is not a certification of this partnership or a substitute for an actual local study.
What an organisation could request next
A useful request for information would describe a specific intended use rather than ask whether the platform is "safe" in the abstract. For example: evidence lookup by authorised clinicians in a named service, with no automatic execution of recommendations and an agreed approach to information entry.
Against that use, ask for the product configuration, source scope, supported languages, professional eligibility, review expectations and correction process. Ask how changes are communicated and what happens when a source or local pathway becomes outdated. Also ask how the service behaves when it cannot establish a relevant answer.
An organisation could then begin with a bounded evaluation using fictional or properly de-identified cases. It should retain the configuration and source dates so that a later product change does not make the findings impossible to interpret. This is more informative than granting a whole platform an undifferentiated endorsement after a demonstration.
Apply the same questions to every clinical AI tool
As the publisher of this article, iatroX should meet the same expectations it describes for others. Per iatroX product information, September 2026, Ask-iatroX is free clinical reference grounded in NICE, CKS, SIGN and SmPC information from emc, with linked sources. Its published methodology explains the intended retrieval, ranking, citation grounding, output checking and uncertainty handling.
Those are inspectable design features, not proof that every answer is correct. A UK-focused source set does not remove the need to check population, recommendation, setting and applicability. Equally, international expansion does not make a tool inherently unsuitable for local work.
The useful question is whether the application provides an appropriately supported answer for the actual task, while showing where its knowledge of the setting ends. Wider access is an important opportunity. Demonstrable local usefulness is the standard by which that opportunity should be judged.
Frequently asked questions
What have Anthropic and OpenEvidence announced?
The collaboration concerns wider access to a regionally adapted medical AI service, as reported on 22 September 2026. The announcement should not be treated as confirmation of every country's onboarding process or every product's technical architecture.
Does the announcement mean UK clinicians can definitely register?
No UK registration test was completed for this article, and broad geographical wording does not establish an individual clinician's eligibility or feature access. iatroX's updated UK OpenEvidence article separates those questions from organisational permission to use a service.
Does local adaptation prove that recommendations are clinically validated?
No: local adaptation describes work intended to improve relevance, whereas clinical validation requires an appropriate evaluation of a defined system, use and setting. Readers should ask what was assessed and avoid treating design claims as outcome evidence.