Now that a year has passed, we thought it would be beneficial to provide you with an updated timeline around FDA UDI. While nothing is official, the following is the most recent information on how the FDA UDI rollout might look:

12 Months after the FDA UDI Standard is Published (2013)

The first set of deadlines focus on Class III Medical Devices. These are devices that support or sustain human life, are of substantial importance in preventing impairment of human health, or present a potential unreasonable risk of illness or injury to the patient, such as implantable pacemakers, replacement heart valves, automated external defibrillators, and implants.

• UDI will apply to all levels of packaging
• An engraved UDI may be required for some Class III medical devices
• If a device has a serial number, the UDI will also be serialized

36 Months after the FDA UDI Standard is Published (2015)

The next class of medical devices to be effected is Class II, which are items like x-ray systems, gas analyzers, pumps, and surgical drapes.

• UDI will apply to all levels of packaging

60 Months after the FDA UDI Standard is Published (2017)

The final group is Class I Medical Devices, such as tongue depressors, arm slings, examination gloves, and hand-held surgical instruments.

• UDI will probably just apply to the device (not packaging)

Medical devices are classified by intended use and potential risk to the patient, and as you can see from the timeline above, the UDI regulations address the most critical devices first. The years listed are based on the FDA UDI standard being published in 2012, which is the current plan. Stay tuned!

Initially, the new requirement was widely ignored by both the industry and the FDA. This indifference was not intentional, but can be attributed to a pure lack of understanding by both the industry and the regulators. More recently the understanding of the rule has become more widespread within both regulated companies and the regulators. This is mainly thanks to organizations like GAMP and ISPE. There has been significant clarification of
the requirements published by the FDA and, of course, there have been detailed warning letters published on the FDA’s web page. This article is based upon practical experience from numerous 21 CFR Part 11 compliance projects that our company has performed, and through information culled from our customers in consultation with the regulators.

21 CFR Part 11 Labeling Systems: Sharing Our Practical Experience

Based on trends over the past five years, one can see that there are still three main areas where labeling projects can go wrong: supplier based, customer based and application based problems.

1. Supplier Based Problems

The main supplier based problem is the failure to fully appreciate the scale of the task when assisting a customer in implementing a compliant system. Lead times can be unpredictable, as time factored in for such things as documentation approval can easily be eaten up by clarification of points contained in the User Requirement Specification (URS) and/or Functional Specification (FS) documents. We have learned that it’s more cost effective to schedule a comprehensive face to face meeting to discuss the application requirements as detailed in the customer’s URS document, rather than assuming our interpretation is the same as the customer’s. This type of approach also makes sense for the review of the FS document, and has actually saved money for both customer and supplier.

This approach has also highlighted the need for supplementary software tools to be included by the supplier or to be made available by the customer, instead of this fact being realized during the implementation phase.

When a new project is sanctioned, there is a customer tendency to ask for lots of ‘nice to have’s’ (but not essential) features. This can be seen as a golden opportunity by the supplier to make the project as large and custom as possible; however, we have once again learned from our experience to question the need for each and every piece of customization requested. Failing to take this approach increases the risk of a custom solution being
developed for each customer instead of a generic solution being tailored to suit individual customers’ needs. This situation should be avoided, because even if the custom solution meets an organization’s requirements today, it’s unlikely to meet future requirements unless a complete 5-10 year plan has been realized.

21 CFR Part 11 compliant labeling projects whether for Pharmaceutical or Medical Device Manufacturers can be quite large and time consuming, which usually results in a dramatically varying workload situation for the supplier. The net result is that a delivery period can be quoted with all the best intentions by the supplier, yet the actual delivery period will depend upon the supplier’s workload at the time of order placement. This becomes even more difficult for the supplier to manage as the project progresses because the internal resources may not be available at the right time to catch up any time lost due slow document approval or delayed functionality
decisions.

2. Customer Based Problems

As an old saying goes ‘there are always two sides to a story ‘ and this is the case with labeling systems. Customers are also a source of problems when implementing new labeling systems. The main customer based cause of disruption is the failure to investigate their own requirements fully or a failure to pass enough detail to the supplier. Invariably, the review of the URS or FS documents with our customer leads to the customer realizing there is more to 21 CFR Part 11 compliance than they initially thought. The systems feeding data to the labeling program should also be considered for 21 CFR Part 11 investigation and compliance. The use of databases is a typical area where the compliance of the labeling system can fall down. Most databases used by customers to populate the labeling system do not have an electronic signature associated with a new record entry or a modification of an existing record. A solution needs to be incorporated to solve this problem, and that often comes as a surprise to the customer.

In the past, most labeling systems were simple standalone systems that were supported by SOPs and paper based records. Today, this is not the case as 21 CFR Part 11 compliance has forced labeling software developers to move towards client/server type systems. Such systems now require much more effort on the part of the customer to maintain control over the system. For example, user permissions and passwords need to be handled for current and former users of the system. The system architecture also needs to be documented and controlled by the customer. This sounds easy enough, but one recent customer who kept this information in an electronic form found out this type of record is also covered by 21 CFR Part 11. The program being used to create the record was not 21 CFR Part 11 compliant, and the compliance exercise failed.

It has come to our attention that 21 CFR Part 11 compliance projects involving labeling systems have a heavy reliance upon customers’ IT teams during the specification and installation phases. It is very important that these people are suitably trained in cGMP procedures to ensure any planned activity is in line with the current regulatory requirements. If a third party service provider is being used for this activity, then once again, their own staff should receive cGMP training. This subject has also been highlighted in recent FDA warning letters.

3. Application Based Problems

Surprisingly, compliant labelling problems can often occur at the application level. A typical problem often occurs when data entered at a local printer keypad is not recorded, thus making it impossible to produce a complete and accurate electronic record of what was actually printed. Data entry to standalone printers or PCs cannot usually be accepted, which has severe implications for many existing Print & Apply systems and causes a great deal of discussion and re-thinking.

The typical print room environment in a Life Sciences environment which may have several operators using several different print stations is no longer practical as the password entered at print time may not match the password that was used when the system was started. Closing the application and restarting it for each different user every few minutes is not a workable solution. Our solution to this problem is to recommend the use of a biometric mouse, thus negating the need to seek a typed password when making a new electronic print record.

To our surprise, this solution led to lengthy conversations about how much of the users thumbprint is scanned while using the mouse, and how this record itself was stored. Some customers and individual users were concerned with the thought of their thumbprint being scanned and stored electronically, fearing the system could lead to misuse and abuse in areas outside the labeling system. In reality, most biometric mice devices take a snapshot of two or three points on the thumbprint and assign coordinates to them. The thumbprint is not actually stored, just the expected image at each of the coordinates selected. The master coordinate and image details are
compared with the user’s thumbprint on the biometric mouse each time a signature is requested. This way it is impossible to reproduce the original thumbprint. Users, as a result, have greater confidence in the system and the solution is now generally accepted on this basis.

In some instances, the label production rate can be adversely affected by the need to record an electronic signature for each different label printed. This can be a problem, especially where the batch quantities are very small. Applications involving clinical trials labels can be a particular problem as every label can potentially be different and a signature for each different label is not practical. Coding changes can be made to print a batch of labels based upon a treatment group and get a reconciliation label with just a single signature entry.

Another application based problem occurs when a label print request is actioned, electronically signed and recorded, but the labels do not get printed due to a printer problem. The original record usually cannot be modified or deleted by a print operator, yet the labels are still required. Until recently, a customer procedure was needed to provide a documented solution to this occurrence. Now, as a result of this experience, you’ll see a label reconciliation tool added to the standard labeling program. This allows the occurrence and the corrective action taken to be recorded, thus the true picture is always known.

Data integrity and data migration have also becoe important points to be considered on 21 CFR Part 11 compliance projects. Most applications that feed data to the labeling system are usually themselves non compliant. Thus, care needs to be taken when making use of such data. In practice, companies should strive to reproduce a function provided by something like Excel within its own compliant application to help solve this problem. This process means companies are in control of their own destiny and can offer customers a high degree of reassurance concerning compliance. Data integrity has been the subject of many recent FDA warning letters, particularly with reference to non 21 CFR Part 11 compliance. Data migration can also be a problem as simply importing data from another source often means this data is unchecked or unapproved. It is possible to import data, make it secure and approve it for label production use ‘ but this can be time consuming. To help reduce the scale of the task, companies should remove redundant data before any migration is considered.

Another point to consider is that FDA warning letters are also becoming more frequent in the area of network architecture and its lack of consideration when it comes to validation or 21 CFR Part 11 compliance. The FDA has recognized that keeping control of the relevant network architecture is important to ensure the integrity of the system in question. Companies should ensure that network plans are available and that they are kept up to date.

Validation should prove that any critical data can be safely moved around the network and that, where automated data retrieval systems are involved, tests should be done to prove that in the event of a failure the system fails safe.

Conclusion

Replacement of existing labeling systems is a much larger and more involved task than previously thought, although by choosing the correct vendor, there are ways to make the project easier to manage and also to ensure an FDA 483 warning letter is not still issued once an audit is performed. Current labeling practices need to change in most pharmaceutical and medical organizations due to the wide ranging scope of 21 CFR Part 11. Choosing the correct supplier and working closely with them is important to ensure a smooth transition between labeling systems.

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:-

1. 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.
2. 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.
3. 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.
4. 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.
5. 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:-

1. No Company ‘X’ Functional Specification in the validation materials.
2. Using software with inadequate version controls.
3. General inconsistencies in the validation materials.
4. 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:-

1. 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?
2. 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?
3. 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?
4. 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.
5. 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.