close
close

How to optimize the reliability and costs of surgical robotic systems

How to optimize the reliability and costs of surgical robotic systems

By Chris Illman, PA Consulting

The tension between reliability and cost has never been greater in the field of robot-assisted surgery (RAS). For systems in development today, focusing on reliability is the path to success. These competing factors are not as antithetical as they seem, and the right approach can optimize both simultaneously.

Early RAS systems designed and developed by Intuitive were cited as disrupting 2.5% of operations due to equipment failure that could have resulted in technical work on the machine or conversion to laparoscopic or open surgery, thereby increasing the risk to the patient. Although 2.5 percent was not a huge number, it was a significant figure and clearly needed to be minimized where patient outcomes could be compromised.

Nearly 25 years later, systems are jostling for space in the operating room, competing not only on their own functionality or specialty, but also on cost of purchase and ownership. The systems should be both cheaper and more reliable than before. This poses a challenge for new players in the rush to market.

Competing challenges

Having a reliability team or a dedicated reliability engineer is often considered a luxury, even in established companies, let alone startups. At worst, it can be seen as an obstacle or a milestone door to pass at the end of development. In a world of fundraising and tight deadlines, reliability and cost are rarely priorities when it comes to demonstrations.

Widespread attitudes lead to repeating the same mistakes. Overengineering is considered the free solution to reliability, but it doesn’t always help. The cost of goods (CoG) increases, often along with the number of parts. It is very likely that this will make the reliability worse.

The opposite mistake is to adopt the head-in-the-sand belief that reliability will only emerge during general development – ​​especially popular when cost goals are at the forefront. Lifespan testing (crucial for a product to stand the test of time) suffers a similar fate, with companies casually using their early adopters to test reliability. Releasing a product that isn’t ready can provide important feedback, but it can also poison the market against the product in perpetuity. Another challenge lies in the tendency to confuse perceived quality and reliability. Perceived quality is easy to create (for example, through intelligent industrial design), while reliability requires conscious effort, expertise and planning up front.

Finding the right balance

With so many ways to go wrong, how can we optimize reliability and cost simultaneously? How can we ensure reliability without surgical robots becoming too restrictive, slow and expensive? How will this help reduce CoG?

First, know your acronyms – they are often distorted:

  • MTTF: Average time to failure represents the time it takes for half of the machines in the field to fail, often used interchangeably to describe reliability.
  • MTBF: Mean time between failures is the time between repairable faults. It’s more useful.
  • MTTR: Average repair time is much more interesting for a complex system like a robot.
  • Mountain biking: Average time between services has an obvious interdependence with MTBF.
  • Availability: A combination of MTBF and MTTR, this is a measure of how often a system will be available, which is very useful to the clinician. This is why we really need to optimize.
  • RFD: Designed for reliability is the discipline that brings it all together.

Profiling a system for high availability is the art of balancing all the above factors with CoG and development cost without requiring 100% reliability of the machine. Here, “best” is the enemy of “good enough.” The chart below shows the sweet spot. The lowest total cost (taking into account development and failure costs) appears at less than 100% reliability – good news. The total cost line typically slopes sharply to the right, where further work on reliability has diminishing returns. To optimize costs and quality, target “good” not “perfect”.

Put in place the right management

Creating a reliable product is a management task. Establish a dedicated DFR workflow from the start, with the leadership necessary to hold the engineering team accountable for driving the project. appropriate reliability balance. Do this, regardless of the size of your design team, and you will see the benefits in CoG and cost of ownership. Here are the entries:

  • Eestablish a business directive – define the limit you are willing to spend on repair and replacement once in the market as well as the scope of a reliability program.
  • Define high-level reliability requirements around availability and lifespan (MTBF).
  • Be realistic about MTBS – you want service touchpoints with a robot, and none will or should ever be free of them.
  • Develop market knowledge – know what clinicians expect and, most importantly, how your equipment will be used. Only when the environment is known can you design accordingly. Not being the first robot to get approval helps here (in fairness to Intuitive’s early Da Vinci models).
  • Let your reliability engineer carefully evaluate all mandatory reliability standards and requirements; The BS5760 series is an excellent manual for navigating the path, but specific standards may require reliability for safety reasons.
  • we do not count twice the safety margin according to the specifications – authorize your reliability engineer to do this to avoid raising CoGs.

A reliability-minded engineer should target reliability with low CoG and low operating costs from the start of the development project. Simple designs tend to be inherently reliable, inexpensive, and completed quickly, but design teams have a habit of deviating from this path without guidance.

Leveraging Lifetime Testing

The best indicator of field reliability at the R&D stage is a meaningful and representative life test – a long, scary line in the GANTT chart of development and required by developing regulations. If the reliability workstream was successful, this should go smoothly: a confirmation check. Testing subsystems throughout development should leave no surprises, no costly rework, and no quick duct-tape fixes before product release. The system will be neither over-reliable nor unreliable, with appropriate maintenance intervals and recoverable error states.

It takes considerable skill to accelerate life testing while still achieving meaningful results. Surgical robots have an advantage here over many other complex systems because much of the load is intrinsic. Factors such as self-weight, wire tension and thermal management make up the lion’s share of the service load. These factors are predictable and can be used to successfully streamline life testing. Perform these tests correctly and you will launch your product into the market with confidence that clinician perceptions will be positive and that there will be no costly recalls or warranty claims.

High availability at launch will help establish a reputation for excellent quality at a given price point. After product launch, continuous reliability monitoring is an ongoing task. If the system is well characterized in terms of reliability, it is ideal for generating additional costs. Continuous monitoring will highlight areas requiring further optimization and generate valuable data that can help extend the life of the MTBS or equipment or highlight further reduction in CoGs. The natural extension of monitoring is real-time telemetry to monitor equipment usage and health, enabling predictive maintenance and repair, and even informing an intelligent supply chain. Closing this loop allows you to control machine availability.

The tension between reliability and cost in surgical robotics has never been greater. But by prioritizing a robust methodology for reliability engineering, you can find the right balance.

About the authors:

Chris Illman is a biomedical engineer based at PA Consulting’s Global Innovation and Technology Center in Cambridge, England. He has years of experience in new product development and compliance of existing products.