OHDSI Home | Forums | Wiki | Github

Vocab Request - Additional Type Concepts for Claims Provenance

Vocabulary Users
#1

Hello all, this is my first time requesting vocab modifications (but it does tie back to some previous forum conversations, linked below), so I apologize if I’m missed anything, posted in the wrong place, etc. Please see below and advise on next steps.

My goal:

  • Annotate records with provenance showing that they are from a particular claim type and include the “open”/“closed” adjudication status. As an example, a specific record may come from a “closed professional claim line” or an “open dental claim line”.

The issue:

  • This is not currently possible in the OMOP schema using standard vocabularies. The standard vocabulary Type Concept provides the ability to delineate claim type (id: 32871 “Professional claim”, id: 32844 “Facility claim”, id: 32816 “Dental claim”, etc.). That same vocabulary also has records for id: 32875 “Payer System” and id:32867 “Primary Provider System” which can roughly translate to “open” pre-adjudicated claims or “closed” adjudicated claims. The trouble is that there aren’t any vocabulary entities that combine this information.

Why is it important to retain this information?

  • Claim type (Professional, Facility, Dental, etc.)
    • Provide researchers with a general understanding of provenance
    • Understanding claim type is critical for researching things like policy interventions, utilization patterns, etc.
  • Adjudication status
    • Post-adjudication (“Closed”) claims are generally viewed as higher quality for most use cases. They represent completed transactions that have been thoroughly reviewed, with any discrepancies resolved.
    • Pre-adjudication (“Open”) claims frequently have more data, but also missing claims and duplicates which affect research findings if not properly understood and managed.

Also, adjudication status is critical for the cost table to work correctly, which is something Vojtech pointed out in the other post.

My Proposal:

I am requesting that OMOP modify their standard type vocabulary to include additional entities that can create a hierarchical relationship grouping by claim adjudication status.

This picks up on an exchange I originally had with several others on the forum, including @Vojtech_Huser . I believe the below captures what Vojtek advised at the end of this post.

Also, for quick reference, here is the existing standard vocab list for aall type concepts with “Claim” in the name is here.

An example of the new members I am requesting is below, with new entities labeled with a *

  • Dental claim

    • Approved dental claim*

    • Rejected dental claim*

    • Pre-adjudicated dental claim*

  • Facility claim

    • Approved facility claim*

    • Rejected facility claim*

    • Pre-adjudicated facility claim*

  • Inpatient claim

    • Approved inpatient claim*

    • Rejected inpatient claim*

    • Pre-adjudicated inpatient claim*

  • Outpatient claim

    • Approved outpatient claim*

    • Rejected outpatient claim*

    • Pre-adjudicated outpatient claim*

  • Pharmacy claim

    • Approved pharmacy claim*

    • Rejected pharmacy claim*

    • Pre-adjudicated pharmacy claim*

  • Professional claim

    • Approved pharmacy claim*

    • Rejected pharmacy claim*

    • Pre-adjudicated pharmacy claim*

The leaf-level new members shown above would also roll up to existing members in a separate hierarchy, shown below:

  • Adjudicated Approved Claims*

    • Approved dental claim *

    • Approved facility claim *

    • Approved inpatient claim *

    • Approved outpatient claim *

    • Approved pharmacy claim *

    • Approved professional claim *

  • Adjudicated Rejected Claims*

    • Rejected dental claim

    • Rejected facility claim *

    • Rejected inpatient claim *

    • Rejected outpatient claim *

    • Rejected pharmacy claim *

    • Rejected professional claim *

  • Pre-Adjudicated Claims*

    • Pre-Adjudicated dental claim *

    • Pre-Adjudicated facility claim *

    • Pre-Adjudicated inpatient claim *

    • Pre-Adjudicated outpatient claim *

    • Pre-Adjudicated professional claim *

    • Pre-Adjudicated pharmacy claim *

4 Likes
Cost table spec improvement and interest in health economics
#2

Hi @Dan_Angelelli:

By “pre-adjudicated” you probably mean open claims that have been submitted (aka invoices) and the payer hasn’t reacted yet. There are also special pre-adjudication services which scrub claims before they go into the system to give them a better first-pass chance of approval. Or do you mean to get that distinction?

#3

By “pre-adjudication”, I just mean “open claims that have been submitted (aka invoices) and the payer hasn’t reacted yet.”

2 Likes
#4

@Dan_Angelelli:

Ok.

Next question. We currently have the following claims: Claim, Dental claim, Facility claim, Inpatient claim, Outpatient claim, Pharmacy claim, Professional claim, Vision claim, Facility claim detail, Facility claim header, Inpatient claim detail, Inpatient claim header, Outpatient claim detail, Outpatient claim header, Professional claim detail, Professional claim header.

According to your idea, we would have to triplicate them, by adding one pre-coordinated concept for each “Open” and “Closed”. That would make it 16*3=48 of them. Do you think that is necessary?

What’s the use case anyway for all of this? Usually, the entire database is either Open or Closed Claim. Why would you query each record?

#5

Addressing the 1st point:

I don’t know that you would need to triplicate all of those. The list you pasted in has the generic “claim” and also the more detailed “claim header” and “claim detail” for each type of claim. I can certainly see the case for consistency and applying the 3-status approach to all of those, but as you said that makes way more concepts.

IMO, it’s a reasonable to apply this logic just to the 7 more generic “claim” concepts ( Dental claim, Facility claim, Inpatient claim, Outpatient claim, Pharmacy claim, Professional claim, Vision claim) and not to the corresponding “header” and “detail” concepts. You also don’t need to apply this to the “Claim” concept - the proposed “Adjudicated Approved Claims”, “Adjudicated Rejected Claims”, and “Pre-Adjudicated Claims” parent-level concepts already address that.

So it would actually be 7*3=21, not 48. (I missed “Vision” in my original post when I listed the claim types).

Addressing the 2nd point:

21 new concepts is still not nothing, so I hear you on needing the use case.
I’m currently transforming data for a large population into OMOP. That data includes a mix of open and closed claims + rejections, primarily from commercial data providers. There are also plans to add more data sources down to road to build a more complete profile of the population.
So I am currently working with a database that is a mix of open and closed claims.

I was hoping the Why is it important to retain this information? section, above, explained the use case but let me know if that isn’t sufficient. I’m an engineer, not a researcher, so I’m trying to accurately represent the use cases from the researchers.

#6

Checking back on this. What can I do to help move this forward?

Also @Vojtech_Huser, is this request roughly in line with what you outlined in the post linked in the 1st message?

#7

@Dan_Angelelli:

The process of adding concepts is straightforward. You would fall into part I.

However, I am not yet sure this is the right thing to do. Here is why:

Type Concepts are there to denote the provenance of the information. It is not some way to add detail to some fact. So, a “Rejected facility claim” would be a justified addition if you obtain those records from a different source than “Facility claim”. But my hunch is you would not. You want to add an additional fact that a claim was rejected. The Type Concepts are not there to do that.

This is different for, say, Open and Closed claims. They have very different capture processes and therefore their interpretation can differ substantially (for example, the Open Claims contain the invoice prices, often fantastically high, while the Close Claims contain the actual paid amounts).

I can see valid use cases (rejected claims means often limited access to healthcare, and that ought to have consequences). Which is where this probably belongs: The COST table (if it happened but wasn’t paid), or in case of a denied pre-approval some OBSERVATION record (if it never happened).

Something like that?

#8

@Dan_Angelelli You should make your new concept request. Don’t consider replies on forum to capture/reflect the whole community.

I want to add one other example.

Patient had iron level measured in blood. It was part of visit for an infections disease. (the only diagnosis on the claim)

Insurance rejected the iron blood line on the claim because the claim did not indicate a corresponding diagnosis justifying the iron test. A mistake of the billing office.
Payor did approve the claim items that were related to the infectious disease.

(btw: Lab results are not included in the dataset. So the only way to capture patient centric events is via claims.)

The iron testing is the truth that happened to the patient. (“for the patient centric folks in the room”)

Closed claims will thus have incorrect view of the patient life. An important follow up care on previously low iron in blood will be excluded from the CDM.
(it will look as non adherence to guidelines for monitoring low iron in blood).

With bundled care, similar distortion of details occurs.
Btw, I am not saying some opposite use cases also happen (fraud, inventing events or overbilling)

You can also argue in the opposite conclusion that @Christian_Reich said about provenance.

The only row about the iron test IS THE PROVENANCE of the information - that would otherwise be not in the CDM at all.

In this case, iron test row is THE ONLY row reflecting reality.

Anything else (any other solution) is not doing justice to the ambition of CDM to milk out as much information as possible from claims.

In my view, nothing wrong with extra level of provenance detail in a type concept.

It is similar dynamic that you run into diagnoses and those that come from NLP. Folks ignore type concept explicit statement and then complain that their cohorts are too big because they “pick up the NLPed concepts”.

And their solution is to not put NLPed concepts at all into the Dx table of the CDM (just because their cohort definitions were not explicitly limiting themselves to fromClaims diagnoses).

There is complexity of the source data that renders certain cohort definitions not specified enough. (not to the ideal level of detail.)

The solution of the conundrum should not be to ban the extra complexity from entering into the CDM [data]. Instead, one has to increase the complexity of the cohort definitions used.

#9

@Vojtech_Huser:

No question that a claim rejection shouldn’t be construed as that the claimed action did not happen. It just did not fit some formal requirement or is not covered by the payer’s policies (which itself could be incorrect).

Still, a type concept is not the place to collect that information. The type concept just says where I know a certain fact from, so it can be interpreted for it’s validity.

I think the best home would be the COST table. Because that’s what this is: A payment was rejected.

#10

I like @Christian_Reich 's point about provenance being scoped to a literal definition of “where did the row come from”, but I think there are some complexities here.
For one - I may be getting the data from a single provider, but in my case that provider is combining data from different sources and the best understanding I have of that non-OMOP provenance is via the combined adjudication status and type (prof, facility, etc.) described above.

I can see the argument for putting rejection/approval status into the COST table, but IMO that becomes a bit convoluted.
If you think about the lifecycle of a claim, it starts as pre-adjudicated (open) and then is adjudicated to essentially 2 states - adjudicated-approved and adjudicated-rejected.

. . . . . . . . . . . . . . . . . . . . . . ┌─► Adjudicated-Approved (Closed)
Pre-Adjudicated (Open) ──┤
. . . . . . . . . . . . . . . . . . . . . . └─►─Adjudicated-Rejected (Closed)

It seems like unnecessary complexity to push a requirement onto researchers/users to join a lot of things to the COST table if all they want to do is select down to a population of approved closed claims. That design pattern seems like it’s breaking that information into two areas (type_concepts and cost attributes) and requiring users to specify multiple conditions when one condition should suffice.

I appreciate both of your feedback!

I’m still of the opinion that a hierarchical relationship in the type_concepts makes sense and is a good use of the tools already built into OMOP. Even if we set the approved vs rejected distinction aside, a simplified hierarchy similar to what I’ve described above would be needed to describe pre-adjudicated vs post-adjudicated while also retaining the type of claim (e.g., distinguishing a “Pre-Adjudicated facility claim” from “Adjudicated facility claim”).

If an update to the vocabulary ends up not being the way to go, I think a separate column like adjudication_status_concept_id would be reasonable as a claims-specific extension to the OMOP model. But that would be a bigger change affecting many tables (visit_detail, procedure_occurrence, condition_occurrence, etc.) and would still essentially be describing “what type of data is this” so it is not my preferred path forward.

Thanks for the guidance! I plan to return to this thread after working through the vocab request.

#11

Linking an old post on how we define the type_concept_id field:

So, based on your use case:

Your answer will be ‘facility claim’ for both of the above examples. We should NOT cram further information into the field. That is why we split the condition_status information out of the type_concept_id field long ago.

I suggest you follow up on your idea:

And compare it to @Christian_Reich suggestion using real data and real questions.

#12

Hm. A population can only be patients (or, maybe, providers, but we have seen no such use case in reality). OMOP has no concept of a “claim”. All it has is records of medical events that occurred to patients. The only reference to a claim is in the type concept: we know about an event because it was used as justification for reimbursement. Approved or rejected merely determines whether there is a $ amount in the COST table or not. The event itself happened, and it did so way before those funds were processed.

I understand what you are saying. But again, these are different things. The event happened. Later on, some money was paid or not. Take a diagnosis: the payer doesn’t “reject” the diagnosis. The payer rejects the payment for some treatment for which the diagnosis was used to justify. Which means, the events and the payments are logically and temporally completely independent from each other, and the type concept for one must not refer to the other.

I do have empathy why you don’t want to put it on the COST. Apart from the extra join (which is easy since it is a one-to-one FK-PK situation) another reason is that we may not have cost information. We only know it was paid (approved) or not (rejected). Maybe we expand or extend the COST table to reflect that, for example by adding a field “reimbursement_claim” and the concepts “approved” or “rejected”.

Thoughts?

#13

Thanks, all! Sending a big response then I probably won’t respond until the new year.

@MPhilofsky , that does sound very similar so maybe this design decision is already made. I’m not thrilled about creating an extension column in lots of tables (every table with a “type_concept_id” field), but it seems doable and easy enough to think through. That linked post was helpful.

@Christian_Reich on your idea about using COST

I want to echo back to check for understanding.

  1. Keep the “type_concept_id” fields simple. Form most claims use cases, they would get a value of id: 32871 “Professional claim”, id: 32844 “Facility claim”, id: 32816 “Dental claim”, etc. (or maybe something less granular)
  2. Add a field to the COST table called “reimbursement_claim_id” with accepted vocab of “approved” or “rejected”
    • If it’s going to differentiate “open” claims from “closed”, it would need a 3rd option for that. But I think an extension column is better.
  3. Every record sourced from claims in the visit table and the domain tables would link to a record in the cost table.
    • Procedure records and visit records with drg codes would generally have a cost, so this fits well
    • Lots of other records, e.g., condition and measurement, and sometimes things like procedures and visits don’t have cost, either due to data quality or b/c they just aren’t directly associated with costs. For these, they would still link to the COST table, most fields in COST would be NULL, but the new “reimbursement_claim_id” would be populated.

Some impacts of this:

A. The COST table probably gets bigger - Every visit record, procedure record, condition record, obs record, measurement record, drug_exposure record, etc. gets a corresponding record in the cost table

B. If users need to differentiate between data sourced approved claims and rejected claims, all their queries must include joins to the COST table.

C. If users want to differentiate data sourced from claims vs data sourced from something else (e.g., EHR), they’d still use the “type_concept” fields

I’m going to take this back to my group and workshop it, probably revisiting it after the new year. My initial reaction, though, is below.

I see how using a flag in the COST table could work, and I see the benefit to keeping the approval/rejection status within the COST domain. It seems like a decent solution for that narrow use of approved/rejected, but has the complementary downsides of making the COST table potentially much larger and requiring it’s use in many more queries.

#14

@Dan_Angelelli

Here’s a poster on customizing your OMOP CDM.

t