Proposal for Cost Table Adjustment

[Gowtham_Rao]

@Christian_Reich

Is that general consensus? VISIT_OCCURRENCE=header and VISIT_DETAIL=detail? You get only one header for an entire hospital visit?

If we focus this discussion to claims data I would say this should be the general consensus (among payers) - definitely a US medical claims weighted opinion. I have no clue about Germany. We discussed this when the CDM WG arbitrated this very topic, when I had proposed the visit_detail table.

@Christian_Reich

I feel like you are alluding to - me!

Not really. This was something @ericaVoss and I discussed at the 2017 OHDSI symposium. Then at the CDM WG meeting in October and Novemeber, we discussed this same topic, and we all agreed that 'if you dont know what you are doing - you can mess up". Remember @Patrick_Ryan saying something similar with respect to using data about conditions or procedures - if you dont have clinical knowledge, you cant do meaningful analysis; if you dont have health economics knowledge, you cant do meaningful analysis.

@Christian_Reich

Do you have them listed somewhere? That would help.

Let’s focus on data representation ETL use-case and later an analytic use case. The below would be a common and generalizable scenario A person has a 3 night inpatient stay in a University hospital for appendicitis. The sequence of events are

1. Ambulance ride to emergency room of the hospital. Day 1. Seen by ER physician.
2. The emergency room admission, stabilization and transfer/admission to hospital. Day 1. Seen by admitting physician.
3. Hospital takes him to operating room – appendicetomy. Seen by Surgeon. Day 1.
4. Transfer to Intensive care unit. Seen by Surgeon, ICU doctor, admitting physician, Infectious Disease Physician. Day 1 and Day 2.
5. Transfer to step-down unit Day 2. Seen by Rehab team including physical therapist, admitting physician, Infectious Disease Doctor.
6. Transfer to Floor Day 3. Admitting physician, Infectious Disease Doctor.
7. Discharge to home Day 4 morning. Discharged by admitting physician.

How is this billed? Lets keep this simple, and tolerate some lack of precision to ensure simplicity. There will be two types of claims and there will many billed claims.In US, the two main types of claims are

1. Professional claims 5010 X222 or CMS 1500 - Billed by a human like the physician or nurse practitioner or physical therapist.
2. Institutional Facility claims 5010 X223 or CMS 1450 (see page 9 to 14, and 18). Billed by the organization - generally the hospital.

The number of bills are dependent on number of legal billable entities the person encountered during the 3 night stay. If the ER and Hospital are two different legal entities, then there will be two institutional claims. Generally, in the case above – there will be one Institutional Facility claim because most University hospitals will have their own ER’s. Each clinician who saw the person will file their own claim. Infact there may be a different claim for each day (sometimes each encounter ) the clinician had with the patient during the stay. So, the surgeon may have two claims - one for the surgery and second for the ICU visit. The ER physician would have only one claim. The Admitting physician probably 4 claims. The dates for each of these claims may be different e.g. the Infectious disease physicians first date of service is actually day 2. Ambulance would be a professional claim by itself.

The two claim types above, will have their own header (summary), and detail (line) in a parent-child hierarchy. The line is the detail. For Institutional claim, the details like the ER, OR, ICU, Rehab, Floor etc are identified by Revenue code. The detail of the professional claims would have EnM CPT codes like http://www.ohdsi.org/web/atlas/#/concept/2514424

@Christian_Reich

And VISIT_DETAIL is is not aggregated the way the provider happened to be organized commercially and split up the claims?

I am sorry - can you elaborate?

@Mark_Danese

One thing we have seen in our data is that the total cost provided in the data does not always equal the sum of the costs in the row. In some global sense, it always adds up. but the view that exists in claims data is not complete. Payers have much more granularity than researchers.

How are the costs linked to the claims? Charges are filed by the providers. Allowed, Paid, Coinsurance, Copay, etc. are determined by the payer. So the charge has no relation to contract, allowed/paid/coinsurance/copay are dependent on the contractual relationship between payer and provider. Charges are ‘free for all’ – charges may come at header level or line level. e.g. a hospital may charge for the entire stay, or may charge for each of the ER, ICU, OR, Rehab, Floor etc. The contractually determined costs are attached to the claim by the payer thru the process of adjudication. Pre-adjudicated claims may not have this cost information.

Adjudication depends on what the contract says. If the contract is a pure traditional fee-for-service, every line item will be adjudicated based on contracted rates and the sum goes to the summary/header. If there is no contract, then the payer may use some form of average rates or usual-and-customary rates. Newer payment methods are changing it. DRG is one form of global payment, where the entire care may be covered by one DRG like http://www.ohdsi.org/web/atlas/#/concept/38001158 . In this case, adjudication may happen at the header-level and not the line level.

So, yes to @Mark_Danese comment below. It add’s up

@Mark_Danese

In some global sense, it always adds up. but the view that exists in claims data is not complete. Payers have much more granularity than researchers. In their data, it has to add up (I hope).

– but you need to know how the adjudication of the claim happened. The adjudication depends on benefit design and contractual relationship – OMOP CDM does not capture those pieces of information, and these types of information are not available. I have tried to address some of those in the recently accepted payer_plan_period . If we really need to balance line records to header records, you have to know benefit design of the health plan. The plan_concept_id, plan_source_value and plan_source_concept_id is our first step towards that.

@Mark_Danese

Just a few simple use cases. I am using reimbursed amount to be cost, but that might vary by dataset.

Calculate the annual average cost for patients in a cohort
Calculate the cumulative cost for patients in a cohort
Estimate the effects of covariates on the cumulative cost in a cohort
Calculate the annualized cost (cost / observation period duration during year)
Calculate the cost of specific utilization per person: drugs, hospitalizations, office visits, emergency room visits, etc

Some of the above might be by subgroup (e.g., diabetes, cancer, osteoporosis, etc)

These are classic payer business intelligence use cases. They are analytic use cases, not data modeling/ETL/data representation use case as above. They are easy to do – with the below steps.

1. Build a cohort.
2. Thru temporal association - find the records in cost table for the person in the cohort.
3. Limit the records in costs table based on the cost_concept_id – do we want allowed, paid, charged, coinsurance – they are all concept_id in the proposed concept list and used to populate cost_concept_id
4. If we want aggregate by total cost – then use concept_class = ‘Total’ and if we want to aggregate by component cost – then use concept_class ‘Component’ from the same concept_id
5. Decide if you want to aggregate person level or cohort level. Do you want to aggregate temporally? All of thee are nicely supported by Feature Extraction 2 of @schuemie
6. If you want to subset the cost table by some condition, or procedure or other – use the cost_event_id and cost_event_table_concept_id as proposed here Use the concept hierarchy.
7. Use temporal for cumulative costs
8. To estimate the effects of covariate – use featureextraction 2 and plp package.
9. To calculate annualize cost – calculate the timeinccohort and costs using feature extraction 2 – and then divide (total cost/total days)*30 to get per person per month cost, or *365 to get per person per year cost!
10. Cost specific of utilization – easy – same – subset cost records by linking them to drug, visit etc.

[Gowtham_Rao]

so, why all the hassle with the header and detail?

Because they are parent and child records. You don’t double count them.

Also – sometimes, depending on the data quality of the source, sum of child may not always add up to parent. Infact, if you are secondary data user – you may not know what is more accurate - detail or header. Thats a source data problem, not a OMOP CDM problem. So you use both, and don’t mix them up

[Christian_Reich]

If we focus this discussion to claims data I would say this should be the general consensus

I am not against it, I wasn’t clear that’s what the consensus was (and neither seemed @jenniferduryea). So, again, not arguing, but asking: If we do that and tell folks “if you have claims put the header into OCCURRENCE and the detail into DETAIL” will this work well? Will @MPhilofsky’s use cases work, where she wants to study patients going from ER to ICU to Rehab and the merits of the various variants?

Let’s focus on data representation
…
would have EnM CPT codes like http://www.ohdsi.org/web/atlas/#/concept/2514424

The way I understand you is that the institutional claims would feed the two VISIT tables, and the individual claims would be placed inside there, correct?

How are the costs linked to the claims?

We may all benefit from a little Tutorial here, @Gowtham_Rao. But this is already a good summary.

So you use both, and don’t mix them up

How do you use both? Right now, in the OMOP CDM, there is no way to indicate “don’t double count this cost record”. Or is there?

[Gowtham_Rao]

I wasn’t clear that’s what the consensus was

We should try to for sure. I said, there is general consensus among payers, not OHDSI community.

Will @MPhilofsky’s use cases work, where she wants to study patients going from ER to ICU to Rehab and the merits of the various variants?

Thats the point - visit_detail is trying to unify the claims data world and EHR data world. Take the above scenario we discussed about appendicitis.
Claims data – We will get many US claims, with each claim having many details. Each US claim should usually have only one place of service – inpatient hospital, ER, etc. Each of those claims (and its details) may have different dates, different providers, different conditions and different procedures – but they are all part of the same episode of care that started at the ambulance and ended with discharge. The episode needs to be inferred during analytic time using temporal association of person level records. Visit_occurrence should have provenance/lineage to claim summary/header, while visit_detail should have provenance/lineage to claim detail.

EHR data – usually one episode of care has one medical record number for the patient from beginning to end. Every thing else is a detail - with its own place of service, condition, procedure, dates etc. There is no need to infer the episode using temporal association, because the source data links the episode using the same medical record number. The medical record number ties together all the details starting from ambulance ride to discharge. If there is no medical record number, then we have a problem (similar to claims data), and in those cases visit_occurrence may need to be derived using an algorithm during ETL (these are tough choices, and hopefully rate choices), while visit_detail will have provenance to the source data.

The way I understand you is that the institutional claims would feed the two VISIT tables, and the individual claims would be placed inside there, correct?

Yes - institutional claims header would go to visit_occurrence, institutional claim detail to visit_detail.

Details go to visit_detail, header goes to visit_occurrrence.

Claims: claims summary/header goes to visit_occurrence, claims line/detail to visit_detail.

EHR: medical record number level summary information to visit_occurrence, details to visit_detail. Some of the visit_occurrence in EHR may have to be ‘derived during ETL’.

Because, from visit_occurrence table description

At any one day, there could be more than one visit.
One visit may involve multiple providers, in which case the ETL must specify how a single provider id is selected or leave the provider_id field null.
One visit may involve multiple Care Sites, in which case the ETL must specify how a single care_site id is selected or leave the care_site_id field null.

Visit_detail will capture what visit_occurrence cannot. e.g. you dont have to select a single provider, or care_site in visit_detail.

At the end of the day, ohdsi standard tools like Atlas rely on building era’s based on temporal association and use collapse strategy like era-fy to build cohorts @chris_knoll. So, we can use circe-be to build cohorts using combination of visit_occurrence and visit_detail.

How do you use both? Right now, in the OMOP CDM, there is no way to indicate “don’t double count this cost record”. Or is there?

Check out the concept_id’s i am proposing here as part of the cost table proposal - concepts. The use of concept_class unambiguously differentiates between total/summary cost and component cost. Summary cost concepts should be linked only to summary table like drug_occurrence and visit_occurrence, Component/Detail costs should only be linked to detail tables e.g. visit_detail, procedure_occurrence, condition_occurrence. I would also argue that with visit_detail - we should not relate cost table to procedure_occurrence anymore @jenniferduryea - I think this will be a point of contention. I would argue that we join detail cost from cost to visit_detail.visit_detail_id and visit_detail.visit_detail_id, and then to procedure_occurrence.visit_detail_id. The only exception would be when we have costs without visit information (rare and non standard).

The proposed concept’s will put the guard rail. The rule that we should only link the the detail concepts to detail, and summary to summary tables will add guard rails.