OHDSI Home | Forums | Wiki | Github

Study artifacts / designs versioning

Developers
#1

Since we are slowly but thoroughly moving from CDM v5 to v6 there appears a need to support both CDM versions by OHDSI tools in parallel while the CDMs have some different tables and fields. Therefore, there is a need for systematic versioning of study designs like Cohort Expressions, Cohort Characterization / Pathways / PLP / PLE design JSONs. E.g. there might be a cohort criterion which is applicable only for CDM v6.1 (e.g. Location region - region_concept_id) and we should clearly state which CDM versions are supported by a Cohort Expression which contains such criteria. As a result of discussions during Atlas WG we came with the following approach:

  • Design spec (e.g. Java classes hierarchy) should contain some marks (e.g. annotations) which define compatibility of the design elements (e.g. the Location region is only supported by CDMs >= 6.1);
  • User should be able to define the intended range of compatible CDMs;
  • When a system persists a design, it should go over the design spec and derive which CDM version range is compatible with the given design and if the user specified an intended compatibility range, it should check whether the user specified range is inside the range based on specification. If the user hasn’t specified the range, then the system puts CDM range derived out of spec into the appropriate design field.

Example 1:

  1. A user defines a cohort definition;
  2. The user chooses a Payer Plan Period criteria (which are compatible with CDM only >= 5.3);
  3. User doesn’t define explicitly which CDM version is supported by his design;
  4. When a system persists the design, it checks that the given criteria are compatible with CDM >= 5.3 according to spec and therefore it sets “cdmRange” field of the design to “>=5.3.0”.

Example 2:

  1. A user defines a cohort definition;
  2. The user chooses a Payer Plan Period criteria (which are compatible with CDM only >= 5.3);
  3. User define explicitly that his design can work only with CDM versions >= 5.3.1;
  4. When a system persists the design, it checks that:
    • the given criteria are compatible with CDM >= 5.3 according to spec;
    • the user-defined compatibility range is in bounds of range derived from spec;
  5. The system sets “cdmRange” field of the design to user-defined “>=5.3.1”.

Example 3:

  1. A user defines a cohort definition;
  2. The user chooses a Payer Plan Period criteria (which are compatible with CDM only >= 5.3);
  3. User define explicitly that his design can work only with CDM versions >= 5.0.0;
  4. When a system persists the design, it checks that:
    • the given criteria are compatible with CDM >= 5.3 according to spec;
    • the user-defined compatibility range is partially out of bounds of range derived from spec;
  5. The system throws exception and doesn’t allow user to save such design

Mechanism implementing such approach was introduced in StandardizedAnalysisAPI repo and applied for Cohort Expressions of Atlas. Moving forward Atlas development team is going to expand the approach of other design JSONs. So, starting from now you’ll be able to see which CDMs can be used for running your study.

Inviting @schuemie to discuss how the approach could be built into FeatureExtraction

tagging @Chris_Knoll, @anthonysena

1 Like
t