Printable hospital template
Hospital software issue report worksheet
Give support a clear description of the affected task, what happened and how to reproduce it with fictional data, without copying patient records into a ticket.
- Written by
- RizCare
- Published
- Last reviewed
RizCare's suggested worksheet. Adapt to your hospital. https://riz.care/library/templates/clinic-software-issue-report
For the hospital contact reporting a software problem.
It is not working gives support very little to investigate. The save button stayed on saving after I recorded a fictional payment tells them where to start. A useful report preserves the observation without exposing the patient's record.
Urgent care follows the hospital's established clinical escalation and continuity procedures. Opening a software ticket is an administrative action and should not hold up that response.
Print this page or save it as a PDF from your browser. The print layout contains only the blank worksheet and its completion note. Fill it in within your hospital.
Practice: ____________________ Prepared by: ____________________ Date: ______________
| Issue / time zone | Task / device | Expected / observed | Safe evidence | Ticket / next check |
|---|---|---|---|---|
| Blank entry | ||||
| Blank entry | ||||
| Blank entry | ||||
| Blank entry | ||||
| Blank entry |
Keep completed copies with the staff authorised to use them.
How to use it
Capture the failure boundary
Record the time with timezone, device reference, relevant screen and the task being attempted. Distinguish an error message from an unexpected result or a slow response. Note whether one device or several are affected. Use an issue reference to connect follow-up reports rather than sending the same problem as several unrelated tickets.
Describe a safe reproduction
Where possible, repeat the steps in an approved demonstration environment using invented records. Write the sequence, expected outcome and observed outcome. Do not experiment on a signed clinical note or repeat a real payment to see whether the problem happens again. If reproduction is unsafe or unavailable, say so and retain the original observation.
Send only what support needs
Use the agreed support channel and check attachments before sending. Remove patient details, credentials, account identifiers and unrelated browser tabs. Share a sanitised error reference instead of a full database or record export. Record the support acknowledgement and next action. Do not describe the issue as fixed until the hospital has checked the relevant task again.
What each field means
- Expected and observed
- Write each separately so the support reader can distinguish the intended action from your interpretation of the fault.
- Impact
- Describe the administrative work affected and the agreed continuity route in use. Clinical priority should be assigned through the clinical team, not guessed from this sheet.
- Evidence and response
- Reference the sanitised evidence and support ticket. Record a response received independently from a correction confirmed, with the colleague responsible for checking it.
Completed fictional example
The fictional example uses a demonstration receipt. Never create a second real payment for troubleshooting.
| Issue / time zone | Task / device | Expected / observed | Safe evidence | Ticket / next check |
|---|---|---|---|---|
| ISS-014 / 10:20 WAT | Fictional receipt / DEMO-02 | Save completes / message remains | Sanitised steps S-14 | SUP-44 / Staff A |
Related resources
Sources and review
The worksheet design and examples are RizCare's recommendations. The sources below support the background discussion; they do not endorse this form.
- Workflow Assessment for Health IT Toolkit (Agency for Healthcare Research and Quality). Read 9 September 2026.