Category: Uncategorized

IT Project Management: A Validation Challenge

IT Project Management: A Validation Challenge

Computer systems validation is a procedure performed in every pharmaceutical or medical device company that uses IT systems at the stage of production, logistics or distribution of its products. Creating a new system and its modifications or implementing existing software requires proper project management. There are two approaches to this type of process prevalent in IT projects, namely the traditional and agile management. This article looks at the differences between the two methodologies and their advantages from the validation point of view.

The main issue is an approach to conducting projects involving the validation of computerized systems in the pharmaceutical sector. Due to serialization requirements, many pharmaceutical firms will be bound to implement some completely new software. Projects are usually delivered using either a classic waterfall or agile methodology. The question is, what are the differences between those two and when do they prove to be more effective?

With traditional methodologies, such as Prince2 or PMI, we divide a project into individual stages (analysis, design, execution and implementation). Since each phase must be completed before the next one begins, they are often called cascade projects. The project is executed according to a precise scheme; its functionality and requirements are well-known and all its areas, such as its duration, measurable business product, resources, organizational structure, including roles and responsibilities necessary for project management, are precisely defined. The project is delivered as a whole. This methodology is characterized by a strict sequence of stages. If the preceding phase has not been satisfactorily completed, the next one cannot begin. It is necessary to go back to the previous stage and make certain modifications to achieve the expected result.

In contrast, in the agile methodology such as Scrum, the plan is also defined, but everything else is flexible. The team itself is responsible for organizing and assigning tasks, and the project is completed stage by stage. Throughout the project, new needs may arise that the team can follow. The scope must be defined both in the agile and cascade projects and it may be identical, but when there is a need to modify the project or the schedule, the difference between the methodologies is clear. In agile methodologies, we have instruments that allow us to modify this scope quickly and easily. In the classic approach, we also have such procedures at hand, but they are time-consuming and require much more commitment. It is also worth mentioning that implementing a project using the waterfall approach requires more time, which usually leads to higher costs. This also entails the necessity to repeat individual stages when there are no effects or when the effects are not the ones that were expected, which, consequently, will lead to downtime.

Another methodology that should be mentioned here is the hybrid agile project management, which combines control mechanisms known from traditional methodologies, such aspects as risks, budget, time and quality, but the paradigm is the continuous collection and discovery of new requirements and following the change.

How do these differences reflect on project validation processes?

Let us agree that validation is a rather rigid method, which requires certain procedures and instructions and is nowhere near flexibility, which probably in many projects would be helpful. We can say that it is a typical cascade process and from our perspective, it is this constant variability in agile methodology that is a challenge, especially from the point of view of documentation and testing. In agile projects, it is both important and problematic to set up our validation rules to avoid too much “distortion” of the agile approach. That means we need to leave the possibility of flexible defining or changing the scope of the project, but on the other hand, we have to observe the formalities required in the validation process, namely to develop a risk analysis and to supervise the risk in the process, to plan the scope of validation work and the scope of tests, to define and develop the required technical documentation without the risk that something has been omitted or, for example, that the scope of tests has been inadequate.

You should also note that there are so-called hard-gates in the validation process that must be met before moving on to the next stage. For example, specification documentation (URS, FS, DS) must be developed before testing can begin. For instance, in agile methodologies, the dynamics of changing functionalities directly affects the documentation, which in turn translates into testing. From my perspective, the whole art of validating agile projects lies in building such an approach or validation model so that completing the formalities one way or another does not block the flexibility of changes in the project.

If the project is too simple to be broken down into smaller phases, i.e. so-called sprints in Scrum nomenclature, it is hard to talk about an agile project. Breaking a project into sprints means gradually adding functionality, which is closer to the client’s requirements from sprint to sprint. In the waterfall project we plan everything from A to Z (first of all, what the final product should look like), we go through the various stages of production and we deliver and check the final product right away, while in agile methodologies we deliver individual elements or functionalities that make up the whole. It is wrong to assume that in agile methodology the plan is improvised, because generally each action is defined and contrary to what it may seem, some agile methodologies also make use of deadlines, i.e. we have the so-called time boxes. In the Scrum methodology, each phase of work, however small, such as an iteration or a sprint, is rigidly defined. Tasks are performed precisely and all our results are verified on an ongoing basis. It’s certainly easier to verify the performance and results after each sprint because if you identify bugs in the delivered functionality from the last sprint, you can implement an improvement after the bug was identified, or schedule a fix for the next sprint. From a software development point of view, for example, this is a very big advantage. From a validation point of view, it complicates the whole situation.

Does this mean that within an iteration or a sprint, validation tasks can be carried out alongside the agile process of the whole project?

It depends on what phase the project is in. It often happens that these initial phases, when, for example, the environment is being prepared and the backend and configuration code are being created, do not contribute much to the whole and from the validator’s point of view can be lost. I have come across two approaches in this situation. In the first one, the validator is involved in the project from the beginning and starts his activities in 2/3, 3/4 of the sprint, for example checking the documentation or validating the application code. He stays on top of it and gives feedback, comments or what has been done wrong from a validation point of view. The validator has control over the entire development process on an ongoing basis and can verify individual stages or functionalities. The risk that the final product will be incompatible with business objectives and requirements and the whole process has not been conducted by the rules, regulations or good manufacturing practice is minimized. Of course, there are also disadvantages of that solution, for instance certain functionality, which was created during the sprints, is often absent in the final product because it has been abandoned. That is contrary to the validator’s approach because his role is to ensure that the solution is consistent with the business goals or specifications. In the second approach, the validator gets involved with the project in its final stages, let’s assume it to be 80% of the delivered functionality. He starts validating and working with the person responsible for the documentation, for the source code, and gets the documents that are needed at the end of the project.

The latter approach obviously has a very serious con. If everything has been done correctly, nothing is missing from the documentation, there are no mistakes and no defects, then the validation process goes smoothly. But if there are complications, deficiencies or defects, validation takes longer and has directly affected the delivery of the final validated product. A far better model is to involve the validator in the project from the very first stages, albeit to a lesser extent.

So, when should a validator or a team of validators start their work in the case of software development or implementation of the project in a pharmaceutical company?

The later we get involved in the project, the worse. The worst option is to include validation right before the tests themselves because in practice this means the most work for everyone. On the one hand, for a validation project to start, a document such as risk analysis or a validation plan has to be created. Even if we are talking about the agile methodology, or Scrum to be precise, we should get involved at the very beginning, with the risk analysis. The validator should have a say in developing such things as the test strategy, when the tests are performed, what tests are performed, what documentation is created during the project, whether it is kept meticulously, what the working environments are, what the implementation should look like, in what environments, and much more. Even if most of the validator’s job is taken into account in the testing and pre-implementation phase, our involvement in the early phases of the project will be helpful. Joining the project, later on, may lead to delays or entail a lot of additional work and costs that will be necessary to make the project compliant and meet regulations, of course when we talk about the need for validation. I am sure it is no secret to anyone that it costs the least, both in terms of time and commitment, as well as in financial terms, to amend a project at the beginning.

Including validation at the very beginning is crucial, because the project team should know what is going on and what is expected. The mere fact that there is no scope or plan of the project yet, is not a matter of agile methodology, it is a result of bad project organization. It is sometimes misunderstood in the case of IT projects that if the project is carried out using agile methodology, certain issues can be approached more freely, e.g. the documentation will be written later or plans will be made later. This is not the case. The scope of the project and its implementation plan must always be known, documented and written down. The documentation must also be provided. As I said at the beginning, the only difference is whether we can break it down into phases and whether we have procedures or functions that allow us to make these modifications.

Let’s assume that a project is being implemented in the agile methodology, but during one of the stages, a defect or non-compliance with the documentation appears. What happens then? Is the sprint or phase terminated when the functionality works? Is there any procedure for that?

We should refer here to the Scrum methodology. Sprints are usually two-week stages, during which specific tasks are planned. After each sprint, you have to present the effects, successfully complete tasks and identified errors (which need to be corrected). After the progress of the project is presented, another meeting is held with the business department to plan the scope of the next sprint. At this meeting, detailed requirements can be discussed, and any doubts as to how the requirements will be implemented can be resolved. If there are bugs, fixing them is included in the plan. In Scrum projects, no sprints are planned from the beginning to the end of the project. To put it simply, a Scrum project is a set of individual tasks that must be completed throughout the project for the final product to be formed as intended. However, the number of sprints often increases during the project because of the bugs that need to be resolved or new features that need to be added. During the sprints, certain tests in the project should also be scheduled, so that it is possible later on to prepare the documentation,, report the progress and the detected bugs, and plan to correct them.

This is also the difference between waterfall and agile methodologies. In traditional methodologies, the occurrence of a critical problem stops the project, because you have to do the tests before you can implement the whole project, so no project may begin until the problem is solved. In Agile, this doesn’t necessarily mean that the project will end up at a standstill. If a given sprint or iteration doesn’t affect other phases or functionalities (and it often doesn’t, because the next stages are only being planned), then one team can work on solving the problem, while the other one carries out other tasks. But in principle, we know about problems or bugs on an ongoing basis.

Also, from a validation perspective, Agile projects should be approached more flexibly, but still within good manufacturing practices. The general guidelines for validation, whether for traditional or agile methodologies, are identical. The key is to choose the right tools to enable the validation process in a “changing environment”. For example, instead of using traditional documents, you can build documents in modules or introduce intermediate revisions (not just major versions) to allow more frequent updating. In fact, it all comes down to the methods of documenting and later approving documents before individual phases. Poor documentation, even in the case of a traditional approach, can ground a project, especially an Agile project. Apart from documents, it is of course important to look at the testing phase and, again, to see whether only parts of the system can be verified during individual sprints. To make sure that the whole system works properly as an integrated whole, you can plan for a regression test phase at the end of the project or end-to-end cross-sectional tests throughout the whole system. With good planning, such tests can be automated beforehand, which will also speed up the whole testing process.

So which methodology is best to choose for validation projects?

The best solution is to carry out the project in a hybrid methodology, for example, AgilePM, i.e. when the main phases will be conducted traditionally with all formal requirements preserved and broken down into the lowest phases, i.e. those groups of tasks that can be divided into iterations specific to the Agile methodology.

With any project, it is very important to have a good work organization, a work plan, a schedule and a flow of information so that everyone involved knows what they are responsible for and they know the project progress. This minimizes the number of mistakes that can happen. It is also important to cooperate with the ordering party and support its close involvement in the project. The exchange of information between the ordering party and the project team is then definitely better and it is certainly easier to deliver a project that is 100% compliant with the expectations in a shorter time.

Agile methodologies are not a cure for all ills, but they can sometimes speed up a project. Before starting a project, it is important to carry out an analysis of the project based on, for example, a requirement analysis, which will give an idea of how this project can be led. From the point of view of validation processes, whatever methodology is chosen, an important aspect is to involve the validator from the beginning of the process so that their comments and recommendations, as well as the work to be done throughout the project, can be taken into account. This will save everyone time and eliminate downtime, which is what not only the client but also the contractor is most concerned about.

Are you ready for the MDR? This is how new EU regulations may impact medical device producers

Are you ready for the MDR? This is how new EU regulations may impact medical device producers

Medtech companies are facing major compliance challenges. As of May 26, 2021 new Medical Devices Regulation goes into effect and previous directives cease to apply. European Union expects full adherence across all its member states. Find out what this means for your company.

The importance of medical devices in the health systems across the world is rapidly growing. European Union, with its aging population prone to greater health risks, is seeking to further regulate the MedTech industry with a focus on patients’ safety. New rules contained in the Medical Devices Regulation (MDR) require increased vigilance in preventing medical device malfunctions and adverse events. In general terms, the emphasis is on product lifecycle – not merely getting it to the market. This means, obtaining approval is not enough. Manufacturers face the effort of retaining it as well.

Transition from the MDD to the MDR. Timelines and transition periods

The MDR is hardly news for the industry. It came into force on May 25, 2017, along with the in-vitro diagnostics regulation (IVDR), marking the start of the transition period for manufacturers distributing medical devices to EU markets to update their technical documentation and processes for the new requirements. The MDR was scheduled to apply from May 25, 2019 but the date was postponed by one year due to COVID-19-related disturbances.

New regulations repeal the rules comprised in three EU acts which have been in place for over 25 years: Medical Devices Directive (MDD, Directive 98/79/EEC and Active Implantable Medical Devices Directive (AIMDD). The latter is integrated into the MDR in an expanded form. The new law comes with 42 implementing acts and 12 delegating acts serving to either clarify or modify the regulations.

The shift in legal framework is mitigated by additional transition periods. New regulations allow for certificates issued under the MDD and AIMDD directives to remain valid until May 25, 2024 under specified conditions, while MDD devices already placed on the market may continue to be made available until May 27, 2025.

MDR: more efficient and transparent regulatory framework

Compared to the previous acts, MDR provisions have more substantial implications and introduce changes that will be deemed as laws – similarly to FDA medical device regulations. The document is also longer and more detailed (174 pages of MDR vs 60 pages of MDD). In essence, MDR is designed to align EU law with technological advancement and progress in medical sciences. It aims to provide an efficient and internationally recognized regulatory framework that will improve patients’ safety, at the same time creating transparent market for the medtech companies from around the world.

Key regulations and requirements for medical device manufacturers

The crucial requirements manufacturers need to comply with are covered in Article 10 of MDR titled “General obligations of manufacturers”. Key points of the new regulations include:

– a new device identification system based on a unique device identifier (UDI) that will facilitate traceability of medical devices,

– an obligation to mark devices with a device identifier (DI) and each batch or production series of the product with a production identifier (PI),

– an ‘implant card’ for patients containing easily available information about implanted medical devices,

– random inspections of manufacturers’ facilities after devices have been brought to the market,

– more rigorous controls on notified bodies, which will have to employ medically skilled people,

– an additional safety checking procedure for high risk devices, conducted not only by a notified body but also a special committee of experts,

– safety requirements for previously unregulated aesthetic products which pose a health risk to consumers, such as colored contact lenses not applicable for vision correction,

– the requirement to provide clinical evidence of medical device safety by manufacturers (as for medicines), especially in the case of higher risk classes.

EUDAMED –  European database on medical devices

The MDR also establishes a set of databases covering, apart from registrations, post-market surveillance and risk management. Data on products, their IDs, manufacturers, related clinical investigations, are to be stored in and made accessible via EUDAMED –  IT system developed by the European Commission to implement MDR, which will provide a living picture of the lifecycle of medical devices distributed in the European Union.

What are the main challenges for medical device producers?

Medical device companies may experience challenges with adapting to the new legal environment introduced by the MDR. Possible issues include:

– greater than budgeted costs of compliance,

– time and personnel engagement necessary for implementing changes,

– implications on the supply chain (business partner may decide to quit the EU market),

– additional, potentially costly responsibility with regard to data requirements,

– weighing the cost of compliance against revenue with a possible outcome of having to withdraw some products from the EU market.

There are plenty more issues to consider, both in terms of compliance and business goals, for medical device manufacturers facing the pressure of new regulations. If you wish to discuss the implications of MDR for your company, don’t hesitate to contact us via phone or email. Our experts will be happy to help you!

 

From CSV to CSA – what should you know about the new validation paradigm?

From CSV to CSA – what should you know about the new validation paradigm?

Validation is going through a paradigm shift. The new way of doing things is called Computer Software Assurance (CSA). It’s founded on critical thinking and intended as an improvement on the long-standing Computer System Validation (CSV) standard. Feeling confused? Don’t be. We’re here to help you through the transition from CSV to CSA the smoothest way possible.

This change has been long awaited. Ever since FDA issued its guidance on General Principles of Software Validation in 2002, the volumes of documentation have been growing out of proportion. “Better to be safe than sorry” has become the common approach in the industry, while the focus on improving medical device quality for patient safety has waned. Now, with CSA, the priorities in the validation process have been reordered. While CSV standard – at least in practice – has been predominantly based on documentation, its successor ascribes key importance to critical thinking.

Common issues with CSV

It’s not like things were poorly thought out from the start. The risk-based approach, now encapsulated in CSA, was promoted by FDA already in 2003 and introduced to CSV by GAMP 5 five years later. With sufficient focus on the system functionalities with the highest risk, CSV serves well enough to achieve compliant computerized systems fit for intended use within a regulated environment in an efficient and effective way.

In reality though, the process is all too often overburdened with documentation which consumes roughly 60% of the time required for completing the validation projects. This doesn’t imply CSV is flawed at its core. The problems usually stem from improper execution and misunderstanding of the validation process. Common issues with CSV application involve the following:

– Insufficient cooperation among business experts

– Insufficient understanding of the intended use of the system subject to testing

– Tendency to maximize testing effort, “just to be sure”

– Demands to provide detailed evidence of testing step by step

– Excessive reviewing of documents

Much of the above boils down to insufficient application of critical thinking in the validation process. With CSA, things are about to change. By no means does it make the CSV obsolete. The new paradigm is rather restructuring than recreating the validation methodology, so that it can help achieve the desired objectives in a more rational and efficient way.

CSA vs CSV – new hierarchy of priorities

The critical thinking underlying CSA model switches the focus from zealous effort to document every action to:

– impartial fact analysis

– pattern identification

– trend assessment

– evaluating outcomes

Combined with a risk-based approach, critical thinking serves to aim the validation effort at the features of the system that are critical to patient safety, product quality, and data integrity. Thus, the central questions the validation team should be able to answer with perfect clarity are:

– Does this software impact patient safety? 

– Does this software impact product quality? 

– Does this software impact system integrity?

CSA – critical thinking for better risk assessment

Combining critical thinking with proper risk assessment allows to address the assurance needs in a proportionate manner. Consequently, the issues requiring more attention won’t be neglected in favor of those of lesser importance, as often is the case with poorly performed CSV. As opposed to its predecessor, CSA results in higher confidence in system performance, rather than excessive documentary records covering even low-risk features where little action is required.

CSA provides not only more reasonable but, in a way, more holistic approach. While CSV focuses on individual steps in a system, the new model aims at understanding the overall business process, in order to better assess the risks involved and apply adequate testing. Therefore, successful CSA completion is highly dependent on seamless collaboration between the experts – skilled professionals knowledgeable about the business processes subject to analysis and testing.

While the “human factor” is crucial, CSA also relies on more extensive use of new technologies, especially automated test tools and systems for digital management of test documentation.

Smooth transition from CSV to CSA paradigm with ecvalidation experts

Essentially, CSA is not about retiring “outdated” CSV standard. It’s about unlocking the potential of a critical mind and collaborative teamwork, as well as overcoming the anxiety related to the responsibility of risk management. As ecvalidation, we’ve completed hundreds of validation projects and have been perfectly aware of potential shortcomings of CSV model.

However, in our individual approach we have always adhered to FDA recommendations regarding the role of risk analysis in validation. Hence, we gladly welcome the transition to CSA paradigm, and perceive it as a valuable upgrade on the previous model. As a result, we’ll be happy to provide assistance to any company interested in smooth implementation of new standards in the validation process.

Computer System Validation – SaaS solutions

Computer System Validation – SaaS solutions

One of the increasingly popular forms of cloud computing are so-called SaaS services, or Software as a Service. This solution is based on the assumption that applications and databases are installed on the provider’s servers, and access to applications is usually provided through a website. The most popular applications of this type include: OneDrive, SalesForce.com, Google Apps, Concur, and Dropbox. The advantage of such an approach is that the Customer gets access to solutions with specific functionalities, without having to invest in IT infrastructure. An additional advantage is that such programs can be accessed through both desktops and mobile devices.

Cloud solutions are also becoming an increasingly popular tool in pharmaceutical companies, including areas deemed as critical to good manufacturing practices (GMP). When we talk about software supporting a critical GMP area, we must of course remember that such a solution will require validation. How can such validation be carried out correctly? What are the potential risks? What kind of cooperation can you expect between the pharmaceutical company and the provider? These are the principal questions, that will be addressed in this article.

Definition of requirements

As in any other case, we should start by preparing the User Requirement Specification (URS). However, when choosing a SaaS solution, it should be kept in mind that apart from functional requirements describing system operation or quality requirements covering GMP aspects, we should particularly consider the issues of data management and data integrity.

We must, first of all, acknowledge that the same solution is already in use or may be used in the future by other companies, including our competitors. This is important because the data will be stored on external servers managed by an external company. If the system is to additionally process personal data, we are entering the area of personal data protection regulations. Therefore, it will be important to specify the requirements in this area in accordance with the internal security and data management policy. When creating the URS, we should at least pay attention to a few of the following issues:

– server location

– dedicated server

– archiving and backup

– access management

– updates, system corrections

– testing

The above issues do not, of course, exhaust the whole range of questions and requirements that can be posed to the SaaS system, but they should help to point the way when writing the URS.

Provider Audit

According to the requirements of Annex 11 of the GMP, the IT systems provider must be audited. In the case of cloud solutions, this is particularly important because we entrust the provider with the implementation of the business process, the system and its care, as well as data and its security. It may also be one of the few opportunities to analyse the provider’s quality system in detail.

Satisfactory responses of the provider to the requirements defined in the URS must be verified and confirmed at this stage. To this end, the provider must be verified with regard to whether they have appropriate procedures in place, whether these procedures are implemented and applied in practice, and whether their staff is adequately trained. From the perspective of the client – a pharmaceutical company – one of the key points of the audit should be the verification of validation documentation and, if the provider does not have such documentation, then the verification of technical and test documentation. Another key audit point should be the aspects related to system security, starting from the verification of system architecture, through encrypted communication protocols, to the verification of penetration tests.

It should be kept in mind that according to GMP regulations, the final responsibility for the business process always falls to the pharmaceutical company, even when the process has been delegated to the provider as a part of the Software as a Service solution. Taking this into account, the provider audit is a critical element of the solution validation process.

Software as a Service solution validation process

As a rule, the SaaS solution validation process should not differ significantly from the validation of other computer systems owned by a pharmaceutical company. Therefore, if the company has defined validation procedures in this area, they should be applied. Below is an example of one of the possible approaches. An example of a validation process is presented in the diagram below:

Risk Analysis – the risk analysis process should commence with the start of the validation process, and all subsequent activities (qualification and its scope, scope of tests, required documentation, etc.) should be planned and performed based on a “risk-based approach”. Various tools can be used for risk analysis, some of the most popular are FMEA and Expert Assessment, which will also work well in this case.

Validation Plan – based on the conducted risk analysis and the results of the provider’s audit, a validation plan should be developed, which should take into account all the key stages of the process, while also taking into account the specificity of the SaaS solution. This mention of the provider’s audit result is not a coincidence, because the conclusions of the audit will strongly influence which actions should be planned for implementation on their own, which actions should be given to the provider for implementation, and which actions can be omitted because they are already being implemented by the provider.

Documentation Preparation – the pharmaceutical company is responsible for the development of the User Requirements Specification, while other technical documentation (Functional Specifications, Technical Specifications, description of system architecture, description of configurations, interfaces and others) should be developed and provided by the software provider. In order to verify that the provider’s documentation properly covers the URS, the preparation of the Traceability Matrix can be started at this stage. The Traceability Matrix is part of the pharmaceutical company’s validation documentation and is designed to demonstrate that user requirements have been implemented in the system (the connection between the URS and the corresponding Functional Specification) and that they have been properly tested (the connection between the URS and the corresponding tests).

Infrastructure Qualification – validation tests must be carried out on qualified infrastructure. The software provider should at this stage provide qualification documentation for servers (at least a test and production server). Without confirmation of infrastructure qualification status, validation tests should not be started.

Performing validation tests – the scope of tests, approach to testing, reporting rules and error assessment criteria as well as the method of documentation should be described in the test plan. The tests can be divided into two groups: IT Tests (Unit Tests, Source Code Review, System Tests, Integration Tests, Security Tests) and Business Tests (User Acceptance Tests, End-to-End Tests). The provider is responsible for the technical part of the system, so if the audit results in the testing area were positive, then in the case of IT Tests, it is possible to refer to tests performed by the provider. It will be important to verify the available test documentation and the scope of testing. Such an approach significantly reduces the amount of testing on the part of the pharmaceutical company, because only Business Tests will be performed. After the tests are completed, the Traceability Matrix should be completed in order to show that each of the requirements has been properly tested. Finally, a Test Report summarising the results should be prepared. All errors reported during testing and their current status should be verified. Errors deemed as critical and important should be resolved before the Test Report is finalised.

Determination of System Maintenance Rules – after completion of all tests and prior to finalization of the Validation Report, system maintenance rules should be established and described. If necessary, appropriate procedures and instructions should be developed and training provided. These actions should also be summarised in the Validation Report and detailed maintenance policies described in a separate Service Level Agreement. Validation Report Preparation – at the end of the validation process a Validation Report should be prepared with a summary of the entire process. If any discrepancies or deviations occurred during the validation process, they should also be described and evaluated. If any discrepancies have not been resolved at this stage, the risk reduction measures implemented and the deadline for resolving open discrepancies should be presented. The Validation Report should include a statement that the object of validation has been approved and released for use in production. All documentation that is produced as part of the validation process must be prepared and approved before signing the Validation Report. This also applies to training materials, procedures, instructions, etc.

System Maintenance – Service Level Agreement

A validated system working within the SaaS solution, like any other, requires maintenance from both the technical and the validation sides. By system maintenance we mean a number of activities carried out by the provider in order to ensure the correctness and continuity of system operation. These activities include: monitoring system operation, making changes, corrections and updates, testing, managing permissions and access, archiving and backup, incident management, providing support lines (helpdesk, 2nd and 3rd lines of support) and others.

From the point of view of the pharmaceutical company, it will be crucial to continuously maintain the validated status, implemented in the change control process, which should combine aspects related to:

– incident and defect management – how defects are handled by the 1st, 2nd and 3rd support line, who opens the incident and when, what the communication channels between the customer and the provider are

– risk assessment – what the assessment criteria are, what needs to be done in case of an emergency notification, how the level of risk translates into further implementation steps, e.g. testing

– document management – which documents and how they should be updated

– testing – how the range of tests is selected, what the testing methods are, how the tests are documented

– training – whether correction or system updates are changing the way the system works and operates, user training is required

This process, in simple terms, should comply with GMP requirements, i.e.:

– formal change requests should be available – this applies to bug fixes, when an incident may be reported, and updates

– each change request should be assessed at least in terms of its impact on the system, documentation and testing; on this basis, an implementation plan should be drawn up together with a list of necessary actions to be taken

– the implementation should be monitored on an ongoing basis in terms of both substantive and qualitative correctness

– finally, the change should be assessed as to whether it has been implemented correctly

Since the system is maintained by the provider and it is the provider who is responsible for the implementation of processes such as, for example, change control, it is crucial that there is a formal service level agreement between the pharmaceutical company and the provider, which will specify the above issues, both in terms of the content of these processes and the principles of cooperation (communication channels, response times, access to documentation, etc.).

Summary

Due to their numerous advantages, SaaS (Software as a Service) cloud solutions are increasingly popular among pharmaceutical companies, also in GMP critical areas. And although the validation required in these cases can be challenging, it seems that the key aspect of the whole process is the choice of the provider, preceded by a detailed audit. However, such a conclusion should not surprise anyone. The quality of the system and its security in this case depends primarily on the provider, their awareness of the GMP requirements and the quality processes being implemented properly. However, it should be kept in mind that when deciding on a given solution, a pharmaceutical company is responsible for the whole validation process and should know how it wants to carry out such validation before deciding on such a solution.

Who, when and how should prepare for the amendment of Annex 1?

Who, when and how should prepare for the amendment of Annex 1?

Introduction

The pharmaceutical industry is characterised by numerous requirements governing its functioning. In my professional history, I have yet to meet an employee of this industry, who couldn’t wait to see an amendment to the Good Manufacturing Practice (GMP) requirements. The next edition of the legislative document is associated with investments, staff shortages, inconsistencies, work load of employees and endless hours spent on risk analysis. When operating in the pharmaceutical industry, it is worthwhile to be aware of GMP trends and not just only the current requirements.

Annex 1 (Manufacture of Sterile Products) to the EU GMP regulations (EudraLex Volume 4) is currently under revision. Do we already know when the finished document will be introduced into the legislation of the Member States? What final form will it be implemented? Unfortunately, we do not know that yet. Is it worth taking an interest in the current form of drafts? Definitely!

Which manufacturers should be interested in amending Annex 1?

Annex 1 is essentially about the manufacture of sterile forms of medicines. However, some of its provisions (e.g. requirements for room finishes, testing of the classification of premises, pressure cascades) are used by manufacturers of non-sterile medicines. This is because the remaining provisions of the law lack the necessary details and clear requirements. In the current draft, we can find unequivocal information that some of its provisions may be implemented in the quality system of a manufacturer of non-sterile medicines. This mainly concerns the products that are particularly vulnerable to contamination during production.

A company’s vast human resources are involved in the creation of a Quality Assurance System (QAS), which should meet all legal requirements, be easily understood by employees and allow the product to be marketed as efficiently as possible. In addition to the so-called hard law – uniform in the European Union, translated into national languages, there are also regulatory lower-ranking but more-detailed documents. These are Q&A issued by EMA, ISO standards, guides (e.g. issued by ISPE), WHO guidelines and many others. The latter documents often precisely describe how the vaguely written requirements of hard law can be met. Although the draft of Annex 1 is 40 pages longer (initially, it was 12 pages, and 52 pages were proposed in the final version), it does not necessarily mean a revolution in the currently operating plants. If we look in detail at the proposed provisions in the draft, we get the impression that the vast majority of these requirements have been already met by these companies. The new provisions combine the requirements of existing law with components of so-called soft law, containing both specific and working details.

What modifications to the requirements have been proposed in the current draft of Annex 1?

Apart from the more precise provisions, the following changes should deserve special attention:

  1. A much greater share of risk management methods are established. Every activity related to sterile production should be designed using risk management methods. Risks should also first be limited by reducing the harmfulness and frequency of errors, and only in the second wave should the methods of error detection be increased.
  2. A new type of risk analysis has been introduced – Contamination Control Strategy (CCS). This document is quoted in a new draft in many different areas. CCS should be implemented throughout the plant to define all critical control points and assess the effectiveness of all control measures (design, procedural, technical and organisational) and monitoring measures related to contamination control. All contaminants, including microbiological, endotoxins, pyrogens and particulates, would be the subject of this document. It has been clearly stated that the document is to be “living”, i.e. it should change as the knowledge and awareness of the manufacturer’s personnel increases.
  3. Tests were imposed to visualise airflows. Visualisation of the effectiveness of pressure cascades, RABS systems, and tightness of premises (Containment leak testing) will be required. Previously, these requirements were part of EN ISO 14644-3. Films from the aforementioned smoke tests should cover both resting and operating conditions. However, the conclusions from the tests carried out should be taken into account when designing microbiological tests (including routine monitoring and qualifications).
  4. The concepts of “at-rest” state and “in operation” state have been developed. The “in operation” state should include the maximum number of personnel and the ongoing process or its simulation and the worst case of processes conducted in the room. Seemingly intuitive recording entails additional work. It involves selecting the worst case during the “in operation” tests and proving that such conditions were maintained during the PQ execution.
  5. Minor differences have been introduced in the scope of airborne particle testing during qualification and monitoring. The requirement to set empirical limits for particles in zone D during operation merits interest. The current Annex 1 requires only testing of the particles in class D at rest.
  6. A requirement has been introduced to determine the number of sampling points. It should be based on a documented risk assessment, including classification results, air visualisation studies and process and operational knowledge.
  7. The minimum scope and frequency of re-qualification of class-designated premises has been set.
  8. In addition to the information on the rotation of disinfectants, the use of sporicidal was recommended.
  9. The effectiveness of disinfectants must be proven in a worst case validation. The scope of this validation is very similar to the microbiological part of the validation of cleaning of production facilities and cannot be replaced by simple monitoring.
  10. Clothing management processes in clean rooms should be qualified.

What to do with knowledge of trends in GMP?

Is it worth preparing yourself for the new Annex 1 draft right now? In fact, this is still a law project, which is still being evaluated by organisations and associations of industry professionals. Once a common version has been developed, the final wording may be subject to significant changes. By implementing the proposed solutions, manufacturers risk wasted resources and perhaps found inconsistencies with the current law. Therefore, one of the solutions is to wait for the completion of the legislative process amending Annex 1.

The second possibility is to implement certain solutions right now. Certainly not those which are contrary to the current law. However, it is worth taking into account the evolutionary change in the QMS documents (and, consequently, in the practice of the production plant) already now. During reviews and revisions due to other needs, procedures can be developed in accordance with both the current law and the new draft of Annex 1. A convenient tool to control the whole process of adjusting the plant may be the so-called “Traceability matrix”, where each legal requirement will be assigned to system, organisational and hardware actions. This would make it possible to assess the compliance of the plant’s QMS with the proposed new law and assess the scale of possible work in the event of the need to adapt to the new guidelines. It is worth being aware of the likely legal changes, especially before investments (planned for a dozen or so years) and the qualifications of new areas. By following both the requirements in force and the proposed legal changes, investments will avoid, for example, repetition of qualifications. The risk of this approach is the involvement of human and financial resources despite the lack of formal requirements. The profit may be the spreading of the revolution in the QMS and optimisation of investments.

Annex 1 is being amended. The list of organisations that are currently commenting on the content of the draft is impressive and gives hope that the final wording of the new legislation will be precise and easily understood by manufacturers. It is not certain when the new rules will exactly come into force, but it is a good idea to take an interest in them now. Regardless of whether the manufacturer, by taking a business decision, will already begin to implement elements of the legal proposal or will wait for legal changes, it is worth being aware of the likely legislative changes which will take place in the near future.