M2: Software V&V
Major Non-Conformity
Code: 2650005-202501-M2
Status: Open: awaiting manufacturer response
Requirements and references
- GSPR 1, 17.2
- Annex II, 6.1(a), (b)
- EN 62304
- EN 82304-1
Documents reviewed by BSI
QMS-legit-health-plus-version-1-1-0-0-design-and-development-software-requirements.pdfQMS-legit-health-plus-version-1-1-0-0-design-and-development-R-TF-012-037-Labeling-and-IFU-Requireme.pdfwaf_*.pngtest_rail_verification_tests-44bb53ee75c87f0e606ac68be0733274_results.csv
Regulatory context
Internal working document
This section is for internal planning only. It will not be included in the final response to BSI.
M2 contains 3 questions about Software Verification & Validation. The non-conformity references GSPR 1, 17.2; Annex II 6.1(a)(b); EN 62304; and EN 82304-1. The core theme is missing or incomplete verification evidence: BSI can see the requirements and the test-case metadata but cannot find the actual execution artefacts proving they passed.
Regulatory requirements cited by BSI
Before analysing each question, we must understand what the cited requirements actually demand, because our responses must reference them explicitly.
| Requirement | What it says | How it applies to M2 |
|---|---|---|
| GSPR 1 (MDR Annex I) | Devices shall be safe and perform as intended when used under the conditions and for the purposes intended. | All V&V evidence must demonstrate the device performs as intended — including security (Q1) and labeling completeness (Q2, Q3). |
| GSPR 17.2 (MDR Annex I) | Software shall be developed and manufactured in accordance with the state of the art, taking into account the principles of development life cycle, risk management, including information security, verification, and validation. | Software V&V must follow EN 62304 life cycle. Verification evidence must be documented per state of the art. |
| MDR Annex II 6.1(a) | Technical documentation shall contain a description of the verification and validation activities undertaken, such as tests, and their results. | We must provide: description of V&V activities, acceptance criteria, and results — for ALL requirements, including labeling (Q2, Q3). |
| MDR Annex II 6.1(b) | Evidence of adequate verification, validation, and integration testing for the device. | The evidence artefacts themselves (not just pass/fail metadata) must be in the technical file. |
| EN 62304 § 5.5 (Software Verification) | Each software requirement shall be verified. Verification may be by test, inspection, analysis, or review (§ 5.5.2). Documented evidence of actual results vs. expected results is required. | Q1: T228 must have actual results, not just "Passed" in TestRail. Q2/Q3: labeling requirements can be verified by review (not test execution) per § 5.5.2. |
| EN 82304-1 § 5.2 | Health software products shall include documentation of verification and validation. Release documentation shall demonstrate the product meets specified requirements. | The technical file must include V&V documentation for the labeling/IFU requirements as part of the release package. |
| EN 82304-1 § 5.3 | Health software products shall be validated to confirm they meet intended use requirements. | IFU content (which implements labeling requirements) must be validated for fitness for purpose. |
Key insight for the response
EN 62304 § 5.5.2 explicitly permits verification by review, inspection, or analysis — not only by test execution. This is critical for Q2 and Q3: labeling requirements are documentation requirements, and content review is the appropriate verification method per the standard. Our response must cite this to justify the verification approach.
Action items for the team
| # | Action | Owner | Deliverable | Notes |
|---|---|---|---|---|
| 1 | Extract T228 evidence from S3 | Gerardo | HTTP 200 and 429/403 response screenshots, audit log entries from test execution | From s3://.../test_run_228/. Include in bookmarked PDF. |
| 2 | Confirm and document AWS WAF default action (Block) | Gerardo | Screenshot of AWS WAF default action configuration + brief written statement | Needed for part 5 (fail-secure) architecture analysis. |
| 3 | Write fail-secure architecture analysis | Taig | Brief analysis document or addendum to R-TF-030-003 | Document WAF default-Block + Shield + API Gateway auth as layered fail-secure. Cite EN 62304 § 5.5.2 (verification by analysis). |
| 4 | Extract FHIR test evidence from S3 (T230, T271) | Gerardo | API request/response payloads showing complete DiagnosticReport JSON | From s3://.../test_run_230/ and test_run_271/. Include in bookmarked PDF. |
| 5 | Create labeling requirements verification record | Taig / Saray | New annex to R-TF-001-006 with per-LR-XXXX verification table | Must include: verification method (EN 62304 § 5.5.2 content review), acceptance criteria, IFU section reference, pass/fail, verified by. |
| 6 | Execute labeling verification | Saray | Completed verification table (26 rows, all verified against IFU v1.1.0.0) | Review each LR-XXXX against the actual IFU/label content. |
| 7 | Update R-TF-012-043 traceability matrix | Taig | Updated matrix with LR-XXXX codes traced to verification record | Currently mentions R-TF-012-037 in scope but does not trace LR codes. |
| 8 | Red-line updated documents | Taig | Red-lined PDFs of R-TF-001-006, R-TF-012-043, and R-TF-030-003 (if modified) | Required per BSI submission instructions. |
| 9 | Compile supplementary evidence PDF | Saray | Single bookmarked PDF with all evidence artifacts | T228 evidence, T230/T271 evidence, WAF config screenshot, labeling verification record. |
Relevant Slack context
- Saray (2026-01-29): Created R-TF-012-037 and explained that labeling requirements (LR-xxx) are "medidas de mitigacion tipo C" (Type C risk mitigation measures — documentation-based). This confirms that these requirements are meant to be verified through documentation review, not software testing.
- Saray (2026-02-10): Confirmed BSI will send only one round of additional questions per reviewer (technical, clinical, AI). Technical round came Feb 28. Deadline is March 17.
- Alfonso (2026-01-12): Noted that BSI "audits your Software Architecture and your Verification testing evidence — they want to see the blueprint and the crash test results, not the bricks." This is relevant: BSI wants the evidence artefacts, not the source code.