Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

These SDTM datasets represent the data collected above. An abbreviated Tobacco Product Identifiers and Descriptors (TO) domain example is also provided for reference.

Jira
showSummaryfalse
serverIssue Tracker (JIRA)
serverId85506ce4-3cb3-3d91-85ee-f633aaaf4a45
keyTOBA-121
TO provides a mechanism for uniquely identifying a tobacco product and is the source of the SPTOBID variable. For more information on this domain, see Section 3.1.1, Tobacco Product Identifiers and Descriptors. Only 1 tobacco product was of interest in the study. 

Dataset wrap
NameTO
Dataset2
RowSTUDYIDDOMAINSPTOBIDTOSEQTOPARMCDTOPARMTOCATTOVAL
1TB123TOVAPE-Z01

1

TBPRDCATTobacco Product CategoryPRODUCT IDENTIFIERENDS (VAPES)
2TB123TOVAPE-Z012TBPRSCATTobacco Product SubcategoryPRODUCT IDENTIFIERCLOSED E-CIGARETTE
3TB123TOVAPE-Z013MANUFManufacturerPRODUCT IDENTIFIERXXX VAPES USA

These product malfunctions and events are represented in EM. Events not specifically associated with the product device should not be represented in this domain.     

The applicant used a standardized or dictionary-derived text for the description of an issue or events. (Note: CDISC does not prescribe what standardized or dictionary-derived text should be used.) The applicant decided to use the International Medical Device Regulators Forum (IMDRF) document terminologies for categorized adverse event reporting for the medical problem codes. The name and version of the dictionary used to map terms must be provided in a Define.XML ExternalCodeList element (see Section 2.10, Standards for Data Exchange).

EMDECOD was the Level 3 IMDRF term. NSVs were used to represent the various coding level variables defined in the dictionary. 

Example SUPPEM Variable Metadata

Variable Label Type Codelist
EMIMDRCDIMDRF CodetextIMDRFANNEXA 
EMIMDRFL2IMDRF Level 2textIMDRFANNEXA
EMIMDRFL1IMDRF Level 1textIMDRFANNEXA

Example External Dictionaries

Codelist

External Dictionary Name

Dictionary Version

Reference

IMDRFANNEXA IMDRF Terminologies for Categorized Adverse Event Reporting (AER): Terms, Terminology Structure and Codes: Annex A 

Release Number: 2022

https://www.imdrf.org/consultations/imdrf-terminologies-categorized-adverse-event-reporting-aer-terms-terminology-structure-and-codes

The SDTM EM dataset is shown below. 

Dataset wrap
NameEM
Dataset2

Row

STUDYID

DOMAIN

USUBJID

SPTOBID

EMSEQ

EMLNKID

EMTERM

EMDECOD

EMMODIFY

EMACNDEV

EMPATT

EMSTDTC

1

TB123

EM

2029

VAPE-Z01

1


Broken Heater

Mechanical Problem

Mechanical Problem

DEVICE REPLACED

SINGLE

2009-12-28

2

TB123

EM

1059

VAPE-Z01

1


Won’t charge

Charging Problem

Charging Problem

BATTERY REPLACED

SINGLE

2009-01-05

3

TB123

EM

3067

VAPE-Z01

1

1

Battery Malfunction

Battery Problem

Battery Problem

BATTERY REPLACED

INTERMITTENT

2009-01-05

The SUPPEM dataset is used to represent the NSVs used for coding the malfunction or event. The parent domain (RDOMAIN) is EM, and IDVAR is EMSEQ. QNAM holds the name of the supplemental qualifier variable being defined. This only shows the data for subject 2029. The data recorded in QVAL applies to the subject’s records, where IDVAR (EMSEQ) equals the value specified in IDVARVAL. 

Dataset wrap
Namesuppem
Dataset2
RowSTUDYIDRDOMAINUSUBJIDIDVARIDVARVALQNAMQLABELQVALQORIGQEVAL
1TB123EM2029EMSEQ1EMIMDRCDIMDR CodeAO5ASSIGNED
2TB123EM2029EMSEQ1EMIMDRL2IMDR Level 2Mechanical ProblemASSIGNED
3TB123EM2029EMSEQ1EMIMDRL1IMDR Level 1Mechanical ProblemASSIGNED

In this study, subject 3067 had an AE associated with the battery problem. This was reported in the AE dataset. Not all variables are shown below for brevity.  

Dataset wrap
Dataset2
RowSTUDYIDDOMAINUSUBJIDSPTOBIDAESEQAELNKIDAETERMAERLDEVEPOCHAESTDTCAEENDTCAESTDYAEENDY
1TB123AE3067VAPE-Z0111SKIN REDNESSRELATEDPRODUCT EXPOSURE2009-01-052009-01-071417

The RELREC dataset was used to record the relationship between the EM dataset and any reported AE represented in the AE dataset. 

Expand
titlerelrec.xpt

Row

STUDYID

RDOMAIN

USUBJID

IDVAR

IDVARVAL

RELTYPE

RELID

1TB005EM
EMLNKID
ONEAEEM1
2TB005AE
AELNKID
ONEAEEM1

Device events in type 1 diabetes (T1D) studies may consist of device problems (which may or may not result in adverse events), device-reported warnings or alarms, calibration events, and replacement of parts. This information is represented in the Device Events (DE) and associated domains. In device studies, cases where the device did not perform as expected are typically called "events" or "incidents," rather than "problems" or "malfunctions," because often the true cause of the issue cannot be determined until a cause analysis is performed. This may or may not be a concern for a given trial depending upon whether the device has already been approved by regulators. Typically, post-approval device studies are less concerned about root-issue attribution.

There is more than one approach to identifying devices in studies. The method chosen will depend upon the granularity at which the sponsor needs to track the devices and will affect how the data are modeled. A device can be identified as a single unit (e.g., a syringe), or its components can be separately identified (e.g., barrel, plunger, needle). The level of granularity a sponsor chooses will be influenced by whether the components will be replaced and/or tracked, and how device/adverse event relationships and actions taken will be assessed.

02-ABC
Xformpusher
OrderTAUG ReferenceCDASHIG VariableQuestion TextPromptData TypeCRF Completion InstructionsSDTMIG TargetSDTM Variable MappingControlled Terminology Codelist NameCRF Implementation NotesPermissible ValuesPre-populated ValueQuery DisplayList StyleHidden
1TAUG-T1D-P&DSPDEVIDWhat device experienced the event?Device Experienced EventtextIndicate the device that was involved in the incident.SPDEVIDIn this case, the sponsor is identifying only the type of device, and not each individual unit. The actual SPDEVID (01-ABC or 02-ABC) would be captured in the field, while the text in the permissible values is shown.01-ABC Reliable Devices CGMon 700;02-ABC Reliable Devices CGMon 900radio2TAUG-T1D-P&DDESPIDWhat is the device event identifier?Device Event IdentifiertextDESPIDSequential number usually populated by the system for use in associated the event with other CRFs, e.g,. AESponsor-definedY5TAUG-T1D-P&DDECATWhat type of device event was experienced?Type of Device EventtextIndicate the investigator's opinion as to what type of device incident was experienced.DECAT(DECAT)This is the investigator's evaluation. In pre-market studies this will not be known until a root cause analysis has occurred; for post-market studies the info can be capturedDevice operational issue; User error; Inadequate labeling; Otherradio6TAUG-T1D-P&DDETERM

Describe the device event.

Device EventtextRecord a description of the device event that occurred.DETERM7TAUG-T1D-P&DDESTDATWhat was the start date when the event first occurred or was identified?Start DatetextRecord the date that the device event first occurred or was noted using this format (DD-MON-YYYY).DESTDTCNo end date is included as the device may never be repaired, etc.8TAUG-T1D-P&DDESETTNGWhat was the setting where the device event occurred?Event SettingtextRecord where the device incident occurred.NSDE.DESETTNG(SETTING)Home; Hospital; Outpatient Clinical; Otherradio9TAUG-T1D-P&DDESTNGOT

If Other, what was the setting where the device event occurred?

Other Event SettingtextSpecify the other setting where the incident occurred, if applicable.NSDE.DESTNGOT10TAUG-T1D-P&DDEPATTHow frequently did the event occur?Event FrequencytextRecord how often the incident occurred.DEPATTControlled Terminology list (FREQ) can be usedSingle Event; Intermittent; Continuousradio11TAUG-T1D-P&DDEACNDEVWhat action was taken with or to study device?Action Taken With DevicetextRecord what action was taken with the device as a result of the incident.DEACNDEV(DEACNDEV)No change; Device modified/adjusted; Device replaced; Removed temporarily; Removed
radio12TAUG-T1D-P&DDEAENO(n)What was the identifier for the primary adverse event(s) associated with or related to this device event?Related Adverse Event IDtextRecord the ID of the primary AE associated with the device event, if any.N/AASSOCIATE WITH RELATED RECORD VIA RELRECThis field is typically used to help create RELREC in SDTM. Multiple fields (DEAENO1, DEAENOn) may be created.
Dataset wrap
Namedi
Rowcaps
Rows 1-4:Show the 4 characteristics chosen to create the device identifier SPDEVID for a CGM. The DEVTYPE is required for all devices in DI; the manufacturer, model, and catalog number together identify the device to the degree of granularity required in the study. Here, it is enough to know the catalog number of the device, and identifying each device unit is not necessary.
Rows 5-8:Show the same 4 characteristics used to create a device identifier (SPDEVID) for a second CGM.
Dataset2
RowSTUDYIDDOMAINSPDEVIDDISEQDIPARMCDDIPARMDIVAL
1CDISC01DI01-ABC1DEVTYPEDevice TypeImplantable glucose monitoring system
2CDISC01DI01-ABC2MANUFManufacturerReliable Devices
3CDISC01DI01-ABC3MODELModel Number

CGMon 700

4CDISC01DI01-ABC4CATNUMCatalog Number01-ABC
5CDISC01DI02-ABC1DEVTYPEDevice TypeImplantable glucose monitoring system
6CDISC01DI02-ABC2MANUFManufacturerReliable Devices
7CDISC01DI02-ABC3MODELModel NumberCGMon 900
8CDISC01DI02-ABC4CATNUMCatalog Number