Sam Brusco, Associate Editor11.01.22
Robotic assistance during surgical procedures has largely been provoked by surgeon demand. Robotic-assisted surgical devices feature smaller, more precise instruments so the surgery can be done without an open procedure and with improved dexterity. A robotic strategy can offer better—even 3D—visualization of the surgical site, reduced post-operative pain, and minimal scarring. The technology has entered the fabric of healthcare so strongly that medical schools and residency programs have embraced surgical training using robotic technologies.
Tom Amlicke, software architect and robotics systems engineer and Shawn Vanseth, business development specialist at MedAcuity, a specialized engineering firm that focuses on medical technology software development, contributed input to the June 2022 MPO feature article “Robotic Surgery: Cutting Through to the Latest.” The breadth of their input was not included in the article, so the entirety of their insights are included here.
Sam Brusco: What are the dominant market forces and challenges currently at play in the surgical robotics market?
Shawn Vanseth: The COVID-19 pandemic, along with various other factors, contributed to a global semiconductor chip shortage, wreaking havoc on the supply chain, especially for hardware components—critical to manufacture of surgical robots/robotic devices. Thousands of components are needed for complex surgical robotic devices, putting a heavy reliance on global manufacturers and suppliers of these components and parts.
Impact to device OEMs is felt at both the business and technical levels. Business tradeoffs are being made to maintain project schedules; they’re resorting to using available components instead of the “best.” Creative work arounds by product owners and system architects to find available processors and components to work with are creating a two-fold problem: making redesign decisions on the fly that disrupt project management schedules, and product managers and system architects spending time on unplanned activities—time away from the actual development effort.
The surgical/medical robotics market is a startup-rich environment heavily reliant on funding. Today, we’re seeing a more risk-averse posture from VC firms. They’re less likely to invest early in robotics startups; rather, they’re more apt to invest later down the line once a proof-of-concept has been developed and they see something tangible. This lack of early-stage investment is making it more challenging for startups to survive the early stages. Startups we have worked with talk about a seven-to-ten-year journey for their companies before they came out of stealth mode with a proof-of-concept to attract investors. A proven robotic technology combined with a strong vision/plan and creative investment approaches is crucial for medical robotics startups to successfully navigate these early years.
There has already been crossover from the industrial and logistics robotic market segments into medical when it comes to basic/fundamental robotic technology. We predict more industrial robotic technology companies will either enter the medtech space or form partnerships with medical device OEMs. It’s not uncommon for companies in most markets to either build the technology themselves, buy it from someone, or acquire the technology by acquiring the company. We could soon see more M&A and partnership activity in this space.
The immense focus on labor shortages is driving the need to widen the net for attracting talent and to invest in training. Often overlooked but a cause of major issues, especially with technical leadership from a purely non-medical robotics background trying to develop a medical robotic. Short cuts are taken only because of unfamiliarity with the applicable standards and regulations. The amount of rework that goes into proper compliance, documentation, etc. is costly and can delay 510(k) submissions and clinical trials. Talent coming from non-medical or non-regulated industries will require time and training investment to bring them to the level of understanding the magnitude of the regulatory/compliance landscape for developing medical/surgical robots before they get burnt.
Tom Amlicke: System architects/engineers must work with both product owners and procurement to create designs that can be implemented to make a market window. You cannot assume any required system components are available, and you may need to find more alternatives. System architectures must be more robust to adapt to this dynamic supply chain.
The downstream impact of this hardware shortage requires adjusting software development timing based on availability of system components. Working in model-based design tools like MATLAB and Simulink to create robotic controls systems and complex medical device algorithms provides an advantage in this crisis. The model-based design tools allow designs to be developed and tested in simulations or on hardware simulators like Speed Goat. Teams can make progress verifying their designs without the final hardware available.
Medical device OEMs purchasing commercial off-the-shelf medical grade robotic arms vs. building their own is fast becoming one of those business tradeoffs we mentioned earlier. It takes multiple engineering disciplines—mechanical, electrical, software—to build robot arms. If commercial robot arms meet the device OEMs’ specs and they can purchase it now, they will. This gives OEMs a leg up in making their market window, plus they’re not faced with sourcing components to build their own arms. The robotic arm manufacturers are ahead in the queue when it comes to sourcing the necessary hardware components.
Brusco: How is MedAcuity responding to these trends?
Amlicke: We’re investing in more MATLAB and Simulink coding licenses to train our engineers to use these technologies we see as critical to dealing with the supply chain challenge. Using these tools in combination, we can simulate and test a design for a surgical robotic device/system without the final hardware. This allows us to do a lot of work while waiting for the hardware to arrive. We use hardware simulators to connect our algorithms to real sensors and actuators to verify their capabilities without having the final hardware. One of the key business benefits of modeling and simulating dynamic robotic systems is the ability to maintain efficiency and velocity on the project.
Good configuration management and testing are critical for software teams to navigate the flux of architectural changes driven by the unstable supply chain. The ability to go back to software that worked with a different hardware component is a more common occurrence these days. Having a trusted set of regression tests can give the software development team confidence in their ability to move quickly with changes and know their software will still achieve its essential performance. Good configuration management and automated testing also lead to more predictable schedules, since code is easy to find and tests “fail-fast” finding problems quicker than traditional manual verification testing. Test automation is considered an upfront investment most OEMS balk at, but is a cost saver in the long run. Without an effective test automation strategy, you will inevitably find yourself laboring through hundreds of changes in an attempt to isolate and track down root causes of failure. The time and effort spent doing so will outweigh costs of deploying test automation from the start.
Brusco: What challenges often arise in developing components/devices/software for surgical robotics? What challenges, if any, have taken you by surprise?
Vanseth: The challenges often arising are the result of two industries converging, and at times, clashing. If you look at it from a pure technology perspective, changing non-medical robotic technology to meet the safety, security, and reliability of a medical device is no small feat. A robot picking inventory in a warehouse is not the same robotic technology required to perform laparoscopic surgery.
What we continue to see with either startups or well-established device OEMs expanding into surgical/medical robotics is the lack of technical talent skilled/experienced in both medical devices and robotic technology. You can find technical talent well skilled in medical device development or roboticists but not both. For most medtech OEMs, a training and development investment is required to bridge this gap. We saw this coming and began hiring talent from both sides and cross-training. Our architects and software engineers offer a blend of expertise in both medical devices and regulated robotics.
Amlicke: More of a "we saw this coming" moment than a surprise is the expectation that software engineering know more hardware when working on robotics. Our medical device clients must ahdere to IEC 60601. Our non-medical robotics clients design to the IEC 61508 standard. We have seen clients building large-scale medical device apply both. Organizations suchas TUV are starting to apply functional safety defined in IEC 61508 to medeical devices.
When developing software for surgical robotics, roboticists have no experience creating medical-grade code—a Class C software. IEC 62304 defines three safety classes for software: Class A – no injury or damage to health is possible; Class B – non-serious injury is possible, and Class C - death or serious Injury is possible. Safety to most roboticists is typically limited to “Hit the big red button” when thing go wrong. Roboticists lack an understanding of the risk-based approach of IEC 62304 and ISO 14971. Risk drives the design, and the medical device designer must show evidence of risk mitigation throughout development. This usually becomes apparent to the roboticists when instructed by QA that they must create unit tests to cover 90% of their code and document the evidence that the tests passed.
The process of developing medical software code is much more labor intensive and governed by a software development plan with a strict process for following that plan. Depending on the software class, you must have these things in place and do them in a specific order. This will require the roboticists to go back to their requirements and rework all derived design artifacts required in IEC 62304. Unfortunately, some roboticists will move on to the next robot project instead of enduring the rigor of the medical device process burden.
Another gap for roboticists is they don’t necessarily know how to apply two critical standards from the Association for the Advancement of Medical Instrumentation (AAMI) specific to developing medical device software: TIR45 and TIR57. AAMI TIR45 provides guidance on how to implement Agile in the development of medical device software. Agile practices have gained significant popularity in the medtech industry and carry the FDA endorsement as a valid approach.
The FDA also recognizes the AAMI TIR57 standard as a “foundational cybersecurity standard for medical devices.” It cannot be underscored enough—in today’s healthcare ecosystem of connected medical devices and systems, all devices must be protected from cybersecurity threats. This might be new thinking for roboticists not familiar with the more heavily regulated medtech space.
Startups working in this space may not make cybersecurity a priority. Because their focus is most often on developing a proof-of-concept or minimum viable product (MVP), device security is not top of mind because it may not be required—or so they think. Working with clients in this situation, we build an architecture that allows them to add the proper security controls in the future when they move their MVP to a final product that will connect to the hospital network and/or cloud.
Tom Amlicke, software architect and robotics systems engineer and Shawn Vanseth, business development specialist at MedAcuity, a specialized engineering firm that focuses on medical technology software development, contributed input to the June 2022 MPO feature article “Robotic Surgery: Cutting Through to the Latest.” The breadth of their input was not included in the article, so the entirety of their insights are included here.
Sam Brusco: What are the dominant market forces and challenges currently at play in the surgical robotics market?
Shawn Vanseth: The COVID-19 pandemic, along with various other factors, contributed to a global semiconductor chip shortage, wreaking havoc on the supply chain, especially for hardware components—critical to manufacture of surgical robots/robotic devices. Thousands of components are needed for complex surgical robotic devices, putting a heavy reliance on global manufacturers and suppliers of these components and parts.
Impact to device OEMs is felt at both the business and technical levels. Business tradeoffs are being made to maintain project schedules; they’re resorting to using available components instead of the “best.” Creative work arounds by product owners and system architects to find available processors and components to work with are creating a two-fold problem: making redesign decisions on the fly that disrupt project management schedules, and product managers and system architects spending time on unplanned activities—time away from the actual development effort.
The surgical/medical robotics market is a startup-rich environment heavily reliant on funding. Today, we’re seeing a more risk-averse posture from VC firms. They’re less likely to invest early in robotics startups; rather, they’re more apt to invest later down the line once a proof-of-concept has been developed and they see something tangible. This lack of early-stage investment is making it more challenging for startups to survive the early stages. Startups we have worked with talk about a seven-to-ten-year journey for their companies before they came out of stealth mode with a proof-of-concept to attract investors. A proven robotic technology combined with a strong vision/plan and creative investment approaches is crucial for medical robotics startups to successfully navigate these early years.
There has already been crossover from the industrial and logistics robotic market segments into medical when it comes to basic/fundamental robotic technology. We predict more industrial robotic technology companies will either enter the medtech space or form partnerships with medical device OEMs. It’s not uncommon for companies in most markets to either build the technology themselves, buy it from someone, or acquire the technology by acquiring the company. We could soon see more M&A and partnership activity in this space.
The immense focus on labor shortages is driving the need to widen the net for attracting talent and to invest in training. Often overlooked but a cause of major issues, especially with technical leadership from a purely non-medical robotics background trying to develop a medical robotic. Short cuts are taken only because of unfamiliarity with the applicable standards and regulations. The amount of rework that goes into proper compliance, documentation, etc. is costly and can delay 510(k) submissions and clinical trials. Talent coming from non-medical or non-regulated industries will require time and training investment to bring them to the level of understanding the magnitude of the regulatory/compliance landscape for developing medical/surgical robots before they get burnt.
Tom Amlicke: System architects/engineers must work with both product owners and procurement to create designs that can be implemented to make a market window. You cannot assume any required system components are available, and you may need to find more alternatives. System architectures must be more robust to adapt to this dynamic supply chain.
The downstream impact of this hardware shortage requires adjusting software development timing based on availability of system components. Working in model-based design tools like MATLAB and Simulink to create robotic controls systems and complex medical device algorithms provides an advantage in this crisis. The model-based design tools allow designs to be developed and tested in simulations or on hardware simulators like Speed Goat. Teams can make progress verifying their designs without the final hardware available.
Medical device OEMs purchasing commercial off-the-shelf medical grade robotic arms vs. building their own is fast becoming one of those business tradeoffs we mentioned earlier. It takes multiple engineering disciplines—mechanical, electrical, software—to build robot arms. If commercial robot arms meet the device OEMs’ specs and they can purchase it now, they will. This gives OEMs a leg up in making their market window, plus they’re not faced with sourcing components to build their own arms. The robotic arm manufacturers are ahead in the queue when it comes to sourcing the necessary hardware components.
Brusco: How is MedAcuity responding to these trends?
Amlicke: We’re investing in more MATLAB and Simulink coding licenses to train our engineers to use these technologies we see as critical to dealing with the supply chain challenge. Using these tools in combination, we can simulate and test a design for a surgical robotic device/system without the final hardware. This allows us to do a lot of work while waiting for the hardware to arrive. We use hardware simulators to connect our algorithms to real sensors and actuators to verify their capabilities without having the final hardware. One of the key business benefits of modeling and simulating dynamic robotic systems is the ability to maintain efficiency and velocity on the project.
Good configuration management and testing are critical for software teams to navigate the flux of architectural changes driven by the unstable supply chain. The ability to go back to software that worked with a different hardware component is a more common occurrence these days. Having a trusted set of regression tests can give the software development team confidence in their ability to move quickly with changes and know their software will still achieve its essential performance. Good configuration management and automated testing also lead to more predictable schedules, since code is easy to find and tests “fail-fast” finding problems quicker than traditional manual verification testing. Test automation is considered an upfront investment most OEMS balk at, but is a cost saver in the long run. Without an effective test automation strategy, you will inevitably find yourself laboring through hundreds of changes in an attempt to isolate and track down root causes of failure. The time and effort spent doing so will outweigh costs of deploying test automation from the start.
Brusco: What challenges often arise in developing components/devices/software for surgical robotics? What challenges, if any, have taken you by surprise?
Vanseth: The challenges often arising are the result of two industries converging, and at times, clashing. If you look at it from a pure technology perspective, changing non-medical robotic technology to meet the safety, security, and reliability of a medical device is no small feat. A robot picking inventory in a warehouse is not the same robotic technology required to perform laparoscopic surgery.
What we continue to see with either startups or well-established device OEMs expanding into surgical/medical robotics is the lack of technical talent skilled/experienced in both medical devices and robotic technology. You can find technical talent well skilled in medical device development or roboticists but not both. For most medtech OEMs, a training and development investment is required to bridge this gap. We saw this coming and began hiring talent from both sides and cross-training. Our architects and software engineers offer a blend of expertise in both medical devices and regulated robotics.
Amlicke: More of a "we saw this coming" moment than a surprise is the expectation that software engineering know more hardware when working on robotics. Our medical device clients must ahdere to IEC 60601. Our non-medical robotics clients design to the IEC 61508 standard. We have seen clients building large-scale medical device apply both. Organizations suchas TUV are starting to apply functional safety defined in IEC 61508 to medeical devices.
When developing software for surgical robotics, roboticists have no experience creating medical-grade code—a Class C software. IEC 62304 defines three safety classes for software: Class A – no injury or damage to health is possible; Class B – non-serious injury is possible, and Class C - death or serious Injury is possible. Safety to most roboticists is typically limited to “Hit the big red button” when thing go wrong. Roboticists lack an understanding of the risk-based approach of IEC 62304 and ISO 14971. Risk drives the design, and the medical device designer must show evidence of risk mitigation throughout development. This usually becomes apparent to the roboticists when instructed by QA that they must create unit tests to cover 90% of their code and document the evidence that the tests passed.
The process of developing medical software code is much more labor intensive and governed by a software development plan with a strict process for following that plan. Depending on the software class, you must have these things in place and do them in a specific order. This will require the roboticists to go back to their requirements and rework all derived design artifacts required in IEC 62304. Unfortunately, some roboticists will move on to the next robot project instead of enduring the rigor of the medical device process burden.
Another gap for roboticists is they don’t necessarily know how to apply two critical standards from the Association for the Advancement of Medical Instrumentation (AAMI) specific to developing medical device software: TIR45 and TIR57. AAMI TIR45 provides guidance on how to implement Agile in the development of medical device software. Agile practices have gained significant popularity in the medtech industry and carry the FDA endorsement as a valid approach.
The FDA also recognizes the AAMI TIR57 standard as a “foundational cybersecurity standard for medical devices.” It cannot be underscored enough—in today’s healthcare ecosystem of connected medical devices and systems, all devices must be protected from cybersecurity threats. This might be new thinking for roboticists not familiar with the more heavily regulated medtech space.
Startups working in this space may not make cybersecurity a priority. Because their focus is most often on developing a proof-of-concept or minimum viable product (MVP), device security is not top of mind because it may not be required—or so they think. Working with clients in this situation, we build an architecture that allows them to add the proper security controls in the future when they move their MVP to a final product that will connect to the hospital network and/or cloud.