systems engineering for fda design controls compliance l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Systems Engineering for FDA Design Controls Compliance PowerPoint Presentation
Download Presentation
Systems Engineering for FDA Design Controls Compliance

Loading in 2 Seconds...

play fullscreen
1 / 30

Systems Engineering for FDA Design Controls Compliance - PowerPoint PPT Presentation


  • 218 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Systems Engineering for FDA Design Controls Compliance' - Gabriel


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
systems engineering for fda design controls compliance

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

slide2

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.
slide3

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)
slide4

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.”
slide5

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.
slide6

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.”
slide7

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).
slide8

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).
slide9

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.
slide10

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.
slide11

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.
slide12

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.
slide13

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.”
slide14

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.
slide15

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.
slide16

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.
slide17

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.
slide18

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.
slide19

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.
slide20

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.
slide21

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.”
slide22

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.
slide23

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.
slide24

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).
slide25

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.
slide26

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.
slide27

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”.
slide28

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.
slide29

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.
slide30

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.)