Systems Engineering for FDA Design Controls Compliance

1. 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. 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. 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. 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. 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. 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. 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. 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. 9 Systems Engineering for FDA Design Controls Compliance • (c) Design input (Continued): • An IPPT Approach toSpecifications: • 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. 10 Systems Engineering for FDA Design Controls Compliance • (c) Design input (Continued): • An IPPT Approach toSpecs (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. 11 Systems Engineering for FDA Design Controls Compliance • (c) Design input (Continued): • An IPPT Approach toSpecs (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. 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 cross-check 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 28 Systems Engineering for FDA Design Controls Compliance • IPPT Compliance Tools (Continued): • Requirements ManagementTools: • 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. 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. 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.)