Karen,
There is no traceability requirement in 21 CFR 820. It is however, a best practice to show that you meet other requirements on Design Verification (21 CFR 820.30 (f) and Design Validation 21 CFR 820.30 (g)). it allows you to provide objective evidence that all of the User Requirements leading to Design Inputs (21 CFR 820.30 (c) which in turn lead to Design Outputs in 21 CFR 820.30 (d) have been addressed. As devices become more complex (and you have indicated you have both hardware and software components in your devices), it becomes difficult to keep track of which Design Inputs have been addressed by Design Outputs, and in turn, which Design Inputs have been Verified (as in many cases a single Design Input can lead to more than one Design Output). Since the Design Validation process is intended to show that all User Needs have been fulfilled, you need to be able to provide that trace back so you can ensure that the objective evidence is available to provide the objective evidence that the Design Validation is complete.
In software, trace tools have become a best practice as well, in fact some indicate that is where they began, to provide the trace for the software lifecycle requirements, such as those of IEC 62304 or other lifecycle process standard. Tools, such as IBM's DOORS and the Requisite Pro tool originated in software and have migrated to complete systems. Since you have software and hardware in your device you probably need to consider it as a system to assure all User Needs and Design Inputs are met. Those would include Regulatory Requirements and requirements from voluntary standards that you claim compliance.
I can point to a requirement for traceability that is in the risk management standard ISO 14971:2007 (and EN ISO 14971:2012) in Clause 3.5. It will also be part of the new edition of the standard to be released late this year. That requirement states you "shall provide traceability for each identified hazard to the risk analysis, the risk evaluation,
the implementation and verification of risk control measures, the assessment of the acceptability of any residual risk(s). The bolded part of the requirement is part of the Design Verification and Design Validation activities of Design Controls. So in this case a traceability requirement, while not part of a regulation, per se, is a part of a standard normally used to meet a regulatory requirement.
Hope this helps.
------------------------------
Edwin Bills MEd, CQA, RAC, BSc, CQE, ASQ
Principal Consultant
Overland Park KS
United States
elb@edwinbillsconsultant.com------------------------------
Original Message:
Sent: 23-Apr-2019 11:23
From: Julie Omohundro
Subject: FDA Traceability Question
Karen, sorry you haven't gotten any responses, at least in the Forum.
Could I ask you a couple of potentially odd questions? What do you see as the purpose of traceability in design control of hardware? And in establishing hardware and software traceability?
------------------------------
Julie Omohundro, ex-RAC (US, GS), still an MBA
Principal Consultant
Class Three, LLC
Mebane, North Carolina, USA
919-544-3366 (T)
434-964-1614 (C)
julie@class3devices.com
Original Message:
Sent: 22-Apr-2019 15:27
From: Karen Zhou
Subject: FDA Traceability Question
Hi everyone,
For clarification, what is the difference in traceability requirements between hardware and software? As per FDA premarket submission requirements for software, there is a traceability requirement linking the SRS to SDS, V&V and risk control measures. How can we establish traceability in design control of hardware? Is the design input matrix in addition to risk analysis table sufficient? What if the device has both hardware and software components? How are hardware and software traceability established? What kind of matrix would like that look like?
Thanks.
------------------------------
Karen Zhou
------------------------------