A vital component to your GE Centricity Hosting or Allscripts hosting environment is a test system. Any changes you make such as form and report updates, service packs and upgrades, ancillary applications and interfaces, should always be applied to your test system and put through the proper testing scenarios before applying them to your production system. This will allow you to detect and prevent any issues that may occur as a result. The data contained in these systems is the lifeblood of your practice. You want to make sure any change you make do not corrupt the data or system in any way, causing you to potentially lose hundreds, if not thousands of dollars in time spent in a lengthy recovery process.
The test environment you build depends on what type of production system you have, whether it’s physical or virtual servers. For every physical production server you have, there should be an identical physical test server.
If your system is setup in a virtual environment such as VMware, you should create a duplicate virtual test server for every production server in your system. These servers would include everything from EMR to Secure Messaging and ePrescribing servers. The connections between your test servers should also match how your production servers connect to each other. It is also important to keep the data on your test servers as up to date as possible.
One way to accomplish this would be to backup your production databases and restore them to your test servers on a weekly basis. This not only keeps the test data current for any testing you may conduct, but also allows you to test your backup and recovery procedures at the same time.If your system is setup in a virtual environment such as VMware, you should create a duplicate
If building a complete test environment is not possible for whatever reason, you should at least create a test database for each of your production databases. While this scenario does not allow you to perform true end to end testing, it does allow you to test any updates against the data to see if any potential issues arise. Whether any testing is performed, it is best practice to always backup your production data prior to applying any change.
Testing new and updated content, such as forms and reports, will help you determine if there are any bugs in the code. These errors could corrupt your production data, and put your patients care at risk. Adding ancillary applications such as e-prescribing and secure messaging will go a long way to improve your patient care, but they should be fully tested to make sure they properly integrate with your current system without any negative effects.
Before you consider interfacing with any external systems like hospital labs, radiology, imaging systems, and the like, they should be tested thoroughly. Connecting them to a test system would determine if the incoming data is viable and suits your needs. Invalid data from an external interface can wreak havoc on your system if not configured properly.
Perhaps the greatest need for a test system is to test service packs and upgrades prior to applying them to your production system. Installing any software update always has the potential to break something. Custom forms and reports may not work properly. Ancillary application functions like e-prescribing and secure messaging may not be compatible. External interfaces may no longer import data properly. There could be small bugs that may hinder workflow, or disastrous errors that corrupt your data and cripple your entire system, putting you in the unenviable position of performing a lengthy and costly recovery.
No matter how simple or complex your testing environment may be, it is vital to have one available, and used whenever proper testing is necessary. Your practice, and your patients care, may well depend on it.