A worked release, replacement and withdrawal process for local guidance in an EHR clinical assistant.
A local protocol can make a clinical AI answer more useful on the ward. It can identify the pathway, service or operational rule that actually applies in that hospital. The less visible question arrives six months later: when the protocol changes, who proves that the old version has stopped influencing new answers?
AMBOSS's healthcare integration page includes local protocols in its clinical-search offering and describes deeper integration under development. That makes ongoing content control a useful procurement question today. It does not establish how a particular hospital's protocol replacement process works.
This article is published by iatroX. Product documentation was checked on 26 October 2026. The control process below is an original worked proposal, not a report of an AMBOSS incident or a claim that a supplier lacks these controls.
Start with a change, rather than an upload
Suppose a fictional hospital uses local document LP-42 to explain which service receives a referral. Version 3 directs the clinician to Team A. Version 4 changes the destination to Team B from Monday morning. No diagnosis, medicine or treatment recommendation is needed to test the underlying information problem.
The hospital could successfully upload version 4 and still have an incomplete change. The old file may remain available under another name. An answer generated on Sunday may stay open on Monday. A saved link may resolve to an outdated copy. A secondary teaching page may repeat the old destination.
Treat the release as a set of state changes: approved, published, available for retrieval, superseded and withdrawn. Each state needs an observable result. "We sent the new document" records an action; "a fresh query retrieves the approved replacement and identifies its effective date" records a testable outcome.
For the broader question of competing guidance, see our existing discussion of local protocols and national evidence. Here, the task is controlling a change after the hierarchy has been agreed.
Give three people different decisions
A practical release process separates clinical authority from technical publication and local deployment. One person can hold several roles in a small service, but the decisions should remain distinguishable.
| Role | Decision to own | Evidence to retain |
|---|---|---|
| Clinical owner | Approve the meaning, audience and effective period | Approval record and explanation of the change |
| Technical publisher | Deliver the intended version and remove superseded retrieval paths | Publication record and retrieval tests |
| Deployment owner | Confirm the release works in the hospital's actual configuration | Acceptance result, communication and escalation contact |
The clinical owner should not have to guess whether an index has refreshed. The technical publisher should not decide which clinical recommendation takes precedence. The deployment owner should know how to restrict a feature if an unresolved problem appears.
Agree these responsibilities before the first local document enters the service. If a supplier manages publication, put the hospital's approval and withdrawal requirements into the agreed workflow. A named mailbox alone is insufficient unless someone is responsible for monitoring and acting on it.
Use one control record from approval to withdrawal
The following fictional record is deliberately small enough to complete during an ordinary release. It can be a form or ticket; its value lies in keeping approval, implementation and proof together.
| Field | Fictional LP-42 entry |
|---|---|
| Change | Referral destination changes from Team A to Team B |
| Approved replacement | LP-42 version 4, effective Monday 09:00 |
| Superseded material | Version 3 plus its duplicate attachment and teaching-page excerpt |
| Acceptance queries | Direct title, old service name, new service name and a paraphrased referral question |
| Expected fresh result | Version 4 identified; current destination shown; source link resolves correctly |
| Historical result | Version 3 labelled as historical where retention is required |
| Open-answer handling | Behaviour agreed for answers generated before the effective time |
| Release decision | Named approver, test completion time and unresolved issues |
| Recovery route | Restrict affected retrieval and show the approved source while corrected |
The record links a content change to a bounded test. It does not prescribe whether a supplier must use a particular database, cache design or interoperability resource. Ask for the observable behaviour, then let the implementation team explain how it is achieved.
Prove replacement through several routes
Run the acceptance queries in the deployed configuration, using permitted test accounts. A test of the publisher's document store is useful but cannot establish what the clinician sees inside the chart.
Begin with an exact-title query. Then use the old service name: this is where a superseded attachment or synonym may remain discoverable. Next ask a natural question without naming the protocol. Finally open the cited source and verify that the displayed version matches the answer.
Repeat after the effective time, rather than only immediately after upload. Record whether results differ between a new session and an already open session. If different departments receive different local content, test the intended department boundary too. These are proposed evaluation conditions, not assertions about current AMBOSS behaviour.
A withdrawn document can remain in an authorised historical archive while being excluded from current recommendations. Ask the supplier to demonstrate that distinction. Keeping an audit history and serving an old instruction as current guidance are different outcomes.
Decide what happens to an answer already on screen
A protocol release changes the source state; it may not automatically change every answer previously generated from that source. The hospital therefore needs an explicit position on saved answers, shared links and drafts awaiting review.
For LP-42, the team might require an answer created before Monday 09:00 to show its generation time and prompt a fresh source check when reopened. Another configuration may regenerate the answer. The appropriate behaviour depends on the actual workflow and must be agreed and tested, rather than assumed from the presence of citations.
If the wrong version appears, preserve enough information to investigate: query, source identifier, generation time, configuration and observed result. Route clinical interpretation to the clinical owner and technical correction to the publisher. Re-run the original acceptance set after correction so closure rests on evidence of the changed behaviour.
Recovery should also be bounded. Restoring an earlier software configuration does not make a withdrawn protocol current again. Keep the content approval decision separate from any technical rollback decision.
Compare the maintenance commitment across systems
Local knowledge is becoming a wider competitive issue. In its May 2026 announcement, Cedars-Sinai describes plans to add its pathways and protocols to OpenEvidence, separately from its live patient-context access. That distinction matters when comparing offers: planned local-content support and an accepted maintenance workflow are different procurement evidence.
Ask each supplier to walk through the same LP-42 change. Who can approve it? How is the effective time represented? What excludes the old attachment? What happens to an existing answer? How does the hospital know the correction reached its deployed service?
Integration can put locally relevant information closer to a decision. Its counterweight is recurring maintenance work. A useful contract or operating agreement should make that work visible instead of treating local content as a one-time import.
Keep an independent UK reference question available
A national evidence question can remain useful while the hospital resolves a local publishing issue. iatroX's published workflow includes referenced lookup and structured reasoning, giving UK clinicians a direct route to examine the general knowledge behind a question.
That is a practical reason to keep iatroX alongside an institutional assistant. A clinician might inspect the national guidance for a referral principle, then use the hospital's approved source to establish the current destination and process. The two checks answer different parts of the task.
The hospital still owns the local operational decision. A reference answer cannot approve LP-42, withdraw a hospital document or certify another platform's release. The useful outcome is a visible path from the general evidence to the current local instruction, with a person responsible when either changes.
FAQs
Does AMBOSS already support every part of this workflow?
This article proposes acceptance questions. AMBOSS's public integration page does not establish every hospital's release, replacement and withdrawal process. Ask for a demonstration in the contracted configuration.
Should a superseded protocol be deleted completely?
Current retrieval and historical retention are separate requirements. Agree how an authorised archive is retained and labelled while superseded material is excluded from current recommendations.
Can iatroX decide which local protocol takes priority?
The hospital's authorised clinical owner decides local policy. iatroX can support a referenced general-knowledge question; it does not replace that approval process.
Explore askiatroX for a UK clinical-reference question, and keep the approved local pathway alongside the evidence you inspect.