Part 11 and "Disappearing" Signature Manifestations

An interesting question appeared on-line today which we thought deserved airing with a wider audience via the blog.

Q. When implementing an electronic document management system, is it acceptable to make the author/approver names and dates disappear? Is this still in compliance with 21 CFR Part 11.50, Signature Manifestations?

A. Let's remind ourselves of the relevant rule:

§ 11.50 Signature manifestations.
(a) Signed electronic records shall contain information associated with the signing that clearly indicates all of the following:
(1) The printed name of the signer;
(2) The date and time when the signature was executed; and
(3) The meaning (such as review, approval, responsibility, or authorship) associated with the signature.
(b) The items identified in paragraphs (a)(1), (a)(2), and (a)(3) of this section shall be subject to the same controls as for electronic records and shall be included as part of any human readable form of the electronic record (such as electronic display or printout).

The first question to ask ourselves is the question of scope. Not all of the documents stored in the EDMS will fall within the scope of 21 CFR Part 11. In fact, this is a notoriously difficult area in which to interpret the predicate rules. Some rules will clearly state that documents need to be signed and in other areas it must be inferred from the use of words like "authorised" or "approved".

The first thing to therefore do is to clearly decide which categories of document fall within the scope of 21 CFR Part 11 OR (to be on the safe side) to decide that the approval of all documents will meet the technical requirements of part 11.

Looking at the specific question of signature manifestations, subpart 11.50 (b) clearly states that the name of the person signing, the signature date and the meaning of the signature must be included in any printout or electronic display.

Making the names and dates "disappear" in some way clearly contravenes the requirements of 11.50 (b) if these components are not readable in either the on-screen display or the hardcopy printout of the document. If this were to be implemented we would consider the solution to be non-compliant with Part 11, at least with respect to the documents that fall within the scope of Part 11.

PLCs and GAMP Categorization

Here's another interesting question and answer that we thought we'd share on-line with a wider audience:

Q. We are developing a standard template to help in identifying and classifying PLCs into GAMP 5 categories. Could you please guide us to develop the right tool for the same.

A. The 'questions' to include are relatively simple and relate to the GAMP definitions of the categories, specifically on the context of PLCs - for example:
- Is the PLC (or parts of the software) used 'as is' with no modification or with simple changes to parameters e.g. run time, setpoint etc (typically with a machine or piece of equipment)? [Cat 3]
- Is the PLC (or parts of the software) reconfigured using standard graphical programming languages e.g. ladder logic, function blocks? [Cat 4]
- Is the PLC (or parts of the software) programmed e.g. are you writing code to achieve a function or operation that is not a standard feature of the PLC? [Cat 5]

You should also remember that it is quite likely that PLCs will contain a combination of Cat 3, 4 and 5 software and that your validation approach should reflect this.

However, the on-going  problem you will have is two-fold:

1. PLC systems have a great deal of variation in the way they they are parametrized/configured/coded, and sometimes the lines are blurred eg. some 'configuration' can be as complex and error prone (risk-likelihood) as traditional coding. You can't possibly expect to come up with questions and guidance on every type of PLC out there.

2. You need to educate people on what all of these terms mean, in the context of the PLC you are looking at. This takes time and experience.

The only time I have seen this done successfully is when a company standardises on just one or two manufacturers PLCs and then they can provide a checklist / guidance based on the manufacturers specific software development techniques.

When developing the validation approach you will also have to take into account the work that may already have been done by the supplier if the PLC is part of an embedded system.

If you are implementing a lot of PLC systems it will be worth developing an SOP or guidance document on the topic. You will however need to develop some subject matter expertise to be able to guide and support your engineers, because this is a specialist area and needs experience to do cost effectively.

Reflecting on 21 years of GAMP

Last Tuesday saw the 21st anniversary celebrations of the GAMP Forum, now of course part of ISPE. It was a great opportunity to reflect on the history of GAMP and to catch up with some of the original founder members.

Although much of the talk was backward looking, rehashing events that led to the formation and subsequent growth of the GAMP forum, Randy Perez (current chairman of ISPE) did reflect upon the role that GAMP has played and continues to play within ISPE i.e. the GAMP Community of Practice has the best selling publications, the best attended conferences etc.

No one stopped at the time to really comment on why that might be. Having thought about it it occurs to me that this simply reflects the increasing importance of computerised systems not only in the pharmaceutical industry but also in everyday life. The pace of technology change is unending and it is perfectly understandable why GAMP came into being and why it continues to look into topical issues such as cloud computing, mobile platforms etc.

As long as this technology change continues apace GAMP will always have a role to play in applying well founded good practices to new technologies and new applications. There is however a significant challenge that ISPE/GAMP faces with the pace of technology change.

Looking back over recent years it appears that new technologies appear and are adopted by leading edge regulated companies faster than organisations such as ISPE/GAMP are currently able to respond. This is perfectly natural because the strength of organisation like ISPE and GAMP are that they are consensus driven and volunteer led. The time taken to achieve consensus and the limited time available from volunteers means that it takes months or years to discuss new technologies, the understand the implications, identify risks and how they can be mitigated and then to publish consensual good practice.

However, we're all aware that other technologies such as blogging, websites and social networking allow interaction between industry professionals in much shorter timescales. In many cases we are starting to see individuals and commercial organisations provide pragmatic and acceptable guidance well ahead of organisations such as GAMP/ISPE. The other part of the challenge is that although ISPE exists to serve the needs of the pharmaceutical community, the move towards greater outsourcing means that it is very often suppliers who are the subject matter experts with new technologies and consultants who have a broader experience in how new challenges are being tackled across the industry.

The challenge for ISPE and the GAMP Community of Practice is to get the balance right between achieving consensual good practices which regulatory agencies can buy in to and providing guidance in a timely manner. This will require more widespread use of some traditional channels such as ISPE Pharmaceutical Engineering and the greater use of Internet channels such as webcasts, web publishing and social networking. This will also mean continuing towards a model where suppliers and consultants provide valuable input but users from regulated companies are the final arbiters of what is acceptable with respect to good practice.

In some cases this will mean identifying a smaller number of thought leading subject matter experts and asking them to focus on providing pragmatic guidance in shorter timescales. This is certainly the way commercial organisations such as IVT and Concept Heidelberg are working when organizing conferences and commissioning articles and although ISPE/GAMP is a not-for-profit organisation it's important to realise that the lines between not-for-profit and commercial are indistinct in these areas. Another part of the challenge will be to identify appropriate subject matter experts in new technologies who may not be working in the pharmaceutical industry and who may not be part of the existing ISPE/GAMP community.

These challenges can however be overcome and ISPE is certainly moving towards this model, led as so often been the case by the GAMP Community of Practice.

Over the last 21 years GAMP has done an excellent job in providing practical guidance to the industry during what has certainly been the greatest period of technological change industry has seen. The fact that this has been led by volunteers (of whom both I, and Business and Decision Life Sciences are proud to be part) is perhaps one of the most amazing parts of the GAMP story. The fact that this extended community has developed good practices behind which most regulated companies and regulatory agencies now stand is a significant achievement and certainly one to be celebrated.

Happy 21st birthday GAMP - and here's to many more!

Practical Risk Management - Webcast Follow Up

Thanks once again to those of you who joined us for yesterday's webcast - the second stop on our "virtual book tour" which looked at practical risk management. We had a good number of questions asked as part of the registration process which we handled in yesterday's webcast (you can watch a recording of the webcast and download the slides here) but unfortunately we didn't have time to answer all of your questions that were asked during the session.

As usual, we taken the time to answer the outstanding questions here on a life sciences blog.

Q. Can you say more about regulators who are worried about misused risk assessments?

A. During the webcast we mentioned that the number of inspectors from European and US regulatory agencies had commented that they have concerns about the quality of risk assessments and the resulting validation. This comments have been made during informal discussions and in one case at a conference.

Their concern is that the resulting validation is either not broad enough in terms of scope or not rigorous enough in terms of depth and that this has been uncovered during inspection of what they believe to be relatively critical systems. In a couple of cases inspectors have commented that they believe that this is a case of the companies involved using risk assessment as an excuse to reduce the level of effort and resources applied in validating such systems.

We know from their comments that in a number of cases this has led to inspection observations and enforcement actions and it appears that a number of regulatory inspectors are in their words "wise to the trick". As we said in a webcast yesterday is important that the scope and rigour of any validation is appropriate to the system and the risk assessment is used to determine which areas and functions in the system require greater focus. The objective of risk-based validation is not to simply produce a level of effort and expenditure but ensure that the efforts and resources are applied most appropriately.

Q. How much time and effort can be saved by using the right risk assessment approach?

A. Our experience is that by using a relative risk assessment process rather than a quantitative risk assessment process it is possible to reduce the time and effort spent on assessing risks by between 50 to 75%. We have also studied the outputs of both types of risk assessment process on very similar systems and it is encouraging to note that in many cases both processes have provided very similar outputs in terms of the distribution of high, medium and low risk priorities both in terms of the relative number of each risk priority grouping and the functions allocated to each group.

This means that for enterprise systems with lower risk it is possible to reduce the time spent assessing risks by half or three quarters and still come up with results which are sufficiently accurate to support appropriate risk-based validation. This is why it is so important that regulated companies have a variety of risk management processes and tools available to them so they can use the most appropriate and cost-effective approach.

Q. When would you use a quantitative risk assessment approach? For what type of systems?

A. You would typically use a quantitative risk assessment approach where it is necessary to distinguish low, medium and high risk impact amongst a variety of requirements or functions that are all or are mostly of high GxP significance. In this case a quantitative (numeric) approach allows you to take a more granular view and again focus your verification activities on the requirements or functions which are of the highest risk impact.

Typically these will be systems which are safety critical and while this approach could be very useful in terms of manufacturing systems, in terms of enterprise systems we see this approach being used to the most critical systems such as adverse event systems (AES), LIMS systems used for product release, MES etc. Even with these systems quantitative risk assessment can be used on a selective basis for those modules which the initial risk assessment determines to be most critical.

Q. Who should conduct the risk assessment of EDMS system supporting the whole Enterprise?

A. Risk assessments cannot be conducted alone. This was a key points bought out in this week's GAMP UK meeting where we ran a risk assessment exercise and it was clearly valuable to have a variety of opinions and experience feeding into the process. You need people who understand the requirements, the business processes and the resulting risks to give their expertise with respect to risk impact.

You also need technical subject matter experts from the engineering or IT group who are much more likely to understand the risk likelihood. Both groups can contribute to thinking about risk detectability, either in terms of detecting risks within the system or as part of the normal business process checks.

It is therefore very important to invite the right people with the right breadth and depth of knowledge to any risk assessment exercise and to allow sufficient time for the relevant risk scenarios to be identified and assessed.


Thank you as ever for your interesting questions - we hope we find the answers above useful. Remember that you can join us on 17th October when will be looking at the very thorny issue of validating enterprise systems in the Cloud  as Software-as-a-Service (registration is free and is open here)

Global Outsourcing Conference Report

Over the last three days we've been taking part and presenting at the third Global Outsourcing Conference, jointly organized by Xavier University and the US FDA.

Although not the best attended of conferences this year, it proved to be one of the best in terms of content presented and the quality of the invited speakers, including a couple of key note addresses from senior members of US FDA. This resulted in some very interesting and beneficial discussions amongst the attendees, all of whom have taken home some thought provoking material and ideas for implementing positive change in terms of better securing the supply chain, assuring product and patient safety and in optimizing the performance of their extended enterprises.

The conference looked at a wide range of outsourcing and supply chain issues, ranging from the pragmatic management of outsourcing and supply chain management best practices, with a mixture of practical best practices from the pharmaceutical industry and research and experience from a number of leading Universities working in the field (presentations are currently available on the Xavier GOC website).

Of significant interest were the FDA presentations looking at the implications of the recent FDA Safety and Innovation Act (FDASIA - due to be signed into law next month) and the changes that this will have in terms of changes to GMP and GDP regulations.

There was a significant interest in the topic of serialization and ePedigree - which was covered in a number of sessions and signs are that companies are now realizing that rolling these solutions out will be necessary and more difficult than originally envisaged when compared to simpler pilot studies.

Supplier selection, assessment and management were also key topics with the focus on developing partnerships and relationships as the best way of meeting forthcoming regulatory expectations for the management of suppliers.

Business & Decision presented a deep dive session on the future challenges faced by ERP System and Process Owners, looking at the need to integrate with serialization systems, master data management systems, and supply chain partners systems. Acknowledging that many ERP systems were never designed to handle such a level of integration, the session looked at how middleware solutions such as Business Process Management solutions and SOA can be used to better integrate the supply chain.

Outsourcing clearly isn't going away and although some companies are looking to in-source some strategic products and services once again, the issues associated with outsourcing cannot be ignored. Although examples from India and China were much in evidence it was also acknowledged that outsourcing risks do not solely exist in so-called 'emerging economies'

This issues exist not only with product (API, excipients and other starting materials), but also with services such as IT services and it is clear that the US FDA expect companies to better manage their suppliers and supply chain.

For pharmaceutical companies looking to get involved in the debate there is the opportunity to follow the discussion on-line in the LinkedIn "Xavier Pharmaceutical Community".

In summary, the conference provided pharmaceutical companies with a comprehensive list of the topics they will need to be address in the next 1 - 3 years, which now need to be developed into a road map leading to on-going compliance, improved product and patient safety and more efficient and cost-effective supply chain operations.

Validating Enterprise Systems - Questions Answered

Thanks to those of you who attended the first session on our 'virtual book tour' - in which we looked at the some of the basics of validating corporate applications, based on the the book "Validating Enterprise Systems: A Practical Guide"

A number of people submitted questions before the webcast which we answered during the session and we also had time to answer a couple of questions submitted at the end of the session. You can see a recording of the webcast and download a copy of the slides at the Business & Decision Life Sciences website.

There were however a couple of questions that we didn't get around to and as usual we've addressed them here:

Q. What challenges to you see for Enterprise Systems in the next five years?

A. Over the past five years we've seen the functional footrpint of systems such as ERP, CRM, LIMS, PLM etc being extending beyond their traditional boundaries (as discussed in the webcast). However, even where business processes are extending beyond traditional 'silos' in the business, the extended business process is still very much within the enterprise.

We are already seeing Life Sciences companies struggle to extend their business processes beyond their own boundaries and this is becoming even more important as companies collaborate and outsource more. (I'm talking about this very issue at the Xavier / FDA Global Outsourcing Conference next week).

Enterprise systems will therefore need to be capable or orchestrating business process and consolidating data from across the extended enterprise - meaning across business partner, supplier and even customer processes and systems. While the tools and technical standards exist to start to do this today, very few companies are actually taking this step and it is an area which promises true business advantage.

Q. How do you see the use of Service Oriented Architecture changing the game with respect to validation?

A. This is really linked to the previous question. SOA - and Business Process Orchestration- is one of the enabling technologies that allows end-to-end business processes to be defined, monitored and optimized both within the traditional enterprise boundary and across the extended enterprise.
These changes will bring compliance and validation challenges.

Key regulatory business processes - such as adverse events management and product recall - will need to be coordinated across the extended enterprise. This will require validation of the end-to-end business process as well as the computer systems validation of the individual applications and Middleware / SOA components.

Like the technology, the techniques for this already exist but relatively few organizations know how to achieve such compliance efficiently in complex organizations and with such integrated architectures. This will be a challenge both to business process owners, to IT and especially to Quality and IT Compliance and CSV professionals, who sometimes tend to lag behind in applying well established principles to new technologies. It's therefore important that we keep up not only with the changes that have taken place over the past five years, but with the changes that are still to come.


In the next stage of the 'virtual book tour' we'll be looking at how the approach to risk management has changed in the last five years - we hope you'll be able to join us for that session, which is on 3rd October (registration is available here)

Parameterised IQ Protocols

Another question from the 21CFRPart11 forum - not strictly relating to ERES, but interesting all the same:

Q. I am wondering about a project and how the FDA could see it as a validated way to execute qualification protocols.
 
There is the idea: we validated our document management system, where we validated the electronic signature, and the documents could be developed as pdf forms, where some fields are able to be written... and in this case, we could develop our qualification protocols as a pdf forms, with the mandatory fields for protocols, able to be written, and filled with the qualification info.

Is this a situation which FDA could see as a correct way to develop and execute protocols?

A. There should be no problem at all with the approach, as long as the final protocols (i.e. with the parameters entered) are still subject to peer review prior to (and usually after) execution.

We do this with such documents and we have also used a similar approach using HP QualityCenter (developing the basic protocol as a test case in QualityCenter and entering the parameters for each instance of the protocol that is being run).

The peer review process is of course also much simpler, because the reviewer can focus on the correct parameters having been specified rather than the (unchanging) body of the document.