Hello
I’m relatively new to OMOP and am currently modeling transformations to claims data. I’m stuck on how to address multiple providers on a claim line and would appreciate feedback.
Context on Claims Data
Healthcare claims data is generally structured in a Header/Line format. From OMOP’s documentation, it seems like the standard is to model using visit_occurence and visit_detail, with each distinct claim_header existing as a record in visit_occurrence and each claim line existing as a record in visit_detail.
An important feature of claims data is that each line contains multiple providers - for example Medicaid/Medicare claims from CMS have “billing” providers and “rendering” providers. There might also be other types - e.g., billing, rendering, referring, prescribing, attending, operating.
Problem Statement
Problem TLDR: it looks like claims data requires additional Foreign Keys for providers and/or a provider_type modifier.
OMOP data structures and ETL guidance suggest choosing the most important provider and using that to populate provider_id. That seems insufficient for claims research - many use cases require visibility to the different providers.
I am looking for the best way to model claims data into OMOP without losing information on the multiple providers tied to each claim line.
I would appreciate guidance on the best practice here. I have listed a few ideas below, but am open to guidance on other (better) approaches.
Ideas on Path Forward
A. Leave provider_id null on the visit_occurrence and visit_detail tables. Instead, use the fact_relationship table as a bridge table linking the fact (visit_detail) to the dimension (provider). The fact_relationship table would need to have a custom vocabulary describing the relationship type as {billing_provider, rendering_provider, referring_provider}.
This seems feasible but unconventional, and potentially counterintuitive to researchers. The bridge table would be long - 3x as many records as the visit_detail table if data retains billing, rendering, and referring providers.
B. Leave provider_id null on the visit occurrence and visit_detail tables. For each visit_detail record, insert on additional child visit detail record per provider type linking to the appropriate providers. This seems to be what the OMOP docs suggest, but it introduces granularity challenges if researchers need to join visit_detail records in a 1:M parent-child fashion.
C. Supplement the standard visit_detail table with a sidecar table listing additional provider_ids. This supplemental table would look like:
{visit_detail_id, provider_1_id, provider_1_concept_id, provider_2_id, provider_2_concept_id, … maybe more FKs}. It would have a 1:1 relationship to the visit_detail table. There are some variations on this approach but the general idea is to make an entirely new non-standard table, which obviously impacts interoperability.