Jerry Fahrni

Who should drive the selection of pharmacy automation and technology?

Written by

Jerry Fahrni

in

Who should be the driving force behind the selection of new automation and technology in a hospital pharmacy? It’s a simple question really, and in my mind there’s only one clear answer: pharmacy should drive the selection of their own automation and technology. That makes sense, right? Well it certainly does to me.

However, lately I’ve seen a disturbing trend when talking with hospital pharmacies about their selection process. It appears that the IT department – you know, those guys that configure computers and keep your network and hospital servers humming along – has been given a lot of authority in the selection process. Call me crazy, but that seems a little strange to me.

I’ve always thought of IT as a service department, someone to help you accomplish your goal when it involves technology. As an IT pharmacist it was my job to look at pharmacy automation and technology, evaluate it, weigh the pros and cons, and make a decision based on what was best for the goals of the pharmacy. Once that was done I would get IT involved in the process to make sure we had everything we needed from not only the vendor, but our own hospital IT department as well. If there were gaps we would work together to flesh them out.

What happens if the IT department is given the leeway to make a decision for the pharmacy on which automation and/or technology they should use? They might make the “right decision”, but if they did it would be the result of sheer dumb luck. The selection process should be one that looks to find the best fit for the pharmacy, one that fits into the pharmacy’s distribution model, one that lines up with existing technology, one that takes future pharmacy plans into consideration, one that will help drive pharmacists out of the pharmacy toward more clinical activities,  one that acknowledges the strengths and weaknesses of the vendor in terms of functionality, usability and support,  and so on. The decision should not be based on who uses the best security protocol, or who prefers Dell Servers over HP Severs, or whether or not the vendor needs network access for support or not, and so on and so forth.

I truly feel sorry for healthcare systems that ignore their pharmacy personnel when thinking about purchasing new automation and technology for pharmacy operations. In my opinion it’s a recipe for disaster. I certainly wouldn’t want to work in a pharmacy where the tools I used were selected by someone who didn’t even know what I was working on. The next time you have the oil changed in your car, ask the mechanic if he would let the person that installed their computers pick out his tools. I bet you’ll get a similar response to mine, although the language may be a bit more colorful. Better yet, ask a software engineer if he’d let a pharmacist pick out the hardware and software necessary to do his job. It’s a safe bet that he’d look at you like you’d lost your mind.

Comments

7 responses to “Who should drive the selection of pharmacy automation and technology?”

  1. Nutekit

    While I agree with this article regarding IT selecting pharmacy automation it should be noted certain automation decisions should take into consideration the ultimate end user. If we are talking pharmacy robot or carousels which only impact pharmacy, then of course pharmacy should drive the process. If though we are talking ADS machines (Pyxis, AccuDose, Omnicell) or smart pumps, then perhaps more of a multidisciplinary approach including nursing, materials management, and sterile processing may be warranted. I also think the bandwidth required by these technologies should have IT involved in the process as they need to insure the infrastructure is robust enough to handle.

  2. Jerry Fahrni

    If I understand your comment correctly then I agree. When we decided on a smart pump vendor, nursing was heavily involved in the decision. My original comments are aimed squarely at those technologies that have a direct impact on pharmacy operations; you mention a couple, i.e. robotics vs. carousels. The point I’m trying to make is that IT should never, ever be the primary decision maker when choosing a technology for another discipline, whether that be pharmacy, nursing, or physicians. I’ll go one step further and say that IT should never be able to veto a decision made by another discipline in regards to a particular vendor, i.e. Omnicell ADU vs. CareFusion ADU. IT should certainly be involved in the process, and their input considered, but the ultimate decision should rest in the hands of “the ultimate end user”. I see IT as a collaborator, facilitator and enabler. Disparate systems are an unfortunate commonality in our healthcare environment. There will always be problems to overcome in regards to technical issues. In my opinion it’s IT’s tole to help other departments navigate those problems and provide them with the best possible solution. I am not discounting IT’s importance in any healthcare system. I’m simply stating that they have a role to play in the process, and that role is different than the role of the pharmacy, or nursing, or physicians, etc.

    Thanks for taking the time to stop by and comment.

  3. Nutekit

    Great Article and Excellent Points!

  4. Tim Limer

    You bring up some interesting points. Thanks for encouraging the conversation. I may have a slightly different perspective. In the words of Henry Ford (more or less) “When asked who should sing tenor in the choir, the answer is obvious. It is the one who can”.

    I have found that in many cases, the pharmacists are excellent at providing functional requirements. They tend to be weaker at providing system requirements, managing large projects and ensuring support requirements can be met. These are areas where IT organizations seem to be more adept. This is, of course, a generalization but I have found it to be more true than not.

    If I am the CIO at a major hospital I am going to want to minimize cost and maximize reliability by ensuring consistency across all of my computer systems. For example, I have the obligation to steer any organization away from a product that requires an Oracle Database on a Linux server if my staff does not know how to support it (or I need to add the cost to create a support organization to the cost of the proposed system – which has the same net result). I have an obligation to ensure that the software being introduced into the infrastructure maintains the security infrastructure. We all understand the HIPAA implications but that is only a slice of the security iceberg. Think about the importance of backups. Who is going to be responsible for backing up the business critical data collected by the pharmacy system? If an IT group has a sophisticated (expensive) backup system in place for all of their other systems, they should be able to levy compatibility with that system as a requirement on the pharmacy system provider, shouldn’t they? These are not things that are concerns to most pharmacists.

    The struggle we run into and I think this may be the point you are making, is when IT becomes so focused on the underlying technology issues that they lose track of mission of the system; to provide improved capability to the pharmacy. It happens. This situation, however, seems to be a function of the culture within particular IT organizations more than a broad issue with their involvement or leadership across the board.

    We as pharmacy automation providers need to understand all of these things. We need to be on top of the functional domain of pharmacy while, at the same time, have an understanding of IT concerns and the ability to work within the requirements of the larger computing infrastructure. The organization that provides the ultimate decision makers will be a function of the particular customer, but we have to be a resource for them all.

  5. Jerry Fahrni

    I would agree that clinicians tend to be weaker at providing system requirements. Makes sense. I wouldn’t pretend otherwise. I also understand the need to ensure consistency, minimize cost, maximize reliability, abide by HIPAA regulations, and so on. Not sure I’ve ever heard of a pharmacy system using an Oracle Database though. Doesn’t mean it doesn’t exist. Feel free to educate me.

    My point is not to ignore IT, but to ensure that pharmacies are getting the right technology. Work with the pharmacy, not against it. Solve the problem, don’t create one. Enable them to succeed, don’t put barriers in the way. And as you so succinctly put it, make sure that IT never “becomes so focused on the underlying technology issues that they lose track of mission of the system; to provide improved capability to the pharmacy”. This happens too often. I’ve worked in several hospitals during my career, and I’ve seen this happen over and over again at the cost of the pharmacy.

    Thanks for stopping by, and for taking the time to comment.

  6. Ashley Thistle

    My company provides Remote Pharmacy Services for hospitals across the nation. From my experience, IT does play a pivotal role in implementing service into a new hospital and making sure their service is always up and running. I believe pharmacists should absolutely drive this decision, but in my experience I have noticed upper level management sometimes drives the selection/decision process. I have spoken to many pharmacists who would love to implement remote order entry into their hospital, but unfortunately it isn’t up to them. Pharmacists understand the needs of their pharmacy and it should be a decision made between several different people, but the pharmacist should have the most say!

  7. Jerry Fahrni

    Hi Ashley – I would agree that IT plays a pivotal role in your business. Remote order entry requires their expertise and knowledge for *implementation* and *support*, but as you’ve pointed out, the decision to go to remote order entry – and more specifically, what vendor to use – should come from the pharmacy. I think we’re on the same page. Thanks for stopping by. – Jerry

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

More posts