The review state should describe what happens next
I would start with the team's intended review states: initial review, subsequent review, waiting for information, ready to act on new information, and completed work. Each state needs an operational meaning and an owner. If staff use the same status for several different reasons, the queue cannot reliably distinguish available work from a pending dependency.
The data request would include CDI review history, next review dates, query creation and response timestamps, query types, recipients, outcomes, workqueue history, and coding status. I would reconcile those records at the hospital-account level while retaining individual queries. One account with several queries is not several independent account handoffs.
A targeted sample should include unanswered queries, recently answered queries, overdue subsequent reviews, and accounts that reached coding completion with unresolved documentation concerns. I would compare the recorded status with what the specialist says should happen next. That often reveals where the process and the status logic diverge.
The configuration should make new information actionable
In Epic, I would inspect CDI workqueue criteria, status dependencies, next-review-date behavior, and the conditions that return an account to a priority or other actionable queue. I would ask for relevant CER rules where the workflow uses them, together with properties, parameters, context, and the configuration that references them.
Then I would follow a representative provider response through the workflow. The response may add documentation, indicate that work was already done, disagree, or require further review. The system event and the clinical meaning are different things. The team needs to know which responses create an actionable account and which require clarification.
I would test the actual queue and review activity after testing individual rules. A correct rule result does not establish that the account is reevaluated at the expected time or that another status condition allows it to appear. The acceptance evidence should show the specialist receiving the account with enough information to decide the next step.
Consistent query content can reduce avoidable back-and-forth
I would review the query type, default subject, query SmartText, and provider response SmartText with CDI and coding leaders. Consistent templates can help specialists assemble a complete request and help clinicians understand the information needed. They should still allow appropriate review and customization for the actual record.
SmartLists can support structured response options, and relevant evidence can help a clinician understand the question. The content needs approval from qualified owners, including appropriate neutral response choices. A template should not suggest that a preferred diagnosis or reimbursement outcome has already been established.
I would also test the response experience the clinicians actually use, including mobile workflows where relevant. A query that works in a desktop demonstration may be difficult to respond to in another supported context. The measure should reflect whether the clinician can provide a complete, usable answer in their normal workflow.
Coding needs the result and any remaining uncertainty
I would agree on what must happen after CDI receives the response: review the new information, record the outcome, update the review, communicate with coding, or send a further clarification when appropriate. The account should not wait simply because everyone assumes the recipient of the message owns the next step.
If an outstanding-query coding validation is used, I would confirm whether it warns users or prevents completion, and which population it affects. That control should match the organization's approved process. Automatically closing a query at another workflow milestone is also different from resolving the original documentation concern.
Acceptance scenarios would include a response with updated documentation, disagreement, no response, a response that needs follow-up, and several queries on the same account. I would verify visibility, ownership, query outcomes, return routing, and the final coding handoff for each scenario. The test should include accounts that legitimately have no further CDI action.
The measurement should continue after the response
I would track time from query creation to response and time from a usable response to the next completed CDI action. I would show unanswered-query age and overdue subsequent reviews separately. Those measures identify whether delay sits with the recipient, routing, specialist capacity, or an unclear operating agreement.
I would measure repeat queries caused by incomplete responses, the proportion of returned accounts that receive timely action, and coding delays attributable to unresolved documentation. Agreement rate alone is insufficient because an appropriate disagreement can be a valid outcome. The review should value accurate resolution rather than a particular answer.
Financial reporting should distinguish documented coding impact from later reimbursement and final payment. A DRG change in a review record is not automatically incremental collected revenue. The practical success is a complete, traceable handoff that supports accurate documentation and coding while reducing time accounts spend waiting for an unidentified owner.