Systems Engineering for FDA
Design Controls Compliance
An Integrated Product/Process Team (IPPT)
Approach to Comprehensive Design Controls for
New/Upgrade Medical Device Development Projects
James H. Jones
Systems Engineering Manager
Optivus Technology, Inc.
1475 S. Victoria Court, San Bernardino, California 92408
www.optivus.com jjones@optivus.com
2
Systems Engineering for FDA Design Controls Compliance
• Presentation:
– Think R&D for embedded systems medical
devices as product development context.
– 21 CFR 820.30 Quality System Regulation
(QSR) provisions for design controls set the
regulatory context.
– Basic Systems Engineering methods within
an Integrated Product/Process Team (IPPT)
approach essentially automate compliance.
3
Systems Engineering for FDA Design Controls Compliance
• Presentation (Continued):
– Double quote marks = direct QSR quotes.
– Time for highlights only – emphasis is on
provisions where basic Systems Engineering
methods are most useful. Other provisions get
shorter shrift, as below:
• (a) General:
– (Introduction to design controls)
4
Systems Engineering for FDA Design Controls Compliance
• (b) Design and development planning:
– Project Management Plan (PMP) Purpose:
• Is to “… describe or reference the design and
development activities and define responsibility for
implementation”
• “The plans shall identify and describe the
interfaces with different groups or activities that
provide, or result in, input to the design and
development process.”
5
Systems Engineering for FDA Design Controls Compliance
• (b) Design ... Planning (Continued):
– IPPT Project Planning:
• Tailoring: Reduce PMP elements from worst case
(for scope, scale, complexity) to a defined project
case, enabling better task estimates.
• Tailoring reduction is constrained by minimum set
of tasks and records needed for design controls
compliance and 510(k) premarket application
submittal for approval to market the device.
6
Systems Engineering for FDA Design Controls Compliance
• (c) Design input:
– Auditably Compliant Specifications
• Design input is defined in QSR 820.3 as “physical
and performance requirements of a device that are
used as the basis for a device design.”
• Initial design input is elicited customer inputs to
requirements that address “intended use of the
device, including needs of the user and patient” in
system requirements specifications.
• Further, “procedures shall include a mechanism for
addressing incomplete, ambiguous, or conflicting
requirements.”
7
Systems Engineering for FDA Design Controls Compliance
• (c) Design input (Continued):
– Auditably Compliant Specs (Continued):
• As defined in QSR 820.3, Design inputs are
outputs from preceding stages in the design effort.
• A Customer Requirements Document (CRD) is for
capturing customer inputs to design requirements.
• The system specification, for project functional,
performance, and qualification requirements, often
is a Product Requirements Document (PRD).
8
Systems Engineering for FDA Design Controls Compliance
• (c) Design input (Continued):
– Auditably Compliant Specs (Continued):
• The CRD inputs to the PRD must be addressed,
but not necessarily by immediate implementation.
• The PRD provides design inputs allocated/derived
as mechanical, electrical, and software
requirements into subsidiary Hardware/Software
Requirements Specifications (HRS/SRS).
9
Systems Engineering for FDA Design Controls Compliance
• (c) Design input (Continued):
– An IPPT Approach to Specifications:
• Requirements Management methods are a means
to providing auditable evidence of design input and
output and verification that is compliant with QSR
Design Controls.
• Use standard Requirements Writing Rules.
• Build PRD driven Concept Architectures to guide
allocation/derivation of the system requirements
into hardware and software specifications.
10
Systems Engineering for FDA Design Controls Compliance
• (c) Design input (Continued):
– An IPPT Approach to Specs (Continued):
• Use Requirements Verification & Validation Trace:
– The RVTM enables inspecting each HW and SW
requirement for correct and complete response to its
driving requirement, so is a “mechanism for addressing
incomplete, ambiguous, or conflicting requirements”.
– The RVTM reduces cost/schedule because requirements
are minimal adequate set (closer to ‘right the first time’).
– Each derived requirement permutation is traced to a step
in a test case in a verification procedure, thus indicating
exactly where its driving PRD requirement is indirectly
validated.
11
Systems Engineering for FDA Design Controls Compliance
• (c) Design input (Continued):
– An IPPT Approach to Specs (Continued):
• Requirements & V/V Trace (Continued):
– The RVTM also traces back to each hazard in the
analysis document for which a requirement has been
cited as the driver for implementing an abatement action.
– Listing requirements being verified within cited procedure
ultimately completes trace because reports of results are
objective evidence of requirements fulfillment and the
risk reduction by design implementation
• The RVTM is project ‘roadmap’ to design controls
compliance.
12
Systems Engineering for FDA Design Controls Compliance
• (c) Design input (Continued):
– Risk Analysis Documentation:
• A Hazard Analysis is first element in Risk Analysis,
listing actions to abate unacceptable risk levels.
(Use ISO 14971:2007 Annex D for organization
and assign risk abatement to PRD requirements.)
• An associated Fault Tree Analysis (FTA) shows the
logical fault propagation paths [descent to a crosscheck or to a single point fault component that
must have high reliability].
• As subsystems are defined, each is subject of
bottom-up Failure Mode and Effects Analysis.
13
Systems Engineering for FDA Design Controls Compliance
• (d) Design output:
– Auditably Compliant Final Device(s) and
Documentation:
• Design output is defined in QSR 820.3 as “the
results of a design effort at each phase and at the
end of the total design effort. ... The total finished
design output consists of the device, its packaging
and labeling, and the device master record.”
• “Design output procedures shall contain or make
reference to acceptance criteria and shall ensure
that those design outputs that are essential for the
proper functioning of the device are identified.”
14
Systems Engineering for FDA Design Controls Compliance
• (d) Design output (Continued):
– Auditably Compliant Final Device(s) and
Documentation (Continued):
• Along with the device, total finished design output
includes the device master record (DMR) that is
associated closely with this subsection.
• Briefly, the DMR contains all the information that
would be necessary to duplicate the device in its
delivered configuration.
15
Systems Engineering for FDA Design Controls Compliance
• (e) Design review:
– Auditably Compliant Design Reviews and
Documentation.
• Design review is “a documented, comprehensive,
systematic evaluation of a design to evaluate
adequacy of the design requirements, to evaluate
the capability of the design to meet these
requirements, and to identify problems.”
• Output of each phase of the device development is
subject to extensive design review procedures.
16
Systems Engineering for FDA Design Controls Compliance
• (f) Design verification:
– Auditably Compliant Requirements
Verification:
• Design verification is defined in QSR 820.3 as
“confirmation by examination and provision of
objective evidence that specified requirements
have been fulfilled.” (Device was built correctly.)
• Design verification is complete when fulfillment of
derived requirements is confirmed by HRS/SRS
verification procedure(s) and the results reported.
17
Systems Engineering for FDA Design Controls Compliance
• (f) Design verification (Continued):
– An IPPT Approach to Requirements
Verification:
• The RVTM assists developing formal verification of
HRS and SRS requirements.
• The RVTM traces hazard or fault abatements to
formal verification of their implementation.
18
Systems Engineering for FDA Design Controls Compliance
• (g) Design validation:
– Auditably Compliant Requirements Validation:
• Design validation is defined in QSR 820.3 as
“establishing by objective evidence that device
specifications conform with user needs and
intended use(s).” (The correct device was built.)
• Because HRS/SRS requirements are derived from
customer inputs, verification is most of validation.
• Design qualification requirements are validated.
19
Systems Engineering for FDA Design Controls Compliance
• (h) Design transfer:
– Auditably Compliant Design Transfer:
• Ensures “that the device design is correctly
translated into production specifications.” Depth
and breadth of translation depends on make/buy
decision for system, subsystem, or component.
• Some items may be contracted to an entity that will
do or arrange for item fabrication and supply the
design drawings/schematics in accordance with
company standards for inclusion in the DMR.
20
Systems Engineering for FDA Design Controls Compliance
• (h) Design transfer (Continued):
– An IPPT Approach to Design Transfer:
• Include Manufacturing Engineering participation
early in the design process, to ease fabrication
(and minimize total cost to implement).
• The resulting benefits also apply to external
producers and may be realized as cost bid
reductions.
21
Systems Engineering for FDA Design Controls Compliance
• (i) Design changes:
– Auditably Compliant Design Changes:
• No substantive device design project will proceed
from customer inputs through production and
validation without at least minor design changes.
• With high likelihood of affecting finished device,
manufacturer must provide “procedures for the
identification, documentation, validation, or where
appropriate verification, review, and approval of
design changes before their implementation.”
22
Systems Engineering for FDA Design Controls Compliance
• (i) Design changes (Continued):
– An IPPT Approach to Design Changes:
• Whenever a requirement is known to be (or might
be) affected, the RVTM enables locating and
determining if other requirement(s) must be
revised (and effect on risk analysis abatement).
• Potential impact alert is a fundamental feature of
requirements management tools.
23
Systems Engineering for FDA Design Controls Compliance
• (j) Design history file:
– Auditably Compliant Design History File:
• Design History File is defined in QSR 820.3 as “a
compilation of records which describes the design
history of a finished device.” This subsection of the
design controls states that “The DHF shall contain
or reference the records necessary to demonstrate
that the design was developed in accordance with
the approved design plan and the requirements of
this part” (the entire QSR), so:
• Work requested and decisions made that impact
the medical device development project are highly
pertinent for DHF capture and retention.
24
Systems Engineering for FDA Design Controls Compliance
• (j) Design history file (Continued):
– An IPPT Approach to Developing the DHF:
• Maximized automatic capture of project decisions
and action items is enabled by establishing one
company network alias for each project (the DHF
electronic file is a default recipient) and instructing
appropriate use by project team members.
– The traditional Memo to File is simplified in execution
and vastly improved in team members notification (at the
cost of capturing much conjecture and trivia).
25
Systems Engineering for FDA Design Controls Compliance
• IPPT Design Controls Compliance Tools:
– Document Templates:
• Increase in effectiveness and efficiency of medical
device development project teams is attained by
comprehensive, integrated document templates
that standardize content and interrelationships. (As
the familiar Data Item Descriptions.)
• Thus, QA and other reviewers can evaluate likely
adequacy of provided content – even when it is
well outside their domains of expertise.
26
Systems Engineering for FDA Design Controls Compliance
• IPPT Compliance Tools (Continued):
– Document Templates (Continued):
• Template content descriptions enable authors and
checkers/reviewers to quickly learn where specific
device information should be placed.
• The PMP (or a cited separate document) instructs
Tailoring by describing deletions of or within each
standardized project document.
27
Systems Engineering for FDA Design Controls Compliance
• Project Planning and Tracking Support:
– Tasks Estimating Support:
• PMP driven Tailoring of standardized document
formats from Templates assists tasks estimating.
– Status Metrics Support
• The RVTM approach enables estimates of percent
complete to be based on “actuals”.
28
Systems Engineering for FDA Design Controls Compliance
• IPPT Compliance Tools (Continued):
– Requirements Management Tools:
• Many commercial requirements management tools
exist (such as DOORS). Maximum value can be
provided by those that can easily produce RVTMs
and provide the direct and ancillary benefits.
29
Systems Engineering for FDA Design Controls Compliance
• Conclusion:
– Systems Engineering methods can be shown
to add value, but cautions are in order when
adapting your defense supplier experience:
• Where SE isn’t seen as a core competency, just do
it and provide examples without using that label.
• Particularly when joining a project in the middle,
begin with examples that also will help future jobs
rather than attempting to fix everything at once.
30
Systems Engineering for FDA Design Controls Compliance
• In brief, Basic Systems Engineering
methods can add substantial value to
embedded systems medical device
development.
• MORE QUESTIONS? (Before the next
paper on Verification Auditability.)