Research and planning

Internal working document

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

What BSI is asking

The IFU § Clinical Benefits and Performance Claims does not clearly explain which diagnostic features (ICD conditions, signs, measures) the reported metrics apply to. The tags used (7GH, 3KX, 8PL, 1QF, 9VW, 5RB, 0ZC) and study references (IDEI_2023, BI_2024, etc.) are not defined in the IFU, so a user cannot understand the context or applicability of the values.

Underlying concern (GSPR 15.1 / 23.4(c), (e), (h)): The IFU must communicate accuracy limits, measurement ranges, and conditions of use so that practitioners can make informed decisions. BSI wants to ensure users reading the IFU can understand what the performance metrics mean, which conditions they apply to, and which studies generated them.

Root cause analysis

The IFU is built as a Docusaurus app (/apps/eu-ifu-mdr/) and exported to PDF via Puppeteer. The Clinical Benefits and Performance Claims page (apps/eu-ifu-mdr/versioned_docs/version-1.1.0.0/clinical-user-manual/clinical-benefits-and-performance-claims.mdx) uses React components:

<ClinicalBenefitsList id="7GH" />
<ClinicalBenefitsList id="3KX" />
...

These components do render fully in the PDF. When Puppeteer captures the page, the user sees:

• The clinical benefit description (e.g., "The device improves accuracy of HCPs during the diagnosis of dermatological conditions...")
• Performance claim tables with achieved values, study IDs shown as badges, indication descriptions, and user groups
• Means of measure for each benefit

So BSI did see rendered content, not raw tags. The issue BSI is raising is more specific:

1. The 3-character codes (7GH, 3KX, etc.) appear as styled badges in the rendered output. These are internal identifiers for clinical benefits. While each benefit has a full description rendered next to its badge, the codes themselves are not defined in a glossary. BSI may have seen these codes and expected a formal definition table.

2. Study references like "IDEI_2023" and "BI_2024" appear as badges alongside individual performance claim results. However, the IFU does not include a bibliography or study reference section where these codes are expanded with full protocol details (investigators, sites, sample sizes, etc.).

3. ICD conditions and diagnostic features: The performance claims show indications like "Multiple conditions", "Melanoma", "Rare diseases", "Hidradenitis supurativa" — but the IFU does not provide a mapping from these labels to specific ICD-11 codes.

Relevant QMS documents

Document	Path	Relevance
IFU Clinical Benefits page	apps/eu-ifu-mdr/versioned_docs/version-1.1.0.0/clinical-user-manual/clinical-benefits-and-performance-claims.mdx	The page BSI reviewed — contains 7 ClinicalBenefitsList component calls
Clinical benefits definitions	packages/ui/src/components/PerformanceClaimsAndClinicalBenefits/clinicalBenefits.ts	Defines 7 clinical benefits with descriptions and filter criteria
Performance claims data	packages/ui/src/components/PerformanceClaimsAndClinicalBenefits/performanceClaims.ts	~148 performance claims with study IDs, metrics, values, indications
Clinical studies data	packages/ui/src/components/ClinicalValidation/clinicalStudiesData.ts	Study metadata: IDEI_2023, BI_2024, AIHS4 2025, etc. with investigators, sites, sample sizes
ClinicalBenefitsList component	packages/ui/src/components/PerformanceClaimsAndClinicalBenefits/ClinicalBenefitsList.tsx	React component rendering each benefit with performance data
R-TF-012-037 Labeling and IFU Requirements	apps/qms/docs/legit-health-plus-version-1-1-0-0/design-and-development/R-TF-012-037-Labeling-and-IFU-Requirements.mdx	IFU labeling requirements per MDR Annex I Ch. III
GSPR analysis	apps/qms/docs/legit-health-plus-version-1-1-0-0/GSPR/R-TF-008-001-General-Safety-and-Performance-Requirements-GSPR.mdx	GSPR 15.1 analysis and compliance statement

The seven clinical benefit tags and their meanings:

Tag	Clinical benefit
7GH	Improves accuracy of HCPs during diagnosis of dermatological conditions
3KX	Reduces waiting times for skin-related consultations
8PL	Improves precision of HCPs during referral
1QF	Improves accuracy of HCPs during diagnosis of lesions suspicious for skin cancer
9VW	Improves accuracy of HCPs during diagnosis of rare diseases
5RB	Measures degree of disease involvement objectively, quantitatively, and reproducibly
0ZC	Improves accuracy of HCPs during remote diagnosis and referral

Gap analysis

• Already had: All data exists in TypeScript files and renders correctly in the PDF. Each clinical benefit has a description, associated performance claims with metrics, study IDs, indications, and user groups. The study metadata (investigators, sites, sample sizes) exists in clinicalStudiesData.ts.
• BSI couldn't find: (a) A glossary or reference table defining the clinical benefit codes; (b) full bibliographic references for study codes; (c) explicit mapping between performance metrics and ICD conditions/diagnostic features.
• Needs updating (all completed — see action items below):
  1. The IFU needs a "Clinical Validation Studies" reference section (bibliography) Done: ClinicalStudiesReference component, commit a0a52d704
  2. The IFU needs a glossary/legend table defining the 3-character clinical benefit codes Done: ClinicalBenefitsGlossary component, commit a0a52d704
  3. The IFU needs clarifying text explaining the distributional nature of the device's output Done: "How to Read the Performance Claims" subsection, commit a0a52d704
  4. The IFU needs a study-to-benefit cross-reference table Done: StudyBenefitCrossReference component (added after self-review)
  5. The IFU "study population" wording needs to distinguish device function from clinical benefit Done: reworded after self-review

Device function vs clinical benefit — critical distinction

There is a counterintuitive aspect of the device's performance claims that must be handled carefully in communications with BSI. The device has condition-specific clinical benefits (e.g., 9VW: "improves accuracy during the diagnosis of rare diseases", 1QF: "improves accuracy during the diagnosis of lesions suspicious for skin cancer") but a uniform device output mechanism (identical full ICD-11 probability distribution for every image, regardless of the condition presented).

These two statements are not contradictory. The distinction is:

• Device function (uniform): The device always performs the same computational operation on every image — it produces a normalised probability distribution across all 346 validated ICD-11 categories. There is no condition-specific mode, no special pathway for rare diseases or melanoma. The algorithm does not "know" in advance what the image shows.
• Clinical benefit (context-dependent): The improvement in healthcare professional performance varies by clinical context because the HCP's baseline accuracy differs across condition categories. A dermatologist may have 56% baseline accuracy for rare diseases but 80% for common conditions. The device's distributional output provides the same quality of information in both cases, but the HCP derives proportionally more benefit in areas where their baseline is lower. This is why benefit 9VW (rare diseases, +26.77% relative improvement) shows a larger effect than benefit 7GH (multiple conditions, +15.12%).

Why this matters for BSI: The auditor may read "no condition-specific device function" alongside "improves accuracy for rare diseases" and conclude we are contradicting ourselves. The response must proactively explain this distinction in clear terms, because:

1. If BSI concludes the claims are contradictory, they may request us to either drop the condition-specific benefits or add condition-specific device functions — both of which would be incorrect.
2. The distinction is analogous to a calculator: the calculator performs the same arithmetic regardless of the problem domain, but a student benefits more from it in advanced mathematics than in basic arithmetic. The calculator's function is uniform; the educational benefit is context-dependent.

In the IFU: The "How to Read the Performance Claims" section now explicitly states this distinction. The "study population" bullet point has been reworded to clarify that the device output mechanism is identical for all images, while the clinical benefit varies because HCP baseline accuracy differs across conditions.

In the response to BSI: This must be explained clearly and positioned as the natural consequence of a decision-support tool: the tool is uniform, but the benefit varies with the user's baseline.

ICD-11 codes — not appropriate here

After reviewing the regulatory rationale documents (clinical-evidence-icd-distribution-rationale.md and icd-distribution-vs-diagnosis.md), adding ICD-11 codes to the performance claims data model would contradict the device's core regulatory position. The device always outputs a normalised probability distribution across all validated ICD-11 categories — the indications field represents the study sample composition, not a condition-specific device function. Adding ICD-11 codes per claim would imply condition-specific performance, contradicting the intended purpose ("interpretative distribution representation of possible ICD categories"), MDCG 2020-1, and the mathematical output definition. Instead, the IFU now cross-references the Intended Use section (which lists all ICD-11 categories) and clarifies the distributional nature of the output.

Response strategy

Regulatory mapping for this response:

GSPR / Annex II clause	How our corrective action addresses it
GSPR 15.1	Updated IFU clearly indicates accuracy limits per condition/context, enabling practitioners to understand the precision and applicability of decision-support information
GSPR 23.4(c)	Performance limitations and residual risks are now explicitly communicated per indication category
GSPR 23.4(e)	Accuracy limitations per condition type serve as precautions for clinical decision-making
GSPR 23.4(h)	Each performance metric now identifies the study that generated it, the user group for whom it was validated, and the clinical context of the study population
Annex II 6.1(a)	Performance characteristics documented in the technical file (R-TF-015-003 Clinical Evaluation Report) are now also clearly communicated in the IFU

Design decisions and rationale:

1. Clinical benefit glossary/legend. The 3-character codes (7GH, 3KX, etc.) are internal identifiers currently rendered as styled badges. Decision: keep the codes but add a legend table at the top of the Clinical Benefits and Performance Claims section that maps each code to its full clinical benefit description. This directly addresses BSI's concern ("Definitions for the tags ... could not be found in the IFU"). We deliberately use unique non-sequential identifiers rather than sequential numbering ("Clinical Benefit 1", "Clinical Benefit 2", etc.) for two reasons: (a) unique IDs guarantee traceability — the same identifier is used in the IFU, the technical file, risk management, and clinical evaluation, so there is never ambiguity about which benefit is being referenced; (b) sequential numbering would create an artificial sense of order or hierarchy among clinical benefits that does not exist — the benefits are independent claims, not a ranked or ordered list.

2. Study bibliography over ICD-11 codes. Rather than adding ICD-11 codes per claim (which would contradict the device's regulatory position), the IFU: (a) provides full study bibliographies via ClinicalStudiesReference, (b) explains that "study population" labels indicate the clinical context of the validation study, not a condition-specific function, (c) cross-references the Intended Use section for the full list of ICD-11 categories covered. See clinical-evidence-icd-distribution-rationale.md and icd-distribution-vs-diagnosis.md for the regulatory rationale.

3. Study-to-benefit cross-reference. Added after self-review identified that the traceability chain between studies and benefits was incomplete. The StudyBenefitCrossReference component dynamically computes which clinical benefits each study supports by cross-referencing claims data, so a user can see at a glance: "Study IDEI_2023 supports benefits 7GH, 1QF, 5RB" etc.

4. Device function vs clinical benefit distinction. Added after self-review identified a potential contradiction in the IFU: the device claims condition-specific benefits (9VW, 1QF) while stating there is no condition-specific device function. The response now explicitly explains this — the device output mechanism is uniform, but the clinical benefit varies because HCP baseline accuracy differs across condition categories. See the :::danger admonition above for the full reasoning.

Response tone rules (learned from self-review):

• Do NOT cite MDR Rule 11 or MDCG 2020-1. BSI did not question the regulatory classification. Citing these proactively reads as a pre-emptive defence and risks opening new lines of questioning. Let the IFU changes speak for themselves.
• Do NOT use technical jargon like "normalised probability vector summing to 1.0" in the response. The response is for an auditor, not a mathematician.
• Address all four GSPR clauses explicitly (15.1, 23.4(c), (e), (h)), not just 15.1. BSI cited all four and expects each to be addressed.
• Do NOT claim "Red-lined documentation is provided" unless it has actually been produced and is attached. The red-lining workflow is still TBD.

Action items (all completed):

#	Action	Owner	Document affected	Status
1	Add clinical studies reference section to IFU	Taig	ifu.pdf (eu-ifu-mdr)	Done
2	Add clinical benefit glossary/legend table to IFU	Taig	clinical-benefits-and-performance-claims.mdx	Done
3	Add clarifying text on distributional output and study context	Taig	clinical-benefits-and-performance-claims.mdx	Done
4	Add study-to-benefit cross-reference table to IFU	Taig	clinical-validation-studies.mdx	Done
5	Fix "study population" wording: device function vs clinical benefit	Taig	clinical-benefits-and-performance-claims.mdx	Done
6	Update es/pt localisations with new IFU sections	Taig	i18n clinical-benefits-and-performance-claims	Done
7	Write response to BSI addressing all four GSPR clauses	Taig	response.mdx	Done

Open items for clinical review round

The following issues are not part of this non-conformity but are flagged proactively because they will likely be raised by BSI during the clinical review. See fyi/question-for-jordi.mdx for full details and options.

1. MC_EVCDAO_2019 (Legacy Device): The IFU bibliography includes a study conducted with the predecessor device ("Legit.Health Legacy Device"). No bridging note or equivalence determination is visible in the IFU. A clinical reviewer will ask why evidence from a different device version is cited. Decision pending (Jordi).

2. AIHS4 2025 (n=2): The IFU bibliography includes a study with a sample size of 2 participants alongside properly powered studies (n=29–204). This undermines the credibility of the evidence package. Decision pending (Jordi).