Interventions [Rules]

[BSnoeijerCD]

Formulation missing from intervention and alignment with IDMP. See feature ticket #316

See JIRA 520

[BSnoeijerCD]

@ASL-rmarshall and @dih-cdisc Can you review my suggestions below?

Updates of the V3 rules that are needed based on the changed attribute names:

• CHK0125 and CHK0151: AgentAdministration -> Administration

Additional checks based on change to optional filling Administration frequency, route and dose

• If a dose is specified a route is expected and vice versa
• if a dose is specified a frequency is expected Or should we make this a must?

Additional checks based on new additions to the model:

• administrableDoseForm coded according to CDISC terminology
• AdministrableProductProperty coded according to CDISC terminology
• Referenced AdministrableProduct defined within the study version.

I think the rest is all handled by the referential integrity and schema. Maybe we need to reconsider the required link to ingredient. Do we want to require an ingredient in case of placebo?

[ASL-rmarshall]

@BSnoeijerCD I agree with your suggestions above, with the following additional thoughts:

• I agree that frequency is only expected when you have a dose (in the same way that route is only expected). However, if you have a frequency, I don't think it would make any sense not to have a dose. This suggests that the "vice versa" for frequency could be a "must", but I think it'd be OK for it only to be a warning if we want it to be part of the same rule.
• I don't think a specific rule is needed for "Referenced AdministrableProduct defined within the study version". The wording suggests that you're expecting StudyVersion to have an API-only collection of AdministrableProducts. However, given that rules are only applied within the context of a study version, checking that an administrable product is defined within the study version is the same as the generic "referenced id values must be valid" rule that we were discussing on 2024-0816 (#454).
• I agree that specifying ingredients should be optional.
• I think there may need to be some additional rules - I'll add them as a separate comment below.

[ASL-rmarshall]

@BSnoeijerCD These are my thoughts for additional checks based on this modelling (without my suggested tweaks):

• A referenced ingredient must not have any references
• An ingredient must not reference itself.
• There must be a corresponding strengthsLowerLimit strength for every strengthsUpperLimit of an Ingredient.
  • We'd need to figure out how to identify a "corresponding" strength.
  • This check wouldn't be necessary if numerator range were a property of Strength
• The unit for the denominator of a strengthsUpperLimit strength is expected to be the same as the unit for the denominator of the corresponding strengthsLowerLimit strength.
  • We'd need to figure out how to identify a "corresponding" strength.
  • This check wouldn't be necessary if numerator range were a property of Strength.
• If the unit for the numerator of a strengthsUpperLimit strength is the same as the unit for the numerator of the corresponding strengthsLowerLimit strength, then the value for the numerator of the strengthsUpperLimit strength must be greater than the value for the numerator of the corresponding strengthsLowerLimit strength.
  • We'd need to figure out how to identify a "corresponding" strength.
  • If numerator range were a property of Strength and the Range class were used, this would be covered by the new rule I've proposed for the Range class (see CHK0198).
• If a dose is specified (for an Administration), then an administrable product must also be specified, and vice versa. (Or is this just a warning?)
• A unit must be specified for every strength denominator and numerator.
  • If numerator range were a property of Strength and the Range class were used and the unit relationship were updated to point to AliasCode instead of Code, then this rule would apply for both Quantity and Range.
• The standard code for a unit of a quantity must be coded according to the Unit (C71620) SDTM codelist.
  • If numerator range were a property of Strength and the Range class were used and the unit relationship were updated to point to AliasCode instead of Code, then this rule would apply for both Quantity and Range.
• Are there any situations in which a substanceCode is required for an Ingredient? If so, we should define a rule.
• What's the standard CDISC codelist that will be used in AliasCode.standardCode for Ingredient.substanceCode? If there is one, we should add a rule. If there isn't one, we shouldn't use AliasCode - there should just be multiple substanceCodes instead.
• Should we try to check for unique ingredients of an administrable product? If so, should we just use Ingredient.name? (If so, I think this would be covered by CHK0009).
• I don't think we need to check for unique administrable product properties - I'm assuming that you can probably have more than value for a given property, which would be represented as separate instances of AdministrableProductProperty with the same type. But should we have a rule for unique property values (no more than one property per type/text/quantity)?
• How are AdministrableProductProperty text and quantity expected to be used? It looks like text is required, so what happens when the property value is specified as a quantity?
• Do we need a check for non-unique administrable product identifiers (in the same way we have checks for non-unique study identifiers and reference identifiers)?
• Should we make denominator required in Strength? If we don't have a denominator, it'll be difficult to figure out what the strength represents and how it relates to the dose.

[BSnoeijerCD]

@dih-cdisc @ASL-rmarshall

I added the following rules based on the above:

• If a dose is specified a route is expected and vice versa
• if a dose is specified a frequency must also be specified. (A frequency can also be applicable to another type of intervention (like psychological therapy). So I did not include vice versa.)
• if a dose is specified an administrable product must also be specified.
• administrableDoseForm coded according to CDISC terminology
• AdministrableProductProperty type coded according to CDISC terminology
• added rule for a referenceSubstance not having a reference itself
• did not add rules for self-referencing as this will be handled by the api (referenced substance will be nested within the substance instance referencing it)
• model is updated so strengthsLowerLimit and strengthsUpperLimit are replaced by strength relationship
• added rule for units to be specified for numerator and denominator
• range class minValue<maxValue rule looks good.
• updated rule for unique identifiers within an identified organization to include AdministrableProductIdentifier

Not added

• code requirement for substance. They are not always specified in a study definition.
• unique substance names are checked with general CHk0009 rule.
• required denominator as this is also not required in IDMP as far as I could see.
• unique administrable product property types - this could be anything. So we need to learn first what is in here before we restrict this to only 1 per type.

To discuss with PO:

• not sure whether aliasCode is specifically intended to have CDISC code as the standard

[dih-cdisc]

To discuss with PO:

• not sure whether aliasCode is specifically intended to have CDISC code as the standard

No, they can be any code lists, generally CDISC, bit not always. An example is geographic/country codes from ISO. There was a note in the IG but updated to make it clearer

[ASL-rmarshall]

@dih-cdisc @BSnoeijerCD OK - rephrasing the question about the standard codelist for substanceCode (as it was) based on above responses and updated model:

• What's the standard codelist that will be used in AliasCode.standardCode for Substance.code? The CT spreadsheet currently says "Point out to multiple Biomedical coding dictionaries such as WHODrug, ATC, UNII, etc.", but doesn't indicate which codelist is the standard one. If there is a standard codelist, we should document the codelist in the CT file and IG, and consider adding a rule (if the codelist is accessible for checking against). If there isn't one, we shouldn't use AliasCode; there should just be multiple codes instead - i.e., a 0..* codes relationship to the Code class (in the same way that we allow multiple StudyIntervention.codes, which has the same "Point out to multiple..." comment in the CT file).

It would probably also be a good idea to change "CDISC code" to something like "term from a standard codelist" in section 4.5 of the IG, which currently says:

Where a CDISC code is demanded by the model but flexibility is needed, users may include other terms (aliases) using the AliasCode class.

[daveih]

It would probably also be a good idea to change "CDISC code" to something like "term from a standard codelist" in section 4.5 of the IG, which currently says:

Where a CDISC code is demanded by the model but flexibility is needed, users may include other terms (aliases) using the AliasCode class.

See comment above "No, they can be any code lists, generally CDISC, bit not always. An example is geographic/country codes from ISO. There was a note in the IG but updated to make it clearer"

[ASL-rmarshall]

@dih-cdisc Apologies - missed that. But the question still remains. The updated IG says:

Where a standard code (typically a CDISC code but not always) is demanded by the model but flexibility is desirable / needed, users may include other terms (aliases) using the AliasCode class.

When coded, would each substance have a "standard code ... demanded by the model"? I haven't heard or found any mention of a standard codelist for substance that's demanded by the model, so I don't think we should be using AliasCode.

We already have an apparently equivalent relationship for StudyIntervention - in the CT spreadsheet, StudyIntervention.codes has an equivalent description and exactly the same text in the "Has Value List" column:

Y (Point out to multiple Biomedical coding dictionaries such as WHODrug, ATC, UNII, etc.)

The StudyIntervention.codes relationship is defined as a 0.. relationship with Code and, if the relationships are equivalent, I think we should define a Substance.codes 1 -> 0.. Code relationship in the same way, instead of Substance.code 1 -> 0..1 AliasCode.

[dih-cdisc]

@dih-cdisc Apologies - missed that. But the question still remains. The updated IG says:

Where a standard code (typically a CDISC code but not always) is demanded by the model but flexibility is desirable / needed, users may include other terms (aliases) using the AliasCode class.

When coded, would each substance have a "standard code ... demanded by the model"? I haven't heard or found any mention of a standard codelist for substance that's demanded by the model, so I don't think we should be using AliasCode.

We already have an apparently equivalent relationship for StudyIntervention - in the CT spreadsheet, StudyIntervention.codes has an equivalent description and exactly the same text in the "Has Value List" column:

Y (Point out to multiple Biomedical coding dictionaries such as WHODrug, ATC, UNII, etc.)

The StudyIntervention.codes relationship is defined as a 0.. relationship with Code and, if the relationships are equivalent, I think we should define a Substance.codes 1 -> 0.. Code relationship in the same way, instead of Substance.code 1 -> 0..1 AliasCode.

Agree, looks like a list of codes rather than an Alias with a single std code plus aliases

[BSnoeijerCD]

@dih-cdisc Apologies - missed that. But the question still remains. The updated IG says:

Where a standard code (typically a CDISC code but not always) is demanded by the model but flexibility is desirable / needed, users may include other terms (aliases) using the AliasCode class.

When coded, would each substance have a "standard code ... demanded by the model"? I haven't heard or found any mention of a standard codelist for substance that's demanded by the model, so I don't think we should be using AliasCode. We already have an apparently equivalent relationship for StudyIntervention - in the CT spreadsheet, StudyIntervention.codes has an equivalent description and exactly the same text in the "Has Value List" column:

Y (Point out to multiple Biomedical coding dictionaries such as WHODrug, ATC, UNII, etc.)

The StudyIntervention.codes relationship is defined as a 0.. relationship with Code and, if the relationships are equivalent, I think we should define a Substance.codes 1 -> 0.. Code relationship in the same way, instead of Substance.code 1 -> 0..1 AliasCode.

Agree, looks like a list of codes rather than an Alias with a single std code plus aliases

Ok. I will update it in the next push today.