What Is SOTA, and Why Is Everyone Talking About It?

 


If you work in medical devices under the EU MDR or IVDR, you have probably come across this term:
SOTA, State of the Art.

It sounds like another vague concept, a bit of a buzzword, but the truth is that SOTA is a substantial regulatory foundation. The problem is that the regulations mention SOTA no fewer than 12 times, yet they do not define it clearly.
That is exactly why it is important to understand properly what SOTA is.

So what is SOTA, really?

The accepted definition (based on ISO 14971, IMDRF and MDCG documents) is:

"The most advanced state of knowledge and capability in a given field at a given time."
This refers to what is currently considered an accepted and proven method, technology or solution, based on scientific knowledge, technological experience and clinical information accumulated over time.

This means:

  • It is not necessarily the newest solution, but what is considered safe, effective and accepted today.

  • It does not depend only on technology, but also on what is clinically proven and what is known from the market.

Why does it matter?

It matters because SOTA:

  • Affects your ability to justify clinical claims

  • Sets the "reasonable" level of risk you are required to meet

  • Influences the choice of technology, the design approach and the functional requirements

  • Is linked to almost every regulatory document you will write, from the CER to the GSPR

When do you start working on it?

As early as possible.
Already at the design stage (Design Input), it is important to ask yourselves:
What is considered the advanced and accepted solution in the field today? What is the existing standard? What are the limitations?

If you start too late, you will find yourselves changing your approach at a late and expensive stage.

Where does SOTA actually show up?

SOTA is not a mandatory document, but it appears almost everywhere:

How do you apply SOTA in practice?

Step 1: Describe the clinical and technological context

  • What clinical problem does the device solve?

  • What are the accepted ways of treating it today?

  • Which populations is the device intended for?

  • Are there approved devices with a similar indication?

Tip: do not write only about your own device. Explain what is accepted on the market in the clinical field you work in.

Step 2: Choose products for comparison

  • Choose at least one or two similar devices on the market (CE / FDA)

  • Compare technical characteristics, indications and clinical performance

It is recommended to include the following in the table:

Product name, manufacturer, indication, technology, safety and performance data, approval date

Step 3: Review the literature and public information

  • Search the clinical literature (PubMed, Embase, etc.)

  • Review post-market databases (EUDAMED, MAUDE)

  • Read the IFUs of similar devices

  • Check standards (even if they are not harmonized)

Tip: explain your criteria for selecting sources, and what you rejected and why.

Step 4: Analyze the advantages and disadvantages of existing solutions

  • Are there unmet needs?

  • What limitations do the solutions on the market have?

  • What does your device improve?

This is the place to show your benefit in a well-supported way.

Step 5: Connect it to the regulation

  • Does your technological choice meet the current safety bar?

  • Does the Benefit/Risk meet the existing standard?

  • Do you need to run a clinical investigation, or can you rely on similar performance?

Step 6: Write it up and embed it in your documents

There is no single correct format, but best practice is to:

  • Integrate SOTA as a structured chapter within the CER

  • Or create a standalone document that the CER, GSPR and Risk File can refer to

Common mistakes to avoid

  • Relying only on what the standards say: a standard is only part of the picture and does not necessarily reflect what is on the market.

  • Choosing comparison products that are not really similar: a device with a different indication or a different technology does not count as a benchmark.

  • Not updating the document: SOTA changes. What was relevant two years ago may no longer be accepted today.

Questions worth asking yourselves

  1. What is the current level of technology and knowledge in our field?

  2. Does our device at least meet that bar, and if not, why is that reasonable?

  3. How did we support our claims? (sources, comparisons, analyses)

  4. How is our SOTA document (or chapter) linked to other documents?

  5. When will we update it again?

It helps you understand where you stand relative to the market, and what you should aim for.

In summary, SOTA is not just another regulatory term. It is a critical analysis tool.

It does not limit you; it guides you toward better decisions.

If you do this work seriously, you will find that many design, clinical and regulatory decisions become clear on their own.