Procedure
Getting help
Steps for raising a support request, what to include so it can be actioned, and how to reach support during and outside working hours.
When something goes wrong, a hospital raises a support request through its own nominated authorised support contacts. This page sets out who may open a request, what a good request says, why patient data never goes into one, and what happens on the rare occasion an engineer has to look at a record.
Where to check first
A status page shows the current state of the Platform, the incidents that are open, and the history of past ones. A knowledge base publishes help articles and how-to documentation that answer common questions. If the answer is on either, a request is not needed. Where it is not, an authorised support contact opens one.
Raise a request
A request is a ticket. It is raised by one of the hospital's nominated authorised support contacts, and any of them may open a ticket at any severity.
- 1
Open the request as an authorised support contact
Only a nominated authorised support contact opens the ticket. The hospital keeps that list current and can change it by notice at any time.
- 2
Say what is affected, in identifiers
Name the site, the affected department and the users affected, describe what the user was doing when the problem appeared, and note the time it began. Support works from these identifiers, not from the contents of a record.
- 3
Quote any error reference the screen shows
Copy the error reference exactly as it appears. An engineer traces a fault from that reference far more quickly than from a description alone.
- 4
Propose a severity
Set the severity that matches the operational consequence to the hospital. Support confirms or corrects it. The response targets that follow from each level are on the severity page.
- 5
Telephone as well for a Severity 1
A Severity 1 matter carries a telephone emergency line in addition to the ticket, and is received, acknowledged and worked around the clock on every support tier, including a business-hours tier. Telephone the emergency line as well as opening the ticket.
Patient data never goes into a request
Patient data must never be pasted into a ticket, a chat or an e-mail. A screenshot that contains patient data is refused and deleted rather than kept. Describe the screen and quote the error reference instead. Support is built to resolve a request from identifiers and references, so the record itself stays where it belongs.
When support needs to see a record
Most requests are settled without anyone opening a record. Where a defect can only be understood by looking at one, an engineer's access is made under a grant that a second person approves, that is scoped to the task and time-bound, and that expires on its own with no revocation step for anyone to forget. The engineer works in the live environment and takes no copy of the record: nothing is exported to a laptop and nothing is restored into a lower environment. Every action under the grant is written to the hospital's own immutable audit trail, which the engineer cannot alter, and the grant, its reason and its approver are disclosable to the hospital on request.
No standing access
No engineer holds standing permission to read a hospital's data. Access begins at nothing, is requested and approved for a stated reason, and returns to nothing when the grant expires.
Can we send a screenshot?
A screenshot with no patient data on it is welcome. A screenshot that shows patient data is refused and deleted, so crop it out or describe the screen and quote the error reference instead.
What if it is out of hours?
A Severity 1 is worked every hour of every day, on every support tier. The tier recorded for the site sets the handling of the lower severities. The targets for each level are on the severity page.
Who is allowed to open a ticket?
The hospital's nominated authorised support contacts. Any of them may raise a ticket at any severity, and the hospital changes that list by notice.
Read how each level is classified and how a request rises in severity and escalation, how every engineer action is recorded in the audit trail, and who holds which duty in shared responsibility.