In connected device development and validation, our focus shifts to the solution and how to bring it to life, starting with creation and system architecture.
By Bill Betten, S3 Connected Health
This is the third installment in my series offering a deep dive into data strategy for connected medical devices. The first two articles explored the importance of understanding data strategy and establishing a strong foundation for a successful product. By now, you should have a solid grasp of why data is critical and how you intend to use it.
As we move into the development and validation phase, our focus shifts from why the product exists to what the solution will be and how to bring it to life. This stage encompasses solution creation, system architecture, validation, and regulatory compliance. That’s a lot to tackle so for the purposes of this article, we’ll concentrate on the first two: solution creation and system architecture.
While digital strategy influences what gets built, the process is highly iterative, often requiring close alignment between strategic vision and technical feasibility. There is frequently a gap between what business leaders envision and what engineers and data scientists can realistically develop. The business, marketing, and technical teams must communicate, articulating tradeoffs and defining priorities. ensuring the device is fully integrated into the broader data strategy. A strong data strategy ensures the solution is capable of collecting, managing, and processing data efficiently, while generating meaningful insights that drive value.
Meet Bill: Betten is set to speak at our DeviceTalks West show in Santa Clara, California Oct. 15-16. Register now to save your seat.
Solution creation: Considerations for designing the data ecosystem
In earlier articles, we covered how your device will generate data and where that data is supposed to go. Now it’s time to get into the how. Once data is collected by the device, how does it get to its destination?
Historically, someone — typically a service technician — had to pull data directly from a machine, maybe using a USB stick. Then came networked connections. Today, there are many options, but one of the most important considerations is connectivity: how you plan to connect the device to the ecosystem that needs the data.
What happens when there’s no connectivity?
One of the most overlooked questions is what happens when connectivity fails? We often assume that connectivity will always be there, but in reality it isn’t guaranteed. For example, some connected medical devices rely on smartphones, but hospitals don’t always want numerous devices competing for bandwidth. In some cases, a private network may be needed as the hospital may not want all devices on their backbone network
So how long can your device collect and store data if it loses connectivity? Can it buffer for minutes? Hours? Days? And when connectivity is restored, can it reliably push that data through (a “store and forward” model)?
This gets even more complex in time-critical situations. You can’t always afford delays. I once worked on a system used with heart-lung machines that keep blood flowing during surgery. It had multiple layers of failover, powered by the hospital’s mains, backed up by generators, batteries, and, if all else failed, a manual hand crank. The data pipeline might not need that level of redundancy, but the same thinking applies. If connectivity fails, what’s your plan?
Even if the final approach isn’t clear, it’s smart to design with connectivity in mind early on. It can be far more cost-effective to build in capability up front, even if you don’t use it right away.
Connectivity options
There are two main types of connections: wired and wireless.
Wireless options include Wi-Fi, Bluetooth, MICS (for implanted devices), proprietary connection schemes, and even standard consumer technologies like cellular.
Wired connections could involve Ethernet or direct links to hospital networks.
The key thing to remember is that there is no one-size-fits-all. No method is inherently better as it depends on your specific use case.
Mobile, hub, or custom?
Another key decision related to connectivity is how the user interacts with the device and how the data is collected and transmitted. There are several methods for doing this:
- Mobile-based: This leverages the user’s phone to collect and transmit data. This is tempting because phones are everywhere, but comes with risks. You don’t control the hardware, OS updates, battery life, or connectivity. Will the device work with all phones? Will users have the right app running?
- Hub-based: A dedicated communication device that’s small, quiet, purpose-built to receive data (e.g. from a pacemaker), and often running passively in the background offers more control, more stability, fewer surprises.
- Custom solution: A fully integrated system with built-in communications capabilities is less common, especially in implantables, because it often requires more power and battery life than the device can support, but it provides the ultimate in management of the options
The user interface is a critical element of your overall data strategy. It determines not just how data is collected and sent, but where. Back to the user? A physician? A third-party monitoring system?
There’s a big difference between sending data from a pregnancy or COVID test and transmitting critical, potentially life-threatening information like cancer indicators. Some form of intermediary or validation layer (for instance, a healthcare provider who is trained to understand medical information) is often required to ensure sensitive or complex data is interpreted and acted upon appropriately.
Storing the data
You can store data locally (on the device or within the hospital) or send it to the cloud. Local storage is often more secure and may be necessary if the data needs to be processed urgently. Cloud storage, on the other hand, offers flexibility, scalability, and easier access for multiple users, but may introduce delays or face regulatory hurdles.
Cloud processing might work for diagnostics. But it may not work for emergencies. You must ask: How real-time does this data need to be?
Cloud-based storage is increasingly viable as infrastructure improves, and many companies no longer need to manage massive servers in-house. Still, there are regulatory constraints. Some governments require that health data remain within national borders, so cloud usage must be compliant.
It’s also worth considering what you want to do with the data later. If you plan to use it to refine algorithms, support artificial intelligence/machine learning models, or enhance device performance, easier access through the cloud might make more sense.
Architecture: Building a scalable and secure data infrastructure
Designing the right data architecture is about setting your device up for long-term success. Below are areas to focus on as you build out your data infrastructure.
Platform versus custom design
One of the first big decisions in designing your architecture is whether to build on an existing platform or develop a custom solution. This applies not just to how you collect and send information, but to the entire system stack.
Using an off-the-shelf platform means you get built-in support, infrastructure, and scalability, often at a lower upfront cost. It can also speed up your time to market. Long-term, it typically offers better support, since costs and improvements are shared across a broader ecosystem of products. However, intellectual property ownership and long-term partnership implications should be considered so choose the platform wisely.
On the flip side, a custom system gives you full control, but requires more time, resources, and maintenance.
Your decision is an interactive tradeoff among scalability, cost, and flexibility. For example, a smaller, focused patient base might make a custom approach viable. But if you’re aiming to roll out across multiple hospitals or regions, a platform-based architecture could offer the scalability and support you need.
Whatever the path, your infrastructure and architecture should align with the scope and requirements defined back in stage one of your business case.
Edge processing versus cloud computing
Another key consideration: where should the data be processed?
- Edge computing means processing happens on the device itself, ideal for time-sensitive tasks or situations where connectivity might be limited.
- Cloud computing centralizes processing, which can be great for more complex analytics, broader access, and easier updates, but it may introduce latency or dependency on reliable connectivity.
The right choice depends on how fast decisions need to be made, how critical the data is, and how consistent your connectivity is expected to be.
Looking ahead to Part 4
During the development and validation phase, the generation, transmission, storage, and use of data drive the process of turning a concept into a functional product. This is what traditional medical device companies know how to do well.
However, a well-defined data strategy ensures the device is secure, scalable, compliant, and meets the users’ needs. It also ensures that a “beyond the device” business model is an element of the development. In Part 4 of this series, we’ll dive into how regulatory compliance shapes data strategy, impacting everything from data privacy to interoperability standards.
Bill Betten [Photo courtesy of S3 Connected Health]
Read more MDO Contributions and learn how to submit your own
The opinions expressed in this blog post are the author’s only and do not necessarily reflect those of Medical Design & Outsourcing or its employees.
