FDA 510(k) support example for a connected ECG monitor

Let us take a relatively straightforward example: a portable connected ECG monitor.

It is not an implant, a life-support system, or a completely new medical technology. Similar ECG devices already exist, predicate devices can be identified, and an experienced team can navigate the FDA 510(k) process without turning the project into a scientific expedition.

The ECG measurement itself is not the difficult part of our story.

The interesting part starts when the device needs to store a recording, connect through LTE, send the data to the cloud, and make it available to a healthcare professional.

That is where a simple ECG recorder becomes a connected medical device system.

The First Prototype Works

A patient starts an ECG recording. The device captures the signal and stores the completed recording locally. An LTE modem connects to the cellular network, and the device uploads the recording to the cloud. A healthcare professional opens a web portal and sees the result. The first end-to-end demonstration is successful.

The waveform is there. The device is online. The cloud has received the data. The dashboard shows a green status. From an engineering perspective, this is a good day.

Then someone asks which firmware version produced the recording. The information probably exists somewhere, but it is not attached to the recording.

Another person asks what happens if LTE connectivity disappears halfway through the upload. The firmware engineer explains that the device will retry. The cloud engineer asks whether the retry will create a second record.

Then comes the more difficult question:

What happens if the cloud receives the complete ECG, but the connection drops before the acknowledgement reaches the device?

The cloud believes the upload succeeded.

The device believes it failed.

When connectivity returns, the device sends the recording again.

At this point, the green status indicator is no longer the most interesting part of the dashboard.

This is the moment when a working prototype starts becoming a regulated product. The team no longer needs to prove only that the happy path works. It needs to understand, control, and explain what happens when the system behaves less conveniently.

Define the Device Before Building More Software

For this example, we assume a prescription-use, single-lead ECG recorder intended for adult patients to capture short recordings at home.

The device stores each recording locally and uploads it for subsequent manual review by an authorized healthcare professional.

It does not continuously monitor the patient. It does not generate alarms. It does not automatically diagnose arrhythmias or recommend treatment. The cloud does not perform an independent clinical interpretation of the ECG.

These limitations matter.

A cloud platform that stores and transfers ECG recordings has a different role from software that analyzes the signal and generates a diagnostic conclusion. Adding an arrhythmia-detection algorithm is not simply another dashboard feature. It changes the function of the product and may change the regulatory work required to support it.

For this article, we also assume that the regulatory team has identified an appropriate Class II 510(k) pathway and a suitable predicate device. The actual classification still needs to be confirmed for the real intended use and technological characteristics.

Our connected system includes:

ECG monitor

→ embedded firmware

→ local storage

→ LTE modem and SIM/eSIM

→ cellular network

→ secure connection

→ KaaIoT

→ healthcare professional portal

The device records the ECG.

The embedded software stores it and manages synchronization.

LTE provides the communication path.

KaaIoT receives the recording and related telemetry, associates it with the correct device, and makes the information available to authorized systems and users.

This architecture should be agreed before the team starts collecting random telemetry or creating more dashboards.

Otherwise, different teams may use the word “device” to describe different things. Hardware may mean the physical recorder. Firmware may include the modem and local storage. Cloud may think only about the API client. Regulatory may mean the complete system supporting the medical function.

All four descriptions can sound reasonable in separate meetings. They cannot all remain undefined in the same submission.

Compare the Connected Design With the Predicate

The predicate comparison should begin early because it helps the team identify where additional evidence will be needed.

Suppose the selected predicate also captures a short single-lead ECG for professional review, but uses a different transfer method. Perhaps the predicate relies on a cable, a phone, or another established communication workflow, while our device uploads recordings directly through LTE.

The ECG measurement may be similar.

The connected behavior is not.

The team now needs to explain and evaluate the differences:

This is not yet the substantial-equivalence argument.

It is a map of where engineering work is required.

The key difference in this example is not the ECG waveform. It is the connected system around the waveform.

Follow One Recording All the Way Through

The successful sequence is straightforward:

Recording starts

→ ECG is captured

→ recording is stored locally

→ LTE connection is established

→ upload begins

→ cloud receives the complete recording

→ cloud confirms receipt

→ device marks the recording as synchronized

→ recording becomes available for review

The team should then follow the same recording through the failure scenario.

The device completes the ECG and stores it locally.

It begins uploading the recording in segments.

The cloud receives every segment and reconstructs the complete ECG.

Before the acknowledgement reaches the device, the LTE connection drops.

The device keeps the recording in a pending state because it has not received confirmation. When the connection returns, it uploads the same recording again.

The correct behavior should be clear:

• the second upload must not create a second clinical record;
• the cloud must recognize the stable recording identifier;
• already accepted segments must not corrupt the result;
• conflicting data must be rejected;
• the device must eventually receive the current synchronization state;
• the recording must not be available for review until completeness has been confirmed.

This means the upload operation must be idempotent. Repeating the same operation should produce the same logical result rather than another ECG record.

That single failure scenario produces several concrete requirements:

• every recording needs a stable identifier;
• uploaded segments need a defined sequence or identity;
• the backend needs a completeness rule;
• the device and cloud need explicit synchronization states;
• retry behavior needs to be predictable;
• acknowledgements need to refer to the correct recording;
• the event history needs to be reconstructable.

This is more useful than saying that the system “supports reliable cloud connectivity.” It explains what reliable connectivity actually means for the product.

Decide What the System Must Remember

The first prototype may upload only the ECG recording and the current battery level.

That is enough to show a waveform on a screen.

It is not enough to investigate a failed transfer.

For every recording, the team should be able to answer a few basic questions.

Which physical device created it?

Which hardware, firmware, modem firmware, communication protocol and configuration versions were active?

When was the ECG recorded?

When was it uploaded?

How many upload attempts occurred?

Was the recording complete?

Were any segments missing, duplicated or rejected?

Did the cloud return an acknowledgement?

What did the device believe its synchronization state was?

The telemetry model should be built around those questions.

For this device, the relevant context may include:

• device ID and serial number;
• hardware revision;
• embedded and modem firmware versions;
• configuration and protocol versions;
• recording ID;
• recording start and completion times;
• expected and received segment counts;
• integrity-check result;
• network registration and connectivity events;
• upload attempts and retry count;
• acknowledgement status;
• final synchronization state;
• certificate and authentication events;
• configuration and firmware changes.

The objective is not to collect every diagnostic value produced by the modem.

The objective is to retain enough information to explain the system’s behavior.

Telemetry should begin with requirements, risks and investigation needs—not with whatever fields were easiest to add to the payload.

Build the Workflow Around Explicit States

Connected systems become difficult when the same object has a different status in different components.

The device may think a recording is pending.

The cloud may think it is complete.

The portal may already show it to a healthcare professional.

That disagreement is the real problem.

A simple state model can make the workflow explicit:

RECORDED

→ STORED_LOCALLY

→ UPLOAD_PENDING

→ UPLOAD_IN_PROGRESS

→ RECEIVED_INCOMPLETE

→ RECEIVED_COMPLETE

→ ACKNOWLEDGED

→ SYNCHRONIZED

The exact names are not important.

The important part is agreeing on what each state means, who owns it, and which transitions are allowed.

For example, RECEIVED_COMPLETE should not mean that the cloud happened to receive a final message. It should mean that all expected data is present and the defined integrity checks have passed.

KaaIoT can be configured to support this workflow by:

• verifying device identity;
• checking message structure and required fields;
• associating incoming data with the correct device and recording;
• applying configured completeness and integrity rules;
• rejecting inconsistent records;
• tracking synchronization states;
• retaining the event history;
• exposing the result through APIs, dashboards and reports.

This is also where timestamps need proper definitions.

The device recording time and the cloud receipt time are not the same thing. If the device remains offline for six hours, both timestamps are valid, but they describe different events.

A generic field called timestamp is not enough. The report must distinguish when the ECG was captured, when the upload started, when the cloud received the complete recording, and when synchronization was confirmed.

Verify the Data Pipeline Before Trusting Its Output

A good-looking dashboard does not prove that the connected workflow is correct.

Before the telemetry and reports can support verification work, the team needs to test the data pipeline itself.

For the ECG monitor, that means confirming that:

• recordings are always associated with the correct device;
• software versions are captured accurately;
• expected segments are counted correctly;
• repeated uploads do not create additional records;
• incomplete recordings remain unavailable for professional review;
• invalid or expired credentials are rejected;
• event ordering remains understandable when data arrives late;
• report calculations match the underlying records;
• the reported result can be traced back to the original data.

The manufacturer owns the verification process, protocols, acceptance criteria and approvals.

KaaIoT engineers can support the platform and integration work: preparing the environment, simulating network failures, helping define what must be observed, investigating unexpected behavior and verifying the reporting logic.

The distinction is simple: KaaIoT records what happened.

The manufacturer decides whether what happened satisfies the approved requirement.

Test the Failure, Not Only the Happy Path

The manufacturer now creates a controlled test for the lost-acknowledgement scenario.

The ECG monitor completes a recording and begins uploading it.

After the cloud receives the complete recording, the LTE connection is interrupted before the acknowledgement reaches the device.

When connectivity returns, the device retries the upload.

The expected result is that:

• the complete recording remains stored locally until synchronization is confirmed;
• the repeated upload is recognized as the same recording;
• duplicate segments do not create another logical record;
• the ECG becomes available for review only once;
• the device eventually reaches the synchronized state;
• the event sequence can be reconstructed.

A clear traceability chain could look like this:

The same KaaIoT data could also support testing of a partial upload. In that case, the result should remain incomplete and unavailable for review until the missing data is successfully transferred.

Produce a Report That Explains the Result

Nobody should need to read thousands of raw telemetry records to understand the test.

KaaIoT can generate an ECG Transfer Report that summarizes the relevant technical facts while preserving references to the underlying data.

For example:

ECG Transfer Report

Device ID: ECG-0042

Recording ID: REC-2026-01841

Hardware revision: Rev B

Embedded firmware: 1.4.2

Modem firmware: 03.07

Configuration: CFG-18

Recording completed: 10:14:32 UTC

First upload started: 10:15:01 UTC

Connection lost: 10:15:18 UTC

Second upload started: 10:17:46 UTC

Synchronization confirmed: 10:18:04 UTC

Expected segments: 1,800

Accepted unique segments: 1,800

Duplicate segments received: 1,800

Missing segments: 0

Integrity check: Passed

Upload attempts: 2

Logical ECG records created: 1

Final state: SYNCHRONIZED

This report answers the practical question.

The cloud received the complete recording during the first upload, but the acknowledgement was lost. The device repeated the upload. The backend recognized the existing recording, handled the duplicate data correctly and preserved one logical ECG record.

The report does not declare the official test result.

The manufacturer’s validation team reviews it against the approved acceptance criteria. The approved conclusion and any deviations remain in the QMS.

The report provides the technical facts behind that conclusion.

Other reports can answer other questions:

• Device Event Timeline reconstructs the complete sequence;
• Configuration Report shows which device and software baseline was involved;
• Data Completeness Report identifies missing recordings or intervals;
• Connectivity Report shows network registration failures and synchronization delays;
• Fleet Report shows whether a problem is isolated or associated with a firmware, modem or hardware group;
• Cybersecurity Event Report summarizes authentication, certificate and authorization failures within the platform scope.

Reports should be designed around questions, not around database tables.

Connect the Report to the QMS

KaaIoT does not need to become the manufacturer’s QMS.

The QMS remains responsible for approved protocols, test records, deviations, reviews, CAPA and controlled conclusions.

The important part is creating a reliable connection between the QMS record and the supporting technical data.

A controlled test record may reference:

• the test protocol and execution IDs;
• the device and recording IDs;
• the tested hardware and software versions;
• the KaaIoT report ID;
• the exact reporting period;
• a stable reference to the source data;
• the approved conclusion.

The handoff may use a PDF report, structured export, API integration or controlled object-storage reference. The technology is less important than preserving the relationship between the approved conclusion and the actual device data.

The flow is straightforward:

ECG monitor

→ KaaIoT telemetry and recording context

→ technical report

→ engineering and validation review

→ approved QMS record

→ supporting reference in the 510(k)

Use the Same Technical Story in the 510(k)

The connected-device work supports several parts of the submission.

The architecture and data-flow diagrams help describe the complete system.

The state model and interface documentation explain how recordings are transferred and synchronized.

The verified reports support testing of connectivity, completeness, retry behavior and relevant risk controls.

The device, firmware, modem and configuration context show which product baseline produced the test result.

The platform documentation contributes to the software and cybersecurity sections for the KaaIoT scope.

For cybersecurity, the complete device still needs a broader story covering embedded firmware, modem firmware, communication libraries, certificates, software updates, the professional portal and third-party components. A KaaIoT platform SBOM is useful, but it is not the SBOM for the complete medical device.

KaaIoT engineers can prepare platform-related architecture, interface, data-flow, security and reporting documentation and work alongside the manufacturer’s engineering, quality, validation and regulatory teams.

The manufacturer remains responsible for the final regulatory strategy, predicate selection, substantial-equivalence argument, approvals and submission.

The Infrastructure Remains Useful After Clearance

The same connected-data layer continues to provide value after the 510(k) process.

Suppose a new embedded firmware version is deployed.

A few weeks later, the fleet data shows longer synchronization times, more network reconnections and a growing backlog of recordings waiting to upload.

KaaIoT can help identify:

• which devices are affected;
• which embedded and modem firmware versions they use;
• when the change began;
• whether the behavior is associated with a particular hardware revision or carrier profile;
• which events normally occur before the failed synchronization.

The manufacturer can then decide whether the issue requires a complaint investigation, CAPA, rollback, additional testing or a regulatory change assessment.

The platform does not make that decision.

It provides the facts needed to make it.

What KaaIoT Brings to the Project

For a connected ECG project, KaaIoT provides reusable technology and engineering support for:

• secure device identity and direct device-to-cloud communication;
• telemetry and event modelling;
• store-and-forward synchronization;
• retry and idempotency handling;
• firmware, modem and configuration context;
• dashboards and technical reports;
• connectivity and cybersecurity monitoring;
• APIs and evidence exports;
• integration with validation, document-control and QMS workflows;
• platform-related technical documentation.

These capabilities are configured for the actual device, its risks, its data model and its validation approach.

The benefit is not that KaaIoT magically produces a 510(k).

The benefit is that the manufacturer does not have to invent a separate custom system for device identity, connectivity history, synchronization state, version context, reporting and evidence export.

Conclusion

The ECG monitor in this example is not based on a mysterious new medical technology.

The challenge comes from making the physical device, embedded software, local storage, LTE connection, cloud platform and professional portal behave as one controlled system.

The device records the ECG. The firmware stores it. LTE transfers it.

KaaIoT receives the data and preserves its context.

The portal makes the recording available for review.

The QMS controls the approved conclusion.

When the connection fails, the team must still be able to explain what happened: which device was involved, which software was running, how much data reached the cloud, whether the upload was repeated, how duplicates were handled and why only one complete ECG became available.

That explanation should not be reconstructed manually after the event.

It should be available in a clear technical report generated from verified device data.

This is how KaaIoT supports the connected portion of an FDA 510(k): not by replacing regulatory strategy, validation or the QMS, but by making the behavior of the connected device visible, structured and explainable.