Sleep Clinic and DME Software: Where Studies, CPAP Compliance and Resupply Actually Break

Why sleep and CPAP software makes or breaks a multi-site sleep operation

It is 7:10 on a Monday at a four-site sleep group with a DME arm. The compliance coordinator has six things open: ResMed AirView, Philips Care Orchestrator, Brightree, the Epic portal for the hospital that sends half the referrals, a shared Outlook inbox where the fax service dumps PDFs, and a spreadsheet called 90 day tracker FINAL v4. She is looking for patients who hit four hours a night on 70 percent of nights across a consecutive 30-day stretch inside their first 90 days, because that is the CMS PAP coverage rule, and it decides whether months 4 through 13 of a capped rental get paid or clawed back. She checks them one at a time. Serial number, download, eyeball, type, next.

Every piece of software in that stack is good at its job and none of them are doing this job. Polysmith, ProFusion, Noxturnal and Sleepware G3 are scoring platforms, and they score. Brightree, Bonafide, NikoHealth and TIMS are billing and inventory systems, and they bill. AirView and Care Orchestrator are device clouds owned by the manufacturers, and they show you device data. What nobody sells you is the connective tissue: one record of a patient's journey from a referral fax to a scored study to a delivered machine to a compliant user to a resupply annuity that runs for years.

The leak is quiet, which is why it survives. In discovery at one four-site group, we timed the compliance routine at roughly 90 seconds per patient per checkpoint across about 1,400 active PAP patients on 30, 60 and 90 day checks. That is two people, full time, moving numbers between browser tabs, and it still missed the patients who were going to fail, because by the time a human notices a 52 percent adherence rate on day 85 there is nothing left to save.

Problem: the money starts leaking at the referral fax, not at the bed

Sixty referrals a week arrive in four shapes: fax PDFs from primary care and ENT, HL7 orders from the one referrer sharing your hospital's Epic instance, e-prescriptions through Parachute Health, and a cardiologist's office that still calls. A coordinator retypes each into scheduling. Half are missing something that matters later: the Epworth score, the BMI, the face-to-face date, the correct plan ID. Then prior authorization, where most commercial payers now want a home sleep test attempted before an in-lab study. Three weeks pass. The patient no-shows. Nobody knows the referrer sent eleven patients last quarter and eight of them evaporated.

SomnoWare and your EHR both assume the order arrives clean and structured. Neither treats a fax queue as a work queue with an owner, an age and a reason code. And your HST kits, the ApneaLink and WatchPAT and Nox recorders, are tracked on a clipboard: one client was buying about a dozen replacement kits a year for units that were simply never returned, and nobody had noticed.

A custom intake layer ingests all four channels into one order record. AI does one thing here that nothing else in the stack can: document extraction reads the faxed PDF and pulls referrer NPI, ICD-10, Epworth, BMI, neck circumference, face-to-face date and insurance card fields into structured data with a per-field confidence score. Anything below threshold routes to a human review queue instead of failing silently, which is the difference between an AI feature that helps and one that creates a new class of error. Behind it: a payer rule table your billing lead edits without calling a vendor, an SMS self-scheduling link that goes out at 9 pm with the right modality already selected, and every HST kit as a serialized asset with a state machine (in stock, shipped, with patient, overdue, returned, cleaned, downloaded) that texts the patient on day 4 instead of never.

Problem: your compliance data lives in someone else's cloud

A mixed fleet means a mixed portal problem. AirView for ResMed, Care Orchestrator for Philips, iCodeConnect for React Health, Prisma Cloud for Löwenstein. Each one knows what the machine did last night. None of them knows your rental start date, your billing calendar, or which payer's definition of adherence applies to this specific patient. ResMed owns Brightree, so that one pair talks; the moment you have a second brand or want your own rule, you are back in tabs.

The rule is a payer rule, not a device rule, and that is the part off-the-shelf tools cannot model. Medicare wants four hours on 70 percent of nights in a rolling consecutive 30-day window inside the first 90 days, plus a face-to-face re-evaluation between day 31 and day 90. Two of your commercial plans word it differently. A portal that reports usage percentage against a fixed calendar month is answering a question nobody asked.

What a build does: nightly ingest from each vendor API into one compliance ledger, keyed to your patient ID and their therapy day zero, with the therapy night as a first-class versioned record (vendors restate data, and last night's number can change tomorrow). On top of it, a rule engine that models the payer's actual language, including rolling windows and the re-eval due date. Then the thing that changes behavior: a daily exception queue ranked by dollars at risk and days remaining, not alphabetically. And a usage trajectory model trained on your own history, scoring who will miss at day 90 from nights 1 through 14 (session count, mask-off events, leak, residual AHI), so your RT calls the 40 patients who can still be rescued instead of the 400 who are fine.

Problem: resupply is an annuity run on guesswork

Medicare's replacement schedule is public and mechanical: cushions at two per month, mask at one per three months, tubing at one per three months, headgear and non-disposable filters at one per six months. So Brightree's resupply module, or Bonafide, or a call center, works the eligibility calendar and dials. Which is fine, except the calendar does not know that this patient stopped using the machine in month five. You ship the cushions, you bill, the patient disputes the copay, or an auditor asks for the compliance download and there is nothing behind it.

The fix is a three-way gate that no single incumbent can build, because no single incumbent holds all three inputs: the payer's allowable calendar, the last ship date from your billing system, and the last 30 nights of actual usage from the device cloud. Patients under threshold go to a re-engagement track, not a shipping track. Patients above it get an after-hours SMS or voice agent that runs the whole conversation, confirms the mask model and size against the fitting record on file, and drops a confirmed order for a human to release, escalating anything nonstandard. Measure it in confirmed orders per RT hour and in the share of shipments backed by a compliant patient, not in call volume.

Problem: an ADR letter turns into a scavenger hunt

A Targeted Probe and Educate letter lands: 30 claims, 45 days. For each E0601 you need the standard written order, the face-to-face evaluation documenting symptoms, the sleep test report showing criteria met, the proof of delivery with a date and signature, the compliance download covering the qualifying window, and the re-eval note. Those six artifacts live in five systems plus a scanned folder. Your team spends three weeks assembling PDFs, and discovers on claim 19 that the face-to-face note from 2023 never documented daytime somnolence, which is unfixable now and was a two-minute phone call then.

Brightree stores documents. It does not know whether the set is complete, and it certainly does not read the note. Completeness gets checked by a human at audit time, which is exactly the wrong time.

A custom build scores document completeness at the moment of setup. Every required artifact is a typed record with a source system, a date and an owner. The software refuses to generate a delivery ticket without a dated written order preceding it, so order-before-delivery stops being a policy and becomes physics. Extraction reads the face-to-face note against the required elements and flags the gap while the referrer will still take your call. When the letter arrives, the audit packet is one click: 30 indexed PDFs, assembled, with a completeness report you saw months ago.

Problem: nobody can answer "how are the six sites actually doing"

The owner wants four numbers: referral to study conversion by referrer, study to setup by site, setup to compliant by RT, and compliant to resupply-active at month six. Nobody produces them, because Brightree reports on claims, the EHR reports on encounters, AirView reports on devices, and the only way to join them is an Excel export matched on name and date of birth, which is wrong by Tuesday.

The unlock is unglamorous: a canonical patient and episode model where an episode carries referral, study, interpretation, order, setup, compliance window and resupply as timestamped events on one key. Then the questions answer themselves. Which referrers send patients who never convert, and whether the reason is prior auth denial, no-show or no answer. Bed utilization against HST mix, which tells you whether to add a bed or add kits. RT setup capacity against next month's scored-study backlog. And a forecast of month 4 through 13 rental revenue currently at risk from the live compliance cohort, which is the number that should be on the wall.

What it costs and how long it takes

Across 2,000-plus Digital Heroes projects, the pattern in this category is consistent. A focused first release, meaning the compliance ledger, the rule engine for one payer set, read-only ingest from your device clouds and the exception queue, runs $60,000 to $130,000 and ships in 12 to 16 weeks. A full platform covering intake, scheduling, HST kit tracking, resupply gating, audit packets and cross-site reporting runs $150,000 to $400,000, phased across 6 to 12 months.

What pushes you up the band here specifically: the number of device clouds, because each one has its own auth model, data shape and patient matching problem, and the fourth one costs almost as much as the first. Bidirectional writes into Brightree, since reading is cheap and writing is not. An HL7 or FHIR interface into a hospital Epic instance, where the interface engine queue and the hospital IT calendar, not your code, set the schedule. Rule engine breadth, because Medicare only is a fraction of the work of fourteen commercial plans with different adherence definitions. And HIPAA posture done properly: BAAs, audit logging on every PHI read, key management, access review, and a penetration test before go-live. If a hospital partner wants SOC 2 evidence, add three to four weeks. What keeps you in the lower band is starting read-only with one payer rule set and letting the exception queue prove itself before you touch billing writes.

Build versus buy: the honest line

Buy, and do not think twice, if you are a single site with one device brand, a simple payer mix and somewhere under 300 to 400 active PAP patients. Brightree plus AirView plus one disciplined coordinator works at that size, and a custom build will cost more than it returns. Also never build the scoring software. Polysmith, ProFusion and Noxturnal represent decades of signal processing and regulatory clearance, you will not out-build them, and you do not need to.

Build when: you have two or more device clouds; two or more staff exist mainly to move data between systems; you have eaten a recoupment or a TPE and could not explain why; you are acquiring sites and each one arrives with its own portal and its own tribal workflow; or your resupply rules are set by your vendor's calendar and you cannot change them. Here is the position: the mistake we see most is operators deciding the answer is to replace their billing system. Do not. Brightree is fine at claims. Build the layer above it that owns the patient journey, holds the truth about therapy nights and document completeness, and tells your team who to call this morning. That layer is what you actually lack, and it is the cheaper build.

How to choose a developer for sleep clinic and CPAP software

Make them model the domain on a whiteboard before you sign anything. Patient, device serial, rental episode, therapy night, compliance window, payer rule, resupply eligibility. If they draw "patient has many orders" and stop, they are building you a CRM (Customer Relationship Management) with your logo on it. Ask specifically how they version a therapy night when the vendor restates it, and how they handle a patient with two serial numbers and a swapped machine. The answer tells you everything.

Ask what they have actually shipped against a device cloud API. AirView identifiers are not your identifiers, and patient matching across a manufacturer cloud, your billing system and your EHR is the part that quietly consumes a third of the project. Anyone who calls this "just an integration" has not done it.

Treat compliance as engineering, not paperwork. Ask to see how they implement audit logging of PHI access, encryption and key management, and least-privilege roles that differ for an RT, a biller and an owner. Ask whether they run a penetration test before go-live or after the first incident.

Get code ownership in writing and ask about the day ResMed changes their API. The repository sits in your organization from day one, not in the vendor's account. Then ask who monitors the vendor's API changelog, what the response window is, and what it costs. Finally, ask for the name and phone number of the operator, not the executive, who uses the last thing they built. Call at 7 on a Monday morning. That is when this software either works or does not.