Page History
These SDTM datasets represent the data collected above. An abbreviated Tobacco Product Identifiers and Descriptors (TO) domain example is also provided for reference.
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. Jira showSummary false server Issue Tracker (JIRA) serverId 85506ce4-3cb3-3d91-85ee-f633aaaf4a45 key TOBA-121
Dataset wrap | ||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||
|
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 |
---|---|---|---|
EMIMDRCD | IMDRF Code | text | IMDRFANNEXA |
EMIMDRFL2 | IMDRF Level 2 | text | IMDRFANNEXA |
EMIMDRFL1 | IMDRF Level 1 | text | IMDRFANNEXA |
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 |
The SDTM EM dataset is shown below.
Dataset wrap | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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 | ||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||
|
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 | ||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The RELREC dataset was used to record the relationship between the EM dataset and any reported AE represented in the AE dataset.
Expand | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||
|
Panel |
---|
Team needs to decide : The level of modelling devices. We can model the single device with no components and collect AE related to the single device ( electronic cigarette ) . or we can model the components of the device ( a mouthpiece or drip tip, a cartridge (tank), a heating element or atomizer, which is sometimes accompanied by a clearomizer, and a battery.))
|
Device events in tobacco 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.
Xformpusher | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Order | TAUG Reference | CDASHIG Variable | Question Text | Prompt | Data Type | CRF Completion Instructions | SDTMIG Target | SDTM Variable Mapping | Controlled Terminology Codelist Name | CRF Implementation Notes | Permissible Values | Pre-populated Value | Query Display | List Style | Hidden | 1 | TAUG-T1D-P&D | SPDEVID | What device experienced the event? | Device Experienced Event | text | Indicate the device that was involved in the incident. | SPDEVID | In 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 900 | radio | 2 | TAUG-T1D-P&D | DESPID | What is the device event identifier? | Device Event Identifier | text | DESPID | Sequential number usually populated by the system for use in associated the event with other CRFs, e.g,. AE | Sponsor-defined | Y | 5 | TAUG-T1D-P&D | DECAT | What type of device event was experienced? | Type of Device Event | text | Indicate 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 captured | Device operational issue; User error; Inadequate labeling; Other | radio | 6 | TAUG-T1D-P&D | DETERM | Describe the device event. | Device Event | text | Record a description of the device event that occurred. | DETERM | 7 | TAUG-T1D-P&D | DESTDAT | What was the start date when the event first occurred or was identified? | Start Date | text | Record the date that the device event first occurred or was noted using this format (DD-MON-YYYY). | DESTDTC | No end date is included as the device may never be repaired, etc. | 8 | TAUG-T1D-P&D | DESETTNG | What was the setting where the device event occurred? | Event Setting | text | Record where the device incident occurred. | NSDE.DESETTNG | (SETTING) | Home; Hospital; Outpatient Clinical; Other | radio | 9 | TAUG-T1D-P&D | DESTNGOT | If Other, what was the setting where the device event occurred? | Other Event Setting | text | Specify the other setting where the incident occurred, if applicable. | NSDE.DESTNGOT | 10 | TAUG-T1D-P&D | DEPATT | How frequently did the event occur? | Event Frequency | text | Record how often the incident occurred. | DEPATT | Controlled Terminology list (FREQ) can be used | Single Event; Intermittent; Continuous | radio | 11 | TAUG-T1D-P&D | DEACNDEV | What action was taken with or to study device? | Action Taken With Device | text | Record 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 | radio | 12 | TAUG-T1D-P&D | DEAENO(n) | What was the identifier for the primary adverse event(s) associated with or related to this device event? | Related Adverse Event ID | text | Record the ID of the primary AE associated with the device event, if any. | N/A | ASSOCIATE WITH RELATED RECORD VIA RELREC | This field is typically used to help create RELREC in SDTM. Multiple fields (DEAENO1, DEAENOn) may be created. |
Dataset wrap | |||||||||||||||
| |||||||||||||||
Rowcaps | | ||||||||||||||
Rows 1-4: | Show the 3 characteristics chosen to create the device identifier SPDEVID for a CGM. The DEVTYPE is required for all devices in DI; the manufacturer, model, together identify the device to the degree of granularity required in the study. | ||||||||||||||
Rows 5-8: | Show the same 3 characteristics used to create a device identifier (SPDEVID) for a second CGM. | ||||||||||||||
Dataset2 | |||||||||||||||
Row | STUDYID | DOMAIN | SPDEVID | DISEQ | DIPARMCD | DIPARM | DIVAL | ||||||||
1 | TOB07 | DI | 01-ABC | 1 | DEVTYPE | Device Type | Mouthpiece | ||||||||
2 | TOB07 | DI | 01-ABC | 2 | MANUF | Manufacturer | Reliable Devices | ||||||||
3 | TOB07 | DI | 01-ABC | 3 | MODEL | Model Number | 700XYZ | ||||||||
5 | TOB07 | DI | 02-ABC | 1 | DEVTYPE | Device Type | Cartridge | ||||||||
6 | TOB07 | DI | 02-ABC | 2 | MANUF | Manufacturer | ManF A Device | 7 | TOB07 | DI | 02-ABC | 3 | MODEL | Model Number | 900 Tob