Clinicaltrials.gov Registry Coverage

[dih-cdisc]

We need to check that we have enough CT registry coverage in the USDM. Priority is

• "WHO 30" elements
• CT.gov
• EU CTIS
• Others

Item	Ticket
Model	#238
CT	#239
API	#240
IG	#241
Examples	#242

[BSnoeijerCD]

@dih-cdisc : based on version 2.7 and tickets already raised there are only a few items left:

for studyDesign:

• maskingRoles => codes for participant, care provider, investigator, outcomes assessor, multiple possible (may also align to M11)
• maskingDescription -> text

Controlled Terminology:

• Add "Sham Comparator" and "Other" to StudyArm.type
• Check studyIntervention.type with CT.gov list if not already done:
  • Drug: Including placebo
  • Device: Including sham
  • Biological/Vaccine
  • Procedure/Srugery
  • Radiation
  • Behavioral: For example, psychotherapy, liefe style counseling
  • Genetic: Including gene transfer stem cell and recombinant DNA
  • Dietary Supplement: For example, vitamins, minerals
  • Combination product: Combining a drug and device, a biological product and device; a drug and biological product, or a drug, biological product and device
  • Diagnostic test: for example, imaging, in vitro
  • Other

[dih-cdisc]

With "masking" do we mean "blinding"? I note the M11 comment

"While blinding is the more commonly used term, masking is an alternative term which may be used in certain situations."

[PanikosCh]

Although masking can be an alternative to blinding in software vendors there is sometimes a distinction in that the behavior might differ. Masking may be on screen obfuscation (stars instead of real text) that can be read by the user (the user has access to data). Blinding does take a more formal and audited step to unblinded and may have consequences to that data depending on setup.

Not sure if this is of value to the discussion but thought it worth mentioning

On Mon, Nov 27, 2023 at 6:39 AM Dave IH @.***> wrote:

With "masking" do we mean "blinding"? I note the M11 comment

"While blinding is the more commonly used term, masking is an alternative term which may be used in certain situations."

— Reply to this email directly, view it on GitHub https://github.com/cdisc-org/DDF-RA/issues/169#issuecomment-1827208143, or unsubscribe https://github.com/notifications/unsubscribe-auth/A7YNFUTPBO64FPIQYABLYLDYGQYSDAVCNFSM6AAAAAA5UBUGIGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRXGIYDQMJUGM . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- Panikos Christofi Director of Product, Product Management | saama.com https://www.saama.com/ https://www.saama.com/

https://www.linkedin.com/company/saama-technologies/

--

This communication is confidential and subject to and governed by Saama’s  Electronic Communications Disclaimer. https://www.saama.com/email-communication-disclaimer/

 

[EMuhlbradt]

@BSnoeijerCD regarding the 'Controlled Terminology:' piece above, we can confirm that 'Sham Comparator' is already in the StudyArm.type codelist for DDF CT. Erin/Craig are concerned about adding 'Other' into the codelist however. We, as a general rule, do not add 'Other' into codelists for a number of reasons: 1. 'Other' is not a description of an arm; 2. 'Other' cannot be defined consistently across use datasets; 3. Adding 'Other' discourages the use of actually useful data values; 4. In SDTM at least 'Other' is covered by codelist extensibility, allowing sponsors to add whatever other values they feel are important/not covered by existing terms. So bottom line up front, we really do not want to add 'Other' to the codelist.

[BSnoeijerCD]

@BSnoeijerCD regarding the 'Controlled Terminology:' piece above, we can confirm that 'Sham Comparator' is already in the StudyArm.type codelist for DDF CT. Erin/Craig are concerned about adding 'Other' into the codelist however. We, as a general rule, do not add 'Other' into codelists for a number of reasons: 1. 'Other' is not a description of an arm; 2. 'Other' cannot be defined consistently across use datasets; 3. Adding 'Other' discourages the use of actually useful data values; 4. In SDTM at least 'Other' is covered by codelist extensibility, allowing sponsors to add whatever other values they feel are important/not covered by existing terms. So bottom line up front, we really do not want to add 'Other' to the codelist.

Ok. Point taken. Notifying @dih-cdisc

[EMuhlbradt]

@BSnoeijerCD regarding the 'Controlled Terminology' piece above, we have reviewed the Intervention Type Response codelist with the clinicaltrials.gov list and identified two values that can be added to the list so that we can cover CT.gov list.

[EMuhlbradt]

@BSnoeijerCD - We have reviewed CTIS valid value sets and confirmed that they do not have a codelist that covers what the Intervention Type codelist covers. Therefore there is nothing to add/align there.

[BSnoeijerCD]

@dih-cdisc @EMuhlbradt @czwickl Please see added Masking class in UML below (left bottom of the picture) with corresponding relationship role and attribute description. I also added the relationship maskingRoles to the studyDesign class to refer to this. Are you ok with the naming?

[dih-cdisc]

@BSnoeijerCD @EMuhlbradt

WRT to "other" values discussed above. We need to be cautious of null flavours. Want to handle consistently and I think we have a few, the M11 reason for change comes to mind and has the need for the "other" string value. We can use a datatype along the lines of FHIR datatypes.

Wise first move might be to separate this concern out so we can finish this ticket. Make a list of places where we have the "other" need and then handle in the same manner

[BSnoeijerCD]

@BSnoeijerCD @EMuhlbradt

WRT to "other" values discussed above. We need to be cautious of null flavours. Want to handle consistently and I think we have a few, the M11 reason for change comes to mind and has the need for the "other" string value. We can use a datatype along the lines of FHIR datatypes.

Wise first move might be to separate this concern out so we can finish this ticket. Make a list of places where we have the "other" need and then handle in the same manner

Agreed. I will make a separate ticket for it.

[dih-cdisc]

Overall changes for release 2.8

[BSnoeijerCD]

@BSnoeijerCD @EMuhlbradt

WRT to "other" values discussed above. We need to be cautious of null flavours. Want to handle consistently and I think we have a few, the M11 reason for change comes to mind and has the need for the "other" string value. We can use a datatype along the lines of FHIR datatypes.

Wise first move might be to separate this concern out so we can finish this ticket. Make a list of places where we have the "other" need and then handle in the same manner

See ticket #243

[BSnoeijerCD]

@EMuhlbradt @czwickl : 1 minor change needed in CT: role is referring to CT and thus to the code class. Therefore the Role should be "Complex Datatype Relationship".

[EMuhlbradt]

@EMuhlbradt @czwickl : 1 minor change needed in CT: role is referring to CT and thus to the code class. Therefore the Role should be "Complex Datatype Relationship".

@BSnoeijerCD fixed