Jump to content

BB Validation/New Server


Recommended Posts

If your computer system is being moved to a new server (AIX) that is the same operating system but an upgraded version with faster processing, would re-validation of the BB system need to be performed?  Not sure if a new server would be considered a "hardware" change? And if re-validation would be required, is a full re-validation needed or would a partial validation check be sufficient?  We have reached out to our vendor and they are telling us that re-validation is not necessary.

Any thoughts/recommendations would be appreciated!

Thanks,

LA

Link to comment
Share on other sites

We just moved to a new server for our donor system and we did a short validation to ensure that we could enter and receive all information end to end.  That would include our connections to our donor questionnaire program, registration, draw information, manufacturing of the unit and exporting the unit to our transfusion system.  We also tested our instrument interface that sends donor tests and the interface that we receive our tests that we send out for donor testing.  It might seem like a lot to some, but when they are moving your whole application to a new piece of hardware, it would be prudent to ensure they did it correctly.  We have a validation environment that they did the changes to first so that we could do our validation, (from which we did find some problems) then we performed a smoke test in the production side after the move as well. 

Considering that FDA states that you should validate your system...using the same software, hardware etc...I would recommend some type of documented validation.

Link to comment
Share on other sites

Another vote for validate.

We had a call with two people from FDA.  Our IT wanted to do a build on server A, all of the testing and validation on server A, then at go live, exactly replicate server A on server B and have server B be the new production server.  Our IT said since it would be identical it would not need validation.  I disagreed (as I often do), hence the call with FDA.

FDA agreed that server B was not validated and not suitable for use prior to testing and validation.

When I approach these events I try and understand what I want to accomplish.  Am I just meeting a regulation and there is no safety to the patient / donor added?  Then I do the least required.  Is there a chance, even a small one, that data could get compromised?  Then I do a full validation, regardless of what's required.

Link to comment
Share on other sites

  • 4 years later...
10 hours ago, labgirl256 said:

I don't think so, but I am told it is a requirement to validate the software every 2 years (mini-validation). I am still searching for answers. :) 

I'd suggest starting with who recommended a validation every two years.  We've gone many routes over the past couple of decades.  We've done the validation 100% inhouse (a lot of work) and hired people to do all that is allowed for an outside vendor to do (a lot of money).

Link to comment
Share on other sites

12 hours ago, Cliff said:

I'd suggest starting with who recommended a validation every two years.  We've gone many routes over the past couple of decades.  We've done the validation 100% inhouse (a lot of work) and hired people to do all that is allowed for an outside vendor to do (a lot of money).

Also, if you waste time and effort on validation that is not necessary, you have less of both to do necessary validation.  

I mean what's next?  Validating the change is the oxygen/CO2 ratio due to staff breathing?

Link to comment
Share on other sites

On 11/11/2021 at 8:06 AM, Baby Banker said:

I mean what's next?  Validating the change is the oxygen/CO2 ratio due to staff breathing?

Random extrapolation: I always ponder the change in BB tech heart rate when an Massive Transfusion Protocol is called, the differences between techs, and how much, if any average variation between hospitals ...

Link to comment
Share on other sites

AABB 3.9 Information Systems


The BB/TS shall have processes to support the implementation and modification of software,
hardware, and databases relating to the requirements of these BB/TS Standards. Standard
5.1.1 applies. These processes shall include:
1. Risk analysis, training, validation, implementation, and evaluation of postimplementation
performance.
2. System maintenance and operation.
3. Documentation written in language understandable to the user.
4. Display and verification of data before final acceptance, when data are added, or when
data are amended.
5. Evaluation, authorization, and documentation of modifications to the system.

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.