Unit Dose Roll-Out Part III

Another key element to our success: Bring candy to nurses. Not only do you make nurses happy because they get candy, but you're also showing that you understand their culture and are at least a little bit willing to move yourself closer to it.

Just make sure you don't buy only "granny candy". As project managers and senior nurse educators, we tend to be closer to the end of our career than to the beginning. Don't forget that a significant number of nurses nowadays carry iPhones and have a huge number of friends on Facebook.

Unit Dose Roll-Out Part II

The machines we're using to package the medications are the FastPak EXP from Automed (AmerisourceBergen). They have an awesome pre-installation support team. The front-end sales people were so-so -- your mileage will vary, of course, depending on the region. The sales team was Western Canada; the pre-installation support is for all of Canada.

The machines themselves have a number of quirks. Nothing that can't be worked around, but don't believe that you won't have to make any decisions yourself. Also, since we're running three machines, we've written our own little database scripts to keep the data in the machines synchronized. There's no way you should try to do it by hand, although I suspect that's what most people do because the vendor doesn't have anything to help.

The main competition to Automed are the Pacmed machines from McKesson. There are some differences between the two that will require a change to your extract or interface from whatever Pharmacy Information System you're using. Nothing big, but in software even a small thing can cost a lot of money. It's worth looking into the interface in detail if you're looking at switching from Pacmed or running both in parallel.

Because we're packaging all regularly scheduled oral solids (with some exceptions) we've found that our Pharmacy Information System wasn't really set up to handle some of the scenarios. Our distribution model seems to be different from the typical hospital pharmacy, but I don't have enough experience with hospital pharmacies to say if these challenges would generalize to other installations.

Successful Unit Dose Roll-Out Part I

We've begun to roll out a just-in-time unit dose medication distribution system at GF Strong, UBC and Vancouver General Hospitals. Just-in-time unit dose medication distribution increases patient safety by making it easier for nurses to do what they always do: provide quality care, including medications.

Nurses are loving the new approach. "You just saved me ten minutes", "I really like it", and a big two thumbs up are some of the comments I've heard as I provide go-live support on a pair of medical nursing units.

I'd say there are two major reasons why it's going so well: First, the system is intrinsically good for nurses. Nurses are over-worked, under-paid, and totally committed to their patients. Anything that improves patient safety while making their job easier is going to be a hit.

The second reason is the excellent communication and training by our team of nurse educators. We have to train about 3,000 nurses. We started four weeks before the first units went live, and will continue up to the last go-live week in December. With four nurse educators giving a half-hour session, we're reaching 100 percent of the nurses on most nursing units, and well over 80 percent on the rest.

On any future front-line health care projects I may do, I'm going to insist on the budget to adequately listen to and train the front-line health care providers. This has been so key.

I've been the project manager on this project for just over a year. It's been a complicated, multi-faceted project with a lot of challenges. It's totally satisfying to see a successful start to the roll-out. We're phasing in nursing units for the next three months, so I'm sure there'll be some challenges along the way, but it's clear that we've got a winner.

Stay tuned for future posts about why this project is so successful, and what the challenges have been.

Challenge # 42 of Healthcare IT

Many who've worked in healthcare IT believe it's more difficult than IT in other contexts. Everyone has their reasons. I'd like to add mine here.

Mistakes in healthcare are really bad. They literally lead to people's health being compromised, or in the worst case, people dying. Projects are about doing something new. Doing something new is about making mistakes and learning from them, or at least trying out new ideas, some of which will turn out to be wrong.

Sometimes these two things are in direct contradiction. More often it leads to all sorts of misunderstandings between the healthcare team and the external project team that are hard for either side to recognize, let alone overcome.

For example, it's pretty standard practice on a project to do a design and put it in front of a group of people for review. While it can be hard to listen to others criticize your design after all the work you've done on it, we all get used to it.

Now imagine you're a nurse, doctor or pharmacist. All your life you've been terrified of making a mistake because someone might die because of it. Everyone around you is also terrified of making a mistake, and in fact the best way for them to feel good is to catch you making a mistake. It's pretty easy to fall into a pattern of avoiding mistakes at all costs, avoiding blame for mistakes when they do occur, and catching others' mistakes in order to appear to be a better nurse, doctor or pharmacist than the others.

You're not likely even to be able to understand a consultant who suggest you put up a proposed design and let others criticize it. And if you understand, you're not likely to want to go along with it. Every fibre in your being is about avoiding mistakes. And everyone you work with considers making a mistake to be the worst thing anyone can do. No consultant is going to convince you that you should publicly set yourself up to "make a mistake".

If you're running a project in a healthcare environment, you need to understand the depth of fear of making mistakes. To move the project forward in spite of this fear, try some of these ideas:

• Let the people you're working with tell you what makes them comfortable. They won't necessarily tell you just because you ask them. You have to listen to how they want to do the project
• Bring groups together and facilitate group decision making, rather than expecting one person to tell you an answer. It will take longer than if you could find one person to make the decision, but the reality is, you aren't going to find that one person
• Use project staff if you can. Just let them know they're going to take a beating. The passion with which many people expose other people's mistakes in healthcare is unnerving
  

By the way, I'm really glad that healthcare providers have a phobia about mistakes. If I'm ever in the hospital I want to know that everyone there is doing everything they can to avoid mistakes. It's only difficult when you're trying to run a project.

Change Management and Project Management

I heard a good talk on Friday that identified for me a real tension between change management and project management. That wasn't the point of the talk. The presenters were just presenting change management in the context of a major health care IT initiative that's underway in BC. However, their words of guidance to project managers triggered some thoughts.

To avoid confusion: We're talking here about "change management" in the sense of how to help people change the way they work, typically with the introduction of new technology. We're not talking about change management as in the management of changes to IT infrastructure itself.

The presentation showed the "Six Human Needs" that you had to look at when undertaking major workplace changes. First on the list was the need to be heard and have control. To give people control means they might change what the project has to do. The tension is that our standard project management approach in IT hates scope change. We have mechanisms to handle scope change, but we certainly don't encourage it.

I think there are a lot of situations where this sort of creative tension actually leads to a good result: The change management people will bring good ideas back to the project team. The project manager will push back due to budget constraints, and the customer will get the "best" result.

This puts a lot of pressure on the scope change decision-making process. You have to get those trade-offs between scope and budget mostly right. In my experience, it's been really hard to get the right people to take the time to truly work through an issue and come to a reasoned conclusion on that type of issue.

I think this is an area where the IT industry's "best practices" need to be improved. As a project manager, you're pretty much between a rock and a hard place when you get the change management input. If more projects would formally recognize the exploratory stage that most require before confirming budgets and scope, we'd be a lot better. Not being a PMP, I don't know if the Project Management Institute (PMI) has done a lot of work on the quality of a change management process, as opposed to the existence of one. I'd be interested in hearing what they've done.

By the way, the talk was part of BC Health Information Management Professionals Society (BCHIMPS) spring education session on Friday. The BCHIMPS spring and fall education sessions are excellent meetings for anyone involved in health care IT in BC.