Article
How MedTech Teams Must Evolve for the Agentic AI Era

A MedTech company develops a promising AI algorithm. The data looks good. The use case is compelling. Leadership wants to know when it can reach the product.
Then the timeline starts growing.
The team needs more data. Regulatory questions surface.
Validation requires evidence no one preserved during discovery.
Engineering discovers that the existing product architecture was never designed to accommodate the new capability. Legal raises questions about whether the company can use the underlying data at all.
The algorithm may have taken months to discover. Getting it into production could take another year.
For MedTech leaders making larger investments in AI, that gap matters. The strategic question is no longer simply, can we develop useful algorithms?
It is: Can we repeatedly turn what we discover into something we can deploy?
That is the idea behind the MedTech AI Factory.
AI does not create a strong digital ecosystem by itself.
Its value depends heavily on what already exists underneath it: connected products, cloud services, clinical systems, user interactions, data infrastructure, and the processes that connect them.
Orthogonal CEO Bernhard Kappe describes AI as a complementary technology. It becomes more useful when combined with an ecosystem already creating value for patients, clinicians, and other stakeholders.
That creates an important feedback loop.
Give someone a useful service and they have a reason to use it. That interaction generates data. Use that data to improve therapy, simplify a workflow, identify a useful pattern, or create another service, and the ecosystem becomes more valuable.
Then the cycle starts again.
“By using that data, you can create more value.”
That is where AI can become much more than another feature in the device. An algorithm could help optimize therapy. It could support surgical planning or rehabilitation. The same data might uncover operational opportunities outside regulated functionality.
But none of those opportunities matter if the organization cannot move from discovery to deployment.
Before a team can build an effective AI Factory, it needs good raw materials.
In many organizations, the first constraint is not the algorithm at all. It is whether the right data exists in the first place.
As Bernhard puts it:
“You need to not treat data as exhaust. You need to treat data as an asset.”
That changes how teams should think during product and ecosystem design.
Instead of collecting only what today’s product feature requires, organizations should consider what data might support future product improvements, operations, research, or algorithm discovery. You may not know exactly what tomorrow’s AI opportunity will require, which makes these decisions difficult to revisit after years of data were never captured.
This does not mean collecting everything simply because you can. Some information may be expensive to capture, transmit, or store. The point is to make those decisions deliberately at design time, while the option to collect the data still exists.
Where practical, preserving raw data also matters. A transformation that makes sense today may remove information that becomes valuable later. Processing may hide errors or prevent teams from applying a better method of analysis in the future.
For an AI Factory, good data is not just about volume. It is about retaining useful, manageable raw materials that can support questions you have not thought to ask yet.
The raw data itself is only part of the picture.
There is also metadata: the context that tells you what the data actually represents.
Which population did it come from? What device or equipment generated it? Who was using the equipment, and how experienced were they? Where was the data collected? When? Under what clinical conditions? Has the data been transformed, and if so, how and by whom?
Those details can become important when a team starts asking whether an algorithm performs consistently across populations, users, equipment, or clinical environments. They may also help teams examine potential bias, model drift, and whether a result is applicable beyond the original dataset.
Time itself may matter. Something collected in July may not represent the same clinical environment as something collected six months earlier.
For regulated AI, this context becomes even more important. Good data governance means being able to show how information was captured, managed, transformed, and used, supported by records and audit trails rather than reconstructing the history after an algorithm becomes important.
The goal is not simply to have a large dataset.
It is to have data you understand and can trust.
The richest discoveries may also come from combining your own data with information generated elsewhere.
A piece of data that seems unremarkable on its own can become useful when it is connected with another source.
Bernhard gives the example of combining location information with weather or pollution data for conditions influenced by environmental triggers.
That kind of augmentation can reveal relationships that were not visible in either dataset by itself.
It is another reason to think expansively about data during design. What does your ecosystem generate today?
What contextual information should travel with it? And what other data might you eventually bring into the AI Factory to make those assets more useful?
The more complete and well-contextualized the inputs, the more possibilities the organization has for future discovery.
This becomes especially important when experimentation moves quickly.
Most experiments will go nowhere. That is expected. But the process around those experiments does not have to disappear with them.
With the right data management, tooling, and auditability, an organization can retain enough context around exploratory work that when something does succeed, the team does not have to reconstruct how it got there.
Instead, it can begin asking the next questions: What about the edge cases? What about other populations? Is the finding defensible? What formal training, verification, clinical validation, and risk management will be required?
That changes what happens when an experiment becomes a real product opportunity.
The company can move forward instead of moving backward to recreate the evidence.
There is another important distinction.
Not every organization needs to optimize AI development in the same way.
“A factory is designed to produce things quickly and efficiently.”
If your company develops an algorithm occasionally, a highly optimized production model may not make sense.
But the economics change if AI is becoming a recurring part of your product roadmap.
If your organization expects to introduce multiple algorithms over time, rebuilding the path from discovery to production for every algorithm becomes its own source of delay.
Then the leadership question becomes: Where is our limiting step?
Maybe your teams repeatedly discover that they did not collect the right data.
Maybe regulatory determination is slowing decisions because the boundaries between medical-device and non-medical-device functionality are unclear.
Maybe formal validation is cumbersome.
Maybe your digital architecture makes new algorithms difficult to deploy.
Or maybe the problem is neither technical nor regulatory. Your customer agreements may not give you the rights required to use the data.
An AI Factory is not simply a standardized checklist. It is a way to look across the entire path from discovery through deployment, identify where time is being lost, and invest in making that part of the system more repeatable.
Data rights are a good example of how far this problem reaches across the organization.
Bernhard points to medical device companies that did not initially prioritize rights to the data generated around their products. Later, they realized that data had significant value and had to obtain it from their customers.
By then, the issue could not be solved by hiring another data scientist.
A serious AI strategy may require changes to customer agreements, sales incentives, negotiation playbooks, data governance, product architecture, quality processes, and regulatory strategy.
That is why building an AI Factory is ultimately an organizational question.
For executives, the opportunity is not just shaving a few months off one algorithm.
It is building an organization where the second, fifth, or tenth algorithm does not encounter the same avoidable delays as the first.
On September 30 at 11 AM CT, Orthogonal will explore the four phases of the MedTech AI Factory: Discovery, Regulatory Determination, Formalization and Validation, and Deployment.
We will examine how MedTech organizations can build the data foundation, regulatory processes, validation practices, evidence, deployment infrastructure, and data agreements needed to move AI/ML and Agentic AI capabilities through a more repeatable pipeline.
If AI is becoming part of your product strategy, the question is no longer whether your organization will find promising algorithms.
It is what happens after you find one.
Join us for The MedTech AI Factory: From Algorithm Discovery to Compliant Deployment and learn how to shorten the path between AI discovery and deployed product value.
Related Posts
Article
How MedTech Teams Must Evolve for the Agentic AI Era
Article
Why Ecosystem Design Controls Are Really About Moving Faster With the Right Rigor
Article
MedTech Teams Should Stop Paying for Compliance Twice
Article
Beyond the Device: Where MedTech Digital Ecosystems Are Starting to Pay Off