Support & operations · Practical guide

Carry emergency fixes back into normal publishing

A supplier edits the live output directly, and the next routine release silently restores the original fault.

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

Make the lasting correction in the source used by normal publishing, then verify it through that process. An emergency patch may restore service quickly, but its location and relationship to the maintained version must be recorded. Ask the supplier to show both the immediate repair and the source reconciliation. The final acceptance test is a normal regeneration that retains the fix, not merely a screenshot taken immediately after a live edit.

A worked example

Illustrative example

Illustrative test: The emergency repair remains present after a clean routine publication. An urgent live change may repair a broken enquiry link, but the source project still contains the old value. The next content publication would restore it. The supplier reconciles the change into the maintained source and runs normal publishing. Your reviewer follows the original failing link again afterwards. The issue can then close with evidence that routine editing preserves the repair, not merely that an emergency patch worked briefly.

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

An urgent live edit may restore a broken page quickly, but the next routine publication can overwrite it if the maintained source was never corrected. Ask your supplier to record where the emergency change was made and reconcile it into the normal project. Then run the ordinary publishing process and repeat the original failing action. This establishes that the repair will survive future content updates. Keep the immediate service restoration and the lasting source correction as distinct parts of the issue until both are complete. Your practice should not have to remember to warn every future editor about a fragile patch that exists only in the currently deployed files.

How to check the result

The maintained source and live behaviour agree on the corrected implementation.

A mistake to avoid

Closing the incident before source reconciliation leaves the fault ready to return.

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.