How to Fix The Four Major Obstacles to Staff Safety Rollouts
Implementation is the first test of whether a technology can bring real benefits to a hospital. Yet far too many companies (and hospitals) fail this preliminary challenge due to organizational or process obstacles, rather than issues with the technology itself. This deprives health systems of an excellent solution, and one that could have the potential to transform the experience for patients and providers alike.
Throughout my long career in healthcare tech, I’ve encountered many of these hurdles; with the benefit of time, experience, and the help of fantastic colleagues and collaborators, I’ve been able to identify and overcome them.
This article will take the lens of implementing staff safety solutions across major health systems, because that’s a priority initiative for many organizations right now, and one that yields tangible benefits for clinicians. However, each of the following obstacles are also relevant to other hospital operational use cases, including supply chain management, patient flow, and hand hygiene, to name a few.
Key Takeaways
- Staff safety implementations rarely succeed or fail based on the technology itself; instead, the key lies in organizational and process obstacles, such as ambiguous decision-making processes or unclear communication.
- Every staff safety solution must feed a defined workflow, with a person accountable for said workflow; otherwise, solutions will not add value, and instead, become another burden for teams to work around.
- People must be bought in, or else they won’t use the technology, and implementation will fail. This means multiple communications (emails, meetings, or bulletins) in advance, spaced out over a period of time, for maximum memory retention.
Obstacle 1: An ambiguous decision-making framework
I’ve sat in many rooms and meetings where much would be discussed and heads would nod, but nothing would be decided. Often, this is due to structure or culture: some health systems tend to decide things by committee, while others try to take a bottom-up approach, empowering their frontline clinicians and staff to have a say in the process. While this is admirable and borne of good intentions, it will delay project timelines and introduce ambiguity into the rollout.
The solution to this is simple: have a decision-maker in the room at each meeting, so that they can move the process along. Of course, this is not always easy or even straightforward; authority may be concentrated in a handful of leaders, who are not able to attend every meeting that they’ll need to.
In that case, leadership must devolve decision making powers; first, they should determine which meetings will have impacts on the overall implementation timetable, and then they must deputize one person in each meeting who can make the hard decisions. In this manner, hospital leaders can not only ensure that their implementation initiatives keep moving, but also maintain the role of mid- and frontline staff in the process.
How to remove ambiguity and move decisions along
Let’s take a large-scale, system-wide staff safety implementation as an example. Assume that a hospital’s IT team is meeting with nurses who are piloting a new safety badge, in order to get their feedback on comfort, form factor, and overall usability. If the nurses request a redesign of certain features, perhaps asking that it be made lighter and more intuitive, then someone at the meeting has to be able to approve this redesign request and submit it to the vendor.
If only a high-ranking position, such as the VP of IT, can sign off on this proposal, then this person needs to attend the meeting. If they cannot, then they need to delegate the responsibility to a trusted subordinate, and vest them with the power to decide. Otherwise, the request will be in limbo, and the entire implementation initiative will be delayed.
Obstacle 2: Neglecting the process portion
I like to think of implementation as a three-legged stool, consisting of people, process, and technology. All three legs are load-bearing components: for instance, trying to install a technology without building a solid process will not bring results.
The fix is to subordinate technology to processes. Every solution must feed a defined workflow, and every workflow must be overseen by a person who will determine the efficacy; for maximum effectiveness, follow-through must be continuous. In essence, the solution will change the workflow permanently, and for the better.
Here’s an example. Kontakt.io’s Staff Safety solution enables nurses to trigger duress alerts with room-level accuracy, but simply adding duress buttons and sensors cannot make nurses safer. Instead, implementation requires collaboration with security teams to define clear response protocols, assign responders, and regularly review incident data and reports to identify patterns and improve security postures. This is an ongoing effort; staffing levels, unit layouts, and risk factors shift over time, so response workflows must be continuously optimized in order to remain effective.
Building new workflows means deprecating old ones
The process of building a new process also facilitates the deprecation of legacy technologies and environments, traditionally one of the hardest parts of any implementation. Instead of ignoring or working around these leftover solutions, my team usually helps our customers document their current workflows and analyze their existing infrastructure, so that we can determine what to fix or remove.
From a security perspective, this would include transitioning security teams away from old devices and workflows. For instance, if security teams use radios to call in alerts and route responders, they may be concerned that mobile safety badges may serve as an additional channel, massively increasing calls for help and overwhelming responders.
The solution was to help them rethink their response procedures, and to deemphasize the use of previous tools, such as radios and static call buttons. While these devices were still valuable (in particular, radios were helpful for keeping security teams updated on fast-changing situations), alerts from mobile duress buttons were prioritized.
Ultimately, the number of alerts remained the same, simply because the smart badges started to account for the bulk of the duress calls. Best of all, there was no gap in security coverage, despite this technological and organizational transition.
Obstacle 3: Forgetting about the people factor
In addition, rolling out a solution without onboarding your people simply cannot succeed, because at the end of the day, people are the end users. As a result, they must be bought in, or else this technology won’t fix any of the problems it was designed to.
Getting buy-in boils down to strong internal communication. Health system leadership must explain why this technology was purchased in the first place, the goals of this implementation, and how both the hospital and the individual teams involved will benefit.
Without disseminating this information downstream, people will get defensive. Just imagine your reaction if someone shows up in your workplace one day, with a radically new technology that promises to completely overhaul your existing workflows. If you hadn’t been informed beforehand, how would you react?
Communicate clearly and frequently
In terms of communication, top-down clarity and repetition are key. As part of one staff safety rollout, I met the IT director of a hospital that belonged to a major national health system. After I introduced myself, I started to outline the technology, when he stopped me; he explained that he had already been in seven briefings, and that he and his team were ready to do their part.
Interestingly, this health system’s procedures were based on best practices around human memory. Researchers found that the best way to encourage memory and information retention was to space out repetitions over a long period of time.
Obstacle 4: Data usage and transparency
This concern deserves special mention due to its frequency; it often originates from nurses who are involved in staff safety deployments. They worry that their productivity will be tracked, their every minute monitored, and ultimately, that they will be fired or retained based on these metrics. Based on these fears, nurses might even decide not to wear their safety badges, defeating the purpose of having a mobile duress button that provides real-time, room-level location data.
Threading the needle on this is tricky, but can be done. Ultimately, it all comes back to safety: nurses aren’t tracked during their daily routines. Instead, their locations are only important for routing security responses, or perhaps for secondary use cases such as receiving hand hygiene alerts when they pass the threshold of a patient room.
Data is for system-wide optimization, not individual punishment
To address these concerns, leaders must ensure that data cannot be used punitively, especially for performance reviews related to firing or retention. After all, the key focus is to keep nurses safe from workplace violence or infection, not to measure how they spend their shift. As one nursing leader told me, the message has to be set from the very beginning: the word ‘tracking’ cannot enter the conversation, or this program will not work.
Why rollouts succeed or fail
None of these obstacles are really about technology at all; instead, they concern the less obvious, less tangible aspects of an organization, ranging from decision making responsibilities to nurse concerns.
To successfully implement technologies, hospitals must treat it as both an organizational and technical process. Get the process and people legs of the stool right, and the technology can make a real, tangible difference for your employees, patients, and health system.
