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: Provide complete verification evidence, including full test results, for requirement LR-7XP ("HL7 FHIR interoperability standard compliance").

What standard is at stake: Same as Q2 — EN 62304 § 5.5 (each requirement must be verified), MDR Annex II 6.1(a)(b) (verification description and evidence must be in technical file), GSPR 17.2 (V&V per state of the art).

Underlying concern: LR-7XP is a labeling requirement that says "the IFU shall document the device's compliance with HL7 FHIR". BSI wants to see the evidence chain: requirement → verification activity → actual results. This is a specific instance of the Q2 gap applied to a high-profile interoperability claim.

LR-7XP requirement detail

LR-7XP specifies three sub-points that the IFU must document:

1. The device outputs follow FHIR specifications, returning a DiagnosticReport resource
2. DiagnosticReport status is marked as 'preliminary' to indicate outputs support, not replace, clinical judgment
3. FHIR-compliant data format for healthcare system integration

All three must be verified in the IFU content.

Relevant QMS documents and sections

Document	Path	Relevance
LR-7XP definition	apps/qms/src/components/LabelingRequirements/labeling-requirements.json (code: LR-7XP)	Full requirement: 3 sub-points about FHIR documentation in IFU. Mitigates risks R-2TP, R-HBD, R-U6M.
IFU Endpoint Specification	apps/eu-ifu-mdr/versioned_docs/version-1.1.0.0/installation-manual/endpoint-specification.mdx	Line 21: "you send images, and you receive a DiagnosticReport as defined in HL7's FHIR specifications". Line 40: DiagnosticReport status is preliminary. Covers all 3 sub-points of LR-7XP.
IFU Security Requirements	apps/eu-ifu-mdr/versioned_docs/version-1.1.0.0/installation-manual/security-requirements.mdx	Documents FHIR-compliant data handling
SRS-F05 ("Generate FHIR DiagnosticReport Base Structure")	apps/qms/src/components/SoftwareRequirements/software-requirements.json (line ~531)	The software requirement that implements FHIR compliance in the device
Direct SRS-F05 tests (2 tests)	Traceability matrix	T230 (C368): "Verify FHIR DiagnosticReport base structure for a detector" — Passed. T271 (C453): "Verify FHIR DiagnosticReport base structure for a segmenter" — Passed. Both reviewed and approved by Gerardo Fernández.
Related DiagnosticReport tests (5 tests)	TestRail CSV	T231 (SRS-FMG): analysisDuration field. T235, T236 (SRS-K6N): imageAnalyses array structure. T239, T240 (SRS-W5Z): identifier assignment and uniqueness. All Passed. These verify specific DiagnosticReport fields but map to different SRS codes.
S3 evidence for T230	s3://legit-health-plus/software-tests/v1.1.0.0/02_software_verification/preproduction/test-plan-13/test_run_230/	Actual API request/response payloads showing FHIR DiagnosticReport output
S3 evidence for T271	s3://legit-health-plus/software-tests/v1.1.0.0/02_software_verification/preproduction/test-plan-13/test_run_271/	Actual API request/response payloads showing FHIR DiagnosticReport output

Gap analysis

What we have:

• LR-7XP clearly defined with 3 sub-points: DiagnosticReport resource, preliminary status, FHIR-compliant format
• The IFU does document FHIR compliance — the Endpoint Specification (line 21) explicitly says "you receive a DiagnosticReport as defined in HL7's FHIR specifications" and (line 40) mentions preliminary status. All 3 sub-points of LR-7XP are addressed.
• 2 tests directly verify SRS-F05 (FHIR DiagnosticReport base structure):
  • T230 (C368): Verifies DiagnosticReport for detector models — Passed
  • T271 (C453): Verifies DiagnosticReport for segmenter models — Passed
• 5 additional tests verify specific DiagnosticReport fields (mapped to other SRS codes):
  • T231 → SRS-FMG: analysisDuration field present and non-negative
  • T235 → SRS-K6N: single image maps to structured imageAnalyses object
  • T236 → SRS-K6N: multiple images map to distinct imageAnalyses objects
  • T239 → SRS-W5Z: identifier assigned to DiagnosticReport
  • T240 → SRS-W5Z: identifiers are unique across reports
• All 7 tests passed, reviewed and approved by Gerardo Fernández (2026-01-17)
• S3 evidence locations are defined for each test (API request/response payloads)

What's missing:

• No formal verification record that says "we checked the IFU and confirmed it documents FHIR compliance per LR-7XP" — this is a subset of the Q2 gap
• The actual S3 evidence (API request/response payloads) was not included in the submission package

Response strategy

Approach: Two-layer response — labeling verification (content review) + software verification (test evidence)

LR-7XP is unique because it bridges labeling and software: it's a labeling requirement ("the IFU shall document...") but its claim is supported by software verification (the device IS FHIR-compliant). We provide both layers:

1. Labeling verification (from Q2): Reference the labeling verification record created for Q2. Show that LR-7XP has been verified — the IFU Endpoint Specification documents all 3 sub-points:

   • Sub-point 1 (DiagnosticReport resource): Line 21 — "you receive a DiagnosticReport as defined in HL7's FHIR specifications"
   • Sub-point 2 (preliminary status): Line 40 — DiagnosticReport marked preliminary
   • Sub-point 3 (FHIR-compliant format): Line 36 — "which adheres to the FHIR standard"

2. Software verification evidence: Demonstrate the device actually produces FHIR-compliant output (proving the IFU's claims are truthful):

   • 2 direct FHIR tests (T230, T271) verify SRS-F05 — provide the actual S3 evidence (API request/response payloads showing complete DiagnosticReport)
   • 5 related tests (T231, T235, T236, T239, T240) verify specific DiagnosticReport fields — reference these for comprehensive coverage
   • Each test has expected results detailing the DiagnosticReport structure (identifier, issuedAt, analysisDuration, imageAnalysis, findings, etc.)

3. Provide actual S3 evidence in the bookmarked PDF: Extract from S3 the API response payloads for T230 and T271, showing complete FHIR DiagnosticReport JSON. This is the "full test results" BSI is asking for. Do NOT use the marketing website example (AnonymousDiagnosticReport component) — use the actual test execution evidence.

4. Cite the regulatory basis: Reference EN 62304 § 5.5.2 for the labeling verification (content review) and EN 62304 § 5.5 for the software verification (test execution). Reference MDR Annex II 6.1(a)(b) for completeness.

Confidence level: High. Strongest position of the three questions. The IFU clearly documents FHIR. The software is comprehensively tested (7 related tests, 2 directly on SRS-F05). Once we provide the actual S3 evidence and the labeling verification record from Q2, this question is fully addressed.