Does the Scope of 21 CFR Part 820.72 (Equipment) apply to Design?

[Mark Meer]

§820.72 (inspection, measuring, and test equipment) is under Subpart G (Production and Process Controls) of the regulations. Does this mean that the scope of these requirements is limited to production (and outside the scope of design controls)?

The reason I ask, is that our developers use A LOT of equipment! Strictly speaking, this equipment is used to make measurements, but these measurements are limited to the development process, and are NOT used to conduct formal design verification testing.

Do I need to worry about the requirements of this section (820.72) for all this development equipment? I'd argue no..but curious to know what others think.

MM

 

[Ronen E]

My understanding is similar to yours.
You must have controls in place to ensure that "exempt" development equipment doesn't participate in "official" design acceptance activities.

 

[v9991]

Do I need to worry about the requirements of this section (820.72) for all this development equipment? I'd argue no..but curious to know what others think. MM

precedence... might tell us that it has not been an issue (so far!!!)

as per the (broken link removed) PAI audit scope., traceability of development data to registration/submission requirements is on e of the objectives; hence all the data "generated / cited / relied" upon to finalize the product (even if its development ) must undergo relevant controls.

...Objective 2: Conformance to Application ...
Verify that the formulation, manufacturing or processing methods, and analytical (or examination) methods are consistent with descriptions contained in the CMC section of the application for the biobatch (and other pivotal clinical batches, when applicable), the proposed commercial scale batch, and the API(s).

and another point to consider is that, once you have taken a product/process from prototype-to-verification/validation stages, the cost of discovering any 'surprise/failure - redevelopment etc" would have cost impact at a different scale.

hence, instead of no-controls.., I would rationalize the extent (freqneyc /. depth) of controls.

 

[Mark Meer]

...hence, instead of no-controls.., I would rationalize the extent (freqneyc /. depth) of controls.

Yes, this is more-or-less what we've been doing, but lately its been proven to be becoming quite burdensome.

Some of our developers are what could be described as "hobbiests/enthusiasts", and will frequently want to purchase a piece of newest software, bring equipment from home, or go out an borrow a piece of equipment temporarily. ...and hence keeping track of records and scheduling has become very onerous.

I don't want to hinder their enthusiasm, and want to maintain a development environment in which they are free to use whatever tools they want.

What seems fair to me is to:
1. Let them do their thing (uncontrolled)....
2. Only when they have a prototype ready to be tested, does controlled equipment come into play...

MM

 

[William55401]

Hi Mark

Good question. In my experience, I have never encountered an agency finding regarding lack of equipment control on the development side. However, all of the organizations I have worked in, have included engineering projects actively in product development in scope of their full QMS that includes equipment controls. Some organizations may choose to draw the line of their QMS to exclude research (the stage before development) which can be very conceptual / early stage. Their QMS usually states to apply full controls to development projects intended for commercialization and gives research (or whatever you may choose to call it) the freedom desired.