Skip to content Skip to navigation

Testing?!! We don't need no Stinking TESTING!

Printer-friendly version

The title of this blog makes a reference to the movie "Blazing Saddles." It's a Wild West comedy. No rules, no Sheriff Badges, just go and plunder. I don't like to plunder into a code migration. Nobody really believes that their programming skills are so bullet proof that they can just plug it into production and it will work right out of the gate. But I keep hearing of analysts and system managers that do just that. They don't have a test environment or they allow vendors to migrate a change to production without fully testing it. They have a naive belief that the vendor has already smoke tested the change so they should know what they are doing.

The reality is that every system is different. You have funky interfaces and extracts that kick off and do their own thing. Vendors have no way of knowing what the client created on their own system. They may have a process that generates a report at One AM, and then feeds the information somewhere else. What is the worst thing that can happen? Maybe a patient gets billed the wrong amount? How about an incorrect code feeds an interface that populates an EHR? Now you have a serious issue.

I have very little tolerance for someone that does not follow best practices when it comes to testing. If you are doing an upgrade or new implementation, then having a full test plan with QA and sign off for each test phase. This is critical to the success, and helps make your go-live become a "non-event." I go one step further and ask for screen shots during testing to:

1) Show results of the test at the time it was tested.

2) Keep the analysts honest that they really did test that feature/function.

I hope your organization has a formal testing and change management structure. If not, then you are gambling in the Wild West.

Nobody really believes that their programming skills are so bullet proof that they can just plug it into production and it will work right out of the gate. But I keep hearing of analysts and system managers that do just that. They don't have a test environment or they allow vendors to migrate a change to production without fully testing it. They have a naive belief that the vendor has already smoke tested the change so they should know what they are doing. The reality is that every system is different.
When doing an upgrade or new implementation, having a full test plan with QA is necessary

Comments

Thanks Bob. There is not enough emphasis given to Physician certifications for EHR use. There was a time that just getting a Doc to log-in to the system was a measure of success. We are now way beyond that in terms of adoption. Do you know of any standards out there for basic physician competencies for certification?
-On another note. Blazing saddles spoofed "The Treasure of the Sierra Madre" among other movies.
-Is that a Ten Gallon Hat?

There are no standards that I know. Many institutions that are having great successes with adoption use a web-based learning system, some classroom, and at the elbow extended duration go-live support. Or, as I like to say, it isn't 2005 anymore. If you can't figure it out in 2011 you shouldn't be in the business. And finally, change management is still paramount for the vocal minority providers resisting transformation. Paper is for cavemen.

Pete, your post also relates to IT infrastructure - especially wired and wireless networks and virtualized server environments. Just because a new firmware release for your wireless LAN AP controllers comes from the vendor, doesn't mean it will work flawlessly in your environment (as many have learned the hard way).

As medical device systems are increasingly supported by enterprise IT infrastructure, that infrastructure becomes part of the regulated medical device. After installation, it is the customer's responsibility to ensure that infrastructure remains within the medical device manufacturer's specifications - to ensure continued safe and effective operation.

A new standard, IEC 80001, was published last September to ensure the ongoing safety of networked medical devices. I suspect that some entity or accreditation body will mandate the adoption of this standard.

IEC 80001 is a formal risk management process that drives the formal testing and change management that you mention in your post.

It seems to me that CIOs will spend an increased amount of time dealing with risk management, testing, change control and related governance issues in 2011.

Amen Bob!

Our project managment department will make sure of that every step of the way. Additionally, as is becoming increasingly clear in adoption, is testing and certifying the physicians to use the EHR and HIT at their institutions. And training and recertifying again for new systems and updates.

And more importantly, I love Blazing Saddles, but, as my father omnisciently corrected me, the quote came from http://www.imdb.com/title/tt0040897/quotes