Article
MedTech Teams Should Stop Paying for Compliance Twice
Why Ecosystem Design Controls Are Really About Moving Faster With the Right Rigor
MedTech companies are no longer building products with a neat boundary around one device. They are building ecosystems.
A connected health product might include a mobile app, cloud services, patient-facing features, clinician dashboards, data pipelines, analytics, AI-enabled functionality, and future integrations with EHRs or partner platforms. A dosing algorithm, a patient portal, and a cloud service may all live close together in the same ecosystem, but they do not all carry the same patient risk or regulatory burden.
The trouble starts when companies treat them as if they do.
At first, that approach can feel conservative. In practice, it often slows teams down without adding meaningful safety or quality. Low-risk features get pulled into high-rigor processes. Documentation expands. Review cycles stretch out. Teams spend more time proving compliance than improving the product.
That is the issue Orthogonal will explore in its upcoming webinar, “Ecosystem Design Controls: Moving Faster With the Right Level of Compliance,” on Wednesday, July 22, 2026, at 11:00 a.m. CT.
At the center of the webinar is a question many SaMD, connected device, and digital health teams are already wrestling with:
How do you apply the right level of control to the right parts of the system, without slowing everything else down?
It Starts With the Boundary
According to Megan Graham, Orthogonal’s VP of Regulatory and Quality, the first step is understanding what each part of the software actually does.
Regulatory obligations are tied to function and risk. A software function that analyzes clinical data and provides a diagnosis or treatment recommendation will not be viewed the same way as a feature that collects supporting information or displays non-critical data.
That difference should show up in the architecture.
When teams clearly separate higher-risk medical device functionality from lower-risk or non-device functionality, they can often reduce unnecessary downstream burden. A change to a lower-risk component may not require the same level of regulatory work as a change to the core clinical function.
This is not a shortcut around compliance. It is a way to make the architecture match how risk actually shows up in the product.
Megan made it clear that once medical device functionality exists within an ecosystem, the manufacturer still needs to understand the quality of the components, dependencies, and deployment environment. The team is never fully “off the hook.” But when boundaries are intentional, the compliance strategy becomes more precise.
More Documentation Is Not Always More Rigor
Once teams define those boundaries, the next challenge is applying the right amount of rigor.
Many companies still treat design controls as a documentation exercise. Megan’s view is much sharper:
“It was never about the documents. The documents are the evidence.”
Design controls should reflect the quality of the design work itself: the architecture, risk thinking, verification strategy, validation approach, safety case, and the decisions teams make throughout development.
When teams confuse documentation with rigor, they can add process without adding value.
Megan shared an example of an organization with a highly formal technical review process. The reviews required substantial documentation and a minimum review period of two weeks. Over time, those reviews stopped finding meaningful issues because the team had already improved upstream practices that caught defects earlier.
The process had once served a purpose. Later, it became extra work.
The point is not to make the process lighter everywhere. It is to make the process earn its place. If a control is no longer finding risk, the team should know that and adjust.
Build for the Product You Are Creating Next
This risk-based approach becomes even more important when teams think beyond the first release.
A company may start with a product that displays a basic physiological metric. Later, that same metric may support expanded indications, clinical decision support, or more advanced analytics. If the team only designs for the first release, it may create avoidable friction later.
Megan recommends thinking about the product as part of a broader platform or portfolio. That means asking questions such as:
- What functionality may become more clinically significant over time?
- What data do we need to collect now to support future evidence?
- Which components should be modular to support future products, integrations, or jurisdictions?
- Which parts of the MVP are intentionally temporary, and which need to scale?
An MVP does not always need to be fully scalable. But teams should be honest about what they are building, what they may replace later, and how today’s regulatory strategy supports tomorrow’s roadmap.
Done well, design controls help teams make product decisions today that do not create regulatory drag six months later.
AI Can Help, But Only If the Foundation Is Strong
The same principle applies to AI-supported product development and maintenance.
Megan notes that AI can help teams manage the growing complexity of connected medical devices by supporting impact analysis across requirements, risks, architecture, verification evidence, and product changes. For example, when a team updates a cloud service, modifies a software component, or adds a new feature, AI-supported tools may help identify which requirements, hazards, test cases, dependencies, and documentation could be affected. That can make maintenance work more manageable, especially when products are evolving across multiple releases, jurisdictions, and connected components.
But AI is not a substitute for design or regulatory judgment.
The right guardrails still matter. Teams need to confirm that AI tools are creating the right outputs, and not introducing additional quality or safety risks.
Experienced professionals should remain in the loop to review AI-supported recommendations before teams rely on them for decisions that affect the product or its compliance strategy.
AI becomes more useful when the product already has strong architecture and traceability. Without that foundation, impact analysis becomes harder, regardless of the tool.
Join the Webinar
If your organization is building a connected device, SaMD product, mobile app, cloud-enabled platform, or AI-supported medical device ecosystem, this webinar will offer a practical look at how to move faster with the right level of compliance.
You will learn how to define medical device boundaries, scale rigor based on risk, reduce unnecessary documentation burden, support future product evolution, and apply design controls as part of the way the product is built, not just how it is documented.
Join Orthogonal on Wednesday, July 22, 2026, at 11:00 a.m. CT for “Ecosystem Design Controls: Moving Faster With the Right Level of Compliance.”
Register to hear how MedTech teams can apply compliance more precisely, so high-risk functions get the rigor they need without forcing the entire ecosystem through the same process.
Related Posts
Article
Beyond the Device: Where MedTech Digital Ecosystems Are Starting to Pay Off
Article
Why MedTech Teams Slow Down as Software Grows and What Better Architecture Looks Like
Article
What Actually Works in MedTech, According to Industry Leaders
