Define rules brainstorm for controlled terminology

[rbakercdisc1]

For controlled terminology there could be three types of rules:

1. General
2. Specific
3. Codelist

These are defined as follows:

1. General - If terminology is defined for an attribute, the attribute must be contained from the terminology list.
2. Specific - If term defined from the attribute, the assigned code must be checked to see that it is defined by the codelist assigned to/defined by this attribute. If the codelist is extensible, first check for synonyms to ensure the appropriate term is used.
3. If the specified code is in the codelist, then the decode must match what is in the codelist.

[rbakercdisc1]

Other considerations regarding CT

1. If the C-code is used in the USDM model, does the Test name and Test Code make a difference? How will this work together, if it indeed works together?
2. There is the opportunity to pre-populate the Trial Summary design SDTM tables in the protocol development phase by this (at least some if it)
3. TESTCD and TEST - is this only relevant at the BC level?
4. ETCD versus element = Which of the attributes of name and label would correspond with the values and how does that correspond to the code?
5. Does the model allow users to define a value list to be used somewhere within a study? (sponsor-defined terms) Is there a way to check for this if this exists?

This is a list of the use of CD in SDTM (in addition to Findings TESTCD)-
• ARMS
• MedDRA
• Element code – have attributes
• PARMCD – much like test and test code
• PARMS – some are trial summary, others are study terminology for device identifier and nonhost organism identifier, also for trial sets (used in SEND…. So does it apply to USDM; in clinical trials there are studies PK type w normal function, and another subject with mild kidney dysfunction CKD2, want to see if this effects the of the drug; some studies recruit nonsmokers and smokers for trial sets; also use them for GenTox studies) – covered by Trial populations,
• REPROPATH code (SEND) – out of scope

Other thoughs
In trial summary parameters, It looks like there is a relationship between the code and the class. You only expect one set of parameters. If expecting one instance of …. Will the C-code exist more than once in the specified code system.

We need to know what codelist the C-code is from …. What would this be checked against?
For TS – the code being specified is the code for the response.

Ths is only applicable, if decode must match a specified term.

@ASL-rmarshall
@DianeWold

Please add to and edit this page. Thank you (and the main question). I added this discussion as a general PBI to Define CT rules - PBI 100 - Controlled terminology rule(s)#100

[DianeWold]

Questions:
The USDM attributes for Code include code and decode, but several SDTM terminologies including those for Trial Summary Parameters, have a c-code, a short name (e.g., a value for TSPARMCD) and a long name (e.g., a value for TSPARM). Does the USDM class Code need another attribute so that all three parts of the SDTM terminology can be included?

When M11 specifies a terminology set, is use of that terminology a requirement for conformance to the USDM?

How should a conformance check of terminology be expected to handle extensible terminologies?

Would a conformance check of terminology include checking that all attributes of the code are consistent with the code system?

Would checks against CDISC controlled terminology specify the code system as "CDISC" or would the code system be a particular codelist within the CDISC terminology?

Does the USDM support SDTM Trial Sets? Trial Sets may be covered by the concepts of cohorts and populations in the USDM.

SDTM includes special structures designed to describe the design of SEND DART (developmental and reproductive) studies. Is the scope of the USDM human clinical trials, which would mean that DART studies are out of scope?

[DianeWold]

PIvot2023-12-18.pptx

[BSnoeijerCD]

@DianeWold @rbakercdisc1 @ASL-rmarshall
While reiterating our discussion yesterday I realized that the CDISC codelist is defined by the CT of USDM. So given that, you don't have to specify it in the code class itself. Entering "CDISC" in code.codesystem only including the version number makes it easier to cross-check for consistency in using the same codelist version.

In the CT Excel spreadsheet you have 3 flavours of valid value lists:

• N or N/A
• Y (SDTM Terminology Codelist C..... )
• Y (Protocol Terminology Codelist C....)
• Y (Point out to external dictionaries)
• Y (C.....) will be a USDM codelist specified in the valid value sets.
• Y (CNEW ....) will be a USDM codelist specified in the valid value set still to be defined.

A good check then will be whether the code that is given for a parameter corresponds to an available code in the specified codelist.
Note that we are considering to define whether codelists are extensible or not in the near future.

[DianeWold]

I wonder whether the rules engine can access the USDM CT.

[BSnoeijerCD]

Good point. Are there comparable 'code' rules in SDTM? And how is that handled?

[drewcdisc]

During a discussion with the POC team, we came up with several salient points:

• The Rules Engine does access codelists in the Library for SDTM.
• The Rules Engine is not accessing codelists for USDM in the Library (this is not an implemented feature in the Library).
• We don't think the Rules Engine can access which codelist goes with which entity.
• The SDTM terminology in the Library does not distinguish between codelists in the instance where a variable has multiple code lists. That information is stored in codetable mapping files, which are NOT available in the Library.