Anyone involved with connected medical devices knows that success has an interesting side effect: data. Lots of it.
A single device might generate a manageable amount of patient data, telemetry, logs, images, or video. Deploy thousands, or hundreds of thousands, of those devices and the economics change quickly. And collecting the data is only the beginning. Clinical organizations need the data for patient care. Medical device companies want to analyze it and use it to improve their products. Everyone is exploring appropriate uses of device data for analytics, AI, product development, and clinical workflows. In our multi-cloud world this also means moving it: from a hospital datacenter to another, to a cloud, between clouds or all of the above.
This is where an unintended consequence of the public cloud model starts to appear. The data generated by medical devices is there, but moving large quantities of it into, out of, and within some clouds can cost money.
Think of it as an innovation tax.
The more successful your connected-device strategy becomes, and the more innovative uses you find for the data, the more that tax can influence where and how you use it.
What if we approached the problem differently?
Start with the devices
Medical device data presents some interesting challenges. The industry has everything from infusion pumps and patient monitors to imaging systems, wearables, laboratory instruments, and specialized clinical equipment. Different manufacturers use different protocols and data formats, and many devices were designed long before anyone imagined their data feeding cloud-scale analytics and AI.
In healthcare, making data useful also means governing it appropriately. Device data can be subject to privacy, security, regulatory, contractual, residency, and organizational requirements depending on the data, use case, and jurisdiction. Any architecture for connected medical devices therefore needs to consider not only how data is collected and moved, but also how access, use, protection, and governance requirements are applied.
The Oracle Connected Devices strategy is to facilitate the connection and aggregation of device data to enable downstream consumption by other systems to drive novel workflows. It is designed to address this problem across the stack, spanning the device layer, data foundation, clinical and application services, intelligence, and the broader healthcare ecosystem.
At the center of the data architecture is OCI Internet of Things (IoT) Platform.
The OCI IoT Platform is a developer service designed to ingest real-time IoT data and integrate it into business processes and applications. It supports common IoT protocols and uses digital twins and adapters to normalize device data. The normalized data can then be stored in Oracle Autonomous AI Database and made available to applications, analytics, and AI.
This architecture has an important implication for medtech.
Instead of making every device or every application consuming its data solve the integration problem independently, manufacturers can establish a common data foundation. Once the data is normalized and accessible, it becomes much easier to find new uses for it.
And that’s when another problem begins.
Data gravity meets cloud economics
As connected-device fleets grow, data develops gravity.
Engineering teams may want device telemetry for product development. Quality teams may need it for post-market analysis. Data scientists want it for AI model development. Healthcare customers may need subsets of the data integrated into clinical systems. Business partners may want to build applications around it.
The Connected Devices architecture recognizes this broader opportunity, extending from IoT and device management through database and AI, FHIR and connectivity services, imaging and video, edge capabilities, and application development.
But those applications won’t necessarily all live in the same cloud.
This is where cloud economics can start driving architecture instead of architecture driving innovation.
Cloud providers have traditionally made it inexpensive to put data into their clouds while charging customers to move it out. For small amounts of data, that may not matter much. For a medical device manufacturer continuously collecting data from a global device fleet, it can matter a lot.
OCI approaches data movement differently.
OCI includes 10 TB per month of outbound data transfer over the public internet at no additional charge, with comparatively low pricing beyond that allowance. Private connectivity using OCI FastConnect uses port-based pricing rather than charging OCI customers for every gigabyte transferred over private peering.
The practical result is that a medical device company can spend less time asking, “What will it cost to move this data?” and more time asking, “What else can we do with it?”
What if OCI became the data hub?
There is another assumption worth questioning: Why does choosing a cloud for your medical device data mean choosing that cloud for everything?
Healthcare is already heterogeneous. Medical device companies are heterogeneous. Their customers certainly are.
One healthcare organization might run applications in one cloud. Another might have a significant footprint in a different cloud. Yet another may have critical systems on-premises. Most large organizations will probably have some combination of all of them.
Trying to eliminate that complexity isn’t particularly realistic but connecting it might be.
OCI supports multicloud architectures through private connectivity options that can connect OCI with environments in AWS, Microsoft Azure, and Google Cloud, with available services and connectivity models varying by provider and region. That creates an interesting architecture for connected medtech. Bring device data into OCI. Normalize it once. Establish OCI as the data foundation. Then make that data available to applications and services wherever they make sense.
Your AI team wants to train models in OCI? Great.
A customer needs authorized data available to workloads in another cloud? OCI connectivity options can support that architecture.
An application needs to combine device data with enterprise or clinical data? Connect them.
The goal shouldn’t be to create another cloud data silo. It should be to make medical device data easier to use.
In fact, the Connected Devices architecture describes OCI as a bridge connecting medtech AI and data with enterprise, life sciences, clinical, revenue-cycle, payer, and partner systems across public cloud, dedicated cloud, multicloud, and hybrid environments.
That’s a very different way to think about cloud architecture.
Networking matters when everything becomes data
Of course, making OCI a data hub only works if the underlying network can keep up.
Oracle Acceleron represents an evolution in OCI networking architecture. Acceleron’s multiplanar networking architecture uses multiple physically and logically independent network fabrics. Each plane has independent data and control planes, avoiding the “fate sharing” that can occur when network components depend on the same underlying infrastructure. The architecture is designed to provide massive bandwidth, predictable latency, and resilience for extremely demanding workloads.
Oracle Acceleron’s SmartNIC extends that architecture to OCI Compute by combining host networking and cloud control functions in a security-first architecture. Oracle reports up to 2X networking improvements for some workloads while maintaining the strong isolation model that has been part of OCI’s architecture from the beginning.
Oracle developed these capabilities in large part to meet the extraordinary networking requirements of AI and other data-intensive workloads. But think about what those same characteristics mean for healthcare: high throughput, predictable performance, strong isolation, efficient data movement, and infrastructure designed for resiliency.
Those seem like pretty useful characteristics for a cloud hosting data from large fleets of connected medical devices.
Especially when that data increasingly feeds AI.
Removing the innovation tax
Medtech companies already have plenty of hard problems to solve.
They operate in an environment shaped by regulatory requirements, cybersecurity threats, legacy infrastructure, siloed data, and constant pressure to accelerate R&D.
Paying to move the data generated by their connected-device ecosystems shouldn’t make innovation harder.
The OCI IoT Platform provides a foundation for ingesting and normalizing device data. Autonomous AI Database can make that data immediately useful to applications, analytics, and AI. OCI’s data-transfer economics can reduce the penalty associated with moving large data sets. Cloud interconnects can make that data available across heterogeneous environments. And Oracle Acceleron provides a new networking architecture designed for the performance, isolation, and resilience required by increasingly data-intensive workloads.
Put those pieces together and OCI can play a particularly interesting role in connected medtech.
Not simply as the cloud where device data lands, but as the data hub where medical device data becomes useful.
In our age of connected devices, cloud computing, and AI, why put an economic barrier between innovators and the data their own products generate?
Medical device companies have better things to spend that money on.
Like the next medical device.
To learn more, visit How IoT and AI are Driving the Future of Healthcare Delivery.
Oracle does not endorse any specific product or solution built using Oracle Cloud Infrastructure services described on this page. OCI services are general-purpose platforms and are not intended to provide diagnostic or treatment recommendations. Customers are responsible for validating their products and solutions and ensuring compliance with any applicable regulatory requirements.