MSO Revenue Leakage Definitions: How to Standardize Them Across Practices

An MSO can compare revenue leakage across its practices only after every practice uses the same definitions: what opens a leakage item, what closes it, what is excluded and which denominator the rate uses. Write those definitions down once, apply them to each practice's own data, and compare each practice with its own baseline before ranking practices against each other.

This article is for MSO operations leaders, COOs and the analysts who build roll-up reports. It assumes you already know leakage exists; the problem is measuring it consistently.

Why do leakage definitions differ from practice to practice?

Definitions drift because each practice built its follow-up habits before it joined the MSO, around its own EHR and its own staff.

• Workflow history. One practice counts a referral as closed when it is scheduled. Another waits until the patient is seen. A third closes it when the consult note goes back.
• EHR differences. Recall modules, order statuses and appointment types behave differently across systems, and sometimes across versions of the same system.
• Local codes. "Colonoscopy" might be three appointment types at one practice and one at another.
• Denominators. One practice divides by all referrals received; another excludes referrals missing insurance or demographics.
• What gets measured. Teams tend to define success by what they control, so a front desk may count calls made while the MSO wants completed visits.

Illustrative example. Two practices each report a referral conversion figure. Practice A counts referrals scheduled within the period, divided by all referrals received. Practice B counts patients seen, divided by referrals received with complete information. Practice B's process could be performing better and still post a lower number, or the reverse. Neither number is wrong; they just answer different questions. The detail of choosing a referral formula is covered in how to calculate referral leakage.

What should each MSO revenue leakage definition include?

Without written MSO revenue leakage definitions, an MSO ends up ranking practices on numbers that do not mean the same thing. Every definition should state the same eight elements:

1. Trigger. The record that opens the item, such as a signed procedure order.
2. Window. How long after the trigger before the item counts as open leakage.
3. Closure. The record that closes it, such as a completed procedure for the same service.
4. Suppression. What keeps an item off the list, such as a booked appointment for the same service inside the window.
5. Exclusions. Records that never count, such as orders canceled by a clinician.
6. Closure reasons. The fixed list staff may use to close an item without completed care.
7. Denominator. What the rate is divided by.
8. Owner. The role responsible for working open items.

What does a standard definition table look like?

The table below is a starting framework. The structure matters more than the specific wording; adapt it to the specialties your MSO supports.

Notice what the last column does not include. Practices can change how long to wait and how local codes map to the shared definitions. They should not change what counts as closed or what is excluded, because that is what makes the numbers comparable.

Which parts should be standard, and which can vary?

Standardize the logic: triggers, closures, exclusions, closure reasons and denominators. These define what the number means.

Let practices vary the settings: windows tied to local capacity or referral patterns, the mapping of local appointment types and order codes, and which role owns each queue. Windows that depend on clinical intervals, such as recall grace periods, should be approved by a clinical reviewer rather than set by the operations team alone.

Write both down in a short data dictionary, one page per leakage type. Practice administrators should be able to read it without an analyst.

How do you build a fair baseline for each practice?

A baseline tells you where each practice started, under the shared definitions, before anyone changed how they work.

• Restate history. Apply the standard definitions to past data from each practice, ideally enough to cover seasonal swings. Do not reuse the practice's own historical reports; they were built on its old definitions.
• Baseline per practice, not per MSO. An average across practices hides the spread you most need to see.
• Compare trends before levels. A practice that improves meaningfully from a low starting point may be doing better work than one that holds steady at a high level.

Illustrative example. Under shared definitions, Practice A converts 60 of every 100 referrals at baseline and 66 of every 100 a few months later. Practice B converts 80 of every 100 at baseline and still converts 80. Ranked on level, B looks stronger. Ranked on change against baseline, A has moved and B has not. Both views are useful; only the second tells you whether a new process is working. The revenue leakage metrics guide covers more measures to track this way.

Who should own the definitions?

One person at the MSO, usually the COO or a director of operations, should own the definitions and the change log. Clinical reviewers approve windows that rest on clinical intervals. Practice administrators review the definitions on a set schedule and raise local exceptions. IT or the EHR team confirms what each practice's data can support.

Every change gets a date, a reason and a note on whether baselines need restating. Otherwise a definition change in March will look like a performance change in April.

What mistakes should an MSO avoid?

• Ranking practices before baselines exist.
• Changing a definition mid-year without restating the baseline.
• Counting contact as closure. A call is activity; a completed visit is the outcome.
• Letting practices opt out of exclusions they find inconvenient.
• Ignoring data differences between EHRs. If one practice's system cannot show a field, say so in the report rather than filling the gap with an assumption.

If you are starting from scratch, a revenue leakage assessment at one practice is a good way to test definitions before rolling them out to all of them. PE-backed platforms face the same problem with acquired practices; measuring revenue leakage in PE-backed practices covers that angle.

How does Nuvory support MSO definitions?

Nuvory applies one rule set across the practices an MSO supports, with a baseline per practice built from about two years of history, and each rule is signed off by a clinical reviewer. Its windows are configurable; the product's starting defaults, such as flagging referrals with no contact after 7 days, are configuration settings each MSO adjusts, not recommended standards. See revenue leakage intelligence for MSOs, and more on this topic in revenue leakage.

Frequently asked questions

Why not just use each practice's existing reports?

Because each report reflects that practice's own definitions. Rolling them up produces a number, but not one you can compare. Restating each practice's history under shared definitions takes more effort once and saves repeated arguments about whose numbers are right.

How many leakage types should an MSO standardize first?

Start with the two or three that matter most to the specialties you support, often referrals, procedure orders and recalls. Get those definitions agreed, baselined and trusted before adding more. A short, trusted dictionary is more useful than a long, disputed one.

Should windows be the same at every practice?

Not necessarily. Windows often reflect local capacity and referral patterns, so they can vary within agreed limits. What should stay fixed is what opens an item, what closes it and what is excluded. Clinical intervals need clinical reviewer approval.

What if one practice's EHR cannot provide a field the definition needs?

Note the gap in the data dictionary and in every report that uses that measure. Do not estimate the missing data silently. Sometimes optional sources such as claims can fill the gap later; until then, compare that practice only on measures its data supports.