Transferring a validated software platform to a virtual server

kisxena

Starting to get Involved
#1
Hello:

Last year I spent many months validating our 3rd-party documentation software. Now, the IT department wants to move it from the Oracle platform to a virtual machine system (VMS).

My question is, how in-depth of a validation do I need to create and perform?

The IT department wrote a very skeletal virtual plan which only outlines performing functions of generating an ECO, creating a part number, verifying CCB review can be performed, release of the ECO and opening an attachment.

I'm not an expert in ISO and QSR requirements when it comes to transferring an already validation software system to a virtual platform.

Any advice is greatly appreciated.

Thanks,

-Renee
 
Elsmar Forum Sponsor

Marc

Hunkered Down for the Duration
Staff member
Admin
#2
I moved this thread to the Software Quality Assurance forum. We don't get too many software people here, but hopefully someone can help.
 

Kevin Mader

One of THE Original Covers!
Staff member
Admin
#3
Marc,

I'll take a shot, but it is late so this may be in parts.

Renee,

My experience is that the IT folks understand very little about validation from a Part 820 or Part 11 perspective. It's difficult to say for sure if the plan provides an adequate validation strategy, but using a risk based approach, you might significantly reduce the amount of work needed. For instance, it is not uncommon to use a different client server to verify and validate software before loading it into the production environment. Here, you would need to demonstrate why the test client is similar the production client. This is done all the time. You might want to develop your rationale around the level of testing needed around this concept, develop your validation strategy in the hopes of minimizing your work. I'm skeptical of the IT plan - some of the ones I've seen are flimsy and poorly concieved because they aren't familiar with the regulatory requirements and because many IT professionals I've worked with are adhoc testers, creating and validating in the same effort. Poorly established requirements are largely to blame as most often its experimenting while designing only nobody knows when to stop designing and when to start validating. It makes the strategy and tactics of validation difficult and sometimes impossible.

Well, something to get you started. There are others here with good experience around your problem. Hopefully they will chime in too.

Regards,

Kevin
 

kisxena

Starting to get Involved
#4
Thanks Kevin for your info. Hopefully others will chime in as well.

You're right, IT does not fully comprehend 21 CFR Part 11 but we try to educate them. :)
 

Kevin Mader

One of THE Original Covers!
Staff member
Admin
#5
kisxena,

Questions for you -

Does your QMS have established procedures around QMS software validation? If you do, there may be some internal guidance there that can help you.

When reviewing your original Validation Plan, are there aspects in it that can be leveraged? I'm assuming that many aspects can be rationalized as to why you wouldn't have to revalidate them.

Regards,

Kevin

P.S. I love the weather in San Diego! I generally get to pass through your city a few times a year.
 

BradM

Staff member
Admin
#6
I think Kevin covered this quite sufficiently.:agree1: Good to see you around, Kevin.:yes::agree1:

First, there should be a written plan that entails what differences are expected. The designer of the validated program should be able to help provide some caveats to the differences that will occur when switching platforms.

I would think a general testing plan should focus less on the actual functionality within the application, and more what happens when it interacts on whatever platform it has been placed.

For example, will the software time out the same, will the reports look the same, will access to the platform be the same, etc. Even after any validation work has been completed, I would recommend keeping a good change control, issue system so that you can capture when something occurs, and clearly identify the applied solution.

Just some random thoughts.:D
 

Kevin Mader

One of THE Original Covers!
Staff member
Admin
#8
That's good advice Brad. Asking the architects about the differences and challenges to be faced should help tease out the test plan requirements and help to establish/adjust the acceptance criteria.

I don't get back here as often as I'd like to - darned kids;), but it's good to contribute when I can. Thanks for chiming in.

Kev
 
A

arin_23

#9
Hello:

Last year I spent many months validating our 3rd-party documentation software. Now, the IT department wants to move it from the Oracle platform to a virtual machine system (VMS).

My question is, how in-depth of a validation do I need to create and perform?

The IT department wrote a very skeletal virtual plan which only outlines performing functions of generating an ECO, creating a part number, verifying CCB review can be performed, release of the ECO and opening an attachment.

I'm not an expert in ISO and QSR requirements when it comes to transferring an already validation software system to a virtual platform.

Any advice is greatly appreciated.

Thanks,

-Renee
Dear Renee,

I could not get the clear picture from your problem statement, is it a legacy system you possess which needs to be re engineered? Or it is simply moving from one technology to the other?

If you talking about validation then I assume you are the end user of the software.

Lifecycle models are going to be different based on the different kind of situations. For case 1 the re-engineering lifecycle model shall be followed, while in case 2 it would probably be a modification / enhancement lifecycle where the standard SDLC would be followed. Based on the lifecycle models your testing strategy shall vary.

For case 1 there would be significant changes to the project artifacts and test cases shall be redefined, whereas for case 2 there might be new set of test cases developed based on the URS and followed up by a detailed requirement analysis.

In both the cases however the base lined SRS is the artifact which would give clear indication of the testing strategy. In my opinion before jumping onto the UAT of the final application ; carry out the validation in a staggered manner, and in each stage namely SRS, HLD, LLD, Module-wise code review and finally UAT of the application. Please make it a point to validate the product documentation as well.

The URS shall be your starting point and the Application successfully running in the production environment is the last step. In between strict configuration control has to be exercised for all CR’s as there should not be anything which is missed out due to loose configuration control mechanism.

This kind of staggered validation technique shall enable you to have full work knowledge about the product.

Regards,

Arin
 
Thread starter Similar threads Forum Replies Date
H Transferring an ISO 13485 certificate to a new CB - Do I have to start from scratch? ISO 13485:2016 - Medical Device Quality Management Systems 2
B ISO 13485 Transferring a product from manufacturing facility 1 to manufacturing facility 2 ISO 13485:2016 - Medical Device Quality Management Systems 6
W Transferring epoxy from container to dispenser - Labeling AS9100, IAQG 9100, Nadcap and related Aerospace Standards and Requirements 1
E Pallets need to be changed when raw materials are transferring from WH to MFG area? Pharmaceuticals (21 CFR Part 210, 21 CFR Part 211 and related Regulations) 6
Q Transferring EPA Registrations - Timeline? Various Other Specifications, Standards, and related Requirements 3
K Transferring Authorized Representative (AR) in Malaysia Other Medical Device Regulations World-Wide 7
D Transferring Paper Records to Electronic Record Archival Records and Data - Quality, Legal and Other Evidence 4
harrysons Automotive product transferring process what requirement to comply? IATF 16949 - Automotive Quality Systems Standard 3
K Process Validation - Production Line Transferring to a Different Facility Qualification and Validation (including 21 CFR Part 11) 16
J Help me make a judgement about transferring this process Six Sigma 6
K Transferring Calibration Certificates General Measurement Device and Calibration Topics 5
C Medical Device Stability Studies - Non-validated pilot production Other Medical Device Related Standards 1
D Use of password managers on validated computer systems (21 CFR Part 11) Medical Information Technology, Medical Software and Health Informatics 2
P Retired equipment that was never validated Qualification and Validation (including 21 CFR Part 11) 2
D Verification that Manufacturing Equipment has maintained a Validated State Design and Development of Products and Processes 11
S Is Process Validated samples required for IND submission ? US Food and Drug Administration (FDA) 2
I Run a batch every year to revalidate the validated condition? Qualification and Validation (including 21 CFR Part 11) 4
P Customer Validated Special Process Requirements AS9100, IAQG 9100, Nadcap and related Aerospace Standards and Requirements 2
H Validated Software - IND study to get a BLA (Blood Analysis Device) 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
M 7.5.1.3 Should mentioned examples such as initial run be verified or validated? IATF 16949 - Automotive Quality Systems Standard 1
E AQL Level Change for FDA Validated Unclassified Dental Product Inspection, Prints (Drawings), Testing, Sampling and Related Topics 10
P Selling Joint Implants without a Validated Process Manufacturing and Related Processes 8
I Using validated SAS JMP to validate Excel for Statistical Analysis? Qualification and Validation (including 21 CFR Part 11) 11
M 21 CFR Part 11 & Control of Raw Data Records used as input into Validated Spreadsheet Qualification and Validation (including 21 CFR Part 11) 2
T Final inspection and testing of product from validated processes Misc. Quality Assurance and Business Systems Related Topics 1
B Package validation on a different product in an already validated package? ISO 13485:2016 - Medical Device Quality Management Systems 7
S FDA part 820 Software Validation - Can software be retrospectively validated? Qualification and Validation (including 21 CFR Part 11) 10
Ajit Basrur Blocking a Mold Cavity - 16 cavity mold which has been validated for a part ISO 13485:2016 - Medical Device Quality Management Systems 12
Y OS Changes to Fielded (Validated) Medical System 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
apestate How are calibration procedures validated? General Measurement Device and Calibration Topics 3
D Is there a "list" of what are termed Special Processes that have to be validated? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 49
A Manufacturing process design validation - What aspects are validated? Design and Development of Products and Processes 3
C Database validation - Guidance on how a database should be validated? Software Quality Assurance 4
P Part 11 - Changes to a system validated to Part 11 - What to revalidate? Qualification and Validation (including 21 CFR Part 11) 1
R Shall a new UDI-DI be required when stand-alone software device's version is updated? EU Medical Device Regulations 1
R MSA for ATE (Automatic Test Equipment Embedded Software) Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 9
S MDR GSPR Clause 17 - Software Requirements EU Medical Device Regulations 2
L Turkish Requirements - Does the Software need to be translated? CE Marking (Conformité Européene) / CB Scheme 2
MDD_QNA Medical Device Software - Is a Help Button required? IEC 62304 - Medical Device Software Life Cycle Processes 1
F Software as a Medical Device (SaMD) Technical File Requirements Manufacturing and Related Processes 1
D Software User Interface Languages for LVD and IVD CE Marking (Conformité Européene) / CB Scheme 2
A Software as Medical Device (SaMD) definition and its applicability Other Medical Device and Orthopedic Related Topics 4
K Software Validation for Measurement Tools used in Process Validation ISO 13485:2016 - Medical Device Quality Management Systems 2
B ISO 14971 Applied to Software ISO 14971 - Medical Device Risk Management 2
N ERP Software Implementation Manufacturing and Related Processes 3
C NCR (Nonconformance System) Software Nonconformance and Corrective Action 7
U Document Approval - Software company ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
B Risk Assessment Checklist for Non product Software IEC 62304 - Medical Device Software Life Cycle Processes 1
MrTetris Should potential bugs be considered in software risk analysis? ISO 14971 - Medical Device Risk Management 5
S SOP for ISO 13485:2016 Quality related Software validation ISO 13485:2016 - Medical Device Quality Management Systems 8
Similar threads


















































Top Bottom