Jump to content

Computer Validation


Recommended Posts

We are wondering how to interpret the standard that says a computer system must be validated on site. Does that mean that a third party validation is not good enough or does that have to do with a hospital system having multiple hospital sites? We are a bit confused.

Thanks

Link to comment
Share on other sites

The standard means that the software cannot be furnished "pre-validated" on a disc. It must be loaded on the actual hardware on which it will be used and tested.

A third-party can test it for you and give you the documentation, but the plan must be acceptable to you, and the final packet must be reviewed and approved. Some of the "fun" of validating a computer system is learning the in's and out's of the software and its configuration during the validation process.

I always have a problem with sites that had no plan, no documentation that they executed it, and no final review and acceptance documented. Merely doing what the vendor gives you may not be sufficient - someone must review it and augment it with additional testing, if the original plan is not sufficient for your liking. And if you think it is sufficient, it still must be reviewed and approved in writing.

If you are adding to an exisiting and validated enterprise system, my thinking is that is is not sufficient to add a terminal and a printer to the system and call your job done. Each workstation must be configured and tested to confirm that essential processes will work the way all the other wrokstations do. That includes when something breaks and must be replaced.

But that's what it takes for me to sleep at night ...

Link to comment
Share on other sites

We are wondering how to interpret the standard that says a computer system must be validated on site. Does that mean that a third party validation is not good enough or does that have to do with a hospital system having multiple hospital sites? We are a bit confused.

Thanks

Although BCSH Guidelines (obviously) only apply to the UK, it could be worth your while going onto their website and looking at the guideline entitled, "The specification and use of information technology systems in blood transfusion practice.". I believe this document contains exactly the kind of information you need.

If you have access to the original journal, it is in Transfusion Medicine 2007; 17: 1-21.

If not, you can put "BCSH Guidelines" into your search engine, go to guidelines, then to blood transfusion guidelines, and you will find it there.

As I said above, be aware that these guidelines only apply to the UK, but they do give a pretty good overview and may be of help to you.

:):)

Link to comment
Share on other sites

Here's the FDA's definition, found in a guidance document for Computer Validation on their website:

Software validation means confirmation by examination and provision of objective evidence that the particular requirements for the software’s intended uses can be consistently fulfilled (Ref. 1). In other words, validation of BECS in the user’s facility should assure that the software is suitable for your specific operations and workload, and can accurately and repeatedly meet your needs as defined in your requirements document.

Link to comment
Share on other sites

Lcsmrz is right, doing your own validation is a great way to learn the system even though it is very time consuming. Having a plan and validation documentation is a must.

You can have a 3rd party validate your software, now days I think they can remote right into the hardware that you will be/are using and perform the validations on that hardware. Open up your wallet though, I know it doesn't come cheap.

We have multiple sites on the same server and just went up last fall, we did our own vals. If you have questions send me an e-mail Mary_Mendel@ssmhc.com

Link to comment
Share on other sites

When I did the Softbank software validations, the company provided us with a huge manual and step by step validation instructions. It was my first time to do validations and it's very challenging to find out what it can do and what it can't do. What helps me a lot is to print the screen for each NIBES functions and saved them for documentation. On site validations must be tested using the actual hardware you will be using for the applications and software program applicable to your SOP.

Link to comment
Share on other sites

I think Lcsmrz's explanation was good. What Likewine 99 said was also true.

We paid to a vendor to validate our new Mediware HCLL system 3 years ago. They remotely signed into our system, performed the validation exercises, printed & compiled the screen prints (which they gave to use as our documentation.) Our FDA Inspector was very impressed (for whatever that is worth.)

Mediware did provide very nice step by step validation scripts to follow if you are going to do the validation yourself. I would have liked for us to do the validation ourselves, because you really do learn a lot about the system (and I thought the cost of the vendor validation was high!) But we just did not have the time or personnel to do it ourselves. (It's a LOT of work!!) Of course there were still plenty of things that we checked ourselves. All in all, we were very pleased with the vendor's validation.

Link to comment
Share on other sites

Hello,

In the new document library section, here what i found in a document from FDA called "Blood Establishment Computer System Validation in the User’s Facility"

"Validation of your Blood Establishment Computer System should reflect and anticipate the system's actual use in your establishment. You should validate your system using your own personnel and your own test plans written for your specific intended use of the software. You may wish to retain a consultant for direction and assistance for this project.

We also recognize that it is a common practice for the software manufacturer to provide test cases to blood establishments for use in system validation. We recommend that you carefully consider your own intended use of the software and your internal policies and procedures and add or change test plans as appropriate to ensure that the software will accurately and repeatedly meet your requirements.

Software validation is difficult because you cannot test forever, and it is hard to know how much evidence is enough. Mostly, software validation is a matter of developing a “level of confidence” (Ref. 1) that the device meets all requirements and user expectations for the software automated functions and features."

Benoît

Link to comment
Share on other sites

  • 1 month later...

The other advantage of on-site, user performed validation is you can spot any problems in your build - things that will be unusable in practice and can (hopefully!) be changed prior to implementation to reflect the expected use.

It also helps in developing organisation-specific training materials. We opted for our own, not using the vendor's since they were effectively useless for our purposes "Select hospital <Never heard of one like that before>" (sure...and then everyone is confused and discombobulated when it comes to the real thing) and it certainly gave our end-users a degree of comfort knowing that the training materials were prepared specifically for them. We changed to computer crossmatching from immediate spin, so that comfort zone was helpful.

Link to comment
Share on other sites

  • 4 months later...

I think that the recommendation mentioned in one of the posts that you perform your own validation is a good one for a number of reasons.

- as a number of people have said it is an opportunity to get to know the program

- it is independent from the vendor - remember they are testing what they have built the system to do and this may actually vary from how you will use it in-situ. I know that we have found unexpected things when testing a system and had to develop work-arounds for what we wanted to achieve.

- if it's a custom built system for you then it is your opportunity to see if they have actually developed what you intended rather than what they thought you were asking (this has often happened in my experience - lab people and computer people don't always speak the same language)

An independent (from the vendor) company is a compromise though, especially if resources are tight

as I said - my opinion only :)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Advertisement

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.