An Overview to User Requirement Specifications and Design Qualification
User Requirement Specifications (URS) and Design Qualification (DQ) are implemented in many organizations in response to EU and other guidance documents. Many organizations lack understanding of why these tools are recommended and therefore implement them incorrectly or at inappropriate times.
User Requirement Specifications and DQ are tools that were co-opted by the concept of Quality by Design (QbD). The concept of QbD is driven by ICH Q8 through Q11 as well as Risk Based Approach models described in ISPE and other baseline guidance documents. A URS and/or DQ can be used to demonstrate your equipment, instrument, utility system, process, etc. are following a risk based approach and QbD.
User Requirement Specifications
“Ugh, why did they design it this way?” “How am I supposed to qualify this?” These questions and frustrations are examples of what drove developers of the risk based approach and QbD processes to start pushing the use of URSs. URSs have been around for years and many are used to document anything from general purchase specifications to construction specifications. The main purpose of a URS is to give a vendor a set of requirements that must be satisfied upon purchase or receipt of an engineered system. Those involved in generating and maintaining quality systems within organizations began to realize a URS can be used to implement quality at the very beginning of the process.
For any organization in a cGMP industry, a URS should be used for one main purpose: implementing QbD. To achieve QbD, a prerequisite is understanding what quality is with respect to the equipment or system qualified. The starting point for a is a risk assessment or impact assessment. The assessments should identify all currently known risks and critical-to-quality attributes and/or process parameters (CQAs / CPPs). With risks identified, it is possible to also identify methods for risk control and anything necessary to monitor or control CQAs and CPPs into the URS. The result is a document that drives what testing is necessary, based on which attributes are truly critical for commissioning and qualification activities.
The risk assessment is also a starting point (from a quality perspective) for what to look for in a design specification, functional specification, software design specification, etc. (Hey, this looks familiar; like we’re starting a trace matrixJ!) That is correct; the starting document for a trace matrix is the URS! The critical-to-quality items identified in the assessments are documented in the URS, and then included in the design and all subsequent specifications and qualifications.
In the above example, the main purpose of a URS was to demonstrate QbD, but there are other legitimate reasons for using User Requirement Specifications. Although the not essential for quality, the URS can capture items such as safety requirements and ergonomic requirements. These items are important, and if they are excluded from the purchase specification it makes sense to include them in a URS. When including non-quality attributes in a URS, it becomes important to specify which specifications are critical-to-quality and which ones are not. Add a column to a URS table such as “CTQ (Yes / No)” to make this distinction.
In previous paragraphs, the term engineered system was underlined. Many organizations erroneously require that all systems on site require a URS. This is a mistake and demonstrates a poor understanding of the purpose of a URS. In light of using a URS for QbD it does not make sense to generate a URS for a piece of equipment or an instrument purchased from a catalogue or off-the-shelf. It is difficult to design quality into something that is not being designed. The appropriate approach for off-the-shelf equipment is to employ a risk or impact assessment in lieu of a URS. Another approach is to use a general purchase policy to identify requirements for items such as laboratory instrument. Such a policy might include Part 11 requirements, purchased qualification packages and/or specific FDA requirements.
Design Qualification
Where does design qualification fit in? The DQ has a similar purpose as the URS: to verify CTQ design elements are successfully incorporated into the design. Since regulatory guidance documents drive use of the URS and DQ, it is important that URS and DQ documents reflect and focus on critical-to-quality items an auditor would look for such as quality items that impact patient safety. While important to document or verify that operator safety, ergonomic and other concerns were included in the design, segregation should be made between CTQ, and non-CTQ requirements.
The DQ should be no more complicated than to verify that CTQ items in the URS successfully made it into the final design. Anything more may be above and beyond the intent of QbD.
Retrospection
Many organizations decided to retrospectively generate URSs for equipment and systems that are already in place or which are already designed and built to “check the box” on the regulatory requirement. Retrospectively generating a URS signals to an auditor that QbD was accidental and that the organization has not fulfilled the intent of QbD. Retrospection is non-value-added, so if a project is already past design/build, it makes more sense to perform risk and impact assessments. This is a check on commissioning and qualification documentation to verify each CTQ item. Policies and procedures that allow risk and impact assessments for existing systems and URS and DQ at the beginning of a new project saves time and stays true to the intent of a DQ and URS.
Conclusion
The main take away is that the main purpose of a URS and DQ is to ensure and demonstrate your organization is following QbD for engineered systems. The starting point for the URS is risk and impact assessments. Without assessments, the specifications are not targeted to the specific intended use, and may result in generic engineering specifications that already exist. Quality auditors are the audience for your quality documents. Auditors want to see a true understanding of QbD and QbD implemented from start to finish. Call CTI if you or your organization needs help with identifying where URS and DQ fit into your quality program or your projects.