OHDSI Community! Time to break out the champagne
as I am happy to announce that CDM v5.4 is officially available. In terms of the model itself there is not a huge difference; you can find all changes from v5.3 โ v5.4 listed by table on our website. One thing you will no doubt notice right away if you visit our github is that it looks very different. It used to be that all the DDL code was available on the master branch, with a folder for each SQL dialect we support. In terms of folder structure, the master branch and releases would always look the same. Now, each release will have a zip file associated with it that contains the DDLs:
By releasing them in this way it allowed us to decouple the code to create the tables from the code we use to actually generate the DDLs. To that end, the master branch now contains an R package that creates the DDLs, documentation, website, zip files, and it will even connect to your database and instantiate the tables automatically. We will touch on this briefly at the next community call and we will do a demo at a future meeting.
Secondly we are not referring to this version as v5.4.0 but rather v5.4. This is deliberate and I promise there is a method to our madness. We do our best to stick to semantic versioning when it comes to the Common Data Model which increments version numbers but, as you know, the model is not a piece of software. Therefore, we have defined our versions using the following methodology:
Version X.Y.Z
X is versioned when changes are made that would break our current software tools
- In terms of the CDM this means changing the name of a column that ATLAS uses to define a cohort, for example
Y is versioned when tables or fields are added in a backwards compatible manner
- Going from CDM v5.3 โ CDM v5.4 we added the EPISODE and EPISODE_EVENT tables
Z is versioned when backwards compatible bug fixes are made to the DDLs
- When Z is incremented up, the model itself does not change
This way, if someone is on v5.3.2 or v5.3.5 we know that they are using the same tables and fields and, therefore, they are using the same model. Dropping the patch number from our discussions allows us to be clear about the model structure we are using without worrying about the need to adopt each bug fix as they are released.
Please check it out, we included lots more documentation on both the website https://ohdsi.github.io/CommonDataModel and our github front page https://github.com/ohdsi/CommonDataModel and donโt hesitate to reach out with any questions
Common Data Model Working Group
tagging @Patrick_Ryan @ericaVoss @Rijnbeek @Christian_Reich @krfeeney @gregk