OHDSI Home | Forums | Wiki | Github

Vocabulary for Payer Plan Period table

Vocabulary Users
#1

Good morning OHDSI!

Payer plan period table needs your guidance for adding concept_id’s! This topic has been discussed before in the CDM work group, and in the forums.

GitHub https://github.com/OHDSI/CommonDataModel/issues/120 (approved by CDM WG).
Related discussions here and here thread.

We would like to begin adding vocabulary, but before adding wanted to get community opinion one more time

Question for discussion - Could we start by adding one vocabulary for the field payer_concept_id as the first vocabulary? i.e. can we add concept_ids for concepts in this external vocabulary pdf version and its corresponding csv versions are here for your review. Additional reading

@jenniferduryea

2 Likes
#2

Will the top hierarchy concepts be standard concepts? We are usually lucky
if we can distinguish commercial and medicare let alone what type of
Medicare.

#3

The proposed vocabulary from PHDSC can definitely support hierarchy.

image.png1084×364 30.6 KB

In this case Medicare (1) is the parent, while 11 Medicare (Managed Care) is child. etc. All levels may be standard-concepts I think - like in SNOMED or RxNorm.

1 Like
#4

@Gowtham_Rao:

“Medicare Non-managed Care Other” - Ouch!!! Let’s list out. Who cares if the list is a little longer. Or leave out, and then the next Concept up will be used (“Medicare (Non-managed Care”).

#5

@Gowtham_Rao need your expert help. I am still struggling a bit to understand how we can use our existing Payer and Plan vocabulary domains to sufficiently map Medicare part A, B, C and D. In my mind, it should be working like this: Medicare - mapped to payer, and we have a concept or that. For Part A (inpatient / hospital), B (medical) and D (drugs) - and setting C aside for a minute - these should be mapped to the corresponding plan. However, this is what we have today

image
image2466×844 127 KB

there is no corresponding term for Part A, but there are for Part B and Part D?

Then, there is whole different thing called “Medicare Part C” (Medicare Advantage). According to Medicare, this is - “Medicare Advantage Plans, sometimes called “Part C” or “MA Plans,” are an “all in one” alternative to Original Medicare . They are offered by private companies approved by Medicare”. So, in this cases - who should be the payer and what should be the plan type? Apparently, being in Medicare Part C does not necessarily mean it would cover hospital, medical and drugs.

Then I am also confused that we seems to be mixing actually Payers and Management Type (HMO, PPO etc…) in our Payer domain.

Any thoughts?

#6

I think the various types of medicare are non standard (source) concepts.

We created standard concepts to capture plan, sponsor, payor, benefit domains that should go to corresponding standard concept field

#7

Yes. We created the concepts, but not the mapping.

Exactly. We felt that precordinating the mapping in the vocabulary would be a big lift. Plus, we may not have consensus and how do we support international use cases.

We felt it would be best to do the mapping decisions during ETL.

#8

so, which concept would we use to map Part A too since there seems to be no individual concept representing Hospital only plan type?

#9

I would consider creating a non standard concept

#10

Gents:

Are we good with this? Or do we need a powow returning to the choice of concepts we have?

#11

sorry, missed that last message.

I think we need to re-open this discussion and potentially kick off a new mini-project to clean up the cost and payer domains. I do not see a clear way to do multiple things today, for example easily mapping to Medicare Part A/B/C/D, eligibility flag etc…

#12

@SKent - tagging Seamus, seems to be a similar struggle in this domain. Would be good to team up and clean things up together

#13

Hi @Gowtham_Rao
In our source data we have something like this:
payer_name =‘HUMANA’
model_type_name =‘MEDICARE D UNSPECIFIED’

So, we map it to
Payer = 327 Private Health Insurance
Plan 273 Drug only plan

But we have the 308 Medicare Drug Benefit.
Probably this concept should be made non-standard, to avoid the confusion in the cases similar to mine.
What do you think?

#14

We could. I think, at the time - we decided to make the PHDSC vocabulary standard (for good or for worse)

#15

Hello! @Gowtham_Rao I’m working with @Dmytry Dymshyts and I faced some issues in PHDSC vocabulary.

Firstly, there is only one domain_id - “Payer”. However, there a lot of plan concepts (e.g. 324 391 Federal Employee Health Plan) Is it possible to add domain_id “Plan” for such concepts?

Secondly, concept 280 1 Medicare (which is also a plan as I understand) has several “children”, for example, 364 13 Medicare Hospice or 281 11 Medicare Managed Care, but none of them represents real parts of Medicare - A, B, C, D. Should they be added as Medicare A, Medicare B, etc? It can really help during work with this vocabulary.

#16

Hi All,

I’m part of a team working to create an OMOP model for Military Health System (MHS [DoD]) data and looking at the payer plan period table. I found some concepts available for payer under “DoD TRICARE” and “Military Treatment Facility”. I have two issues I’m trying to figure out:

  1. The first aligns with Greg’s question above: I would consider TRICARE the payer for all of these, and so perhaps only one concept is needed for payer. Then underneath that, there are numerous TRICARE plans (Prime, Select, USFHP, etc.). Is it possible to shift the level of granularity captured under payer vs. that under plan?
  2. Some of these values need to be updated (or new ones need to be added). Concept IDs 298 and 299 refer to TRICARE Standard and Extra, which were replaced with TRICARE Select on January 1, 2018. There are potentially some other plans of interest that are not captured in the vocabulary tables yet (TRICARE Plus, TRICARE Retired Reserve). We can use custom concepts for now, but what is the process for getting official updates in the vocabulary?

I’m out on paternity leave pretty soon, so sorry if I don’t respond!

-Keith

#17

I think we need to recap a little history first – According to the book of OHDSI

  • Rationale for domains : Domains are identified and separately defined in an entity-relationship model if they have an analysis use case (conditions, for example) and the domain has specific attributes that are not otherwise applicable. All other data can be preserved as an observation in the observation table in an entity-attribute-value structure.

A technical interpretation is - one domain per unique table in OMOP i.e. one table one domain i.e. condition has one domain. T

When i redesigned the payer plan period table, we had to deviate from this one table because there was no appetite to break the original table (which would have been ideal). So we needed up with one table with multiple ‘domain like’ ideas per row
https://ohdsi.github.io/CommonDataModel/cdm60.html#payer_plan_period

i.e. it captures in one rows, spans of time that are a unique combination of (domain like ideas)
payer_concept_id
plan_concept_id
contract_concept_id
sponsor_concept_id
stop_reason_concept_id

This was a way for us to avoid - breaking up the payer plan period table into 5 different tables… that was the consensus from the vocabulary group.

So yes - we needed 5 new domains for each of this.

#18

Once we had the 5 domains, we need new vocabulary - and we needed to have them classified as standard vs non standard - with standard going to fields like plan_concept_id, while non standard going to plan_source_concept_id

In traditional omop style - we looked for vocabulary that we could import as is - and found many from CMS, PHDSC etc. but they were not ‘clean’ vocabulary (think ICD vs SNOMED) as they did not follow the informatics constructs and were all ‘ugly’. None of them met the ‘standard criteria’

#19

So we had to create our own vocabulary - which was a lot of work… but not many in the OMOP community had data to explore what level of granularity we want to capture the idea in the ‘new omop concepts’. the project never took off. And we stopped here…

#20

Now to answer your question - yes, all these vocabularies that we found are ‘dirty’ and cant be used as standard concepts unfortunately. We need to clean this up.

We could do this thru consensus building i.e. one poor soul goes thru each of this and makes a proposal. Others will review and provide their opinion. And we all agree vs disagree :stuck_out_tongue:

t