The journey to a paperless hospital - How to identify and address the challenges shaping technology adoption in a clinical environment

Once you spend uncountable hours prototyping, designing, developing, and polishing your brand-new app, you are usually quite confident that everyone will really want to have it and use it. After all, that's why you developed it in the first place, right? It turns out that achieving good adoption of IT solutions, especially in healthcare, is a bit trickier and challenging. Once you deploy your solution in a real healthcare environment, users are typically not very fond of letting go of their papers or changing existing processes. This is something my team and I learned while working with University Children's Hospital in Ljubljana (UCHL) on their journey to become paperless.

Although UCHL had a clear vision on becoming a paperless hospital and supporting any existing processes with various IT solutions and apps, it quickly became clear that, in order to successfully rollout all of the planned IT modules and achieve this transformation, just focusing on the development of good apps would not be enough.

The first test for us and the hospital was the rollout of the laboratory module. And, although we spent a whole year shadowing users, doing interviews, designing, prototyping, and ultimately developing the solution, it turned out to be quite a challenge to actually implement it in real clinical environment, and throughout the entire hospital.

There were several reasons for this. The solution we provided actually changed existing processes connected with ordering lab examinations, collecting samples, transporting samples, and receiving lab results. And, the hospital also decided that each step of the process needed to be done by someone in the appropriate position. This meant that lab orders had to be entered into the system by physicians, but physicians are usually quite busy, especially during night shifts. So, the first idea of rolling out the lab module in the entire hospital at once was quickly changed. We decided to find one department, however, that really wanted to change, and understood all the benefits of having new and modern IT support.

Then, we identified some power users from that ward, and ran some intensive training and knowledge transfer sessions with them. We realised that by relying on the IT system for such a critical process as labs, it would be of utmost importance that any questions or concerns would be resolved immediately by colleagues from the hospital, and not by having to call some IT hotline, and waiting indefinitely for the answer.

Once we did that, we got one step closer to rolling out the system in the first ward. We did a pilot run in clinical environment and found out that even though the system supported the creation of order sets which really simplified and sped up the ordering process, practically none of the users actually created these order sets; instead they complained about how inconvenient it was to order labs using the system. So, we worked with the power users who pre-defined the most common order sets for that particular ward, and we created what we refer to as "single-click orders", which enabled physicians to quickly order labs with single click.

This had a really positive effect. All of a sudden, even junior doctors knew what to order without having to constantly check with senior doctors, and they actually started ordering less, because they had good order sets for the typical conditions of their particular ward. And, the senior doctors actually found it easier to use the "one-click" orders and get results in an electronic format, rather than write the orders on piece of paper and then later search the ward for the results.

So, things began to run smoothly, at least during the day. But, we missed one important scenario - lab orders during night shifts. Medical teams are significantly reduced in number during the night shift, and having to create several lab orders for patients staying over-night turned out to be overwhelming at times. We decided to spend some nights with the night shift personnel to figure out how to best tackle their challenges. Luckily, we found out that the existing functionalities were more or less OK, and that we were just missing the ability for doctors to order labs at any time of the day. Most of the lab orders ordered during the night turned out to be planned orders made by the day-shift team. But, instead of just entering these orders during the day, and simply marking a later time for the execution of the order, the day-shift teams just passed the instructions to night shift teams orally.

Next, we actually fell victim to our own success;)
Now that all the doctors had let go of their paper orders, and the nurses had quickly taken on their part of the process by relying on the task list for taking samples and barcoding lab containers, medical teams ran out of available computers. There was a constant need to access the system - to create new orders, check for results, monitor the task list, take samples, print barcodes, scan containers that were transported to the lab, etc. And this meant that users started to overlap and fight for access to computers!
The only way to actually continue with the normal use of the system was for the hospital to buy and install more computers. One of the smartest moves they made was to actually not just buy additional desktop work stations, but to also invest in so-called COWs (computer on wheels). These turned out to be incredibly useful, not just for labs, but also later on, when we rolled out medication management.

After this point, it was really easy to roll out the module throughout the hospital. At the same time, we learned some very important lessons:

• Develop a minimal valuable product (MVP) as soon as you can and deploy it to a live production environment, because no matter how hard you try, until you test the solution in a real environment, you will not know if you have missed something.
• Find the right power users and the ward that shows the most ambition to change, and it will later serve as a role model for the other wards to follow suit, and work with them closely.
• Do not underestimate the importance of having good IT infrastructure and plenty of workstations of different kinds.
• Develop your own rollout methodology in a way that helps you identify the specifics of each care provider, thus helping you properly guide the care provider throughout the transformation; select/deploy the right devices and IT infrastructure, and at the same time configure your solution accordingly.
• Prepare rollout strategy, workshop materials, and do not forget about helping the care provider set up some sort of continuous learning processes. Care providers have high staff turnover, which means that constant learning is a must.
• After going live, spend as much time as possible with users, and also use the metrics built into the app to track how the application is being used. Use the acquired information and knowledge to continuously improve the app, and to keep your users informed on your future plans and ambitions, so that they don't feel like they are wasting their time when they give you feedback.

Based on what we learned during the development and rollout of this module, we continued to perfect the whole process - from the ideas initial inception and prototyping to roll out. But, more on the rollout process and how it helped the hospital with their overall transformation to paperless, and eventually achieving HIMSS EMRAM Stage 6 certification, in my next blog.