diff --git a/.DS_Store b/.DS_Store index 465b784..03e6739 100644 Binary files a/.DS_Store and b/.DS_Store differ diff --git a/docs/cdm60.html b/docs/cdm60.html index 66be19b..60c6628 100644 --- a/docs/cdm60.html +++ b/docs/cdm60.html @@ -500,8 +500,12 @@ div.tocify {

OMOP CDM v6.0

+
+

NOTE ABOUT CDM v6.0

+

Please be aware that v6.0 of the OMOP CDM is not fully supported by the OHDSI suite of tools and methods. The major difference in CDM v5.3 and CDM v6.0 involves switching the *_datetime fields to mandatory rather than optional. This switch radically changes the assumptions related to exposure and outcome timing. Rather than move forward with v6.0, CDM v5.4 is actively in production to address additions to the model that have been requested by the community while retaining the date structure of medical events in v5.3. Please see our roadmap for more information on which proposals will be included in CDM v5.4. For new collaborators to OHDSI, please transform your data to CDM v5.3 until such time that CDM v5.4 is ready for release.

Below is the specification document for the OMOP Common Data Model, v6.0. Each table is represented with a high-level description and ETL conventions that should be followed. This is continued with a discussion of each field in each table, any conventions related to the field, and constraints that should be followed (like primary key, foreign key, etc). Should you have questions please feel free to visit the forums or the github issue page.

–after regeneration of DDLs link to csv of cdm link to pdf of cdm documentation link to forum on doc page

+

Changes in v6.0

-

The OMOP Common Data Model is managed by the OHDSI CDM Working Group. Through the end of 2019 and into 2020 our goal was to fully update the documentation in an effort to facilitate greater understanding of the model. Almost every forum post relating to a question on how to map data into the CDM inevitably referenced the (now outdated) technical and difficult-to-understand explanations of the tables and fields currently on the wiki. To remedy we focused on one or two tables each month, diving fully into the user guidance and ETL specifications. The results of our efforts can be seen on the pages detailing v5.3.1 and v6.0.

-

In addition to documentation the formal remit of the CDM Working Group is to hear proposals for change, ratifying only those with valid use cases and data to support them. This process will be slower through 2020 though proposals related to existing CDM tables will be considered during the months those tables are being updated. For example November 2019 will be focused on the PERSON and OBSERVATION_PERIOD tables so any proposals related to those two tables will be evaluated during November 2019. Once proposals are accepted they are listed as such and will be integrated in an upcoming version of the OMOP CDM. Currently accepted proposals can be found under the “Proposals” drop down across the top.

-
-

CDM WG Meeting Information

-

Every first Tuesday of the month at 1pm est Teams Meeting

-

Note This was recently changed from a Skype meeting to a Microsoft Teams meeting. If you do you have access to the OHDSI Teams Tenet, please contact Clair Blacketer at .

+

The OMOP Common Data Model is managed by the OHDSI CDM Working Group. Through the end of 2019 and into 2020 our goal was to fully update the documentation in an effort to facilitate greater understanding of the model. Almost every forum post relating to a question on how to map data into the CDM inevitably referenced the (now outdated) technical and difficult-to-understand explanations of the tables and fields currently on the wiki. To remedy we focused on one or two tables each month, diving fully into the user guidance and ETL specifications. The results of our efforts can be seen on the pages detailing v5.3 and v6.0.

+

In addition to documentation the formal remit of the CDM Working Group (WG) is to hear proposals for change, ratifying only those with valid use cases and data to support them. In the past, this was done by the WG alone. The group would invite others from around the community to present use cases for change and suggestions for improvement. The WG would then vote on the proposals and a new CDM version would be released after a certain period of time or if enough proposals were voted in. This approach worked when the community was smaller but as it is growing rapidly the CDM WG needed to adapt the refresh cycle such that everyone has an opportunity to weigh in on the proposed changes.

+
+

CDM Refresh Cycle

+
+

1. Define New Version

+

The image below describes the new CDM refresh cycle. It begins with defining a new version. This has been completed for the current cycle. Issues and proposals on the github were considered during a 4-hour workshop where it was decided the next CDM version will be CDM v5.4, building off of CDM v5.3. The group then participated in a rapid-fire voting activity to identify which changes should be incorporated into CDM v5.4. Any items that were not unanimously agreed upon were then discussed in small groups to hone the proposal and suggestions were presented back to the group. The final roadmap for CDM v5.4 can be found here.

+

## 2. Sign off from Work Groups

+

This is the current stage of the refresh cycle for CDM v5.4. Each member of the CDM WG is a liaison for another workgroup in the community. They are responsible for presenting the proposed changes to the CDM and collecting the feedback. This has resulted in very helpful suggestions from the EHR, Data Quality, Device, HADES, and ACHILLES groups. This outreach has proven to be very effective and should result in a very stable version.

+
+
+

3. Release DDLs

+

After all changes and suggestions are agreed upon by the community and work groups the next step is to generate the DDLs this will be done by the CDM Development group.

+
+
+

4. Software Update

+

There will be period of time once the DDLs are ready to allow the software and methods developers to prepare for the official release of the CDM. This is meant to serve as a buffer so that once the community starts adopting the new model, the tools and methods will be ready to support it.

+
+
+

5. Community Support

+

This is the final stage of the CDM refresh cycle. Once the DDLs are ready and the software and tools supports the new version, the CDM WG will work to help the community convert their data to the new model.

+
+
+

CDM WG Meeting Information

+

The CDM working group meets the first and third Tuesday of the month. See below for links to the meetings.

+

Every first Tuesday of the month at 1pm est Teams Meeting

+

Every third Tuesday of the month at 1pm est Teams Meeting

+

Note These were recently changed from a Skype meeting to a Microsoft Teams meeting. If you do you have access to the OHDSI Teams Tenet, please contact Clair Blacketer at .

+