why does something so simple become so difficult?
by david amor, cqa, ms
editor's note: this is the third installment in david amor's med-dev from scratch: compliant innovation column dedicated to helping entrepreneurs build their medical device companies in a compliant and streamlined way. you an also read the first and second installments in the series or hear him speak about improving existing methodologies in design, review, verification, and validation at the upcoming md&m minneapolis conference on wednesday, october 29, 2014.
one of the first things i look for when entering a remediation project with a client is a quality plan. along with a gap analysis of whatever system or area is in trouble, it sets the framework for the program and gives clear guidance on what quality practices, procedures, and principles will be used. however, quality plans are also a necessity during the product development effort. let’s examine the when, why, and how of quality planning.
the quality plan: what?
quality plans are documented plans that outline quality policies, procedures, practices, and guidelines for projects and/or facilities while establishing quality expectations and metrics. they can be written to scope a project or development program or be used in a site-wide setting. these plans are typically written with a concise, explicit scope and can be used as a checklist to ensure that a process or project is meeting quality requirements for a site, company or project.
the quality plan: when?
this is probably the most important question when it comes to quality planning. 21 cfr 820 subpart b (quality system requirements) says, “each manufacturer shall establish a quality plan which defines the quality practices, resources, and activities relevant to devices that are designed and manufactured. the manufacturer shall establish how the requirements for quality will be met.”
this type of document is what i typically refer to as a site quality plan. the site quality plan should describe how your company’s quality policy allows creation of quality procedures (maintained in the quality manual) that satisfy local and federal regulations as well as quality system practices (i.e., the qsr, iso 13485). this site quality plan may include sections such as site initiatives, quality management overview, quality system effectiveness reviews, and quality site initiatives.
per the quality system inspection technique (qsit), fda’s recognized audit format, quality plans for specific device or product development “…would need to include reference to applicable quality system documents and how those documents apply to the device(s) that is the subject of the plan.” in a nutshell, fda is saying to outline how your quality system makes it possible for you to design, develop, and manufacture a safe and effective product, including reference to sops, work instructions, forms, and templates. for these types of plans, it is crucial to create a checklist of what your internal quality system says to follow for the pdp and issue a quality report at the end of development with objective evidence of completion.
the last focal area for this article on quality planning is prior to entering a remediation project. whether resulting from an fda inspection, 483, warning letter, or notified body audit, remediation quality plans must establish what a company will do bring its quality practices up to snuff and, most importantly, how they will confirm that current processes do not compromise product being developed or manufactured (i.e., risk evaluation). the remediation quality plan should start with the identified gap or observation being remediated, how it impacts the quality of the company or product, and the risk associated with operating in the interim while remediation is underway.
the quality plan: how?
each of the quality plan types described in this article has distinct requirements for successful implementation. we will focus on the pdp quality plan in this example and the remediation quality plan in a separate article.
pdp quality plan. most companies will have a product development standard operating procedure that describes the different stages of development, starting with a charter or proof of concept stage and ending in postmarket surveillance, or continuous improvement (terminology differs). the main point to consider is to identify in your quality plan when design controls are initiated—typically after proof of concept or feasibility phases. i typically structure a quality plan’s design controls section in accordance with 21 cfr 820.30 design controls or the corresponding sections of element 7 in iso 13485, depending on the quality plan. manufacturing and production quality deliverables (i.e., items related to the device master record) would be identified in the proper design outputs section. here is a sample from a quality plan written for a hypothetical device that deals with design verification:
design verification shall be performed in accordance with sopx.1234 and wiy.1234 and will confirm that design inputs identified in document 123456 are tested and verified. a design verification protocol shall be written per template 123 and the report shall be written per template 456.
short, concise, and to the point, with appropriate references! one of the biggest mistakes companies make is trying to shove every aspect of design verification into that one paragraph. for example, including sample size determination, test flows, and test method validation all in the above paragraph when the references themselves should establish or point to other documents in support of the design verification activities. the level of explicitness that you implement in your quality plan should follow this rule: give enough information and references to be able to carry out the task, but don’t include excess information that does not add value and may lead to compliance gaps.
deviations to quality procedures may sometimes be required for a variety of reasons. however, if you know that you will be deviating from a quality practice or procedure that is part of your quality system, indicate the “what” and the “why” with sufficient justification as to why it will not compromise the product’s safety or efficacy.
quality reports—typically one of the last deliverables in a pdp—“checks the box” and ensures that the product was developed in accordance with the quality procedures and practices outlined in your plan. a trace matrix is a good way of showing objective evidence that points to each of your quality requirements outlined in the plan and can include reference to published, released documents, or outputs from quality software (example: doors, requirements 1 for design inputs), just to name a few.
in summary, quality plans can be a powerful tool in demonstrating compliance. however, not understanding how to write and implement a quality plan may end up creating more gaps than your company is trying to close.
david amor is a medical device consultant who has worked with companies such as boston scientific, st. jude medical, and hospira to develop quality management systems and guide fda remediation projects. a graduate of the senior innovation fellows program at the university of minnesota medical device center, amor was named one of md+di’s top 40 under 40 medical device innovators in 2012. he founded medgineering, a niche quality consulting firm focusing on remote compliance solutions including fda remediation, quality staffing and consulting, and medtech investment due diligence. amor and his medgineering team cofounded www.myquickconsult.com, an online consulting marketplace that allows flexible question/answer and small project consults. he also currently serves as chief operating officer of remind technologies, a mobile health startup dedicated to tackling medication adherence by using smart-device-based medication dispensing units and software applications. he will also speak at the upcoming md&m minneapolis conference on october 29, 2014.
[main image courtesy of stuart miles/freedigitalphoto.net]