TL;DR: A multi-specialty group can automate revenue cycle work on top of ModMed by standardizing its highest-volume tasks (eligibility checks, claim status follow-up, denial follow-up, and payment posting) as shared automated workflows, then layering specialty-specific payer rules on top. Inventory what each location does today, centralize the tasks that look the same everywhere, roll out one specialty at a time, and keep audit trails and human review for anything that needs judgment.
Why is revenue cycle automation harder for a multi-specialty group?
A single-specialty practice has one set of payer rules, one coding vocabulary, and usually one way of working a denial. A multi-specialty group has several of each, all running on the same ModMed foundation.
Dermatology, ophthalmology, and orthopedics all submit claims through the same system. They don't run into the same problems. Dermatology fights modifier and bundling edits on procedure-heavy days. Ophthalmology deals with medical necessity and prior authorization for surgical cases. Orthopedics spends its time on authorizations and high-dollar claims. Each location also builds habits over the years: a spreadsheet here, a payer portal bookmark there, a biller who knows which rep to call.
That variation is why automation projects stall in groups. Someone buys a tool, configures it for the loudest specialty, and discovers three months later that the other locations work differently enough that the rules don't carry over.
The scale of the problem is worth stating plainly. Kodiak Solutions reported that the initial denial rate reached 11.81% of claims in 2024, and that true accounts receivable days rose 5.2% year over year. In a group with several specialties and locations, that pressure shows up in every billing office at once, and each office is solving it a little differently.
The fix is to separate what's the same from what's different. Most of the repetitive work is the same. The rules around it are different. Automation works best when you build one shared layer for the first and a thin, specialty-specific layer for the second.
How do you inventory revenue cycle workflows across locations?
Start by writing down what people actually do, not what the process document says. This takes a week or two and pays for itself.
For each location and specialty, capture:
- Who does the task and how long it takes. Ask billers for rough minutes per claim status check, per denial, and per remittance posted.
- Where the work happens. ModMed, a clearinghouse, a payer portal, a spreadsheet, or a phone call.
- Which payers drive the volume. A group usually has five to ten payers that account for most of the work.
- What gets escalated and to whom. Appeals, short-pays, and recoupments tend to follow informal paths.
- What goes wrong. Aging claims, missed filing deadlines, unposted payments, and denials nobody owns.
Put the results in one table with a row per task and a column per location. When you scan across a row, the picture gets clear fast. Rows where every location does roughly the same thing are centralization candidates. Rows where locations diverge need a closer look at why.
Sometimes the divergence is real, because one specialty has a payer rule the others don't. Sometimes it's habit, and the inventory is the first time anyone noticed. Both are useful to know, and the inventory is how you tell them apart.
Keep the inventory. It doubles as your baseline for measuring results later.
Which tasks centralize cleanly, and which need specialty configuration?
Sort every task into one of three buckets.
Bucket 1: shared across specialties. These tasks have structured inputs and the same logic everywhere:
- ERA payment posting, where the 835 remittance file is the input
- Claim status checks on aging claims
- Eligibility and benefits verification before visits
- Routine denial fixes such as demographic errors, duplicate submissions, and coordination-of-benefits updates
Standardized electronic transactions make these good candidates. The 2025 CAQH Index found that 81% of medical claim status inquiries and 78% of claim payments now run electronically, and still estimated more than $20 billion in remaining annual savings. The manual work left over sits in reading responses and deciding what to do next.
Bucket 2: shared workflow, specialty rules. The task is the same, but the rules differ. Denial follow-up is the clearest example. The workflow of reading a reason code, deciding whether it has a known fix, and routing the rest is shared. The specific fixes depend on the specialty: which modifiers a payer expects, which documentation supports a procedure, which codes bundle.
Bucket 3: specialty-specific. Prior authorization for surgical procedures, medical necessity appeals, and contract disputes on high-dollar claims. These stay with specialty-trained staff, with agents assembling documentation where they can.
The practical rule is to automate Bucket 1 first across all locations, build Bucket 2 as a shared workflow with a rules table per specialty, and leave Bucket 3 to people.
That structure keeps the number of things you maintain small. One posting workflow serves every location. One denial workflow serves every location, with a lookup of specialty rules attached. When a payer changes a requirement, you update a rule instead of retraining five offices.
How should a multi-specialty group roll this out?
Phase it. Trying to switch on every workflow at every location at once is how groups lose their billers' trust.
Phase 1: one specialty, one or two workflows (60 to 90 days). Pick the specialty with the highest denial volume or the most backlog, and start with payment posting and claim status follow-up. Both have structured inputs and clear rules. Run the agents in a review-first mode where a biller approves actions before they take effect, then loosen as the exception rate drops.
Phase 2: add denial follow-up for that specialty. Start with Tier 1 denials that have a known fix. Build the specialty rules table with the billers who work those denials every day. Their knowledge is the rule set.
Phase 3: second specialty on the shared layer. Here the payoff of standardizing shows up. The posting and claim status workflows carry over. You add the new specialty's rules rather than building from scratch. Expect the second specialty to go faster than the first, though not instantly.
Phase 4: remaining locations and eligibility. Add the rest, and bring in eligibility and benefits verification, which touches the front desk and so needs its own change management.
At each phase boundary, compare results to the baseline before moving on. If days in A/R and posting lag haven't improved after a clean pilot, find out why before expanding.
Honey Health's revenue cycle agents, such as Denial Management and Payment Posting, follow this shape: one automation layer working alongside ModMed across locations, with rules configured per specialty and every action logged. Whichever tool you evaluate, ask whether it can run one layer across sites or whether each location needs its own setup.
What governance and audit trails does a group need?
A group carries more compliance exposure than a single practice. More billers, more locations, and more payers mean more places for a mistake to hide. Agents add speed, and speed makes governance matter more.
Set these up before the pilot starts:
- A named owner for every rule. If a denial rule changes, someone approved it and the date is recorded.
- An action log that your compliance lead can read. Every posting, resubmission, and adjustment should show what the agent did, when, to which claim, and under which rule.
- Minimum necessary access. The agent should reach only the data its workflow needs. Require a signed business associate agreement before any protected health information moves.
- Escalation thresholds by dollar amount and type. Short-pays above a set amount, recoupments, unmatched payments, and high-dollar claims always go to a person.
- A sampling routine. Once a week, a lead pulls a sample of agent actions and checks them the way they'd check a new hire's work.
Governance also protects you when staff change. A group with a clean log and named rule owners can onboard a new biller or a new location without relearning why things work the way they do.
What should you measure across sites?
Measure the same few numbers everywhere, and compare locations to their own baselines rather than only to each other. Specialties have different payer mixes, and a straight comparison can mislead.
- Days in A/R, overall and by payer
- Posting lag, meaning days between a remittance arriving and the payment being posted
- Unworked denials older than 14 days
- Dollars recovered from corrected and resubmitted denials
- Exceptions per hundred items, which tells you whether your rules fit your data
- Staff hours per task, compared with the inventory baseline
Premier's survey of more than 500 provider organizations, reported by RevCycleIntelligence, estimated providers spend $19.7 billion a year reviewing denials. In a group, even small improvements in denial turnaround repeat across every location, so measure them at the group level too.
A last metric deserves attention: the share of denials by root cause. When agents log every action, you can see that one location generates most of the eligibility denials, or that one specialty accounts for most of the coding-related ones. That points to prevention work at the front desk or in coding, which is where the next round of savings lives.
What about integration friction and change management?
Two things trip up multi-specialty rollouts, and neither one is technical.
Integration varies by environment. Groups often run ModMed configurations that differ by specialty and location, with different templates, fee schedules, and clearinghouse connections. Ask any vendor exactly what the agent can read, what it can write back, and where the audit log lives. Test with real data from your slowest location, not your cleanest one. A pilot that works in the tidiest office tells you very little.
Billers worry about their jobs. That worry is reasonable, and ignoring it kills adoption. Be direct about what changes. The agents take over repetitive posting and routine denial work. Your billers move to exceptions, appeals, payer escalations, and root-cause work. Involve them in writing the rules, since they know which payer needs a call and which denial code means something different than the manual says.
A few habits help:
- Put your most experienced biller from each specialty on the rules team.
- Share the weekly numbers with the whole team, including the exception queue.
- Keep the review step visible in the first weeks, so staff can see the agent making mistakes and getting corrected.
- Celebrate the cleared backlog rather than the headcount math.
Expect friction in the first month. Your team reviews more than they eventually will, exceptions run high, and some rules need rewriting. That's normal. If exceptions don't fall after six to eight weeks, the data or the rules need attention before you add more scope.
Frequently Asked Questions
Can a multi-specialty group run one automation layer across all its ModMed locations?
Yes, for the shared tasks. Payment posting, claim status follow-up, and routine denial fixes use the same logic everywhere, so a single workflow can serve every location. Specialty-specific payer rules sit on top as configuration, not as separate builds.
Which specialty should we automate first?
Pick the one with the largest denial backlog or the highest posting volume, since that's where the baseline gap is widest. Starting there gives you measurable results quickly and a rules table the other specialties can borrow from.
How long does a rollout across several specialties take?
Plan on 60 to 90 days for the first specialty and first workflows. Later specialties move faster because the shared layer carries over, but each one still needs its own rules built with its billers. Expect the full group rollout to take several quarters.
What should stay with human billers?
Medical necessity appeals, contract underpayment disputes, peer-to-peer reviews, payer escalations, and any claim above your dollar threshold. Agents can assemble the documentation, but a person should decide the argument and own the outcome.
How do we keep automation compliant across locations?
Require a business associate agreement, limit data access to what each workflow needs, keep an action log your compliance lead can review, and assign a named owner to every rule. Sample agent actions weekly and review thresholds monthly during the pilot.
