IoMT Decisions in Development That Become Operational Risk
When you are deep in development, the pressure is straightforward: get the product built, get it certified, get it live. Everything else feels secondary. The problem is that some of the decisions that seem secondary during development turn out to matter a lot once the device is running in real clinical environments. We have worked through enough of these situations with MedTech teams to know which ones come up again and again. Here is what we see most often, and how we help teams get ahead of it.
Architecture designed for launch, not for what comes after
Most teams build an architecture that passes testing and gets the product certified. That is the right short-term goal. But we have seen many times what happens when that same architecture needs to support hundreds of devices across dozens of hospitals, with continuous data streams and update cycles that cannot disrupt clinical workflows. It often does not hold up.
How we approach it
From the first architecture conversation, we think about the full lifecycle: how the product will be monitored, updated, and scaled in production.
We know where the pressure points appear and how to design around them early.
Security handled as a certification requirement
Pen tests pass, cybersecurity documentation gets submitted, and the regulatory review accepts it. At that point many teams consider security done.
The threat landscape for connected medical devices changes continuously though. New vulnerabilities appear in open-source libraries.
Network configurations evolve. What was secure at launch needs active maintenance to stay secure.
How we approach it
We design security as an ongoing operational function from the start, not a project milestone. That means continuous monitoring, a clear response process, and the regulatory know-how to assess what a new vulnerability actually means for your specific device and its certification status.
No clear owner for the product after launch
Development teams move to the next product. Regulatory teams focus on the next submission. It is completely natural and it leaves the live device without active ownership. We have seen what this looks like in practice: slow incident response, missed update cycles, clinical users who lose confidence in the product because issues take too long to resolve.
How we approach it
For many of our clients, we become that owner. We take responsibility for the live product — monitoring it, maintaining it, and evolving it — so the internal team can focus on what they do best. That continuity is one of the most valuable things we provide.
Post-market surveillance planned but not operationalized
Under MDR and FDA requirements, PMS is not optional. Real-world data needs to be collected and fed back into the quality system. Vigilance reports need to be filed. PSURs need to be prepared. We regularly see teams that have a PMS plan on paper but no running process behind it. That gap tends to surface at the worst possible time.
How we approach it
We integrate post-market surveillance into the operational model. We have the regulatory experience to know what needs to be collected, when it needs to be reported, and what a clinical incident actually requires in terms of response. That is not something you want to figure out under pressure.
What tends to be true of IoMT products that run well long-term: The teams behind them thought about operations during development, not after something went wrong. And they had someone alongside them who had navigated these situations before. That is the role we play at Thaumatec.
We work with MedTech companies across the full product lifecycle: Develop, Run, and Evolve. If your team is currently in development, the best time to address these questions is now, before the architecture is fixed and the decisions are harder to revisit.
Building an IoMT product and thinking about what comes after launch?
We have helped many MedTech teams get this right from the development phase.