OHDSI Home | Forums | Wiki | Github

How to represent insurance companies?

Implementers
#1

We are converting a big dataset containing both EHR and questionnaire data. Some of the clients are insurance companies that wish to look at data from several care sites they manage.

How can I represent that insurance company in OMOP? They are not a care site nor there are concepts for care site that fit the insurance company description.

I understand that insurance data can be kept with payer_plan_period but this does not represent the entity insurance company, it representes an interaction between a payer and a person.

One of our ideas was a custom Organization table that can group several care sites into one entity and that organization would have a concept_id such as Private Health Insurance

#2

@joaofonseca9:

Not following. You have EHR data with insurance information in it, or you have data from insurance companies (one at a time I assume)?

And what is wrong with the payer field in PAYER_PLAN_PERIOD?

#3

Payer field works perfectly fine but was wondering if there is space for a payer table.
In our use case, the insurance company needs to be treated as a separate entity to:

  • Connect that entity (payer) to several care_sites on which they act
  • Do hierarchical relationships between payers, i.e. insurance company 1 performs payments using a child insurance company 2. So in an analysis, company 1 will see data where payer=company 2 but not the other way
#4

That sounds like a direct use-case for FACT_RELATIONSHIP table.

It is not my favorite thing to suggest, but it seems perfectly fitting here.

You will need some unusual concept to represent these relationships, luckily there are a lot of them in SNOMED. They are not “approved” for use in Standard SNOMED concept, but they are kept for use-cases like this one.

1 Like
#5

You have that information, @joaofonseca9?

Or this?

And what is the use case for having that model?

#6

I have both infos. What we decided was:

Use case: A big insurance company will contain smaller payers and will act on several care sites
Solution: One OMOP-CDM database for the big insurance company X (so the info about the insurance comes from the tenant of the data itself) and the payers are the X and all other subsidiaries, smaller payers. Their relationship is done with concept_relationship

t