Design Traceability - Labelling / Instructions for Use

ThatSinc

Involved In Discussions
#1
Hi All,

Looking at design traceability and expectations for showing traceability for all detail within the labelling and instructions for use back to the source requirements.

At the moment there is no formal document that provides, requirement by requirement, what each regulation needs for the development of the labels and IFU, or the outputs from risk.
And there is no link back from each statement in the labelling/IFU to what requirement it came from.
The final prepared documents are approved by QARA, confirming that the content meets the applicable regulatory requirements as per the regulatory strategy document and all outputs from risk.

The business maintains a single DTM for each device that provides references from the User Needs, at a basic level, to the the design inputs, outputs, verification and validation, however doesn't currently maintain the labelling and IFU requirements to any level of detail that would allow a content creator to develop them.

To me this seems like a gap, but putting the level of detail required to allow content creation of the labelling and IFU into a single high-level DTM seems somewhat overkill.


Obviously the regulatory requirements of each relevant country provide sources for the design inputs;
Is there an expectation that each individual requirement, such as the numerous GSPRs for labelling and IFU under the MDR, be explicitly mapped out as a design input if applicable?

e.g. would you have a labelling section of your DTM that has a design input of "label must show manufacturers name and address adjacent to manufacturer's symbol" and reference this back to the source requirement of the MDR and ISO 15223-1, or would you have this as a part of a separate specification document, or nothing at all?


Thanks,

TS
 
Elsmar Forum Sponsor

Tidge

Trusted Information Resource
#2
I have seen companies use a standard (i.e. defined) label review process with an accompanying checklist/worksheet. Minimally, the checklist covers the 'basics' required by regulatory authorities but it also includes the 'special labeling' included because of the specific product. This is by process, and if it is part of the greater design project it comes in through 'stakeholder needs' rather than 'user needs', where the key stakeholders are (typically) regulatory affairs and marketing.

The 'special labeling' includes things like symbols that are added because of the nature of the product. Those symbols typically get added not by specific requirements but as elements of a design output (i.e. the label) to address whatever reason (usually a risk) that the symbol is meant to be informing users about.
 

ThatSinc

Involved In Discussions
#3
This is by process, and if it is part of the greater design project it comes in through 'stakeholder needs' rather than 'user needs', where the key stakeholders are (typically) regulatory affairs and marketing.
I consider end users/medical practitioners/regulatory affairs (or more specifically the regulations of the regions planned for sale)/marketing/business stakeholders all under "users" in one way or another, but these are usually documented within separate requirements specs, by each department providing input to the project, reviewed against each other, conflicts resolved, and all mapped through to design inputs. Each stakeholder is defined clearly within these documents.

Those symbols typically get added not by specific requirements but as elements of a design output (i.e. the label) to address whatever reason (usually a risk) that the symbol is meant to be informing users about.
So in a system-level design traceability document, would you just refer the labelling/IFU content requirements out to the checklist/worksheet?

where would you document your input requirements for the label/ifu content?
 

indubioush

Quite Involved in Discussions
#4
Design input for labeling can be documented in a distinct section in your traceability matrix. Input can be requirements like, "Label must comply with applicable requirements from ISO 15223." Then you will have a label specification/checklist that has detailed requirements. This specification is referenced in the trace matrix. Verification that the label meets requirements is the completed checklist, which becomes part of the design history file.
 

ThatSinc

Involved In Discussions
#5
"Label must comply with applicable requirements from ISO 15223."
Where the stakeholder requirement is compliance with various regulations, in the system traceability matrix, would you include the labelling section and broadly state "labelling shall comply with relevant requirements of all regional regulations" with a reference back to the regulatory stakeholder need that you've documented which includes all regulations for planned markets?
or would you divide it out to each regulation? Seems like it would be overkill to divide it out if you're just going to repeat the same thing over and over but with a different regulation number.

Then the design output is the various labelling (including both labels, IFUs, practitioner guides, service manuals etc. etc) and your verification is the sign off against the checklist for the regulation?

That makes a lot of sense to me, and I suggested this, but was told that this would be a too broad approach.
 

indubioush

Quite Involved in Discussions
#6
or would you divide it out to each regulation?
I would make a bulleted list of all standards as one design input. However, you can do whatever makes sense for your organization as long as you have evidence of the following:
  • It was determined which standards were applicable to your device label (design input),
  • The design input above was reviewed and approved,
  • The labels (design output) were designed according to those requirements, were reviewed, and approved,
  • The labels (design output) were verified as meeting the standard requirements (design input) through a verification report or checklist, and
  • There is a method to ensure label compliance when labels are changed.
Note that I'm talking about the device label and not the IFU. I would have IFU requirements separated out.
 
Thread starter Similar threads Forum Replies Date
S Traceability of requirements to design and risk Design and Development of Products and Processes 3
shimonv Design input/output traceability for mechanical parts ISO 13485:2016 - Medical Device Quality Management Systems 31
S How to maintain a design traceability matrix ISO 13485:2016 - Medical Device Quality Management Systems 2
W Maintaining Component Traceability in DHR (Design History Record) 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 5
A Design Traceability Matrix Requirements 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 7
R Role of QA during Design and Development of Products and Processes Design and Development of Products and Processes 3
B Design Responsibilities for Mature Acquired Product Lines ISO 13485:2016 - Medical Device Quality Management Systems 3
I RWE Studies and Design Controls US Food and Drug Administration (FDA) 1
G How to record Regulations and Standards as Design Inputs? Design and Development of Products and Processes 15
B How to exclude empty rows in full factorial design analysis? Using Minitab Software 0
M Handling design changes with use-as-is inventory disposition Quality Manager and Management Related Issues 6
M Design Control - Management of Electronic CAD files Design and Development of Products and Processes 14
S Examples of FDA acceptable Software Design Specification (SDS) Medical Device and FDA Regulations and Standards News 6
A Design Change/ECO Related Question 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
R Using R package to implement Bayesian phase I/II dose-finding design for three outcomes ISO 13485:2016 - Medical Device Quality Management Systems 6
C ISO 9001:2015 8.3.2. h) Design and Development Planning - What is required? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 4
Z Software for design control ISO 13485:2016 - Medical Device Quality Management Systems 5
E Design and Development file Procedure ISO 13485:2016 - Medical Device Quality Management Systems 0
DuncanGibbons Section 8.3 relevant for design organisations AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 2
P DFMEA - Machinery Design Best Practices FMEA and Control Plans 0
R Is a FAIR required on parts that we design? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
U API Spec Q1 - 5.6.1.2 C (3) - Design software Oil and Gas Industry Standards and Regulations 3
N Example for design and development planning,input,output,review,verification,validation and transfer Misc. Quality Assurance and Business Systems Related Topics 4
A 8.6 Release of products and services, 8.3 Design and development - evidence required ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 9
C Stress / Challenge Conditions for Design Verification Testing to Reduce Sample Size 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 11
J Significant change related to design and intended use EU Medical Device Regulations 3
U NOC - What is considered a "design change" EU Medical Device Regulations 5
Q PPT used as Design Review ISO 13485:2016 - Medical Device Quality Management Systems 3
D Design Verification Sample Size vs Repeats Statistical Analysis Tools, Techniques and SPC 9
A Design and development procedure for API Spec Q2 Oil and Gas Industry Standards and Regulations 6
D Design controls - Inputs, outputs, V&V, DHF, DMR ISO 13485:2016 - Medical Device Quality Management Systems 10
LostLouie Manufacturer divorced from Design process, is he justified in design process deficiencies? ISO 13485:2016 - Medical Device Quality Management Systems 9
R DFA & DFM - Examples for Design for assembly and design for manufacturability Lean in Manufacturing and Service Industries 2
D Using Laboratory Notebooks in R&D and Design and Development ISO 13485:2016 - Medical Device Quality Management Systems 3
D ISO 13485 - 7.3.6 Design and development verification - Do most folks create a separate SOP? ISO 13485:2016 - Medical Device Quality Management Systems 6
K Joint approval between OEM and Manufacturer on Design Documents ISO 13485:2016 - Medical Device Quality Management Systems 4
M API 4F/7K/8C Design Package Validation Oil and Gas Industry Standards and Regulations 2
A Design History File - Not ready to share the design drawings or Bill of Material US Food and Drug Administration (FDA) 2
W Need for current design or process control FMEA and Control Plans 2
A What is the difference between Design Process, Process Design and Design Control? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
D Test summary report example for design validation wanted - ISO 13485 ISO 13485:2016 - Medical Device Quality Management Systems 1
B Why the Greek god Hephaestus should have done a design FMEA (DFMEA) on his giant robot APQP and PPAP 1
S Documenting Design Verification Test Results (ISO 9001) Design and Development of Products and Processes 1
DuncanGibbons Understanding the applicability of Design of Experiments to the IQ OQ PQ qualification approach Qualification and Validation (including 21 CFR Part 11) 5
S Requirement to Conduct New Shelf-life Testing? (re-do testing for design change) EU Medical Device Regulations 3
A Sample Agreement available for Outsourcing Medical Device Design activity? ISO 13485:2016 - Medical Device Quality Management Systems 1
DuncanGibbons How is the arrangement between Design and Production organisation envisaged? EASA and JAA Aviation Standards and Requirements 4
L Design & Development of a SERVICE Service Industry Specific Topics 13
C Documentation for items used for Design Verification 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
P Design verification driven by new equipment. How is this different than process validation? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1

Similar threads

Top Bottom