OHDSI Home | Forums | Wiki | Github

Cost vocabulary - addition to OMOP

CDM Builders
#1

This is a continuation of discussions at the OMOP CDM and vocabulary workgroup



Proposed changes were accepted by the WG. Vocabularies were proposed during this process and @Dymshyts is in the process of putting the proposed cost concepts into OMOP CDM. The vocabulary approved are here . Vocabulary specific discussions are at GitHub issue above.

Before putting the vocabularies into OMOP CDM, @Dymshyts and I decided to post it on the forum for any issues we may have not captured. Specifically, on looking at the Google Docs, please provide input on

  • our proposal for the use of concepts_class_id and domain.

  • there are some concepts that belong to the domain ‘Type concept’ and are to be used to populate the field cost_type_concept_id, but most of the proposed concept belong to the ‘Cost’ domain and are to be used to populated cost_concept_id

  • if the domain is ‘Cost’ then we are using two concept_class_id ‘Detail’ vs ‘Summary’ - to avoid any ambiguity that may lead to computation errors, mixing up cost detail and cost summary.

  • vocabulary_id for all is ‘Cost Type’

#2

I agree with the proposal too.
the classes and domains corresponds to the overall vocabulary logic.

I’ll wait till the end of the week letting people react on this and then add the concepts to the vocabulary as they are listed.

#3

Thanks @Gowtham_Rao and @Dymshyts for putting this together. I like the ‘Detail’ and ‘Summary’ concept_class_ids, especially since there was some concern about how to store total cost in the new Cost table. The only thing I am not sure about is the vocabulary_id ‘Cost Type’. It is a little confusing to have concepts with a domain of ‘Type Concept’ and vocabulary ‘Cost Type’ since the word ‘type’ may have two different meanings.

In the previous Cost table, there were only three concepts in the Cost Type vocabulary and they were meant to describe if the cost was paid, charged, or incurred:

5031 Amount paid by the patient or reimbursed by the payer
5032 Amount charged to the patient or the payer by the provider, list price
5033 Cost incurred by the provider

Many of the new concepts in your list comply with the idea of paid, charged, or incurred, though some do not. Something like ‘Premium, employee contribution’ wouldn’t make sense to be in the Cost Type vocabulary, though it does make sense to have the domain of ‘Type Concept’. Maybe instead of the Cost Type vocabulary we use the more generic vocabulary_id of ‘Cost’? I could even see something like a vocabulary_id of ‘Financial’ and then the concepts that represent a monetary value, like ‘Deductible’, could look like this:

domain_id Cost Type
vocabulary_id Financial (or something just as generic)
concept_class_id summary

#4

Focusing on Type Concept’s only here

For vocabulary_id: I think ‘Cost Type’ will stay with the vocabulary_id ‘Type Concept’ - because some are preexisting (although I will argue that we need deprecate them - see below).

My understanding of the use of Type_concept_id in other OMOP tables are used to represent attribute of the data-source, rather than attribute of the data-record. e.g.
Measurement_type_concept_id – eligible type concept_id

Procuedure_type_concept_id – eligible type concept_id

‘5001 Test ordered through EHR’ - sounds like an attribute of the data source, i.e. the data source is EHR, vs. Patient reported value etc. While ‘5031 Amount paid by the patient or reimbursed by the payer’ sounds like an attribute of the datum/record. If this was, ‘Financial record reported by Patient’, or ‘Financial record from a claim’, or ‘Financial record from EHR’ – this would be a ‘Type concept’ and be an attribute of the data.

We did not have cost_concept_id in legacy cost table, but we have in OMOP 5.3+ cost table. The concept_id 5031, 5032, 5033 sounds like a _concept_id (attribute of the datum/record), rather than attribute of the data source. So, it is not

the provenance or the source of the COST data:.
hence, I argue that we should remove it.

Based on this argument, new ‘Type concept’ for cost belonging to the vocabulary ‘Cost Type’

We may need more, to represent the concepts ‘Financial record reported by Patient’, or ‘Financial record from a claim’, or ‘Financial record from EHR’ . Happy to add and more them as Type-concept-id, based on the discussion here

#5

Focusing on cost-concept in this post

Note: the domain_id is new here, and the domain_id is ‘Cost’. Not ‘Cost Type’

Two new concept_class_id’s are being proposed to avoid ambiguity
concept_class_id: Summary
concept_class_id: Detail

I think we need to develop conventions for use of ‘Detail’ vs ‘Summary’, but almost always depends on how the source data gives us the data. In US claims, one header claim record, may have one or more detail record. Costs may be attached to the header claim record, and/or the detail claim record. Generally (depends on the quality of source data), sum of costs in detail claim record = cost in the header claim record. e.g. if there is one inpatient claim record header with 10,000$s and this header record has 5 detail record with 5 revenue codes each for room and board, ICU stay, blood transfusion, ambulance etc then each of the revenue_code would have a cost attached to it. See post by @jenniferduryea Proposal for a Unified Cost Table If the source data does not give us information on whether the data is summary or detail, then we default it as ‘Summary’. We should not be adding up, ‘Summary’ and ‘Detail’ - because then that would be double counting

Agree with you that current proposed vocabulary_id ‘Cost Type’ creates ambiguity. I chose that vocabulary_id to represent the new concept_id’s to avoid needing to create a new vocabulary_id. We could create a new vocabulary_id called ‘Financial’ or just ‘Cost’. @Christian_Reich, should we create a new OMOP vocabulary_id or should reuse existing OMOP vocabulary_id? If we re-use ‘Cost Type’ vocabulary_id, then the same vocabulary_id would be used across domain_id (‘Type Concept’ and ‘Cost’).

#6

I’m a little confused about this, mainly due to my lack of expertise in the
cost information you are referring to, so bear with me.

TYPE_CONCEPT_ID fields are intended to capture the provenance of the data.
So, where did the cost information actually come from? I could imagine
across our community we may see costs coming from various sources,
including from ‘claim submitted by patient/provider’, ‘claim
adjudicated/reimbursed by payer’, ‘hospital billing summary’, ‘patient
self-report’, etc…(I’m sure there are more nuances and defer to
@Gowtham_Rao and other experts there)

The CONCEPT_ID is intended to describe the entity that is represented in
the data. So, what is the the dollar amount stored in the data record, a
cost paid by patient for out-of-pocket, co-insurance, deductible, a cost
incurred by payer, etc.? It would seem this construct could be quite
useful if anyone had the data and wanted to try to reconcile charge vs.
paid amounts (as those could be differentiated by CONCEPT_ID).

Amongst the items proposed, it’s unclear to me how to think about
‘Premium’. Is ‘premium information’ a separate data feed separate from the
claims processing (in which case it makes sense as a TYPE_CONCEPT_ID)? Or
is it simply a cost that a patient (and potentially employer) incur to
acquire coverage (in which case it makes sense to be stored as a
CONCEPT_ID)? It could imagine it could be either or both, depending on
the source data.

#7

Thanks @Patrick_Ryan. Agree with your comments on TYPE_CONCEPT_ID, my thoughts above are in line with yours

We are in agreement.

Agreed again - please see two posts above.

Premium - i agree is confusing. This idea started here https://github.com/OHDSI/CommonDataModel/issues/81#issuecomment-348299195 @Vojtech_Huser thoughts?

As a ‘Type concept’, it would be information such as
‘Premium recorded by payers system’
‘Premium self reported by person’
‘Premium derived from employers benefit system’

As a ‘cost concept’, it would be concepts such as

#8

Hi all!

Is there the final version of the concept list I’ll add to the vocabulary?

#9

@Dymshyts for cost concept id’s, should we create a new vocabulary_id called ‘Cost’ or re-use existing vocabulary called ‘Cost Type’. This is different from Domain_id ‘Type Concept’ and ‘Cost’. Other than that, I say - please add.

Final version is in the Google Docs here

#10

I’m a bit confused:

but

do you mean, we need to add these concepts as is in google doc (with vocabulary_id = ‘Cost Type’) but add the vocabulary_id = ‘Cost’ for future purposes?
or Modify these concepts from google doc making vocabulary_id = ‘Cost’?

and first 3 concepts need to be deprecated, right?

#11

Thanks @Dymshyts

In OMOP vocabulary we currently have vocabulary_id = ‘Cost Type’ . All the current concepts in this vocabulary_id belongs to the domain ‘Type Concept’.

The proposed list of concept_id’s does the following:

  1. Proposes some concepts in the domain_id =‘Type Concept’
  2. Proposes some concepts in the domain_id = ‘Cost’ - this is a new domain_id

For the new concepts proposed, for concepts that belong the domain_id ‘Type Concept’ - i am proposing we use the vocabulary_id ‘Cost Type’.

For the proposed concept’s that belong to the domain_id ‘Cost’ - initially I proposed to use the vocabulary_id ‘Cost Type’. But someone expressed that it may cause confusion because the vocabulary_id ‘Cost Type’ has ‘Type’ in it, implying it is ‘Type Concept’. But it is not. So - to prevent that we could use a NEW vocabulary_id = ‘Cost’. But then, that means we are adding a new vocabulary_id called ‘Cost’, instead off reusing ‘Cost Type’.

So @Dymshyts to avoid confusion for proposed concepts that belong to domain_id = ‘Cost’, lets create a new vocabulary_id = ‘Cost’

#12

Thanks:)
now we can use this table as is

1 Like
t