practical-qara

MedTech - A Clinicians Perspective

Fri, 16 Oct 2026 15:20:52 GMT

Dr Maria Vella, Elevate Medtech's clinician gives her perspctve on MedTech

In the Beginning…

When I graduated from medical school in 1999, the MedTech as a term was not widely recognised. We simply used the term "medical devices" or "devices," to capture all products we used to diagnose, monitor or treat patients. Most of us were not tech-minded; our goal was patients, and devices were there to support that mission. We were shown which devices to use for specific procedures or diagnoses based on what was in use at the time. We became aware of their limitations either because we were told or discovered through trial and error.

Fast forward twenty years, and we now live in a different world. The MedTech evolution is here, a multi-billion dollar industry where technology advances at an exponential rate. Software developments are expanding what devices can do and clinicians need to adapt to a changing world and changing practice. Medtech exists to advance clinical care through faster, more reliable diagnoses, better treatment, improved monitoring, and prevention. Clearly, any advancement that positively impacts human health is advantageous. However, we must not lose sight of the bigger picture: the patient, who is supposed to be the ultimate beneficiary of that advancement.

I say "supposed to be" because MedTech organisations are not charities. They are commercial entities that primarily exist to make money. Their goal is to get novel products to market as quickly as possible, before a competitor does, in order to maximise profitability. We certainly do not want to miss out on technological advances that could lead to better patient care, but this must be managed carefully, as the drive for profit and the assurance of device quality can sometimes be opposing goals.

Healthcare standards have improved significantly over the past century, for many reasons. Medical discoveries have allowed us to determine predisposition to disease, enable early detection, and develop pharmaceutical advances. There have also been advances in training and in technology. There is no question that progress in medical technology has positively influenced healthcare, yet it remains just one of many factors driving improvements in clinical practice and patient care, all of which are inextricably linked.

At the risk of stating the obvious: for devices to fulfil their intended use, they must be used, and used correctly. Developers need to know who their users are and the settings in which devices will be used. This generally falls into two categories: home use and professional use. Home use devices are typically low-risk and are used by patients or carers for monitoring, prevention, or mild treatment (e.g., an inhaler). If an abnormality or concerning result is detected, it is usually up to the user or patient to seek professional help for further interpretation or to act as previously directed by a clinician. Professional devices are generally more complex to operate, requiring an assumed level of competence and knowledge. They are also typically higher-risk and require interpretation of results so that the most appropriate next steps in care can be determined.

Throughout my career as a professional user I have used hundreds of different types of devices, some good, some terrible. Clinicians generally give little to no thought to how devices came into clinical use, who designed them, who approved them, or who decided to procure them. The exception is when things go wrong, then we want answers. Most often, we simply work with what we are given or what we have become accustomed to using. This is not to say we are uninterested in MedTech or developments in the field, we are, but our primary focus remains the wellbeing of the patient, ensuring they leave our care in a better state than when they entered. Devices are one link in that chain.

Many elements differentiate a good device from a bad one, and in my experience they can be broken down into three main areas:

Clinical performance and patient safety
Usability and integration
Reliability and Durability

Although listed separately, all three are inextricably linked in practice. Notably absent from this list is cost. While we know devices are not cheap, and that more expensive devices are probably better, product cost, both upfront and ongoing, is not something most clinicians become aware of unless specifically brought to our attention. Further attention will now be paid to these three key areas.

Clinical Performance and Patient Safety

As stated above, my goal as a clinician is to ensure patient wellbeing. Devices are simply the tools that enable us to achieve that. We choose the right tool for the right job to deliver the desired outcome. There is an underlying assumption that devices placed on the market are fit for purpose and that the regulatory systems in place are rigorous enough to safeguard against harm. In truth, very few clinicians know much about the regulatory framework surrounding MedTech. We know it exists, and we largely assume it functions as intended. However, there is a belief that devices are not regulated to the same extent as pharmaceuticals, and therefore we need to remain vigilant.

We have all had experiences with bad devices and have seen some that we believe are unsafe and should never have been allowed onto the market, gynaecological mesh being a prime example. While I have witnessed products being recalled due to safety concerns, there are also devices I currently use that I consider unsafe because of the way they can be used or misused. Where an alternative exists, I will choose that instead. I have seen products with labels or notes written by in-house staff, instructing users to "do this," "don't do that," "use here, not there," and so on. We should not need to add such labels to equipment, having to do so is indicative of a failure of the manufacturer to consider the use and use environment.

We accept that some degree of risk is inherent to all devices, but in some cases, the risk is simply too high. We are regularly involved in pharmaceutical clinical trials, yet far less often in device trials. I believe that many of these risks could be alleviated if device companies simply talked to us. This is especially important when it comes to device usability.

Usability and integration

It is important to distinguish between products that are fundamentally unsafe, i.e. those with inherent flaws in the technology and those that are simply difficult to use, which in practice can also make them unsafe. Even if a device is built on proven technology, it can only fulfil its intended purpose if it is used correctly. To be blunt, your device is one of many in the clinical space and our priority is always the patient. The time we have to operate any given device is not as generous as you might imagine, and it is entirely possible that our full attention will not be on the device at the moment of use. Simply put, a device that demands more user input and concentration leaves more room for error, or if it is too complicated we simply wont use it.

Let me give you an example. By chance, I once visited a company that had prototyped a diagnostic device for use in an intensive care unit (ITU). It was all ready for manufacture and all systems go. The employees were proud of their work and eagerly showed me how it functioned. The device features man knobs, levers, and buttons. I started pressing some buttons and twisting knobs, and I could see the employee's face change colour as I inadvertently did things I wasn't supposed to. I had accidentally initiated a calibration process, a process that in itself was extremely manual, clunky, and laborious. The core concept was excellent, and the underlying technology worked, but the user interface and operation required to make the technology function did not. I politely explained that pressing the wrong buttons and twisting the wrong levers at the wrong time was exactly what would happen in a real clinical environment, especially in ITU. I asked how many of the developers had been in an ITU? The answer, none. The calibration process, critical for ensuring sensitivity and specificity, was far from user-friendly. It looked impressive to those inside the organisation, but they had become so familiar with the device that operation was second nature to them, they could not see the forest for the trees. They knew what to press, what to twist, and in what order to make it 'work'. Although the company had a clinical resource, their input had been limited to the core technology and concept, which was proven, not the operation. Further usability assessments confirmed the same concerns, leading to a costly major redesign ultimately costing the company millions and contributing to its eventual collapse.

When considering usability, it is also vital to account for variation across the spectrum of users. What does 'for professional use only' actually mean? A doctor? A nurse? An Operating Department Practitioner? Each group may have different expectations, competencies, nuances and physical attributes. As a petite female surgeon, I struggle with many surgical instruments that are clearly designed for people with larger hands than mine, predominantly men. Different clinicians also vary in how quickly they adapt to the latest technology, some love it, others much less so. Some of my colleagues prefer different devices for the same procedure based on personal preference. Using devices is often like riding a bicycle, the more you do it, the more competent you become. However, given their shaky start learners are excellent at exposing device flaws, whereas familiarity tends to normalise or embed quirks and risky areas of operation. Those risks, once identified, can and should be fed back to the manufacturer so they can be addressed.

Primarily, devices need to be intuitive in operation. The reality is that very few clinicians read the instructions that come with products. While we often receive training for more complex devices, that knowledge only stays fresh for so long. Eventually, use becomes second nature, or we rely on intuition. The best products are those you can walk up and use because you have used something similar before, or for more complex systems, the user interface provides clear prompts on what to do. When an alarm sounds due to a device fault or patient alert, the nature of the fault needs to be immediately clear to the user. Alarms that sound constantly for minor issues lead to alarm fatigue and missed critical events.

Alongside usability is adaptability. Unless your product is a true game-changer that completely transforms a given process, it will need to integrate into existing practice and the current operating environment. For example, if your device must connect to a hospital IT network and requires additional infrastructure for functionality or cybersecurity, the chances of adoption drop significantly. If your device requires cords or cables to run across workspace floors, that creates additional hazards and may raise eyebrows from Heath and Safety. Returning to the ITU device mentioned earlier, if a product demands so much attention or concentration to operate such that other necessary tasks are neglected, it will not fit well into the use environment. Careful consideration of the use environment and integration with current practice is essential. Your ideal operating environment may not exist or may simply be unrealistic. Speaking to actual users in the early stages of development is absolutely critical to address these issues and increase chances of adoption.

Reliability and Durability

It should come as no surprise that we expect devices to operate as intended, consistently. Clinicians want tools that make their jobs easier. That said, we are also creatures of habit, so getting us to adopt a new procedure or device can be challenging. While I am more than happy to try a new device, I do so with caution. If it breaks down, gives a clearly erroneous result, or proves temperamental, my confidence in it diminishes. I will give it a second chance, but if it fails again, there will not be a third. We accept that products can occasionally fail, but repeated failures lead to a rapid loss of trust.

We expect downtime to be kept to an absolute minimum. Devices that are frequently unavailable due to constant calibration or maintenance are of limited practical use. Maintenance and calibration schedules should be clear and simple. Likewise, any faults that require user intervention should be straightforward to remedy.

Products must also withstand the realities of the clinical environment, realities that often surprise device designers. As mentioned, healthcare settings can be chaotic. Your device may not be handled as you expect. It may be knocked or dropped, intentionally or unintentionally misused, have liquids spilled on it, or be exposed to aggressive cleaning or disinfecting solutions. If it is portable, can it be moved freely? When moved, it will inevitably bump into things, will that damage critical components, and will the user be aware? While I cannot claim to be a software or cybersecurity expert, I have seen patients try to log into hospital equipment so can only imagine what the threats are in cyberspace. Will your device be adequately protected against threats and unintentional access?

Device developers need to be clear about the intended use environment and aware of its realities. I have seen many products that break too easily, claim to be portable yet cannot be moved by smaller-staff members, create trip hazards with multiple cords and cables, or have displays that become unreadable under certain lighting or direct sunlight. These examples are far from exhaustive. Understanding the use environment is essential, and that understanding can only be gained through direct exposure either by device developers immersing themselves in clinical settings, or by drawing on the experience of those who work there.

Summary

There is no question that advances in MedTech have improved clinical outcomes for patients and made healthcare delivery more efficient. However, as technology evolves at an unprecedented pace we must not lose sight of the bigger picture, the people at the heart of MedTech —patients.

While great ideas backed by technology are plentiful, we must be cautious of the “solution in search of a problem” scenario. Innovation in MedTech must be driven by real clinical needs, not the other way around. Devices should have a clearly defined clinical purpose and be safe, reliable, and intuitive. Although clinicians recognise the need for innovation, they are generally creatures of habit and resist change unless there is a clear, demonstrable benefit. We want devices that reduce burden, not add to it, while still improving clinical outcomes.

Even though we largely trust the technology and regulatory systems designed to protect patients and users, my decades of clinical experience have shown that many companies fail to appreciate the importance of device usability and overlook the dynamics of the clinical environment. These failures introduce risks to both users and patients. If your device is intended for use by clinicians, involve them from the early stages. They are well positioned to identify risks that developers might overlook and to offer feedback on known risks. If you have a device that addresses a specific clinical need or even if you’re unsure, talk to us. We are more than happy to help develop products that make our lives easier and improve clinical outcomes.

END

AI in MedTech

Tue, 14 Apr 2026 10:23:33 GMT

AI in MedTech - Should we be worried?

Seldom does a day pass without hearing the acronym "AI" or having our lives touched by artificial intelligence in some way. It is one of the few acronyms that everyone seems to understand. Intentionally or not, we likely all interact with some form of AI in our daily lives whether through a simple Google search that generates AI-driven results, or by deliberately using AI to reword something we have written.

Like COVID-19, the AI revolution has caught us somewhat off guard. We are having to adjust how we work and live to embrace it. But unlike COVID-19 and conspiracy theories aside, AI as the name implies, is artificial. Arguably, we should be in full control of its seemingly uncontrolled proliferation in society. Yet the reverse appears true: something artificial is trying to control us. So how did we get here?

For context, I am no IT expert , ust someone who has worked in the MedTech quality and regulatory space for decades. Like many of you, I am coming to grips with what AI means and what lies ahead. While the term "artificial intelligence" might strike some as an oxymoron, I thought it prudent to explore some background.

First: AI is not new.
It has been around for nearly 90 years. In 1936, Alan Turing conceptualised the "Turing Machine"—a device capable of reading data and solving problems using algorithms. The term "artificial intelligence" didn't enter common vocabulary until the 1950s. In 1955, the Oxford English Dictionary defined it as:

"The capacity of computers or other machines to exhibit or simulate intelligent behaviour; the field of study concerned with this."

This was later expanded to include:

"…software used to perform tasks or produce output previously thought to require human intelligence, especially by using machine learning to extrapolate from large collections of data."

The key word here is intelligence, defined as "the faculty of understanding; intellect." Intellect, in turn, is "that faculty of the mind by which a person knows and reasons; power of thought; understanding; analytic intelligence."

All pretty deep.

Looking at the updated Oxford definition above, it states:

"…software used to perform tasks or produce output previously thought to require human intelligence."

"Previously thought"? Are we now suggesting that AI's tasks aren't truly intelligent but merely computational—driven purely by input?

Reflecting on the deeper definition of intellect, the key terms are reasoning and power of thought. Reasoning and thought rely on knowledge, yet knowledge alone does not equal intelligence. Someone with vast knowledge may simply have a strong memory, not necessarily the ability to critically process, question, or extrapolate. Knowledge serves as the foundation for analysis and justification. However, the ability to retain knowledge, analyse, reason, and process information varies greatly among individuals. It is not one-size-fits-all.

The rise of AI is directly tied to software's ability to analyse information at lightning speed. Tasks that might take us hours or days can now be completed in seconds. But AI is not magic. It is software, rooted in zeros and ones, that detects patterns in data to draw conclusions or make predictions. AI merely simulates and processes existing knowledge. That is arguably not intelligence. It cannot reason or justify.

AI in Healthcare
AI's use in MedTech has also been around for decades. In 2002, during a Master's degree in Medical Diagnostics, I was assigned a project on Artificial Neural Networks. I found it fascinating and saw huge potential—but with my quality and regulatory hat on, I could see clinical risks, particularly in disease diagnosis. I highlighted those risks. Despite being challenged by a few academics, I earned a very good mark because I could argue my points with reasoning and justification, points grounded in real-world experience as a medical device developer and user.

Fast forward 20+ years, and AI in MedTech is becoming more prominent. As noted, we are playing catch-up. Recent publications demonstrate this:

2019: OECD AI Principles (fairness, innovation, accountability, transparency)
2021: EU proposal for the AI Act (entered into force 01 August 2024)
2023: BS/AAMI 34971 (applying ISO 14971 to machine learning in AI)
2023: ISO 42001 (AI Management System)
2023: US Blueprint for an AI Bill of Rights (ethics and bias)
2025 (draft): FDA guidance Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations

With the exception of the FDA guidance (specific to medical devices), all documents are non-industry-specific.

Notably, ISO 42001 does not include the word quality, yet it contains many elements of a medical device QMS (document control, internal audit, etc.) and is expected to be integrated within it. Like the OECD document, it promotes transparency, fairness, accountability, and security, but takes a deeper dive into risk management. Rightly so.

BS/AAMI 34971 specifically addresses risks arising from machine learning. It provides guidance on applying ISO 14971 to regulated AI medical technologies, without replacing it.

The FDA draft guidance outlines key information for marketing submissions. One of the FDA's strengths I've always appreciated is its commitment to transparency. The guidance underscores a Total Product Lifecycle (TPLC) approach for AI-integrated devices, highlighting transparency and bias mitigation. It adopts a patient/user-centred focus, requiring details on:

Intended users and user interface
Instructions and information for users
User training requirements
Device performance and AI training data (including representativeness)
Post-market surveillance (PMS) and performance monitoring

To further transparency, the FDA also requires a Public Submission Summary, offering stakeholders insight into design and validation.

The EU AI Act
The EU AI Act is comprehensive. It aims to provide a regulatory framework for AI within the EU, ensuring safety while respecting rights and values, using a risk-based approach. Implementation is staged over 6–36 months. As of 02 February 2025, obligations on prohibited AI practices and AI literacy are mandatory. Obligations for high-risk AI systems, including medical devices and IVDs take effect on 02 August 2026. Only two guidance documents have been published so far; others are expected by August 2026.

Unlike the FDA guidance, the Act places obligations on both providers and deployers of AI systems:

Provider: develops an AI system or places it on the market under its own name.
Deployer: uses an AI system under its authority (excluding personal non-professional use).

Article 26 requires deployers to:

Ensure use in accordance with instructions for use (IFU)
Assign human oversight to high-risk AI systems
Monitor use and associated risks
Report serious incidents to provider, importer, distributor, and market surveillance authority
Undertake a data protection assessment
Inform affected workers and representatives before use
Inform natural persons how the AI system's output impacts them

These responsibilities aim at transparency, i.e. that users and patients are aware AI is being used and how it may affect them. In theory, that is positive but given my many years in MedTech, the following concerns arise:

Use in accordance with IFU: In reality, IFUs for MedTech devices are rarely read in clinical facilities. Do we really expect medical professionals and home users to read them? How will compliance be monitored?
Human oversight: This implies a "trust but verify" approach. How much oversight? By whom? Who decides? If constant verification is needed, what is the point of the AI?
Monitor risks: Risk assessment is subjective. User A may assign lower risk than User B for the same product. If the manufacturer monitors itself, is that not marking its own homework while trying to eliminate bias?
Report serious incidents: Is it realistic to expect users to know who the importer, distributor, and market surveillance authority are? A consultant using an AI device will not be the one reporting incidents. Hospitals are chaotic environments.
Data protection assessment: Who would do this? How would they know the software's limitations regarding data security? Full disclosure from providers is required, but the more risks they disclose, the less likely they are to sell. Commercial reality.
Inform workers and representatives: Who determines what information is disclosed? How is this monitored over time as workers and users change?
Inform natural persons: As above. How will users or patients acknowledge consent to AI use and accept associated risks?

The vision is commendable, but experience tells me reality may differ. Transparency is good, but it relies heavily on labelling and product information. This challenges ISO 14971's principle that information for safety is the last resort of risk mitigation and for good reason, as IFUs are rarely, if ever, read.

To date, those classified as deployers have had no obligation to understand regulatory requirements for bringing a device to market. Any failure when used as intended has largely been on the provider. Do deployer responsibilities now mean a clinical facility may be held accountable under an Act they likely know nothing about? Do we expect nurses, doctors, and patients to read and understand the Act? Having worked in QARA for decades, I can say it is not an easy read. Plenty of caffeine was required and something stronger later in the evening.

I have major concerns that placing such obligations on deployers may give providers an easy escape from mitigating risks 'as far as possible', preferably by design, as required by EU MDR/IVDR. A defence of "they didn't read the IFU" or "they didn't use it as intended" becomes more justifiable after an adverse event.

The FDA takes a more pragmatic approach. They state that transparency is context-dependent. They encourage designers to consider:

Where will the device be used, and what are the conditions?
What else might users be doing simultaneously?
How timely is the application of information?
In what settings will the device output be viewed?
Will the users who interpret output be the same as those who operate the device?

This is music to my ears. Anyone who has sat with me in a risk assessment session knows I always emphasise context of use, user profiles, what else users are doing (your device is not their focus!), and environmental limitations. Context is key—not only in AI transparency but in any MedTech risk assessment.

Machine Learning
AAMI TIR66:2017 defines machine learning as "function of a system that can learn from input data instead of strictly following a set of specific instructions." So, like us, AI "learns." Its brain is uploaded with existing knowledge (data) and computes based on input quality.

Everyone reading this can recall good and bad teachers at school. I think back to algebra class. Everyone received the same teaching input. Some grasped it immediately; most, including myself, did not. Was that intelligence, or just different ways of learning and processing information? The input was the teaching. The desired output was full understanding by all pupils. It didn't work.

After class, many of us tried to teach ourselves, with limited success. Then one student went home, and his civil engineer father explained how algebra was used and why—he put it into context. Let's call him Pupil A. Pupil A then explained the reasoning to Pupil B, who grasped it and explained to others. Some grasped it; others did not. We all started with the same knowledge, but our ability to draw conclusions varied. The initial teaching input did not consider context of use or user variability.

This is pertinent to AI in MedTech. Critical factors for safety and effectiveness include:

Method of training
Training data
Understanding user/patient variability (skills, customs, race, predispositions)
Understanding use environments
Understanding that risk mitigation by labelling really is a last resort

Above all, data, the input, is king. All these factors are inextricably linked and carry many permutations of risk. For an AI product to work according to its intended use, all assocuated risks must be fully understood and "built in."

Take an AI diagnostic system for melanoma. If the algorithm is trained on white Europeans but destined for a global population, the data is not representative. As a pale Scot who turns beetroot red under a full moon, I differ hugely from my Mediterranean wife. Our skin cancer risk profiles and ease of detection are totally different. Similarly, an AI device for diabetes trained on people in the Far East would not necessarily be appropriate for US or Western European populations.

I am not anti-AI. Far from it. AI has enormous potential in society and MedTech, but it needs careful management. Quality in healthcare AI does not happen by chance. It is only as good as the data used to feed it. It builds on existing quality concepts like risk analysis and trainingbut here, training is of the algorithm, not people, and the permutations of harm increase profoundly.

MedTech practice is grounded in risk. "First, do no harm" acknowledges that every intervention carries risk. Effective management is essential, yet many companies lack robust understanding of their devices' true clinical and usability risks or the realities of the clinical environment. AI will introduce unprecedented complexity and new risk categories. Consider an AI system that trains continuously during clinical use: Who verifies this learning? Who is accountable? Ultimately, it comes down to controlling inputs, outputs, and variability.

Thankfully, BS/AAMI 34971 addresses some concerns by guiding what to consider when identifying risks. It states that people involved in risk assessment must have relevant knowledge of the data used to train, test, and validate the system. But this requires correct input data at the time of use (e.g., ethnicity, age). The algorithm may work, but ongoing training data may be erroneous and this will be somewhat out of the developers control.

Curious about numbers of AI-based devices approved/cleared, I ironically used AI to do the task for me. Why? It saved hours of trawling databases, and if the numbers are somewhat inaccurate, no one gets harmed.

In an unscientific study, I asked three AI platforms (Deepseek, Grok, ChatGPT): "How many AI-enabled medical devices have been cleared by the US FDA to date?" and "How many have been approved under EU MDR/IVDR?"

For FDA clearance:

ChatGPT: 1400–1450 (to April 2026)
Grok: 1430–1451 (to mid-April 2026)
Deepseek: 1356 (to end of March 2026)

Deepseek and Grok provided further detail (radiology predominant). ChatGPT provided most information on trends over time.

For the EU, unsurprisingly, no platform could provide exact numbers due to the lack of an operational public database. Deepseek and ChatGPT stated numbers were unavailable and gave reasons. Grok provided estimates from multiple sources.

The same query yielded different results because algorithms and training differ. Using AI saved me hours or days of work, and I was grateful. It replaced a manual, tedious task that didn't require much intellect, just knowing where to look (knowledge). Time was the winner. Despite differing outputs, I was impressed. But these results also show that AI in MedTech is growing, even the FDA now uses AI in technical reviews.

Should we be scared? To a point, yes. At a recent MedTech expo, many expressed concerns about the speed of AI's takeover, especially in MedTech. The human reasoning element seems absent. Computational power is quick and efficient, but reasoning power is debatable. We will rely less on highly trained clinicians for diagnosis or procedures. It is not all binary zeros and ones—there are 0.27's, 0.35's, 0.52's, 0.86's. Those grey areas rely on clinical oversight, justification, reasoning, and thought. Ask any clinician if they have the same knowledge they had when they originally qualified, they will undoubtedly say no, most of their clincial reasoning has been based on experience away from the textbook.

Multidisciplinary team meetings have been common practice in medicine for centuries. They discuss grey areas, gather opinions that matter, include those who have seen something before that triggers alarm bells or offers alternative perspectives. Clinicians know the risks, they spent years training, are bound by the Hippocratic oath, and undergo periodic peer assessments. Should AI replace that?

Curious to gather a clincial insight I gathered a clinician's viewpoint from consultant gynaecologist Dr. Maria Vella ;who said

"We increasingly hear how, in a cash-strapped health service, AI can save money, increase productivity, and improve accuracy especially in diagnostics. AI will undoubtedly help in many clinical scenarios, but its use needs careful regulation and governance.
Areas like breast imaging (screening mammography) could deploy AI successfully, processing large volumes at lower cost. Dermatology is another trial area.
The downside: human bodies have subtle differences. The experienced clinician's eye is essential to differentiate normal variants from early pathological changes. Using AI in diagnostics could, at best, increase clinician workload (anything not 'box standard' normal requires investigation, increasing patient anxiety). At worst, subtle early changes, critical for identifying disease, could be ignored. Any process deploying these systems needs careful review and appropriate governance before becoming the default service."

To conclude: The potential for AI in MedTech is enormous. It will save time, save money, and I hope save lives. But we need to proceed with caution, and a lot of it. The AI Act, FDA guidance, and others are steps in the right direction, but we seem to be running before we can walk. My fear is that society is being driven by AI, it is controlling us, not the other way around. The appeal of time and cost savings in cash-strapped health systems is real, but so are the risks. We must not lose sight of the bigger picture.

We may be ready for AI to provide recommendations in MedTech that are verified by trained clinicians. But there are genuine concerns about AI devices that train on the job with no human validation check, and those that make final clinical decisions or perform surgical procedures. Lives are at stake. I hope that in the rush to adopt AI in MedTech we avoid a disaster that forces us to reassess its use.

Technological advancement only creates possibility. We cannot just drop AI into practice and assume a positive clinical impact. Positive impact in any MedTech requires deliberate design based on thorough risk management, and a fully weighted benefit-risk assessment throughout the entire lifecycle, not just getting the product to market. This is especially the case for AI.

The tech revolution is here and it is big. But unless we close the gaps, we will miss out on the value.

Quality and Regulatory hurdles in a Robotic Start-Up. In the Beginning…

Wed, 06 Nov 2024 13:45:22 GMT

Quality and Regulatory hurdles

Stephen Smith, Co-Founder of Practical QARA, discusses some of the QA and RA hurdles in getting a surgical robot to the market. The blog is based on real world experience.

By nature medical device start ups are often spin outs characterised by academics and people who may not have had exposure to previous joys of getting a new device to the market, and that’s ok. The drawback is that they often do not realise how hard it is to get a new device to market especially one as complex as a surgical robotic system.

So, let’s say you have a great idea for a new robotic device or any medical device for that matter. You have thought about the technology, know roughly what type of surgery you think the system is capable of and set about building a prototype. You build your prototype, everything is good so you start to think about upscaling and selling. You desperately need that return on investment and keep that positive news flow to the investors. Time is of the essence, we get it, we have been there with robotic companies and many other start-ups.

To quote Elon Musk, ‘Prototypes are Easy, Production is hard’. He is right but are medical device prototypes that easy? Practically, yes. It is relatively easy to knock up a few in a lab and get them working how you think they need to be working. The fun comes when you want to up-scale and sell them. Such challenges increase exponentially with device complexity. Both authors have seen many start-ups fail as they do not consider key elements in the prototype stages, such as;

Can you actually manufacture it at scale? Building a prototype in a lab by R & D Scientists and Engineers is one thing, being able to mass produce with reproducibility and reliability is quite another.
Do you really know what the customer wants? It is often totally different to what you think they want.
Who will be using your robot? Yes, obviously surgeons, but what type of surgeons? Surgeons with experience in robotics, general surgeons, specialty surgeons, surgeons who have just qualified? Do surgical practices differ according to territories in which you want to sell it?
What is the kind of environment that the device will be used in, the extremes of those environments, the chaos?

Introducing Quality Assurance (QA) and Regulatory Affairs (RA).

And then there is the often neglected aspect of QA and RA. First a little perspective and food for thought. ‘First do no Harm’ is the Hippocratic Oath in which medics must abide by in practice, and we think it is fair to say that nobody could argue with this and we are all glad this is the case.. In essence doctors/surgeons perform three tasks, they Diagnose, they Treat , and they Monitor. They go through many years of training, theoretical and practical examinations before they are let loose on patients. Such that the patient does not come to any harm under their care. And again, we are all kind of glad they do. They are also governed by bodies such as the General Medical Council in the UK. In essence, medical devices perform the same functions, they Diagnose , the Treat , they Monitor , yet we as device developers and manufacturers do not need to undergo any medical training or undertake exams in order to diagnose, treat or monitor those on the receiving end of our devices. Now think about how much medics rely on devices to either make their decisions in entirety or to aid them. Scary?

Let’s now introduce QA and RA. Whilst QA and RA arguably are different disciplines, they are inextricably linked in practice.

With an objective of ‘first do no harm’ they are essentially there to make sure our devices do what we say they do and patients will not be in a worse state after using our device than before.

Let’s start with Quality Assurance where the word ‘Assurance’ is key. How will you ‘assure’ the quality of your system? Quality is about knowing what the customer wants and having a product that meets those requirements, first time , every time . ‘Assuring’ Quality can only come about by reducing sources of variability in the design and the manufacturing process; so we first need to know where these sources of variability originate, how to address them and how we will verify our fix. There is also the not insignificant requirement of a Quality Management System (QMS). As the title implies this system is supposed to assure quality for all products covering aspects such as design control, supplier control and Internal audits – yes, you will need to do these too. And your Quality system will also need to be certified. Fortunately the need for a QMS seems to be widely acknowledged at an early stages by execs but having one which is complaint is one thing, having one which is compliant and effective (I won't bog you down) is quite another.

Regulatory Affairs, is primarily about gaining approval so your device can be marketed. There are many regulations and the more complex your device, the more regulations you will have to comply with. Regulations are getting more stringent. Take the introduction of the EU Medical Device Regulation (2017/745) for instance. This has resulted in a significant increase in the level of pre-market scrutiny that is required to get your device to market. And where there is increased scrutiny, the costs also increase.

Regulations will vary according to where you want to sell it, but taking the EU as and example your robot and documentation will need to demonstrate electrical safety, most commonly to the EN60601 series of standards. If it has batteries in back up systems and sold in the EU you will need to comply with the Battery Regulation 2023/1542. As an invasive device you will need to show biocompatibility to the ISO10993 series. Usability to the IEC62366 series, software to the EN62366 series, clinical investigations to ISO14155, risk to ISO1491, the WEEE regulations, the RoHS regulations… to name a few: but you get the picture. Getting regulatory clearance for a robot is no mean feat and will take time... and a lot of money.

The Pitfalls

You may think your robot prototype is great and it probably is. It may work great in the lab, may have worked great in your animal and cadaver studies, but... if it does not meet biocompatibility or electrical safety requirements, it isn’t going anywhere near a patient. Many companies fail to consider the requirements of standards or regulations in good time and/or fail to keep up with regulatory changes. Central to your device will be clinical evaluations. How will you do this? What are your determinations of safety and effectiveness? What are your end points? You’ll also need ethical approvals, is the population of your trial(s) representative of your target population? The list goes on, and will need to be considered at the very early stages.

Central to QA and RA is a four-letter work ending in K that is pivotal to success, or failure – RISK. Getting back to the Hippocratic Oath mentioned above, in order to ‘do not harm’ we must know what the risks of our device are and mitigate these risks accordingly. Regulations are ultimately there to protect the patient and user from risk, and there are any different types of risk. ISO14971 is the standard for medical device risk, and whilst not strictly deemed as obligatory, it is expected, so you had better have a pretty solid rationale for not adhering to it. Central to this standard is the concept of ‘Generally Acknowledged State of the Art’. You will be expected to have conducted a thorough analysis of, and have an understanding of the Generally Acknowledged State of the Art in relation to the Intended Use and Indications of your Robot. And how your device will present a favourable benefit-risk assessment against it. It is all about understanding and demonstrating device safety.

The severity of harm, if your robot malfunctions, can be catastrophic; and one malfunction can put an end to your venture in an instant. As highly complex devices the potential points of failure will go into the thousands if not tens of thousands.

Your robotic surgical instruments are where the rubber meets the road. Whilst they may not be the most complex part of your system they probably present the highest risks. Each instrument alone is a highly complex and will present some of the biggest challenges. Each cable, mechanical joint, electrical connection will present single points of failure. But you will also need to consider multiple points of failure. As an example, if the user misses the port (it happens!) and the device bends back on itself, this may cause a cable to break! But will that one break in a cable result in additional strain on the others? Will an unforeseen surge in electrical current in electrocautery result in weakening of cables? Will too high a torque from the robotic arm impact any haptic feedback through the instrument or result in parts becoming detached from the instrument?

There are countless permutations and combinations of device failure and whist we cannot be expected to foresee each one, we will be expected to have made a thorough attempt and demonstrate due diligence in the process.

Aside from risks relating to the device failing from a technical perspective, consideration of usability risks and the operating environment are equally as critical and will receive scrutiny from regulators for good reason. Whilst it is relatively safe to assume the users are all trained to a similar level clinically, there are other considerations, such as are they as tech savvy as each other? One user might love technology, be a huge fan of robotics having used them for years... whilst another may still be coming to terms with the steam engine, being a complete technophobe and avoiding them like the plague.

Both surgeons will present completely different risk profiles to the device but will likely fit your user profile. It is essential that you get input from extremes of users when analysing your risk.

And how do we deal with risks once identified, and then verify any mitigations put in place? If for example, in the case of a fault, it was decided that an audio alarm will sound... how many other alarms or noises will be present in the operating environment? How will the surgeon know how to react on being made aware of an alarm? If a visual alarm, how is it distinguishable from other flashing warnings? What if the user is colourblind?

Put simply, if you do not comprehensively analyse risks and include sound verified risk mitigations in your design, it will come back to bite you by either not getting past regulatory scrutiny, or worse resulting in an adverse event and recall. Not getting approval in the first place is actually the lesser of the two evils.

Whilst investors might not be best pleased with a delay to approval, they will be less pleased with an adverse event where a patient is harmed. I have seen devices and start-ups fail as they simply neglect to adequately consider design risk coupled with user needs, user variability, the use environment, and multiple points of failure.

What we Suggest.

With a combined 50+ years in devices we have been there, done it and got the scars as well as grey hairs to prove it. With that in mind we have the following advice:

Consider Regulator(s) as a CUSTOMER who you need to satisfy as much as those buying the system. If there is a requirement to make your surgical graspers of a certain type of material - then that is a design input. If there is a regulatory or guidance requirement to have your instrument cables to a specific tensile strength - that is a design input. If there is a requirement that an audible warning must be of a certain decibel for the use environment - that is a design input….you get the picture…
Know your user(s). You may think you know how the device will be used, or want them to use it in a certain way... but the harsh reality is, they won’t. Operating theatres can be chaotic and your robot is not the centre of attention. It needs to be easy to use by all users, including those technophobes. If you want something broken in ways you cannot conceive, give it to a medic. If you want to see how the device can be used incorrectly as well as broken in inconceivable ways, give it to two medics. Ease of use and usability is critical.
Know your applicable regulations, standards, and guidance documents from the get-go. Quality and Regulatory requirements are dynamic and you need to keep abreast of changes and trends. Many standards are also not cheap, so these will need to be budgeted for. Guidance documents are plentiful and useful, use them. Whilst they are termed ‘guidance’ and therefore not obligatory, many inspectors treat them as such.
Many requirements in regulations and standards can be interpreted and applied in different ways. You need a sound rationale to show how you interpreted and applied them. QA and RA can help with this, but it is not their ultimate responsibility. Whilst they might have scientific, engineering or medical degrees... they are not experts in everything, and cannot be expected to understand much of the technical jargon. But they will help you.
Unfortunately there is a lot of inconsistency in what reviewers/inspectors/auditors deem acceptable; with most having their own preconceived ideas. So you need to be prepared to present your case in a clear concise manner. Whilst they may have knowledge of the area they are inspecting, they will not know the product as well as you. Know your risks, mitigations and be prepared to defend them.
Lead times to regulatory clearance can be long as well as super expensive, so it is essential that you include realistic timelines in your project plans and budgets. Also keep in mind that times to regulatory clearance are often best case, and they will likely take much longer... with added costs for additional reviews. In the EU and UK, Notified Bodies and Approved Bodies are commercial entities. They charge an absolute fortune, with questionable reliability and consistency. They will make more money out of more visits and reviews... so it pays to get it right first time.
Importantly, QA and RA personnel are not the enemy! Despite what it may appear at time, they want the same outcome as you do, and are only doing their job. If they say something needs to be different, then they are saying bercause they believe a regulator will require that, based on their experience. It is not the QARA team you need to convince. Remember they do not make the rules nor necessarily agree with many of them. Their job is not an easy one, they take a lot of flack so be nice to them. (Please.)

Meeting QA and RA is more than just a tick box. A poor device may still meet regulations, same as a poor Quality System can be certified, however a poor device will not sell and may result in an adverse event, and a poor quality system will burden you down with bureaucracy. Get it right from the start. It all starts with design .

Whilst the above is targeted toward a surgical robot, what is written applies to any medical device or IVD. A blog from a clinicians point of view on devices, an area often overlooked will follow soon.