CDM v5.5 Coming this August!

General
1

The CDM Working Group wants you to know about CDM v5.5!

Calling all workgroups! CDM v5.5 is slated to be released at the end of August. We in the CDM working group would like to give you a heads up as to what you can expect from this upcoming version so you can being to prepare. As this is a minor version, all changes are backwards compatible with CDM v5.4, but we do have some exciting additions. You will see some new vocabulary support tables meant to make community contributions easier and some new columns in patient-level event tables to make our data model even more robust! Please see the summary table and document below for details and feel free to contact us on the CDM Working Group channel on teams or reply here on the forums with any questions.

OMOP CDM v5_5 facts.docx

Change Patient Data? Breaking? WG Sensitivity Level Status
Add visit_occurrence_id and visit_detail_id to SPECIMEN Yes No Low :white_check_mark: Strong support
Add value_as_date to OBSERVATION Yes No Moderate :white_check_mark: Supported
Add PACK_CONTENT table No No Low :white_check_mark: Supported
Add CONCEPT_METADATA and CONCEPT_RELATIONSHIP_METADATA tables No No Low :white_check_mark: Supported
Add value_as_source_concept_id to MEASUREMENT and OBSERVATION Yes No High (THEMIS, Vocabulary, and Survey WG alignment needed) :white_check_mark: Supported
Add unit_source_concept_id to OBSERVATION Yes No Low :white_check_mark: Supported
4 Likes
2

pasting here the .docx content (most of it)

All additions are optional, non-breaking, and preserve compatibility with existing tools and ETL pipelines. Items were endorsed at the 2025 OHDSI Symposium and approved for community feedback by the OHDSI Steering Committee

1. Add visit_occurrence_id and visit_detail_id to the SPECIMEN table

GitHub Issue: Specimen table is missing FK to Visit Occurrence and Visit Detail table · Issue #586 · OHDSI/CommonDataModel · GitHub
Type: Patient-level data
Rationale: Enables linking specimens to encounters, especially important as microbiology mapping expands (e.g., culture dates, collection contexts). Aligns SPECIMEN with other fact tables.
Pros

  • Increases analytic usability of specimen data

  • Supports microbial/diagnostic workflows

  • Aligns with CDM convention that clinical events can reference visits

Cons

  • Requires ETL updates for teams that populate SPECIMEN (rare today)

  • Adds two additional fields to a lightly-used table

Meeting notes context: Clear consensus and strong support (22 yes, 0 no). Low controversy.

CDM WG Meeting 15 Dec 2025

2. Add value_as_date to the OBSERVATION table

GitHub Issue: Revisit adding VALUE_AS_DATE to the OBSERVATION table · Issue #475 · OHDSI/CommonDataModel · GitHub
Type: Patient-level data
Rationale: Enables representation of observations whose value is itself a date, e.g., expected due date, date of a past event (“history of MI in 2012”), survey responses, or patient-reported timelines.
Pros

  • Fills a functional gap (previously had only number/string)

  • Enables richer clinical/contextual data

  • Supports survey data and temporal patient-reported outcomes

Cons

  • Slightly increases complexity of OBSERVATION conventions

  • Requires careful documentation to prevent misuse

Meeting notes context: Strong support; implementation details clarified (observation date = encounter date; value_as_date = fact date).

CDM WG Meeting 15 Dec 2025

3. Add new vocabulary reference table: PACK_CONTENT

GitHub Issue: Add table PACK_CONTENT · Issue #726 · OHDSI/CommonDataModel · GitHub
Type: Vocabulary-only (no patient data)
Rationale: Provides structured information about multi-drug packs (e.g., contraceptive packs with multiple active ingredients), which is not fully supported by DRUG_STRENGTH.
Pros

  • Supports correct handling of drug packs

  • Improves transparency in vocabulary content

  • No ETL impact for patient-level mapping

Cons

  • Additional table to ship/host with vocabulary releases

  • Tooling must ignore this table unless needed

Meeting notes context: Non-controversial; viewed as a vocabulary-team deliverable helpful for pack-based drug research.

CDM WG Meeting 15 Dec 2025

4. Add vocabulary metadata tables: CONCEPT_METADATA & CONCEPT_RELATIONSHIP_METADATA

GitHub Issue: Create sections for vocab reference · Issue #735 · OHDSI/CommonDataModel · GitHub
Type: Vocabulary-only
Rationale: Provides improved transparency on concept provenance, mapping approach (manual vs algorithmic), category labels, and origin of relationships—important as community-contributed vocabularies and LLM-generated mapping expand.
Pros

  • Greater vocabulary auditability & reproducibility

  • Supports LLM-assisted vocabulary generation (rule- vs probabilistic-based distinctions)

  • No impact on ETL pipelines

Cons

  • Adds two tables that some data holders will ignore

  • Requires consistent update/versioning in vocab releases

Meeting notes context: Widely supported; expected to enhance community vocabulary stewardship.

5. Add value_as_source_concept_id to MEASUREMENT and OBSERVATION

GitHub Issue: Adding value_source_concept_concept_id field to the Measurement and Observation table · Issue #751 · OHDSI/CommonDataModel · GitHub

Type: Patient-level data

Rationale: Every concept_id in the OMOP CDM should have a source_concept_id to ensure the representation of the data at the source is fully represented. NOTE this proposal has been updated from the github issue to be value_as_source_concept_id instead of value_source_concept_id and is explicitly expected to be the representation of the value_source_value and mapped to the value_as_concept_id.

Pros:

  • Allows representation of the data as it is represented in the source

  • Follows OMOP CDM modeling conventions for all concept_ids

Cons

  • Requires ETL updates to 2 tables, MEASUREMENT and OBSERVATION

  • Adds one additional field to 2 tables

6. Add unit_source_concept_id to the OBSERVATION table

Type: Patient-level data

Rationale: Every concept_id in the OMOP CDM should have a source_concept_id to ensure the representation of the data at the source is fully represented.

Pros:

  1. Allows representation of the data as it represented at the source

  2. Aligns with OMOP CDM data modeling conventions for all concept_ids

Cons

  • Requires ETL update to the OBSERVATION

Items NOT approved for v5.5

These were discussed but voted down at the Symposium:

  • Adding visit occurrence source key to VISIT_OCCURRENCE

  • Adding polymeric keys to PROCEDURE_OCCURRENCE

3

https://ohdsi.github.io/CommonDataModel/cdm55.html

https://ohdsi.github.io/CommonDataModel/cdm55Changes.html

csv file CommonDataModel/inst/csv/OMOP_CDMv5.5_Field_Level.csv at main · OHDSI/CommonDataModel · GitHub