A country dropdown can tell a medical AI tool where the user works. It cannot, by itself, establish which guideline applies, what information a recommendation requires or how a local service implements it. Localisation is the work of making those relationships explicit, testable and maintainable.
WHO's SMART Guidelines provide an established reference for that work. SMART means Standards-based, Machine-readable, Adaptive, Requirements-based and Testable. WHO describes reusable digital components and a five-step route from recommendations towards implementation. WHO's programme page, checked on 23 September 2026, explains the approach.
This is relevant context for current medical AI expansion. It is not evidence that the Anthropic and OpenEvidence partnership uses WHO SMART Guidelines, and no such implementation claim is made here.
Translation, source selection and pathway adaptation are different
Translation changes the language in which information is expressed. It needs to preserve meaning, including uncertainty and distinctions between recommendations, options and requirements. A fluent translation can still be misleading if a local term refers to a different service or professional role.
Source selection determines which material should inform the answer. A national guideline, a product-specific document and a local pathway can address different parts of the same question. Selecting a country's language does not establish that the relevant source was retrieved.
Pathway adaptation concerns what happens in practice. It may require specifying the responsible professional, the information collected, the referral route and the point at which a human decision is required. A recommendation can remain unchanged while its operational implementation differs.
Conflating these tasks creates an attractive but weak claim: that a tool is localised because it uses familiar language and names the country. A more useful question is which of these tasks has actually been completed and how a user can inspect it.
What WHO's approach adds
WHO's digital adaptation kits are designed to express health programme requirements in a structured, software-neutral form. They help bridge the gap between those responsible for clinical guidance and those building digital systems. The material can specify workflows, data needs and decision logic without assuming that a single software vendor supplies the implementation. WHO's explanation of SMART Guidelines and digital adaptation kits describes that purpose.
For medical AI, the important lesson is that narrative guidance is not automatically an executable specification. The information a clinician can interpret in prose may need to be represented explicitly before software can use it consistently.
A narrative statement can contain conditions, exceptions, implied sequencing and unresolved judgement. A digital system needs an intentional way to handle those features. Otherwise, implementation decisions may be made accidentally by a prompt, a default value or the wording of an interface.
The following worked example is an original illustration of those implementation questions. It is not a WHO guideline, a clinical recommendation or a description of an existing product.
Worked example: turning a routine invitation policy into a workflow
Imagine an approved local policy stating that eligible people should be invited for a routine preventive assessment. The example deliberately supplies no clinical eligibility criteria, assessment interval or treatment instruction. Its purpose is to examine how a recommendation becomes a usable digital process.
The first task is to identify the policy and its scope. Who approved it? Which service does it cover? Is it current? Does it describe an invitation, a clinical assessment or both? Those distinctions affect what the software is being asked to do.
The next task is to identify the required inputs. Eligibility must be established by the approved process. Contact information must be current and usable under the organisation's arrangements. The person's communication needs may affect how the invitation is prepared. Missing information should not be treated as a negative answer.
The workflow must then distinguish a draft from an action. Preparing an invitation for review is not the same as sending it. Confirming eligibility is not the same as confirming attendance. A system should not award itself a completed task merely because it generated plausible text.
| Implementation element | Question the team must answer | Example of a testable requirement |
|---|---|---|
| Source identity | Which approved policy governs this workflow? | Display the policy title and version used |
| Scope | Is the task invitation preparation or clinical assessment? | Do not present a draft invitation as a completed assessment |
| Required input | Has eligibility been established by the approved process? | Route unknown eligibility for review rather than treating it as false |
| Local adaptation | Which service and contact route apply? | Use only the approved local route supplied to the system |
| Human responsibility | Who reviews the draft and authorises an action? | Distinguish preparation, approval and sending |
| Change handling | What happens when the policy is replaced? | Prevent the superseded version from silently governing new work |
The table demonstrates why localisation is not merely a change in wording. The software needs a representation of the task, its inputs and its boundaries.
Missing is not the same as no
An apparently small data decision can change the meaning of a workflow. If a required item is missing, does the system stop, ask a question, use a default or infer a value?
In the fictional invitation example, missing eligibility information should not quietly become "not eligible". Equally, the absence of a recorded exclusion should not automatically become evidence that the person is eligible. Those are different claims about the state of knowledge.
A language model can make this problem harder to notice because it can produce a smooth explanation around an unsupported assumption. A digital specification should therefore identify important unknown states and define how they are surfaced.
This does not mean collecting every possible detail before answering. It means identifying which missing inputs materially affect the task. An application can provide general information while clearly stating that it cannot resolve an eligibility-dependent decision from the supplied facts.
A recommendation is not always an if-then rule
Some guidance can be represented as explicit conditions and actions. Other parts require judgement, discussion or interpretation of evidence that does not reduce cleanly to a single branch.
A localisation process should identify that boundary rather than force all guidance into deterministic logic. The system might present the relevant considerations and request professional review instead of pretending that the narrative contains a fully specified decision rule.
It should also distinguish a recommendation from a local administrative requirement. A local document may define where a referral is sent without supplying the clinical evidence for making the referral. A national recommendation may explain when an assessment is appropriate without specifying the local booking process.
A useful interface shows these roles separately. Otherwise, a local operational detail can acquire the apparent authority of national guidance, or a national recommendation can be mistaken for a verified description of local service availability.
Versioning is part of clinical meaning
A citation to a document title is incomplete when several versions may exist. The user needs to know which version informed the output and whether a local modification was applied.
In a proposed implementation record, the original source, local adaptation and approval decision would be linked but distinct. A team could then examine whether a change came from new evidence, a revised local workflow or a software modification.
This matters when a recommendation changes. Updating the source collection is not necessarily enough if the previous interpretation remains embedded in prompts, examples, tests or interface text. The update needs to reach the components that depend on it.
An evaluation can test this directly with a fictional version change. Supply an approved replacement policy, remove the superseded version and check whether the system still reproduces the old logic. The result should be recorded for the actual implementation; it should not be assumed from a statement that the knowledge base is updated regularly.
What clinicians and informatics teams can ask
A practical assessment starts with a single output. Can the user identify the supporting source and the version used? Can they see whether a local document modified the operational pathway? Can they distinguish supplied facts from assumptions?
Then examine a boundary case. What happens when required information is missing, when sources disagree or when a local service cannot be established? A system that always produces a complete-looking plan may be less transparent than one that identifies a specific unresolved dependency.
Finally, examine maintenance. Who owns the local source collection? Who approves an adaptation? How are errors reported and corrected? Can a known problem be traced to the affected version and use case?
These questions do not require every clinician to read a technical specification. They require the organisation or supplier to make the relevant decisions inspectable and to give users a clear route when the answer depends on something the system does not know.
Applying the principle to generative clinical reference
WHO's approach should not be treated as a claim that every clinical AI answer must be a rigid decision tree. A conversational system can help users explore evidence and ask better questions. The implementation discipline concerns what the system is allowed to infer and how its output relates to the source.
For a reference answer, a lightweight record of jurisdiction, source version, setting and unresolved facts may be enough to expose important assumptions. For a workflow that prepares or executes actions, a more explicit specification of states, permissions and review steps is needed.
The proposed context-receipt article in this series explores the first idea. The proposed context-sensitive benchmark explores how to test whether an answer changes appropriately when a material setting variable changes. Neither is presented as a WHO-certified instrument.
What UK-focused should mean for iatroX
Per iatroX product information, September 2026, Ask-iatroX uses NICE, CKS, SIGN and SmPC information from emc with linked sources. Its methodology describes intended source selection, ranking, grounding and uncertainty handling.
That provides a relevant source orientation. It does not establish that every UK pathway is represented, that every local service is known or that every answer is superior to an international alternative. A UK label is useful only when the actual source and assumptions match the task.
The practical standard is therefore the same for iatroX and any other platform: preserve the meaning of the evidence, distinguish it from local implementation and make uncertainty visible where the system lacks the information needed to connect the two.
Frequently asked questions
What are WHO SMART Guidelines?
They are WHO's approach to expressing recommendations through standards-based, machine-readable, adaptive, requirements-based and testable digital components. They help connect narrative guidance with the requirements of digital implementation.
Does the Anthropic and OpenEvidence partnership use WHO SMART Guidelines?
That is not established by the sources reviewed for this article on 23 September 2026. WHO's framework is used here as relevant implementation context, not as a claimed component of the partnership.
Is selecting UK guidance enough to localise a medical AI answer?
No: source selection is important, but the answer may also depend on the care setting, local pathway, required inputs and unresolved facts. Those dependencies should be identified rather than inferred from a country label alone.
Explore source-linked UK clinical reference with Ask-iatroX →