Simplifying Part 11

In August 1997, three major events that happened include: 1) Apple and Microsoft announced a partnership, 2) the Teamsters Union strikes related to issues surrounding pensions and part-time workers and 3) 21 CFR Part 11 becomes effective. Personally, I had no idea about those first two national events, but 1997 was my first year in the world of pharmaceuticals and Part 11 was big news. It was the topic of ‘how to’ discussions, a popular conference topic, and even the focus of countless meetings with the quality department to define how a company was going to not only interpret the regulation but how they were going to implement it. Here we are, 23 years later, and Part 11 is still a widely discussed topic. There are still webinars, conference break-out sessions, and those meetings with the quality department.

Over the years, I have helped companies take a logical, and yet simple, approach to Part 11. I love it when a company can get away from a “Part 11 assessment” because they simply build those requirements into their new software purchases. It is an expectation, not something you have to remind someone of.

So, I want to talk a little about the pure software elements of the regulation. For the purposes of this discussion, I am going to ignore the requirement for telling the agency that you plan to use electronic signatures, and the procedures you need to have in place regarding people acknowledging that their electronic signature is just as binding as their handwritten one. I am also going to leave out the encryption requirements for open systems as depending on your company philosophy and infrastructure, that particular piece of the regulations can get a bit tricky.

What does that leave us with? First, it leaves us with the scope of Part 11. The guidance on how Part 11 will be interpreted clearly states that it will be a narrower enforcement than originally anticipated. It specifically talks about legacy systems, or those systems that were in-use prior to the effective date of the regulation. As long as those systems meet certain criteria, the agency does not intend to take enforcement action related to those systems. What are those criteria? They include being in place prior to the effective date of Part 11, meeting all the predicate rules before the effective date, currently meeting the predicate rules, and having documented evidence that the system meets intended use.

So, when does Part 11 apply? Well, it depends. I always ask my clients “If this was on paper, would it be required based on your regulations, or predicate rules?” If the answer is yes, then Part 11 would apply. For example, if you had a completely paper based system and you didn’t keep your redline drafts of standard operating procedure (SOP) changes, why would you need to keep them just because you happen to manage those documents in an electronic tool? In my opinion, the same process you use to determine whether a system requires validation should also be used to determine if Part 11 applies to an application. There should not have to be a separate activity that needs to be performed.

Second, it leaves us with the physical requirements of the application itself. Requirements such as controlled access, operational checks to ensure people are performing the correct actions based on the process, audit trails and electronic signatures.

Let’s talk about electronic signatures for a moment. FDA guidance defines Part 11 signatures as those electronic signatures that are used, for example, to document the fact that certain events or actions occurred in accordance with the predicate rules. It’s where an electronic signature takes the place of one that would be required if the process was paper based…it uses the verbs Approved, Reviewed, or Verified. It all relates back to what would be required on paper. If it is needed on paper, it is needed in the electronic system.

This applies directly to something like the audit trail. If I was making corrections to a data element in a paper batch record, I would have the ever popular single strike-through, the corrected data element, my initials/date, and even a reason for making that change. The same concept applies to electronic records. There comes a point in the process where the data is ‘official’ and changes made to it need to be captured. In some cases, having the history in the audit trail may be enough, but you may have systems and/or data where you want changes flagged in any output (such as data views, or reports), because you need to know that data was changed and why. That is a decision that has to be made by each company based on their records, their data, and their specific predicate rules.

Perhaps that is exactly why Part 11 still seems to be such a source of heartburn for companies even after 23 years. It is one of the more specific regulations published by the FDA and yet there is still no one-size- fits-all solution. Everything is dependent on your company and how they choose to embrace the electronic age. It depends on how important a paperless environment is and how they interpret and implement their own predicate rules.

What does all this mean for you and your company? It means you need to establish Part 11 requirements as the default when designing or purchasing a new piece of software. It means you should detail out those requirements as part of any vendor assessment and system selection process. It really means that your Part 11 requirements should be as natural and as integral as the core function you need that software to do.