However, as payers interpret and transform these contracts into machine readable files utilizing the provided schemas, the prices are altered into a shadow, increasingly abstracted and intricate, distanced from the source contracts.

Three examples of payer-provider contract methodologies that do not translate, but should be taken into account when benchmarking a fair price are The Cascade, Group Classification, and Per Case/Per Visit/Per Unit.

The Cascade: while there may be a simple rate-per-code translation for a set of facility services, the analysis changes drastically when the codes are billed and performed together, and a contract would outline that the primary procedure is paid at 100% of the allowable, the secondary procedure is paid at 50% of the allowable, and the rest of the procedures are paid at 25%. This is to reflect the reduction in resources used in a single session.

A rate table (or TIC file) without acknowledgement of this cascade obscures any machine readable file. Unfortunately the TIC files contemplate only "single-rate" billing and payment, which does not address this issue except to indicate the additional information field could be used.

Group Classification Rates: many contracts identify classification groups (i.e. groups 1-5) and a rate for each group. This means there are only a few actual rates for thousands of CPT codes. While this is a very simple schedule to represent by providing the rates for each group and list of CPT codes with a group assignment, these group rates are often the only codes paid on a bill even if there are other codes on a bill that would normally be paid.

The ancillary codes are part of the global payment and paid at zero. Further, there is often a cascade applied to these codes. While this formula can be adequately described in a paragraph, it does not translate well into a list of rates. There is no adequate way in the TIC files to address this issue outside of using the additional information field.

Per Case/Per Visit/Per Unit: some services are identified by revenue code (not CPT code) and paid on a Per Case flat rate for the day, however other services can be paid on a Per Visit rate or Per Unit basis. The complexity in this method arises when a Per Case service is billed with a Per Visit service.

The Per Case rate is paid and the Per Visit rate is part of the case, so it is not paid. While this logic makes sense in a paragraph, the only real way to convey this information is in the additional information and descriptor fields in the TIC files, but this does not really create a machine readable way to analyze rates any more than producing the contract provision.

While there are a large number of other formulas in payer contract methodologies that do not translate well into a TIC file, these examples highlight some of the issues with the TIC files we have today. This obfuscation results in two key challenges when they are used to benchmark prices:

Complexity over Clarity: the attempt to generate a complex schema that lists every possible combination of provider and payer contract calculated rate balloons the resulting file into a terabyte-sized behemoth, making them almost indecipherable in some instances. A requirement to list the actual rates rather than the formula to produce the rates based on public tables (like a multiple of the Medicare rate), turns a one paragraph provision from a contract into 10,000 plus lines of rates for each code.

These rates are then linked to other files that identify which groups of providers apply to that rate. For years payers and providers have exchanged simple contracts and loaded finite data into systems as a simple ratio and a list of tax identifiers or provider NPIs (the public tables already available in the system). Why not release the same formula description from the contracts instead of, or along with, the TIC files?

Loss of Original Intent: As the file schemas for TIC files add layers of complexity, the formulas for rate calculations in the original contracts are buried beneath millions of lines of extraneous data. Decades of contract negotiations, implementation, and system claim processing has led to a very clear set of instructions on how to calculate rates, attached to each payer contract. These blueprints are uniform, and many of the largest payers use almost the exact same template with each provider, only modifying a few variables in negotiations.

These payment instructions, which only amount to a few pages of text, when compared together, would reveal high priced and low priced hospitals. Why not release the templates, and then release the changed variables in a dataset for each provider? These simple datasets are likely how the claim processing systems are configured and maintained in the payer's own systems.

Related: Why price transparency isn't the whole story

The significant effort placed in the design and production of these TIC files has unfortunately chained the public inside a cave with shadows of the original source payer-provider contracts outside. While this transparency effort does provide some relief (general estimates and a starting point somewhere below billed charges for price review), it would be an immense help if the regulators took the additional step and required the source contracts to be produced alongside the files.

The TIC data does provide another perspective and data point when analyzing medical prices. However, other public cost and payment benchmarks, standard contracting methodologies, and academic studies could definitely aid in the search for clarity in hospital prices.