A practical way to compare embedded clinical search, patient context and reviewable actions before committing to a wider rollout.
An AMBOSS AI Mode pilot should produce an acceptance record for the capability the hospital is actually buying. A strong search result does not establish that patient context is current, and a convincing draft does not establish that an action can be reviewed reliably. Each additional integration capability needs its own evidence before the institution expands the permitted workflow.
Published by iatroX, which offers clinical reference and learning tools. Product descriptions were checked against public documentation on 26 October 2026. The worksheet below is an original proposed evaluation aid, not an official standard, completed product trial or report of supplier performance. It translates a particular roadmap into observable acceptance questions.
Put the contracted capability on page one
AMBOSS's integration roadmap distinguishes live search without patient data, forthcoming chart context and writeback in development; the richer demonstration is a research preview. The existing iatroX rollout explainer provides the background. Here, the purpose is to assess the exact configuration offered locally.
Create an acceptance record with these fields: product and version; institution and environment; clinical task; intended users; source collection; permitted inputs; permitted outputs; capabilities excluded; supplier contact; hospital decision owner; and test date. Attach the specification or written confirmation that identifies what is available now.
Make the scope a sentence: "This acceptance stage evaluates [task], using [inputs], producing [output], for [users]." If the supplier demonstrates a different configuration, record the difference. A test in an idealised sandbox cannot silently become evidence that the contracted hospital environment behaves identically.
Gate one: accept in-chart search on its own terms
Use representative evidence questions and synthetic scenarios. Prepare the expected scope and suitable source material before seeing the generated answer. The starting comparison should be the institution's current way of completing that same task, including the work of checking sources and returning to the chart.
For every row in the following three tables, add five local fields: observed result, evidence reference, responsible reviewer, unresolved issue and decision. An evidence reference should identify the saved test input and output or witnessed interaction; "looked good in demo" is insufficiently reproducible.
| Search test | Input or action | Expected observation to agree locally |
|---|---|---|
| S1: launch | Open search from the intended EHR location | Correct user and agreed access route are visible |
| S2: task | Ask a representative evidence question | The answer addresses the defined information need |
| S3: support | Open the sources for material claims | Supporting passages are accessible and relevant |
| S4: applicability | Specify setting and jurisdiction | Applicability and material qualifications remain visible |
| S5: recovery | Close the answer and resume the original task | The clinician can complete the agreed workflow |
Record complete-task time as an observation, including source review and correction. Do not replace content assessment with a count of clicks. A convenient interface with unresolved material claims has not met the same requirement as a checked answer that is easy to use.
Gate two: add patient context only when offered
This gate belongs to a configuration that actually receives patient context. It cannot be marked passed on the strength of the search gate. Document the permitted record fields and time window before running it. Use wholly synthetic records whose relevant facts and deliberate gaps are known to the assessors.
| Context test | Input or action | Expected observation to agree locally |
|---|---|---|
| C1: selection | Supply a known synthetic record | Relevant supplied facts and their source can be identified |
| C2: missingness | Withhold a field material to the question | Missing input is distinguishable from a documented negative |
| C3: contradiction | Supply two entries with conflicting status | The material conflict can be inspected and resolved |
| C4: change | Update a fact while an answer remains open | Refresh or expiry behaviour is observable |
| C5: encounter | Switch to a different synthetic encounter | Context stays associated with the intended record |
Agree what constitutes a material omission for each case beforehand. If a fact never reaches the assistant, classify that separately from a fact received but misinterpreted. The remedies may involve different teams. An unexplained answer change should remain an unresolved finding until the reviewers can account for it.
Gate three: assess proposed actions separately
If structured output back into the chart becomes available, give it another acceptance stage. A draft, a saved note and an executed order are different states. The implementation team should demonstrate which states the offered configuration permits and what the clinician must do to move between them.
| Action test | Input or action | Expected observation to agree locally |
|---|---|---|
| A1: inspect | Open proposed structured output | Content and intended destination can be reviewed |
| A2: amend | Change a draft before acceptance | The clinician's amendment remains visible in the resulting output |
| A3: reject | Decline a proposed action | Rejection leaves no unintended completed action |
| A4: stale input | Change relevant context before acceptance | The agreed recheck or invalidation behaviour occurs |
| A5: trace | Review the result in the test record | The resulting state and responsible user can be established |
These are proposed questions, not claims that AMBOSS currently offers these functions or lacks any control. Where a function remains unavailable, enter "not offered in this configuration". That is more useful than a speculative score based on the roadmap.
Use explicit stop conditions
Averages can obscure findings that matter to the acceptance decision. Agree stop conditions before testing. Examples for local consideration include an unresolved record mismatch, an untraceable material claim, a draft appearing in the wrong destination or uncertainty about whether a test action completed. The appropriate threshold and response belong to the institution's clinical and technical owners.
For every unresolved finding, record its scope, evidence, owner, proposed remedy and retest requirement. Keep a clear distinction between a capability that failed its agreed test, one not tested and one not available. None should be counted as an implicit pass because another part of the demonstration performed well.
Possible decisions include accepting the defined search workflow, accepting it with a specific restriction, requesting correction and retesting, or declining expansion. The decision record should name the capability being accepted. It should never approve an unspecified future product.
Ask competing suppliers for the same evidence
UpToDate documents EHR links and contextual Infobutton approaches. ClinicalKey AI advertises EHR/API access and context tailoring when prompted. Those descriptions do not establish identical chart permissions. Ask each supplier which gate its offered configuration can demonstrate.
For a documented contextual deployment, Cedars-Sinai describes enterprise OpenEvidence access combining relevant record information with evidence; adding local pathways remains a stated plan. A different hospital still needs evidence for its own configuration. Compare the same task and permitted context, rather than ranking products by their broadest advertised ambition.
The case for integration is practical: information can become easier to access and repeated entry may fall. The counterweight is the additional work of establishing context, review and action behaviour. The three gates let a hospital recognise a useful improvement without assuming that it settles every later requirement.
Keep a reference-and-learning route available
An institutional acceptance record answers a deployment question. A clinician also needs a way to investigate general knowledge gaps and practise reasoning. iatroX connects referenced lookup, structured Brainstorm reasoning and education, making it a useful option for UK-focused reference and continued learning alongside an employer's workflow.
Apply the same source scrutiny to iatroX. Its documented reference-and-learning scope is the reason to consider it here; an acceptance record should credit only capabilities that are actually demonstrated. For broader pilot design, read the existing NHS scale-up evidence guide.
FAQs
Does passing the search gate approve patient-aware AMBOSS functions?
No. It supports a decision about the tested search configuration. Patient-context support needs its own inputs, acceptance criteria and observed evidence when that capability is offered.
Are the fifteen tests an official clinical AI standard?
They are an editorial worksheet for organising a local assessment. Institutions need their own clinical, technical and procurement requirements; completing this sheet does not establish compliance or safety.
Where does iatroX fit in this evaluation?
iatroX is relevant to referenced questions, UK clinical context and deliberate learning. Assess those documented workflows directly rather than assuming an EHR integration capability.
Explore how iatroX works, then use a capability-specific acceptance record to compare the information task that matters to you.