Extending COST table to accommodate data beyond US format restrictions

[mik-ohdsi]

The DRG source value column is limited to 3 characters. DRG systems outside the US have longer DRG codes and it would be desirable to extend this field a little so that non-US DRG codes can also be stored here (besides creating concepts for those non-US codes in other vocabularies than the existing US DRG one).

Please review this thread as well.

[mik-ohdsi]

then again, @clairblacketer , would it maybe be better to store a concept ID that identifies a DRG code?

[ablack3]

I'd also like to suggest adding person_id and possibly a date field to the cost table. Cost is considered a domain (or at least there is a domain_id = "COST").

From the book -

"The domains are modeled in a person-centric relational data model, where for each record the identity of the person and a date is captured as a minimum."

Seems like cost should have person_id and a date. It would certainly make queries easier.

[clairblacketer]

Hi @ablack3 agreed. The v6.0 COST table does have person_id and incurred_date, billed_date, and paid_date. It is a worthwhile discussion if we should bring these edits to the 5 series.

[clairblacketer]

then again, @clairblacketer , would it maybe be better to store a concept ID that identifies a DRG code?

@mik-ohdsi the v6.0 COST table solves this problem as well.

[cgreich]

We do have to start thinking what we do with these DRGs. They are conglomerates putting together condition, visit and various treatment information to negotiate pricing. From a OMOP perspective, they make no sense, because there is nothing patient-centric about it. I need to think.