Design Traceability - Labelling / Instructions for Use

[ThatSinc]

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

 

[Tidge]

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]

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]

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]

"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]

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.