As life-critical medical devices become more connected, the engineering challenge increasingly extends beyond the device itself. A single solution may now include external controllers, mobile applications, cloud platforms, clinical interfaces, and third-party systems, each with its own dependencies and lifecycles.
For engineering teams, this impacts how they design the wider system. Connectivity can be interrupted. Software versions can become incompatible. External platforms can change independently of the device. And while a device itself may remain in service for years, the mobile applications, operating systems, and cloud services around it may change far more frequently.
Engineering the wider ecosystem therefore means understanding how these components depend on one another, what happens when one is unavailable, and which functions need to keep working regardless.
In this final article in our Engineering Life-Critical Devices Series, we look beyond the device to the wider connected ecosystem. We explore the connectivity, architectural, verification, and lifecycle considerations involved in engineering systems that must remain reliable as surrounding technologies evolve.
Connectivity requirements need to be defined across the entire connected ecosystem, not just the medical device itself. Engineers must consider what data must be transmitted between devices, mobile applications, cloud platforms, and clinical systems, how often it needs to be exchanged, and the required levels of throughput, latency, and reliability. For example, a therapy adjustment command sent from a clinician interface has very different latency requirements from diagnostic log uploads or periodic patient monitoring data. Treating all traffic the same can add complexity, increase power consumption, and raise mobile data plan costs.
As transmission frequency or range increases, power consumption may also rise, so communication technology must deliver the required performance within the device's physical and energy constraints. For implanted or wearable devices, where power capabilities may be particularly limited, connectivity decisions can directly affect battery life and broader architectural decisions about where functionality, processing, and data storage reside within the ecosystem.
Another important consideration is that continuous connectivity cannot always be assumed. Engineers need to define how the system behaves when communication is disrupted: which functions continue locally, what data is retained, and how the system returns to a consistent state once the connection is restored.
A key architectural decision is where functionality should reside. Functions that once sat entirely within the medical device may now be distributed across the device, an external controller, mobile application, cloud platform, or other digital services. Where a function sits has practical consequences. It can affect response times, usability, cybersecurity, what happens when connectivity is lost, and how easily individual parts of the ecosystem can be changed later.
Safety-critical functions that require immediate action, such as detecting a patient condition and triggering a response, should reside on the device. In contrast, less time-sensitive functions such as analytics, reporting, or population-level insights may be handled elsewhere in the ecosystem. Raw patient data from the device might need to travel to cloud-based back-end applications for specialized processing (e.g., AI-based clinical decision support), and clinical insights need to return in real time to the HCP at the point of care. All these cases require thoughtful planning, partitioning, and interfacing. The architecture should also avoid creating unnecessary dependencies on components that may not always be available, such as mobile applications or third-party integrations.
A failure in one part of the ecosystem shouldn't automatically compromise the rest. If a cloud service goes down or a third-party integration changes, the device still needs to behave safely. Clearly defined interfaces and responsibilities help contain those failures and reduce the knock-on effects of updates or outages. This is especially important in ecosystems where components operate on very different lifecycles.
Cybersecurity must also be addressed as an architectural concern, not an isolated feature. As functionality and data spread across the ecosystem, security considerations become closely tied to how those components communicate. Access needs to be controlled, data protected, and communications secured without introducing dependencies that could reduce availability or affect patient safety.
Effective verification depends on placing the right amount of test effort at each level of the system, from components and modules through integration and full-system testing. Defects are generally faster and less costly to diagnose and correct when they are detected close to where they are introduced; when the same problems surface only at system level, isolating their root cause becomes significantly more difficult and expensive.
The number of possible configurations can grow quickly. Different device and firmware versions may need to operate with multiple mobile platforms, operating systems, application versions, cloud services, network configurations, and third-party systems. As the ecosystem evolves, an increasingly complex verification matrix emerges that cannot practically be tested in every possible combination.
Engineering teams need to define which interfaces and configurations they control, which combinations they support, and what level of representative testing provides sufficient coverage. A risk-based approach can help determine where to concentrate verification effort, particularly around interfaces, configurations, or functionality that could affect therapy delivery or patient safety.
At that scale, manual regression testing quickly becomes impractical. Test firmware, emulators, simulated services, and automated regression environments allow teams to cover far more of the supported configuration space.
Verification must also cover conditions in which the ecosystem does not behave as expected. Interrupted communications, unavailable services, unexpected responses, incompatible versions, and interface failures can be introduced deliberately to confirm that the system detects and manages them appropriately.
Components within a connected medical device ecosystem rarely evolve at the same rate, and each change can affect an interface or dependency elsewhere in the system.
Clearly defined interfaces, communication protocols, data formats, and versioning can help limit the impact of change in one component on the rest of the system. When third parties supply or control components, teams also need to understand which dependencies sit outside their direct control and how they will identify and assess changes to those technologies.
Compatibility is especially important for medical devices with long operational lifetimes. New versions of applications, operating systems, or external hardware may be required to keep devices in use, requiring decisions about backward and forward compatibility and how long particular configurations will remain supported. Changes to one component also need to be assessed for their impact on interfaces and dependencies elsewhere in the ecosystem.
Security dependencies also change over the lifetime of the system. Vulnerabilities can emerge long after a system is released, while certificates, third-party software components, and security requirements can all change over time. Secure update mechanisms, vulnerability management, and the ability to patch affected components must therefore be considered alongside the ecosystem's functional evolution.
Case Study: Engineering a connected implantable device ecosystem
S3 Connected Health supported the development of a connected implantable medical device ecosystem comprising an implantable device, a patient subsystem with an implant control device, mobile application and website, and a clinician on-site subsystem incorporating programming hardware, software and a mobile application. The ecosystem also included a clinician portal supporting patient administration, authorization workflows, home monitoring, therapy reporting, and data synchronization, alongside applications and devices for manufacturer field representatives.
Subsystems were aligned as much as possible around common architectural patterns, data interfaces, communication protocols, and HFE and UX/UI design standards. Connectivity included RF telemetry, Bluetooth, Wi-Fi, and cellular, each with distinct technical requirements.
Data flows varied by subsystem. Clinician systems supported bidirectional communication, enabling implant data uploads and downloads of parameter changes and firmware updates. Patient systems primarily supported data uploads for home monitoring, along with basic therapy start/stop controls, and the architecture was designed to accommodate future remote device adjustments.
The engineering challenge was to support these functions and communication requirements while maintaining a consistent architecture that could evolve over time.
To achieve this, the engineering approach focused on common architectural patterns, standardized data interfaces, and well-defined communication protocols. A microservice architecture helped minimize dependencies between components, while separating medical and non-medical functionality helped manage regulatory scope and change control.
Cybersecurity was addressed across the entire ecosystem, with common requirements for encryption, access management, certificates, and secure communication between endpoints. Formal verification was also carried out at both product and system levels, with requirements mapped to the appropriate testing activities.
This approach supported the ecosystem's evolution from an initial minimum viable product through multiple releases each year, while helping maintain consistent development schedules and supporting successful regulatory submissions.
Engineering a connected life-critical device means engineering for changes beyond the device itself. Reliability depends not only on how individual components perform, but on how the wider ecosystem behaves as interfaces, platforms, dependencies, and threats evolve over time. Designing for those realities from the outset helps ensure the system remains safe, supportable, and dependable throughout its operational life.
This article is part of our Engineering Life-Critical Devices series, where we explore the engineering challenges behind some of the most demanding medical technologies. Visit our series hub to read the other articles and discover how we approach the development of safe, reliable, and compliant medical devices.