OHDSI Home | Forums | Wiki | Github

How to Differentiate Closed Claims data sets from Open Claims data sets

Implementers
#1

I’m working on the modelling / etl for healthcare claims data to OMOP.
The data set has a mix of open claims (claims submitted by the providers, pre-adjudication) and closed claims (adjudicated claims provided by the payers).
I’m stuck on how to differentiate the open claims vs closed claims data in OMOP, which is important information to provide to researchers because closed claims are generally viewed as higher quality.

1st plan:
I was initially thinking that I could use the cost_type_concept_id to capture this, as shown below.
Concept Code Concept Interpretation
OMOP4822212 Provider System Open Claims
OMOP4822218 Payer system (Primary payer) Closed Claims
OMOP4822217 Payer system (Secondary payer) Closed Claims

I’m not sure that’s best though for two reasons -
A) Open (pre-adjudicated) claims should generally have something like a charged/billed, probably co-pay, and maybe allowed amount. Open claims don’t have a “paid amount” though and might not have any amount at the line level, so I’m not 100% sure that every open claims record would hit the cost table (at least for the claim line level in visit_detail).
B) Open vs closed claims seems more like it’s describing the visit_type, and it feels a bit like hiding that important descriptor off to the side if it lives in the cost table.

2nd plan:
I’m modelling every claim line (grain: header_id + line_number) to be a record in the visit_detail table and then will aggregate that up into visit_occurrence so that a visit_occurrence record is basically an episode of care. I think it makes most sense to capture the open claim vs closed claim differentiation on the visit_detail and visit_occurrence records themselves, probably by the visit_type_concept_id.

Here, though, I’m stuck again. I see concepts for medical/pharma/dental claim that all seem like they would represent a closed claim, but I don’t see any concepts that would represent an open medical/pharma/dental claim. It seems like I can add custom concepts to accomplish my goal, but I’m assuming there is a within-bounds way to do this already and I’m just not seeing it.

Can someone provide guidance on how this is typically approached?

#2

To identify the provenance of a record in the CDM, utilize the domain(aka table)_type_concept_id field. The allowable concept_ids for this field are located here. And it looks like you found them:

#3

Can you elaborate what exactly happens during adjudication? E.g., x items becomes y items (y < x, y=x-n) and n items are not-adjudicated.

Do you care about representing money issues (pre and post adjudication)? (items lost as not adjudicated).

Or you are focused on diagnoses (or procedures) pre and post adjudication? (items lost as not adjudicated).

I am partially trying to learn more about this issue from someone who is close to the data.

I am trying to see the later use case (analytical/research question)

  • Study what procedures or diagnoses end up in the n set? That is a very interesting question (as a healthcare consumer).

  • Which payors reject which items?

#4

The difference in quality is two-fold:

  • There is substantial amount of fraudulent claims which payers are trying to weed out. Not sure how successful they are with that. Probably, nobody knows.
  • There are Open Claims that cannot be assigned to a patient, because the identifiable information (name, subscription ID, dob etc.) is wrong. Which results in Open Claims having a substantial amount of semi-duplicates (claims that get reclaimed after they are returned by the payer as erroneous). But these claims tend to be “solitaires”, i.e. the only record for that “patient”. For our type of longitudinal research they never make it into meaningful cohorts, so in reality Open Claims work much better than expected.

The claims that are nominally correct but get rejected for violating a billing rule are actually a quality issue of the Closed Claims. Billing rules are notoriously opaque. They change all the time, and private payers have different (but similar) rules from the Medicare/Medicaid rule set.

And yes, the Open Claims have charges, and the Closed Claims contain what was paid. The charges in the Open Claims tend to be pretty useless, as they often are fantasy prices ignoring what was negotiated between payers and providers. The payers just pay what’s due.

These shouldn’t be just in the COST table, but in all the clinical event tables that get populated from a claim.

That’s not OMOP CDM. It does NOT model claims. It models what happened to a patient. So, if the patient had a hospital visit, and the hospital (facility claim) and a bunch of physician providers or provider groups claimed either fee for service or aggregated (DRG type) claims, you need to consolidate that into one VISIT_OCCURRENCE record. It should last from admission to discharge. The VISIT_DETAIL would point out what happened within that visit, i.e. move between different departments and functions.

Episodes of care could be placed into the EPISODE and EPISODE_EVENT tables.

But again, OMOP is not about reimbursement of healthcare service. You can create your own representation for that. Would be good to show the community what you did. Just don’t abuse the existing tables.

#5

Alright, thanks for all the feedback. There are multiple things to address, but breaking it down into responses below.

@Vojtech_Huser :
I think Christian_Reich explained the Open/Closed difference and what happens during adjudication. The main thing I’m concerned with is that I will eventually be combining data from Open claims into the same place as data from Closed claims, and I need to have a clear way for researchers to know the provenance. I’m not the best person to speak to the different use cases for Open vs Closed, I just want to make sure that people can clearly tell which data they’re looking at.

@MPhilofsky thanks for confirming that those 3 OMOP codes would be how I call out the provenance in the cost table.

@Christian_Reich

“These shouldn’t be just in the COST table, but in all the clinical event tables that get populated from a claim.”

This might be what I’m missing. Can we build out an example? Lets say I have a closed claims data source (e.g., Medicaid payer data) showing that a patient had a procedure that is 100% paid for by Medicaid.

Are you saying that the record in the procedure_occurrence table would have a value of ‘OMOP4822218’ (Payer system (Primary payer) Closed Claims) in the procedure_type_concept_id field?

Also, the corresponding row in the cost table would have the exact same value of ‘OMOP4822218’ in the cost_type_concept_id field? And this cost record would have cost_event_id linking to the procedure record (or possibly both the procedure_occurrence record and the cost record link to the same visit_detail id, tbd)?

@Christian_Reich

You lost me here:

“That’s not OMOP CDM. It does NOT model claims.”

I misspoke when I said “episode of care”. I’m planning on visit_occurrence being aggregated up from visit_detail similar to the discussion in the decision time for visit_detail thread and this separate comment by Gowthan_Rao. The grain for visit_occurrence will be coarser than the claim_header and we’ll use temporal association so that a visit_occurrence is bound by Admission/Discharge/Transfer.
Does that correction address your concern?

1 Like
#6

Exactly.

Perfect.

You got it.

Good luck.

#8

Okay great. That was super helpful and I think I understand perfectly. I have one last question to make sure I’m tracking provenance correctly for cost and the other tables.

Can you confirm that the below is accurate?

Consider below in the context of loading a schema from a single data source that is exclusively closed claims. If that data source flows into all of these tables, the “_type_concept_id” fields would be populated as shown to reflect the provenance.

Table Field for Identifying Provenance FK Class Appropriate Concept Code
CONDITION_OCCURRENCE condition_type_concept_id Type Concept OMOP4976940
COST cost_type_concept_id (Blank in docs, but implied as “Type Concept”) OMOP4976940, or OMOP4976941*
DEATH death_type_concept_id Type Concept OMOP4976940
DEVICE_EXPOSURE device_type_concept_id Type Concept OMOP4976940
DRUG_EXPOSURE drug_type_concept_id Type Concept OMOP4976940
EPISODE episode_type_concept_id Type Concept OMOP4976940
MEASUREMENT measurement_type_concept_id Type Concept OMOP4976940
NOTE note_type_concept_id Type Concept OMOP4976940
OBSERVATION observation_type_concept_id Type Concept OMOP4976940
OBSERVATION_PERIOD period_type_concept_id Type Concept OMOP4976940
PROCEDURE_OCCURRENCE procedure_type_concept_id Type Concept OMOP4976940
VISIT_DETAIL visit_detail_type_concept_id Type Concept OMOP4976940
VISIT_OCCURRENCE visit_type_concept_id Type Concept OMOP4976940

* in cases where there is a secondary payer, the cost table would get an additional row with the secondary payer code.

OMOP4976940 Payer system record (primary payer)

OMOP4976941 Payer system record (secondary payer)

#9

Sounds good.

#10

I don’t know if this is best pursued as a separate post to the vocab group so please let me know if that’s more appropriate.

Now that I’ve gone and tried to map this, I’ve come across another hurdle.

  • My source data is from a mix of open claims and closed claims. I want to reflect that provenance in the type_concept_id fields.
  • That same data is from a mix of professional, facility, and dental claims. I want to reflect that provenance in the type_concept_id fields.

Those attributes are both about the provenance of the data, and there are type concepts that cover all of them. There are not, however, any type concepts that appear to combine those concepts to distinguish a “professional claim from the payer system” from a “professional claim from a provider system”. It seems like I have to choose between tracking provenance for Open/Closed claims (as discussed above) and tracking the provenance as Professional/Facility/Dental/etc. claim type.

I’m a bit stuck because the standard vocabulary doesn’t support those type concepts. What is the recommendation?

(I will be delayed in responding until ~ 6/27)

#11

@Dan_Angelelli:

Not sure I follow.

Claims from a provider = open claims. Claims from a payer = closed claims. Where am I missing things?

There are, however, early view claims from the payer, before they get adjudicated. They, essentially, are provider claims.

#12

The missing piece is that I would lose visibility to the claim type of each record (e.g., professional claim, a facility claim, a dental claim).

That claim type is also useful and as far as I can see, choosing to track “Payer System” vs “Provider System” in the “_type_concept” field means not tracking professional/facility/dental anywhere.

1 Like
#13

This is the crux, here. What is the use case?

OMOP is a patient-centric model generating “the evidence that promotes better health decisions and better care”, according to our mission. Do you think it matters for health decisions and care who does the claiming? It might, I am just not aware of such research.

Or does it have to do with the healthcare system and their assignment of resources, which means we should look at the COST table to support use cases.

#14

Let me make a few remarks.

I find the term open and closed confusing. Pre-adjudication and adjudicated (or adjudication-completed or post-adjudication) is better.

Even better - you say source and adjudication status

So types are:

  • FromProvider~pre-adjudication
  • FromPayer~pre-adjudication
  • FromPayer~completed-adjudication

Payer pays only for procedures. Not diagnoses. So to simplify, I will focus on duo of tables ‘cost’ and ‘procedure_occurrence’.

The types below seem like not be enough.

OMOP4822212 Provider System Open Claims
OMOP4822218 Payer system (Primary payer) Closed Claims
OMOP4822217 Payer system (Secondary payer) Closed Claims

First addition must by origin of the claim (professional vs facility vs dental) (and it was pointed out in this thread)

Second addition is the RESULT OF ADJUDICATION. (accepted-and-paid vs. rejected) for Closed (=adjudication-complete) Claims.

Consider a case A) where provider performed to patient a cervicoplasty (plastic surgery procedure on the neck) (CPT 15819).

From patient point of view the procedure happened. But if result of adjudication is rejection – depending on ETL rules, it may end up in CDM or it may not. I would like to see how various groups represent rejection/acceptance of a claim by payer.

You need to split code OMOP4822218 Payer system (Primary payer) Closed Claims into two flavors

  • OMOP48222181 Payer system (Primary payer) Closed Claims – Rejected by Adjudication

And

  • OMOP48222182 Payer system (Primary payer) Closed Claims – Accepted by Adjudication

If you have secondary Payer – it may be referred to that secondary payor and result of secondary payer adjudication may be Accepted. So do you put the row there twice?

No -because we are patient centric but with some eye on at least good-enough (or allowed in OMOP) claim-ish-ness – you can create a third code for claim type that says ‘rejected by primary and accepted by secondary’ (as postcoordination).

Going back to conditions linked to type of source data of FromPayer~pre-adjudication – what do you do with diagnoses for a claim where all procedures on that claim were rejected?

For reference, claim form example pasted below (from here)

Result of adjudication is absolutely key for ‘cost’ table so our type concepts at the moment are ‘not fit for purpose’ for patient centric model that also tries to be as claim-ish as possible at the same time. And in my view, why not allow it. Type concept hierarchies is what we used in other situations.

image
image627×748 178 KB

t