PrisymID have been a leading supplier of labeling software solutions to the world’s Life Sciences companies for almost 25 years including over 10 years of experience delivering labeling solutions to meet the requirements of 21 CFR Part 11.
This article shares the experiences of the delivery team at PrisymID and gives readers an update on the findings of the team over the last few years. It also gives details of the key features of a modern labeling system and a guide to the questions they should ask any potential labeling system supplier.
A Do It Yourself Audit - Is Your Labeling System Really 21 CFR Part 11 Compliant?
The main topic for discussion is the top five areas where we have found installed labeling systems fall short when audited for compliance in general but for 21 CFR Part 11 in particular. Common problems on systems we have replaced are discussed, the key features required for a validated system are listed and of course what to look out for when reviewing your own system? This article poses some questions that you should ask yourself if you are responsible for a labeling system and concerned about possible compliance issues. At the end of this article you should have a better idea as to which common pitfalls to look out for.
What is 21 CFR Part 11 ?
We all know that 21 CFR Part 11 is well established and that the risk based approach introduced several years ago is now fully accepted by the FDA providing of course your justifications are sound and logical. Practically speaking 21 CFR Part 11 requires the implementation of controls, including audits, validation and documentation for the software and systems involved in printing the labels. After all the label is a controlled document and is part of the bill of materials for the device or drug.
The top five areas where you labeling system may fall short in an audit, based upon our experience at PrisymID, are detailed below:-
- The labeling system is not deemed to be 21 CRF Part 11 compliant as it’s not properly supported by validation documentation. The documentation is either inadequate, the system has not been the subject of a risk assessment or the documentation is missing completely.
- The labeling system is non compliant to the requirements detailed in quality systems regulation 21 CFR Part 820. This usually relates to the process of label design revisions not being controlled properly with little or no control over the old version being recalled when a new version is released. The process to do this is not forced upon the users and the SOP’s are often weak in this area.
- The labeling system SOP’s are not documented. Often we found our potential customers to have good GMP practices around the labeling system but when we asked for a copy of the SOP’s they were not always found or indeed proven to be reflecting what actually happened in the labeling process.
- There is no label batch traceability or direct employee accountability in the event of a product recall due to a labeling error. Often it was not possible to trace the actions to one single individual due to shared passwords or just plain open systems.
- The labeling system does not meet the FDA’s requirements in terms of version control and history for each individual label design. Often there is no single electronic file containing the various version of a label design and its change history or the links to sister files are missing or broken.
To help highlight how serious the situation can become without the users sometimes realising it then please consider this recent case study concerning medical device company’.
Company ‘X’ are based at two locations, one in New Jersey and one in Pennsylvania, they share a central database (MFG/PRO) across the two sites and are exporting products on a worldwide basis. A paper based system is used for the approval of label designs which are generated by generic labeling software with no vendor provided lifecycle documentation. The label approval process takes weeks as the sites are split and the process relies on people passing a folder around to get the label approvals done. ‘Validation’ on the labeling system was done by the customers own IT department but no formal documentation could be produced. In essence the IT department tested the system but could not validate it as the systems requirements were not documented. The system must print foreign characters and phrases on the labels for export to Europe but no one could be found to be responsible or accountable for the translations. Finally they inspect each and every label after it has been printed due to their concerns about characters being missing, label misprints and the data not being available in the manufacturing database. This was a huge burden on them and dramatically slowed down the production process.
It should be no big surprise to anyone that the FDA were not pleased when they conducted their audit. A 483 Warning Letter was issued, a summary of the notice is detailed below:-
- No Company ‘X’ Functional Specification in the validation materials.
- Using software with inadequate version controls.
- General inconsistencies in the validation materials.
- Vendor software coding not subject to a QA review, no vendor audit undertaken.
In this particular instance the FDA were very helpful with their suggestions as to what Company ‘X’ should do. It was suggested Company ‘X’ should move to an electronic record keeping system as part of a move to a new properly validated labeling system which would ensure a better chance of general FDA compliance in the future. An electronic system would give quicker responses to audit requests or product recalls. This would result in the labels being designed and printed in accordance with 21 CFR 820 quality assurance guidelines while also meeting the requirements of 21 CFR Part 11.
The FDA suggested their chosen software supplier should be one that has completed general product lifecycle testing of the software with the relevant supporting documentation being passed on to the users. The supplier should be asked to assist the users with the execution of an onsite validation plan following the GAMP guidelines for computer software systems. A separate language database should be created with a table for each language required thus allowing the phrases to be translated and validated individually and outside of the main labeling system. Finally it was suggested that the vendor supplying the label printers should perform a printer driver test on each one to prove the printed output and remove the need to inspect each and every label. This in its self would lead to greater efficiencies and allow time for the proper compliance monitoring of the system.
The key features of a validated and FDA compliant labeling system are still those based around the GAMP guidelines for validation. A piece of software itself cannot be considered as compliant yet we still get asked this question about our software. Any critical software must be supported by a properly conceived and performed validation project. Software should be written and tested using a documented and recognised lifecycle process to help reduce the amount of validation needed to be done onsite by the user. The software should automatically generate complete and accurate records of all critical changes to the system and not just be limited to changes in the label designs. Records need to be quickly retrievable and stored in a way to ensure they are secure, accountable to the person making or adding to the record as well as being protected against unauthorised input and deletion. Finally the labeling software should be installed via a pre-approved validation plan comprising of IQ/OQ/PQ scripts and supported by reports detailing the result of the running such scripts. This way you are in control of your system and of course rebuilding it or reproducing it should be much simpler.
When at the planning stage and considering a new labeling system there are several important questions you need to ask yourself to ensure you are looking at the right solution. For example is there an automatic and accurate time/date stamp for all entries that create or modify a record and does the audit log show the name of the signer and the meaning of the signature all in a single record? Does the system enforce the correct sequencing of steps and events such as in the label design and approval process? Are there checks to ensure that only authorised persons can use the system and are electronic signatures provided only for user actions that are at their appropriate level of authority? Users need to be forced to change their own passwords frequently and not be allowed to reuse a password as this helps prevent the use of unauthorised group passwords that can be common around the use of label printing systems.
Check the systems audit trail is independent of the users, for example we have found some audit trails have been switched off or they can be edited by unscrupulous users. Ensure you will receive a comprehensive set of lifecycle documentation from your system supplier and make sure the documentation is for the version of software you are purchasing or have installed. It’s amazing how many discrepancies we have found in this area. The vendor should provide you with a risk based list of activities you should concentrate your onsite validation efforts on. If it’s not offered then ask for it before making your purchasing decision. Be careful when upgrades are installed, ensure you have the documentation to support the upgrade and make sure you are using the upgraded software in all the relevant locations and not just some of them. This is a very common error and is easily spotted by even the most casual audit of an inspector. Finally make sure you know about your chosen vendor’s quality certification as you will be relying on it to help support your risk based validation approach when questioned by the FDA.
There are five important things to remember when looking at general computer based software and in our experience labeling software in particular:-
- s the labeling software you are going to use ‘fit for purpose’ for Life Sciences labeling requirements in general and specifically 21 CFR Part 11? Are you going to make do with generic software or choose the right tool for the job?
- In the event of a product recall or FDA audit are you able to supply an audit log of the label history going back five years and can you provide this in a timely manor as you may very well need to do so sometime?
- Is your labeling software supported by full lifecycle documentation to prove your exact needs were considered before it was purchased, i.e. was it a planned and documented purchase?
- Did your software get installed as part of a validation project covering all the labeling focused PC’s, terminals and printers? The whole system needs to be validated and not just parts of it.
- Can you be sure the compliance of the labeling system has been proven over its network or web connections? This is an important area which is being focused on by the FDA but it’s often missed by the system owners.
If you don’t get each of the above points right then the consequences can be very serious indeed. An FDA 483 warning letter can lead to company difficulties, the share price falling and even potential job losses. Hopefully this article and the guidance contained within it will prevent such an occurrence happening to you.
This article is based upon a presentation researched and written by Bob Tilling that was presented at the IVT Validation Week held in Philadelphia PA in November 2008.
Tags: 21 CFR Part 11, FDA, GMP
