Support & operations · Practical guide

Publish the version your practice actually approved

The practice approves one preview, but the supplier publishes a later build containing additional unreviewed changes.

Healthcare website support desk with a system checklist, telephone and orange notebook.
Know who to call and what help your support arrangement includes.

What to change

Tie approval to an identifiable release, not merely to a preview address that can change. Ask the supplier to record the reviewed revision and demonstrate that the public deployment contains it. Any additional changes should be visible as a separate review decision. This makes acceptance specific enough to reproduce and gives the owner a meaningful reference if a fault later requires restoration of the last approved version.

A worked example

Illustrative example

Illustrative test: A harmless visible test change distinguishes the approved revision from a later draft. A practice may approve revised contact wording in a preview, then the supplier adds an unrelated navigation experiment before publishing. An identifiable reviewed version reveals the difference. The owner can approve the additional change separately or request the original release. After publication, the agreed wording and version are checked publicly. The record therefore describes what was actually accepted, rather than relying on a preview URL whose contents keep changing.

Healthcare website maintenance with infrastructure, a status panel, tools and an operational checklist.
Monitor the useful journey, not just whether a server responds.
Healthcare backup and recovery illustrated by storage copies, an archive folder and a restoration route.
Test whether a backup can restore a usable service.

What this means for your practice

A preview address can change as a supplier continues working. Approving that link on Monday does not necessarily approve every change later placed at the same address. Ask the supplier to identify the reviewed version and connect it to the release that will go live. Any additions should be visible as a separate decision. After publication, compare the agreed changes on the real website and retain the version reference with your approval. This is useful if a fault later requires restoring a known acceptable state. A simple visible example can help your team distinguish versions, while the supplier maintains the technical release identifier behind the record.

How to check the result

The published release matches the approval evidence and any differences are explicitly accepted.

A mistake to avoid

A reusable preview URL alone does not identify what was approved.

Turn reading into a next step

Your action checklist

Work through these checks with your team or supplier. Tick the ones you have resolved and leave unknowns open.

Checks to discuss

Record what you know, what is still missing and the answer you need from your team or supplier.

Use project decisions only, without personal, patient or confidential details. Entries stay in this page and are not submitted to Kay & Co. Copy or download before leaving; this page does not save your notes.

Further reading

These sources provide background for the topic. The practice examples and checklist are illustrative planning suggestions from Kay & Co.

Related guides

Need help with this?

Tell us what is getting in the way. Kay & Co. can help you understand the options and turn the next step into something that works for your practice.

Explore support & operations services or discuss your project.

Try the free Healthcare Digital Planner to find your starting priority.