Avoiding the #1 Interface Validation Mistake

When provider organizations are on a tight deadline to implement or upgrade an EHR, EMR, HIS or other clinical system, setting up a test or staging system can seem like just another procedural hurdle. So it couldn’t hurt to just do the final testing in the live, production system, right?


Why It’s Tempting

It might seem quicker to simply tag test data as “Test Patient1” in “Bed #1-T” and get it into the production EMR or HIS. You skip duplicate server (or virtualization) costs, maintenance overhead, connectivity issues, and the whole headache involved with mirroring data, settings, and configurations between the test and production installations.

But this is a tradeoff you don’t want to make.

Why It’s Dangerous

1. You can’t be sure that you’ve canceled all your test transactions. After all, the purpose of interface validation is to check that the interface is working as expected. If it isn’t, you’ll end up with faulty transactions in your production system.

2. Whenever you’re in the production system, you run the risk of impacting ePHI or protected health information in HIPAA terms.

3. Audits. CMS audits include HL7 billing data. You don’t want phantom test data turning up in a CMS audit.

We all know testing in a live system is a bad idea, but it sounds like people are still going down this road. Any further thoughts as to why?