matt14802

I wouldn't be surprised if your system is on an old server somewhere. Korchek Technologies can get the data off that server and provide you that data in an archive. Who was your old blood bank computer system vendor?

I would say that you would have to re validate the entire system. Especially if the operating systems etc have changed on the new server. What blood bank system are you currently using?

Let me get this straight. You are being forced to use the software vendor to validate their own software. How can that not be a conflict of interest? Validation, whether done by the hospital or by an INDEPENDENT third party, is the opportunity to challenge the software and the software vendor's claims about functionality. What is to stop the software vendor (if they are performing the validation) from overlooking known defects in order to assure a timely go live. Software vendor's get paid when systems go live and I could certainly imagine an instance where validation may be compromised for financial gain.

Hello, I work for Korchek Technologies. I would love to make you aware of our data conversion and validation services. We have performed hundreds of data conversions and validations for all the major blood bank and donor systems. I would like to talk about how we might be able to help. Matthew Lund MT(ASCP) matt@korchek.com 813-961-4052

It has been my experience that developing automated scripts to perform validation is not worth the effort. It is labor intensive to develop automated scripts for the purpose of validation and the time spent in the development of the scripts would be better served by having an experienced blood banker stress the system. There is a tendency when developing automated scripts to myopically test known pathways through a system while missing subtle idiosyncrasies that are captured through manual testing. The argument can be made that scripts are reusable; therefore, the cost of the initial development may be saved in subsequent usage of the scripts. This may be true; however, in order to develop truly robust and reusable scripts a tremendous amount of time must expended in order to develop a "testing harness". A "testing harness" is the backbone of the automated test script environment and includes defined functions, parameters, and variables that will be used when running the automated scripts. If a "testing harness" is not properly set up when developing the automated scripts, then the "reusability" of the automated scripts will be greatly diminished. In other words if you go to run your scripts a year from when you initially developed them without a good "testing harness", you will have to dive into them again and tweak them extensively to get them to run.

You need to alot time for validating your ISBT 128 implementation. That should certainly be a included in project planning.