What It Really Takes to Build a Telehealth App for Pulmonary Care

Konstantin Kalinin

Head of Content

July 28, 2025

Building a telehealth app for pulmonary care? Get ready for a crash course in reality. The path from prototype to revenue is littered with sleek devices, beautiful UIs… and dead startups.

If you’re not solving for reimbursement, distribution, and clinical integration, you’re not building a business—you’re demoing software. This blog unpacks the real lessons from the graveyard and gives you a battle-tested game plan for survival.

Key Takeaways

• B2B2C is the only way out alive. Every D2C pulmonary startup flamed out. Selling through providers and CPT-backed workflows is the only proven path.
• Don’t start with the device—start with reimbursement. RPM codes like 99457 and G0511 are your launchpad. Skip the 16-day trap and get paid early.
• You don’t need a full-stack platform—yet. A compliant MVP + one clinical win + 75 retained patients = enough to close your first real funding round.

Table of Contents

1. The Reimbursement Reality Check
2. Device Integration — What Actually Works
3. The Architecture That Won’t Kill You at Scale
4. FDA Navigation Without the $300K Consultant
5. The Hard Truth Behind Pulmonary Telehealth App Survival
6. Your 90-Day Launch Checklist

The Reimbursement Reality Check

If you’re building a pulmonary telehealth app and think the tech is the hard part—pause. The real question is: Will you get paid? Because until your reimbursement math checks out, everything else is a side quest. That’s the reality of telehealth pulmonary app development.

We’ve dug into 2025’s RPM and virtual pulmonary rehab reimbursement data, denial patterns, and geographic payout quirks. Here’s what your financial roadmap actually looks like.

Pulmonary Conditions That Actually Pay

COPD is the golden child. Medicare reliably reimburses RPM for COPD—especially moderate to very severe cases. CPT codes 99453 (setup), 99454 (device), and 99457/99458 (care management) all apply here.

Asthma and long COVID? Trickier, but still billable if you build your documentation right.

Interstitial lung disease and bronchiectasis? Often left in limbo unless your local Medicare Administrative Contractor (MAC) says otherwise.

Monthly Revenue Per Patient (Medicare, 2025):

• COPD (full RPM suite billed): ~$149.39/month (99453 + 99454 + 99457 + 99458)
• Long COVID or Asthma (partial coverage): Expect ~$91–$100/month depending on adherence and documentation
• Pulmonary Rehab (94625/94626): $58.34 per 60-min session — capped at 2/day, 36 sessions/lifetime unless KX modifier used

But don’t celebrate yet. These numbers are pre-GPCI adjustment, and your actual payout depends heavily on geography (spoiler: San Francisco RPMs make 37% more than rural Alabama RPMs).

The Denial Minefield: Codes Most Likely to Fail

You’d think the CPT codes would be your best friends. Until they ghost your claims.

Top denial triggers:

• CPT 99454: Denied when patients don’t transmit data at least 16 days/month. Miss this, and you’re out ~$43 per patient.
• CPT 99453: Can be billed once per episode of care—but CMS is cagey on what that means. If your patient starts with a pulse ox and later adds a BP cuff, tread carefully unless your documentation defines a new episode .
• CPT 99091: Underused, but high risk. Billable only with 30 minutes of QHCP time and often flagged for unclear documentation.

Also: billing 99453 or 99454 with a date range = instant denial. Use a single date of service, period.

Documentation Mistakes That’ll Get You Audited

CMS audits are no joke—and pulmonary RPM is on their radar (RPM spend ballooned from $15M in 2019 to $300M+ in 2022). Here’s what gets practices in hot water:

• Generic care plans: If your plan doesn’t explicitly say “Notify provider if SpO2 < 89% for 5 min,” it’s not compliant.
• Vague orders: “Monitoring ordered” doesn’t cut it. Auditors want formal, dated prescriptions.
• Missing consent: You need proof the patient understood copays, opt-out rights, and single-provider billing rules.
• Unlicensed staff: Health coaches can’t bill 99457—even if they talk to patients daily.

Pro tip: Build your defense into your EHR. Templated orders + consent scripts + time logs are your audit insurance.

Why Some Practices Make 30–50% More

It’s not always about seeing more patients. The winners:

• Use dual-billing: Combining 99457/99458 with 99091 for QHCP review boosts margins.
• Bill strategically: Align billing cycles (99454 = every 30 days; 99457 = calendar month) to avoid revenue loss.
• Exploit GPCI variance: Practices in San Francisco get $59.56 for 99454 vs. $43.01 in rural Arkansas. That’s a 38% delta for the same patient care.

Also, FQHCs and RHCs can bill G0511 instead—$72.98/month—but can’t double-dip on RTM. Know your billing entity.

Until your CPT strategy is airtight, you don’t have a business model—you have a prototype with a prayer. Start with your financial architecture. Then—and only then—move on to tech and compliance.

Device Integration — What Actually Works

You’ve chosen your spirometer. Great. Now comes the real work: making it behave.

The dream? Plug-and-play data flowing into your mobile app. The reality? A BLE stack from 2019, zero public GitHub repos, and a Bluetooth pairing error that only shows up on Android 12 at 3:07 AM.

Let’s talk about what actually works—and what will wreck your timeline if you don’t plan for it.

SDK Access: Who Plays Nice, Who Ghosts You

Let’s start with the SDKs. Because if your device vendor doesn’t hand you the keys, you’re not driving anywhere.

• MIR (Spirobank): Surprisingly solid. Offers SDKs for iOS, Android, and Windows. Includes GLI multi-ethnic reference sets, quality indicators, and real-time test data. No public GitHub, but at least the docs exist.
• Vitalograph: Also dev-friendly. Real-time streaming, access to error flags (like cough detection or extrapolated volumes), and actual audit trails.
• NuvoAir: Walled garden. Their SDK is internal-use only—unless you’ve got a direct partnership or clinical volume that impresses them, integration is a dead end.

If your product roadmap includes NuvoAir, budget time for negotiations, not just code.

Here’s how the top spirometer vendors stack up at a glance (real-world data, not brochure claims):

Legend: ✅ = good; ⚠️ = inconsistent; ❌ = not available

Android BLE: The Graveyard of Dreams

Everyone hates Android BLE. And for good reason.

• Status 133 (GATT_ERROR) is the Voldemort of BLE bugs—common, fatal, and basically undocumented.
• Android 12+ replaced location permission with BLUETOOTH_SCAN and BLUETOOTH_CONNECT, but the real fix? Set neverForLocation = true or your app will still prompt users for their location to connect a spirometer.
• Maximum scan limit? Five per 30 seconds. Exceed it and your app silently fails. Enjoy debugging that on a Xiaomi phone with a custom BLE stack.

Also Read: A Guide to BLE App Development

If you’re building for Android, you need a retry queue, serial BLE command buffer, and a very patient QA team.

iOS: Clean API, Subtle Landmines

iOS CoreBluetooth is more stable—but not stress-free.

• All BLE calls must run on the main thread. Miss this and your app silently crashes in production.
• Background BLE? Notoriously finicky. You’ll need to configure your Info.plist with the right background modes and aggressively manage power usage or risk disconnects mid-test.
• Threading bugs are easy to introduce, hard to catch. Use serial queues. Always.

That said, if you can keep the user in-app during testing, iOS is less chaotic than Android overall.

The Battery Problem

The spirometer isn’t the only thing draining. BLE scanning can eat 1,000 mAh in hours on a phone—especially in SCAN_MODE_LOW_LATENCY.

On the device side:

• MIR warns that weak AAA batteries cause mid-test disconnects.
• Vitalograph is only stable if voltage stays above 2.4V.
• None of the major brands let you manage power state programmatically. Forget about sleep/wake APIs.

Smart mitigation:

• Use SCAN_MODE_BALANCED where possible.
• Auto-detect battery state and flag users when the signal gets flaky.
• Never trust users to replace their batteries on time. Ever.

Integration Timelines: Best Case vs Real Life

Best case (ideal setup, no BLE bugs):

• MIR: ~3–4 weeks for basic data flow; another 2 for quality metrics
• Vitalograph: ~4–6 weeks if you use their streaming mode; longer if you’re adding FEV1/FVC logic
• NuvoAir: Not applicable without a business contract

Actual timeline if Android is in scope:

Double it. And throw in another 2–3 weeks for weird firmware issues like:

• Devices dropping when switching to test mode
• Pairing issues caused by low proximity or sleep state
• BLE UUIDs not matching the docs (yes, this still happens)

Why 60% of Patients Stop Syncing by Week 3

Three words: BLE Friction Fatigue.

• Android users get location prompts they don’t understand.
• Battery dies mid-test and they think the app is broken.
• Devices don’t auto-reconnect, and there’s no retry logic in the app.

This is where Cohero Health fell apart. Despite FDA clearance and working hardware, they couldn’t get enough patients to stick with regular spirometry. Most never made it past the second week .

Wellinks and Spire learned the lesson: combine always-on devices with coaching or clinical oversight—or lose your users entirely.

Checklist for Your Dev Team: Patient-Side Stability

Here’s what actually prevents support tickets, sync failures, and user churn in the field:

🔌 BLE Connection & Pairing

• ☐ Retry queue for Status 133 and scan timeout
• ☐ Android: implement BLUETOOTH_SCAN + neverForLocation
• ☐ iOS: ensure CoreBluetooth runs on main thread

🔋 Battery Optimization

• ☐ Use SCAN_MODE_BALANCED not LOW_LATENCY
• ☐ Warn users on low signal (voltage drops = disconnects)
• ☐ Auto-log disconnects for support debugging

📱 UX & Support-Readiness

• ☐ Device setup wizard with permission walk-through (esp. Android)
• ☐ “Test your connection” screen built in
• ☐ Auto-reconnect after sleep/bluetooth toggle
• ☐ Support dashboard with device state + logs

📊 Data Integrity

• ☐ Fallback alert when data stream halts mid-test
• ☐ Sync retries w/ exponential backoff
• ☐ Display last sync timestamp in user-visible UI

Next up: we leave the BLE jungle and look at how to build an architecture that won’t fall apart the moment your app hits 1,000 active patients.

The Architecture That Won’t Kill You at Scale

You can build a beautiful pulmonary telehealth app. But if your architecture crumbles the moment 1,000 patients sync at once, congratulations—you’ve built a stress test, not a platform.

Here’s how to architect like someone who’s already lived through the pager storms, 3G dead zones, and SQS queues longer than the Mississippi.

Offline-First or Die Trying

Let’s start with the most overlooked killer: rural bandwidth.

COPD patients over 60 in West Virginia aren’t on Wi-Fi. You’ll see bursts of 3G, maybe LTE if the wind blows right. That means:

• Cache everything. Local-first, async sync later.
• Use SQLite or RoomDB for data persistence. It’s not sexy, but it’s resilient.
• Retry queues should back off exponentially, and yes, you need a “sync now” panic button for support calls.

A good offline-first design doesn’t mean “offline mode.” It means your app just works—even when the cloud’s 2 hours away.

Alert Systems That Don’t Break Providers

Alert fatigue is real. And fatal to adoption. Don’t let your backend fire off push alerts every time a pulse ox reads 89%. Providers want actionable, not anxious.

Here’s the pattern that works:

• Use cloud functions (e.g., AWS Lambda) to process streaming vitals in near-real-time.
• Pipe anomalies into Amazon SQS or Azure Queue Storage.
• Create a daily digest (per patient) unless the alert is tagged critical (e.g., SpO2 < 85% for 5+ minutes = immediate).

What counts as critical?

Use a rolling threshold model:

• 3 anomalies in 24 hours = elevate
• 1 anomaly per week = defer

This logic cuts false positive alerts by ~70% based on our internal dashboards.

Your Real AWS Bill (Spoiler: It’s Not Just EC2)

At ~5,000 patients actively uploading vitals + spirometry 2–3x/day, here’s what your monthly AWS bill looks like:

That’s before you add AppSync, Cognito, or FHIR translation services.

Pro tip: log less. If you’re storing all BLE handshake logs, you’ll burn $200+ just in CloudWatch charges.

Architecture That Scales (Without Burning Out Your Team)

A proven pattern looks something like this:

• Frontend: React Native with local SQLite layer, BLE integration via native modules
• Middleware: GraphQL via AWS AppSync or Apollo, with retry logic baked in
• Backend: Lambda + SQS + DynamoDB (or Postgres if you need relational queries)
• Alert Logic: Event-driven, backed by rules engine or plain Python jobs

You don’t need Kubernetes. You need observability. Start with:

• Sentry (for app crashes)
• Datadog or New Relic (for server-side traces)
• Grafana + Prometheus if you’re hosting custom nodes

And set up health checks on BLE event ingestion. Your device team won’t tell you when the firmware breaks packet formatting.

FHIR Prep (So Year-2 You Doesn’t Hate You)

Ignore FHIR now, and you’ll pay for it when you try to onboard your first enterprise pilot. The only resources that matter early on:

• Observation (SpO2, FEV1, etc.)
• Device (UDI, make/model)
• Patient (obviously)
• CarePlan if you’re pushing protocols back to the app

Related: A Guide to FHIR integration in healthcare

Map your internal data models to FHIR now—even if you don’t expose them yet. Otherwise, translating a year’s worth of spaghetti into R4 will feel like dental work with a Dremel.

Your infrastructure’s humming, alerts aren’t drowning providers, and sync retries finally behave in rural dead zones. But just when the tech calms down… the regulatory maze begins.

Next up: how to face the FDA without burning half your runway—or hiring a $300K consultant who still can’t tell you what class your app is.

FDA Navigation Without the $300K Consultant

So you googled “FDA 510(k) submission” and landed on a consultant’s site quoting $300K+ just to hold your hand. Breathe. That price tag might be real—for a Class III device claiming to cure COPD while baking banana bread.

But for most telehealth apps in the pulmonary space? You can absolutely navigate the FDA gauntlet yourself—if you know what features don’t trigger scrutiny and how to walk the predicate path smartly.

Class I, Class II, Class Uh-Oh

Let’s start with classification. If your app only logs symptoms or tracks medication usage without controlling a connected device, you’re likely Class I or even Class II exempt. That means no premarket review, just good manufacturing practices and proper labeling.

But the second you start:

• Driving therapy (e.g., controlling inhaler dosage),
• Making diagnostic claims (e.g., “detects asthma exacerbation”), or
• Integrating with Class IIb/III hardware (think implanted neuromodulators, or automated oxygen delivery),

you’ve entered Class II/III territory, and the FDA wants a conversation. The line between “remote monitoring” and “clinical decision support” is razor-thin—and that line determines whether you need a full 510(k), de novo, or worse, PMA.

Example: Spry Health’s Loop wearable got 510(k) clearance for continuous SpO₂ monitoring in COPD patients, but never claimed diagnostic utility. The moment you say “predicts deterioration” or “alerts doctors to intervene,” you’re on the hook for much deeper validation .

Your Best Friend: The Predicate Path

Let’s talk strategy. The fastest way through 510(k) is to piggyback on a predicate device—something already cleared that’s “substantially equivalent” to your app or system.

For pulmonary platforms, solid predicate paths include:

• Cohero Health’s mSpirometer (510(k) K151043) – smartphone-connected spirometry
• NuvoAir Air Next (K202344, enhanced in 2024) – home-use spirometry with ATS 2019 compliance
• Propeller Health’s sensor suite (multiple 510(k) clearances) – medication adherence tracking via smart inhalers

These set precedent for:

• Home-use Bluetooth spirometry,
• Integration with apps,
• Cloud dashboards without crossing into Class III claims.

If you’re building a platform with remote spirometry, check how closely your spirometer aligns with NuvoAir’s 2024 clearance or MIR Spirobank’s specs. Use their documentation as your benchmark and, ideally, your predicate. Don’t DIY unless your device is truly novel—it’ll trigger more scrutiny than it’s worth.

The Red Flags That Get You Rejected

Founders love to brag about “AI insights” and “predictive analytics.” The FDA doesn’t.

Top reasons pulmonary telehealth apps get rejected or downgraded:

• Vague clinical claims (e.g., “improves outcomes” without evidence)
• Non-equivalence to predicate (even small UI/UX differences in test procedures can derail your submission)
• Unvalidated Bluetooth integration (especially with closed ecosystems like NuvoAir, which doesn’t provide public SDKs)
• Battery issues causing test instability (yep, the FDA has flagged connection dropouts caused by weak AAA batteries)

One overlooked issue: apps that rely on real-time BLE readings without handling connection drops or failed spirometry sessions gracefully. FDA reviewers will test edge cases, including flaky Android BLE behavior. Get ahead of this by showing robust reconnection logic and error handling.

eSTAR, Not eStress

Since late 2023, FDA mandates eSTAR for most 510(k) submissions—a structured electronic format. It’s basically a glorified PDF wizard, but if you haven’t used it before, it will eat a week of your time. The good news? The built-in validation flags many submission issues before they reach the reviewer’s desk.

Hot tip: If your app includes a mobile SDK or is device-agnostic, submit your software documentation as a “Device Accessory” and clarify data flow in the system diagram. That heads off the dreaded “Please clarify intended use” emails that delay reviews by 2–3 weeks.

Real Timelines and Hidden Costs

Let’s debunk the timeline myths. The median 510(k) review takes 150–180 calendar days from submission to clearance—assuming no Additional Information (AI) requests. Plan for:

• 2–3 months prep (testing, documentation)
• 1–2 months back-and-forth post-submission
• 1–2 months for labeling, final QA, and launch readiness

And cost-wise?

• DIY prep with in-house regulatory help: $50–75K (mostly time + testing)
• Mid-tier consultant (1–2 devices): $120–150K
• Big-name firm handling full stack: $275–350K

If your platform hinges on just one device integration (e.g. a spirometer + app), you can do it in-house with the right playbook and testing partner.

Want to Save $200K? Book the Free Q-Sub

Before you commit to a full submission, use the FDA’s Q-Sub (Pre-Sub) pathway. It’s a free, no-penalty meeting to validate your classification and predicate strategy.

Do:

• Bring a visual of your data flow (device ↔ app ↔ cloud)
• Outline what predicate(s) you’re referencing
• Ask clearly: “Do you agree this qualifies as Class II with [predicate device]?”
• Include your draft intended use statement—this is where most misfires happen

Don’t:

• Ask about business strategy
• Use vague AI buzzwords
• Leave your Bluetooth integration unmentioned—FDA reviewers love digging into wireless connectivity and cybersecurity

TL;DR for the founder with sticker shock: You don’t need a $300K FDA whisperer to ship your app—but you do need to respect what trips others up. Stick to the predicate path, test your integrations like your business depends on it (because it does), and ask the FDA for clarity early. This isn’t a mystery cult—it’s a process. And you can absolutely beat it.

Next up: what TytoCare, Propeller, and Cohero Health can teach you about survival—beyond the paperwork.

The Hard Truth Behind Pulmonary Telehealth App Survival

Let’s drop the romance: digital pulmonary care is a hard market. Startups enter with strong tech, slick UX, and good intentions—but unless they crack distribution, reimbursement, and real clinical value, they’re just another pilot on someone’s shelf.

Yes, a few players made it out, for example Propeller, Wellinks, and Spire. But look closer: most only survived by radically rethinking their model or getting scooped up by larger players with deeper pockets and distribution channels.

This section isn’t about throwing shade—it’s a pattern-matching exercise. If you’re building in this space, learn from these wins and wipeouts before you become one.

Legend: Success Stories / Cautionary Tales / Mixed Results

1. Propeller Health: A $225M Exit With Strings Attached

Propeller’s smart inhaler sensors, backed by pharma studies and FDA clearance, were a rare combo: clinically validated and payer-aligned. But even with all that, they needed ResMed’s reach to survive. Why? Provider integration dragged. Pharma partners were cautious. The direct-to-consumer dream fizzled.

• Founded: 2010
• Acquired by ResMed: $225M in 2018
• Team: 65+ commercial programs pre-acquisition
• Notable Wins: 9 FDA clearances, 58% med adherence bump, 53% fewer ER visits

Lesson: Strong data and good tech still need massive distribution. B2B2C beat D2C—again.

2. Cohero Health: The Pilot Trap

Cohero had Bluetooth spirometers and a slick adherence platform, but never landed a big fish. No major pharma deal. No payer adoption. After years of pilots that went nowhere, they sold for $2.4M—a rounding error compared to the $12M+ they raised.

• Founded: 2013
• Acquired by Aptar: 2020
• Backers: Samsung, Omron
• Staff at time of sale: Skeleton crew

Lesson: Pilots ≠ product-market fit. If you can’t scale the business model, your tech is just a demo.

3. MySpiroo (AioCare): FDA-Grade, Consumer-Grade Mistake

Poland-based MySpiroo burned through $8M trying to sell diagnostic-grade spirometers directly to consumers. The market didn’t bite. They pivoted into provider-focused sales under the AioCare brand and finally got some traction.

• Raised: ~$8M (estimate from EU/US grant + VC sources)
• FDA + CE Certified: Yes
• Original Play: Direct-to-consumer smart spirometer
• Pivot: Rebranded to AioCare and moved B2B by 2018

Lesson: Patients don’t buy medical-grade devices without a prescription—or a reason. D2C is a myth in regulated care.

4. Spry Health: When Timing Almost Saves You

Spry had a wearable that continuously monitored vitals for COPD. Then COVID hit. Suddenly, their remote tech was hot. They got scooped up by Itamar Medical. Not because their RPM model worked—but because the tech could pivot into sleep apnea care.

• Founded: 2014
• Acquired by Itamar: 2021 (undisclosed sum)
• FDA Clearance: Loop system (2019)
• COVID Pivot: “Loop Signal” for home monitoring of mild COVID cases

Lesson: Tech alone won’t save you. Timing + repurposing will.

5. Wellinks: Pivoted to Platform—and Won

Wellinks started with a smart compression vest. It didn’t sell. But instead of folding, they evolved into a full-stack COPD care platform—RPM, nurse coaching, digital spirometry, the works. Suddenly, they weren’t a gadget company. They were care delivery with reimbursement.

• Founded: 2013
• Raised: $25M Series C (2021)
• Pivot: 2020–2021, into end-to-end COPD care model
• Core Offerings: Bluetooth spirometer, oximeter, app, health coaching, tele-pulmonary rehab

Lesson: Investors don’t want sensors. They want sustainable care models with CPT code alignment.

6. HGE Health: From Research Pilot to $26M Acquisition

HGE Health turned a simple COPD symptom questionnaire into a remote monitoring tool used by 100K+ patients. But scaling a software-only telehealth service in a reimbursement minefield? That’s where things got hazy. Vapotherm acquired them in 2020 for ~$19–26M—just enough to suggest “not a failure,” but not quite a win either.

• Founded: 2015 (spinout from Temple University research)
• Acquired by Vapotherm: 2020 for $19–26M (upfront + earn-out)
• Footprint: 100K+ COPD patients on platform pre-acquisition

Lesson: Software-only RPM rarely scales. Without a physical device or care service, you’re just another portal providers don’t log into.

7. Spire Health: The Sensor That Finally Got Worn

Spire’s breathable sensor patch nailed the hardest part of RPM—patient adherence. It stuck to your underwear and never needed charging. Elegant, invisible, and accurate. So why the merger with Wellinks in 2024? Because even the best sensor is a tree falling in the woods without distribution, billing codes, or a care team to act on its alerts.

• Founded: ~2014 (pivoted to healthcare by 2018)
• Merged with Wellinks: 2024, stock-based transaction
• Outcome Data: ~45–65% reduction in COPD hospitalizations in pilots

Lesson: Build the world’s best sensor, and you still need someone to staff the dashboard. Tech needs services—or a partner who has them.

The Business Model Trap: Why B2B2C Beats D2C Every Time

Across the board, these startups learned the hard way: direct-to-consumer models almost never work in pulmonary care. The patient may have the problem, but the system holds the purse strings. Reimbursement for spirometry, RPM, or connected devices is still gated by provider workflows and CMS billing codes. You either:

• Sell to health systems or payers (B2B), or
• Build a platform that providers use with patients (B2B2C)

Startups that ignored this—Cohero, MySpiroo—got punished. Those that adapted—Propeller, later-stage Wellinks, and Spire Health—found buyers or new life.

Repeated Mistakes:

• Banking on viral consumer adoption
• Treating CPT reimbursement as a “later problem”
• Launching hardware without a full clinical service model
• Underestimating the integration lift (EHR, care teams, coaching)

If there’s one theme across every pulmonary flameout, it’s this: founders assumed a good device + sleek app = adoption. In reality, nothing moves in pulmonary care without:

• Reimbursement
• Provider buy-in
• And a model that doesn’t rely on patients buying tech out-of-pocket

B2B2C (selling through clinics and care programs) consistently outperformed D2C. And pilots without a pathway to contracts? They drain teams, cap valuations, and delay hard decisions.

Bottom line: A good device and clean UX might land you TechCrunch coverage—but unless you solve for reimbursement, care delivery, and provider workflows, you’re not in the pulmonary care business. You’re just demoing software.

That’s why B2B2C wins. That’s why direct-to-consumer fails. And that’s why every investor in this space is now asking: how fast can you prove CPT-backed revenue?

Next, we’ll show you how to actually get to market—without wasting the next 18 months on the wrong playbook.

Your 90-Day Launch Checklist

Let’s say you’ve got funding, a deck, maybe even a prototype—and your investors want to see “real traction” by next quarter. This is where you stop planning and start proving.

What follows is a 90-day launch plan that’s actually fundable: tight, scrappy, and optimized to get CPT-backed revenue flowing before the next partner meeting.

Phase 1: Build the Foundation (Weeks 1–4)

Lock in FQHC/RHC pilot partners

Federally Qualified Health Centers (FQHCs) and Rural Health Clinics (RHCs) can bill G0511 immediately at $72.98/patient/month. That’s ~20% more than standard RPM codes, with less red tape. Start here.

Pro tip: Get the established patient requirement waiver in writing. Otherwise you’re dead in the water for new enrollments.

Cut MVP scope to barebones

You don’t need a full dashboard suite. Start with:

• Simple SMS check-ins (WelTel proved 70-75% retention with just texts)
• Manual vitals input (pulse ox readings, not synced… yet)
• Secure message threads for provider check-ins

Also Read: A Guide to Healthcare App Development

Build billing-proof documentation

Templates matter more than features at this stage:

• Patient consent scripts that mention copays and opt-out rights (auditors check)
• Provider order forms that look like prescriptions (not EMR notes)
• 30-day billing cycle alignment protocols
• Audit indemnification clause if devices aren’t FDA-cleared yet

Consider remote staffing in high-GPCI areas—San Francisco literally pays 37% more than Alabama for the same CPT codes. Geography is margin.

You’re not aiming for elegance—you’re aiming for the first reimbursable claim.

Phase 2: First Patients, First Revenue (Weeks 5–8)

Start with 99457 (skip the 16-day trap)

This code reimburses $47.87/month for 20 minutes of provider review. One phone call gets you paid. No device syncing required.

Even better: Dual-bill 99457 + 99091 for complex patients ($100.58 combined). Nurses handle the routine 20-minute check-ins while your pulmonologist bills 30 minutes for data review. Same patient, double revenue.

Accept drop-off—build for resilience

Plan for 25–30% patient attrition out of the gate. That means onboarding ~30 to retain 20+. If you’re hitting 70-75% retention (WelTel’s benchmark), you’re actually doing great. Below 70%? Your engagement model needs work.

First revenue proof point

You should be seeing $1,200–$1,400 in MRR by the end of this sprint. That’s enough to prove the engine works—now you just need to pour fuel into it.

Phase 3: Scale Signals (Weeks 9–12)

Ramp to 75–100 active patients

This is the benchmark most VCs use to sniff out PMF. Not downloads—retained patients billing monthly.

Show ONE clinical win

Pick your victory:

• 6-13 point CAT score improvement in COPD patients (that’s the clinically meaningful threshold)
• 97% attendance for virtual pulmonary rehab sessions
• 70%+ month-2 retention when industry average is 50%

You need one defensible outcome story. Just one.

Pilot contract optimization

By now, you’ll know which partners are leaning in. Clean up those contracts to include:

• Clear audit protection language (you handle tech, they handle clinical)
• Expansion triggers (auto-add patients when you prove >50 active)
• Geographic exclusivity within their health system

What Actually Moves the Needle

Prioritize these partnerships:

• FQHCs and RHCs (G0511 = highest reimbursement)
• Pulmonary practices already billing RPM (infrastructure exists)
• Health systems with 500+ monthly COPD patients (volume play)

Track these KPIs (VCs sure do):

• 🟢 Revenue/patient/month: $45–75 realistic (mix of 99457 and G0511)
• 🟢 Patient acquisition cost: <$50 via clinic partnerships
• 🟢 Monthly churn: <30% or you’re hemorrhaging
• 🟢 Time to first claim paid: <45 days shows you can operate

What NOT to Do (Learn from the Graveyard)

• Don’t chase Cigna—they only cover COPD with strict criteria
• Don’t build for 99454 (device data) until you’ve mastered 99457
• Don’t promise spirometer Bluetooth sync in V1—that killed Cohero
• Don’t go D2C—every dead pulmonary startup tried it

TL;DR: The Launch Triangle

You can launch fast, cheap, or scalable. You get two:

• Fast + Cheap: Start with 99457 + SMS. Just get paid.
• Fast + Scalable: Partner with FQHCs. They’ve got volume and billing teams.
• Cheap + Scalable: Build a white-label backend and let clinics run their own ops. But you’ll move slower.

Pick your two—and start building.