When reading various comments and initiatives on important issues for the development and placing on the market of medical devices, I am concerned about what seems to me to be an apparent confusion on topics such as clinical evaluation, risk management and state of the art of medical devices, with a separation of activities only for specific processes, that the benefit/risk determination is part of the risk management process or that the analysis of the current state of generally recognized knowledge/state of the art is only necessary for the clinical evaluation) which does not seem to make sense to me. Here are some initial thoughts for my (and possibly your) consideration:

For a variety of reasons that I won’t go into in this post (but may expand on in the future), the two basic aspects that define whether a medical device can be placed and maintained on the market are:

• The device must be safe and effective
• The device must not compromise the health or safety of the patient, user, or others

For the above two aspects to be true, it is also necessary that:

• The potential risks must be compatible with a high degree of health and safety protection, given the current generally recognized state of knowledge
• The potential risks associated with the use of the device must be acceptable when balanced against the expected clinical benefits that the device provides to the patient (seen in another way, the clinical benefits must “outweigh” the potential risks)

For a manufacturer to be able to demonstrate the above, they must, in general:

• Define what it means to be safe for their device
• Define what it means to be effective for their device
• Define and measure the expected clinical benefits of their device
• Define and estimate the potential risks associated with the use of their devices
• Design the device so that any risks associated with its use are compatible with a high level of health and safety protection in accordance with generally recognized knowledge, i.e., the device cannot in principle be more dangerous than similar devices or alternative clinical solutions for the same clinical problem currently on the market
• Compare the expected clinical benefits with the estimated potential risks, including the way in which the device was designed to control such risks, and conclude whether the expected benefits “outweigh” the potential risks

With this in mind, it is important to remember that the entire process related to transforming an idea to solve a clinical need into an industrialized medical device is known as design (or engineering design, using the most common technical term).

• The design process must include the so-called design inputs, design outputs, design verification and validation steps, among others (the related requirements are normally known as “design control”). Furthermore, it includes or interfaces with any other process that performs some activity related to design, such as risk management in general, the usability engineering process, biological safety assessment (biocompatibility) or clinical evaluation

When defining the so-called “design inputs” (which are the requirements that the product must meet), the manufacturer must define various requirements, such as safety requirements, performance requirements, usability requirements, marking requirements, packaging requirements, etc. In addition, he must also decide how to verify that these requirements are met (by bench tests, on animals, or another type of evaluation).

• In order to define these design requirements, it is common for manufacturers to analyze both the history of the clinical problem and similar devices on the market, including their evolution. I do not know of a manufacturer that has not done this in some way, even if simple. On the other hand, this assessment is precisely an assessment of the current state of generally recognized knowledge. Most of the time, this assessment is done before the project is even started, as part of the project feasibility analysis
• In the case of clinical benefits, this analysis should also be one of the first activities of a project; in the case of safety requirements, these must be identified, in addition to the aforementioned analysis, also by applying the risk management process

The risk management process is the process that analyzes (identifies potential risks), evaluates (concludes whether the risks are acceptable or not), controls (defines how to control unacceptable risks) and monitors (the acceptability of all) potential risks of using the device. The risk management process can be understood as a decision-making process, not an implementation process. For example, identifying potential risks primarily uses the analyses made during the design, including in particular the design inputs, to conclude which risks may arise from the use of the device. Even in the case of risk controls defined in risk management, the one who actually implements the controls is the more general design process.

• The risk management process in general does not include a process for identifying, measuring and concluding on clinical benefits. Although a standard such as ISO 14971 includes some possibilities related to the justification of certain risks versus benefits (this is another historical confusion that may be expanded in the future), these benefits should be identified and measured in a separate process. The so-called “benefit/risk determination” of the device as a whole is therefore a general design activity

The clinical evaluation process is a process of generating, collecting, analyzing and determining clinical data on the device (which is defined as safety or efficacy data that comes from the clinical use of the device in humans). And where do the definitions of what data will be generated, collected, analyzed and determined come from? Again, from the more general design process. In other words, the clinical evaluation process (which is nothing more than a specific implementation of the scientific research process called “systematic review”) deals only with data, but it does not define the data itself, it uses the data pre-defined in stages of the device design.

• As a specific example, regulations such as European Regulation 745/2017 (MDR) require that the clinical evaluation plan of the device specify the intended purpose of the device and detail benefits and other parameters. This information does not come from the clinical evaluation. It comes from the design (and a good part of the design input requirements) of the device

Finally, a comment on the issue of state of the art, state-of-the-art, or whatever term you want to use to demonstrate the “consensus” level of current knowledge.

We do not have a definition of the term in medical device regulations (we currently have a definition in ISO 14971 which was created based on a definition from another ISO/IEC standard). For example, in the European Regulation 745/2017 (MDR), there are 12 instances of the term “state of the art”. Most of these 12 instances indicate that the requirements should be applied “considering”, “based on”, “in the context of” the state of the art. None of these requirements indicate that products have to BE state of the art. What’s the reason?

One of the reasons is that the determination of whether or not a product IS “state of the art” cannot be made solely by a company, a notified body, or even a regulator. Something “BEING” state of the art implies that a wide range of stakeholders agree (consensus) that something is state of the art. Even technical standards, which are agreed upon (consensus) by those involved, are not considered to “be” state of the art, but to “reflect” the state of the art (an interesting discussion can be seen in item 3.5 of the MDCG 2021 document-5 Rev. 1 Guidance on standardization for medical devices).

In my experience, the only situation I know of where something is defined as “being” state of the art is in the context of a product liability lawsuit in which a company is being sued by a user who feels they have been harmed by a product. Even in this case, the court ruling can basically confirm whether a product “was” or “was not” state of the art when it was put on the market or used by the user (i.e. whether the manufacturer demonstrated that it did enough from a design and safety standpoint that the product was therefore not the cause of the problem).

What is the reason for the above comments? Well, it seems to me that many people today think that the “state of the art” (or the term SOTA) is something new, and that its analysis must be done in a very detailed and in-depth manner.

As I mentioned above, companies have always done, in one way or another, an analysis of the current knowledge to design their products. Furthermore, regulations indicate the need to “consider” and “base oneself on the “state of the art” in order to comply with regulations. No regulation that I am aware of requires that a SUPER DETAILED  ANALYSIS OF THE STATE OF THE ART be done, nor does it identify how any analysis should be done.

Therefore, I suggest being careful with indications that a complex analysis of the state of the art must be done in order to comply with regulations. They are not supported by regulatory requirements (unfortunately, certain current developments such as the upcoming ISO 18969 clinical evaluation standard seem to focus too much on having requirements for doing a complex state-of-the-art analysis, and too few requirements for the clinical evaluation/systematic review process itself).