ISO 13485 in Connected Medical Device Development: What It Means for Your IoMT Architecture

Executive Summary

ISO 13485 affects IoMT architecture by defining how connected medical devices must be designed, modified, validated, and maintained across the firmware, software, cloud, and data layers.

The hardest compliance problems usually stem from early architectural decisions that ignore certification evidence: unclear firmware ownership, undocumented BLE behavior, uncontrolled OTA updates, cloud changes outside the QMS, or missing traceability across the entire system.

The standard supports FDA and MDR readiness by defining the quality management processes behind design controls, risk management, validation, change control, and post-market maintenance. In IoMT, compliance needs to shape architecture before core system boundaries are locked.

In connected medical device development, ISO 13485 starts shaping the product before the certification file exists. It affects decisions about data movement, clinical logic, firmware updates, BLE communication, cloud processing, and validation records.

For IoMT teams, the main question is whether the architecture can produce the evidence needed for certification without major reconstruction later. Drawing on Monterail's firsthand experience building certified connected medical devices, including FDA and MDR-regulated IoMT products, this guide explains how ISO 13485 applies to IoMT architectures and where compliance debt tends to accumulate when regulatory requirements are treated as an afterthought.

Why ISO 13485 matters for connected medical devices

Connected medical devices are harder to develop and maintain than traditional medical devices. A single IoMT solution often combines physical hardware, embedded software, mobile applications, cloud services, and integrations with clinical systems. Each component introduces its own risks, while the interactions between them create additional challenges related to safety, quality, cybersecurity, and data management.

ISO 13485 matters because connected medical devices have more regulated control points than traditional devices. Sensors, firmware, Bluetooth communication, mobile software, backend services, cloud storage, dashboards, and EHR integrations can all affect safety, performance, cybersecurity, or data integrity.

Certification also examines how the product was developed. A device can function correctly and still face regulatory problems if requirements are unclear, risks were assessed late, test records are incomplete, or changes were approved outside the QMS.

ISO 13485 gives teams the quality management basis for design control, risk management, supplier oversight, traceability, validation, and change management. These processes also support work toward  FDA and EU MDR pathways.

For connected device teams, the standard is most useful when it guides early product decisions, especially at boundaries between firmware, app, cloud, and clinical data systems.

How ISO 13485 changes how you build

Structured development lifecycle

Under ISO 13485, development can no longer rely on informal decisions or undocumented changes. Teams are expected to define requirements for developing, manufacturing, and maintaining key decisions as the product evolves.

This does not prevent agile development. Teams can still work in sprints and release iteratively. The difference is that significant changes must be assessed, documented, and approved. What might previously have been a quick engineering decision becomes part of a controlled development process.

In practice, this often becomes visible when a team needs to change a feature that has already been approved. A modification to a data synchronization workflow, device connectivity mechanism, or user interface may require updates to requirements, risk assessments, test plans, and design documentation before implementation can proceed. 

The change itself may take only a few hours to develop, but demonstrating that it has been evaluated and controlled is part of the development process.

Risk management from day one

Many software teams treat risk assessment as something that happens shortly before release. ISO 13485 takes a different approach, and ISO 14971, the dedicated standard for medical device risk management, makes this explicit. 

For connected medical devices, this means that risks associated with connectivity, data handling, software failures, or device behavior must be identified early and revisited as the product evolves.

ISO 14971 also requires that risk controls be traceable from the original requirement all the way through to deployment, it must be possible to show not only that a risk was identified, but that a control was defined, implemented, and verified.

For example, a team developing a remote patient monitoring device may identify the risk that a connectivity failure could prevent critical health data from reaching clinicians. Addressing that risk under ISO 14971 involves more than logging it in a register.

The team must define mitigation measures such as local data buffering or alert mechanisms, link those controls back to the originating requirement, and generate evidence that they function as intended under realistic conditions.

Traceability across the system

One of the most common challenges in regulated development is proving how a requirement became a working feature.

ISO 13485 requires manufacturers to maintain clear links between user needs, technical requirements, implementation, testing, and validation. In an IoMT product, those links often span multiple systems, including devices, mobile applications, cloud services, and clinical platforms. Without that traceability, it becomes difficult to demonstrate that the product behaves as intended or that important requirements have been fully addressed.

A seemingly simple requirement such as "clinicians must receive patient alerts within a specified time frame" can affect multiple parts of an IoMT ecosystem. Firmware may generate the alert, a mobile application may transmit it, and a clinical dashboard may simply display it. Traceability enables demonstration of how each component contributes to fulfilling the original requirement.

Documentation as part of the product

Under ISO 13485, documentation is created alongside the product itself. Requirements, design reviews, risk assessments, test results, and change records are generated throughout development and become part of the evidence supporting certification. 

By the time the product reaches an audit, the documentation should already reflect the decisions that shaped the device rather than being reconstructed after the fact.

Who owns compliance at the hardware–software boundary?

The answer is often surprising: no single team owns it. ISO 13485 governs the entire product, which means compliance responsibility is distributed across every team that contributes to its development. 

Hardware engineers, firmware developers, mobile teams, cloud architects, QA specialists, and regulatory stakeholders all generate evidence that feeds into the Quality Management System (QMS). 

The challenge here is ensuring that responsibilities are clearly defined at every point where systems interact. This becomes particularly important in areas such as firmware and BLE communication, over-the-air updates, and cloud infrastructure.

BLE and firmware as regulated components

Firmware is often treated as an extension of hardware, but it's actually software and must be managed accordingly. It requires version control, validation, testing, and traceability throughout the product lifecycle. The level of documentation depends on the software's potential impact on patient safety, as defined by IEC 62304.

Bluetooth Low Energy (BLE) communication introduces another layer of responsibility. Decisions about pairing methods, data transmission, and error handling affect how data integrity is demonstrated across the device-to-app boundary. 

Regulators expect manufacturers to show not only that data is transmitted successfully, but also how failures such as disconnections, packet loss, or operating-system restrictions are identified and managed for compliance.

The handoff between device and application is therefore a compliance boundary. Teams must define who is responsible for documenting requirements, testing data integrity, and maintaining traceability across that interface.

OTA updates – a change control problem, not a DevOps problem

Under ISO 13485, over-the-air (OTA) update is treated as a controlled product change. Before deployment, manufacturers must assess how the update affects safety, performance, cybersecurity, risk management, and regulatory compliance, then document and approve the change through the Quality Management System (QMS).

This has several practical implications:

1. Rollback mechanisms are regulatory safeguards that allow manufacturers to recover devices if an update introduces unexpected issues. 

2. Staged rollouts require documented risk assessments and predefined criteria for expanding deployment to larger user groups. 

3. Every update must leave an audit trail showing what changed, why it changed, how it was tested, and who approved it.

For business and product teams, the key takeaway is that OTA updates cannot be managed solely through release management processes. They must also pass through formal change-control procedures. 

When cloud infrastructure falls within the QMS scope

Regulatory requirements apply to the device and all things around it that process, store, or transmit regulated medical data. This means that changes to cloud architecture, backend services, data-processing pipelines, or infrastructure-as-code configurations are subject to the same change-control principles as application code. 

If a cloud update affects how clinical data is processed or presented, its impact must be assessed, tested, documented, and approved.

Regulators also expect end-to-end data traceability. Manufacturers must be able to demonstrate how data moves from the device through the cloud environment and ultimately to the clinician or user interface. Every significant transformation of that data should be documented and auditable. 

What ISO 13485 looks like in practice

Development workflow

ISO 13485 doesn't require abandoning agile. What changes is the evidence generated along the way.

In a standard sprint, "done" means working and tested. Under ISO 13485, teams also need to show how the feature maps to documented requirements, what risks were considered, and how the implementation was verified. That evidence is created during development. Sprint artifacts become audit records. Design reviews become formal checkpoints; risk assessments update with each new feature.

Architecture constraints

ISO 13485 does not dictate how manufacturers should design an IoMT product. However, it does influence which architectural decisions are easiest to live with over the long term.

Choices made early in development, such as where patient data is processed, how devices communicate with cloud services, or how software components interact, can have significant compliance implications later. Once those decisions become part of a regulated product, changing them may require new risk assessment, additional testing or updated project’s documentation. 

Clinical logic placement

One of the earliest and most important architectural decisions is where clinical logic will run. Whether calculations, alerts, or clinical decision-making happen in firmware, a mobile application, or the cloud directly affects what must be tested, validated, and documented.

The key constraint is that moving clinical logic after development has started is expensive. It changes the validation scope, creates new documentation requirements, and may require updates to regulatory submissions.

For that reason, teams should decide where clinical functionality belongs before development begins rather than revisiting the decision later.

Data flow documentation

In an IoMT system, data typically passes through multiple stages before reaching a clinician or patient. Measurements may be filtered, calibrated, aggregated, or analyzed as they move from the device to the application and cloud platform.

From a compliance perspective, every significant transformation must be documented. It is not enough to understand how the data is processed after the fact. 

Teams must be able to show what changed, why it changed, and where that transformation was implemented. Missing documentation around data processing is a common source of audit findings because it makes system behavior difficult to verify.

BLE communication

Bluetooth Low Energy (BLE), although often treated as a technical implementation detail, is also a compliance decision.

Choices around pairing, reconnection, buffering, and error handling influence how manufacturers demonstrate that data is transferred accurately and reliably between the device and the application. If a connection is interrupted, for example, the system must be able to handle the failure predictably and prevent the loss or corruption of clinically relevant data.

These design decisions shape potential risks, necessary controls and the evidence required during validation. A BLE architecture chosen primarily for development convenience can become a significant obstacle during certification if data integrity, reliability, and patient safety considerations were not addressed from the outset.

EHR integration

If an IoMT product exchanges data with an Electronic Health Record (EHR) system, the compliance boundary extends to that integration.

This is particularly important in remote patient monitoring solutions. For example, a blood pressure monitor may collect measurements at home, transmit them through a mobile application and cloud platform, and ultimately display them in a clinician's EHR dashboard. From a regulatory perspective, manufacturers must be able to demonstrate how that data moves through every stage of the process. Data mappings, transformations, timestamps, and audit logs all become part of the evidence that regulators may review.

Treating EHR integration as a simple product feature rather than a regulated interface often creates unexpected compliance work later in the certification process. If a clinician sees a blood pressure reading in the EHR, the manufacturer may need to demonstrate exactly how that value was captured, transmitted, processed, and displayed throughout the system.

Case Study: Elvie Pump

The Elvie Pump is one of the most recognized connected medical devices in the FemTech category. Monterail contributed directly to its development across firmware, BLE connectivity, and the mobile application.

The core compliance challenge was data integrity across the device-to-app boundary, specifically when users ran two pumps simultaneously or experienced intermittent Bluetooth connectivity. The team needed to demonstrate that data stayed accurate and traceable under real-world conditions, not just in ideal test scenarios.

The team designed BLE communication protocols, synchronization behavior, and reconnection handling as a regulated system boundary from the start. That meant every critical interaction could be tested and documented already during development.

The product shipped meeting both FDA and MDR requirements, with no architectural rework required at the certification stage. It went on to become one of the most commercially successful connected FemTech devices on the market, with more than 20 notable awards.

Source: Elvie website

What happens when teams develop without ISO 13485 processes?

The following mistakes are among the most common causes of unexpected rework, certification delays, and increased compliance costs.

IoMT compliance readiness check

Before moving further into development, ask yourself the following questions:

• Have you started documenting how the product is designed, tested, and validated, or are you planning to assemble that evidence later?

• Are firmware changes tracked and reviewed in the same way as software and infrastructure changes?

• Can you demonstrate how each major product requirement was implemented, tested, and validated?

• Is risk management already part of the development process, or is it still planned for a later stage?

• Do cloud infrastructure changes go through the same review and approval process as application code changes?

• Do you have a documented process for deploying and rolling back OTA updates if something goes wrong?

• Is ownership clearly defined at the hardware–software boundary, including how data and requirements move between systems?

Compliance is an architectural decision

Certification is where the QMS begins to prove its worth in production. Post-market surveillance requires the same traceability infrastructure built during development: incident tracking, change assessment, and risk updates. Teams that keep compliance embedded in their engineering workflow handle this without disruption. Teams that treated it as a pre-market checklist face it as a second project. The architecture decisions made in month one determine which situation you end up even months after launch.