[{"data":1,"prerenderedAt":4},["ShallowReactive",2],{"guide-clinical-evidence-part-i":3},"\u003Ch2 id=\"introduction\">1 Introduction\u003C/h2>\n\u003Cp>\n  \"For our device, pre-clinical data is enough,\" the regulatory lead said. She sounded confident. On\n  my screen, I could see a few heads nodding.\n\u003C/p>\n\u003Cp>\"Okay,\" I said. \"Why?\"\u003C/p>\n\u003Cp>A short pause.\u003C/p>\n\u003Cp>\n  \"Well, first of all, it’s software. It doesn’t touch the patient. It just provides supporting\n  information.\"\n\u003C/p>\n\u003Cp>\n  \"And in the end, it’s the clinician who makes the final decision anyway,\" someone added. \"We don’t\n  give a result.\"\n\u003C/p>\n\u003Cp>\n  I waited to see if anyone would offer something more concrete. They did not look particularly\n  convinced.\n\u003C/p>\n\u003Cp>\n  It turned out that, for their device, pre-clinical data was indeed enough. At least for\n  demonstrating performance.\n\u003C/p>\n\u003Cp>\n  It also turned out that the pre-clinical data they needed were not the pre-clinical data they had\n  in mind. When they spoke of pre-clinical data, they meant data generated from device testing\n  in-house. When I spoke of pre-clinical data, I meant data from \u003Cem>patients\u003C/em>.\n\u003C/p>\n\u003Cp>\n  \"Wait, wait a second, Cesare!\" they stopped me. \"We don’t have the time or money now to run a\n  randomized controlled trial, you know?\"\n\u003C/p>\n\u003Cp>\n  What followed was a long discussion about pre-clinical and clinical data, about performance and\n  safety, about acceptance criteria and state of the art.\n\u003C/p>\n\u003Cp>\n  And, in case you are wondering: no, they did not ultimately need to run a clinical trial for\n  certification.\n\u003C/p>\n\u003Cp>But that discussion led to a workshop, which was followed by many others.\u003C/p>\n\u003Cp>Over time, those workshops turned into a framework we kept using again and again.\u003C/p>\n\u003Cp>\n  Rather than keeping that framework inside individual projects and workshops, I decided to put it\n  together and make it publicly available.\n\u003C/p>\n\u003Cp>\n  That turned out to be harder than expected. It took us months to structure the material, challenge\n  our own assumptions, and turn years of project work into something that could actually be used by\n  others.\n\u003C/p>\n\u003Cp>This guide is the result.\u003C/p>\n\u003Cp>\n  It will take you through a way of thinking about medical devices that is rarely presented\n  explicitly. Much of it comes from working across hundreds of devices, resolving countless\n  deficiencies, and spending many long hours discussing clinical evidence, performance, safety, and\n  regulatory strategy with manufacturers.\n\u003C/p>\n\u003Cp>\n  The objective is not to give you another summary of the MDR or IVDR. It is to give you a framework\n  for reasoning about the questions behind the regulations.\n\u003C/p>\n\u003Cp>\n  And the best place to start is with the question that started those workshops in the first place:\n\u003C/p>\n\u003Ch2 id=\"what-is-clinical-and-what-is-pre-clinical\">2 What is clinical and what is pre-clinical?\u003C/h2>\n\u003Cp>\n  Neither the MDR nor the IVDR provide a definition of non-clinical or pre-clinical data. The MDR\n  characterizes non-clinical data by listing examples: results of tests, such as engineering,\n  laboratory, simulated use and animal tests, and published literature applicable to the device,\n  biocompatibility, physical, chemical and microbiological characterisation, electrical safety and\n  electromagnetic compatibility, software verification and validation, stability, including shelf\n  life (MDR, Annex II, Section 6.1).\u003Ca\n    href=\"#fn1\"\n    class=\"footnote-ref\"\n    id=\"fnref1\"\n    role=\"doc-noteref\"\n    >\u003Csup>1\u003C/sup>\u003C/a\n  >\n\u003C/p>\n\u003Cp>\n  In practice, non-clinical data can be understood as any evidence that does not meet the MDR\n  definition of clinical data. The MDR defines clinical data in Article 2(48) as follows:\n\u003C/p>\n\u003Cblockquote>\n  \u003Cp>\n    ‘clinical data’ means information concerning safety or performance that is generated from the\n    use of a device and is sourced from the following:\n  \u003C/p>\n  \u003Cul>\n    \u003Cli>\u003Cp>clinical investigation(s) of the device concerned,\u003C/p>\u003C/li>\n    \u003Cli>\n      \u003Cp>\n        clinical investigation(s) or other studies reported in scientific literature, of a device\n        for which equivalence to the device in question can be demonstrated,\n      \u003C/p>\n    \u003C/li>\n    \u003Cli>\n      \u003Cp>\n        reports published in peer-reviewed scientific literature on other clinical experience of\n        either the device in question or a device for which equivalence to the device in question\n        can be demonstrated,\n      \u003C/p>\n    \u003C/li>\n    \u003Cli>\n      \u003Cp>\n        clinically relevant information coming from post-market surveillance, in particular the\n        post-market clinical follow-up.\n      \u003C/p>\n    \u003C/li>\n  \u003C/ul>\n\u003C/blockquote>\n\u003Cp>\n  Clinical data is therefore \u003Cem>not\u003C/em> defined by the setting (e.g. “in a clinic”), nor by the\n  subject (e.g. “data from patients”). For example, a manufacturer of an AI-based medical device may\n  collect annotated datasets from the target patient population in a clinical environment for the\n  purpose of training the model. Although such data may originate from patients and clinical\n  workflows, it does not involve the \u003Cem>use of the device\u003C/em> itself and is therefore not clinical\n  data under the MDR.\n\u003C/p>\n\u003Cp>Instead, three factors are critical in determining whether data qualifies as clinical data:\u003C/p>\n\u003Col>\n  \u003Cli>\n    \u003Cp>\n      \u003Cstrong>How the data were generated:\u003C/strong> whether the data were generated \"\u003Cem\n        >through the use of a device\u003C/em\n      >\";\n    \u003C/p>\n  \u003C/li>\n  \u003Cli>\n    \u003Cp>\n      \u003Cstrong>Which device was used:\u003C/strong> whether the data concern \"\u003Cem\n        >the device in question\u003C/em\n      >\" or a \"\u003Cem>device for which equivalence can be demonstrated\u003C/em>\"; and\n    \u003C/p>\n  \u003C/li>\n  \u003Cli>\n    \u003Cp>\n      \u003Cstrong>The activity that generated the data:\u003C/strong> whether the data arose from \"\u003Cem\n        >a clinical investigation\u003C/em\n      >\", or clinical experience documented in \"\u003Cem>peer-reviewed scientific literature\u003C/em>\", or\n      \"\u003Cem>post-market surveillance\u003C/em>\".\n    \u003C/p>\n  \u003C/li>\n\u003C/ol>\n\u003Cp>\n  Of the three points, the first—clinical \"\u003Cem>use of a device\u003C/em>\"—sounds the most intuitive. That\n  is perhaps why it also causes the most confusion. In practice, this concept is far less clear than\n  it appears.\n\u003C/p>\n\u003Cp>\n  Consider a surgical knife. If a surgeon uses it during an operation, that clearly constitutes use\n  of the device. No ambiguity there.\n\u003C/p>\n\u003Cp>\n  Now consider a manufacturer that applies an AI-based software to identify cancer lesions in X-ray\n  images. Does this constitute \"use\" of the device in the regulatory sense? The answer depends on\n  what is done with the information coming from the software.\n\u003C/p>\n\u003Cp>\n  If a doctor uses that information to decide on subsequent patient management, then yes, the device\n  is used as intended. But what if the same software is run retrospectively on a set of X-ray\n  images, purely to assess how accurately it identifies cancer lesions, and its output is never\n  shown to the treating physician and never influences patient management?\n\u003C/p>\n\u003Cp>\n  The software is certainly being \u003Cem>operated\u003C/em>. But is it being \u003Cem>used\u003C/em> as a medical\n  device?\n\u003C/p>\n\u003Cp>\n  This is where the apparently simple concept of “use of a device” becomes difficult. Operating a\n  device is not necessarily the same as using it for its medical purpose. To determine whether a\n  device is being used as a medical device, we need to understand what role it plays in the clinical\n  process: what information enters the device, what the device does with that information, what\n  comes out, and what happens as a consequence.\n\u003C/p>\n\u003Cp>\n  When dealing with medical devices, you will encounter thousands of variations of this problem.\n  Fortunately, they can be analysed systematically.\n\u003C/p>\n\u003Cp>\n  The key is to stop looking at the device in isolation and instead look at the clinical process in\n  which it operates.\n\u003C/p>\n\u003Cdiv class=\"tipbox\">\n  \u003Cdiv class=\"boxtitle\">\n    \u003Cp>Tip: Clinical data vs. clinical evidence\u003C/p>\n  \u003C/div>\n  \u003Cp>\n    \"Clinical data\" and \"clinical evidence\". In everyday conversation, these two terms are often\n    used interchangeably. In the MDR, they are not. Clinical data is only one component of clinical\n    evidence. Clinical evidence combines clinical data with the conclusions of the clinical\n    evaluation. In other words, clinical data is what you collect; clinical evidence is what you\n    demonstrate.\n  \u003C/p>\n\u003C/div>\n\u003Ch3 id=\"the-framework\">2.1 The framework\u003C/h3>\n\u003Cfigure>\n  \u003Cimg src=\"/guides/clinical-evidence-part-i/fig-clinical-loop.svg\" />\n  \u003Cdiv id=\"fig-clinical-workflow\">\u003C/div>\n  \u003Cfigcaption>\n    Figure 1: Clinical workflow. \u003Cstrong>A\u003C/strong> Complete workflow combining both clinical\n    decision and clinical action loops. \u003Cstrong>B\u003C/strong> Clinical decision loop: input\n    (information or biological material) obtained from the patient is processed and the output\n    presented to support a clinical decision. \u003Cstrong>C\u003C/strong> Clinical action loop: a clinical\n    decision is turned into a clinical action performed on the patient. ● Step in which a medical\n    device can be used.\n  \u003C/figcaption>\n\u003C/figure>\n\u003Cp>\n  Clinical practice, and medical devices as part of it, can be described in terms of nested\n  \u003Cem>clinical decision\u003C/em> and \u003Cem>clinical action\u003C/em> loops (Figure\n  \u003Ca href=\"#fig-clinical-workflow\">1\u003C/a>).\n\u003C/p>\n\u003Cp>\n  In a \u003Cem>clinical decision loop\u003C/em>, an input is obtained from the patient, processed, and turned\n  into information that can support a decision. A medical device may participate at any point in\n  this loop: it may obtain the input, process it, interpret it, communicate the resulting output,\n  or, in some cases, take the decision itself.\n\u003C/p>\n\u003Cp>\n  The clinical decision closes the loop, and it can go three ways. Do nothing. Get more information,\n  which starts another clinical decision loop. Or act on the patient. Only the third option starts a\n  \u003Cem>clinical action loop\u003C/em>: the action is carried out on the patient, it changes the patient’s\n  state, and the changed state is the input of the next clinical decision loop.\n\u003C/p>\n\u003Cp>\n  The two loops are therefore closely connected. A clinical decision loop produces the basis for\n  clinical action, while clinical action changes the state from which new information is obtained.\n\u003C/p>\n\u003Cp>\n  This distinction gives us a practical way to examine what it actually means to \u003Cem>use\u003C/em> a\n  medical device. We will look at the two loops separately. We start with the clinical decision\n  loop, because that is where clinical practice starts: before anything is done to a patient,\n  somebody has to find out what is wrong.\n\u003C/p>\n\u003Cdiv class=\"tipbox\">\n  \u003Cdiv class=\"boxtitle\">\n    \u003Cp>Tip: Patient and user\u003C/p>\n  \u003C/div>\n  \u003Cp>\n    “Patient” and “user” are roles, and the same person can have both. The patient is the source of\n    the input or the recipient of an action or decision. The user is anyone who assesses the\n    device’s suitability, selects or prepares it, prepares the patient, sets or adjusts parameters,\n    interprets outputs, stops or removes the device, or disposes of it. A nurse who applies ECG\n    electrodes and a physician who reads the trace are both users of the same device.\n  \u003C/p>\n\u003C/div>\n\u003Ch3 id=\"clinical-decision-loop\">2.2 Clinical decision loop\u003C/h3>\n\u003Cp>\n  A clinical decision loop has four stages: input, processing, output and decision. A device may\n  contribute to one stage or several. We examine each contribution separately.\n\u003C/p>\n\u003Cp>\n  A clinical decision loop is fundamentally informational. Its immediate result is information about\n  the patient, rather than a change in the patient’s state. This remains true when the input is\n  physical material. In laboratory testing, for example, a specimen is obtained from the patient and\n  processed to produce a result. The specimen does not return to the patient; the result enters the\n  clinical decision. Similarly, an image, measurement or physiological signal is processed to\n  produce information that can guide what happens next. Any benefit to the patient arises through\n  the resulting decision and, where applicable, the action that follows.\n\u003C/p>\n\u003Ch4 class=\"unnumbered\" id=\"input\">Input\u003C/h4>\n\u003Cp>\n  The input originates from the patient, even when a user selects, records, collects or enters it\n  into the device. Here, \u003Cem>input\u003C/em> means the information or biological material that enters the\n  clinical decision loop, not the act of entering data into the device. It may be information, such\n  as symptoms, history, a measurement, a signal or an image; or biological material, such as blood,\n  urine, tissue or a swab. Devices acquire these inputs, but they can also shape their\n  \u003Cem>content\u003C/em>, \u003Cem>timing\u003C/em> and \u003Cem>quality\u003C/em>.\n\u003C/p>\n\u003Cp>\n  A device shapes the \u003Cem>content\u003C/em> when it determines what is obtained: which question is asked,\n  which parameter is measured, which structure is imaged, or which specimen is taken and from where.\n  An anamnesis system that selects questions from earlier answers decides part of what the physician\n  will receive.\n\u003C/p>\n\u003Cp>\n  A device shapes the \u003Cem>timing\u003C/em> when it decides when, how often or for how long to acquire the\n  input. A monitor that shortens the measurement interval when readings drift takes over a decision\n  from the healthcare professional. Timing matters because a measurement or specimen obtained too\n  early or too late may miss the condition being investigated. A reminder alone does not transfer\n  this decision: if the physician set the time, the decision remains the physician’s.\n\u003C/p>\n\u003Cp>\n  A device affects \u003Cem>quality\u003C/em> through how faithfully the input represents the patient. This\n  may depend directly on technical performance, such as sensor accuracy, image resolution or whether\n  a collection tube haemolyses a sample. It may also depend on guidance: an app helps position the\n  camera, or a meter rejects a strip with too little blood. Unlike content and timing, quality\n  cannot be left entirely to the professional. Every device that acquires an input affects its\n  quality. The question is which aspects the device controls and which depend on the user.\n\u003C/p>\n\u003Ch4 class=\"unnumbered\" id=\"processing\">Processing\u003C/h4>\n\u003Cp>\n  Processing turns the input into information: a physical quantity becomes a value, detector data an\n  image, a signal a finding, several inputs a score, or a specimen an assay result. This is the main\n  mode of action of diagnostic devices, including imaging systems, measuring devices, in-vitro\n  diagnostics and non-therapeutic software. Some also acquire and present information; others only\n  process it.\n\u003C/p>\n\u003Cp>\n  Two things matter here. First, processing can transfer responsibility from the professional to the\n  device. A scoring algorithm contains the rule; an image-classification model contains the\n  judgement. The user receives the result without necessarily being able to see how that rule or\n  judgement was applied.\n\u003C/p>\n\u003Cp>\n  Second, processing can lose information irreversibly. Filtering a signal, compressing an image,\n  rounding a value or consuming a specimen may remove information that cannot be recovered from the\n  result. That loss carries through the rest of the loop.\n\u003C/p>\n\u003Ch4 class=\"unnumbered\" id=\"output\">Output\u003C/h4>\n\u003Cp>\n  The output is what the device makes available for the next decision. It may represent the\n  patient’s condition directly, as an image or waveform; express a derived result, such as a value,\n  classification or score; or communicate an alert, recommendation or decision made by the device.\n  When the output is presented to a person, this is where the device hands responsibility back. But\n  a physician can only correct what they can see. Information lost during processing or omitted from\n  the output cannot be checked simply because a physician is at the end of the chain.\n\u003C/p>\n\u003Cp>\n  Displays, alarms, reports and image-viewers shape the output through the same three\n  characteristics as the input. \u003Cem>Content\u003C/em> is what is shown, prioritised or omitted. More\n  information is not necessarily more useful: selection influences the decision. \u003Cem>Timing\u003C/em> is\n  when the information arrives, including display refresh rates, alarm timing and delays.\n  \u003Cem>Quality\u003C/em> is how faithfully and clearly the result is presented, through choices such as\n  image windows, ECG scales, colour maps, units and decimal places.\n\u003C/p>\n\u003Cp>\n  The device also influences the decision through information supplied \u003Cem>with\u003C/em> the output.\n  Instructions for use, labelling and claims tell the decision maker how to interpret it and what to\n  expect. A claim of clinical benefit may affect whether a physician prescribes the device or how\n  much they trust its output. This material is all part of the device’s contribution to the loop.\n\u003C/p>\n\u003Ch4 class=\"unnumbered\" id=\"decision\">Decision\u003C/h4>\n\u003Cp>\n  The decision closes the loop. There are three options: obtain more information, starting another\n  clinical decision loop; act on the patient, starting a clinical action loop; or do nothing. The\n  decision maker may be a healthcare professional, a patient, a caregiver or the device itself. An\n  automated external defibrillator, for example, decides whether a shock is indicated. When a device\n  takes the decision, it takes over the final stage and the responsibility that comes with it.\n\u003C/p>\n\u003Cp>\n  Although the loop produces information, it carries risk at both ends. Acquiring the input may\n  itself be an intervention: an X-ray delivers radiation, a biopsy removes tissue, and a blood draw\n  removes blood. At the other end, a wrong output may lead to a wrong action or a wrong decision not\n  to act. Information is not harmless merely because it does not act directly on the body.\n\u003C/p>\n\u003Ch3 id=\"clinical-action-loop\">2.3 Clinical action loop\u003C/h3>\n\u003Cp>\n  A clinical action loop begins with a decision to act. Somebody, or something, carries out the\n  action, and the patient’s state changes: \u003Cem>decision, action, effect\u003C/em>. The changed state\n  becomes the input of the next clinical decision loop.\n\u003C/p>\n\u003Cp>\n  Usually, the action is physical. Pumps and syringes deliver substances; implants and dressings are\n  placed into or onto the body; surgical instruments act on tissue; and other devices apply energy\n  or radiation. Dialysis removes blood, changes it and returns it. Although it processes blood, what\n  it delivers to the patient is a change in composition, so this contribution belongs to the action\n  loop.\n\u003C/p>\n\u003Cp>\n  Actions can also work through information. A guided psychotherapy programme or a physiotherapy\n  plan delivered through videos gives instructions whose effect comes from the patient following\n  them. The distinction is what the information does in the loop: here, it guides the therapeutic\n  action.\n\u003C/p>\n\u003Cdiv class=\"samepage\">\n  \u003Cp>\n    The purpose of the action loop is to identify the device’s contribution to carrying out the\n    action. A user may perform the action through the device, as when a surgeon acts on tissue with\n    an instrument. The device may perform the action after a user has selected, configured or\n    started the treatment, as when an infusion pump meters a drug or a radiotherapy system delivers\n    radiation. Or the device may remain on or in the patient and produce its effect through its\n    presence or properties, as with a dressing or an implant. In each case, the device participates\n    in the action, although the degree of user involvement differs.\n  \u003C/p>\n  \u003Cp>\n    A device may also decide whether or how to act and then perform the action itself. An automated\n    insulin-delivery system, for example, may calculate a dose and deliver it without a separate\n    user decision. These remain two distinct contributions: selecting the action closes a clinical\n    decision loop; delivering the insulin completes the action in a clinical action loop. Separating\n    them makes it possible to ask whether the evidence demonstrates that the device chose the right\n    action, performed it as intended, produced the intended effect, or caused harm.\n  \u003C/p>\n\u003C/div>\n\u003Ch3 id=\"one-device-several-loops\">2.4 One device, several loops\u003C/h3>\n\u003Cp>\n  In practice, the loops alternate: a decision leads to an action, the action changes the patient,\n  and the patient is assessed again. Both loops may sit inside the same device.\n\u003C/p>\n\u003Cp>\n  An automated external defibrillator records the ECG, analyses the rhythm and decides whether a\n  shock is indicated. That is a decision loop, closed by the device. If indicated, the shock is then\n  delivered: an action loop. One device, two loops, and a different question for each: does it\n  recognise a shockable rhythm, and does the shock work?\n\u003C/p>\n\u003Cp>\n  The loops can also run continuously, be nested, or occur in sequence. A dialysis machine monitors\n  pressures and conductivity while treating the blood and adjusts treatment accordingly. A\n  radiotherapy system verifies position before delivering a dose; an infusion pump with dose-error\n  reduction software checks the programmed dose before infusion.\n\u003C/p>\n\u003Cp>\n  This is why the framework examines loops rather than devices as a whole. Each loop needs to be\n  considered separately. In the next section, we use this analysis to determine when a device is\n  being used clinically.\n\u003C/p>\n\u003Ch2 id=\"using-a-device-clinically\">3 \"Using\" a device clinically\u003C/h2>\n\u003Cp>\n  We can now return to the question that led us here: when is a device actually being used as a\n  medical device?\n\u003C/p>\n\u003Cp>\n  In this guide, we bring forward the idea that “using” a device clinically means completing a loop:\n  a clinical action loop or a clinical decision loop in which the device takes part.\n\u003C/p>\n\u003Cp>\n  The two loops provide a procedure for determining whether a device is being used clinically.\n  First, identify every clinical decision loop and clinical action loop in which the device takes\n  part. Then, for each loop, identify the device’s contribution and follow it through the clinical\n  process. Finally, determine whether the loop is completed, as follows.\n\u003C/p>\n\u003Cp>\n  A clinical \u003Cem>action\u003C/em> loop is completed when the action in which the device participates is\n  carried out on the patient and produces, or is intended to produce, an effect. A clinical\n  \u003Cem>decision\u003C/em> loop is completed when the information to which the device contributes is used\n  to decide what happens next: obtain more information, act on the patient, or do nothing.\n\u003C/p>\n\u003Cp>\n  If the process stops before that point, the device may have been operated and its performance may\n  have been evaluated, but the loop has not been completed. Under the framework proposed in this\n  guide, the device has therefore not been used clinically.\n\u003C/p>\n\u003Cp>Assessing whether a device is used clinically thus involves three steps:\u003C/p>\n\u003Col>\n  \u003Cli>\u003Cp>Identify all the clinical loops in which the device takes part.\u003C/p>\u003C/li>\n  \u003Cli>\u003Cp>Identify the device’s contribution to each loop.\u003C/p>\u003C/li>\n  \u003Cli>\u003Cp>Determine whether each loop is completed.\u003C/p>\u003C/li>\n\u003C/ol>\n\u003Cp>\n  We will apply this procedure first to a clinical action loop and then to a clinical decision loop.\n\u003C/p>\n\u003Cfigure>\n  \u003Cimg src=\"/guides/clinical-evidence-part-i/fig-direct-action_incomplete.svg\" />\n  \u003Cdiv id=\"fig-action-loop\">\u003C/div>\n  \u003Cfigcaption>\n    Figure 2: Clinical action loop. \u003Cstrong>A\u003C/strong> Complete loop: the decision is turned into an\n    action on the patient. \u003Cstrong>B\u003C/strong> Incomplete loop: no action is performed on the\n    patient.\n  \u003C/figcaption>\n\u003C/figure>\n\u003Cp>\n  Applying the procedure is usually straightforward for clinical action loops. For clinical decision\n  loops, determining whether the loop is completed can be more difficult. Let’s see why.\n\u003C/p>\n\u003Cp>\n  Completion of a clinical action loop is easy to recognise because the device’s function requires\n  an interaction with the body, or at least with the patient. Take that interaction away, Figure\n  \u003Ca href=\"#fig-action-loop\">2\u003C/a>B, and there is no clinical effect. Manufacturers understand this\n  instinctively. If the cannula is not inserted, no fluid is given. If the radiation is not\n  delivered, there is no therapy. If the dressing is not applied, the wound is not protected. If the\n  physiotherapy plan never reaches the patient, nothing is treated. So the loop is easy to see, and\n  so is the moment it closes: when the device acts on the patient, clinical data is being generated;\n  when it does not, it is not.\n\u003C/p>\n\u003Cp>\n  Establishing when a device completes a clinical decision loop proves more challenging in practice.\n  Here is why.\n\u003C/p>\n\u003Cp>\n  Consider the manufacturer of a diagnostic AI that detects acute myocardial infarction from ECG\n  recordings. This manufacturer collects ECG traces from patients, processes them with their device,\n  and provides a myocardial infarction probability score to clinicians. The manufacturer then\n  compares the AI scores against troponin blood test results (the biochemical gold standard for\n  myocardial damage). From this comparison, the manufacturer calculates clinical sensitivity and\n  specificity. The study stops there. In this scenario, the clinical decision that the user made\n  using the device’s output is not applied to patient management—that is, it does not inform the\n  next diagnostic or therapeutic steps. This corresponds to the workflow shown in Figure \u003Ca\n    href=\"#fig-decision-support-no-completion\"\n    >3\u003C/a\n  >.\n\u003C/p>\n\u003Cfigure>\n  \u003Cimg src=\"/guides/clinical-evidence-part-i/fig-decision-support_no-use.svg\" />\n  \u003Cdiv id=\"fig-decision-support-no-completion\">\u003C/div>\n  \u003Cfigcaption>\n    Figure 3: Clinical decision loop. \u003Cstrong>A\u003C/strong> Complete loop.\n    \u003Cstrong>B\u003C/strong> Incomplete loop with gold standard comparison: the decision taken on the\n    output of the device does not reach the patient. The loop does not close, but comparing the\n    decision with a gold standard obtained from the same patient yields the diagnostic performance\n    of the device.\n  \u003C/figcaption>\n\u003C/figure>\n\u003Cp>\n  As in the incomplete clinical action loop, the arrow from the decision to the patient is missing.\n  The loop does not close. And yet the study is not empty. Comparing the output of the AI with the\n  gold standard gives the sensitivity and the specificity of the device, and these are clinical\n  parameters: they say how the device performs on real patients. This is where manufacturers get\n  stuck. The data come from patients, they describe the clinical performance of the device, but the\n  device has not been used on anybody. Are they clinical data or not?\n\u003C/p>\n\u003Cp>\n  Under the framework proposed here, they are not clinical data. They are pre-clinical data because\n  the device’s output was not used in patient management and the clinical decision loop was not\n  completed. Nevertheless, they can support a clinical performance claim. The fact that a claim\n  concerns clinical performance does not make the evidence used to demonstrate it clinical data.\n\u003C/p>\n\u003Ch2 class=\"unnumbered\" id=\"conclusion-to-part-i\">Conclusion to Part I\u003C/h2>\n\u003Cp>\n  Part I has established a procedure for determining whether a device is being used clinically:\n  identify every clinical decision and clinical action loop in which the device takes part, identify\n  the device’s contribution to each loop, and determine whether each loop is completed.\n\u003C/p>\n\u003Cp>\n  This procedure applies to medical devices governed by the MDR and to s governed by the IVDR. Most\n  s participate in a clinical decision loop: a specimen originates from the patient, the device\n  processes it into a result, and that result informs what happens next. In both regulatory\n  frameworks, the questions are the same: what does the device contribute to the clinical process,\n  and is the loop completed?\n\u003C/p>\n\u003Cp>\n  Loop completion tells us whether the device has been used clinically and therefore whether the\n  resulting information can constitute clinical data. It does not, by itself, determine whether a\n  study is useful or which claim its results can support. As the diagnostic example shows, an\n  incomplete loop may still generate evidence of clinical performance.\n\u003C/p>\n\u003Cp>\n  In Part II, we develop the framework further, using the loops to distinguish performance,\n  analytical performance for s, clinical performance, clinical benefit, and safety claims, and to\n  determine the evidence needed to support each type of claim.\n\u003C/p>\n\u003Csection id=\"footnotes\" class=\"footnotes footnotes-end-of-document\" role=\"doc-endnotes\">\n  \u003Chr />\n  \u003Col>\n    \u003Cli id=\"fn1\">\n      \u003Cp>\n        The European Commission’s proposal for a targeted revision of the MDR and IVDR, published on\n        16 December 2025 expressly adds in vitro, ex vivo and in silico testing and computational\n        modeling to the examples of testing that may provide evidence regarding the pre-clinical\n        safety of a device. At the time of writing, however, this amendment remains a legislative\n        proposal and has not yet become applicable law.\u003Ca\n          href=\"#fnref1\"\n          class=\"footnote-back\"\n          role=\"doc-backlink\"\n          >↩︎\u003C/a\n        >\n      \u003C/p>\n    \u003C/li>\n  \u003C/ol>\n\u003C/section>\n",1792608381978]