Software Architecture Challenges for the Surging Robot-Assisted Surgery Market

Robot-assisted surgery (RAS) has opened numerous doors to improved patient outcomes in the 25 years since the debut of Intuitive Surgical’s da Vinci in 1998. With a robot’s ability to work with precision in small spaces, patients see better outcomes and faster recovery times with fewer complications. This breakthrough has created a surge, with hundreds of companies looking to revolutionize procedures across numerous specialties. The number of players in this space, however, does not stem from a low barrier to entry. The obstacles faced by would-be innovators are many.

The criticality of safety in these devices is self-evident. And the complexity of the underlying systems will surprise no company experienced in medical device software development. The challenges in any RAS development project are driven by the need for robust verification, coordination of multi-discipline development teams, and the sheer scale of budget, personnel, and schedule when working on complex distributed systems. Teams working on these projects require deep knowledge in niche domains. And between the need for remote proctoring and the opportunities presented by AI, cybersecurity and network performance are high priorities as well.

Success in this rapidly growing market depends on an up-front plan to meet these challenges head on. Companies that design for success are likely to outperform competitors that attempt to retrofit solutions late in the process.

Cross-Functional Development

It’s easy for even the most-experienced software development teams to discount the challenges of developing hardware for a complex system. Developing the hardware components for a surgical robot is a far cry from cobbling together a few off-the-shelf commodity components. Any engineering team in this space is going to be cross-functional, incorporating systems as well as mechanical, electrical, embedded, and digital products software engineering. All team members will need to adapt to different engineering styles and methods. Software teams accustomed to the “move fast and break things” mantra need to spend significantly more time up front on interface design to allow for the slower turnaround and high rework costs associated with hardware design. Hardware designers can aid their software counterparts by investing in device emulation and rapid prototyping to keep teams unblocked.

Architecting to Compartmentalize Risks in Robot-Assisted Surgery

The risks associated with surgical robots include more than the obvious concerns around patient safety. Hardware failure, power loss, cybersecurity incidents, network latency, and system resource contention are just a few product technology examples. An additional architecture driver is regulatory related: separation of high-risk and low-risk code to reduce the documentation impact on the project. The robot’s system architecture should isolate the technical risks to minimize the “blast radius” of a failure. An obvious example might be using multiple processors dedicated to specific functions to limit the impact of one function on another. Less obvious might be moving all low-risk support code to well-isolated processes (or processors) to reduce the percentage of code that requires high levels of regulatory scrutiny.

Architecting to Ensure Safety and Cybersecurity

Cybersecurity has become a first-class citizen in medical devices across the board. Surgical robots are certainly no exception. With needs ranging from electronic health record (EHR) integration to remote proctoring, networking is a common requirement for RAS. In addition to implementing best practices for security, the system architecture should be designed from the ground up with cybersecurity in mind. Safety-critical modules should be isolated from network-enabled modules to prevent either intentional interference by an attacker or the collateral impact of atypical network traffic (it’s not hard for another device on the network to produce a flurry of activity, causing a spike in CPU utilization on embedded devices).

Incorporating AI

Buzzword-rich predictions about AI fill up LinkedIn feeds and make for occasional nightly news fodder. But the value proposition for medical devices and RAS extends well beyond novelty value. With over 400 AI applications in medical imaging already approved, AI is on the cusp of transitioning from cutting edge to table stakes. But while the barriers to incorporating this functionality are lowering, there are still key challenges to be met.

The new FDA regulations related to AI are specifically interested in how an AI model was trained and validated, with an eye toward avoiding any potential biases. And because an AI model will inevitably be re-trained in the future, FDA requires manufacturers develop a Predetermined Change Control Plan (PCCP) to explain plans for re-training and re-validation up front, with the benefit of reducing regulatory oversite of changes within the defined limits of the PCCP. Executing these plans will require ongoing surveillance of the model’s performance in the field, meaning that an RAS product is not a one-and-done engineering effort.

While many software teams struggle to think past their current milestone, teams working on AI for RAS must plan for ongoing maintenance well before a project nears completion.

Remote Proctoring

RAS often requires remote proctoring of a procedure. Given the ubiquity of Zoom meetings and video calls, this may seem like a solved problem, easily tacked on like an afterthought at the end of the development process. However, the reliability and quality of a consumer-grade solution leave a lot to be desired in a clinical setting. We’ve all seen news interviews cut off mid-sentence due to a bad network connection or software glitch—imagine that experience during a surgical procedure!

Solid network performance must be part of the design from the beginning. Redundant network interfaces that don’t depend on notoriously unreliable hospital WiFi, paired with dedicated processing, the right codec, and optimized encoder settings are just a start. Any telemetry required to support remote proctoring must be factored in as well to ensure a remote observer has as much information about the procedure as possible. And of course, all of this brings with it the ever-present challenges of cybersecurity.

Protected health information (PHI) must be guarded at the facility, over the network, and at the remote proctoring location. Those first two points might be front-of-mind already, but it’s the remote location that is likely the weakest link in the chain. Third-party proctors may be working outside the purview of both the hospital and the surgical robot manufacturer, making it harder to control the threat landscape. The system’s cybersecurity architecture needs to take this into account.

Design for Verification (Testability)

While the importance of software verification for surgical robot safety is clear (and its documentation is required for a 510[k] submission), the complexity and burden have the potential to painfully inflate time-to-market. There are several measures that engineers can design in from the beginning to ease the process. For software verification, automation and interface mocks are key to improving testability. With hardware interfaces, test jigs are required to allow advanced emulation, including fault injection to support testing of error recovery software that can be difficult to achieve otherwise. These approaches require additional up-front planning and often absorb as much—or more—time as the actual product development itself. However, if properly planned and executed, these tools will pay off by significantly reducing integration testing time and delivering better performance against schedule.

Robot-Assisted Surgery Takes a Large-Scale Effort

As high schoolers compete in robotics competitions and novice software developers build apps over sleepless weekend hackathons, it’s easy to forget how massive and complex product development can be. Developing a surgical robot is at the high end of complexity for medical devices. Projects in this space require teams of engineers across multiple disciplines with deep expertise in a wide array of specialties.

The inputs to the process require detailed up-front planning and documentation, all with an eye toward acceptance both by the market and FDA. The outputs will include hundreds of thousands to millions of lines of code, much of it dedicated to emulation and testing.

While the innate challenges offered by robotics in general may appear to be the tallest hill to climb, cybersecurity, regulatory barriers, and rapidly evolving technologies like AI will offer a surprising degree of resistance. Companies preparing to embark on this journey must prepare for a lengthy process, hampered by a scarcity of resources and unfamiliar technical hurdles.

Starting on the Right Foot

With the market for surgical robots projected to grow 18% annually, reaching more than $20B in 2030 according to Grand View Research, opportunities abound for innovative companies seeking better patient outcomes. As with most growing segments, time-to-market is one of the key factors in holding the competition at bay. This is made uniquely complicated by the need to prioritize safety and carefully manage risks throughout a new product initiative.

Planning a development project with the key challenges in mind from day one creates the smoothest possible path to product realization. This includes addressing safety and security, understanding the choreography behind multi-discipline teams, and coordinating long-running efforts comprising numerous and varied subject matter experts.

Most companies in the RAS space will have access to only a subset of the competencies required to successfully bring a product to market. Robotics, cybersecurity, user experience and interface design, and safety-critical real-time control expertise are just a sampling of the skills required—not to mention experience working in a regulated space.

As the RAS industry continues to mature, new players don’t need to start from scratch. Engineering leaders in this field have developed hard-won best practices over the years. Successful players in this field understand when to develop and maintain expertise in-house versus when to engage outside partners to fill the gaps. Leveraging the right expertise from planning through implementation and verification is a prerequisite to success.