Item 0 — Background, Regulatory Guides & Meeting Records

What this folder is

This is item-0 of the Clinical Review Round 1. It is not a formal BSI question item. Rather, it is the foundational context folder that must be understood before working on any of the seven formal items (item-1 through item-7).

It contains:

1. The regulatory guidance documents BSI expects the Clinical Evaluation to follow.
2. The full transcript of the BSI clarification meeting (2026-03-25), which is the most important source of unwritten context about what BSI actually wants.
3. The two internal post-meeting analysis sessions, where the team decoded BSI's feedback and defined the response strategy.
4. A calendar screenshot of the BSI meeting for reference.

Start here. If you are working on any clinical item without having read this folder, you are missing critical strategic context that changes how every item must be approached.

---

Files in this folder

File	Type	What it contains
meeting-transcript-with-bsi-2026-03-25-at-15-12-12.txt	Plain text	Full auto-transcript of the BSI clarification call on March 25, 2026 (15:12). The primary source of BSI's unwritten expectations. Contains candid, off-the-record-level feedback from both Erin (clinical evaluator) and Nick (senior reviewer). Must be read fully.
meeting-transcript-and-notes-internal-2026-03-25-at-16-22.md	Markdown	Notes + auto-transcript of the internal debrief held the same afternoon (16:22). Contains Gemini-generated meeting notes in Spanish summarising conclusions, plus the full transcript. Defines the first set of action items.
meeting-transcript-and-notes-internal-2026-03-26-at-11-44.md	Markdown	Notes + auto-transcript of the internal meeting the following morning (March 26, 11:44). Resolves the regulatory strategy question: which guidance document(s) to follow. Concludes with the combined MDCG + MEDDEV 2.7.1 Rev 4 approach.
screenshot-2026-03-26-at-12-48-34.png	Image	Calendar invite for the BSI meeting. Shows attendees from both sides.
MDCG-2020-6/	Folder (chunked PDF)	MDCG 2020-6 guidance document, split into 5-page chunks for AI ingestion. The primary MDR-era guidance for clinical evaluation. Defines document structure and MDR-specific requirements. Saray refers to this family of documents as "MDSG 2020/1 — Guidance on Clinical Evaluation, Performance Evaluation of Medical Device Software"; Jordi refers to the latest version as "MDCG 2026". The filename in this folder is MDCG-2020-6. Key internal sections: Appendix 1 lists which sections of MEDDEV 2.7.1 Rev 4 remain applicable under MDR; Appendix 3 provides the clinical data quality hierarchy for class 3 devices (more evidence = higher on the hierarchy); and the guidance includes a checklist for conformity assessment of the evaluation report — this is the literal checklist auditors use.
MEDDEV-2-7-1-rev-4/	Folder (chunked PDF)	MEDDEV 2.7.1 Rev 4 guidance (2016), split into 5-page chunks. Nick explicitly recommended this document. Defines the clinical evaluation process in stages 0–5. These stages are what the CER must visibly follow. Nick said: "Unless you complete stages 0, 1, 2, 3, 4, 5 — they won't work and it will fall down."
relationship-between-MDCG-2020-6-and-MEDDEV-2-7-1-rev-4/	Folder (chunked PDF)	Single-page document explaining which sections of MEDDEV 2.7.1 Rev 4 remain applicable under MDR. Jordi found this during the March 26 meeting — it resolves the question of which guide to follow without needing to ask Erin. Confirms the combined strategy: use MDCG for structure, MEDDEV for process rigor.

---

People who attended the BSI meeting

BSI side:

Name	Role	Notes
Erin Preiss (erin.preiss@bsigroup.com)	Clinical Evaluation Specialist	Meeting organiser. The assigned clinical reviewer. Had reviewed the documents before the call.
Simon Lidgate (simon.lidgate@bsigroup.com)	Unknown / senior BSI staff	Listed as attendee. Did not speak prominently in the transcript.
Nick (surname not confirmed)	Senior clinical reviewer	Not on the calendar invite, joined the call. Gave the most direct and candid feedback. Referenced MEDDEV 2.7.1 Rev 4 explicitly. Issued the warning about likely refusal.

Legit.Health side (from calendar invite):

Name	Role
Saray Ugidos	Regulatory / clinical — attended, spoke
Alfonso Medela	Attended
Jordi Barrachina	Attended, spoke
Taig Mac Carthy	Attended, led discussion

March 26 internal meeting additional attendee:

Name	Notes
Ignacio Hernández (ignaciohernandez@legit.health)	Invited to the March 26 internal meeting. Did not speak in the recorded transcript.

External contacts mentioned:

• Arancha: An external person (likely a consultant) that Saray was planning to call in connection with the clinical review work. Identity and role not fully specified in the transcripts.

---

What BSI told us: the full picture

1. The situation is very serious

Nick stated explicitly and candidly that:

• This application has been open for a long time and was previously close to being refused.
• As of 2026, BSI has a new policy: non-conformities in clinical review can only be closed out via one small round of clarification. There is no indefinite back-and-forth.
• In his view, at the time of the meeting, refusal is extremely likely if the identified gaps are not closed.
• He raised the option of voluntarily withdrawing the application, getting proper expert help, and resubmitting from scratch. This is not a rhetorical suggestion — he genuinely presented it as a viable alternative.
• The team declined withdrawal because the device is on the market under MDD Article 120, so transitioning to MDR is mandatory. Withdrawal is not a real option.

This context is essential. Every item must be treated as if it directly determines whether we get CE marking.

2. The core problem: lack of traceability and a broken storyline

Both Erin and Nick described the same fundamental issue from different angles. The documents do not tell a coherent, traceable story. Specifically:

• A reviewer cannot follow the chain: state of the art → clinical benefit definition → performance acceptance criteria → clinical data → how data meets criteria.
• Statements are made without it being clear how they are supported. This is not just a formatting problem — BSI cannot tell whether the data is actually sufficient because the reasoning is not visible.
• Nick said: "We're not even sure what we're seeing at this point because of the way it's being presented."
• Erin described it as: "It's not clear if you make a statement how that statement is supported — and that traceability element is usually what is lacking."

This is the #1 thing to fix across all items. Every claim, every acceptance criterion, every data table must have a visible chain of reasoning.

3. The CER is not stand-alone

BSI reviews the CER in isolation. They do not cross-reference other documents unless explicitly pointed to. This means:

• The device description must be inside the CER itself: what the device is, what its output looks like, what the interface shows, what it does NOT do.
• The explanation of the intended purpose must be inside the CER.
• The clinical validation strategy (what types of data, why they are appropriate, why the sample sizes are sufficient) must be explained in prose inside the CER.
• The CER cannot assume the reviewer has read the IFU, the device description annex, or any other document.
• The CER needs a "how to read this document" section at the start — an explanation of the table structure, what each column means, and how to navigate the evidence. The team discussed this specifically: "Tenemos esta tabla que es maravillosa con tales columnas que aquí está la explicación de cómo es la tabla. Meter un poquito como que eso que empiecen leyendo eso y les quede claro todo lo demás."

3a. The CER must use prose with regulatory language, not just tables

This is a separate but related insight from the internal meeting. Jordi confirmed that the studies ARE already scored and rated by quality ("están baremados los estudios por calidad"). The data is correct. But it is presented in tables and structured data files (JSON), which BSI cannot easily follow or audit.

What is needed:

• Prose narrative explaining the validation strategy, not just tables.
• The prose must use the exact words from the MDR and from the MDCG guidance. Auditors work from a checklist — they look for specific phrases and terminology. If the CER uses different words to describe the same concept, the box doesn't get ticked.
• The data priority hierarchy (prospective clinical investigations first, then retrospective, then PMS, etc.) must be described in prose, using the MDCG framework, before the tables appear.
• Saray put it clearly: "Aunque el trabajo ya está hecho y baremado, se requiere más prosa en lugar de solo tablas, usando las palabras exactas de la MDR y la guía para demostrar que se sigue la checklist."

4. The "pin" — the device output architecture

During the meeting, Saray and Taig wanted to explain a key architectural point about the device (they called it "the pin"):

• The device always outputs the full array of all visible ICD-11 classes as a probability distribution.
• It never outputs a binary true/false for any specific condition.
• The clinical benefit claim is therefore: "an HCP using the device and seeing the full probability distribution has better diagnostic performance than an HCP without it."
• This is why the team believes per-condition evidence is clinically inappropriate — the device is never read as "does this patient have melanoma: yes/no."

Nick's response was very important:

• He acknowledged this architecture.
• He confirmed that CE marking IS achievable with this kind of evidence approach.
• However, he stated clearly: the rules do not change whether the device diagnoses, informs, or drives clinical management. MDR clinical data requirements apply in full.
• With MRMC-style studies (simulated use), CE marking is possible only if accompanied by a very robust post-market study to prove real-world impact at scale.
• He specifically asked: "Have you looked at a large sample of patients where this device is being used within that described workflow and compared it against standard medical practice?" The answer is that there are two smaller studies, but they are not sufficient on their own.

Practical implication: The "pin" explanation needs to be added to the CER device description with full clarity. But it does not eliminate the need for clinical data. It reframes what evidence is appropriate, and PMCF must include a robust real-world study.

Important nuance from the internal debrief (March 25): Saray added a clarification that the team had not fully articulated during the BSI meeting. The API does output all ICD-11 codes as a probability distribution — but the interface that physicians actually see does NOT show the full list. It shows a prioritised, limited probability view (a "top CCO"). Saray's words: "la forma de uso final sí es con ese top CCO o con ese interfaz que le van a poner que siempre clasifica y te da una probabilidad limitada, no te da la lista entera." This is a meaningful distinction: the physician's experience is of a ranked short-list, not a raw array of hundreds of conditions. The CER description of the device output must reflect this accurately — both what the API provides and what the interface presents — because the intended use is ultimately what the physician sees and acts on.

Unresolved team tension: Saray also noted that even with the "full ICD list" architecture, the physician's final intended use is always in the context of diagnosing diseases. Nick was explicit that BSI evaluates based on intended use regardless of how the device frames its output. Jordi confirmed: "El tío ha sido claro también diciendo que la manera de evaluar no cambia a pesar del intend." This tension — between the device's architectural framing (ICD distribution, not disease-specific) and the regulatory reality that clinical evaluation requirements apply in full — is not fully resolved. The CER must address it head-on, not avoid it.

5. MRMC studies are not considered "clinical data" by Nick

This is a critical and unexpected position. Nick stated:

• MRMC (multi-reader, multi-case) studies where you show doctors images and ask them to assess with/without the device are not clinical data.
• The reason: the device is not intended to be used in a simulated environment. It is intended for real patients in real clinical situations.
• Real clinical data means real patients, real clinical practice, real outcomes.
• The MRMC studies can still be used as supporting evidence, but they cannot be the primary basis for performance claims.

Practical implication: The CER must explicitly frame the MRMC studies as supporting/corroborating evidence, not as primary clinical evidence. Primary evidence must come from real-world studies, PMS data, and investigations conducted in actual clinical settings.

6. Performance acceptance criteria must be established with traceability to SotA

Neither a criterion like "≥80% sensitivity" nor the percentage itself is acceptable without:

1. A clear statement of what the clinical benefit is and why it matters for this device.
2. Identification of comparable devices or methods (state of the art) in the literature.
3. A justification for why the chosen threshold is appropriate based on what those comparable devices achieve.
4. For pooled data across conditions: a risk-based justification for why pooling is appropriate.
5. For higher-risk conditions (melanoma, malignancies): an individual breakdown of acceptance criteria and evidence. BSI will specifically audit these.

Nick noted it is unusual for a device to claim expertise in as many skin conditions as the device does. He suggested the team consider whether all indications are equally well-supported by data — and whether some should be removed from the claims if data is insufficient.

Unresolved tension around disease categorisation: The team discussed whether to group evidence by disease category (malignant, inflammatory, etc.) as Nick implied. Taig noted the concern: doing so means explicitly structuring the evidence around diseases, which reinforces the framing that the device is "for diseases" — conflicting with the intended-use framing based on full ICD probability distributions. Saray's counter-argument is that the physician's final use is always disease-related anyway, and Nick already confirmed the evaluation rules don't change regardless. For malignant conditions (melanoma, carcinomas), data already exists. The question is whether evidence for inflammatory and other lower-risk categories is also sufficient or needs categorisation. This needs to be resolved before drafting Item 2 and Item 3 responses.

7. Equivalence with the Legacy device needs more detail

Erin flagged this as a gap in the CER. The current explanation is too high-level. BSI needs:

• A comprehensive list of what changes were made to the device since the version used in the clinical investigations.
• An assessment of whether those changes are clinically relevant.
• Justification that PMS data from earlier versions is still applicable to the current device.
• If usability changes were made: evidence that usability was re-tested or that usability did not change in a clinically meaningful way.

8. Links in PDFs do not work

Erin asked for a zip file of all referenced papers, with a clear reference list (author + year or numbered references). She cannot follow hyperlinks in the PDF documents. All evidence must be provided as physical files.

9. PMCF plan: too many activities, too little explanation

The PMCF plan has so many activities it is "overwhelming" and difficult to evaluate. What BSI needs:

• Fewer, better-described activities.
• Each activity must be explicitly linked to a specific identified gap from the CER.
• Each activity must include: methodology, sample size, acceptance criteria, timeline (start date, duration), and contingency plan (what happens if recruitment targets are not met).
• The plan must demonstrate how the activities, combined with PMS, will provide sufficient proactive data to cover safety and performance over the device's lifetime (Annex XIV Part 5).
• Activities that are not directly relevant to filling identified gaps should be removed.

Critical prerequisite — gaps must first be declared "acceptable" in the CER: Saray articulated the correct logic flow in the March 25 internal debrief: "estos gaps que son aceptables — hay que explicarlo bien en el CER — que es un gap, pero es aceptable, sigue siendo suficientemente evidencia para validarlo." The CER must not just identify gaps; it must explicitly state that each gap is acceptable and explain why the existing evidence is still sufficient for validation despite the gap. Only then do PMCF activities flow naturally as the means to close those acceptable gaps over time. This two-step — (1) justify the gap is acceptable now, (2) PMCF closes it in post-market — is what gives the structure logical coherence for BSI.

10. Risk (Item 7): need for traceability of rates

Erin asked about specific risk lines and their occurrence rates. The expectation is:

• Occurrence rates must be traceable to where they were pulled from (PMS data, clinical investigations, literature).
• Risk documents must be updated to reflect current evidence.
• If the risk assessment is in a different document than what was sent, a clear cross-reference must be provided explaining which document, which lines, and why they are applicable.

---

Regulatory strategy decided

Decision: combined MDCG + MEDDEV 2.7.1 Rev 4

After the two internal meetings, the team resolved to use a combined approach:

Guidance	Purpose in the combined strategy
MDCG 2020-6	Document structure: organises the CER into sections that match MDR requirements. State-of-the-art requirements are aligned with MDR Annex XIV. This is the primary document BSI uses to check MDR compliance.
MEDDEV 2.7.1 Rev 4	Process rigor: defines the clinical evaluation process as stages 0–5. The CER must demonstrate that each stage was completed. Defines the search strategy methodology, data appraisal criteria, and evaluation depth.
Relationship document	Confirms which sections of MEDDEV R4 remain applicable under MDR. This is what MDCG 2020-6 itself references — it is not two separate methodologies, it is one integrated approach that MDCG formally endorses.

Nick explicitly said the MEDDEV stages are the framework that makes a clinical evaluation work: "Unless you complete stages 0, 1, 2, 3, 4, 5 — they won't work and it will fall down."

The analogy to the software development situation is very relevant here and was raised explicitly by Taig in the internal debrief: the software team had done all the development work correctly but had not framed it according to the recognised IEC 62304 design phases. The non-conformity was not about missing work — it was about missing narration. The exact same pattern applies to the clinical evaluation. Taig said: "Lo hicimos todo bien, pero no lo enmarcamos según las design faces... no cambió el producto, pero sí que cambió cómo lo explicamos." The hypothesis — confirmed by the team — is that reimagining and re-narrating the clinical history according to MEDDEV's stages is the highest-impact action.

Specific key sections of MDCG identified by Jordi during the March 26 meeting:

• The section identifying which MEDDEV R4 stages remain applicable (cross-references within MDCG)
• The clinical evaluation stages and process framework
• A checklist for the evaluation report for conformity assessment — this is the literal list auditors check off
• Appendix 3: hierarchy of clinical data quality (class 3 context — higher in the hierarchy = more relied upon)

---

Action items defined in the internal meetings

The following action items were identified as a result of the BSI meeting and the subsequent internal sessions. These are listed here for context; actual task tracking lives in the item-specific folders.

Owner	Action
El grupo	Use Device Legacy market data (4 years) as Real World Evidence. Mine PMS data to show how hospital outcomes improved when the device was used.
El grupo	Update surveys of physicians to include questions validating achievement of each specific benefit claim, per benefit, per hospital.
El grupo	Rewrite the CER to be stand-alone: include full device description, output explanation, why output is a probability distribution over all ICD-11 classes (not binary), and how to read the CER.
El grupo	Add a high-level prose narrative at the start of the CER explaining the overall validation strategy, what types of data were used, why they are appropriate, and how the full evidence chain is structured.
El grupo	Justify data sufficiency explicitly: why 80 cases for melanoma is enough, why limited paediatric evidence is acceptable, etc.
El grupo	Link every PMCF activity to a specific identified gap in the CER. Remove activities that cannot be linked to a gap.
Jordi Barrachina	Identify gaps where clinical data evidence is insufficient. Find relevant literature to fill those gaps. Provide analysis (not just citation) of each paper. This is complex expert work — AI helps Jordi draft, but the clinical judgment is Jordi's.
El grupo	Clarify equivalence between current device and Legacy device in detail: list changes, assess clinical relevance of each, justify use of historical studies. Note: the melanoma study was done with Legacy, and a section of the CER already explains it is the same device with no changes. This section needs to be expanded and made more prominent, not created from scratch.
Saray Ugidos	Handle post-market documentation (PMS plan). Provide relevant SOPs and procedures. Saray described this as the simpler part: "más que nada es darle los procedimientos y ya lo." Saray also planned to contact Arancha (possible external consultant) in connection with this work.
Taig Mac Carthy	Create this item-0 folder with regulatory guidance PDFs (done). Generate AI-assisted markdown documentation of the guidances. Create action plan for the non-conformities including the intended use definition.
Jordi Barrachina	Review MDCG 2020-6 to identify the specific sections relevant to the CER rewrite. Send to Taig via Slack with highlights of which specific points to prioritise for AI prompts.
Jordi Barrachina	The dataset for the fototipos (skin phototype) study is already prepared. This could be relevant as additional real-world evidence. Jordi mentioned this in the March 26 meeting.

---

Relationship to formal items

Item 0 is the background layer. The seven formal BSI items build on it:

Item	Topic	Primary insight from item-0
Item 1	CER update frequency	Minor. Follow MDR Article 61(11) and 86 cadence language.
Item 2	Device description & clinical benefits vs SotA	Critical. The "pin" explanation, the benefit simplification question, and the SotA acceptance criteria methodology all apply here.
Item 3	Clinical data	Critical. MRMC studies vs real clinical data, equivalence, data sufficiency justification, analysis (not just citation) all apply here.
Item 4	Usability	Follow existing approach; traceability to summative study results needed.
Item 5	PMS plan	Saray's domain. Traceability of SOPs and procedures.
Item 6	PMCF plan	Critical. Link activities to CER gaps, add methodology detail, reduce volume, add timelines and contingencies.
Item 7	Risk	Trace occurrence rates to PMS/clinical data. Cross-reference the correct risk document if it is in another file.