---
title: "How to Build a Medical Device Companion App With FDA Compliance"
author: "Nate Laquis"
author_role: "Founder & CEO"
date: "2027-11-15"
category: "How to Build"
tags:
  - medical device companion app
  - FDA SaMD compliance
  - IEC 62304 software lifecycle
  - 21 CFR Part 11
  - BLE medical device integration
excerpt: "A medical device companion app is not a normal mobile project. FDA regulations, IEC 62304 lifecycle requirements, and 21 CFR Part 11 electronic records rules shape every architecture decision from day one."
reading_time: "14 min read"
canonical_url: "https://kanopylabs.com/blog/how-to-build-a-medical-device-companion-app"
---

# How to Build a Medical Device Companion App With FDA Compliance

## What Makes a Medical Device Companion App Different

If you have built consumer health apps before, set those expectations aside. A medical device companion app operates in a fundamentally different regulatory universe. The app does not just display data. It communicates with a physical medical device, processes clinical measurements, and in many cases influences treatment decisions. That combination puts you squarely in the FDA's crosshairs.

Companion apps pair with devices like continuous glucose monitors, cardiac implants, insulin pumps, pulse oximeters, and neurostimulators. The app might receive raw sensor data over Bluetooth Low Energy, process it into clinically meaningful values, display trends for patients and clinicians, and transmit records to electronic health record systems. Every one of those steps carries regulatory obligations that consumer health apps never face.

The FDA treats many companion apps as Software as a Medical Device (SaMD). That classification triggers a cascade of requirements: quality management systems, design controls, risk management, software lifecycle documentation, and potentially a 510(k) or De Novo submission before you can legally distribute the app. Miss any of these and you are looking at warning letters, injunctions, or product recalls.

![Secure compliance infrastructure with blue-lit server racks representing FDA-regulated medical data systems](https://images.unsplash.com/photo-1563986768609-322da13575f2?w=800&q=80)

The good news: the regulatory path is well-defined if you know where to look. The FDA has published clear guidance documents for mobile medical applications, and standards like IEC 62304 give you a concrete framework for software development. The teams that struggle are the ones that try to build first and figure out compliance later. That approach does not work here. Compliance shapes your architecture, your development process, your testing strategy, and your deployment pipeline. It needs to be baked in from the first sprint.

## FDA SaMD Classification and Regulatory Pathway

The first question you need to answer: does the FDA consider your companion app to be a medical device? The answer depends on what the app does with the data it receives.

The FDA's 2019 guidance on "Policy for Device Software Functions" draws a clear line. If your app merely displays data that a cleared device has already processed (showing a blood glucose reading that the CGM calculated), it generally falls outside FDA oversight. But the moment your app transforms, analyzes, or interprets that data to inform clinical decisions, it crosses into SaMD territory.

**SaMD risk classification uses the IMDRF framework.** The International Medical Device Regulators Forum categorizes SaMD based on two factors: the seriousness of the healthcare situation and the significance of the information the software provides. A companion app that alerts a patient to a life-threatening arrhythmia sits at Class III (high risk). An app that tracks medication adherence trends for a non-critical condition might land at Class I or II.

Your regulatory pathway depends on this classification:

- **Class I (low risk):** General controls only. No premarket submission required in most cases, but you still need a quality management system and must register your establishment with the FDA.

- **Class II (moderate risk):** Requires a 510(k) submission demonstrating substantial equivalence to a predicate device. This is the most common pathway for companion apps. Expect 3 to 6 months for FDA review after submission, plus 4 to 8 months of preparation work.

- **Class III (high risk):** Requires a Premarket Approval (PMA) application with clinical data. Rare for companion apps, but possible if the app controls a life-sustaining device.

- **De Novo classification:** For novel devices without a predicate. If your companion app does something genuinely new (a novel algorithm for predicting hypoglycemic events, for example), De Novo may be your path. It takes longer than 510(k) but establishes your product as the predicate for future entrants.

One critical nuance: the companion app and the physical device may have separate regulatory submissions, or they may be covered under a single submission. If the device manufacturer already holds clearance and your app is part of that system, the app may fall under the device's existing clearance. If you are building a third-party companion app, you likely need your own submission. Engage a regulatory affairs consultant in the first two weeks of your project. Their guidance will save you months of rework.

## IEC 62304 Software Lifecycle and Design Controls

IEC 62304 is the international standard for medical device software lifecycle processes. If you are building SaMD, compliance with this standard is effectively mandatory. The FDA recognizes IEC 62304 as a consensus standard, and referencing it in your 510(k) or De Novo submission dramatically simplifies the review process.

The standard defines three software safety classes:

- **Class A:** No injury or damage to health is possible. Minimal documentation requirements.

- **Class B:** Non-serious injury is possible. Moderate documentation and testing requirements.

- **Class C:** Death or serious injury is possible. Full documentation, unit testing, integration testing, and detailed architecture documentation required.

Most medical device companion apps land at Class B or C. A companion app for a cardiac implant that displays pacing data and alerts clinicians to lead integrity issues is Class C. A companion app for a fitness-oriented pulse oximeter that flags low SpO2 readings might qualify as Class B.

**What IEC 62304 demands from your development process:**

- **Software development planning:** A documented plan covering your development lifecycle model, tools, configuration management, and verification/validation strategy. Agile is fine, but you need to document how your sprints map to design control milestones.

- **Software requirements analysis:** Every functional requirement traced to a system-level requirement. Every requirement testable. Requirements must capture intended use, user needs, performance criteria, and safety requirements.

- **Software architectural design:** Documented architecture showing how software items interact, how data flows between the app and the device, and how safety-critical functions are isolated from non-critical ones.

- **Software detailed design and unit implementation:** For Class C software, every unit must have detailed design documentation and corresponding unit tests. For Class B, you can take a risk-based approach and focus detailed design on safety-critical modules.

- **Software integration and integration testing:** Documented evidence that software items work together correctly. Pay special attention to the BLE communication layer and data processing pipeline.

- **Software system testing:** End-to-end testing against your requirements specification. Every requirement gets at least one test case. Traceability is everything.

This sounds heavy, and it is. But the alternative is worse. Teams that skip IEC 62304 compliance during development end up spending 2 to 3 times more retroactively documenting and testing their software when the regulatory submission deadline approaches. Build compliance into your sprint cadence from day one. Each user story should include acceptance criteria that map to IEC 62304 verification requirements. If you are already familiar with [building healthcare apps](/blog/how-to-build-a-healthcare-app), you have a head start on the documentation discipline, but medical device software takes it further.

## 21 CFR Part 11 and Electronic Records Compliance

21 CFR Part 11 governs electronic records and electronic signatures in FDA-regulated environments. If your companion app generates, stores, or transmits data that the FDA considers a "record" (and clinical measurements almost always qualify), Part 11 applies to you.

The regulation has two core concerns: ensuring that electronic records are trustworthy, reliable, and equivalent to paper records, and ensuring that electronic signatures are legally binding and attributable to a specific individual.

**Technical controls required by Part 11:**

- **Audit trails:** Every creation, modification, or deletion of a record must be logged with the user identity, timestamp, and the old and new values. Audit trails must be computer-generated, timestamped, and cannot be modified by the end user. This applies to clinical data captured from the device, configuration changes, and any manual data entries.

- **Access controls:** Role-based permissions ensuring that only authorized individuals can access, create, modify, or delete records. Patients see their own data. Clinicians see their patients' data. Administrators manage system configuration. These boundaries must be enforced at the API level, not just the UI level.

- **Data integrity:** Records must be accurate and complete. For a companion app, this means validating data received from the medical device against expected ranges, flagging corrupted transmissions, and ensuring that timestamps are synchronized between the device and the app. Checksums or cryptographic hashes on data payloads provide tamper evidence.

- **Electronic signatures:** If clinicians sign off on reports or treatment adjustments through the app, those signatures must include the signer's full name, the date and time, and the meaning of the signature (reviewed, approved, rejected). Signatures must be linked to their respective records so they cannot be copied or transferred.

![Mobile devices displaying clinical data interfaces for medical device companion applications](https://images.unsplash.com/photo-1512941937669-90a1b58e7e9c?w=800&q=80)

**System validation is the foundation.** Part 11 requires that you validate your system to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records. In practice, this means maintaining a validation protocol that documents your testing approach, installation qualification, operational qualification, and performance qualification. Every software release requires revalidation of affected functionality.

Understanding the [true costs of compliance](/blog/hipaa-compliance-costs) early helps you budget accurately. Part 11 compliance adds approximately 15 to 25 percent to your overall development timeline, primarily in documentation and validation activities. Cutting corners here is not an option. FDA 483 observations citing Part 11 deficiencies are among the most common findings during facility inspections.

## BLE Communication and Data Integrity for Medical Devices

Bluetooth Low Energy is the dominant communication protocol for medical device companion apps. It offers low power consumption, adequate bandwidth for clinical data, and broad device support across iOS and Android. But BLE in a medical context demands a level of rigor that consumer app developers rarely encounter.

### Medical BLE Profiles and Services

The Bluetooth SIG defines standard GATT profiles for common medical measurements:

- **Blood Pressure Profile (BLP):** Service UUID 0x1810. Delivers systolic, diastolic, and mean arterial pressure with units, timestamps, and measurement status flags.

- **Glucose Profile (GLP):** Service UUID 0x1808. Provides glucose concentration, sample type, sample location, and sensor status annunciation.

- **Heart Rate Profile (HRP):** Service UUID 0x180D. Heart rate measurement, body sensor location, and energy expended.

- **Continuous Glucose Monitoring Profile (CGMP):** Purpose-built for CGM devices with support for session start/stop, calibration, and alert management.

If the device manufacturer uses a proprietary GATT service (common with newer devices), you will need their SDK or detailed protocol documentation. Expect to spend 2 to 4 weeks on BLE integration and testing per device type.

### Data Validation at the Transport Layer

Medical data integrity is not negotiable. BLE packets can be corrupted, dropped, or arrive out of order. Your app must implement:

- **CRC verification:** Validate checksums on every received packet. Discard corrupted data and request retransmission if the device protocol supports it.

- **Sequence numbering:** Track packet sequence numbers to detect gaps. If readings 47, 48, and 50 arrive but 49 is missing, your app should flag the gap, attempt recovery, and log the event.

- **Timestamp reconciliation:** Device clocks and phone clocks drift. Synchronize timestamps during the connection handshake and apply correction offsets to all received measurements. A glucose reading stamped at the wrong time could lead to incorrect dosing decisions.

- **Range validation:** Reject physiologically impossible values. A heart rate of 350 bpm or a blood glucose of negative 20 mg/dL indicates a sensor malfunction or transmission error. Log these events for post-market surveillance.

### Connection Reliability

BLE connections in real-world conditions are fragile. Users move in and out of range, other devices cause interference, and phone operating systems aggressively kill background Bluetooth connections to save battery. Your architecture must handle this gracefully:

Buffer readings on the device when the app is not connected. Implement automatic reconnection with exponential backoff. On iOS, use state restoration to resume BLE sessions after the OS terminates your app in the background. On Android, use a foreground service with a persistent notification to maintain the connection. Test extensively in environments with high RF interference (hospitals, crowded clinics) because that is where your app will actually be used.

## HIPAA, Cybersecurity, and Patient Data Protection

If your companion app handles protected health information (PHI), HIPAA compliance is mandatory alongside your FDA obligations. These are separate regulatory frameworks with overlapping but distinct requirements. You need to satisfy both.

**HIPAA requirements for companion apps:**

- **Encryption:** AES-256 at rest, TLS 1.2 or higher in transit. This applies to data stored locally on the phone, data transmitted to your backend, and data shared with the medical device if the device stores patient identifiers.

- **Access controls:** Biometric authentication (Face ID, fingerprint) or strong passwords with MFA for clinician-facing interfaces. Session timeouts after periods of inactivity. Automatic data wipe after repeated failed authentication attempts.

- **Business Associate Agreements:** Every cloud provider, analytics service, crash reporting tool, and third-party SDK that could access PHI needs a signed BAA. This catches many teams off guard. Firebase Crashlytics, for example, can capture PHI in crash logs if you are not careful about what data you log.

- **Breach notification:** You must notify affected individuals within 60 days of discovering a breach. Have an incident response plan documented and tested before launch.

### FDA Cybersecurity Requirements

The FDA's 2023 guidance on cybersecurity for medical devices (updated under the PATCH Act provisions) adds requirements beyond HIPAA:

- **Software Bill of Materials (SBOM):** You must maintain a complete list of all software components, including open-source libraries and their versions. The FDA wants to know exactly what code is running and whether any components have known vulnerabilities.

- **Threat modeling:** Conduct a formal threat analysis during design. Use STRIDE or a similar methodology to identify attack vectors specific to your device-app ecosystem. A compromised companion app that sends falsified data to a clinician dashboard is a patient safety issue, not just a cybersecurity issue.

- **Vulnerability management:** Establish a coordinated vulnerability disclosure process. Monitor CVE databases for vulnerabilities in your dependencies. Patch critical vulnerabilities within 14 days of disclosure.

- **Secure update mechanism:** The app must support authenticated, integrity-verified over-the-air updates. Users should not be able to run outdated versions with known security vulnerabilities indefinitely. Implement minimum version enforcement through your backend.

![Data center infrastructure with rows of servers supporting secure medical device cloud systems](https://images.unsplash.com/photo-1558494949-ef010cbdcc31?w=800&q=80)

Build your security architecture to satisfy both HIPAA and FDA requirements simultaneously. The overlap is significant: encryption, access controls, audit logging, and incident response appear in both frameworks. A unified compliance strategy avoids duplicate effort and reduces the risk of gaps between the two sets of requirements.

## Clinical Data Visualization and Dual Interfaces

A companion app serves two fundamentally different user populations: patients who need to understand their own health data, and clinicians who need to make treatment decisions based on aggregated clinical data. These audiences have different mental models, different risk tolerances, and different regulatory implications for UI design.

### Patient-Facing Interface

Patients need simplicity, clarity, and actionable context. A glucose trend chart means nothing to a patient who does not understand what the numbers represent. Your patient interface should:

- **Prioritize status over raw numbers.** Show "In Range" with a green indicator rather than "Blood Glucose: 112 mg/dL" in isolation. Provide the number for patients who want it, but lead with the interpretation.

- **Use progressive disclosure.** Surface the most important information first (current status, any alerts), then let users drill into detailed trends, history, and settings. Do not overwhelm users with a dashboard that looks like a flight cockpit.

- **Support accessibility.** Medical device users skew older than typical app users. Large touch targets, high contrast ratios (WCAG 2.1 AA minimum), VoiceOver/TalkBack support, and configurable font sizes are not nice-to-haves. They are requirements.

- **Provide clear alert escalation.** Color-coded urgency levels (green, yellow, red) with distinct audio alerts. Critical alerts must override Do Not Disturb settings on both iOS and Android. Test this thoroughly because platform behavior varies across OS versions.

### Clinician-Facing Interface

Clinicians need density, efficiency, and clinical precision. They are reviewing data for multiple patients and making time-sensitive decisions. Your clinician interface should:

- **Show data in clinical context.** Overlay glucose readings with meal logs, medication times, and activity data. Display heart rhythm strips alongside symptom diaries. Clinical decisions require correlated data, not isolated measurements.

- **Support multi-patient workflows.** Dashboard views that highlight patients needing attention (out-of-range readings, missed device connections, overdue check-ins). Clinicians should not have to click into each patient individually to find problems.

- **Enable report generation.** Standardized clinical reports (AGP reports for glucose data, for example) that clinicians can review during appointments, share with colleagues, or include in the medical record. PDF export with clinical formatting is table stakes.

- **Include electronic signature workflows.** When a clinician reviews and acknowledges a set of readings or approves a device parameter change, that action must be captured with a Part 11 compliant electronic signature.

Both interfaces pull from the same underlying data, but the presentation layer, permissions model, and audit trail requirements differ significantly. Architect your backend with a clean API layer that serves both interfaces without duplicating business logic.

## QMS Integration, Post-Market Surveillance, and Launch Strategy

Your Quality Management System (QMS) is the backbone of your regulatory compliance. For medical device software, the QMS must comply with 21 CFR Part 820 (FDA's Quality System Regulation) and ideally ISO 13485. This is not a document you write once and file away. It is a living system that governs how you design, develop, test, release, and maintain your software.

**Key QMS elements for companion app development:**

- **Design controls:** Design inputs, design outputs, design reviews, design verification, design validation, and design transfer. Every feature in your app should trace from a user need through design inputs to verified and validated outputs.

- **Document control:** Version-controlled procedures, work instructions, and records. Every document has an owner, a review cycle, and an approval workflow. Use tools like Greenlight Guru, MasterControl, or Qualio to manage this electronically.

- **CAPA (Corrective and Preventive Action):** When bugs are found in the field, complaints are received, or adverse events are reported, your CAPA process drives investigation and resolution. FDA auditors will review your CAPA records closely.

- **Supplier management:** Every third-party library, cloud service, and development tool is a supplier. You need to assess and document the risk each supplier introduces. If your BLE library has a critical bug, that is your problem, not theirs.

### Post-Market Surveillance

Launch is not the finish line. The FDA expects ongoing monitoring of your app's performance in the real world. Your post-market surveillance system should capture:

- **Complaint handling:** A documented process for receiving, evaluating, and investigating user complaints. Complaints involving potential patient harm must be investigated within specific timeframes and may trigger Medical Device Reports (MDRs) to the FDA.

- **Software anomaly tracking:** Monitor crash rates, data synchronization failures, BLE disconnection patterns, and data integrity errors. Aggregate these metrics into trend reports that feed back into your risk management process.

- **Adverse event reporting:** If your app contributes to a death or serious injury, you must file a Medical Device Report within 30 days (or 5 days for events requiring remedial action). Have your reporting templates and escalation procedures ready before launch.

- **Periodic safety updates:** The FDA expects periodic benefit-risk analyses for SaMD products, especially those with AI/ML components that may change behavior over time.

### Timeline and Cost Reality

Building a medical device companion app is a 12 to 18 month effort for most teams. Here is a realistic breakdown:

- **Regulatory strategy and QMS setup (2 to 3 months):** $40,000 to $80,000 including regulatory consultant fees.

- **Design controls, risk management, and architecture (2 to 3 months):** $60,000 to $120,000.

- **Core development with IEC 62304 compliance (4 to 6 months):** $200,000 to $400,000.

- **Verification, validation, and clinical testing (2 to 3 months):** $80,000 to $150,000.

- **510(k) or De Novo preparation and submission (2 to 4 months):** $50,000 to $150,000 including FDA user fees.

Total realistic range: $430,000 to $900,000 for a fully compliant companion app with both patient and clinician interfaces. This does not include the cost of clinical studies if your regulatory pathway requires them.

At Kanopy, we have guided teams through the full lifecycle of regulated software development, from initial SaMD classification through 510(k) submission and post-market surveillance. We pair deep mobile engineering expertise with regulatory process discipline so you can ship a compliant product without burning 18 months on documentation alone. If you are planning a medical device companion app, [book a free strategy call](/get-started) and we will help you map your regulatory pathway and build a realistic development plan.

---

*Originally published on [Kanopy Labs](https://kanopylabs.com/blog/how-to-build-a-medical-device-companion-app)*