Skip to content

Cleanliness is a state. Without evidence, it remains a claim.

X-Mon Germany GmbH

Article · Documentation

What belongs in a URS, and what does not?

A URS should remain testable. Why we recommend including only GMP-relevant requirements and how to keep technical acceptance points cleanly separate.

· 5 min read

Download PDF

Many URS documents are too long. At first that sounds like a nice problem to have, because more requirements seem to mean more certainty. Qualification then shows the opposite. Every requirement in the URS should be verified in qualification in a traceable way: in the DQ, by a test in a test protocol, or through FAT or SAT results whose use has been justified (Annex 15, 3.3 and 3.6). If the URS also covers the colour of the control cabinet door or the manufacturer of the cable trays, these need such evidence too. Qualification becomes expensive and hard to follow, and the product gains nothing from it.

How to recognise an overloaded URS

A typical case is a URS that has grown out of the bill of quantities (BoQ). The BoQ describes in full what is to be built, and that is exactly why it is tempting to use as a template. Copy it line by line, however, and you end up with items such as:

  • makes and models of components
  • sound power levels of fans
  • labelling concepts, colours, cable routing
  • ease of maintenance and accessibility
  • energy efficiency and operating costs

All of this makes technical sense and should be checked. As a rule, it has nothing to do with product quality and patient safety. Maintenance can be an exception. Under Chapter 3 of the EU GMP Guide (Principle and 3.34), premises and equipment should be designed so that they can be cleaned and maintained effectively. If maintenance means entering the cleanroom or opening a product-contact part, maintainability becomes GMP-relevant.

The yardstick: impact on product and patient

Under Annex 15 of the EU GMP Guide (3.2), the specification for equipment, facilities, utilities or systems should be defined in a URS and/or a functional specification. The essential elements of quality need to be built in at this stage, and any GMP risks mitigated to an acceptable level. The key lies in the word essential. It refers to whatever can affect the quality of the product. Quality risk management under ICH Q9(R1) provides the tool for this.

The Annex 15 glossary, however, defines the URS more broadly: the set of owner, user and engineering requirements necessary and sufficient to create a feasible design meeting the intended purpose of the system. Technical requirements are therefore not excluded. Putting only GMP-relevant requirements into the URS, and the rest into a technical requirements document and acceptance under GEP, is our recommendation from practice, not a requirement of the guideline.

Following this recommendation, a requirement belongs in the URS if the answer to at least one of these questions is yes:

  • Could a deviation impair product quality, for example through contamination, mix-ups or incorrect storage conditions?
  • Could it put patient safety at risk?
  • Does it concern the integrity of GMP-relevant data?
  • Does it follow from an explicit requirement, for example a cleanroom grade under Annex 1 for sterile medicinal products or a class under ISO 14644-1, water quality under Ph. Eur., compressed air quality under ISO 8573-1 or one of the operator’s SOPs?

If the answer to all of these questions is no, the requirement is not wrong. It simply belongs somewhere else.

Where does the rest go?

Purely technical requirements are covered by technical acceptance under Good Engineering Practice (GEP). They are checked there just as carefully, only without the formal framework of qualification. Annex 15 also allows document reviews and individual tests from FAT or SAT to be used in qualification without repeating them. This must be justified, and it must be shown that transport and installation have not affected functionality. This avoids duplicate testing.

A workable split looks like this:

Requirement URS Technical acceptance
Cleanroom grade and pressure cascade ✔
Surfaces smooth, non-porous, resistant to disinfectants ✔
Temperature and humidity where the product is sensitive ✔
Temperature and humidity as a comfort value only ✔
Make of fan ✔
Sound level in the plant room ✔
Accessibility for maintenance (except where maintenance affects the cleanroom or the product) ✔

The boundary is not always clear-cut. Room temperature is a good example. In a store for temperature-sensitive goods, it is a critical parameter with an alarm limit. In a changing room, it is a comfort value based on generally accepted engineering practice. The parameter is the same, but its classification depends on the room and the product.

The order makes the difference

The separation is easiest when the URS does not come first. Annex 15 does not specify whether the risk assessment or the URS comes first. For computerised systems, Annex 11 (4.4) states that the URS should be based on a documented risk assessment and that user requirements should be traceable throughout the life cycle. In practice, this order has proven useful:

  1. Qualification master plan (QMP): Which items are qualified, and to what extent?
  2. Risk assessment: Which characteristics of the items could put product or patient at risk?
  3. URS: The requirements are derived from the risks and the regulations.

It is rarely entirely linear. Often the basic requirements and a concept come first, the risk assessment sharpens them, and only then is the URS approved.

Every requirement in the URS can then be traced back to a risk or a regulatory requirement. If that link is missing, it is a sign that the requirement belongs in technical acceptance. More on the role of the risk assessment can be found in the article Risk assessment determines the scope of qualification.

Sources belong in it too

Good URS requirements state their source. That can be a regulation, a line from the risk assessment or a requirement from one of the operator’s SOPs. During an inspection, you can then explain in one sentence why a requirement exists. And when changes are made later, it is immediately clear which requirements are affected if a risk or an SOP changes.

Conclusion

A lean URS is not a sign of carelessness. It shows that someone has decided what matters for the product. The other requirements are still checked, just in the right place. This saves effort in qualification and makes the documentation easier for auditors to follow.

How a URS is structured in principle is explained in the article What is a URS in a GMP environment?. For support with writing and reviewing URS documents, see GMP documentation.

Further reading

Documentation

Common errors in GMP documentation

Common errors in GMP documentation: why they stand out in audits and how to set up requirements, traceability, approvals and raw data properly.

· 7 min read

Documentation

What is a URS in a GMP environment?

URS in a GMP environment: purpose, typical content and testable requirements. How user requirements become the basis for specification, qualification and audit.

· 8 min read

Audit

Audit preparation for technical GMP projects

Audit preparation for technical GMP projects: document map, URS to qualification, CAPA, calibration, maintenance and walkthrough, with a checklist.

· 7 min read

Contact

Questions about your specific project?

Describe your project briefly. You will get a personal reply.

Article as PDF

What belongs in a URS, and what does not?

Please tell us briefly who you are. The download starts straight after.

Your details are sent to us by email. We will not send you a newsletter or advertising. More in our privacy policy.

This website does not set cookies.

Nothing is stored in your browser. We use no analytics, tracking or marketing services and load no content, fonts or scripts from third parties.

Nothing is stored in your browser.

When any website is accessed, the web server processes technically necessary access data such as the IP address. Details are in the privacy policy.

You will find full information in our privacy policy.