At the beginning of the AI Strategy Lab project, our approach was relatively simple and straightforward. We set out to employ AI to detect nurse burnout at hospitals. Nurses have irregular and demanding shift patterns, which can be changed at short notice. Those who create the rosters typically do not take into account the accumulated pressure on individuals over a longer period of time. Thus, detecting burnout seemed a fitting application of AI.
After finishing the project, we ended up developing a decision-support system that would aid those creating the rosters of nurses in the large Dutch university hospital, while being integrated with the scheduling software that the hospital is already using. Reflecting back, I realized that all the steps that we took during the project development led me to understand that the key point of the entire process was to comprehend the work well enough to understand where AI can assist.
From builder to aligner
My tasks had two stages. The first stage was designing the prototype. It was impossible for us to have access to the software used in the hospitals; therefore, we recreated a baseline scheduler with the same functionalities and applied our algorithm in parallel. This helped us have a benchmark to measure rather than just arguing about it.
After developing the prototype to a certain level, at this point in time my task began to evolve into alignment. We each worked on our own piece of the project, and when we saw the results, they were all written about the same solution, but after looking closer at the details, it turned out that there were differences in the product description. We were solving the same problem with the same ideology by using different implementations. Besides, we did not have any common understanding of what exactly our AI piece was supposed to do. Because the prototype was physically representative of all ideas, it showed all the gaps clearly. In our group, we summarized ideas into two alternative approaches to take and finally decided on one of them. Both sides needed to make adjustments to align with each other. The prototype needed to fit the decided solution, and the deck needed to be revised to remove inconsistencies.
Three decisions that shaped the project
From prediction to decision support. This was highlighted by our instructor in the very beginning of our project. In fact, there is no ground truth in hospital records regarding burnout; therefore, a burnout model would not be able to make any predictions that can be verified. We maintained the predictive model for some time but were unable to figure out what it would predict, and later we decided to remove it. The concept of burnout remained with small and specific usage, but the tool would operate based on the available roster data such as overtime, consecutive shifts, rest period, and equal distribution of difficult shifts. The scheduler has full control and the final say over ranked options by the tool.
From competitor to complement. In the beginning, the existing vendor of the scheduling tool was our main direct competitor, and outperforming a well-established competitor sounded tough without any clear reward. However, the optimization of their roster correction is more focused on feasibility and stability than distributing the strain. This means that we could position our solution as a layer over it, making our business model far easier to justify.
From optimisation to a monthly review. Based on the indications from the vendor’s own news that people use a small part of the available features, adding another optimization feature would make no difference. We began to move in the direction of a monthly assessment where the managers got to know how their past rostering decisions had impacted strain and how they could modify them.
Simulation outcome
We were surprised by the results of the simulation. To deal with changes that occur on short notice, our solution rescheduled shifts for more people compared to the baseline solution, hence appearing to be more disruptive at first glance. When put side by side with the cost-generating outcome, the number of call-ins made the scenario look evened out, with more minor rescheduling but fewer call-ins altogether.
It was the issue of whether to have more call-ins and minor rescheduling or to have major rescheduling and fewer call-ins that formed the core of the discussion on Demo Day.
Building with an AI coding tool
The prototype was designed with the help of Claude Code. While it was good for quick construction, it would continuously add additional features and buttons, and we had to strip it down to the bare essentials to demonstrate the idea behind it. The project prototype provided a small fact that more and more complex technology does not immediately add additional value.
Collaboration as translation
As the author of the prototype, a lot of my collaboration involved translation. I translated technical decisions into terms that my teammates could use to present in the deck, and requirements like equity between the nurses into constraints for the prototype to enforce. This process revealed to me that the quality of communication between the business and technical side of a project has a significant role in turning any strategy into a technical solution as intended.
My takeaway
As such, I entered the course with some experience of AI from both the technological and the business perspective, knowing that the main thing was the ability to translate business needs into technology. This assignment allowed me to understand at what point this translation has to be done.
If I had another chance to do this project, I would have first invested time into the domain, understanding how rosters are prepared, how they are modified, and under what circumstances. Without this, it becomes difficult to understand how AI can have an actual impact rather than just a perceived one. We were able to make the most informed decisions by understanding the task better instead of adding more AI into service to solve the problem.
