Balancing Functionality Between Medical Devices and Digital Health Systems

This extract is from our recent whitepaper: From Medical Devices to Digital Health Ecosystems: Navigating the Complexities of Product Development. Featuring insights from Inspire, Natus, and S3 Connected Health, it delves into the transition that occurs when medtech companies advance along the value chain, evolving from creating standalone connected devices to providing integrated digital health solutions. It examines how this shift impacts physical device design, software architecture, and system integration, while also addressing the technical, operational, and regulatory considerations that arise throughout the process.  

One of the most critical (and complex) decisions is determining which functionality should reside on the device itself and which should live in the broader system, such as a mobile app, backend service, or cloud platform.

Distributing functionality between a medical device and its surrounding digital health system involves balancing safety, usability, performance, and compliance. Architects must consider user needs, the context in which the solution is used, data integrity, connectivity limitations, and regulatory constraints. The goal is to optimize the entire system without overwhelming the device or compromising safety, usability, or maintainability.

Questions below will help digital solution architects make the right design decisions:

• Which safety-critical functions must reside on the device to ensure safe and effective operation? When immediate actions are required, such as detecting a patient condition and triggering a response, they must reside on the device. When the response window is longer, cloud processing can add value through deeper insights, extended monitoring, and flexibility without risking timeliness or patient safety.

• Which functions fall under medical device regulations, and which fall under healthcare IT or other frameworks? Understanding these regulatory boundaries early determines not only where functions should live but also the development, validation, and change-management processes they must follow.

• How should functionality be distributed to optimize usability and user experience across the device, app, and other system components? Some interactions benefit from larger screens and richer interfaces, while urgent or time-critical feedback may need to be delivered directly on the device to avoid delays or confusion. Should the information pass directly to the patient or be interpreted by a clinician?

• What data needs to be stored locally on the device versus transmitted to connected systems? Decisions here must account for safety, offline access, compliance, and performance, while ensuring data integrity, ownership, auditability, and privacy across the ecosystem.

• How will performance, power consumption, and connectivity constraints shape the division of functionality? Limited processing power, battery life, latency, and bandwidth can all affect which operations stay on-device and which are delegated to mobile, cloud, or backend systems.

“Both the device and its digital components influence each other, requiring a co-development approach. For example, for a device with no built-in user interface, due to size or design constraints, certain functions must, by default, be handled by external digital components. On the other hand, if the device does have a user interface and can operate independently, it should still be designed to function in both standalone and connected scenarios. This is especially true for devices used in hospital environments, where many vendors design devices to function autonomously, ensuring reliability regardless of connectivity. In the same time, connected devices allow for the design of more efficient clinical workflows.”

Szymon Zysko, VP, R&D, S3 Connected Health

It is essential that the decisions stem from careful planning and long-term thinking, allocating functionality where it makes the most sense today, while also providing enough architectural foresight to adapt as technology and use cases evolve. That’s critical, because shifting functionality from one part of the system to another, for example, from the device to the cloud or vice versa, can be extremely costly and complex, especially after a product is already in the field.

If you haven’t already, you can access the full whitepaper for the complete insights here

Hear from industry leaders at Inspire, Natus, and S3 Connected Health as they provide practical guidance across the entire product lifecycle — from concept and design to development and ongoing management — to help teams build devices that thrive in today’s connected healthcare environment.