Kinesis – Replacing archaic Pager systems

Referral avoidance NHS Advice and guidance

Why does the current bleep process need to be replaced?

The current bleep or pager process used within the NHS has been in use for decades. Pagers or bleep systems were first implemented in a New York hospital back in 1970 nearly 50 years ago and have stood the test of time. But the question is, now in the 21st Century where cars can self-drive, and drones deliver our shopping, why have we not progressed the technology and process for our hospitals? Can more be done to smooth out the process for seeking a colleague’s expertise? Can a better system be implemented to remove the current boundaries around using pagers?

2021 was supposed to be the year that bleeps were phased out across the NHS, as stated in the health and social report, “NHS trusts will be required to phase out pagers by the end of 2021. All hospitals will be expected to have plans and infrastructure in place to ensure this is possible by the end of September 2020” but unfortunately, this has not been the case and pagers are still being used by at least 80% of UK hospitals.

As stated by the Health Secretary in 2019 bleep systems are “outdated, archaic devices” that offer a one-way form of communication with clinical colleagues which can be time-consuming, interruptive, and complicates the prioritisation of tasks. As bleep communications cannot be archived, many hospital clinicians create a personal ‘to-do’ list, often on paper, with attendant clinical safety risk. Pagers also come at a significant cost to the NHS; devices can cost ~£400; the NHS annual bleep spend is currently £6.6 million.

So how can this process be replaced using more intuitive forms of modern innovation such as Kinesis? Instead of receiving a bleep, phoning the clinician, and writing down the clinical information, staff could instead access their colleagues using bespoke search and messaging functions, mitigating the one-way communication process currently being used. The patient’s clinical information and the conversation would be archived and if a call was required, this could be done in the same space without the need for a phone or a written message.

How Kinesis technology creates a modern process

The move to replace pagers with modern technology is a key step to achieving a fully digitised NHS. Kinesis is a web-based application, with a mobile app option, that can be accessed on any device at any time. The Kinesis system would replace pagers and provide a range of additional benefits; using existing smartphone hardware ensures costs are reduced. The Kinesis two-way messaging service has been perfected by our clinical users over the course of 10 years. Kinesis already allows staff to seek out a clinician working within their hospital based on a range of profile and expertise information:  colleagues can be found based on their speciality, department or by name or other relevant profile attributes. For richer context, the ‘requester’ can specify key clinical information, the patients’ details, urgency and location indicators and more. This is based on the  ‘SBAR’ protocol – Situation, Background, Assessment, Recommendation. By collecting this information prior to the message being sent, we can ensure the clinician receiving the Kinesis ‘bleep’ has the clinical information needed to prioritise and make quick, informed decisions.

Receiving clinicians respond to the requesting clinician with clinical advice,  actions or other appropriate response. This might be “Please give the patient XYZ and monitor” OR “I will come and see the patient in X minutes” AND “is there anything else I can do in the meantime”. Other actions are available, such as routing to a colleague.

Kinesis implements ‘quick response’ options to reduce the need to type in a reply, allowing selection from predefined responses. Voice responses are also supported, with a voice to text conversation either on the device or via a secure cloud service (Azure cognitive services). For example: “Message received – I will be able to see the patient in X minutes/hours”. Kinesis will work with the hospital to implement this functionality.

Kinesis ensures that the clinician receiving a ‘bleep’ or ‘message’ is notified immediately, with a range of notification mechanisms supported, appropriate to the operating environment and user preference. Current options include email, SMS text message, in-app notification.

Kinesis supports an extensive set of Real-World business logic, such as ‘out of office’, ‘annual leave’ status, working days/hours etc. to ensure requesting clinicians are able to target available colleagues. Presence indicators allow routing to the most available colleagues; with on-call staff able to update this in real-time. Where APIs support it, presence information can also be accessed from other systems (calendar, Microsoft 365, roster system etc). We aim to keep work and home life separate for staff and give them control over their availability, in conjunction with the organisation’s policies.

There is support for Groups, including by speciality and multi-disciplinary teams; with a variety of other business rules, such as allocating on-call and secondary-call members, ‘first to respond’ rules and more.

Urgent or Mayday Messages

The urgency of ‘bleeps’ is not well differentiated in the legacy systems. The Kinesis platform allows a more granular indication of urgency in messaging, which can be used to route messages intelligently, reduce interruptions for on-call staff and improve personal and team prioritisation of response. However, on occasion, clinicians will need urgent assistance and in this instance, it is vital that the messages are received immediately, possibly by more than one member of staff, to attend as fast as possible. By following a very similar process to the maritime distress procedure, or ‘MAYDAY’ process; users can be given access to a dedicated Mayday button. Kinesis will use a range of notifications, including calling the appropriate clinical team members directly with an automated voice note, e.g. ‘CRASH CART TEAM REQUIRED ON WARD B’. The system then presents information and has escalation procedures in the case that an acknowledgement is not received until the ‘MAYDAY’ is allocated.

This process would also apply in exceptional circumstances where all hospital staff need to be made aware of an incident. For example, if the hospital is about to receive a large number of urgent patients from a road traffic incident, or terrorist attack, the response team would use the ‘MAYDAY’ button to ensure all staff members are ready to act on the event in question.

Kinesis would bring the following benefits over pagers.

  • A two-way conversation allowing clinicians to have a discussion on the patient’s needs.
  • Full audit trial of the clinical conversation and the facility to re-open a conversation later.
  • Ability to attach documents and photographs provides receiving clinician more clinical information meaning more informed responses.
  • Full directory of colleagues that can be found using various search functions.
  • Multiple notifications sent to ensure nothing is missed.
  • Helps the NHS turn paperless as they no longer need to write down the ‘to-do list’
  • Time saved on waiting for a clinician response.
  • Mitigates the need for consultant ‘call-backs’.
  • Integration opportunities to add conversation directly into patient record systems.
  • Money saved on buying expensive pagers.
  • Built in ‘quick-responses’ using generic consultant response i.e. I will be with you in 10 minutes.
  • Ability to add multiple clinicians into one conversation saves time on MDT meetings and allows the users to have an open conversation and shared decision making.
  • More security sending PID.
  • More accessible and better communication.
  • Allows the clinicians to organise and call one another if required.
Ben

This entry has 0 replies

Comments open

Leave a reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>