Digital Ecosystems in MedTech: ROI, Real-World Evidence, and Growth

Beyond the Device: Where Digital Ecosystems Are Creating Real Value in MedTech

Randy Horton

Published on: April 30th, 2026

Executive Summary

The next layer of MedTech product value will come from what happens around the device, not only from the device itself.

The webinar focused on how value is created when connected devices, software, cloud services, mobile apps, SaMD capabilities, patient data, clinical workflows, and external partners work together as an integrated ecosystem.

Tidepool’s origin story clearly shows the problem. In diabetes care 15 years ago, a patient could have a reliable insulin pump and CGM, yet clinicians still had to print reports from separate manufacturers and compare the printed pages, held up to the light, to match glucose readings and insulin administration patterns. The devices worked. The data existed. The workflow to connect them did not.

Tidepool has since grown into a non-profit medical device manufacturer with two related product lines. Its data platform pulls data from more than 100 diabetes devices, has supported more than 950,000 patients, and is used by around 1,300 active health systems each month. That platform helps clinicians and patients monitor diabetes across devices without asking care teams to manage multiple manufacturer portals. Tidepool Loop extends that ecosystem into therapy as an interoperable automated insulin-dosing technology.

Of course, the device still matters. But the ecosystem increasingly determines how much value that device can create.

Moving Beyond the Standalone Device

A digital ecosystem is everything around a medical device that helps it create value beyond the standalone product: the software, data, workflows, and services connected to it.

That ecosystem might include a connected app, a cloud service, a SaMD capability, or a data integration. Its value grows as those pieces begin to work together across care settings, data systems, and clinical workflows.

Digital ecosystems create value in more than one way. They can make device data easier to use, reduce workflow friction for clinicians, support more proactive care, and give patients a less burdensome way to manage their health. They can also make the product harder to replace over time.

A standalone device can always be compared with the next device that does the same job a little better. An ecosystem gives the product more ways to remain useful over time.

That does not mean every MedTech company should build an ecosystem just to say it has one. Ecosystems are hard to build well. They require teams to work differently than they do in traditional device development. They also force companies to think differently about partnerships, data access, system boundaries, and long-term product value.

Why Diabetes Became an Early Case Study

Diabetes offers one of the clearest examples of ecosystem value in MedTech because care does not occur in a single place or at a single point in time.

Type 1 diabetes is chronic, daily, and heavily self-managed. At its core, it is also a data problem: patients are constantly trying to understand and manage glucose levels, insulin dosing, food, exercise, and other factors that affect their health. Once smartphones, connected insulin pumps, and CGMs became part of daily life, it made sense to connect these systems to support better day-to-day management.

The same pattern is starting to show up elsewhere in MedTech. Ecosystem value becomes easier to see when users need to make frequent decisions, when data comes from multiple sources, and when care extends beyond traditional clinical settings into everyday life.

The Problem Tidepool Was Built to Solve

Tidepool’s founding story shows what interoperability problems look like in day-to-day care.

The original problem came from a real diabetes care experience in 2013. A patient had two reliable technologies: an insulin pump and a CGM. But those systems did not work together to support clinical decision-making. Clinicians had to print separate reports from each manufacturer and manually compare them to understand the relationship between glucose readings and insulin dosing patterns.

That workflow gap helped shape Tidepool’s original purpose. The organization began as an aggregator platform to bring together diabetes data. Its data platform has since evolved from collecting data in one place to integrating it into clinical workflows, including the EHR, where care teams can use it more easily.

Patients and caregivers also pushed the industry forward. The “We Are Not Waiting” movement grew from frustration with the slow pace of device integration. People used open-source technology to build automated insulin dosing systems and data ecosystems themselves.

Tidepool’s story shows why connectivity alone is not the endpoint. The value comes when data moves into the workflows that clinicians and patients already rely on.

Interoperability Is About Reducing Burden

Interoperability often gets discussed as a technical issue. At the point of care, it means getting data to the people and the system that need it, without adding work for patients or clinicians.

Moving data is not enough. The data has to become useful where decisions are made.

“Trying to make it easier at the end of the day to reduce the burden on the patient or provider and get data where it needs to be.”
— Kelly Watson

For MedTech teams, that means asking practical questions:

Can one device safely share data with another device?
Can clinicians see the information without opening another portal?
Can patients decide where their data goes?
Can caregivers and care teams access the information they need?
Can data flow into the EHR, population health workflows, or research environments when appropriate?

The webinar drew a distinction between EHR interoperability and medical device interoperability. EHR data has benefited from policy movement around patient-directed access. Device interoperability has not had the same kind of government mandate. That leaves medical device teams with a harder job: they have to design data access, patient choice, and system-to-system communication more deliberately.

Safe Ecosystems Require Clear Boundaries

As devices become more connected, interoperability becomes a risk management problem.

When multiple systems depend on each other, MedTech manufacturers need to understand how those dependencies could affect patient safety. If an insulin pump uses CGM data, a failure in one part of the system can affect another. Engineering, quality, and regulatory teams need to know how one system communicates residual risk, how another system mitigates that risk, and how failures become visible before they compromise patient safety.

Those teams need clear interfaces, transparent residual risks, and defined verification responsibilities across each boundary.

The same logic applies beyond device-to-device interoperability. It also applies to cloud services, mobile operating systems, and BYOD hardware. Once a product depends on another system, that dependency becomes part of the ecosystem design and risk model.

Engagement between the medical device manufacturer and the FDA is most useful before those interface decisions are locked in. The webinar emphasized the value of bringing the FDA in early, when teams are still defining how systems connect, which standards they will use, and which party is responsible for verifying safety at each interface.

Modularity Helps Ecosystems Keep Moving

Connected systems need technical architectures that can handle change.

Modern software systems outside medical devices often solve this by separating the system into smaller parts that can be updated, tested, and recovered independently. If one part fails, the rest of the system should not automatically fail with it.

The same idea applies to connected medical devices. When the app, cloud service, device interface, data pipeline, and clinical workflow are too tightly connected, each new feature becomes harder to release. A small change in one area can require extra review, extra testing, and extra coordination across several parts of the system. Modularity helps contain that work. It gives MedTech teams a way to change one part of the ecosystem without treating every update as a change to the entire product, since the change’s potential impact is limited to specific modules.

“The more they build, the slower they are about building and about getting the next feature out, and the more effort it takes.”
— Bernhard Kappe

The Commercial Reality: Stickiness, Data, and Workflow

Ecosystem strategy affects the business model, not just the technical architecture.

The medical device still has to do its job well. A CGM still needs to capture glucose data. An insulin pump still needs to deliver insulin. A surgical robot still needs to support the procedure. But more of the product’s value now comes from what happens around that device: how easily data moves into the EHR, how well the device fits into clinical workflows, how patients and caregivers access information, and how the data can support monitoring, research, or future product improvements.

The webinar used a familiar consumer technology example: switching from one smartphone ecosystem to another is rarely just a hardware decision. People stay because their data, apps, services, photos, music, and habits already live inside the system. In MedTech, the same kind of stickiness can appear when a product becomes embedded in the way clinicians, surgeons, endocrinologists, patients, parents, or caregivers manage care.

The discussion also connected ecosystem value to surgical workflows. In surgical robotics and surgical planning, the value is not limited to the robot itself. It can also come from the planning tools, data flows, and workflow connections around the procedure. Without that broader ecosystem around the device, companies may find it harder to retain customers or win new ones.

This is more specific than a general push to “go digital.” If a device generates useful data, moves that data into workflows where people already make decisions, and keeps users engaged over time, it can create value long after the initial device sale.

The hard part is not only creating that value. It is also finding a business model that lets the company capture some of it.

Turning Device Data Into Proactive Care

CGM data showed that a connected medical device can support a different care model when integrated into the right workflow.

Raw CGM data has clinical value on its own. But when insights flow into an EHR or population health workflow, clinicians can identify patients at risk across hundreds or thousands of patients. Instead of waiting for the next appointment, care teams can spot deteriorating glucose patterns and intervene at the population scale.

So, the device captures data, and the ecosystem helps care teams see and act on better insights from the device and the rest of the patient’s clinical data.

Reducing Patient Burden Is a Design Constraint

The webinar also looked beyond business value and clinician workflow to the patient’s experience outside the clinic. A strong ecosystem should reduce the cognitive burden on patients, not add to it.

“Are we reducing the cognitive burden for the patient?”
— Kelly Watson

Product, UX, clinical, engineering, and data teams should ask basic questions early: Does the ecosystem make the patient’s job easier?. That means asking whether patients can share data with their care teams more easily. It also means asking whether the ecosystem helps patients and clinicians see useful patterns and trends, such as changes in symptoms, therapy response, activity, or glucose trends, depending on the condition. Connected devices and SaMD products can also become more useful when they combine device data with other data sources, such as wearable data or patient-reported information. Those combinations can support better algorithm development, clearer care decisions, or future product improvements.

Adding more apps, portals, devices, or data sources does not automatically improve an ecosystem. If patients have to manage more accounts, portals, and uploads, or explain the same device data to different providers, the ecosystem is adding work rather than reducing it.

Case Study: Combining Diabetes Device Data With Wearable Data

The webinar also highlighted Tidepool’s collaboration with Oura and Dexcom.

The initiative integrates diabetes device data with physiologic data from Oura, including sleep, exercise, and women’s health tracking. The goal is to build a large, comprehensive diabetes dataset with a focus on women’s health.

People with diabetes can choose to participate through an IRB protocol and donate their personal device data to researchers. That gives researchers a way to study patterns across diabetes device data and biometric data that no single company could access on its own.

Despite decades of advancement in CGM, insulin pumps, and automated insulin dosing technology, researchers still lack enough data to explain why women with diabetes face higher risks for cardiovascular and stroke events, or what should be done about it.

The same data-sharing model could apply beyond diabetes. Combining data sources can help researchers look for signals for early detection, risk stratification, condition management, and correlations among behavior, physiology, and outcomes. Companies may not know in advance what they will find when they combine these data sources. But larger datasets give researchers a better chance of finding patterns that can improve care, algorithm development, or product design.

Key Takeaways

Design for interoperability from the outset

MedTech companies that design for interoperability early can make device data more useful across clinical workflows, partner systems, EHRs, and research programs. If those needs are handled late, teams may have to rework interfaces, data flows, consent models, or risk controls after the product architecture is already set.

Use standards to define interfaces

Standards give manufacturers a clearer way to define how systems exchange data and depend on each other. Clear interfaces also help engineering, quality, and regulatory teams identify who owns each risk and what verification and validation work each boundary requires.

Treat architecture as part of risk management

Modularity, subsystem independence, and clear boundaries help prevent a single change or failure from spreading across the entire system. Without that structure, every new feature can require broader testing, more reviews, and more coordination across functions.

Move data into the workflows where decisions happen

Device data becomes more valuable when it moves into the EHR, population health tools, research programs, or other workflows where clinicians, patients, and researchers can act on it.

Give users a reason to keep engaging

Engagement does not happen just because a company builds an ecosystem. Users keep engaging when the ecosystem saves time, reduces burden, or gives them information they can use. That engagement creates the data loop that can improve monitoring, algorithms, research, or future product decisions.

Keep patient burden visible

An ecosystem is not better simply because it connects more devices, apps, portals, or data sources. It is better when those connections reduce work for patients, caregivers, clinicians, and care teams.

How Orthogonal Can Help

Build connected ecosystems with clear boundaries

Orthogonal helps MedTech teams build SaMD and connected device ecosystems across mobile, cloud, web, Bluetooth, and AI/ML, with attention to safety, regulatory compliance, engagement, and effectiveness.

Apply fast feedback loops inside regulated development

Orthogonal applies fast feedback loops and best practices to quality processes for SaMD and connected device ecosystems, helping companies launch and evolve those systems more effectively.

Combine modern software practices with regulatory and quality thinking

Orthogonal combines modern software development practices with the right approach to regulatory and quality. The webinar noted that when teams combine those well, they can become two to three times as efficient.

Support build, co-build, and internal enablement models

Orthogonal builds products, co-builds with internal teams, and helps organizations develop their own SaMD and ecosystem capabilities over time.

Help teams reason through interoperability, risk, and verification

As systems connect to devices, cloud services, mobile operating systems, and other dependencies, teams need to define interfaces, residual risks, failure transparency, and verification responsibilities. That is where ecosystem strategy becomes practical engineering and quality work.

Watch Webinar Recording

Randy Horton, VP of Solutions and Partnerships, Orthogonal