Q - Is it mandatory to have system requirements should be high level and functional specifications be detailed ?
Ans - There is no specifically defined procedure for validation. Different process and terminologies comes under validation. Instead of using different terms like functional requirements, user requirements, functional specs, user specs, design specs, configuration specs, IT requirements, regulatory requirements, it is advised to mention everything as “system requirements”. The FDA does not care whether the requirement for the system came from the vendor, IT department or QA department. Hence rather than worrying over trying to segregate these various compartments of requirements, mention everything as “requirements “. The requirements must be written in sufficient detail such that they are complete, accurate and testable. So very high level requirements really would be the type of thing that you might have when you evaluate a vendor but requirements for validation projects should be concise and testable.
Q -What are the procedures for retrospective validation of systems that have been in production for five to 20 years?
Ans - “Retrospective validation” is an invalid term and should not be used as validation is a point in time process and systems change over time as well as the network and users and procedures. If you have a system that has been in production, rather than calling it “retrospective validation”, mention that you are going to validate your system. In the validation plan indicate that the system has been in use successfully for “X” number of years and give some good rationale for why it was not validated and indicate that you are going to validate it.
The FDA always allows us the latitude to become more compliant. In this particular case, in your regular validation plan indicate that the system has been in use successfully but you recognize the need for validation and as such record the requirements just like you would for any system. You may have some installation records at the company already that you could use for your installation qualification. Go through the process as you would for the new system.
Q - When data are entered into a database, does that constitute a change? how to determine when change control should be documented for system changes?
When data are entered into the system, it does not constitute a change. When you set up a system or when you install your computerized system you are going to establish the baseline configuration of that system. All the software, hardware, inner phases will be documented as well as the configuration choices. Any subsequent change to that baseline configuration can only be done through change control. But data are not part of your baseline configuration and adding data to a system does not constitute change control. But any change to your documented baseline configuration which you establish at installation would be subject to change control.
If you have more questions please inbox me @ mycomplianceblog@gmail.com . i will post questions and answers of experts here
Ans - There is no specifically defined procedure for validation. Different process and terminologies comes under validation. Instead of using different terms like functional requirements, user requirements, functional specs, user specs, design specs, configuration specs, IT requirements, regulatory requirements, it is advised to mention everything as “system requirements”. The FDA does not care whether the requirement for the system came from the vendor, IT department or QA department. Hence rather than worrying over trying to segregate these various compartments of requirements, mention everything as “requirements “. The requirements must be written in sufficient detail such that they are complete, accurate and testable. So very high level requirements really would be the type of thing that you might have when you evaluate a vendor but requirements for validation projects should be concise and testable.
Q -What are the procedures for retrospective validation of systems that have been in production for five to 20 years?
Ans - “Retrospective validation” is an invalid term and should not be used as validation is a point in time process and systems change over time as well as the network and users and procedures. If you have a system that has been in production, rather than calling it “retrospective validation”, mention that you are going to validate your system. In the validation plan indicate that the system has been in use successfully for “X” number of years and give some good rationale for why it was not validated and indicate that you are going to validate it.
The FDA always allows us the latitude to become more compliant. In this particular case, in your regular validation plan indicate that the system has been in use successfully but you recognize the need for validation and as such record the requirements just like you would for any system. You may have some installation records at the company already that you could use for your installation qualification. Go through the process as you would for the new system.
Q - When data are entered into a database, does that constitute a change? how to determine when change control should be documented for system changes?
When data are entered into the system, it does not constitute a change. When you set up a system or when you install your computerized system you are going to establish the baseline configuration of that system. All the software, hardware, inner phases will be documented as well as the configuration choices. Any subsequent change to that baseline configuration can only be done through change control. But data are not part of your baseline configuration and adding data to a system does not constitute change control. But any change to your documented baseline configuration which you establish at installation would be subject to change control.
If you have more questions please inbox me @ mycomplianceblog@gmail.com . i will post questions and answers of experts here
No comments:
Post a Comment