Your device is cleared. Or close. And the app — the thing patients actually touch every day — is either a known weak point, an afterthought, or not yet built. Medical device companion app development is the conversation Topflight has with device companies every week — and the stakes behind it are enormous.
The global remote patient monitoring market is projected to reach $175 billion by 2030. The continuous glucose monitor (CGM) market alone exceeds $25 billion. The smart inhaler market stands at $2.1 billion and is growing at 16% CAGR. Across every vertical, the companion app is increasingly the product that determines patient retention, clinical outcome data quality, and reimbursement eligibility.
This guide delivers a complete, device-specific reference across the four highest-growth connected medical device categories — CGM, RPM, cardiac monitors, and smart inhalers. It covers FDA classification, Bluetooth Low Energy (BLE) architecture, HIPAA compliance, and the development decisions that are specific to each device type. Not generic mHealth guidance. Not theoretical. Built for the team that has a wearable medical device and needs an app.
| Quick Question: What does it take to build a companion app for a medical device?
Quick Answer: A medical device companion app requires FDA classification assessment (non-device, accessory, or SaMD), BLE architecture validated against target hardware, HIPAA-compliant data infrastructure, and a QMS-aligned development process that produces both working software and the documentation package needed for 510(k) or De Novo submission. The specific requirements vary significantly by device category — CGM, RPM, cardiac, and smart inhaler apps each carry distinct regulatory pathways, technical architectures, and compliance obligations. |
Key Takeaways:
- Your companion app’s FDA classification — not your device’s — determines your regulatory burden. Most teams assume the app inherits the hardware’s clearance. It doesn’t. An app that interprets, alerts, or recommends crosses from non-device into accessory or SaMD territory, and discovering that mid-build means rework.
- CGM, RPM, cardiac, and smart inhaler companion apps are four different products. They share BLE and HIPAA foundations, but diverge sharply on FDA pathway, data architecture, liability profile, and clinical workflow integration. This guide breaks down each category independently so you can skip to yours.
- The checklist and 5-phase process in this guide are built for FDA submission, not just software delivery. A working app that lacks QMS documentation, an SBOM, or a validated test suite is an app that cannot be submitted. The process here produces both the product and all the paperwork.
Table of Contents:
- What Is a Medical Device Companion App — and How Does FDA Classify It?
- The Medical Device Companion App Matrix — FDA, HIPAA, BLE, and Key Challenges by Device Type
- Universal Requirements — What Every Medical Device Companion App Needs
- CGM Companion App Development (Continuous Glucose Monitor)
- RPM Companion App Development (Remote Patient Monitoring)
- Cardiac Monitor Companion App Development (Holter, Patch, ILR)
- Smart Inhaler Companion App Development
- The Development Process for Medical Device Companion Apps
- The Complete Companion App Development Checklist for Medical Device Teams
- Why Choose Topflight Apps for Medical Device Companion App Development
- What Separates a Compliant Companion App from a Costly Rebuild
What Is a Medical Device Companion App — and How Does FDA Classify It?
A companion app for medical devices is a mobile application that connects to a hardware medical device — typically via Bluetooth Low Energy — to display, transmit, store, or analyze data from that device, or to control its functions. FDA’s classification of the companion app depends on what the app itself does with the data, not simply what the hardware does.
The 2023 FDA guidance on device software functions, issued through the FDA Digital Health Center of Excellence, created three tiers relevant to companion apps. Understanding which tier your app occupies is the single most important regulatory decision you will make before writing a line of code.
Tier 1. Non-Device Software (No FDA Oversight)
The app displays raw data from the device without interpretation. Example: showing a CGM glucose reading on a phone screen exactly as received from the sensor, with no trend analysis, alerts, or clinical decision support. FDA generally does not regulate this tier as a medical device in its own right. The app is a display — not medical device software (MDSW).
Tier 2. Accessory to a Medical Device
The app supplements, augments, or controls the functions of a regulated medical device. FDA considers this an accessory to a medical device and may require its own FDA 510(k) clearance or inclusion in the parent device’s submission.
Example: an app that provides dosing recommendations based on CGM data, or an app that adjusts parameters on a cardiac rhythm monitor. This is the classification that catches most companion app teams by surprise — and the most expensive one to discover mid-development.
Tier 3. Standalone SaMD
The app performs medical device functions independently of the hardware — for example, an app that uses phone camera or microphone data to perform a clinical assessment without any paired hardware. This is treated as full Software as a Medical Device (SaMD) with its own regulatory pathway, potentially requiring a De Novo pathway or De Novo classification if no predicate device exists demonstrating substantial equivalence.
Related: SaMD App Development Guide
⚠ Regulatory Flag: The most common regulatory mistake in companion app development is building an app that qualifies as an accessory to a device (Tier 2) and submitting only the hardware for FDA clearance. If the app is integral to the device’s intended use, FDA increasingly expects both to be addressed in the submission. Clarify this in an FDA pre-submission meeting (Q-Sub) before starting development. The risk classification of your app determines your entire regulatory burden.
The Medical Device Companion App Matrix — FDA, HIPAA, BLE, and Key Challenges by Device Type
Here is how the four major companion app device categories compare across the key development dimensions. Whether you are a device product manager scoping a new build, a digital health CTO evaluating architecture trade-offs, or a medical device startup founder navigating FDA for the first time — this is your starting comparison.
| Device Category | FDA Class | Companion App Classification | HIPAA Required? | Primary Protocol | Key Build Challenge |
| CGM (Dexcom G7, Abbott FreeStyle Libre) | Class II | Accessory — often requires 510(k) | Yes (PHI) | BLE GATT + proprietary SDK | Real-time glucose alerts; background sync reliability; insulin dosing liability if app gives recommendations |
| RPM Platform (blood pressure monitor, weight, pulse oximeter, SpO2) | Class II | Non-device display or accessory (depends on alerting logic) | Yes (PHI) | BLE + WiFi; HL7 FHIR for EHR push | Multi-device aggregation; CPT codes 99453/99454 billing workflow; care team dashboard; alert fatigue management |
| Cardiac Monitor (Holter monitor, patch, implantable loop recorder) | Class II / III | Accessory — typically included in parent 510(k) or PMA | Yes (PHI) | BLE for patches; cellular for ILRs | Arrhythmia detection liability; ECG data fidelity; FDA cybersecurity requirements; clinician reporting workflow |
| Smart Inhaler (Propeller Health, Hailie/Adherium) | Class II | Accessory — often requires own 510(k) | Yes (PHI) | BLE GATT | Medication event capture accuracy; geolocation correlation; care plan integration; pediatric UX requirements |
Each device category is explored in depth in the sections below.
Universal Requirements — What Every Medical Device Companion App Needs
Before diving into device-specific requirements, these foundations apply across all four categories. Getting them wrong in any vertical creates the same result: a failed FDA submission, a rejected App Store review, or a patient safety event.
BLE Architecture and Connection Reliability
Medical device companion apps live or die on Bluetooth connection reliability. A dropped CGM reading or missed cardiac event is not a UX problem — it is a patient safety event. The architecture decisions that matter most:
- BLE GATT profile selection — use standardized profiles (Heart Rate, Glucose) where available. Build custom GATT profiles only where the device requires proprietary data characteristics. Bluetooth pairing must be seamless across iOS and Android.
- Background data sync on iOS — iOS aggressively terminates background processes. Core Bluetooth’s state preservation and restoration APIs must be implemented correctly or readings are lost. This is the single most common technical failure point in companion app development.
- Reconnection logic — patients move, devices sleep, and the app must reconnect gracefully without user intervention. Real-time data streaming demands robust retry logic and connection state management.
- Offline mode — readings must be buffered locally and synced when connectivity resumes via a reliable data synchronization pipeline. Data loss is not acceptable in any regulated IoT medical device context.
Battery impact is equally critical. Aggressive BLE polling destroys phone battery life, and patients who charge their phones more often use the app less. Battery optimization must be designed into the connection architecture, not patched later.
For a deeper dive into BLE implementation patterns across iOS and Android, see our guide to BLE mobile app development.
HIPAA Compliance
Every device in this matrix transmits protected health information (PHI). Medical device app HIPAA compliance is not optional for any companion app in these categories. Core requirements that apply universally:
- Execute a business associate agreement (BAA) with your cloud provider, analytics vendor, push notifications service, and any EHR integration partner.
- Implement encryption at rest (AES-256) and encryption in transit (TLS 1.3) for all PHI.
- Audit logging — who accessed which patient record, when, from which device. This is both a HIPAA requirement and an FDA expectation for regulated software.
- Minimum necessary data access — the software should not transmit more PHI than the clinical use case requires.
- Breach notification plan — the 60-day OCR notification window starts when a breach is discovered, not when it is investigated.
Data privacy obligations extend beyond HIPAA when your app operates internationally or collects location data, particularly in pediatric populations. For a complete walkthrough, see our guide to HIPAA compliant app development.
FDA Cybersecurity Requirements (2023 Guidance)
FDA cybersecurity guidance for medical devices now applies to any device software — including companion apps classified as accessories. Requirements that became effectively mandatory after the 2023 guidance update:
- SBOM (software bill of materials) — a complete inventory of all software components, including third-party libraries, open-source dependencies, and their known vulnerabilities.
- Vulnerability monitoring and patching plan — a documented process for responding to discovered vulnerabilities post-market.
- Penetration testing — required pre-submission for most device software.
- Secure development lifecycle (SDL) documentation.
⚠ Regulatory Flag: SBOM is the requirement most companion app teams are not prepared for. Your React Native dependencies, your BLE parsing library, your analytics SDK — all of it must be catalogued, versioned, and monitored for vulnerabilities. Build the SBOM process into development from day one, not as a pre-submission scramble.
HealthKit, Health Connect, and Platform Data Sharing
Most medical device companion apps integrate with Apple HealthKit and Google Health Connect to share device data with the broader health ecosystem on iOS and Android. Both platforms have their own review requirements that run in parallel to FDA:
- Apple requires HealthKit apps to have a clear clinical purpose — wellness-only framing can trigger rejection.
- Health Connect requires data type permissions to be justified in the Play Store submission.
- Both platforms conduct enhanced review for apps handling sensitive health data categories (cardiac, glucose, respiratory).
Topflight builds HIPAA-compliant, FDA-ready companion apps for medical device companies. Talk to our team about your device and intended use.
CGM Companion App Development (Continuous Glucose Monitor)
Market Signal: The CGM market exceeds $25 billion globally. Dexcom and Abbott dominate hardware, but mid-market diabetes management platforms and digital health platform companies are actively building companion layers on top of CGM data APIs. The Dexcom Real-Time API and the Abbott LibreLink developer program both enable third-party CGM companion app development — creating a growing market for specialized development partners.
FDA Classification for CGM Companion Apps
CGM companion apps occupy a narrow regulatory corridor. Displaying a glucose reading from a Dexcom G7 or Abbott FreeStyle Libre: generally non-device. Providing trend-based insulin dosing recommendations: almost certainly an accessory requiring its own 510(k), or inclusion in the CGM system’s predicate submission. The line is the dosing recommendation — and it is a hard line.
Key regulatory reference: FDA’s iCGM guidance (2018) governs interoperable CGM systems that share data with third-party apps. If your application ingests iCGM data, it may need to meet iCGM interoperability requirements, which carry their own accuracy and connectivity validation standards.
Technical Architecture — CGM
- Primary data source options: Dexcom Real-Time API (OAuth 2.0, REST), Abbott LibreLink Up API, or direct BLE from sensor (requires OEM partnership — do not attempt hardware reverse engineering).
- Glucose alert logic: Real-time alerts for high/low readings are the core patient safety feature. Implement with background processing, sound alerts, and Apple Watch / Wear OS mirroring. This is where wearable app development expertise becomes critical.
- Trend arrow display: FDA considers trend arrow display to be clinically significant. Your UI must match the cleared device’s trend arrow definitions exactly — deviations create regulatory risk.
- Data latency: The Dexcom API has up to a 3-minute delay. Your app architecture must handle this gracefully and never imply real-time accuracy it does not have. The cloud data pipeline must account for this latency in every user-facing display.
- Insulin-on-board and carb tracking: If your app adds these features, you have crossed into clinical decision support territory. FDA classification review is required before development.
CGM-Specific HIPAA Considerations
CGM data is extraordinarily sensitive — it reveals daily patterns of life, eating behavior, activity level, and can imply underlying conditions beyond diabetes. The minimum necessary principle is especially important: do not transmit raw CGM time-series data to analytics platforms unless clinically required.
⚠ Regulatory Flag: Several CGM companion app companies have received FTC warning letters for selling anonymized glucose data to third parties. Anonymization of CGM time-series data is technically difficult and legally contested. Default to: collect what you need clinically, retain for the minimum required period, never sell. This applies equally to any mHealth app handling continuous physiologic data.
For teams building AI-driven analytics on top of CGM data pipelines, understanding how AI is reshaping EHR workflows provides useful context — see How will AI help change EHR?
RPM Companion App Development (Remote Patient Monitoring)
Market Signal: RPM reimbursement via CMS CPT codes 99453, 99454, 99457, and 99458 has created an enterprise B2B market for RPM platforms. Health systems are actively procuring RPM solutions. The RPM companion app — the patient-facing component — is the highest-friction element in RPM adoption. Patients who don’t use the application generate no billable data. No data, no reimbursement, no program.
FDA Classification for RPM Companion Apps
RPM companion apps span a wide classification range. A pure data display app showing blood pressure readings from a connected cuff is generally non-device. Software that generates alerts, scores clinical risk, or provides care recommendations based on aggregated data is an accessory or SaMD. Most enterprise RPM platforms include some alerting logic, which immediately triggers regulatory assessment.
Technical Architecture — RPM
- Multi-device management: Enterprise RPM apps aggregate data from blood pressure monitors, pulse oximeters, weight scales, glucometers, and thermometers from different manufacturers. Your BLE layer must handle heterogeneous device profiles — this is fundamentally different from single-device companion apps and is closer to building an IoT app development platform.
- FHIR API integration: RPM data must flow to the ordering provider’s EHR via HL7 FHIR R4. Epic, Cerner, and Athenahealth all have RPM integration pathways. This is the technical layer that makes EHR integration and health system partnership deals possible. For teams navigating EHR build decisions, see our guide on how to build an EHR system.
- Care team dashboard: The companion app is the patient side. You also need a clinician-facing dashboard for alert review, trend analysis, and documentation in the clinical workflow. These are two products, not one.
- CPT billing workflow: RPM reimbursement requires documented physiologic data collection for 16+ days per month and documented clinical review time. Your platform must generate the audit trail for billing — this is not a feature; it is the business model.
- Alert fatigue architecture: RPM generates enormous data volume. Your alerting logic must be tunable by clinical protocol — not binary on/off — or care teams will disable alerts entirely, destroying patient engagement and the program’s clinical value.
RPM-Specific Compliance Considerations
RPM involves a covered entity (the ordering health system) as a direct customer. This makes HIPAA compliance non-negotiable and the BAA a sales prerequisite, not an afterthought. Health system procurement teams will require a completed HIPAA security assessment and BAA before any pilot. Understanding the billing implications is equally critical — see our overview of EHR in medical billing for context on how RPM data flows into reimbursement.
Building an RPM platform and need FHIR-based EHR integration alongside the patient app? Topflight handles both layers.
Cardiac Monitor Companion App Development (Holter, Patch, ILR)
Market Signal: Cardiac monitoring is the highest-stakes companion app category. Class III implantable devices like implantable loop recorders involve companion apps that must meet the same regulatory rigor as the device itself.
The cardiac monitor companion app market sits within the broader cardiac rhythm monitoring industry at $8 billion and growing — driven by atrial fibrillation detection demand post-COVID and Apple Watch-driven patient awareness of heart rhythm irregularities.
FDA Classification for Cardiac Companion Apps
Cardiac companion apps are almost universally classified as accessories to a medical device or included in the parent device’s FDA submission. A program that displays raw ECG data: potentially non-device. An application that detects, classifies, or alerts on arrhythmias: accessory or SaMD. For Class III devices (implantable loop recorders), the companion app is typically included in the PMA submission, which is a fundamentally different regulatory pathway than 510(k).
Key regulatory note: FDA’s 2019 guidance on cardiac rhythm monitoring software specifically addresses algorithm-based arrhythmia detection. Any application performing this function must meet the guidance’s clinical validation requirements — no shortcuts, no equivalence arguments without validated clinical data.
Technical Architecture — Cardiac
- ECG fidelity requirements: Cardiac companion apps must transmit ECG waveforms without signal degradation. Compression algorithms must be validated against clinical accuracy standards — this is not a general-purpose data compression problem.
- Transmission protocols: Ambulatory Holter monitor patches typically use BLE to phone, then cellular or WiFi upload to cloud. The full data pathway must be validated for signal integrity from sensor to clinician report.
- ILR remote programming: Apps for implantable loop recorders may include remote parameter adjustment. This creates the highest regulatory risk profile of any companion app category and requires deep OEM partnership. See our guide on heart monitoring app development for additional technical context.
- Clinician reporting workflow: Cardiac companion apps typically generate PDF reports for the ordering cardiologist. Report format, terminology, and clinical completeness are regulated by the same FDA submission that covers the device.
- Real-time alerting: Atrial fibrillation or critical arrhythmia alerts must reach patients and care teams with validated latency. The alerting architecture is part of the device’s intended use claim and must be tested accordingly.
⚠ Regulatory Flag: Cardiac companion apps carry the highest legal liability of any device category. An arrhythmia that is missed because of a BLE disconnect, a background sync failure, or a software bug is not a product defect — it is a potential wrongful death event. Quality Management System (QMS) documentation, validated testing protocols, and post-market surveillance are not optional for cardiac. They are existential.
Cardiac-Specific Cybersecurity Requirements
FDA’s 2023 cybersecurity guidance applies with particular force to cardiac device software. The guidance explicitly documents that remote access vulnerabilities in cardiac devices have resulted in voluntary recalls. Your app’s authentication, session management, and network communication must meet the cybersecurity section of the 510(k) or PMA submission. AI in healthcare compliance is increasingly relevant here as manufacturers explore automated vulnerability detection in post-market surveillance.
Smart Inhaler Companion App Development
Market Signal: The smart inhaler market stands at $2.1 billion, growing at 16% CAGR. Asthma and COPD together affect over 300 million people globally. Propeller Health (acquired by ResMed), Hailie (Adherium), and Teva’s Digihaler are the established players.
Third-party smart inhaler app development is growing as payers and pharmaceutical companies seek medication adherence data to justify reimbursement and demonstrate real-world drug efficacy.
FDA Classification for Smart Inhaler Apps
Smart inhaler companion apps typically qualify as accessories to the inhalation device. FDA has issued specific guidance on combination products — devices that combine drug delivery with digital components — which applies directly to smart inhalers. The companion app may need its own 510(k) clearance or may be included in the combination product submission, depending on the OEM’s regulatory strategy.
Technical Architecture — Smart Inhaler
- Medication event capture: The core function is detecting an inhaler actuation and logging the time, location, and device ID. BLE GATT profiles for inhaler event capture are not standardized — most require device-specific SDK integration, unlike the standardized profiles available for heart rate or glucose.
- Geolocation correlation: Smart inhaler apps correlate medication events with location (home, school, outdoors) and environmental data (pollen count, air quality index). This data combination raises unique privacy considerations, particularly for pediatric users.
- Adherence scoring: Apps that score adherence and present results to care teams or payers are crossing from display into clinical decision support. FDA classification review is required before this feature ships.
- Pediatric UX requirements: A significant smart inhaler user population is children. The software must be designed for both the child (simple, visual, gamified) and the parent (detailed adherence data, care plan access). Two UX modes in one app.
- Care plan integration: Smart inhaler apps increasingly integrate with asthma action plans. If the application provides escalation guidance (“take rescue inhaler now,” “call your doctor”), that escalation logic needs regulatory review as it constitutes clinical decision support.
Smart Inhaler — Pharma Partnership Considerations
Several smart inhaler companion app projects are funded by pharmaceutical companies seeking real-world adherence data for their drugs. This creates a distinct data governance requirement: patient inhaler usage data may be valuable to the drug manufacturer, but sharing it requires explicit, granular informed consent and creates FTC scrutiny risk if the data sharing is not clearly disclosed.
Understanding the broader cost of AI in healthcare is relevant here as pharma partners increasingly expect AI-driven adherence analytics as part of the companion app deliverable.
The Development Process for Medical Device Companion Apps
Building an FDA companion app medical device teams can submit with confidence is fundamentally different from building a consumer health app. The process must be structured to produce the documentation FDA requires, not just the software clinical teams want. Here is the timeline and phase structure Topflight uses across all four device categories.
Phase 1 — Regulatory Strategy (Weeks 1–4)
- Determine companion app FDA classification based on intended use — engage regulatory counsel early.
- If accessory or SaMD: schedule an FDA pre-submission (Q-Sub) meeting to align on pathway before significant development investment.
- Document intended use statement and indications for use — these drive every subsequent design decision.
- Assess whether app will be included in parent device submission or submitted separately.
Phase 2 — Architecture and Design (Weeks 4–10)
- BLE architecture design — device pairing, GATT profile selection, connection management, background sync for both iOS and Android.
- Data model design — what PHI is collected, where it lives, retention periods, access controls.
- UI/UX design — patient-facing and clinician-facing interfaces. Accessibility requirements (Section 508 compliance for any federally funded program). Human factors engineering documentation begins here.
- Security architecture — authentication, encryption, session management, SBOM foundation.
Phase 3 — Development with QMS Documentation (Weeks 10–30)
- Development under ISO 13485-aligned QMS — software development lifecycle documentation is required for all FDA submissions.
- IEC 62304 software lifecycle compliance — risk classification of software units, traceability matrix from requirements to design to test cases.
- Concurrent documentation: Software Requirements Specification (SRS), Software Design Specification (SDS), risk analysis per ISO 14971.
- SBOM generation maintained throughout development — not a post-build artifact.
- Compliance with 21 CFR Part 820 quality system regulation where applicable.
Phase 4 — Verification and Validation (Weeks 28–40)
- Verification testing — unit tests, integration tests, BLE connection stress testing, data integrity validation.
- Validation testing — usability testing with representative users. FDA requires human factors studies for many device categories.
- Penetration testing — required for FDA cybersecurity submission documentation.
- Performance testing — real-device testing on target iOS and Android hardware with target BLE peripherals. Emulators are not sufficient for regulated software.
Phase 5 — FDA Submission and App Store Launch (Weeks 38–52+)
- 510(k) or De Novo preparation — software documentation package including SRS, SDS, hazard analysis, V&V testing summary, SBOM, cybersecurity documentation.
- Apple App Store and Google Play submission — medical device apps require enhanced review. Prepare for a 2–4 week review timeline.
- Post-market surveillance plan — documented process for monitoring adverse events, software anomalies, and cybersecurity vulnerabilities post-launch.
The Complete Companion App Development Checklist for Medical Device Teams
This checklist maps directly to the five-phase development process above. Device product managers and digital health CTOs can use it as a readiness assessment before engaging a development partner or starting an internal build.
Regulatory Readiness
- ☐ Companion app intended use statement documented
- ☐ FDA classification determined: non-device / accessory / standalone SaMD
- ☐ If accessory or SaMD: FDA Q-Sub (pre-submission) meeting completed
- ☐ Device combination product strategy determined if applicable
- ☐ Regulatory counsel engaged
Quality Management System
- ☐ ISO 13485-aligned QMS in place or QMS gap analysis completed
- ☐ IEC 62304 software lifecycle documentation structure established
- ☐ Software Requirements Specification (SRS) drafted
- ☐ Risk management file started (ISO 14971)
- ☐ Traceability matrix: requirements → design → test cases
Technical Architecture
- ☐ BLE GATT profile selected and validated against target hardware
- ☐ Background sync architecture designed for both iOS and Android
- ☐ Offline data buffering implemented
- ☐ HealthKit and Health Connect integration scoped
- ☐ FHIR R4 integration designed if EHR connection required
- ☐ Multi-device management architecture designed if RPM use case
HIPAA & Data Security
- ☐ HIPAA applicability determination documented
- ☐ BAAs executed: cloud provider, analytics, push notifications, EHR integration
- ☐ Encryption at rest and in transit confirmed for all PHI
- ☐ Audit logging implemented
- ☐ Data retention policy documented
- ☐ SBOM generation process established
FDA Cybersecurity
- ☐ SBOM complete and versioned
- ☐ Penetration testing completed
- ☐ Vulnerability disclosure policy documented
- ☐ Post-market patching plan documented
- ☐ Authentication and session management reviewed against OWASP Mobile Top 10
Verification, Validation & Launch
- ☐ BLE connection stress testing completed on physical target devices
- ☐ Human factors usability testing completed with representative users
- ☐ 510(k) or De Novo software documentation package prepared
- ☐ Apple App Store and Google Play medical device category submission prepared
- ☐ Post-market surveillance plan documented and assigned
Need a development partner who understands both the build and the regulatory documentation? Topflight has shipped FDA-ready companion apps for device companies across all four categories above.
Why Choose Topflight Apps for Medical Device Companion App Development
Topflight builds companion apps for medical device companies — including FDA-classified accessories, RPM platforms, and connected device interfaces. We understand the regulatory documentation requirements, not just the software architecture.
- FDA-ready development: QMS-aligned process, IEC 62304 documentation, SBOM generation built into the development lifecycle.
- BLE expertise across CGM, RPM, cardiac, and respiratory device categories — tested on physical hardware, not emulators.
- HIPAA-compliant architecture from day one — BAA management, encryption, audit logging.
- FHIR-based EHR integration for RPM billing workflows and health system partnerships.
- Apple HealthKit and Google Health Connect integration — including enhanced App Store review preparation.
- Human factors and usability testing for FDA submissions.
Tell us about your device and intended use. We’ll scope your companion app and flag the regulatory considerations specific to your category.
What Separates a Compliant Companion App from a Costly Rebuild
A medical device companion app is not a generic mobile app with a Bluetooth connection bolted on. It is a regulated software product that must be built with the same rigor as the hardware it accompanies — documented, validated, and defensible to FDA, patients, and clinicians.
The four categories in this guide — CGM, RPM, cardiac, and smart inhaler — each have distinct regulatory classification risks, BLE architecture requirements, and compliance obligations. Understanding those distinctions before development begins is the difference between a smooth FDA submission and a major redesign mid-clearance.
The development process outlined above, and the checklist, are your starting point. Engage your regulatory strategy before your architecture decisions, and engage your compliance infrastructure before your first patient data flows through the system. Every companion app for medical devices starts with the same question — what does FDA expect from this software? — and the teams that answer it early are the ones that ship.
Frequently Asked Questions
Does a companion app for a medical device need FDA clearance?
It depends on what the app does. An app that simply displays raw device data typically does not require its own clearance. An app that interprets data, provides clinical recommendations, or controls the device is classified as an accessory or SaMD and likely requires 510(k) clearance, De Novo classification, or inclusion in the parent device’s submission.
What is the difference between a medical device companion app and a standalone health app?
A companion app is tethered to a specific hardware device and exists to extend, display, or transmit that device’s data. A standalone health app operates independently using phone sensors or manual input. FDA regulates companion apps based on the device relationship; standalone health and wellness apps may fall outside FDA oversight entirely unless they perform SaMD functions.
How long does it take to build and get FDA clearance for a companion app?
Typical timeline: 9–14 months from regulatory strategy through App Store launch, with significant variation based on device category and FDA pathway. Phase 1 (regulatory strategy) takes 4 weeks minimum. The 510(k) review itself adds 3–6 months. De Novo adds 6–12 months. The most common delay is discovering regulatory requirements mid-development, which forces architecture rework.
What is IEC 62304 and does it apply to my companion app??
IEC 62304 is the international standard for medical device software lifecycle processes. It applies to any software that is part of a medical device or is itself classified as a medical device, including companion apps classified as accessories. It requires documented software development planning, risk classification of software units, and traceability from requirements through verification.
Does a CGM companion app need its own 510(k)?
What BLE protocols do medical device companion apps use?
Most use Bluetooth Low Energy (BLE) with GATT profiles — standardized where available (Glucose, Heart Rate, Blood Pressure) and custom where device-specific data characteristics are needed. BLE GATT is the dominant protocol for short-range device communication. Some cardiac ILR systems use cellular connectivity for continuous cloud upload instead of or in addition to BLE.
What does an SBOM need to include for a medical device companion app?
Per FDA’s 2023 cybersecurity guidance, the SBOM must include all commercial, open-source, and off-the-shelf software components, their version numbers, and known vulnerabilities. This includes platform frameworks, BLE libraries, analytics SDKs, cloud service dependencies, and any third-party modules. It must be maintained and versioned throughout the product lifecycle.
Can I use a third-party CGM API (Dexom, Abbott) in my companion app?
Yes. Dexcom offers a Real-Time API (OAuth 2.0, REST) and Abbott offers the LibreLink Up API. Both enable third-party companion app development. However, using these APIs does not exempt your app from FDA classification review — if your app adds clinical logic on top of the CGM data, the app itself may require regulatory clearance regardless of the data source.
What is the difference between RPM companion app requirements and general mHealth app requirements?
RPM companion apps must support CMS billing compliance (CPT 99453/99454 documentation), multi-device aggregation, EHR integration via FHIR, and care team alerting workflows. General mHealth apps typically lack these enterprise clinical workflow requirements. RPM apps also require BAAs with health system customers as a procurement prerequisite, not just a compliance checkbox.
How do I handle HIPAA compliance for a companion app that works with an implantable cardiac device?
The same HIPAA requirements apply — encryption, BAAs, audit logging, breach notification — but cardiac devices add heightened cybersecurity requirements because of the patient safety implications of unauthorized access. FDA’s cybersecurity guidance explicitly references cardiac device vulnerabilities. Your HIPAA compliance program must be integrated with your FDA cybersecurity submission, not treated as a separate workstream.