Writing a URS that actually drives the qualification, and deciding whether you need a DQ

Picture the day the new system arrives. The validation engineer opens the user requirements specification (URS) to write the operational qualification. It runs to four pages. Half of it is the supplier’s brochure. The rest asks for a system that is “robust”, “user-friendly” and “Part 11 compliant”. Nothing in it can fail a test, so the protocol ends up repeating the supplier’s own checks.

The URS is the cheapest document in a qualification project, and it sets the cost of all the others. Written well, it chooses the supplier, gives the design qualification (DQ) something to check, and becomes the first column of the traceability matrix. Written badly, it pushes every decision downstream, to the point where changing anything is expensive.

What the regulation asks the URS to do

The EU good manufacturing practice (GMP) guide defines the URS in Annex 15 (2015) as “the set of owner, user and engineering requirements necessary and sufficient to create a feasible design meeting the intended purpose of the system”. Two words do the heavy lifting. Necessary rules out the wish list. Sufficient means nothing important is left for the supplier to guess.

The annex then gives the URS its role. The specification “should be defined in a URS and/or a functional specification”, quality is built in at that stage, and “the URS should be a point of reference throughout the validation life cycle” (§3.2). The requirements are then “verified during the design qualification” (§3.3). That “and/or” matters for standard products: the detail can sit in the supplier’s functional specification, provided it answers each URS line.

For computerised systems, EU GMP Annex 11 (2011) adds two conditions: the URS rests on “documented risk assessment and GMP impact”, and user requirements are “traceable throughout the life-cycle” (§4.4). A URS line is therefore not finished until you know how, and at which stage, it will be verified.

Who writes it, and who must be in the room

The users own the URS: the analysts and the lab head for an instrument, production and process engineering for a line. They know what the system is for. They rarely know everything it needs, which is why the URS is a team document.

Automation brings the controller platform, the operator panel and the interfaces to other equipment and to the manufacturing execution system (MES) or laboratory information management system (LIMS). IT and OT security cover user accounts and roles, the network zone, antivirus and patching, clock synchronisation, backup and restore. Maintenance and metrology think about access for servicing, standard spare parts, calibration points and ranges; environment, health and safety (EHS) about guarding, noise, exposure and ergonomics. Purchasing sets the response framework and the commercial terms, including the price of qualification support. Quality assurance (QA) puts the GMP flag on each line, reviews and approves.

The supplier does not write the URS; it answers it. A URS copied from the favourite supplier’s brochure makes the DQ circular, because the offer ends up being compared with itself. Users and QA approve the URS before it goes out to suppliers. Approved after the order, it describes a purchase rather than specifying one.

One line, one testable requirement

A URS reads best as a table. Each line carries one need and five attributes.

• A unique ID: a family code and a number, such as SEC-05 or DAT-06. The ID reappears in the offer, the DQ, every protocol and the traceability matrix.
• The requirement: one “shall”, with the unit, the tolerance and the condition. “Operates to specification at 15–30 °C” can be tested; “suitable for laboratory conditions” cannot.
• A class: mandatory (a regulatory or business must-have), desired (a benefit that can be traded against price) or comfort (ergonomics, appearance). Mandatory lines decide pass or fail between offers; the others rank them.
• A GxP flag, with its reason: yes when the line can affect product quality, patient safety or data integrity under good practice (GxP) rules. The flag tells QA where to look and the risk analysis where to start.
• How and when it is verified: document review, inspection or test, at DQ, factory or site acceptance test (FAT, SAT), or installation, operational or performance qualification (IQ, OQ, PQ).

State the need rather than the design. “Product-contact parts removable without tools” is a need; a named valve model is a design. Site standards are the exception. A required controller platform or antivirus is a legitimate constraint when maintenance and security depend on it, so write it as a constraint, with the reason.

Where most URSs are thin: data, security and services

Users think in functions and capacity, so those are usually well covered. Three families tend to be thin, and each comes back later as a finding or a hole in the OQ. Data: which records the system creates, where they are stored, the audit trail, clock synchronisation, backup and restore, export in a readable format, retention. Security: individual accounts, roles, lock-out after failed log-ins, password rules that follow site policy, segregation of duties (an administrator should not run or approve analyses), and who may change a method. Services and documents: qualification support (protocols, raw data, test-instrument certificates), training for users and administrators, spare parts, the software support period, document languages.

“Compliant with 21 CFR Part 11” (the US rule on electronic records and signatures) is a hope, not a requirement. Break it into lines that can fail: individual accounts, audit trail content (§11.10(e)), exact copies of records (§11.10(b)), and the name, date, time and meaning shown with each electronic signature (§11.50). The supplier’s compliance statement then feeds the DQ instead of replacing it.

Do you need a DQ? Three questions before the order

Annex 15 defines DQ as “the documented verification that the proposed design of the facilities, systems and equipment is suitable for the intended purpose”. It is where each URS line meets the supplier’s answer. The practical question is how much DQ a purchase needs: a full design review, a one-page comparison, or nothing separate at all.

One site’s decision tree for this is built on four yes/no questions: novelty on site, added functions, qualification scope, and whether the equipment has to be adapted. We use a shorter version with one change: the lighter exits still leave a written record.

If the system is outside the qualification scope, with no GMP function in your inventory (a case packer with no coding or inspection role, say), there is no DQ, but the scope decision itself is recorded.

If it is identical to a qualified reference, such as a third tablet press of the same model and configuration as two already qualified, the first press’s DQ still holds. Confirm the URS is unchanged and cite the existing file. Knowledge management does the DQ’s work here; nothing is skipped.

A standard product used as supplied, a catalogue balance or a stand-alone spectrophotometer, needs a DQ that shrinks to a signed, line-by-line check that the supplier’s specification meets each mandatory URS line. United States Pharmacopeia (USP) general chapter <1058> expects DQ requirements to be “minimal” for commercial off-the-shelf instruments. Minimal is still more than nothing. Annex 11 asks the same for off-the-shelf software, whose documentation is reviewed “to check that user requirements are fulfilled” (§3.3).

Anything adapted, configured or built for you (a new format part, a bespoke skid, a configured recipe system) gets a full DQ: design reviews against each URS line before the build, which then feed the FAT and SAT protocols.

When an offer misses a mandatory line, the DQ records the gap and the decision: change the design, add a procedural control, or accept it with a documented risk assessment. Whichever exit applies, one line in the project file must say which one and why. A light DQ with a written reason can be defended; a missing DQ with no reason is a gap. For what each qualification stage proves, and what it cannot, see DQ, IQ, OQ, PQ: what each stage proves.

The URS is the root of every test

Follow one line through the project.

That chain is the traceability matrix, and it starts the day the URS is approved, not the week before an audit. Deciding which lines need a qualification test at all is the job of the risk analysis. How deep each test goes, and how the matrix proves coverage, is the subject of How deep should a test go?.

PQ acceptance criteria come from the URS as well. A time-to-result line becomes a timed routine run, a capacity line a full-load run. Without a measurable performance line, the PQ has no criterion that anyone agreed before the purchase.

Keep it alive after the order

Version the URS. Requirements move during design reviews and the FAT, and each change needs a version number and a reason, so that the protocols test what was actually bought. After go-live, changes are assessed against the URS under change control. For computerised systems, re-read the URS at each software release.

The mistakes we see most often

The URS written after the supplier has been chosen is the classic. It is reverse-engineered from the offer, so the DQ can only agree with it. Almost as common is the URS written by one person, usually the validation engineer working alone from a template; the users’ real constraints then surface during PQ, when they are expensive.

And then there is the URS where everything is mandatory. When every line is mandatory, none of them separates the offers, and QA can no longer see which lines carry GMP risk.

A requirement nobody can test is a wish, and a URS full of wishes leads to a qualification full of paperwork.

References

• EudraLex Volume 4, EU GMP Annex 15 Qualification and Validation (2015), §3.2, §3.3 and Glossary (URS, DQ), health.ec.europa.eu
• EudraLex Volume 4, EU GMP Annex 11 Computerised Systems (2011), §3.3 and §4.4, health.ec.europa.eu
• US 21 CFR Part 11, Electronic Records; Electronic Signatures, §11.10(b), §11.10(e), §11.50, ecfr.gov
• USP general chapter <1058> Analytical Instrument Qualification (2017), design qualification.