The account has more than one relevant clock
I would distinguish time since discharge, time since the account became ready for coding, time awaiting an available coder, and time spent waiting after coding started. Those intervals explain different operating problems. A single average from discharge to completion can conceal a queue of ready work behind a larger group of accounts waiting for documentation.
The first data request would include discharge dates, coding status history, workqueue history, coder assignments, documentation queries, validation failures, and completion dates. I would define the population by account class or service type and reconcile it to unique hospital accounts. One account appearing in several views should not be counted as several units of coding demand.
Then I would review a sample from each apparent barrier. A status labeled waiting for documentation may be accurate, stale, or used as a general deferral reason. The review needs to establish what information is missing and what event would make the account actionable again.
The workqueue path should reflect the next action
In Epic, I would trace how an account enters the relevant coding workqueue, what makes it eligible for coding, and how it moves when a query or other dependency interrupts the work. I would request routing configuration and the rules or properties that support those decisions. Some HB logic is maintained outside CER, so I would ask the application owner to identify the correct configuration rather than assume one extract is complete.
For a rule-driven selection, I would review the rule context, criteria, property parameters, and known references. A successful Rule Tester result is one piece of evidence. I would also test the consuming workqueue or coding workflow with representative accounts because contact context, processing timing, and other configuration can change the operational result.
The account should reach a team that can perform the next action. A coder waiting for a provider response needs a reliable return path when that response arrives. A manager-review case needs a defined decision. Keeping every account in the same production queue can make staffing appear inadequate while the actual bottleneck remains elsewhere.
The coding application handoff deserves its own review
I would confirm whether the organization uses an integrated encoder and which information moves between that application and Epic. An account can be complete in one system while an interface problem leaves Epic missing coded data or a completion status. I would compare the actual transmitted result with the account fields and validation errors before classifying that account as unfinished coder work.
The same discipline applies to completion checks. I would identify which validation check fails, which team owns the missing or inconsistent data, and whether the failure prevents completion or simply warns the user. Removing a validation because it creates volume can trade an uncoded backlog for inaccurate or rejected claims.
For repeat failures, I would group accounts by the underlying cause and identify a source correction. The recommendation should specify the data owner, configuration owner, resolution workflow, and evidence that will demonstrate the change worked. That is more actionable than asking coders to clear every old item by a deadline.
Capacity planning follows the actionable population
After separating the barriers, I would compare incoming ready work with completed ready work by relevant complexity and skill group. A simple count of accounts per coder can be misleading when one team handles complex inpatient records and another handles a high volume of simpler encounters. The plan should make the case mix and available working time visible.
Acceptance testing would include an account ready at first review, an account awaiting documentation, a returned provider response, a failed encoder handoff, and a valid completion-check failure. I would verify entry, deferral, reassignment, return to actionable work, and final completion. I would also confirm what happens to the account after coding completes.
If the fix changes routing, the existing inventory needs reconciliation. I would show which accounts should move and why, preserve the relevant history, and assign an owner to accounts that do not behave as expected. A mass transfer without that reconciliation makes it harder to understand whether the backlog improved.
The scorecard should reveal the next bottleneck
I would report newly ready accounts, coding completions, ready-work aging, and accounts awaiting other teams. Median and older-case duration should be visible alongside volume. The denominator for a readiness measure is the defined discharged population, while the denominator for coding productivity is the actionable work actually assigned and completed.
I would monitor query response and return-to-queue time, repeat deferrals, encoder or interface failures, and post-coding claim edits. Faster completion is not a success if the same accounts return for avoidable correction downstream. A small review sample should confirm that quality remains acceptable as throughput changes.
The financial benefit is usually first visible in billing progression and cash timing. I would avoid equating the entire uncoded balance with incremental revenue or savings. A useful capacity plan explains how much work needs a coder, which barriers need another owner, and what prevents the same backlog from forming again.