And yet the FDA (Food and Drug Administration) sent a total of 127 warning letters in 2018 due to inadequately validated systems, among other things.
What actually is GMP?
GMP (=Good Manufacturing Practice) has been used since 1962 to summarize guidelines for quality assurance of production procedures and processes in the pharmaceutical sector. These guidelines are regularly (usually annually) revised and expanded by the FDA (Food and Drug Administration), as well as institutions in the EU and other countries.
Why do I need validated systems?
A validated system ensures that no manipulations can be carried out during the manufacturing process. It also ensures (in the context of data integrity) that current and historical data cannot be modified without authorization and/or traceability.
For example, let's assume that an audit by an external institution (such as the FDA) finds authorization errors at RocketScience: Data modifiable? Time/date/time zone on the system can be changed by standard users?
The audit finding requires immediate action, which can entail considerable costs. At the same time, RocketScience must provide evidence of all adjustments to the responsible institution. If not all of them are implemented correctly, this can, in extreme cases, lead to a ban on the sale of RocketScience products.
The path to a validated system
System validation essentially always follows the same process: the V-model.
The URS describes the customer's/laboratory's requirements for the new system and is usually very specific in terms of chemical/biological/process requirements. It is often forgotten that these requirements also have to be tested later on. For this reason, everyone involved should be at the same table right from the start.
For example, the SuperHub laboratory needs a new measuring device and has already selected a suitable one. To carry out the validation, a kick-off meeting is scheduled with the laboratory/customer itself, the CSV specialist/project manager, the IT department and the responsible technical QA. The device can only be purchased if all parties agree.
Labor InsightOut also have a new device in mind, but are missing this important step because time is pressing and it needs to be put into operation as quickly as possible. The device is therefore simply purchased and the relevant departments are gradually involved.
The FS describes the desired technical structure of the system, while the DQ checks whether the requirements from the URS and FS meet the GMP requirements for the product to be produced. Critical functional parameters are also listed and evaluated. Finally, in the "System Build" section, the system is designed or built according to the specifications from the URS/FS/DQ.
During the IQ/OQ phase, the system (and its structure) is extensively tested for errors/problems and the requirements listed in the previous documents are checked for functionality.
Changes are often necessary at short notice during this phase due to technical deviations. This is recorded in the previous documents. A change is usually only subject to change from the end of IQ/start of OQ.
In the final phase(PQ), it is checked whether the system functions continuously within the specified parameters. User acceptance(UAT) and data integrity requirements are also tested. Here it quickly becomes apparent whether the previous steps (especially the kick-off) have covered all aspects.
Labor SuperHub has invested in the preparation time and had the commissioning validated by all relevant parties. The new measuring device can now be integrated into the work processes.
On the other hand, the functionality of the Labor InsightOut device was found to be limited. Either parts or the entire project will have to be readjusted, which will increase the overall effort considerably. In the worst case scenario, a complete revalidation will be necessary, which would entail years of delays in parts of the operating process.
Do you want to run your project like Labor SuperHub?
The rapidly changing data integrity requirements in particular are a major challenge, as institutions often communicate requirements that are difficult or impossible to implement during audits. This requires a deeper technical understanding in order to find solutions or accepted workarounds.
What happens after that?
Once the system has been successfully validated, further monitoring must be set up, as the requirements for validated systems can change significantly every year. Experience has shown that institutions rarely relax requirements, but rather tighten them, which becomes apparent during audits at the latest.
The same requirements also apply to server systems and infrastructure, with a particular focus on backup & restore processes.
What is the situation in your company? Are your systems compliant? Are you unsure? Or have you already identified a need for action and don't know where to start?
innobit is at your side with help and advice! Contact us as your competent partner for a qualified and validated infrastructure.
