OHDSI Home | Forums | Wiki | Github

How to represent visit payer information in the model?

For our network, we have hit a bump where we will at some point need to link payer information to a visit occurrence record. This is particularly important where for a given visit there can be multiple payers associated. We have proposed to introduce the following table structure:


The visit payer table documents insurance information as it relates to a visit in visit_occurrence. For this reason the key of this table will be visit_occurrence_id and plan_id.

Have networks encountered this issue? How did you solve it? Should we take another approach?


Wait. We have that already, have we not? In the VISIT_COST table we have the field payer_plan_period_id, which links to a record in the PAYER_PLAN_PERIOD table. There, you have a place for the payer and for the plan. You don’t have any more details, because all the plans are different. So, plan_type and plan_class are something that we didn’t put in the table, mostly because of lack of use case.

Do you want to give it a shot to amend this structure, rather than to replace it?

@Christian_Reich: OK, I’ve been staring at this for a while, and there are three issues we need to deal with for our use case.

The first is minor: visit_cost contains a bunch of fields about, well, the visit costs, that we don’t have; we just need a link from visit to payer. The upside is that they’re all optional, so we could in effect use visit_cost as a visit-to-payer linking table at the cost of storage space, which is reasonably cheap.

The second is more significant: we typically have payer and plan but not period. This creates problems using payer_plan_period, because the one thing that’s required is the period. I don’t think it makes a lot of sense for us to create millions of single-day records to get the plan info in; it’s both really inefficient and makes it hard to recognize common payers. (There’s a separate discussion to be had about synthesizing coverage periods from utilization data, but I’ll bet we all agree that just lumping all instances of a payer or all per-patient instances of a payer into a single payer_plan_period is not a pretty thought.) One possible solution: normalize the payer info out of payer_plan_period into its own table, say payer, and sub into payer_plan_period a foreign key to that table. For our use case, we could link directly to payer by adding a visit_payer column to visit_occurrence (could even add that to the CDM, since I’ll be we’re not unique, but happy to discuss).

The third issue, also minor, is that our analytic requirement is principally for the plan_type and plan_class info; we need to put it somewhere. I’d vote for the payer table – I’m clearly biased, but I do think public-vs-private and managed-care-vs-fee-for-service, to pick two examples, are common enough use cases that the additions would be beneficial. The alternative in the current CDM would be to add the type and class as observations and link via fact_relationship, but there again a person_id is required.

Any thoughts?


Not sure I can follow completely. Mostly because I am not really familiar with how it works. I understand from what you are saying that we don’t get distinct periods of coverage with distinct benefit plans.from the data, but only the current coverage at anyone encounter. And you wouldn’t want to reconsitute or extrapolate what the coverage might have been. Correct? But we know the payer.

Would it be enough to use the payer-plan-period table without the plan portion of it?

@Christian_Reich: The basic problem with payer_plan_period is that it’s mostly about period, and we’re looking mostly at plan.

You’ve pretty much stated the input side: what we have is that at visit X or for charge X the payer was Healthco Prime Sunrise. We also know that Healthco Prime Sunrise is a Medicaid managed-care plan, and that’s what we need for our analytics. I guess we could use payer_plan_period if we modified the DDL so that the dates weren’t mandatory, and took the source value as the plan ID, and linked the visit through fact_relationship, but I’m thinking you have a simpler solution in mind and I jut missed it?

Hi @bailey,

I’d like to offer you an idea I had about your issue, but please note that I am not volunteering to implement the solution I propose. I’m already working on at least two other modifications to the CDM and the payer_plan_period table works well enough for me as it currently stands.

However, while I was crafting a proposal for a unified cost table, I kept your issue in the back of my mind and I would be remiss if I didn’t share my thoughts on how I would approach your problem. If you like my suggestions, please feel free to adopt them and implement them.

Even though I’m already on three topics (now four) requesting CDM and vocabulary changes I prefer to make as few changes to the CDM as possible. I’m leery of adding a payer or visit_payer table. However, I’m also not happy with how payers are stored in the CDM. Specifically, I don’t like that we have payer_source_value and plan_source_value columns, but no standard vocabulary to represent payers and plans. There actually is a standard vocabulary for representing payers in the US. Those Payer IDs in the first column are used nationally to uniquely identify a payer. I’d love to see this list become a new Payer vocabulary in the concept table for the v5 vocabularies. My concern is that without a standard vocabulary for payers, each ETL will use different names in the payer_source_value field and we won’t be able to do analysis of payers across different CDMs.

I think creating the Payer vocabulary would remove your need for a payers table. Instead, the payer_plan_period table would have a payer_concept_id column which would store the concept_id of the payer found in the concept table.

Now, here’s where we take it to the next level. One cool thing about vocabularies is you can build hierarchies. So now that we have each payer stored in the Payer vocabulary, we can build a hierarchy using the concept_relationship table to represent the information you were proposing to capture in the plan_class field of your visit_payer table. I.e., payers like “aetna”, “anthem”, “blue shield” would all have a parent concept of “Private/Commercial Payer”. Likewise “Medicare - California” and “Medicare Railroad” would both have a parent concept of “Medicare Payer”. Then, when you want to find all payer_plan_periods that are associated with commercial payers, you’d first find the “Private/Commercial Payer” concept, find the concept_ids of all of its descendants, and look for those concept_ids in the payer_plan_period.payer_concept_id column.

But wait, there’s more!

The unified cost table I’m proposing allows a row in the cost table to be assigned to visit_occurrences, procedure_occurrences, etc. The cost table contains a payer_plan_period_id column. So to associate a visit to a plan, you could use the cost table as a join table between visit_occurrence and the appropriate payer_plan_period. You pretty much already suggested that yourself. But, if you found you needed to associate a specific service to a plan, the unified cost table would allow for that join too. No need for the fact_relationship table.

As for your proposed payer_type column, I’d love to see this too. I imagine we could add a few concepts to the concept table to capture HMO, PPO, etc and then store a reference to those concepts in a payer_plan_period.plan_concept_id column.

As for payer_plan_period_start_date and payer_plan_period_end_date, I’d just store some bogus dates in there or maybe synthesize coverage periods. It doesn’t sound like your analysis cares about those dates anyway.

So ultimately what I’m proposing is that we add payer_concept_id and plan_concept_id to the payer_plan_period table along with some vocabularies to support them. Then we add in a few concepts to let us build a hierarchy around the Payer vocabulary to lump payers into Commercial, Medicare, Medicaid, etc. Lastly, the unified cost table becomes a join table between plans and practically any other domain in the CDM.

1 Like

Thanks for the suggestion! I think the notion of representing plan characteristics in the vocabulary is great, if we can come up with the right ontology.

As far as recording the data, I’m afraid the payer_plan_period table is a nonstarter for us. The critical problem is that we – I believe similarly to most cases that aren’t starting from claims data – have payer and plan data, but no PERIOD. And payer and plan are optional in payer_plan_period, but period is required.

So for now we’re going with a visit_payer table to test out its behavior, and will be happy to contribute it to the sandbox when that’s ready. I’ll also keep an eye on the unified cost table, as it might work nicely instead.

Would this be very difficult?

Very nice. Also need to remember that a person may have dual coverage - primary coverage from one health plan (govt health plan) and secondary coverage from another health plan (private).

thank you for these ideas. is vocabulary enhancement to include this possible?