Operational Maintenance Best Practices

Like other organizations, healthcare payers want to get the most out of their IT investments. But keeping up with operational maintenance of fee schedules, code sets, and industry changes can be a daunting task for any health plan.

To allow them to maintain their operations, they need to actively manage their maintenance costs, and ensure their systems are running efficiently. And, nowhere is this more evident than in the amount of operational code sets their systems use. The more code sets an application uses, the more difficult it becomes to maintain those codes. If there are too many code sets, it can become extremely burdensome and frustrating for their business and technical teams to manage, and the system will fail in efficiency.

Automating the processes

Automating processes throughout the healthcare system leads to operational improvements. This is true for operational maintenance of code sets that improve benefit design, physician pricing, fee schedules, and provider contracting.

By automating code sets and workflows in claims processing, billing, care management, and network management, the opportunity for operational efficiencies increases and administrative processes are streamlined. First-pass claim rates improve, minimizing the need for claims to be manually reviewed in most cases. The revenue cycle is shortened, improving the organization’s cash flow. And, there’s better information and more timely communications to providers and plan members, helping increase their satisfaction and improving the quality of care.

Because of our industry knowledge and expertise, we are constantly looking for ways to improve an organization’s core administration technology that’s used regularly to pay and administer claims. The way an organization configures its business rules for benefit plans, pricing, and provider networks can positively or negatively affect its operations and outcomes.

That’s why applications that are shared across the core system including explanation codes, unique user-defined codes, and alert messages should be maintained by a so called “Gatekeeper.” This individual, plus a designated backup, is responsible for maintaining these system level codes and configuration. This ensures consistency and accuracy of all data, and reduces errors during the manual processes.

Provider contracts

Health plans use professional fee schedules either from the Centers for Medicare & Medicaid Services (CMS) calculated physician fee schedule or Resource-based Relative Value Scale (RBRVS). Both calculate a physician payment schedule to determine how much money providers should be paid. And both methods calculate to the same amount.

The CMS calculated fee schedule is the pre-calculated rate assigned to a service. However, in the RBRVS methodology, pricing is calculated during claims adjudication by, in part, reading the providers location.

For example, provider A practices in several different geographic locations, including several states that border one another. Using the CMS calculated fee schedule, this provider would require separate agreements/contracts to calculate for each service location correctly. However, using the RBRVS methodology requires only one provider contract because RBRVS will calculate the rate during claims adjudication based on the claim service location.

The advantage of the RBRVS fee schedule is that it allows a general fee schedule to be shared across multiple provider contracts, regardless of provider location, thus reducing the number of contracts to configure and maintain.

Service IDs (Facets)

Efficiently using Service IDs in Facets is important for maintaining what could be thousands of benefit service codes. We recommend keeping the Service IDs to an effective number, which makes mapping them to procedure and revenue codes more efficient and easier for operational maintenance. Service IDs in Facets are most efficient when kept to an average of 550-600.

Consider designing Service IDs with a naming convention system. For example, Service IDs that begin with A – Q are mapped to the Current Procedural Terminology (CPT)/Procedure and the Healthcare Common Procedure Coding System (HCPCS) codes. While Service IDs beginning with R – W are mapped to hospital-based revenue codes. X, Y, Z can be used for any codes that are not covered. In addition, Service IDs mapped directly to Procedure or Revenue codes are created as two-character IDs, while “supplemental” Service IDs (those codes that include criteria such as provider type/specialty, place of service or diagnosis codes) would be four characters, with the first two characters matching the “base ID.”

For example, “EV” Service ID is mapped to office visit procedure codes. Then, EV01 Service ID maps to those office visit procedure codes, plus Chiropractor Provider Specialty.

Naming conventions help with claims troubleshooting. For example, when a medical claim displays EV, the processor knows to look to the base table for procedure code mapping, however, for EV01 Service ID, the processor knows to look for additional criteria.

Service Rules (Facets)

When managing Facets Service Rules, it’s recommended that all Service Rules are assigned to all Service IDs for consistency and ease of maintenance. The configuration team can work with the database administration (DBA) team to develop a script whereby the configuration team would create a new Service Rule on one Service ID (i.e., Service ID = EV). The DBA team could then update all other Service IDs with that new Service Rule.

This is an effective way to manage a large list of Service Rules across hundreds of Service IDs while ensuring configuration consistency.

Using Facets Workflow for configuration

Facets Workflow is primarily used for routing and tracking pended claims. However, if the core administration system doesn’t have the functionality to assign specific auto adjudication rules, or a rule is very specific, Facets Workflow can be designed to apply automated “overrides” to the claim.

For example, if a specific procedure code requires an authorization only out-of-network, Workflow can be used to waive the prior auth requirement for an in-network and Par providers (a provider who accepts assignments).

This is a more efficient process than carving out that one specific procedure code and mapping it to its own Service ID, which would then have to be maintained in all the Facets related applications (Service Rules, Service Definition, Service Payment, etc.).

An example of using Workflow to supplement core functionality is managing fraud, waste and abuse by creating an automatic claim denial based on a specific Provider Tax ID.

There are often time several options in determining how to configure health plan business rules. Health Plans should consider which are most effective as well as operationally efficient when making their design decision.