@jenniferduryea and I have finalized our proposal for the Unified Cost Table:
Changes since last time:
- Added the revenue_code_concept_id and revenue_code_source_value columns back in. Revenue codes seem to best fit in the cost table because:
- All services rendered in an outpatient facility have a revenue code associated with them. Revenue codes provide additional information about the service rendered.
- So when an outpatient facility claim is ETL’d, its associated revenue code will be placed in a row in the cost table and that row will refer back to the procedure_occurrence/measurement/etc
- Additionally, revenue codes can be reported without being associated to a particular service.
- These revenue codes will also be put into a row in the cost table, but the row will refer back to the visit_occurrence generated for that outpatient facility claim
- All services rendered in an outpatient facility have a revenue code associated with them. Revenue codes provide additional information about the service rendered.
- Renamed “average_wholesale_price” to “cost”
- There are some datasets that provide cost information for services rendered, etc, and it would be nice to capture these costs when available
- E.g. If a hospital provides cost-to-charge ratios, the product of the charge and cost-to-charge ratio can be stored in the cost column
- Average Wholesale Price can be still be stored in the “cost” column when a cost row is associated to a drug_exposure
- There are some datasets that provide cost information for services rendered, etc, and it would be nice to capture these costs when available
@Patrick_Ryan, the columns present in the original cost tables seem to closely mirror the information that is reported in the ANSI 835 specification, which is, of course, behind a paywall, but if you look at loop 2110 of the PDFs linked on this page, you can see most of the fields associated with payments for services.
All major payers in the US use the ANSI 835 specification to transmit electronic Explanation of Benefits (EOB) information to providers and hospitals. Accordingly, we’re reasonably confident that the cost table we’re proposing will be able to capture cost and payment information from claims data and EHRs.
Cost information, when it is provided, is normally reported from the payer perspective. Accordingly, for most claims-based datasets, any given procedure_occurrence, drug_exposure, visit_occurrence, etc will have only a single associated row in the cost table. If your source dataset has payment information for more than one payer, each service would have a row in the cost table for each source of payment (e.g. payer or patient). E.g. if a patient has primary and secondary insurance and you have two payment records for a service (one record for each payer), you’d put two rows into the cost table for that service.
Lastly, @Christian_Reich, @Vojtech_Huser, @Mark_Danese, we definitely need to implement some sort of fix to the CDMv5 in order to accurately capture cost information for our upcoming ETLs of the CMS data. We intend to implement this unified cost table in a sandbox version of the CDM for those upcoming ETLs.