Purpose of the OMOP CDM - analytics ready or close to source?

[Christian_Reich]

This is a post continued from here.

[Christian_Reich]

New table for visits, encounters, care transitions

• Facility claim vs professional claim atleast in USA by using UB04 vs CMS 1500 claim information or pharmacy/vision/dental claim etc.

and

New table for visits, encounters, care transitions

Other important things in claims are HIPAA place of service, Type of bill, revenue code, admit type that help define it further

and

New table for visits, encounters, care transitions

Our mission is to be able to do reproducible, collaborative, large scale research. We use a common data model to standardize the structure, content, representation of data. I don’t think that implies “analytics ready”. We have packages and tools that convert the data in CDM into analytics ready, but the CDM itself is not analytics ready. I don’t think our mission calls for baking in analytic use-cases into CDM so that those use cases are easier; what we do is, collaboratively understand multiple usecases and enhance the CDM such that multiple use cases maybe supported.

[Christian_Reich]

@Gowtham_Rao:

This has been a discussion for a long time: What do we standardize, and for which use case. A good CDM is one that creates a global optimum (or a good local one) between trying to do everything for everyone but shallowly, versus doing something really well for one narrow purpose.

I think traditionally we have been slightly more on the generic end (read: You are too narrow. ). We specificially do not want to be an über-claims database. We want to incorporate EMRs and surveys into the same structure, maybe even clinical trial data. We also want to do this internationally. There is no way anybody outside this country has a clue, or wants to have a clue, what UB04 or CMS1500 means. Neither do you want to know how the claims system works in, say, Germany. (If you do, this is a good start for you to read, at least for ambulatory services).

@Gowtham_Rao

When representing data in OMOP common data model - I think it is critical to represent the data in a such a way that is semantically represents the source data and is at the same atomic level of granularity as the source data. This will retain lineage/provenance to the source 1:1.

That won’t be possible. We cannot be an “attic”, wehre all data are preserved, “just in case”. Instead, we want support the use cases. So, if your use case has a requirement for a certain piece of information and it’s not there, we need to either encode it into the model, a concept_id or a type_concept_id. And we have been doing that. Let us know if something is missing, and will go right to the CDM WG as a change request.

@Gowtham_Rao

Any ‘inferred’ information should be done at the analytic time.

Too late for that. We already have the ERA tables. And we explicitly request the ETL to establish the business rules so that a source data can be mapped to the CDM, including documentation thereof The semantic representation is the CDM’s, not the sources. Those transformations happen particularly often (and sometimes controversially) for the OBSERVATION_PERIOD and VISIT_OCCURRENCE tables (hence the other discussion group).

@Gowtham_Rao

Agree - we need to preserve claims level referencing.

The CDM is a patient-centric model. It is for analyzing patient data and making decisions for the patient. Having said that, I think your needs can be accomodated, and I know you have use cases that require a high level of accuracy, because money depends on it. Let’s work on getting that right.

[Gowtham_Rao]

@Christian_Reich

I know you have use cases that require a high level of accuracy, because money depends on it. Let’s work on getting that right.

Agree with most but with this last point mostly Lets solve this important need.