The service definition comes before consolidation
I would start with one service line and ask the clinical, revenue integrity, and billing owners to define the services they need to distinguish. Similar descriptions do not establish that two codes represent the same service. Differences in units, billing attributes, source systems, or operational use can matter even when the charge names look nearly identical.
My initial inventory would connect charge records to actual usage, generating workflows, department attribution, billing attributes, and existing mapping relationships. I would identify records with no recent activity, but I would not retire them solely for that reason. An infrequent service can still be valid, and a code can be referenced by build that has not yet produced recent activity.
The decision register should state whether each candidate is retained, consolidated, corrected, or retired, along with the operational reason. The register also needs the owner who can approve the service definition. That prevents a technical cleanup from becoming a series of undocumented clinical and billing decisions.
Dynamic charging changes what must remain distinct
In Epic, a charge's final attributes can depend on configuration outside the charge record itself. I would review the department and location relationships, cost center assignment, pricing dependencies, and any source-specific mappings relevant to the service. A duplicate-looking charge code might be compensating for an upstream limitation, while a consolidated code might already support several appropriate contexts.
For interfaced charges, I would confirm what the sending system can supply. If the interface does not send enough information to distinguish the intended department or other required attributes, consolidating mappings can erase the information the billing workflow needs. The source and interface owners should validate that assumption with actual messages.
Where rule logic participates in the decision, I would ask for the relevant CER records and the configuration that references them. I would trace criteria, context, parameters, and priority against sample transactions. The goal is to establish which piece of build supplies each final attribute rather than expect one extract to describe the entire charging design.
The maintenance process should preserve those decisions
I would define a change request that captures the service, charging method, affected departments, billing attributes, effective date, and downstream dependencies. The request should identify the clinical approver and the operational teams that will test the result. A code can be correct in the catalog and still be difficult for users to select correctly.
I would also document who maintains source-system mappings, procedure relationships, and department setup after the charge master change. A new clinical workflow, acquired department, or interface update can invalidate an earlier assumption. Revenue integrity needs visibility into those triggers rather than wait for a missing-charge report to reveal the change.
For retired or consolidated records, I would preserve an intelligible crosswalk and an approved effective-date approach. Historical activity should remain interpretable. The team needs to know how to handle a late charge, reversal, or correction that refers to the earlier configuration.
The test set should follow the service across contexts
I would select representative transactions for every materially different charging source and department in scope. The test should confirm that the clinical event generates the expected charge, the charge reaches its billing destination, the correct department and cost center receive attribution, and the billing attributes match the approved service definition.
Boundary cases should include an interfaced transaction with missing source information, a corrected service, a late charge around the effective date, and a transaction that legitimately uses a different code. I would include both hospital and professional outcomes when the service has responsibilities in both workflows.
The acceptance evidence should make the original decision traceable. A reviewer should be able to move from the service definition to the mapping, test transaction, posted charge, and billing outcome. That is stronger evidence than a signed spreadsheet showing that the requested number of codes was removed.
The result should show accuracy and maintainability
I would track mapping defects, transactions assigned to an unexpected or default error cost center, charge corrections caused by catalog problems, and time required to complete an approved change. The denominator should be the relevant service or transaction population, not every charge in the organization.
For maintenance, I would measure requests returned for missing information, changes implemented without complete testing, and repeat issues tied to the same unresolved dependency. These measures help distinguish a cleaner decision process from a temporary reduction in the queue of requests.
The financial evaluation needs its own evidence. Correcting a billing attribute or source mapping can protect reimbursement, while consolidating a code may primarily reduce maintenance effort. A price change does not necessarily create an equal increase in net revenue. I would report the benefit the organization actually achieved and retain the service-level decisions that make the charge master sustainable.