Cloud-connected devices

The technology underlying the medical device industry has evolved significantly over the past few decades. For practical and prudent reasons, the industry’s never on the bleeding edge of technology, but rather a few steps back; in most cases adopting technology only after its been proven in other, less risk averse, sectors. Due to their more intense focus on clinical technology, medical device companies have intentionally lagged in adoption of new computer-related technology.

However, the technology pressures mounting on device manufacturers today seem quite different. The rapid evolution of cybersecurity threats, and associated escalating regulatory impacts, is happening in parallel with similar challenges and pressures in the rest of the commercial domains. Artificial intelligence (AI) and machine learning (ML) adoption is accruing not only coincident with other industries, but in the case of imaging diagnostics, it may even be ahead of the others.

All this technological change, and its related regulatory impact with the usual march of clinical technology and knowledge is placing enormous strains on research & development (R&D) organizations and budgets in the medtech industry. Throughout the past decade, R&D as a percentage of revenue has increased significantly in the device industry. In 2010, R&D as a percentage of revenue was a bit more than 7%. By 2021, it was more than 12%.

These changes are being felt directly in the existing fielded products of the industry, as well as in the organizations that develop and sustain them. Each of these new technologies and associated capabilities are stressors to product and system architectures, development methodologies, verification strategies, deployment processes, and product support needs. Below we take a quick look at several the product development and support changes.

Security

The U.S. Food and Drug Administration’s (FDA) recent announcement that all submissions of cyber devices has shortened the useful life for nearly all shipping medical devices. Any device that connects to the cloud or the internet will now need to meet the new Cybersecurity Requirements.

The need for security in a distributed system is clear. However, simplistic patterns for achieving security aren’t sufficient. For connected systems that include medical devices or medical device functions, security considerations must be addressed architecturally and evolve, even when the product isn’t changing.

Within the device, software must be signed to ensure installed updates were produced by an authorized source. Access through a user interface must implement authentication and authorization, while simultaneously avoiding the risk of locking out a provider during a life-threatening emergency.

For connected, distributed systems, the industry must adopt a policy of zero trust, meaning it’s no longer acceptable to assume that once access into the system is granted the caller can be considered trustworthy. Instead, in order to limit the blast radius of an unauthorized user gaining access to the system, each component is responsible for restricting access and validating operations. This is a key approach that can only be effective if built from the start, as retrofitting zero trust requires significant architectural rework. Even properly guarded against unauthorized access, a connected system can easily fall victim to a distributed denial-of-service (DDoS) or other external attack. The result can have life-threatening implications to patients, in addition to downtime, loss of data, and damage to the hospital’s reputation.

In addition to requiring a more robust treatment of cybersecurity within the fielded products, a robust cybersecurity support process must be demonstrated. Monitoring the products’ cyber performance is coupled with this requirement to ensure a thorough vetting of all utilized third-party components, including any patches or updates to those products, throughout the entire life of the product.

The FDA’s new guidance makes it clear that manufacturers now are responsible for vetting and managing the risks associated with third party software components. These risks are constantly evolving as issues are discovered over time and updates and patches are released.

This requires more detailed management of all the components used in cloud systems. Nearly all cloud systems are built using off-the-shelf software technology stacks that comprise numerous third-party dependencies. Simple single page applications built using most popular web frameworks may include hundreds, sometimes thousands, of libraries once the dependency tree is fully explored. Usually well maintained and open source, many of these libraries are in a constant state of flux due to security patches and bug fixes. A finished application can become almost out of date in a matter of months without the right maintenance strategy. This represents a fundamental change to software maintenance for device manufacturers.

The cloud industry has sophisticated tools to help with these challenges. Dependency scanners built into cloud platforms and source control systems will catch out-of-date components in both software and operating systems, but processes on when and how to run them need to be created. Updates must be made by engineering staff on a regular basis, irrespective of their own release schedules, complete with regression testing and a staged deployment strategy to avoid production outages. This requires continuous monitoring, and a commitment to investing in maintenance as well as adoption of new DevOps philosophies.

Support for scalability, inclusion of emerging technologies

Integration of AI engines into new diagnostic systems is increasingly seen as a critical medical evolution. More sophisticated analysis of input streams to better understand the context of the data and the actual patient condition is required to ensure clinical value and avoid false positives.

However, AI engines are evolving at a very rapid pace. Architecting systems for the flexibility to allow easy replacement of these engines is needed to allow product evolution along with the AI industry, always fielding the most capable technology. Use of the microservices architecture pattern allows for this, and it is supportive of other characteristics such as scalability and maintainability. Failure to design for the inevitability of change, in AI as well as other components of the system, risks falling behind the competition.

Finally, a component that’s often overlooked: the impact of architectural choices on operating costs, can be extreme. Many problems of scale and availability appear easy to solve by implementing a reference architecture that has no regard for an application’s cost constraints. Economical solutions require careful up-front consideration and design. Efforts to build distributed, connected systems too often fail at scale due to financial factors.

Verification

The pace of change in cloud-based systems is fundamentally different from classic medical products, and verification strategies need to be sophisticated and current to avoid crippling bottlenecks. The siloed approach of executing a comprehensive test plan in isolation from the development team does not scale to a release cycle that can be measured in months or even weeks.

DevOps and test automation are key to avoiding or breaking this bottleneck. This involves a lot more than just writing test scripts. Cost-effective test strategies for complex, distributed software systems should be considered at the architectural level. While testing less well architected systems is possible, engineering teams that attempt to shoehorn automation into existing code often produce cumbersome, unreliable test scripts that achieve poor code coverage and challenge time and budget restrictions. Detailed system analysis must be performed before developing a test strategy to avoid being one of the manufacturers with ineffective automation that abandon their test scripts, leaving them where they started with expensive, inefficient manual procedures.

Additionally, the product code itself must be written in a manner that facilitates automated testing, with components having clearly defined code contracts and being capable of running in isolation. It’s important to not forget that the test scripts themselves also require their own updating, maintenance, and code reviews. This means development teams must adapt to a new set of responsibilities. Testing must become a core part of what a software team delivers, not an outside function operating on its own schedule.

Regulatory

A well-architected system, with strong deployment and field monitoring processes, is crucial to the safe and effective operation of a connected medical device. A comprehensive assessment of risk, both patient and cybersecurity, is needed to drive design decisions. Anticipation of future risks must also be considered to address cybersecurity and updatability as a requirement for any modern connected medical device.

With the shift to more software intensive medical systems, the FDA is evolving its approach to regulation. FDA guidance around Software as a Medical Device (SaMD) extends many of the concerns around device software to pure software solutions, but with increased flexibility in defining which components of the software system should be regulated. Where critical functionality and algorithms are implemented in the software behind connected devices, manufacturers must apply the same scrutiny and process to distributed systems as would be expected on the device.

The concern for a security breach affecting a medical device is obvious, but the FDA has recently released its new guidance on both cybersecurity and AI/ML within medical systems. Creating a secure healthcare environment requires all players to adequately consider potential threats while also adopting a zero-trust posture.

Conclusion

The fundamental changes to system architecture, especially for cybersecurity, AI, and risk analysis, paired with the shorter cycles of today’s tech stacks create new opportunities and challenges for all manufacturers. Existing product development teams must rapidly rebuild skill sets to adapt. As we have seen, this is far more than learning a new language or platform. The fundamental approach to designing, building, and maintaining a distributed system connecting medical devices represents a sea change for all OEM and system manufacturers.

Timothy Bowe is the CEO for Full Spectrum.

Full Spectrum
https://www.fullspectrumsoftware.com