Connectivity in medical devices has become ubiquitous. No longer a novelty, the ability to gather and exchange data across a network of devices is often a required part of any modern system.

 

Devices with more sophisticated connectivity offer extensive potential improvements: data collection allows manufacturers to improve patient outcomes by analyzing usage patterns, augmenting device behavior with off-device functionality, such as AI. By uncovering opportunities for expanded functionality and usability improvements, or even improved training, a device can gain wider adoption within a healthcare facility. For devices used in the home-care setting, providers can ensure proper use based on information collected centrally and integrated with EHRs.

 

Improvements to support and serviceability both streamline operations for the manufacturer and lead to better customer satisfaction. Over-the-air software updates pushed remotely can keep systems more secure and up to date. Manufacturers can fast track field service by preparing technicians with the data they need ahead of a site visit, and even ensuring the availability of parts ahead of time.

 

Product managers are well positioned to ingest the wealth of data produced by connected devices to feed future innovation. Disused functionality can be replaced with new features. Workflow optimization becomes easier based on real-world feedback. And through it all, engineers can fine tune algorithms with larger datasets to produce better results.

 

Unlocking this potential, however, requires more than an extension of the status quo. Connected, distributed software systems have little in common with the static, self-contained device software of old. Delivering scalable, secure, stable software connected to a fast-paced cloud ecosystem necessitates a different approach to engineering. The key challenges a medical device company must overcome include distributed system architecture, a more expansive view of data and system security, the ability to adapt to constantly updating dependencies, a nimbler approach to verification, fast-paced development methodologies, and more complex and evolving regulatory requirements.

 

Architecture

 

Distributed systems have different architectural needs than self-contained system software. Systems designed to interact with entire fleets of devices, often installed around the globe, must be scalable and highly available. And with the resulting complexity, a monolithic approach to architecture quickly becomes an inflexible maintenance and quality nightmare.

 

Software companies building large scale applications in the cloud have solved these problems through the microservices architecture pattern. Large applications are broken up into small, well-defined services on domain boundaries. Each service operates independently, with a strong API contract to dictate how it interfaces both with other services and outside callers.

 

The resulting software becomes more maintainable by significantly reducing the amount of tightly integrated code, as well as the overall scope of each service. Scalability is no longer a question of sizing up an entire system, but instead each service scales up and down based on its own load. And by architecting a distributed system to work statelessly across geographic regions, high availability is achieved even in the event of local failures.

 

Finally, 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 can easily fail at scale due to financial factors.

Security

 

The FDA’s April 8, 2022, draft guidance on Cyber Security in Medical Devices represents only the latest step in the journey making security top of mind for the industry. The need for security in a distributed system has become self-evident, however, simplistic patterns for achieving security are not sufficient. Fortunately, security can be treated as the default option – but only if designed correctly from the start. Distributed systems that implement security as an afterthought often result in costly rework to achieve the desired protection.

 

For connected systems integrating with medical devices, security considerations must be addressed at all architectural levels. Obvious concerns include connections between devices and servers, which must implement industry standard encryption in the transport layer. But that’s just the beginning.

 

Within the device, software must be signed to ensure any updates installed 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 cloud-connected distributed systems, the industry is increasingly adopting a policy of “zero trust”. This means it is no longer acceptable to assume that once a caller is allowed into the system that the caller can be considered trustworthy. Instead, all components of a large system are responsible for restricting access and validating operations. This limits the “blast radius” of a breach, as a security hole in one part of the system does not become a problem for the whole system. In tandem with the principle of “least privilege”, this ensures that security in systems incorporating cloud services is now the rule and not the exception. This is a key approach that can only be effective if built from the start, as retrofitting zero trust requires significant rework.

 

Closely related to security concerns, data privacy has been long established as a key architectural requirement. This topic may cover multiple areas, including PHI and proprietary data. And while manufacturers are already focused on HIPAA concerns, GDPR brings additional constraints targeted at the European market. Correctly architected, a cloud application can store sensitive data securely with access allowed only to authorized requesters. While techniques such as database encryption and regional sharding provide a means to address these concerns, these solutions are not a panacea. Developers must take care to avoid leaking sensitive data through logs, and access controls require thoughtful design to correctly gate PHI.

 

Even properly guarded against unauthorized access, a connected system can easily fall victim to a DDoS or other external attack. Without the right system architecture and the correct tools to mitigate an attack, a system can be taken offline by a remote attacker. The result could have life-threatening implications to patients, in addition to downtime, loss of data, and damage to the company’s reputation.

Dependency Management

 

Modern software systems are increasingly built on off-the-shelf software stacks that comprise countless 3^rd party dependencies. A simple single page application built using any of the most popular web frameworks may include thousands of libraries once the dependency tree is fully explored. Often 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 hopelessly out of date in a matter of months without the right maintenance strategy. This represents a fundamental change to software maintenance for device manufacturers. Annual, or even quarterly updates are insufficient to keep pace with components that must constantly respond to security issues and other defects.

 

The FDA’s April 8, 2022 draft guidance makes it clear that manufacturers are ultimately responsible for vetting and managing the risks associated with 3^rd party software components: “all software, including that developed by the device manufacturer… and obtained from third parties should be assessed for cybersecurity risk and that risk should be addressed.” These risks are constantly evolving as issues are discovered over time. Keeping pace with change is more than just good hygiene for a manufacturer, it is a necessity.

 

The risks of letting a code base become stale are twofold. First, security issues in external libraries are certain to be exploited in a matter of time. Second, and perhaps more concerning, modern libraries used in web and cloud applications move fast and are quick to introduce non-backwards compatible changes. Small, incremental upgrades to components are relatively painless. But once an application has fallen too far behind it becomes costly and time consuming to catch up. A company that waits until they have a problem at hand will almost certainly be unable to respond in a timely fashion.

 

The software industry has produced tools to solve these problems, with dependency scanners built into cloud platforms and source control systems that will catch out of date components in both software and operating systems. However, making use of these tools is far from automatic. Updates must be made by engineering staff on a regular basis, complete with regression testing and a staged deployment strategy to avoid production outages. This requires continuous monitoring, and a commitment to investing in maintenance. The DevOps philosophy that has taken root in the software industry in recent years is becoming increasingly relevant in the medical device industry.

Verification

 

Given the pace of change common in distributed systems built on the cloud, verification has the potential to introduce crippling bottlenecks. The waterfall approach of executing a comprehensive test plan after completing development does not scale to a release cycle that can be measured in days or even hours.

 

Test automation is key to breaking this bottleneck. But this is 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. Detailed system analysis should 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 manual procedures.

 

Code must be written in a manner that facilitates automated testing, with components having clearly defined code contracts and being capable of running in isolation. Test scripts also require their own 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.

Development

 

The approaches described above represent a different way of thinking about software development. Engineers working in the medical device space have traditionally approached problem solving in a top-down waterfall fashion that assumes a more deliberate and carefully planned approach, with a division of labor that breaks up work across teams by function. Working at the pace required to adapt and update distributed systems is incompatible with this philosophy.

 

Software teams working in this environment must be cross-functional, with the skills necessary to rapidly design, build, test, and deploy small components. This has become commonplace in IT shops but is a challenge when applied to regulated medical devices. Teams must still satisfy regulatory requirements, but without falling back to old habits that assume a monolithic project. This is an uncommon combination of skills in the industry.

 

This change of approach extends beyond the development team. Maintaining a distributed system requires an around-the-clock focus on operations. An after-hours disruption cannot wait for Monday morning, and certainly can’t be put off until the next planned release cycle. Companies operating in this space must be prepared with the people and tools necessary to monitor systems, identify problems, and deploy solutions with a sense of immediacy.

Regulatory

 

In addition to being a good practice in general, addressing these topics is increasingly on the FDA’s radar. A well-architected system is crucial to the safe and effective operation of a connected medical device. A comprehensive assessment of patient risks and cyber security risks, paired with a design built around cyber security and updatability, is required 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 aspects 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. This is especially true for security risks.

 

The concern for a security breach affecting a medical device is obvious, but the FDA in the April 8, 2022 guidance also warns of the risk to other networks by a compromised component of a connected system. Creating a secure healthcare environment requires all players to adequately consider potential threats while also adopting a zero-trust posture.

 

Whether connected to the public internet or limited to a hospital network, connected medical devices operate in an ecosystem rife with pitfalls and in a constant state of change. To design a system that is both effective and economical, system architects must carefully draw domain boundaries with consideration for patient and security risks. Done correctly, the maintenance burden of a large system is minimized, avoiding crippling verification and operational costs.

Conclusion

 

Connected medical devices, either limited to well-defined integration use cases or part of a sprawling digital ecosystem, are now table stakes for Manufacturers. But while the technology around distributed systems is rapidly maturing, the impact on the medical device industry is unique.

 

The fundamental changes to system architecture, especially for cyber security and risk analysis, paired with the short cycle nature of today’s tech stacks, create barriers to entry for Manufacturers. Existing software teams must rebuild skillsets 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 the industry.

 

Interested in delving into how these changes and considerations impact your organization? Contact us for a discussion.