Wound Care Practice Software: Revenue Cycle Case Study

Client: a US wound care provider group. Status: live in production. Our role: we designed and built the platform, web and mobile.

The group was good at healing wounds and was losing money on the billing. We built one system that follows a wound care visit from the assessment to the claim. Coverage is checked before the patient is seen, the insurer's benefit response is read into plain terms, and every claim is checked before it is sent, with a suggested fix for each problem.

The situation: claims lost between the visit and the payment

Wound care coding is detailed. The claim depends on the wound type, its location, its size and stage, and the procedures and supplies used, and the notes that justify payment have to match. Any gap between what was done and how it was coded can turn into a denial. Some visits also went ahead for patients whose coverage did not apply.

The people running the practice are clinicians. Decoding an insurer's benefit response is not their job. Before this project, care was delivered, a claim went out, and the practice found out weeks later whether a coding slip or a coverage gap had cost them the payment. Each loss was small. Across a busy practice they added up.

We expected the problem to sit in the claim itself: codes, modifiers and the checks before submission. Time with the front desk showed us an earlier leak. Insurers answer an eligibility check with a dense block of coverage codes and qualifiers, and a misread copay, deductible or limit sets up a denial before the patient is even seen. So we treated the benefit response as a problem of its own. That is how we start most custom healthcare software development work: watch the people doing the job before deciding what to build.

What we built

One platform covers the visit from start to finish. The web app serves the front desk and billing team, and a mobile app serves clinicians. Both use the same API and the same records.

Wound assessments built for the claim

The clinician records each wound in set fields: location on a body diagram, type and classification, stage, length, width and depth in centimeters, tunneling and undermining, tissue type, and healing and prognosis notes. Risk scores such as Braden and ABI readings sit in the same form. Before and after photos are attached to the wound record.

The photos are stored, not analysed. The software does not measure wounds from images or predict healing. The clinician measures, and the structured fields carry that measurement into the claim.

Eligibility before the visit

Coverage is checked through the practice's clearinghouse before the appointment. If the plan does not cover the visit, the front desk sees it while there is still time to collect new plan details or agree on self-pay.

Benefits read into plain terms

An AI model reads the insurer's eligibility response and pulls out the copay, deductible, coinsurance, out-of-pocket amounts and plan dates. It also returns a confidence level. The billing team sees plain fields, with the raw response one click away, and anything the model is unsure of goes to a person to check. The AI does this one narrow job. Coding and claim decisions stay with rules and people. Our healthcare AI solutions follow the same pattern: a small, checkable task with a person signing off.

Claim checks before submission

Every claim runs 11 checks before it leaves the practice: required fields, patient details, service dates and timely filing, procedure codes, diagnosis codes, modifiers, prior authorization status and units, code pairs that cannot be billed together, place of service, billing provider details, and amounts that look wrong. Each problem comes back as an error, a warning or a note, with a suggested fix. Errors hold the claim until they are fixed. Warnings let a person decide.

The rest of the revenue cycle

Around those three pieces sit the screens a billing team uses every day: prior authorizations, CMS-1500 claims, remittances, denials, A/R aging, a work queue, scheduling and a supplies inventory. Together they make a revenue cycle management system built around how a wound care practice bills.

How it works

The web and mobile apps share one API. When the front desk checks coverage, the eligibility service sends the request to the clearinghouse and passes the response to the AI benefit reader. When a claim is ready, the claim checker runs before anything is submitted, and rejections and denials that come back land in a work queue. The clearinghouse connection is the healthcare interoperability part of the build.

The web app is built with Next.js, the mobile app with React Native (Expo), and the API with Node.js and Express on MongoDB. Benefit reading uses an OpenAI model.

What is live, and what is next

The platform is live in production with the provider group: wound assessments, eligibility checks, benefit reading and claim checks, on web and mobile.

One check is not finished. The code-pair check starts from a short list of pairs, with wound debridement codes among them. The next step is loading the full federal list of these pairs, the NCCI edits, so the check covers every code the practice bills. We plan releases the same way in our healthcare software product development work, with the next step written down before the current one ships.

What we learned

• The first leak sits before the visit. We came in focused on clean claims. Misread benefit responses were setting up denials before care began. Fixing eligibility first made the claim checks matter more.
• Structured wound data does the billing work. When size, depth, stage and location are set fields, the claim can be checked against them. Free text cannot be checked.
• Let clinicians stay clinical. The system carries the coding and coverage detail, so the people healing wounds are not asked to become billing experts.
• Use AI where the reading is hardest. Turning a dense insurer response into plain fields a person can check is a good fit. Deciding how to code a claim is not.

Running a specialty practice that loses money on billing?

If claims leak between the visit and the payment, we can look at your workflow and tell you where the money goes and what it would take to stop it. Read about our revenue cycle management software development and custom EHR development services, see what a build typically costs in our custom EHR development cost guide, or talk to us about your practice.