MedTech Ecosystem Design Controls: Move Faster with Right Level Compliance

MedTech Ecosystem Design Controls: Move Faster With the Right Level of Compliance

Randy Horton

Published on: July 14th, 2026

Executive Summary

In a recent Orthogonal webinar, panelists from Eli Lilly and Orthogonal discussed how MedTech companies can apply design controls across connected digital ecosystems without treating every component as though it carries the same patient risk.

Connected medical products increasingly extend beyond a standalone device. An ecosystem may include a physical medical device, software within the device, Software as a Medical Device, mobile and web applications, cloud infrastructure, connected IT systems, third-party interfaces, and AI-enabled functions. These parts work together, but they may have different regulatory classifications, software safety classifications, risks, and requirements.

Treating the entire ecosystem as one monolithic medical device can slow development and release cadence, limit scalability, and increase maintenance costs. A change in one area may also trigger documentation, testing, review, and regulatory work across a much broader portion of the product.

Ecosystem design controls help teams define the complete system, identify the function and classification of each part, map the boundaries and dependencies between them, and apply the appropriate level of rigor. This approach allows lower-risk and higher-risk functions to follow different development paths while still managing the interoperability, cybersecurity, and dependency risks that cross system boundaries.

Why Ecosystem Design Controls Are Needed

The Product Is Becoming an Ecosystem

Connected medical device ecosystems are not new. The diabetes space has combined devices and software systems for years. Still, the same model is becoming more common across the broader MedTech industry as products rely more heavily on software, AI, cloud infrastructure, and surrounding digital services.

In surgical environments, for example, surgical robots and surgical-planning tools that were once less connected are increasingly becoming part of integrated systems. Purchasers of medical devices increasingly evaluate not only the physical device, but also the software and services around it.

Some components of these ecosystems are medical devices. Others contribute to the overall product but are not themselves medical devices.

Teams must therefore decide how the components should work together, where meaningful boundaries should be drawn, and what regulatory pathway and level of design-control rigor should apply to each one.

Why One-Size-Fits-All Controls Fail

Applying the highest level of design-control rigor to every part of a product may appear to be the most conservative approach.

That model becomes difficult to sustain when a product includes multiple connected functions that carry different levels of patient risk and need to change at different rates.

Treating the entire ecosystem as one monolithic device means the whole product may move at the pace of its highest-risk component. A small change to a lower-risk function can trigger work across a much larger portion of the system, slowing releases and increasing long-term maintenance costs.

The same issue appears when organizations equate rigor with the amount of documentation they produce.

Documentation is an essential part of the engineering process. It records what the team is doing, why decisions were made, and how the product is being controlled. More documentation, however, does not automatically produce a safer or higher-quality product.

“More documentation does not mean better quality. Better quality means better quality.”
— Megan Graham, Orthogonal

The webinar described one manufacturer whose classification process placed nearly every software component into safety Class C. This created a restrictive framework that the organization needed to change before it could move forward with its broader ecosystem work.

If a process is intended to distinguish among several possible classifications but consistently produces only the highest result, it may not be evaluating risk effectively. Classification should help determine the appropriate level of rigor rather than automatically selecting the most burdensome pathway.

The goal is not to minimize controls or documentation. It is to ensure that the required documentation, testing, review, and approval reflect the function and risk of the work being performed.

To do that effectively, teams must first understand the complete ecosystem and how its components operate together.

Define the System and Its Boundaries

Start by Defining the System

Before classifying individual components or drawing regulatory boundaries, teams need to define the ecosystem and the problem it is intended to solve. The ecosystem may extend beyond a single medical device. It can include device and non-device functions, software applications, cloud services, connected IT systems, external dependencies, and the interfaces through which they work together.

That requires clear answers to several questions:

What is the system intended to do? Define its purpose, users, and overall goal.
What are the parts of the system? Identify the devices, software, applications, services, and external components that work together.
What function does each part perform? Clarify the technical purpose and role of each component.
How do the parts work together? Map the connections, interfaces, and dependencies between them.
How do data and functionality flow? Identify where information and functions cross proposed technical or regulatory boundaries.
What happens when something fails? Understand the failure modes and risks created by those connections.

The webinar emphasized the need for system-level thinking and intentional decisions about how the components, interfaces, and boundaries are defined.

Those boundaries must reflect how the product actually operates. A diagram may separate device and non-device functions, but that distinction may not hold if regulated data or functionality passes through components placed outside the proposed device boundary.

Let the Implementation Determine the Risk

The name given to a component does not provide enough information to determine its risk or the controls it requires.

The webinar illustrated this point with three mobile-application examples.

The first example is an application that connects to a device through Bluetooth and displays information. Its dependencies on the operating system may be relatively limited and straightforward to test and manage.

The second example runs an AI algorithm within the application. Its performance may depend on floating-point calculations and differences among smartphone GPUs.

The third example uses images from a smartphone camera to perform a diagnostic function. Its performance may depend on the camera, lighting, and how the operating system processes raw images.

All three are mobile applications, but their dependencies and risks are different.

As a medical function becomes more dependent on external hardware and software, the manufacturer needs to explain how those dependencies are being managed and tested. Evidence may include standalone studies, bench studies, or evaluation as part of a clinical trial.

The appropriate regulatory position and level of rigor should therefore reflect what the application actually does, what it depends on, and how those dependencies could affect the device.

Classify Components and Draw Defensible Boundaries

Many organizations begin with a binary question: Is this component a medical device?

But that is only the first part of a longer analysis. For each component, teams should consider:

Intended use: What the component is intended to do.
Technical purpose: The function it performs within the ecosystem.
Role in the system: How it contributes to the product’s overall purpose.
Risk profile: The risks associated with the component and its connections.
Regulatory classification: Whether it is Class I, Class II, Class III, or not a medical device.
Software safety classification: The software safety class assigned under IEC 62304 and the corresponding level of rigor.
Dependencies: The hardware, software, services, and systems it relies on or supports.

Regulatory classification and risk profile are related, but they are not the same question. Regulatory classification determines how a component is regulated based on factors such as its intended use. Its risk profile considers the function it performs within the ecosystem, what could happen if it fails, and how its interfaces and dependencies could affect the wider system.

A component may sit outside the medical device boundary but still create risks that need to be managed. Teams need to consider both when determining what controls are required for a component to perform its intended function effectively over time.

The webinar described a process in which each component within an ecosystem receives a clear, written regulatory classification. That decision is documented through a defined regulatory process based on factors such as intended use.
This gives engineering, quality, product, and regulatory teams a common decision to work from instead of relying on informal conversations or repeated debates. It also creates a clear audit trail.

Classification should also be revisited when a component changes. If its features, capabilities, or intended use expand, the organization must determine whether a different classification or higher level of design-control rigor now applies.

Align the Technical and Regulatory Architecture

Technical architecture and regulatory architecture are two views of the same system:

Technical or solution architecture explains how the product will meet user needs and perform its intended function. It addresses how the system is structured, how its components work together, and how the product operates.
Regulatory architecture examines the same system through a different lens. It identifies the classification of each function, the boundaries between device and non-device functions, and what the organization must demonstrate to show that the product is safe and effective.

These perspectives should both be developed together because the way a system boundary is drawn has direct consequences. Functions grouped within the same boundary may need to follow the highest classification contained within that system.

Teams must also consider how the architecture affects future changes. An administrative update may have a different regulatory and risk impact from adding an indication or changing a regulated function.

The architecture and the organization’s processes should make it possible to distinguish among those changes and apply the appropriate type and level of rigor.

Use Existing Regulatory and Engineering Concepts Together

The webinar highlighted three existing MedTech concepts that help teams structure and control a connected ecosystem: multiple-function device guidance, interoperability guidance, and software segregation.
Each addresses a different part of the same problem.

1. Multiple-Function Device Guidance

The multiple-function approach helps teams distinguish device functions from non-device functions within a broader product or ecosystem.

It supports defining the regulatory boundary and organizing functions into modules that align with the technical architecture. Drawing a function outside the medical-device boundary, however, does not remove the need to understand its effect on the regulated function.

Dependencies and risks that cross the boundary still need to be identified and managed.

2. Interoperability Guidance

Interoperability guidance helps teams evaluate what happens when two systems exchange data or depend on one another.
When a medical device connects to another software system, teams need to define what information is exchanged, which standard the interface follows, and what risks are created by the connection.
They must also determine how those risks will be assessed and who is responsible for showing that the connected systems work together properly.
These concepts can also be applied when the connected system is not itself a medical device. The connected subsystem should communicate its known failure modes and residual risks so that the receiving system can detect and mitigate them.

3. Software Segregation

Software segregation provides techniques for separating functions based on risk and limiting the effects of a failure in one part of the system.

It allows teams to structure components so that lower-risk and higher-risk functions can follow different development paths without ignoring their dependencies.

It is important to note, however, that a system diagram alone does not demonstrate that segregation is effective. The organization must also test the architecture under failure conditions.

Develop a Defensible Regulatory Position Before Talking to a Regulator

Once the system, classifications, dependencies, and boundaries have been defined, the manufacturer should develop a clear regulatory position before approaching the FDA or another regulatory agency.

The regulatory rationale should explain the product’s intended use, solution architecture, regulatory architecture, system boundaries, classifications, and risks. The organization should also be prepared to show how those risks are being addressed.

An architecture diagram can support that position, but it must reflect how data and functionality actually move through the system. A proposed boundary may not be defensible if regulated data or functions flow through components the organization has placed outside the medical-device boundary.

The purpose of an agency discussion is not to ask the regulator to create the classification strategy for the manufacturer. The organization should first complete its own analysis and present a reasoned, evidence-based position.

Of course, a regulator may disagree with the proposed classification. Formal pathways may be available for obtaining a classification decision, but the manufacturer should begin with a position grounded in the product’s actual intended use, architecture, functionality, and risk.

Manage Risk Across Interfaces

Make Ecosystem Design Controls a Cross-Functional Responsibility

Connected ecosystems typically rely on multiple teams and external partners, with each group responsible for different parts of the product. One team may build the medical-device software, another may develop a connected application, and a third party may support another component or service.

“They (Ecosystem design controls) are the definition of a team sport, because there’s no single team that can develop an entire ecosystem.”
— Carl Washburn, Eli Lilly and Company

Software architecture, regulatory, quality, clinical risk, product, and third-party partners each bring a different perspective to the system.

Teams need enough understanding of one another’s disciplines to recognize when a decision in one area creates consequences elsewhere.

Verification and validation plans should define:

Interface responsibility: Which team owns each connection between systems.
Interoperability risk: Who identifies and assesses the risks created by the connection.
End-to-end testing: Who performs production-equivalent testing of the complete workflow.
Testing scope: What evidence is required to show that the integrated system works properly.
Approval: Who reviews the results and approves the connected system.

Teams should not assume that end-to-end testing will happen simply because each group has tested its own component. Responsibility for the testing of the complete system must be stated clearly.

The same principle applies to the documentation that those teams produce. Regulatory strategies, architecture documents, quality agreements, risk-management information, and verification plans should reference one another and describe the same system, boundaries, and responsibilities.

When third parties are involved, shared responsibilities and interoperability risks should also be addressed through appropriate quality agreements.

Make Failures Visible and Limit Their Effects

Connected systems should not assume that every component or dependency will always work as expected. To use a famous expression from cloud computing, “Everything breaks all the time.”

Each subsystem should make its known failure modes and residual risks visible to the systems that depend on it. The receiving system can then detect the condition, mitigate the resulting risk, and prevent the failure from spreading through the broader ecosystem.

This is also an important principle of cloud-native architecture. Large platforms contain many services that interact and change independently. They remain robust and resilient by defining how failures are communicated and managed on both sides of an interface.

Medical-device ecosystems require the same level of intention. Teams need to identify what happens when a component breaks and demonstrate through testing that the failure remains contained rather than cascading through the rest of the system.

Modularity and software segregation are only effective when teams can show that the boundaries work under failure conditions. A clear architecture diagram is useful, but testing provides the evidence that the system can detect, manage, and contain those failures.

Treat Cybersecurity as a System-Wide Concern

Many design controls can vary across an ecosystem based on each component’s function, classification, and risk.

Cybersecurity is different.

Cybersecurity risks are difficult to contain within the same technical and regulatory boundaries used for other controls. A component outside the medical-device boundary may still connect to or affect the regulated portion of the system.

Cybersecurity must therefore be analyzed and mitigated across the complete ecosystem. Different components may require different levels of design-control rigor, but nearly every connected part of the system will require appropriate cybersecurity consideration.

Manage Dependencies Outside the Manufacturer’s Direct Control

Some parts of a connected ecosystem may change outside the manufacturer’s direct control.

Cloud platforms are one example. The underlying infrastructure may change while continuing to provide services that the medical product depends on. The manufacturer may not control those changes directly, but it is still responsible for understanding and managing the dependency.

That requires visibility into the external system’s failure modes and residual risks, along with an approach for maintaining robustness and resilience when changes occur outside the organization’s control.

The discussion connected this approach to cloud computing and suggested that the same pattern may also help teams think about mobile platforms and LLM-based agentic systems. (The application of agentic AI within medical devices, however, remains unsettled.)

The key question is not whether the manufacturer owns or controls every part of the ecosystem. When ownership is not total, the question becomes whether the organization understands the dependency and has a clear approach for managing the risks it creates.

These controls must remain effective not only when the ecosystem is first released, but also as its components, dependencies, and regulatory requirements change.

Design for Change and Scale

Design the Ecosystem for Change

A connected ecosystem should be designed with future changes in mind.

The architecture and quality system need to distinguish among changes with different regulatory and risk impacts. An administrative update should not automatically follow the same process as adding an indication or making another change that affects the regulated function.

Teams need to determine:

Which functions can change independently?
Which changes affect the regulated portion of the system?
Which changes could alter the product’s nature, indications, or patient risk?
Which changes may require another regulatory cycle?
What level and type of rigor apply to each change?

The organization’s process must be able to distinguish among these situations and scale the required work appropriately.

Predetermined Change Control Plans (PCCP) provide one way to manage certain anticipated changes to device functionality. The manufacturer identifies the types of changes in advance and explains why they will not change the nature of the medical device, alter its indications, or increase patient risk. However, a PCCP does not provide unrestricted freedom to make changes. The changes must remain predetermined and risk-controlled.

The broader goal is to decide how different parts of the ecosystem can evolve before those changes occur.

Account for Differences Across Jurisdictions

A function may not receive the same regulatory treatment in every market.

The webinar used medication reminders as one example. Whether that type of feature is considered a medical device may depend on the nature of the reminder and the interpretation applied in a particular jurisdiction.

Companies developing global products may therefore need different regulatory views of the same ecosystem.

A high-level architecture may need to show U.S. and European device classifications, software safety classifications, device and non-device functions, cybersecurity requirements, interoperability considerations, and good machine learning practices.

Those regulatory views should remain connected to the same underlying components, interfaces, and dependencies. This allows teams to understand which requirements apply in each jurisdiction without losing sight of how the complete system operates.

Make Architecture and Compliance Information Machine-Readable

The webinar advocated an “everything as code” approach that includes architecture as code, requirements as code, and testing as code.

The goal is to maintain important product and compliance information in a format that is both human-readable and machine-readable.

This allows teams to view the same ecosystem in different ways, including by component, jurisdiction, classification, requirement, or dependency.

That structure becomes especially useful when a product operates across multiple markets. Teams can see how a regulatory requirement or classification differs by jurisdiction while keeping each view connected to the same underlying system.

Machine-readable information also makes change analysis easier. When a product component or regulation changes, software tools and AI agents can help identify which parts of the ecosystem may be affected and alert the appropriate teams earlier.

The value does not come from converting documents into code for its own sake. It comes from making the relationships among architecture, requirements, classifications, and system components easier to trace and update.

Use AI Agents to Support Impact Analysis and Testing

Machine-readable architecture, requirements, classifications, and testing information create a foundation that AI agents can use to support development teams.

When a product component or regulatory requirement changes, agents can help surface which parts of the ecosystem may be affected. They can also provide earlier alerts so teams can review the potential impact before the change moves further through development.

The webinar also discussed using architecture and testing agents to support software segregation. Agents can help teams apply segregation patterns and orchestrate the testing needed to demonstrate what happens when components break and whether failures remain contained.

AI agents support the process rather than define the organization’s regulatory position or make risk decisions on their own. Their usefulness depends on the quality and structure of the underlying information.

When product and compliance information is connected and machine-readable, agents can help teams identify potential issues earlier and reduce the manual work required to trace changes across a complex ecosystem.

Together, these practices describe a mature ecosystem approach. Organizations do not need to implement everything at once.

Where to Start

The webinar’s closing discussion pointed to a practical sequence for organizations beginning to apply ecosystem design controls.

1. Define the System and the Problem

Start by clarifying what the ecosystem is intended to do, the different pieces that fit together, and the problem the organization is trying to solve.
Teams also need to understand the system’s ultimate goal. That context is necessary before deciding which processes, controls, or capabilities need to be added.

2 Assess the Current State and Strategic Need

Evaluate where the organization is today and why it needs an ecosystem approach.
That assessment should consider what the organization is not currently able to do, the size of the gap, how quickly it needs to move, and the strategic value the ecosystem is expected to provide.

3. Identify Project-Specific Regulatory and QMS Gaps

Review the project the organization expects to undertake and determine which processes or capabilities are missing.
Depending on the project, those gaps may include quality agreements, interoperability SOPs, interoperability risk-management processes, other interoperability procedures, or a lightweight IT-level QMS for a connected information system.

4. Build a Prioritized Roadmap

Use the assessment to determine which gaps need to be addressed first and how far the organization needs to go.

Not every company needs the same level of maturity or development speed. The roadmap should reflect the organization’s current scale, strategic goals, and anticipated project rather than attempting to implement every possible practice at once.

The goal is to understand the gap between the organization’s current capabilities and what the planned ecosystem requires, then create a practical plan for closing it.

Key Takeaways

Define the complete system before drawing boundaries

Identify what the ecosystem is intended to do, the components involved, and how data and functionality move between them. Technical and regulatory boundaries must reflect how the product actually operates.

Match controls to function, implementation, and risk

Components within the same ecosystem may have different intended uses, classifications, dependencies, and risk profiles. The required level of rigor should reflect those differences rather than defaulting every component to the highest classification.

Connect the technical and regulatory architecture

Technical and regulatory architecture are two views of the same system. Teams need to consider both how the product works and how architectural decisions affect classification, evidence requirements, regulatory review, and future changes.

Manage risks and ownership across interfaces

Multiple teams and partners often develop connected systems. Verification plans should identify who owns each interface, who assesses interoperability risks, who performs end-to-end testing, and who approves the integrated system.

Design the ecosystem for failure and change

Failure modes and residual risks should be visible to connected systems, and testing should demonstrate that failures remain contained. The architecture and QMS should also distinguish among changes with different regulatory and risk impacts.

Keep system information connected and structured

Architecture, requirements, classifications, and testing information become more useful when they are maintained in connected, machine-readable formats. This helps teams manage jurisdictional differences, assess change impacts, and use AI agents to surface potential issues earlier.

Watch Webinar Recording

Randy Horton, VP of Solutions and Partnerships, Orthogonal