Instrument testing can be a touchy subject. All labs are concerned about downtime. The purpose of this document is to provide the beginning of a discussion between the people doing the testing, and the lab techs responsible for getting results out the door.
Testing for a new system eventually means testing every test that is run on an instrument. This is not a quick process. Taking shortcuts can mean extended downtimes at go-live as unforeseen/untested workflows crash into the reality of the system. Thorough testing is painful, but beneficial.
Here are a few ways you can minimize the pain for testing the new system.
- Work with the lab to determine the best times to test.
- If there are duplicate instruments of the same exact model, test one at a time.
- You may run a subset of tests on one instrument in a pair, and other tests on the other instrument, but if they are emergency backups of each other, you must eventually run everything you could want to run on both.
- Barcode numbers must NEVER overlap.
- If the system is advanced enough, it may be able to interface to two different systems at the same time.
- On track systems, some container status/storage messages cannot be blocked so some messages meant for one system may accidentally make it to the other system.
- Always check with the instrument vendor to make sure this is possible/safe.
- An instrument can be connected for a short while to allow orders (or instrument queries) to cross, then switched back to production while tests run. Once the tests are done, switch again and retransmit the results.
- If an instrument is being tested with the new system, it may be possible to still load a sample from the old system and manually program the instrument with the tests to be run. When the interface is swapped back, retransmit the results.
- If a STAT comes in and swapping the interface back is not feasible, manually running the test and manually entering the results is less than ideal but possible.
- Have a list of tests you plan to test beforehand. You can order them beforehand as well. If you have a barcode printer, even better. DI will hold orders for at least 2 days beforehand, although it is best not to order on Friday to run Monday.
- Make sure the lab has a sample or can make a sample that matches what you want to run ahead of time.
- If you are testing GLUCOSE with a beyond linearity flag, make sure they can do so ahead of time (Examples: Run a QC sample with the Beaker barcode? Doctor up a sample?).
- Some instruments can “fake” results (but this is rare).
- Best to have the lab tech work with the Vendor to figure out if this is possible, how to do it, and ensure the instrument id will match the testing done on the real instrument.