Research and planning

Internal working document

This page is for internal planning only. It will not be included in the final response to BSI.

Analysis

What BSI is asking: BSI cannot find any verification or validation evidence for the 26 labeling requirements defined in R-TF-012-037. Specifically, they cannot find:

1. A V&V plan for labeling/IFU requirements
2. Traceability showing each LR-XXXX requirement was verified/validated
3. Test protocols and test results
4. A verification or validation summary report

What standard is at stake:

• EN 62304 § 5.5: All requirements must be verified. However, § 5.5.2 permits verification by review/inspection/analysis — not only by test execution. This is critical because labeling requirements are documentation requirements, not software behaviour requirements.
• MDR Annex II 6.1(a): The technical documentation must contain a "description of the verification and validation activities undertaken... and their results." This means we need a documented verification activity with results, even if the method is content review.
• MDR Annex II 6.1(b): "Evidence of adequate verification, validation, and integration testing." The evidence itself must be in the technical file.
• EN 82304-1 § 5.2-5.3: Release documentation must demonstrate the product meets specified requirements; the product must be validated for intended use.

Underlying concern: The labeling requirements (LR-XXXX codes) exist as a defined set of design inputs, but they live in a parallel universe from the software V&V framework. The traceability matrix R-TF-012-043 mentions R-TF-012-037 in its scope (as "Regulatory Requirements (RR)") but only traces SRS → Test Cases, not LR → verification evidence.

Why BSI cites EN 62304 for labeling requirements: R-TF-012-037 sits in the design-and-development folder as part of the software documentation set. BSI is treating labeling requirements as design inputs that entered the EN 62304 life cycle (§ 5.2 — software requirements analysis), which means they require verification per § 5.5. This is a reasonable interpretation because the labeling requirements are formal design inputs that trace to risk mitigations.

Relevant QMS documents and sections

Document	Path	Relevance
R-TF-012-037 Labeling Requirements	apps/qms/docs/legit-health-plus-version-1-1-0-0/design-and-development/R-TF-012-037-Labeling-and-IFU-Requirements.mdx	The 26 labeling requirements (LR-XXXX codes). Does NOT describe verification activities.
labeling-requirements.json	apps/qms/src/components/LabelingRequirements/labeling-requirements.json	Data source: 26 entries, each with code, name, description, location (Label/IFU), category, and mitigatesRisks array
R-TF-001-006 IFU and Label Validation	apps/qms/docs/legit-health-plus-version-1-1-0-0/information-provided-by-the-manufacturer/R-TF-001-006-IFU-and-Label-Validation.mdx	Validates label (MDR §23.2) and eIFU (Commission Regulation 2021/2226). Does NOT reference specific LR-XXXX codes. Validates at regulatory-checklist level, not design-input level.
R-TF-012-043 Traceability Matrix	apps/qms/docs/legit-health-plus-version-1-1-0-0/design-and-development/R-TF-012-043-Traceability-Matrix.mdx	Mentions R-TF-012-037 in scope (line 55) as "Regulatory Requirements (RR)" but only traces PR → SRS → Test Cases. Coverage: 18 PRs (100%), 122 SRS (100%), 145 test cases (144 passed, 1 skipped). Does NOT trace LR codes.
EU IFU MDR (the IFU itself)	apps/eu-ifu-mdr/versioned_docs/version-1.1.0.0/	The actual IFU content that IMPLEMENTS the labeling requirements
R-TF-025-007 Summative Evaluation Report	apps/qms/docs/legit-health-plus-version-1-1-0-0/product-verification-and-validation/usability/R-TF-025-007-Summative-Evaluation-Report/	Usability testing of IFU (validates comprehensibility, not content completeness)
R-TF-012-026 Phase 5 Checklist	apps/qms/docs/legit-health-plus-version-1-1-0-0/design-and-development/R-TF-012-026-Product-Validation-Phase-5-Checklist.mdx	Includes "Information Provided by Manufacturer" section that checks IFU completeness, intended use, contraindications, warnings, technical specifications, and label regulatory information. Evidence that IFU/label WAS reviewed during design.
GP-012 Design, Redesign and Development	apps/qms/docs/procedures/GP-012/index.mdx	Phase 5 (Product Validation) explicitly lists "Labelling / User manual / Translation" as an activity. Design review in Phase 5 covers IFU and label.
R-TF-013-002 Risk Management Record	apps/qms/docs/legit-health-plus-version-1-1-0-0/risk-management/R-TF-013-002-Risk-Management-Record/	35 Type C controls for labeling. verificationOfImplementation references software test cases. verificationOfEffectiveness references Summative Evaluation (T-TF-025-007) and CER (R-TF-015-003).
GP-001 Control of Documents	apps/qms/docs/procedures/GP-001/index.mdx	Defines document control: responsibilities.json + Signature component + GPG-signed commits as evidence of authorship, review, and approval per 21 CFR Part 11. Applies to all records including R-TF-001-006.

Gap analysis

What we have:

• 26 labeling requirements clearly defined (LR-4XK through LR-6HS) with descriptions, locations (Label/IFU), categories, and risk mitigations
• R-TF-001-006 validates the IFU and label against MDR Annex I Chapter III §23.2 and Commission Regulation 2021/2226
• R-TF-001-006 includes a comprehensive compliance table for eIFU requirements (Articles 4-7)
• The IFU itself is developed, deployed, and maintained as code with the same V&V rigour as the device (Git, GPG-signed commits, branch approvals, CI/CD, automated verification)
• Usability testing (R-TF-025-007) validates IFU comprehensibility
• Risk management (R-TF-013-002) traces risks to labeling mitigations
• Phase 5 Product Validation design review (R-TF-012-026) includes an "Information Provided by Manufacturer" section that checks IFU completeness, intended use, contraindications, warnings, technical specifications, and label regulatory information — all marked as ✓ with references to R-TF-001-006. This confirms IFU/label content WAS reviewed during development at the regulatory-checklist level.
• R-TF-013-002 verificationOfEffectiveness for Type C labeling controls references T-TF-025-007 Summative Evaluation Report and R-TF-015-003 Clinical Evaluation Report — the ISO 14971 § 7.3 effectiveness loop is closed through usability and clinical evaluation.

What's missing (BSI's concerns are partially valid):

The IFU and label content was reviewed during development (Phase 5 design review, R-TF-012-026), but the review was at the regulatory-checklist level, not at the individual LR-XXXX design-input level. Specifically:

1. No per-requirement traceability from each LR-XXXX code to a specific verification result — EN 62304 § 5.5 requires each requirement to be verified, and the Phase 5 checklist verifies IFU content by category (intended use, warnings, etc.) rather than by individual LR code
2. No verification results table documenting acceptance criteria and pass/fail per LR code — MDR Annex II 6.1(a) requires "results"
3. No labeling requirements in the traceability matrix — R-TF-012-043 mentions R-TF-012-037 in scope but only traces PR → SRS → Test Cases, not LR → verification evidence

Note: BSI also asked for "a plan for verification/validation of requirements." The verification of IFU/label content is a planned Phase 5 activity in GP-012 (which lists "Labelling / User manual / Translation" explicitly). However, the plan does not describe per-LR-code verification as a distinct step. The new verification section in R-TF-001-006 addresses this by documenting the method, scope, and results — effectively serving as both plan and report for this activity.

Root cause of the gap: The labeling requirements (created by Saray on 2026-01-29, per Slack) are a relatively recent addition to the design input documentation. They were defined as risk mitigation measures of "type C" (documentation-based mitigations). While the IFU validation document (R-TF-001-006) validates the IFU against regulatory requirements at the MDR level, and the Phase 5 checklist confirms IFU content completeness by category, neither document traces back to the specific LR-XXXX codes. The V&V framework was built around software requirements (SRS codes) and does not extend to labeling/regulatory requirements at the individual design-input level.

Important distinction — verification method: Unlike SRS requirements where verification means "run a test and check the software behaves correctly", labeling requirements are documentation requirements — verification means "confirm the IFU/label contains the specified information". Per EN 62304 § 5.5.2, verification by review or inspection is explicitly permitted. This is the appropriate verification method for content requirements, and the response must cite this clause to justify the approach.

Response strategy

Approach: Reference existing Phase 5 design review + add per-requirement traceability + update traceability matrix

The gap is narrower than it first appears. IFU/label content WAS reviewed during development (Phase 5 design review). What's missing is per-LR-code traceability. The strategy is:

1. Reframe the gap: Per-requirement verification of labeling requirements was not documented with individual traceability. The IFU and label content was reviewed during the Phase 5 Product Validation design review (R-TF-012-026, section "Information Provided by Manufacturer"). The update adds formal per-requirement traceability to that existing review activity.

2. Add per-requirement verification to R-TF-001-006 as a new section "Labeling requirements verification". The section contains:

   Verification method statement (citing EN 62304 § 5.5.2): "Labeling requirements are design inputs specifying information content that must appear in the IFU and/or label. Per EN 62304 § 5.5.2, verification is performed by review: each requirement is verified by confirming the IFU/label version 1.1.0.0 contains the specified information."

   Verification results table — columns: LR Code, Requirement, Location (Label/IFU), Implementing section, Acceptance criterion, Result (pass/fail).

   No "Verified by" column needed — our document control system (GP-001) uses responsibilities.json + Signature component + GPG-signed verified commits as evidence of authorship, review, and approval per 21 CFR Part 11. This applies uniformly to all records, including R-TF-001-006. Adding a "Verified by" column would be redundant with the established system and inconsistent with every other record in the QMS.

   Verification summary: "All 26 labeling requirements have been verified against IFU version 1.1.0.0 and the device label. 26 of 26 requirements passed."

3. Update R-TF-012-043 (traceability matrix) with Part 4: Labeling Requirements (LR) to Verification Evidence. Traces 26 LR codes to their verification evidence in R-TF-001-006.

4. In the response to BSI:

   • Reference R-TF-012-026 Phase 5 design review as the existing verification activity
   • Describe the per-requirement verification record added to R-TF-001-006
   • Describe the traceability update in R-TF-012-043
   • Do NOT over-share about git/GPG/CI/CD — this is our document control system (GP-001), not a labeling V&V matter
   • Do NOT add a paragraph about risk control effectiveness — the ISO 14971 § 7.3 loop is already closed via T-TF-025-007 and R-TF-015-003 in R-TF-013-002, and mentioning it could open new lines of questioning

Confidence level: Medium-High. The gap is real but narrower than initially assessed — we had Phase 5 design review covering IFU/label at the category level; we just lacked per-LR-code traceability. The new verification record in R-TF-001-006 with 26-row results table should satisfy BSI's request for "traceability demonstrating that the requirements have been verified" and "associated test protocols and results." The main risk is whether BSI considers content review (EN 62304 § 5.5.2) sufficient or expects TestRail-style test execution.

Key research findings

Finding 1: Phase 5 design review already covers IFU/label content

GP-012 Phase 5 (Product Validation) explicitly lists "Labelling / User manual / Translation" as a design phase activity. The Phase 5 checklist (R-TF-012-026) includes a section "Information Provided by Manufacturer" with a table that checks IFU completeness, intended use, contraindications, warnings, technical specifications, and label regulatory information — all marked ✓ with references to R-TF-001-006.

Implication: The NC is not "we didn't verify labeling requirements during development." It is "the Phase 5 design review verified IFU/label content at the regulatory-checklist level, but did not trace individual LR-XXXX codes." This is a much narrower and less serious gap.

Finding 2: No "Verified by" column needed — existing document control system applies

Our QMS document control system (GP-001) uses:

• responsibilities.json: Defines who should author/review/approve each document (role-based governance)
• Signature component: Renders expected roles on every document and directs to verified commits
• GPG-signed commits: Provide cryptographic evidence of who did what and when, per 21 CFR Part 11

R-TF-001-006 inherits from GP-001: Author = team members involved, Reviewer = JD-003 & JD-004, Approver = JD-001. The commit history for the labeling verification section IS the evidence. Adding a "Verified by" column to the table would be redundant and inconsistent with every other record in the QMS.

Finding 3: Risk control effectiveness loop is already closed

R-TF-013-002 contains 35 Type C (information-based) controls for labeling. For these controls:

• verificationOfImplementation references software test cases (C382, C383, etc.) — these verify device functionality, not IFU content. R-TF-001-006's new section adds the content verification layer.
• verificationOfEffectiveness references T-TF-025-007 Summative Evaluation Report and R-TF-015-003 Clinical Evaluation Report — usability testing and clinical evaluation confirm the information actually reduces risk.

The ISO 14971 § 7.1 (implementation) and § 7.3 (effectiveness) loops are closed. However, R-TF-013-002 does not directly cross-reference R-TF-001-006 — the traceability is indirect (Risk → LR codes → R-TF-001-006 verifies LR codes). This is adequate but could be strengthened in a future update. We should NOT address this in the BSI response as it could open new lines of questioning.

Cross-NC connection: Q2 and QC are two sides of the same coin

Auditor reasoning pattern

Q2 and QC (IFU usability results) are not independent findings — they reflect the auditor systematically checking the complete V&V story for the IFU:

• Q2 = Verification: Are the 26 labeling requirements (LR-XXXX) present and correct in the IFU/label? BSI asked for "verified and/or validated" — the verification leg is content completeness, addressed by the per-requirement review table in R-TF-001-006.
• QC = Validation: Does the IFU actually work for users? Under IEC 62366-1 §5.9, usability testing of the IFU is the mechanism by which IFU validation is demonstrated. The auditor was looking for explicit conclusions about whether users could access, read, comprehend, and apply the IFU content — i.e., evidence that the labeling information achieves its intended purpose.

This explains why the auditor looked for specific explicit IFU validation in the usability results: they see usability testing as the validation leg of labeling V&V. The two NCs together form a single compliance question: "Show me that your IFU has the right content (Q2) AND that it works (QC)."

Our responses already cross-reference each other (Q2 cites R-TF-025-007 as validation evidence per EN 82304-1 §5.3; QC cites R-TF-001-006 for content verification). Keeping this alignment consistent across both responses strengthens the overall narrative.

Potential weaknesses (BSI auditor perspective)

Internal working document

These concerns were identified through a critical review of our response from the BSI auditor's perspective. Items marked ✅ have been addressed in the response. Items marked ⚠️ remain unaddressed and may be raised in Round 2.

✅ Addressed concerns

1. V&V plan not addressed in response. BSI explicitly asked for "a plan for verification/validation." The response now references GP-012 Phase 5 as the planned activity that includes labeling V&V, and describes how the verification method statement in R-TF-001-006 implements that planned activity.

3. Validation not mentioned. BSI asked about "verified and/or validated." The response now references R-TF-025-007 summative usability evaluation as the validation evidence for labeling effectiveness (EN 82304-1 § 5.3).

8. EN 82304-1 only referenced in passing. BSI cited EN 82304-1 as a basis for the NC. The response now explicitly addresses EN 82304-1 § 5.2 (release documentation) and § 5.3 (validation for intended use) alongside EN 62304 and MDR Annex II.

⚠️ Unaddressed concerns (potential Round 2 risks)

2. Response framing implies retroactive creation. The response says "this per-requirement traceability has now been added." The word "now" tells BSI the documentation was created after the NC was raised (commit date 2026-03-01, NC received 2026-02-28). A better framing would be: "the verification activity was performed during development (Phase 5 design review, R-TF-012-026); the per-requirement documentation of that activity has been formalized in R-TF-001-006." This reframes from "we hadn't done it" to "we did it but didn't document it at the individual LR level." Both statements are true — the Phase 5 design review did happen — but the current framing is weaker.

4. R-TF-012-043 Part 4 is thin compared to Parts 2 and 3. Parts 2 and 3 contain data-driven tables (React components with full row-by-row traceability). Part 4 is three paragraphs and a bullet list that says "go look at R-TF-001-006." An auditor expects the traceability to be IN the traceability matrix, not delegated to another document. Consider adding a data-driven table to Part 4 showing each LR code traced to its verification evidence location and result, consistent with how Parts 2 and 3 are structured.

5. Verification method statement is not structured as a test protocol. BSI asked for "associated test protocols." The verification method paragraph in R-TF-001-006 reads as a justification for using content review rather than a formal protocol. A protocol typically includes: scope (26 LR codes from R-TF-012-037), method (content review per EN 62304 § 5.5.2), items under review (IFU v1.1.0.0 and device label), acceptance criteria definition, and references. The content is there but the structure is narrative rather than protocol-like.

6. Who performed the verification? The M2 action items assign verification execution to Saray (action item #6), but the commit was authored by Taig (commit 2d16b03b2). If BSI asks who performed the verification and whether they had the competence and independence to do so, the answer must be clear. GP-001's Signature component handles authorship/review/approval at the document level, but the verification activity itself (reviewing 26 requirements against the IFU) should have a clear performer. Ensure the commit and review chain reflect the actual verification workflow.

7. Some acceptance criteria are restatements of the requirement. Several acceptance criteria in the verification table paraphrase the requirement rather than defining a testable criterion. For example, LR-7MN's criterion is "IFU specifies intended purpose, target users (HCPs, ITPs), device function, and clinical decision support nature" — this describes what should be there, not what constitutes a pass. A stricter auditor might flag this. Low risk but worth noting.