How to Build an O&P Practice Management System

Before a single claim goes out for one Medicare above-knee prosthesis, the chart already has to carry a physician face-to-face exam with a K-level assessment, a Standard Written Order with diagnosis and functional level, a clinical justification letter, prior authorization from the patient’s DME MAC for the high-cost L-codes, fabrication tracked from prescription to delivery, and a signed delivery record. Then the claim itself needs the correct HCPCS L-code, a first-position modifier, and LCD-compliant medical-necessity documentation.

Generic O&P practice management software doesn’t run that workflow. Practices on OPIE, Futura, or a modified DME billing system carry most of it by hand, and the ones we’ve seen try a generic EHR found the clinical documentation model just doesn’t fit.

Five things make O&P its own software domain: L-code billing with device-specific modifier logic, K-level functional documentation, prior auth for custom and high-cost devices, fabrication lifecycle tracking, and ABC/BOC accreditation compliance.

It’s a market worth building for: multibillion-dollar in the US across roughly 6,000 patient-care facilities, and consolidating fast under a handful of big players. Hanger keeps buying up clinics and component makers (Fillauer in early 2024, Point Designs in 2025) while Össur rebrands to Embla Medical and Ottobock moves into neural-interface startups. Independents are still most of the locations, and most of them are underserved.

How do you build an O&P practice management system?

Build the modules general-purpose practice software skips: O&P billing software with HCPCS L-codes and first-position modifier logic, K-level functional documentation, multi-payer prior authorization, fabrication lifecycle tracking, and accreditation compliance for annual unannounced surveys. The billing risk concentrates around the KX/WOPD documentation gate. The system should block claim submission until the physician exam, written order, and clinical notes are present and dated, because missing pre-delivery documentation usually can’t be repaired after the device is delivered.

Key Takeaways:

1. Make the KX documentation gate an active block on claim submission. It’s the single highest billing risk in O&P, and with orthotics improper-payment rates between 35% and 54%, the gate should hold a claim until the physician exam, written order, and clinical notes are on file.
2. Fabrication lifecycle tracking is the workflow that most sets O&P apart, so tie every stage to its clock. Bind each fabrication stage to its documentation and to the prior-auth and coverage windows, so the system flags a device about to age out before it becomes a denial.
3. Build the accreditation module for continuous, year-round readiness. As of 2026, DMEPOS surveys are annual and unannounced, so credentials, complaint logs, policies, and outcomes have to stay survey-ready every day, because the prep window is gone.

Table of Contents

1. Core modules an O&P practice management system can’t skip
2. L-code billing is the technical core of O&P claims
3. Prior authorization in O&P needs its own workflow engine
4. Fabrication lifecycle tracking is the workflow that sets O&P apart
5. Accreditation compliance after the 2026 annual-survey rule
6. EHR and clearinghouse integration: why redundancy is not optional
7. The HIPAA risks unique to O&P: device photos and fab-lab data
8. Build, configure, or adopt: the real O&P software decision
9. Why choose Topflight Apps for O&P practice management development

Core modules an O&P practice management system can’t skip

Spelled out as a module list, orthotics and prosthetics practice management reads like any other practice management platform: patient management, clinical documentation, billing, scheduling, reporting. The difference is what each module has to do. Inside every one sits an O&P-specific requirement that a generic platform, or off-the-shelf medical device integration software, was never built for.

Four modules carry the real complexity: L-code billing, prior auth, fabrication tracking, and accreditation. We break each of those out below. Here’s the full map, the starting point for any team or healthcare app developers scoping the build.

L-code billing is the technical core of O&P claims

HCPCS L-codes are the billing language of O&P, and the claim lives or dies on them. O&P billing software has two jobs a CPT-centric billing engine doesn’t: keep the L-code logic correct, and refuse to submit a claim until the documentation behind it actually exists. The second job protects the claim.

What the L-code engine has to handle

These are durable medical equipment (DME) claims, billed on several thousand Level II L-codes, and the engine has to keep that library honest:

• current codes with effective and deletion dates, since CMS reshuffles them yearly, so you’re never billing one that no longer exists;
• combination rules, because some L-codes can’t go on the same claim, and a prefabricated orthosis and its custom-made equivalent never share one;
• a signed delivery receipt on file, which Medicare treats as a condition of payment for many devices.

Then the modifiers. A 2024 rule change means prosthetic L-codes now reject unless a KX, GA, GY, or GZ modifier sits in the first position, the same rule orthotic L-codes (think AFOs and knee braces) already lived under. Two modifier codes carry the weight: the KX modifier says the medical-necessity documentation the local coverage determination (LCD) requires is on file, and the GA modifier flags a service you expect Medicare to deny.

One more wrinkle: coverage rules vary by the patient’s Medicare Administrative Contractor (MAC), so the same L-code can demand different documentation from one region to the next. The system routes its compliance checks by jurisdiction instead of applying one national rule.

The KX documentation gate: the highest billing risk you build

This is where the billing module has to stop acting like a checklist and start acting like a claims lock.

Here’s the rule that forces the design. The written order has to exist before device delivery. Deliver first and Medicare can deny the claim, and getting the paperwork afterward won’t save it. A passive checkbox that says “documentation on file” just hides the problem until an audit finds it.

The safer design blocks submission until the actual documents are uploaded and dated: the physician face-to-face exam, the Standard Written Order, and clinical notes that support the patient’s functional level, including the K-level functional classification from K0 through K4.

The numbers are why this is worth real engineering. DMEPOS improper payments ran 21.4% in FY2024 and 24.1% the next year; orthotics specifically run between 35% and 54%, against a Medicare fee-for-service average near 7.66%. It’s almost entirely documentation-driven. O&P’s L-code billing runs several times the program-wide rate, and an active gate is the most direct thing software can do about it.

Prior authorization in O&P needs its own workflow engine

O&P prior authorization deserves its own workflow because of one ugly fact: the device usually has to be built, or at least started, before the approval comes back. Prosthetics practice management software has to handle two different PA worlds and keep the cost of starting early in plain sight.

Two PA tracks the software runs at once

Medicare fee-for-service. High-cost Medicare Part B prosthetics like microprocessor knees do require prior authorization, and the approval is only good for about 120 days. Standard, lower-cost devices don’t. That 120-day clock is why this is a workflow at all: the system has to tie the approval to the fabrication schedule, because the two are racing each other.

Everyone else. Medicare Advantage, Medicaid, and commercial plans usually require PA for custom-fabricated devices too, each with its own rules. Medicaid prosthetics coverage and commercial insurance O&P both vary by state and carrier. By January 1, 2027, a federal rule (CMS-0057-F) moves those plans onto standardized electronic prior authorization, so a smart build adopts each payer’s new system as it comes online while still handling today’s portals and forms.

What the PA engine has to do

• Generate the PA package per payer: clinical justification letter, prescription, functional-level documentation, and usually photos or measurements.
• Flag any device already in fabrication without an approved PA, and show the dollars at risk if it’s denied.
• Watch the approval window and warn before a delivery date slips past it.
• Route by payer and apply each plan’s rules.

Starting fabrication before approval may keep the patient on schedule. It also puts the practice’s money on the table before the payer has agreed to pay. The PA engine should show that tradeoff before the device moves too far through fabrication.

Fabrication lifecycle tracking is the workflow that sets O&P apart

Most healthcare software tracks visits and claims. O&P software tracks the making of a physical object: a custom fabricated device built for one patient’s body. That has no equivalent in general practice management software, which is why prosthetics and orthotics software lives or dies on its fabrication tracking.

The device fabrication workflow runs from prescription through casting, fitting and adjustment, and device delivery to long-term follow-up, and at each stage the system records what happened and watches for the thing that becomes a denial later.

None of this is new as a list, OPIE’s Fab Tracking already walks the stages. The difference that earns a custom build is binding each stage to the documentation it needs and to the clock it’s racing: the 120-day Medicare prior-auth window and the coverage windows on Medicare Advantage plans.

Miss those and a finished device ages out into a denial. That same tracking discipline runs past delivery into repair and modification and full device lifecycle management, the kind of ongoing monitoring a remote patient monitoring app does for vitals, here applied to the device itself. Most general-purpose systems were never designed to follow the device after delivery.

Accreditation compliance after the 2026 annual-survey rule

Accreditation used to run on a multi-year cycle. As of 2026, that’s over: DMEPOS surveys are now annual and unannounced. The job of an orthotics practice management system shifts accordingly, from survey prep to continuous, year-round audit-readiness.

What changed in 2026, and why it raises the bar for software

For years, an accredited O&P supplier got resurveyed about once every three years. A 2026 rule cut that to at least once a year, and the surveys stay unannounced. That kills the prep window. Everything a surveyor might ask for has to be complete and current all the time, because they can show up any week. Software that treats accreditation as an annual fire drill is built for the wrong cadence now; the module’s job is to hold the practice in a continuously survey-ready state.

The contested ABC vs BOC landscape

Two accrediting bodies matter for O&P: ABC, the O&P-specialized one, and BOC. Their standards differ, so a practice with ABC accreditation carries different obligations than one with BOC accreditation, and a system built to ABC accreditation standards alone has a gap the moment it signs a BOC customer.

BOC is also the riskier bet right now. Its federal approval is on shaky ground, a court order is keeping it alive after CMS moved to pull it, and it can’t accredit in California, Florida, New York, or Texas. So “ABC and BOC support” is a promise aimed at a moving target. Pick a framework and say which one, or build to handle both honestly.

What the accreditation module must maintain

Underneath the news, the module’s job is steady. It has to maintain:

• Practitioner credentials: each O&P practitioner’s certifications, certified prosthetist (CP), certified orthotist (CO), or certified prosthetist orthotist (CPO), plus state license and continuing-education credits, with alerts before any expire.
• Patient satisfaction: run satisfaction surveys at delivery and follow-up, then report on the responses.
• A complaint log: every complaint with its resolution and timeline.
• A policy library: the quality-management and quality improvement policies (patient rights, infection control, supervision) with version control and sign-off tracking.
• Outcomes: aggregate device-function and complication data, and run a prosthetic outcomes measurement program with instruments like OPUS (Orthotics and Prosthetics Users Survey) and the amputee mobility predictor (AMP).

EHR and clearinghouse integration: why redundancy is not optional

An O&P system doesn’t live alone. Referrals come in from a hospital’s EHR and claims go out through a clearinghouse, with an eligibility check bouncing off the payer before you ever cast a limb. O&P EHR software is only as reliable as those connections, and in February 2024 the whole industry learned what happens when one fails.

The EHR side: referrals in, notes back

Most O&P referrals start in a physician’s EHR, usually Epic, Oracle Health (Cerner), or Athenahealth. Connect through HL7 FHIR (R4), the standard healthcare data API, and run the EHR integration both ways:

• Inbound: pull the patient record and the order, diagnosis included, so intake populates without retyping a referral fax.
• Outbound: push your fitting notes, functional-level assessment, outcomes, and a co-signature request where the device needs one, all back into the physician’s own system.

The payoff of healthcare interoperability is the K-level. It starts in the physician’s exam and gates your KX documentation, and the same number belongs on the outcomes you report back. FHIR lets that one fact travel from their chart through your billing and into their inbox without a human copying it three times. For the deeper version, see our guide on how to integrate with Epic EHR.

The clearinghouse side: getting paid

The clearinghouse handles electronic claims submission to payers and brings back the remittance. A generic system posts the payment and moves on. The billing module handles denial management, reading the denials and sorting them by what you do next:

• “Fix the documentation and we’ll pay” goes to an appeal queue.
• “That’s the patient’s responsibility” goes to patient billing.

Mapping denials at the L-code level, then routing by who owes the money, is the difference between clean revenue cycle management and a pile of unworked rejections.

Eligibility hides one O&P-specific trap. O&P coverage often sits in a separate bucket from standard DME. Check the DME benefit alone and the system says the patient’s covered when the O&P benefit is capped or exhausted, right before you spend weeks building a device. The eligibility check has to ask the right question, or it lies to you.

Why two clearinghouses, not one

In February 2024, Change Healthcare went down in a cyberattack. It handled close to half of all US medical claims, the disruption ran about two months, and the industry impact topped $1 billion. Practices that routed everything through it stopped getting paid.

That outage is the practical case for redundancy:

• Wire your system to at least two clearinghouses. Change Healthcare (Optum), Waystar, and Availity are the usual names.
• Make switching a configuration change, not a re-integration, so you reroute when one goes dark.

The same standards-based shift is coming to prior auth: the FHIR prior-authorization standards now rolling out under federal rule will carry approvals through the same kind of API, which is where AI-assisted workflows get interesting (see our take on AI in EHR). Treat it as API integration: build the layer so a new payer API plugs in instead of forcing a rebuild.

The HIPAA risks unique to O&P: device photos and fab-lab data

The HIPAA privacy baseline here is the same as for any health app: business associate agreements with every subprocessor, encryption at rest and in transit, audit logging on PHI access, role-based access, and breach notification. Assume that baseline HIPAA compliant software development, so assume all of it. The O&P-specific risk lives somewhere blander and easier to get wrong.

Casting, fitting, and wound or residual-limb photos are PHI, and they’re the PHI most likely to end up somewhere it shouldn’t: a practitioner’s camera roll, or an email to the lab. So the digital imaging has to be captured inside the app, never to the phone’s gallery, stored encrypted, and logged on every view.

Three more exposures are specific to how O&P operates:

• Fab-lab handoffs: outsourcing fabrication sends identifiable patient data and limb measurements to an outside lab, which makes that lab a business associate. It needs a signed BAA and an encrypted transfer, since a file on a regular email won’t cut it.
• Clearinghouse BAAs: the clearinghouses that move your claims are business associates too, so keep a BAA on file with whichever you use, Waystar, Optum (Change Healthcare), or Availity.
• Payer-portal credentials: practices that submit eligibility and prior auth through payer portals have to manage those logins with access controls and an audit trail.

Build, configure, or adopt: the real O&P software decision

For a founder or CTO weighing O&P software development, the decision that actually matters is build-or-configure versus adopt a platform that already exists. Hospital-first EHRs don’t fit O&P documentation. The real alternative is the incumbents. OPIE Software has run the category since 2003 and sits in roughly 1,700 facilities, with its own fabrication tracking and outcome measures; Nymbl Systems is the cloud-native challenger, practice software built for O&P rather than retrofitted from hospital systems. A new build needs a defensible reason to exist: a sub-specialty, a payer mix, an enterprise multi-location need, or an outcomes approach the incumbents underserve. Otherwise the healthcare app development cost is hard to justify against adopting one of them.

If you build only three things, build these

You can’t build all of it at once, so sequence it. If you build only three things, build these:

• The active KX documentation gate that blocks a claim until the paperwork exists. It’s the single highest compliance risk, with the orthotics improper-payment rate (35% to 54%) on the line.
• The fabrication lifecycle tracker, tied to the PA and coverage windows. It’s the workflow that most separates O&P from everything else.
• The accreditation module, built for annual unannounced surveys, since continuous audit-readiness is the admin load owners complain about most.

Get those three right and the people using the system every day will adopt it and tell their peers. Whatever the eventual scope of your healthcare app development, that’s the order to build in.

Why choose Topflight Apps for O&P practice management development

The hard part of an O&P build is the domain. The L-code rules, the documentation gates, the accreditation cadence, the fabrication workflow no generic platform models, that’s where these projects succeed or fail, and it’s the part Topflight builds for.

We build HIPAA-compliant software for specialty-practice healthcare, the underserved disciplines where billing, documentation, fabrication, and integration don’t fit an off-the-shelf EHR.

For O&P, that’s the work this article has described: an L-code billing architecture with KX audit gates and jurisdiction-aware coverage rules; clinical documentation with device-measurement templates, fabrication tracking, functional-level records, and outcomes integration; FHIR referral and note exchange with Epic, Oracle Health, and Athenahealth; and accreditation documentation that holds up to ABC and BOC surveys.

You know L-codes and K-levels better than we ever will. What we bring is the engineering that turns those rules into a system your practitioners actually use.

If you’re ready to build O&P practice management system software, or weighing a custom build against adopting an incumbent for a multi-location practice, talk to us about your billing workflow, your accreditation obligations, and your integration requirements. That conversation is where the real scoping starts, billing first, because that’s where the risk and the money are.