Sleep Clinic Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does replacing the billing system get proposed, and why does it sink the project?

The pain is felt at the billing system, so the billing system looks like the problem. A group that is losing rental revenue to compliance failures decides the answer is to replace Brightree, and the project immediately becomes claims, payer plumbing, inventory, remittance posting and a migration of every open rental. Eighteen months and a large budget later the group has rebuilt what it already had, and the compliance coordinator is still working in six browser tabs on a Monday morning.

This happens in sleep specifically because the systems in the stack each do their own job competently and none of them is obviously wrong. Polysmith, ProFusion, Noxturnal and Sleepware G3 score studies. Brightree, Bonafide, NikoHealth and TIMS bill and hold inventory. AirView and Care Orchestrator show what the machine did last night. Nobody is failing. What is missing is the layer above them holding one patient journey from a referral fax to a compliant user to a resupply annuity.

The fix is a boundary written before anyone quotes. The billing system keeps claims, remittance and inventory. The scoring platforms keep signal processing and clearance, which you will not out-build and do not need to. The device clouds keep the raw device record. Your platform owns the patient journey, the therapy night record, the payer rule, document completeness and the exception queue. That layer is a fraction of the cost of a billing replacement and it is where the recovered revenue actually is.

What goes wrong when patients, serials and therapy history are migrated?

Everything joins on the patient, and the patient does not join cleanly. The manufacturer cloud has its own identifiers, the billing system has another, the electronic health record has a third, and the only fields common to all three are name and date of birth, which are exactly the fields that produce false matches on a common surname and miss on a married name change.

Device serials make it worse. A patient issued a replacement machine after a failure now has two serials with two therapy histories, and if the platform treats a serial as the anchor, the compliance window silently restarts. The opposite error is just as bad: a refurbished machine reissued to a different patient carries prior therapy nights that must not follow the hardware.

There is a third trap. Vendors restate device data, so last night's usage figure can change tomorrow. A migration that snapshots history without versioning the therapy night produces numbers that do not reproduce, which is the one property an audit packet cannot afford.

Build a reconciliation phase into the plan rather than assuming a clean import. Match on multiple fields, score confidence, and route low confidence matches to a human queue, because a silent mismatch is worse than a gap. Anchor the record on the rental episode with therapy day zero, and treat serials as equipment assigned to an episode rather than as the patient's identity. Version therapy nights so a restatement is a new version rather than an overwrite. Migrate active patients and open episodes fully and keep closed history in a read only archive, rather than paying to clean data nobody will query.

Why do device cloud and hospital record integrations break after launch?

The device clouds break on authentication and on shape. Each manufacturer has its own authentication model, its own rate limits and its own idea of what a nightly summary contains, and those change without a release note reaching you. The failure mode is quiet: the nightly ingest returns an empty set rather than an error, so the compliance ledger simply shows no data for a cohort and the exception queue looks calm. A patient failing at day fifty two is not flagged because no nights arrived at all.

The hospital interface breaks on process rather than on code. An HL7 or FHIR feed from a referrer's electronic health record sits behind an interface engine, a queue and an information technology change calendar that is not yours. A message type gets modified during their upgrade, and orders stop arriving in the shape you parse. Nobody tells the sleep group because the sleep group is not on their change list.

The fix is the same shape for both. Expect a nightly volume per source and alert when it falls outside the band, so an empty ingest is an incident rather than a quiet Monday. Register each integration credential as an owned asset with an expiry and a named owner. And ask, before signing, who monitors the manufacturers' API changelogs, what the response window is when one changes, and what that support costs. A developer who has no answer has not run one of these past launch.

What happens when document completeness and audit logging are not covered?

A Targeted Probe and Educate letter arrives asking for thirty claims in forty five days. For each positive airway pressure device you need the standard written order, the face to face evaluation documenting symptoms, the sleep test report showing criteria met, proof of delivery with a date and signature, the compliance download covering the qualifying window, and the re-evaluation note. Those artefacts live across five systems and a scanned folder.

The failure is not that documents are missing at audit. It is that nobody checked completeness at setup, when the gap was still fixable. Discovering on claim nineteen that a face to face note never documented daytime somnolence is an unrecoverable finding that was a two minute phone call two years earlier.

The second gap is protected health information handling. Access logging on every read, least privilege roles that genuinely differ for a respiratory therapist, a biller and an owner, key management and a signed business associate agreement are engineering work, not a policy paragraph. Groups that treat this as documentation discover the difference during a hospital partner's security review.

Score completeness at the moment of setup. Make every required artefact a typed record with a source system, a date and an owner, and stop the system from producing a delivery ticket without a dated written order preceding it, so order before delivery becomes a property of the software rather than a policy people remember. Read the face to face note against the required elements and flag the gap while the referrer will still take the call. Then the audit packet is an export with a completeness report you saw months earlier.

Should you build custom or configure what you already own?

Buy, and do not agonise over it, if you are a single site with one device brand, a simple payer mix and somewhere under three to four hundred active positive airway pressure patients. Brightree plus AirView plus one disciplined coordinator works at that size, and a custom build will cost more than it returns. Resupply through Brightree's own module or Bonafide is reasonable when the eligibility calendar is genuinely your constraint.

Never build scoring software. Polysmith, ProFusion and Noxturnal represent decades of signal processing and regulatory clearance and you will not improve on them. SomnoWare is a fair answer if your problem is a clean study workflow at a lab that already receives structured orders on one device brand.

Build when two or more of these hold. You run two or more device clouds. Two or more staff exist mainly to move data between systems. You have absorbed a recoupment or a probe review and could not explain why. You are acquiring sites, each arriving with its own portal and its own undocumented workflow. Or your resupply rules are set by a vendor calendar you cannot change. The mistake to avoid is concluding that this means replacing billing. Build the layer above it.

How do hidden costs get into the quote?

Device cloud count is the first, and it is not linear. Each manufacturer cloud has its own authentication, data shape and patient matching problem, and the fourth costs nearly as much as the first. A quote covering device integration without naming the clouds will be reopened.

Direction of travel is the second. Reading from the billing system is cheap. Writing back into it is a different project with its own testing burden, and quotes routinely price the read and only describe the write.

Payer rule breadth is the third and it is the one that surprises operators. Medicare's four hours on seventy percent of nights across a consecutive thirty day stretch inside the first ninety days is one rule set. Fourteen commercial plans with differently worded adherence definitions and different re-evaluation timing is a materially larger piece of work, and it is where a first release quietly becomes a second phase.

Then the compliance line items. A penetration test before go live, access review tooling, and three to four extra weeks if a hospital partner wants security evidence before connecting. An HL7 or FHIR interface moves at the hospital's calendar rather than yours. And the parallel run, where the coordinator works both the old tabs and the new queue for a few weeks, which is short and is never in a proposal.

What separates a build that works from one that fails here?

Make a prospective developer model the domain on a whiteboard before you sign. Patient, device serial, rental episode, therapy night, compliance window, payer rule, resupply eligibility. If they draw a patient with many orders and stop, they are building a customer database 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 serials after a machine swap. The answer tells you whether they have done this.

Insist that the exception queue is ranked by dollars at risk and days remaining rather than alphabetically. That single design choice is what turns a report into a work list, and it is the difference between a therapist calling the forty patients who can still be rescued and working through four hundred who are mostly fine.

Gate resupply on three inputs, not one. The payer's allowable calendar, the last ship date from billing, and the last thirty nights of actual usage from the device cloud. Shipping on the calendar alone produces billed supplies to patients who stopped therapy in month five, which is a copay dispute at best and an audit finding at worst.

Settle code ownership in writing before kickoff, with the repository in your organisation's account rather than the developer's. At Digital Heroes the client owns the code from the first commit. Then ask for the name and phone number of the operator, not the executive, who uses the last system they built, and call at seven on a Monday morning. That is the hour this software either works or does not.