This is a post continued from here.
New table for visits, encounters, care transitions
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).
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.
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).
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.
HL/7 AdministrativeGender missing
Agree with most but with this last point mostly Lets solve this important need.