On the weekend before the July 4th holiday, one of our air conditioners (the one for the master suite) went out. Because we were expecting guests, and 90+
o F weather, this occasioned an emergency (and therefore expensive) service call to get things back into working condition. It turned out that our fan motor was shutting down intermittently, and could go out completely at any time, so I elected to have a "rescue" motor installed so that we would have AC over the long weekend. This, of course, required some jury-rigging of the motor circuitry during the installation but, long story short, the technician left having pronounced the system to be in working order. To our dismay, we discovered several hours later that there had been no temperature reduction in the master suite, and called the technician back to investigate. It turned out he had wired the motor backward (apparently an easy mistake to make) with the result that, instead of pulling air across the cooling coils and into the house, it was pushing air back into the cooling chamber. Once properly wired, it worked flawlessly.
You see, the motor was not built in error; it was misconfigured. When the configuration was properly performed, the motor worked just fine.Software has the same problem. Because of the wide varieties in medication management practice in our hospitals, software on which we rely has to be configured to meet the needs of individual hospitals, and errors can occur in such configurations.
One such case was recently reported at the ASHP Summer Meeting Medication Safety Officers track, and,
as reported through ISMP MSOS News, the problem turned out to be misconfiguration of the software. In this case, the misconfiguration resulted in inappropriate interpretation of an order frequency, which could have serious consequences. Fortunately, the hospital was able to fix the problem as soon as they discovered it.
Having said that, it is worth noting that configuration of our software systems is not for everyone to do, and testing is necessary to ensure that any given configuration doesn't produce unexpected negative downstream consequences. This has the following general implications:
- Configuration should be performed only by persons trained and experienced in the job - software is a power tool, and therefore best used in the hands of people who know how to use it properly. There is nothing about having R.Ph. after one's name that magically makes them suitable to perform configurations untrained.
- Configuration should be first performed on a test system, where the downstream effects can be evaluated - while this isn't necessarily the fastest way to get something into production, it is the safest. What this implies is that the test system is sufficiently similar to the production system that it is likely to uncover any negative downstream effects. It also implies that, where changes affect interfaces with other systems, there needs to be a way of generating test transactions from the other systems to test the configuration changes.
- Transfer of the configuration from test to production should be checked by a second set of eyes - as we all learned from the early unit-dose days, any time there is transcription there is the possibility of error.
It is also important to realize that sometimes configurations are predicated on a particular version of software and may represent workarounds to the way the software works. In those cases, subsequent versions of the software may correct the reason for the workaround, and result in configurations that no longer work properly, or have unexpected consequences. That is why implementation of a new release of software should also be first evaluated in a test environment against a well-defined test plan with documented expected results. Again, more work than many want to do, but necessary for the protection of our patients.
What are your thoughts?
Dennis A. Tribble, Pharm.D., FASHP
Ormond Beach, FL
DATdoc@aol.com
The opinions expressed herein are my own, and not necessarily those of ASHP or my employer