Recent Webinar Q&A on the DMR:

QUES: About Device Master Records : Does a listing of documents which are registered on other files can respond to the DMR? For instance if we have the document that needs to be on the DMR on the technical file is it acceptable to not put it on the DMR ? Or do we need to have all the documents in the DMR? In case of subcontracting for the manufacturing of the device : some documents as for instance equipment tests are specific to CMO and we, as order giver don’t have these documents in our system. Is it also acceptable to only mentioned it on our DMR?

ANS:  The DMR is the device “recipe” for your company.  It could include a BOM, assembly SOPs, test SOP, a “Traveler”  having check offs for Line Clearance, Label Reconciliations, operating settings / ranges with operator and QC initials, specs, et al (see 21 CFR 820.181).  

The CMO should have their own DMR for the component(s) they are manufacturing for you, and you would show that completed component P/N that you receive from them on your DMR (that would translate through to your technical file). 

If you are the spec developer not just for the completed device, but also for the components built by the CMO, then you may have to include that P/N’s assembly in your DMR / Technical File.  That may be determined by how the part was developed, who developed it, the contractual arrangements with your CMO, any CMO Quality Agreements with your company, etc. 

When dealing with a CMO the final / parent company has to ensure that all regulatory requirements have been addressed totally, which by the CMO (verified by the company), and the remainder by the company.  The company is ultimately responsible for complete compliance.

I answered the above based on the US FDA / CGMPs; but similar points could be made for the EU MDR and ISO 13485.  

-- jel@jelincoln.com

Typo corrected 08/11/23 - JEL

 Recent Webinar Q&A on Design Verification and Design Validation:

QUES: About design verification and design validation : You have mentioned activities both on design verification and design validation : for instance shelf life, biocompatibility… We have difficulties to understand clearly what activities are design verification and what activities are design validation. Could you please explain us? Does a type of activity can be on both and so what are the differences? 

ANS:  Your company needs to specifically define these terms in an SOP so they can be followed by those using the SOP and simultaneously comply with the CGMPs upon which the SOP is based.  E.g., if I have a medical device that touches the patient, I might have requirements for functionality, biocompatibility, sterility, safety in shipping, etc.

I test each requirement, e.g.,  biocompatibility at a lab per ISO 10993, sterility per applicable ISO standard by a contract lab, do shake / drop / cross country shipping testing, environmental test, packaging seal testing (pull, dye…), functional testing (in-house bench testing, lab testing), etc.  Per my “working definitions” of V&V, I would define each of those tests of a specific requirement as a verification. Put their final versions (of verifications) altogether into a Test Report, and that would by my device Validation Test Report, proving all “user needs”, i.e., requirements (customer requirements, standards, guidance documents, manufacturing capabilities, etc.), have been met.

-- jel@jelincoln.com

Minor additional explanations on V&V added, 12/31/23 - JEL

 

Recent Webinar Q&A on User Needs and Design Inputs:

QUES:  User needs / design inputs : could you clarify (maybe with an example) the definition for user needs and design inputs please ?

ANS:  Your SOP should make that definition, as there can be several variations, all acceptable per the CGMPs.  

When I validate, I list all the “ Requirements / expectations by the various stakeholders (including the FDA and other regulatory agencies)” for the item / process / equipment being validated, which include Marketing specs, Standards, Guidance Docs, Company capabilities, etc.  All of these I define as “user needs”, i.e., the user (patient, clinician …) has wants, but expects the device to adhere to safety standards, operating standards, and other considerations necessary in order to produce a safe and effective device. 

These requirements are changed into specific design elements to meet those requirements, and thereby  would drive/define Design Inputs (820.3(f) “…the physical and performance requirements of a device that are used as a basis for device design”.  These would form the initial Design Inputs.  During development, the initial DIs become initial Design Outputs, which in turn become new initial DI and so on until the final DOs are achieved, approved and the Design (documents, et al) is Approved / Transferred / placed into the system for manufacturing.  The FDA discusses this in one of their documents on Design Control (a slide presentation on inspection of 820.30) where they say that only approved DOs need to be retained: however, I usually encourage my clients to include the key transition interim DIs / DOs as well to maintain a usable development history for the company, not only for the FDA. I usually file the interim DIs / DOs under the DO tab in the DHF - define specifics in your company's SOPs.  

-- jel@jelincoln.com

Added additional info on interim DIs / DOs, 12/31/23 - JEL

 Recent Webinar Q&A on Formative vs Summative Evaluations:

QUES:  About Usability studies : could you explain why formative report is a verification data whereas summative report is a validation data ? Indeed, we considered both documents as verification data for the validation of the instruction for use.

ANS:  I stressed that I use my "working definitions" and that you should develop the same (defined in your SOPs and FOLLOWED); that regulatory agencies give much leeway on definitions as long as they are reasonably covered by ISO / GMP, etc., definitions.

RE:  Formative and summative (per IEC 62366), see FDA Guidance "Applying Human Factors and Usability Engineering to Medical Devices", Guidance, dated February 3, 2016,

page 3, Definition "3.3 Formative evaluation Process of assessing, at one or more stages during the device development process, a user interface or user interactions with the user interface to identify the interface’s strengths and weaknesses and to identify potential use errors that would or could result in harm to the patient or user. " I defined as testing, checking  ... verification;

page 20, footnote 4:  "4 Human factors validation testing is sometimes referred to as “summative usability testing.” However, summative usability testing can be defined differently and some definitions omit essential components of human factors validation testing as described in this guidance document."

Further response to the first question:

 

QUES: Could you explain why formative report is a verification data whereas summative report is a validation data ? Indeed, we considered both documents as verification data for the validation of the instruction for use. 

 

ANS:  You are correct when you state that both your formative evaluations and summative evaluation would be verifications as part of the validation of the IFU.  This is because both are used for another step, that is, the validation of another entity, not the UE / HF device interface. Clarify in the SOP. 

 

However, my above comments are based on UE / HF applications , where formative evaluations/testing are in-process verifications of UE/HF, and summative evaluation is the final validation of the device design interface.  Where those documents satisfy the definitions of formative and summative in evaluation of a device's user interface, if they are used for another application / entity, e.g., IFUs, then both could be considered verifications / tests which become part of the IFU validation.

-- jel@jelincoln.com