Siegfried Schmitt, PhD, is Vice President Technical at Parexel International, Siegfried.Schmitt@parexel.com.

Siegfried Schmitt

Q.  We are a well-established pharmaceutical company, and part of our procurement process requires us to prepare a ‘spec sheet’ (i.e., a document listing our requirements for either the service or the equipment we want to acquire). That has served its purpose well; however, we are finding it difficult to use when purchasing automated systems or software products. As we often have very little expertise or understanding of the software component, we struggle to write sensible specifications. We are tempted to simply accept the vendors’ system descriptions. Do you have any advice for us as to how we can overcome this challenge?

	A. Your situation is not unusual, and the reason, as you already mentioned, often is a certain lack of expertise with software products. Whereas there is a lot of process and product expertise in companies, including processing equipment, the same cannot be said for automation. Let us first look at the parties/departments involved in preparing spec sheets for equipment. This will involve the operations group (e.g., manufacturing department, laboratories, utilities group), engineering, procurement, and the quality unit. When it comes to automated systems or pure software applications, the information technology (IT) department must be involved too. The IT terminology and the engineering and operations terminology are not necessarily the same or aligned, which can make communication more difficult, not only internally, but also with the suppliers. For example, what you refer to as a ‘spec sheet’ is a user requirements specification (URS) in computerized systems terms. The issue is further complicated as we as humans are used to being able to touch, smell, or hear equipment, none of which applies to software.

	Can you simply adopt or accept the supplier’s description of the system or software, or do you need to prepare this yourself? The answer is that even if you were to accept the vendor’s description without any change, you still must confirm this in writing. In other words, the vendor’s description becomes your URS (aka spec sheet). With that, you also become responsible for the URS to be compliant with the applicable regulations.

	In a few cases, you may be at the mercy of the supplier with regard to functionality and performance, but mostly you will have a choice. For example, if you are looking for software to support a quality management system, there are systems available that offer you everything you may wish for. But, you may only want to use certain functionalities (e.g., workflow) and specific modules (e.g., deviations and complaints management modules, but not the change management module). In this case, it would be wrong to merely copy/paste the full system description by the vendor into your URS; instead the URS has to be specific to your needs (i.e., requirements).

	In computerized systems validation (CSV) terms, the URS forms the basis for user acceptance testing (also referred to as performance qualification). This is where it becomes essential that the URS is compliant with the regulations. To give an unacceptable example would be to write in the URS: ‘the screen refresh must be fast.’ This cannot be tested as it is a wholly ambiguous requirement. Another example would be to require ‘an easy-to-read screen.’ But how do you describe this in testable terms if you are not the software expert? This is where your IT team will have to support you and provide appropriate language. For example, they could suggest a refresh rate of 100 milliseconds or recommend a certain screen display quality that will meet your needs.

	Despite its age, one of the best guidance documents for writing a URS is FDA’s 

General Principles of Software Validation; Final Guidance for Industry

 from January 2002 (1). Other agency guidance documents and industry best practices are available online (e.g., 

European Directorate for the Quality of Medicines

 [4], to name but a few). As the use of automated systems will surely increase in the future, it is sensible to build up relevant expertise in-house, so that in future you will be as comfortable writing spec sheets for a mechanical system as for a piece of software.

General Principles of Software Validation; Final Guidance for Industry and FDA Staff

 (CDRH, CBER, January 11, 2002).
	2. EDQM, 

Revised: Validation of Computerised Systems Guideline

EudraLex The Rules Governing Medicinal Products in the European Union Volume 4 Good Manufacturing Practice Medicinal Products for Human and Veterinary Use, Annex 11: Computerised Systems 

GAMP 5 Guide: Compliant GxP Computerized Systems


	Vol. 42, No. 11
	November 2018
	Page: 58

	When referring to this article, please cite it as. S. Schmitt, "User Requirements Specifications–How Difficult Can It Be?," 

Articles

Building up relevant expertise in-house will make writing spec sheets for software easier, according to Siegfried Schmitt, principal consultant at PAREXEL. 

User Requirements Specifications–How Difficult Can It Be?

Q. During a recent audit, we received an observation relating to our incoming goods inspection process in the warehouse. Our current procedure requires us to check for damage and to assure the correct goods are received. We currently do not have a detailed description on how to perform this task, as we find this would be far too complicated to describe. Can you recommend a solution for this?

	A. What you describe is often observed during audits. Let us first analyze why this is the case. Warehouse personnel are usually very experienced and therefore know what to look for when goods are delivered. This experience is shared with new staff members, albeit often on an informal and on-the-job basis. This is not to say that these persons do a bad job, but as you learned from your audit, this process has to be described in sufficient detail, and it must be documented.

	As there will be many different types of packaging for the wide variety of goods that are delivered to a warehouse, you may find it difficult to provide a detailed enough description in your instructions procedure, without it becoming too complex and unwieldy. There are solutions for this, which are a combination of instructions, check lists, and training materials.

	The instructions need to detail what to check, for example:

	- Correct license plate of the delivery vehicle

	- Interior of the delivery vehicle clean, no odors/smells,

	dry (no condensation or puddles), and deliveries orderly

	- In case of wooden pallets, correct treatment stamps applied.

	The above are just typical examples that are often second nature to seasoned staff, which can be detailed on a check list as an attachment to the procedure. Now this still does not provide all the detail your inspectors were looking for. Let us look at the check for the correct license plate of the delivery vehicle. The instruction could be like this:

	• The warehouse operative documents the vehicle’s license plate. To do so, the operative must go to the vehicle and record the plate number on the form.

	• Confirm that his or her license plate corresponds with the information provided by the shipping company. In case of discrepancy, stop the process and report a deviation.

	Now let us take another example: ‘looking for any sign of damage.’ It is difficult to describe in words, what is in reality a visual impression. Therefore, it is best practice to prepare photographs of any kind of damage. These are then annotated and explained. Such a photo library is an excellent training tool; and in fact, this is where this library should be placed.

	This training material can be updated each time a new kind of damage is observed. Of course, version control should be maintained. For example, if the operator has to check a carton’s outer package for damage, there may be a superficial cut or tear. The extent of the damage determines acceptability or not. The warehouse operative will document on the check sheet the type of damage and whether this is acceptable or not. The easiest way to do so will be to compare the observed damage against the photo library and document the reference number from that library. In case of doubt, a picture should be taken and appended to the check sheet. This minimizes ambiguity in the process. Following such an approach-which leverages instructions, check sheets, and picture training materials-should provide you with a solution that is easy to follow, well documented, and above all, compliant.


	Vol. 42, No. 9
	September 2018
	Page: 70

	When referring to this article, please cite it as. S. Schmitt, "Checking Incoming Goods," 

Detailed process descriptions and robust documentation aid in compliance as well as training, says Siegfried Schmitt, principal consultant at PAREXEL.

Checking Incoming Goods

Q: Our company recently acquired several new production sites in Europe, Asia, and the Americas. As part of the integration process, we decided to harmonize our batch records. We appreciate that local regulations and differences regarding the type of production equipment we use may require some local adaptations and deviations from a standard template; however, we are faced with stiff opposition from many sites to change their batch record design. Can you advise on how best to convince everyone of the benefits of a harmonized template?


	
	A:  The integration you describe will without doubt require many changes to the documentation, and therefore, it is a sensible decision to think about harmonizing documents, such as batch records. You are correct that there will be differences in the equipment and the processes, even for the same product by the same synthetic method, but in different facilities. But, this in itself is not an impediment to creating a universal batch record template.

	It is important to consider why batch record templates differ so widely. First, the workforce will be used to different styles of documentation. How much or how little detail do they require to perform a task? It is not unusual to find a 10-page document used for a process in one location to extend to 50 pages for the exact same process elsewhere.

	Next, let us look at the style of the contents: Is it all text? Is there use of pictures or graphics? Is it all in a logical sequence? Is it in one language or in multiple languages? Does it require each page to be signed by five persons for each batch record, or is there just one signature page? All these styles exist, and they all are developed for specific reasons. It is thus important to understand these reasons in order to design a universally accepted template.

	Having the opportunity to completely redesign the batch record template provides a unique chance to build in as many safeguards from a data integrity perspective as possible. This includes removing any ambiguity regarding what must be recorded, by who, when, and how. For example, the instruction ‘add 100 liters 10% NaOH over 1 hour should have fields for entering the actual values that should look like this:

	This technique makes it clear to the operators what fields to complete and how to enter the values correctly. The use of symbols and colors is encouraged (e.g., to highlight critical steps, warn of potentially dangerous substances, etc.).

	This is also a superb opportunity to eliminate the ‘numeritis disease’ (i.e., the unnecessary and time-wasting use of highly complex numbering systems). Step 001 in the batch record should be followed by step 002, then step 003, etc. There is no need at all for having something like step 1.2.5.2.8a.

	Depending on the level of automation in the plants, you may be able to move from paper batch records to electronic batch records. The latter will provide a higher degree of data integrity as much fewer manual entries of data will be required. Thus, the standardization of the batch record can indirectly also drive standardization of the computerized systems in your plants.

	Now let us look at some indisputable benefits of having a standard batch record template rather than a free-for-all: 

		Reviewing batch records for continued compliance with the regulations is facilitated across sites, countries, and continents.

		Extracting information for or verifying concurrence with the submitted dossiers (e.g., for new drug applications, marketing authorization applications, variations, post-approval changes, etc.) is straightforward and simplified.

		Batch record review by the qualified person (as regulated in the European Union) or the quality unit (e.g., for the purpose of batch release or audits) is streamlined.

		Extracting information from the batch records for preparing annual product reviews (or product quality reviews), or for the purpose of benchmarking is effectively repeatable and possible.

	Every day a product can be released to the market earlier because of any of the above benefits can result in monetary benefits. And who is to dispute that advantage in your company?

	In summary, if the regulatory compliance benefits of a standardized batch record template aren’t compelling enough, monetary benefits gained by earlier release of drug product will no doubt make it a straightforward decision. 

	When referring to this article, please cite it as S. Schmitt, "Harmonization of Batch Records" 

Monetary benefits will outweigh the hassle of batch record harmonization, says Siegfried Schmitt, principal consultant at PAREXEL.

Harmonization of Batch Records

Q. We are planning to upgrade several of our automated systems in production and in the laboratories. These upgrades are necessary so that we can implement functionality like audit trails, which are now required to achieve data integrity compliance. We contacted suitable vendors, and some have now offered to sell to us fully 21 

) Part 11 and data integrity-compliant software packages. Such a package seems like a very good deal, but it is not offered by the majority of suppliers. Can you give some insight on how other companies address this situation?

	A. You are in a very typical situation where not all your automated systems are of a technical standard that make compliance with the applicable regulations possible, unless you upgrade or replace certain systems. It is an unfortunate fact that there are still vendors out there who make misleading claims, either out of ignorance, or worse, knowingly. The only party that can legally commission and operate a computerized system in a fully compliant manner is the system owner (i.e., someone within your organization). Only you know how you are going to use the specific system and for what purpose. No vendor can do this for you. Therefore, automated system suppliers can merely offer to sell you systems that are designed and built in a manner that allows you, the customer, to operate them in a compliant manner (e.g., complying with 21 

Part 11 or other regulatory requirements).

	Let me give you an example to clarify this: You may purchase a system upgrade that provides audit trail functionality. Although the vendor gives you an audit trail as you requested, you may choose not to activate it (perhaps because it slows the system down too much). Now you may be in a non-compliant situation. Or, you decide to activate the audit trail, but upon review you find that it is not in human readable form, or that it only captures a fraction of the transaction, or that the amount of data in the audit trail is so overwhelming that it becomes unmanageable.

	Savvy companies have in-house experts with a sound understanding of the regulations covering automated systems, how to perform computerized systems validation, and how to optimally harness the vendors’ expertise. These experts will put together the user requirement specifications (URS) for the various systems. The URS is the document that will steer how the system (or system upgrade) will help you to operate in compliance with the regulations (i.e., what it takes to make sure that data are trustworthy and your system is fully validated). In the URS, companies will specify what they expect from the audit trail (e.g., it must be human readable, sortable, exportable, searchable, etc.). 

	The URS also forms the basis for the testing requirements, namely the testing by the users. Users may be quality unit personnel who need to verify that on an analytical instrument the series of injections for an analysis tally with the method, or that there were no rogue injections. Only these people will know what they are looking for and how they want to perform their review. Your system vendors are now tasked with providing you with a system that meets your needs, and not just a ‘one-size-fits-all’ solution.

	Don’t be lulled into a false sense of security by sales promises; instead, make sure you have experts at hand who can help you select the systems and suppliers who best meet your needs. Once you do this, you will find that validation and compliance even with the most demanding regulations become not only possible, but exciting. 

	When referring to this article, please cite it as S. Schmitt, "Computerized Systems Validation," 

In-house experts can help select the right systems and suppliers, making validation and compliance easy, says Siegfried Schmitt, principal consultant at PAREXEL.

Computerized Systems Validation

Q: Given the current focus on the subject of data integrity in regulatory inspections, we have performed an internal assessment. We found several pieces of equipment, in particular analytical instruments, which do not meet the requirements (e.g., shared user access). We are concerned whether we can continue using this equipment under these circumstances. Can you advise?


	
	A:  Although data integrity is not a new concept, it is true that there has been an increased focus on data integrity in inspections by regulatory agencies globally, and this is very likely to continue unabated. You certainly did the right thing by assessing your current compliance level, which, it turns out, is not in substantial compliance with the regulations.

	First, you must determine whether is it acceptable to continue to use these non-compliant systems for the manufacture of pharmaceutical products, and if so, under which circumstances. The regulators encourage a risk-based approach to compliance, though this must not be misinterpreted as being allowed to be non-compliant, rather, this compliance approach requires you to perform a risk assessment (i.e., you need to ascertain the risk to the patients should you continue using your out-of-compliance equipment).
	Take for example, a tablet press that has been in operation for 15 years, which is in perfect working order and has no access controls. Anyone working on the machine can change the parameters and edit the stored data. This is not an acceptable situation. Preferably, one would implement technical solutions (perhaps a software upgrade), but where this is not an option or would take too long, one needs to consider procedural remedial actions. In this instance, this could include the verification of the settings by a second person, plus an amendment to the operating procedure, which would clearly define acceptable and unacceptable data handling (e.g., changing parameters). If neither technical nor procedural solutions lead to an acceptable risk level, I’m afraid, this piece of equipment must no longer be used.

	Another example would be the use of a laboratory information management system (LIMS) by several operators sharing a user ID and password. If this is the case because of cost savings (purchasing a minimum number of licenses only), then this issue can be remedied almost immediately by purchasing the appropriate number of licenses and revising the operating procedure to mandate individual user IDs and passwords for all LIMS operators.

	You did the right first step (i.e., assessing the as-is situation); however, you should not stop there. Now you must implement a company-wide data integrity policy and embed data integrity into your quality management system. Only by taking data integrity seriously, and implementing the appropriate processes, procedures, and systems within your company, will you be able to achieve full compliance with the data integrity requirements. This will give you peace of mind when an agency inspector calls next time. 

	When referring to this article, please cite it as S. Schmitt, “Meeting Data Integrity Requirements," 

Enterprise-wide processes, procedures, and systems are the keys to data integrity and peace of mind, according to Siegfried Schmitt, PhD, principal consultant at PAREXEL.

Meeting Data Integrity Requirements

Q: We have one established change control process, and this process is applied to all planned changes, including changing standard operating procedures (SOPs). On average, it takes far too long to complete the process. For example, just preparing a line-by-line description of the rationales for each individual change in the text of the SOP can take several weeks. The result is that we often have to operate according to draft versions of SOPs, as changes must be implemented faster for operational or safety reasons. How can we expedite this process?


	
	A:  You have correctly interpreted the regulations, which require you to establish change control, or as 

 (ICH) Q10 calls it, change management (1), and to have documented procedures, most likely in the form of 

(2). The issue seems to lie in the way change control is applied (i.e., the level of formality).

	A formal change control process, which as you describe can take weeks or months to complete (e.g., for the replacement of a filling line), typically consists of these steps:
	
	• Change request
	• Feasibility assessment
	• Technical review
	• Input by regulatory affairs
	• Review by quality assurance (QA)
	• Approval of change
	• Implementation of change
	• Verification of change effectiveness
	• Close-out of the change request.
	
	Notwithstanding the formality of the process, a change control process should be effective (1), meaning it is user-friendly, simple, and with minimal cycle time for decisions. This is aligned with the concept in ICH Q10 that the level of effort and formality should be commensurate with the level of risk.

	Your example of preparing a line-by-line description of the rationales for each individual change in the text of the SOP gives a good idea of the level of formality you apply at present. A change to a SOP will be requested by the owner of the procedure covered by the SOP. So this person needs this change and is thus in a position to assess the technical and operational feasibility of the change very well. More importantly, the requester is perfectly well aware of the reasons (i.e., the rationale for each change in the document). For these reasons, it is standard industry practice to provide a summary rationale, not a line-by-line explanation in the revised document (e.g., change due to revision in the applicable regulations).

	It is also easy for reviewers to see changes to the revised draft document as these are created with word processors in ‘track changes’ mode. This normally provides sufficient information for the reviewers and approvers. One issue often encountered at this step in the change process is the number of reviewers and approvers that have to sign off on the document. In effective organizations, this is kept to a minimum (i.e., two or three signatures).
	The solution to your problem is to review the level of formality applied, especially in the documentation of the change and the reasons for the change. There is no reason why a change to a SOP cannot be completed in a compliant, controlled, and formal manner in as short a time as one working day.

 Volume 4, Part I, Chapter 4 Documentation. 

	When referring to this article, please cite it as S. Schmitt, “Change Control for Standard Operating Procedures" 

The level of formality in change control may be holding back your SOP progress, according to Siegfried Schmitt, principal consultant at PAREXEL.