Study Data Tabulation Model

Implementation Guide for

Medical Devices (SDTMIG-MD)
Version 1.1

Prepared by the
CDISC Device Team

Revision History

Date Author Version Summary of Changes

2018-12-12 Medical Device Team 1.1 Final Finalized provisional version by confirming all variables approved,
and DI and DR domains assigned new roles; minor updates
2012-12-04 Medical Device Team 1.0 Provisional Provisional SDTMIG-MD. Released version reflecting all changes
and corrections identified during the comment period.
2012-01-23 Medical Device Team 1.0 Draft Released version for public comment

See Appendix F for Representations and Warranties, Limitations of Liability, and Disclaimers.
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

CONTENTS
1 INTRODUCTION ................................................................................................................. 3
1.1 PURPOSE ................................................................................................................................................................ 3
1.2 ORGANIZATION OF THIS DOCUMENT ..................................................................................................................... 4
1.3 RELATIONSHIP TO PRIOR DOCUMENTS .................................................................................................................. 4
1.4 GENERAL NOTES AND DEFINITIONS ...................................................................................................................... 5
1.4.1 Electronic Submission ............................................................................................................................ 5
1.4.2 Differences Between Drug and Device Terminology............................................................................. 5

2 SDTM-BASED DEVICE DOMAINS .................................................................................. 6

2.1 OVERVIEW............................................................................................................................................................. 6
2.2 DOMAIN DESCRIPTIONS ......................................................................................................................................... 6
2.3 OBSERVATION CLASSES OF THE DEVICE DOMAINS ............................................................................................... 7
2.4 HOW DEVICE DOMAINS RELATE TO EXISTING DOMAINS IN THE SDTMIG ........................................................... 8
2.5 HOW DEVICE DOMAINS RELATE TO EACH OTHER ................................................................................................ 8

3 DEVICE DOMAIN SPECIFICATIONS........................................................................... 13

3.1 DEVICE IDENTIFIERS (DI) .................................................................................................................................... 13
3.1.1 Assumptions for the Device Identifiers Domain Model ....................................................................... 14
3.1.2 Examples for the Device Identifiers Domain Model ............................................................................ 16
3.2 DEVICE-IN-USE (DU) .......................................................................................................................................... 18
3.2.1 Assumptions for the Device-In-Use Domain Model ............................................................................ 20
3.2.2 Examples for the Device-In-Use Domain Model ................................................................................. 21
3.3 DEVICE EXPOSURE (DX) ..................................................................................................................................... 23
3.3.1 Assumptions for the Device Exposure Domain Model ........................................................................ 25
3.3.2 Examples for the Device Exposure Domain Model ............................................................................. 26
3.4 DEVICE EVENTS (DE).......................................................................................................................................... 28
3.4.1 Assumptions for the Device Events Domain Model ............................................................................ 30
3.4.2 Examples for the Device Events Domain Model ................................................................................. 31
3.5 DEVICE TRACKING AND DISPOSITION (DT) ......................................................................................................... 33
3.5.1 Assumptions for the Device Tracking and Disposition Domain Model ............................................... 34
3.5.2 Examples for the Device Tracking and Disposition Domain Model .................................................... 35
3.6 DEVICE-SUBJECT RELATIONSHIPS (DR) .............................................................................................................. 37
3.6.1 Assumptions for the Device-Subject Relationships Domain Model .................................................... 37
3.6.2 Examples for the Device-Subject Relationships Domain Model ......................................................... 37
3.7 DEVICE PROPERTIES (DO) ................................................................................................................................... 39
3.7.1 Assumptions for the Device Properties Domain Model ....................................................................... 40
3.7.2 Examples for the Device Properties Domain Model ............................................................................ 41

4 CROSS-DOMAIN RELATIONSHIP EXAMPLES......................................................... 42

4.1 DEVICE-IN-USE AND TEST RESULTS ................................................................................................................... 42

APPENDICES ............................................................................................................................. 46
APPENDIX A: GLOSSARY AND ABBREVIATIONS ........................................................................................................... 46
APPENDIX B: REVISION HISTORY ................................................................................................................................. 48
APPENDIX C: CDISC CONTROLLED TERMINOLOGY..................................................................................................... 49
APPENDIX D: OTHER RELEVANT STANDARDS.............................................................................................................. 49
Appendix D1: Unique Device Identifier (UDI) ....................................................................................................... 50
Appendix D2: Code of Federal Regulations ............................................................................................................ 50
Appendix D3: International Organization for Standardization (ISO) ...................................................................... 50
Appendix D4: Code Lists and Terminology ............................................................................................................ 50
APPENDIX E: PARTICIPATING COMPANIES ................................................................................................................... 50
APPENDIX F: REPRESENTATIONS AND WARRANTIES, LIMITATIONS OF LIABILITY, AND DISCLAIMERS ........................ 51

Page 2 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
1 Introduction
1.1 Purpose
This Medical Device Implementation Guide (IG) to the Study Data Tabulation Model (SDTM) defines
recommended standards for the submission of data from clinical trials in which medical devices were used, and is
referred to as the SDTMIG-MD. This implementation guide is based on the original SDTM Implementation Guide
(SDTMIG) developed for human clinical trials. The device standards are intended to cover both paper and electronic
regulatory submissions. Here, “electronic” means submissions that provide study and other data in machine-readable
electronic database format.

Devices are an important and growing part of the medical world, both on their own and in combination with drugs or
biologic agents. The ISO 14155 Medical Devices Good Clinical Practices standard defines a “device” as:

Any instrument, apparatus, implement, machine, appliance, implant, software, material, or other similar or
related article

• a) intended by the manufacturer to be used, alone or in combination, for human beings for one or more of
the specific purpose(s) of
o 1) diagnosis, prevention, monitoring, treatment or alleviation of disease,
o 2) diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury,
o 3) investigation, replacement, modification, or support of the anatomy or of a physiological
process,
o 4) supporting or sustaining life,
o 5) control of conception,
o 6) disinfection of medical devices, and
• b) which does not achieve its primary intended action in or on the human body by pharmacological,
immunological or metabolic means, but which may be assisted in its intended function by such means

Note 1 to entry: The term “medical device” is usually defined by national regulations. For the purposes of this
International Standard, this definition does not list “in vitro diagnostic medical devices” (see ISO 13485:2003,
definition 3.7[1]).

Although different types of devices have widely varying data requirements, most Class II and III devices requiring
regulatory data submissions share some fundamental characteristics. This document contains SDTMIG regulatory
data submission standards for some key data shared by most types of devices. It is intended to guide the
organization, structure, and format of standard device clinical trial tabulation datasets submitted to regulatory
authorities. This document also describes SDTM device domains, showing rules and examples implementing these
domains specifically for device-related data.

This document does not contain all the domains necessary for sponsors to implement CDISC SDTM-based
standards for medical device studies. Specifically, this document does not discuss existing domains that may be
common to both device and drug studies, for example, Adverse Events and Demographics. These can be found in
the SDTMIG (available for download at https://www.cdisc.org/). In addition, the domains defined in this
implementation guide are not necessarily required; sponsors should use those domains that represent the data
necessary to address the appropriate scientific and regulatory needs.

The domains defined in this document comprise some of the device-specific data that may be needed for the clinical
sections of a regulatory submission involving devices under study. Data may be required to answer protocol
questions, to address associated safety questions, or to associate specific devices with subjects. Some data are
collected on Case Report Forms (CRF) that are completed by the investigative sites, whereas other data are usually
derived by sponsors for the SDTM-based datasets. Other data needed for the submission—such as manufacturing
quality information—may be included in other sections of the submission, but are not considered clinical data and

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 3
Final 12 December 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

therefore are not included in the SDTM-based domains. The device domains include some non-subject data
definitions, such as Device Events and Device Tracking information.

The domains in this document may also be used for studies where devices are used to obtain study measurements or
results, but the devices themselves are not the object of the study. For example, a study that uses an MRI to capture
images of the brain to measure brain volume for an Alzheimer's trial may choose to use the Device-In-Use domain
to capture the field strength and slice thickness setting for each image, even though the MRI machine is not being
studied and is already approved for use. The domains used in these circumstances will be determined by the sponsor
based on the data needed for submission.

1.2 Organization of This Document

This document contains information on how to format tabulation data for the purposes of submission. Although the
document is self-contained with respect to device-specific information, it has been developed to be harmonized with
other CDISC standards.

This document is organized into the following sections:

• Section 1, Introduction, provides an orientation to data submitted for medical devices.

• Section 2, SDTM-Based Device Domains, provides an overview of the device domains and their
relationship to each other as well as to existing domains described in the SDTMIG.
• Section 3, Device Domain Specifications, describes each of the device domains, including domain models,
assumptions, and examples.
• Section 4, Cross-Domain Relationship Examples, describes the relationship between Device-In-Use and
results generated from the measurement or output of the device. It illustrates how domains can be linked.
• The Appendices provide additional information regarding the Medical Devices project as well as references
and supplemental material relevant to implementation of the SDTMIG-MD.

1.3 Relationship to Prior Documents

This document is not intended to replace the standards defined in the current SDTMIG. The SDTMIG-MD should
be implemented together with the SDTMIG (available at https://www.cdisc.org/). The SDTMIG is based on the
general SDTM conceptual model for representing data to be submitted to regulatory authorities. The SDTM and
SDTMIG should be read prior to reading the SDTMIG-MD. An understanding of both of these documents is needed
before attempting to understand this implementation guide. The version used (and whether to update to newer
version if relevant) is the sponsor’s decision, based upon their needs and their communications with the FDA.

The sections of the SDTMIG that will be the most relevant are:

• Section 2, Fundamentals of the SDTM

• Section 4, Assumptions for Domain Models (review the introductory paragraphs in the main sections and
scan the remainder)
• Section 6, Domain Models Based on the General Observation Classes (introductory paragraphs for each
domain and scan the included variables)
• Section 8, Representing Relationships and Data (introductory paragraphs to the main sections, and scan the
remainder)
• Appendix C, Controlled Terminology (introductory paragraphs and scan the remainder)

Page 4 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
1.4 General Notes and Definitions

1.4.1 Electronic Submission

Different segments of the drug/biologics/devices industry have different underlying assumptions with respect to
submitting data to regulatory authorities. “Electronic data” refers to the practice of sending study data to a regulatory
agency in an electronic format such as a dataset. In this type of submission, documents are submitted in electronic
files such as MS Word or PDF, and subject and device data from clinical trials are submitted as electronic datasets
using a defined data format. The following considerations might be useful to sponsors submitting data in an
electronic format:
• Paper versus electronic regulatory submission: These standards are intended to be applicable for
regulatory submissions regardless of whether the data are sent on paper, in electronic document files, or as
electronic study data databases.
• Paper CRFs versus electronic CRFs: The term “CRF” used throughout this document refers to both
paper and electronic formats, unless otherwise specified.
• Fields versus variables: The term data collection “fields” refers to questions that are seen on the CRF (i.e.,
the concept of the information solicited by a question). The term data collection “variables” refers to how
data are organized and stored in a clinical database.
• Mechanisms for data collection: Different data collection mechanisms can be used to control how data
are collected (e.g., tick boxes, check boxes, radio buttons, drop-down lists). For the purposes of this
document, these terms will be used interchangeably. The SDTMIG-MD is designed to accommodate both
paper and electronic data capture, although it is assumed that data will be entered into an electronic
database at some point.
• Ancillary: An “ancillary device” is one that is used in a study but is not the device under study.
Information may or may not be captured for ancillary devices.

1.4.2 Differences Between Drug and Device Terminology

Differences exist between drugs and devices in the implementation of specific domains. For example, the terms
Accountability, Disposition, and Exposure are used somewhat differently. Currently, many CDISC definitions are
aligned with those of the drug sector. Table 1 illustrates the different uses of these terms.

Table 1.4.2.1 Comparison and Contrast of Term Usage in Device Versus Drug Trials
Term Device Definition Drug Definition
Accountability Device Accountability: Tracking where the device is Drug Accountability: Tracking where the drug is;
physically; shipping information may be on the CRF; accounting for all of the drug (e.g., pill counts); in
usually between sponsor and site. the clinical trial, usually between the site and the
subject; shipping info not usually captured on CRFs.
Disposition Device Disposition: The final location/status of the Subject Disposition: The status of the subject’s
device at the time of submission or the end of the trial. participation in the trial at a given time point (e.g.,
completed the study, withdrew early).
Exposure Device Exposure: The interaction or interface between Study Drug Exposure: The amount of study drug to
the subject and the device or device constituents. which the subject is exposed.
Note that exposure information about a drug delivered
via a device would generally be placed in Study Drug
Exposure (EX). Sponsors should confer with the
regulatory reviewers to determine the correct domain to
use.

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 5
Final 12 December 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

2 SDTM-Based Device Domains

2.1 Overview
This Implementation Guide includes five Study Data Tabulation Model (SDTM) Device domains based on the
SDTM Events, Findings, and Interventions general observation classes, one Relationships dataset structure, and one
Study Reference dataset structure. These domains will accommodate most of the core requirements for the majority
of studies with implantable, diagnostic, and imaging devices. When CDASH models are developed, they will be
presented in both normalized and non-normalized layouts. Users may employ whichever structure is optimal for
their data capture.

Medical Device domains are somewhat different from many other SDTM domains developed thus far, in that they
may capture information about entities other than the study subject or the trial itself. The MD domains must also
accommodate a more complex set of data, and more variation in the relationship of the device to subjects, than is
typical in drug development studies. As a result, developing a relationship structure that is not typically required in
most subject-related data (i.e., Device-Subject Relationships domain) was required.

2.2 Domain Descriptions

The following seven SDTM-based domains are included in this implementation guide:

1. Device Identifiers (DI): This is a Study Reference domain designed for the submission of information that
identifies a specific device unit. The primary purpose of this domain is to provide a consistent sponsor-
defined variable (SPDEVID) for linking data across Device domains, independent of the level of
granularity by which a device might be identified by a sponsor in a study. The information included in DI
depends upon what is needed to identify the device uniquely within a submission and to meet analysis and
regulatory requirements. The domain is not intended to contain information about characteristics that can
change without affecting the identification of the device, such as supplier details or dial settings (e.g.,
imaging devices). Device identifiers exist independently from subjects; therefore, the DI domain does not
contain USUBJID.
2. Device-In-Use (DU): DU is a Findings domain that contains the values of measurements and settings that
are intentionally set on a device when it is used, and may vary from subject to subject or other target. These
are characteristics that exist for the device, and have a specific setting for a use instance. DU is distinct
from Device Properties (DO), which describes static characteristics of the device. For example, DO would
capture that an MRI machine’s field strength has a range from 0.2 to 3 Tesla, whereas the DU domain
would capture that the field strength for the MRI scan for Subject 123 was 0.5 T.
3. Device Exposure (DX): DX is an Interventions domain that records the details of a subject’s exposure to a
medical device under study. This device is prospectively defined as a test article within a study and may be
used by the subject, on the subject, or be implanted into the subject. Examples include but are not limited to
stents, drug delivery systems, and any other item under study that is defined as a device in the applicable
regulations.
4. Device Events (DE): DE is an Events domain that contains information about various kinds of device-
related events, such as device malfunctions. A device event may or may not be associated with a subject or
a visit. If a device event, such as a malfunction, results in an adverse event, then this information should be
recorded in the Adverse Events (AE) domain (see SDTMIG, AE domain). The relationship between the AE
and a device malfunction in DE can be recorded using RELREC (see SDTMIG section “Relating
Datasets”) and appropriate identifying variables such as DESPID and AESPID.
5. Device Tracking and Disposition (DT): The DT domain is an Events domain that represents a record of
tracking events for a given device (e.g., initial shipment, deployment, return, destruction). Different events
would be relevant to different types of devices. The last record represents the device disposition at the time
of submission. The sponsor decides upon the level of granularity that is appropriate for this domain based
on the type of device and agreements with the regulatory agencies.
6. Device-Subject Relationships (DR): The DR domain is a Relationships dataset structure that links each
subject to devices to which they have been exposed. Information in this table may have been initially

Page 6 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
 collected and submitted in other domains (e.g., Device Exposure, Device Tracking and Disposition, Device
Events). This domain, however, provides a single, consistent location to find the relationship between a
subject and a device, regardless of the device or the domain in which subject-related data may have been
collected or submitted.
7. Device Properties (DO): The DO Findings domain is used to report characteristics of the device that are
important to include in the submission and do not vary over the course of the study but are not used to
identify the device. Examples include expiration date or shelf life. Device properties exist independently
from subjects and therefore the DO domain does not contain USUBJID.

Although some domains, such as DU, were developed to support submission of device-related data in both device
and non-device-focused trials (e.g., where the device is used to generate study measurements and is not itself under
study), any of these domains can be used in any trial type, including device/drug and device/biologic combination
trials, if deemed appropriate by the sponsor and regulators.

2.3 Observation Classes of the Device Domains

The following list shows the observation class for each device domain.

Study Reference
• Device Identifiers (DI)

Relationships
• Device-Subject Relationships (DR)

Interventions General Observation Class

• Device Exposure (DX)

Events General Observation Class

• Device Events (DE)
• Device Tracking (DT)

Findings General Observation Class

• Device-In-Use (DU)
• Device Properties (DO)

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 7
Final 12 December 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

2.4 How Device Domains Relate to Existing Domains in the

SDTMIG
Figure 2.4.1 illustrates device and existing SDTM-based domains, and the combinations of subject and/or device
data they might contain. The domains listed below are only examples of those that might or might not contain device
and/or subject data.

Figure 2.4.1 Device and Subject Data in Different Domains

Will Have Device Will Have Device Will Have Will Have
Subject and/or

Will Have
Device Data

Data; Data; Device Data Subject Data; Subject Data;

&
No Subject May Have Will Have May have No Device Data
Data Subject Data Subject Data Device Data

Device In-Use Device

Device Exposure (DX), Adverse Demographics
(DU), Device
Domains
Example

Properties Device- Events (AE), (DM), Subject

Tracking (DT),
(DO), Device Subject Drug Exposure Disposition
Device Events
Identifiers (DI) Relationship (EX) (DS)
(DE)
(DR)

2.5 How Device Domains Relate to Each Other

Figures 2.5.1-2.5.6 show simple examples of how the different domains relate to each other through the choice of
identifiers present in each. In these examples, Subject 02-1024 in Study ABC-123 had one telescoping titanium
orthopedic rod implanted. The rod was sourced from Rods, Co. (DI) and has a length of 4 cm when fully contracted
and 8 cm when fully extended (DO). The sponsor would decide whether to model the lengths separately in DO as
minimum and maximum lengths, or as a single size characteristic. Here, the sizes are separated.

The model name is SuperLynx (DI), and the serial number for the rod is 274962 (DI). These, plus the manufacturer,
are the only characteristics needed to identify each rod uniquely. This domain associates the three key identifier
characteristics to the single SPDEVID (TEL-3745), used to reference the device across the other domains. The
fourth record in DI is the DEVTYPE, which is required for all device submissions where any device-specific
information is included, and is encouraged for the remainder. For post-marketing studies, the use of FDAUDI (the
FDA’s UDI identifier) is also required, but this example represents a pre-approval study.

The rod was shipped from the sponsor to Site 02 on 26-Apr-2011 (DT), and implanted into the subject on 29-Apr-
2011 (DT & DX). When implanted, the telescoping length was set to 4 cm (DU). The rod was implanted into the
right femur (DX). There were no malfunctions or other events (no DE), and the device was not explanted (no
explantation record in DT and no end date in DX). In this case, the relationship between the device and the subject is
derived from DX into DR. The purpose of DR is to provide a link between device and subject data independent of
the identifiers that exist on each domain, or of the domains that are present for a given submission.

The different identifiers (study, subject, and device) are color and pattern coded in the following figures to facilitate
identifying the relationships of the data among the domains and to see how different domains use different

Page 8 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
combinations of identifiers. Note that, in order to simplify the display, the tables contain a subset of the available
variables.

Figure 2.5.1 Study Device Identifiers (DI) Using Study ID and Sponsor Device ID Only
STUDYID SPDEVID DIPARMCD DIPARM DIVAL

Study Sponsor Device Device Identifier Element Device Identifier Device Identifier
Identifier Identifier Short Name Element Name Element Value

ABC-123 TEL-3745 MANUF Manufacturer Rods, Co.

ABC-123 TEL-3745 MODEL Model SuperLynx

ABC-123 TEL-3745 SERIAL Serial Number 274962

Telescoping orthopedic
ABC-123 TEL-3745 DEVTYPE Type of device
rod

Figure 2.5.2 Device Properties Using Study ID and Sponsor Device ID Only
STUDY
USUBJID SPDEVID DOTESTCD DOTEST DOORRES DOORRESU
ID

Study Unique Subject Sponsor Device Device Property Device Property Result or Finding Original
Identifier Identifier Identifier Short Name Test Name in Original Units Units

ABC-123 02-1024 TEL-3745 COMPOS Composition Titanium

ABC-123 02-1024 TEL-3745 MXLENGTH Maximum Length 8 cm

ABC-123 02-1024 TEL-3745 MNLENGTH Minimum Length 4 cm

Figure 2.5.3 Device Exposure Using Study ID, Subject ID, and Sponsor Device ID
STUDYID USUBJID SPDEVID DXTRT DXLOC DXLAT DXSTDTC DXENDTC

Name of
Unique Sponsor Location Laterality Start Date/Time End Date/Time
Study Device
Subject Device of Device of Device of Device of Device
Identifier Exposure or
Identifier Identifier Exposure Exposure Exposure Exposure
Output

SuperLynx
ABC-123 02-1024 TEL-3745 FEMUR RIGHT 2011-04-29 (null)
Ortho Rod

Figure 2.5.4 Device-In-Use Using Study ID, Subject ID, and Sponsor Device ID
STUDYID USUBJID SPDEVID
DUTESTCD DUTEST DUORRES DUORRESU DUDTC

Study Unique Sponsor Device-In-Use Device-In- Result or Date/Time

Original
Identifier Subject Device Test Short Use Test Finding in Device Used
Units
Identifier Identifier Name Name Original Units with Test/ Setting

ABC-123 02-1024 TEL-3745 ISLENGTH In situ length 4 cm 2011-04-29

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 9
Final 12 December 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

Figure 2.5.5 Device Tracking Using Study ID and Device ID Only

STUDYID SPDEVID DTTERM DTPARTY DTPRTYID DTSTDTC

Study Sponsor Device Reported Term for the Party Responsible Responsible Party Start Date/Time of
Identifier Identifier Tracking Event for the Device Identifier Device Tracking Event

ABC-123 TEL-3745 SHIPPED SITE 02 2011-04-26

ABC-123 TEL-3745 IMPLANTED SUBJECT 02-1024 2011-04-29

Note: when a subject appears in this domain, it is a value of DTPARTY/DTPRTYID.

Figure 2.5.6 Device-Subject Relationship Using Study ID, Subject ID, and Sponsor Device ID
STUDYID USUBJID SPDEVID

Unique Subject Sponsor Device

Study Identifier
Identifier Identifier

ABC-258 04-1027 TEL-8526

Figures 2.5.7-2.5.15 show more complex examples of domain relationships. In Study ABC-258, Subject 04-1027
had a telescopic titanium orthopedic rod implanted. The rod’s maximum extended length is 8 cm, its minimum
length is 4 cm, and the rod’s composition is of titanium (DO). The test device’s manufacturer (Rods, Co.) appears in
DI, along with the model (SuperLynx) and serial number (562987) to ensure uniqueness. In this case, there is a
comparator device (not shown), and similar information would be added for the comparator device. DR links device
and subject data regardless of what identifiers exist.

The rod was shipped from the sponsor to Site 04 on 23-May-2011 (DT), and implanted into the subject on 12-Jun-
2011 (DT & DX). It was explanted on 01-Jul-2011, and shipped back to the sponsor on 25-Jul-2011 (DT & DX).
Note that the implantation and explantation data in DT is for device accountability and not for exposure. In other
cases it may not mirror exposure as closely. When implanted, the telescoping length was set to 6 cm (DU).

The device developed a fissure (DE), considered a malfunction (DECAT), at which point the subject developed
inflammation at the incision site (AE). This AE caused the device to be explanted (DE, and could also appear in
DX) and the subject to discontinue from the study (DS). If the appropriate links are collected, the malfunction and
its associated AE can be linked via RELREC records. Note that this implementation guide does not include the AE
and DS domains, because they are defined in the SDTMIG.

As with the preceding examples, the different identifiers (study, subject, and device) are color and pattern coded in
the data tables below to facilitate identifying the relationships of the data between the domains. Note that, in order to
simplify the display, the tables contain a subset of the available variables.

Figure 2.5.7 Study Device Identifiers Using Study ID and Sponsor Device ID Only
STUDYID SPDEVID DIPARMCD DIPARM DIVAL

Study Sponsor Device Device Identifier Element Device Identifier Element Device Identifier Element
Identifier Identifier Short Name Name Value

ABC-258 TEL-8526 MANUF Manufacturer Rods, Co.

ABC-258 TEL-8526 MODEL Model SuperLynx

ABC-258 TEL-8526 SERIAL Serial Number 562987

ABC-258 TEL-8526 Telescoping orthopedic

DEVTYPE Type of device
rod

Page 10 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
Figure 2.5.8 Device Properties Using Study ID and Sponsor Device ID Only

STUDYID USUBJID SPDEVID DOTESTCD DOTEST DOORRES DOORRESU

Study Unique Subject Sponsor Device Device Property Device Property Result or Finding
Original Units
Identifier Identifier Identifier Short Name Test Name in Original Units

Maximum
ABC-258 04-1027 TEL-8526 MXLENGTH 8 cm
Length

Minimum
ABC-258 04-1027 TEL-8526 MNLENGTH 4 cm
Length

ABC-258 04-1027 TEL-8526 COMPOS Composition Titanium

Figure 2.5.9 Device Exposure Using Study ID, Subject ID and Sponsor Device ID
STUDYID USUBJID SPDEVID DXTRT DXLOC DXLAT DXSTDTC DXENDTC

Start
Unique Sponsor Name of Device Location Laterality of End Date/Time
Study Date/Time of
Subject Device Exposure or of Device Device of Device
Identifier Device
Identifier Identifier Output Exposure Exposure Exposure
Exposure

ABC-258 04-1027 TEL-8526 SuperLynx Ortho

FEMUR LEFT 2011-06-12 2011-07-01
Rod

Figure 2.5.10 Device-In-Use Using Study ID, Subject ID, and Sponsor Device ID

STUDYID USUBJID SPDEVID DUTESTCD DUTEST DUORRES DUORRESU DUDTC

Study Unique Sponsor Result or

Device-In-Use Device-In- Date/Time Device
Identifier Subject Device Finding in
Test Short Use Test Original Units Used with Test/
Identifier Identifier Original
Name Name Setting
Units

In situ
ABC-258 04-1027 TEL-8526 ISLENGTH 6 cm 2011-06-12
length

Figure 2.5.11 Device Tracking Using Study ID and Sponsor Device ID Only
STUDYID SPDEVID DTTERM DTPARTY DTPRTYID DTSTDTC

Study Sponsor
Reported Term for the Party Responsible Responsible Party Start Date/Time of Device
Identifier Device
Tracking Event for the Device Identifier Tracking Event
Identifier

ABC-258 TEL-8526 SHIPPED SITE 04 2011-05-23

ABC-258 TEL-8526 IMPLANTED SUBJECT 04-1027 2011-06-12

ABC-258 TEL-8526 EXPLANTED SITE 04 2011-07-01

ABC-258 TEL-8526 SHIPPED SPONSOR 2011-07-25

Note: when a subject appears in this domain, it is a value of DTPARTY/DTPRTYID.

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 11
Final 12 December 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

Figure 2.5.12 Device Events Using Study ID, Subject ID, and Sponsor Device ID
STUDY
USUBJID SPDEVID DESPID DETERM DEDECOD DECAT DEACNDEV DESTDTC DEENDTC
ID

Reported Device Start End

Unique Sponsor Sponsor-
Study Term for Events Category of Action Taken Date/Time Date/Time
Subject Device Defined
Identifier Device Dictionary- Device Event with Device of Device of Device
Identifier Identifier Identifier
Event Derived Term Event Event

Fissure Device
ABC-258 04-1027 TEL-8526 2 FISSFORM MALFUNCTION 2011-06-25
formation Explanted

Figure 2.5.13 Device-Subject Relationship Using Study ID, Subject ID, and Sponsor Device ID
STUDYID USUBJID SPDEVID

Unique Subject Sponsor Device

Study Identifier
Identifier Identifier

ABC-258 04-1027 TEL-8526

At the time of this publishing, the mechanism of linking the specific AE to the specific device has not yet been
established. Figure 2.5.14 shows what the data might look like in the AE domain. The linkage could be
accomplished using --SPID variables in data capture, and this could permit the construction of a RELREC dataset.

Figure 2.5.14 Adverse Events Using Study ID and Subject ID

STUDYID USUBJID AESPID AEDECOD AETERM AEACNDEV AESTDTC AEENDTC

Unique Sponsor- Event

Study Dictionary-Derived Other Action Event Start Event End
Subject Defined Verbatim
Identifier Term Taken For AE Date/Time Date/Time
Identifier Identifier Term

Incision site Device

ABC-258 04-1027 3 INFLAMMATION 2011-06-25 2011-07-10
inflammation removed

ABC-258 04-1027 4 HEADACHE Headache None 2011-06-30 2011-07-02

The event in Figure 2.5.15 is Discontinuation from the Study Due to an AE. The “start” date is also used for a point
in time event, which is the case here. If the specific device needs to be linked to this event, it could be accomplished
in data capture using --SPID variables, which can then be reflected here in a RELREC dataset.

Figure 2.5.15 Subject Disposition Using Study ID and Subject ID only.

STUDYID USUBJID DSDECOD DSTERM DSSTDTC

Study Unique
Standardized Disposition Disposition Event Reported Disposition Event Start
Identifier Subject
Term Term Date/Time
Identifier

ABC-258 04-1027 ADVERSE EVENT Adverse event 2011-07-01

Page 12 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
3 Device Domain Specifications
3.1 Device Identifiers (DI)
di.xpt, Device Identifiers - Study Reference, Version 1.1. One record per device identifier per device, Tabulation
Controlled
Variable Terms, Code
Variable Label Type Role CDISC Notes Core
Name List, or
Formata
STUDYID Study Identifier Char Identifier Unique identifier for a study. Req
DOMAIN Domain Char DI Identifier Two-character abbreviation for the domain. Req
Abbreviation
SPDEVID Sponsor Device Char Identifier Sponsor-defined identifier for the device. Req
Identifier It must be unique for each tracked unit of the device under study, and can be at
whatever level of granularity the device should be identified (e.g., model or serial
number, combination of identifiers).
DISEQ Sequence Num Identifier Sequence number given to ensure uniqueness within a parameter within a device Exp
Number (SPDEVID) within dataset.
If there is only one value for DIPARMCD for each value of SPDEVID, then DISEQ
will be 1 for all records. DISEQ must be a valid number.
DIPARMCD Device Identifier Char * Topic Short name of the identifier characteristic of the device (e.g., "SERIAL", Req
Element Short "MODEL").
Name A record with DIPARMCD = "DEVTYPE" should be included (see below).
DIPARM Device Identifier Char * Synonym Name of the identifier characteristic of the device. Req
Element Name Qualifier Examples: Serial Number, Model. A record with DIPARM = "DEVTYPE" should
be included (see below).
DIVAL Device Identifier Char * Result Value for the parameter. Value for the parameter. When DIPARMCD=DEVTYPE it Req
Element Value Qualifier should use controlled terminology defined by FDA in their Preferred Term codelist.
FDA has stated a preference for the Global Medical Device Nomenclature (GMDN),
but as of the date of this publication, the GMDN is not freely available to the public.
In its Unique Device Identification rule, FDA indicated that GMDN will not be
required unless it is available to the public at no cost. There is a lookup tool on the
FDA website to map GMDN codes to FDA PT codes.
aAsterisk indicates variable may be subject to controlled terminology.

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 13
December 12, 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

3.1.1 Assumptions for the Device Identifiers Domain Model

1. Definition: Device Identifiers (DI) is a Study Reference domain that provides a mechanism for using multiple identifiers to create a single identifier for
each device.
2. The primary purpose of this domain is to provide a consistent variable (SPDEVID) for linking data across Device domains, independent of the level of
granularity by which a device might be identified by a sponsor in a study. One of the challenges of identifying devices consistently is that different types
of devices use different characteristics and different numbers of characteristics as identifiers. For example, it may be sufficient to use a serial number
only to identify an MRI machine, but identifying a box of screws may require a batch number and a box number. In study-specific datasets this could be
accomplished by using different numbers of identifier variables, but this is not feasible for a general standard. SPDEVID is a mechanism for aggregating
any number of identifiers into one, allowing for a consistent structure for identifying all devices. SPDEVID is a surrogate identifier that represents all
the characteristics of a device in the Study DI domain, but is a simple, short identifier that can appear in each dataset. Having different identifier
variables in different submissions does not help interoperability, and this approach allows for a single identifier while preserving access to the
identifying information needed for the submission. It also facilitates merging datasets.
3. DI was modeled as a Study Reference domain because it has none of the characteristics (except identifiers) of a Findings domain, and is clearly not an
event or intervention. This is separated from the Device Properties (DO) domain because DI contains the total set of characteristics necessary for device
identification, whereas DO contains information important for submission but that are not part of the device identifier.
4. In order to determine the right level of granularity for the parameters defined in DI, it is critical that the sponsor think carefully about how the devices
will need to be tracked (e.g., in Device-In-Use, Device Events) and design SPDEVID to reflect that level of specificity. For example, if surgical screws
only need to be tracked by box and not by individual screw, then the value in SPDEVID might be a box number. If each screw needs to be tracked, then
the parameters would need to include the identifier on each screw.
5. The DI domain must exist if SPDEVID is used in any domain in a study. It is required when any device-specific information is submitted. This includes
information about the device under study as well as parameters captured for devices not under study (e.g., MRI slice thickness, field strength). If none of
this applies (e.g., ECG machine used to generate a tracing, but no information about the machine is needed), then DI is not required.
6. If the DI domain exists, at a minimum it must contain a record with DEVTYPE populated.
7. SPDEVID should not change during a specific device’s lifetime.
8. DISEQ must be unique within each value of DIPARMCD within a SPDEVID. If there is only 1 value of DIPARMCD per device, then DISEQ will
always be 1.
9. The DI domain was designed to be able to handle situations where SPDEVID is needed to identify individual devices. In some situations, such as
studies in which a device is not the product under study and is used only to conduct assessments, SPDEVID may need only to identify a kind of device.
For example, an oncology trial might need to identify the kind of device used to image a tumor, in which case SPDEVID might be used to distinguish
MRI, CT, and X-Ray devices. In such cases, the minimum requirement for a SPDEVID for a kind of device is DEVTYPE (DIPARMCD=DEVTYPE).
Sponsors should define the appropriate level of granularity for unique identification; in some cases it may be a serial number, whereas in others it may
be a box, lot, or batch number, or some combination of these or other identifiers.
10. The DI domain is often referred to as the Study DI domain to help distinguish it from the FDA’s Unique Device Identifier (UDI).
11. This domain should not be used for device characteristics other than identifiers. Any additional non-identifier attributes that the sponsor needs to submit
should be placed in DO instead.
12. This structure allows for the association between one SPDEVID and as many identifiers as a sponsor feels necessary to support all the submitted data.
This easily transforms into a one-record-per-SPDEVID structure for potential merging with other device-related datasets that would contain the
SPDEVID variable, as shown in these samples for a set of Study DI records for a single device.

Page 14 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
 DI data arranged vertically (normalized) showing correspondence between identifiers and SPDEVID (Study Data Tabulation Model, SDTM,
structure):

STUDYID DOMAIN SPDEVID DISEQ DIPARMCD DIPARM DIVAL

DEVM-0004-0003 DI ABC001 1 DEVTYPE Device Type STENT
DEVM-0004-0003 DI ABC001 2 MANUF Manufacturer Acme Stents
DEVM-0004-0003 DI ABC001 3 MODEL Model 45-JFI
DEVM-0004-0003 DI ABC001 4 BATCH Batch identifier 2011-1307
DEVM-0004-0003 DI ABC001 5 LOT Lot Identifier 45678
DEVM-0004-0003 DI ABC001 6 SERIAL Serial Number 456789132-AXQ
DEVM-0004-0003 DI ABC001 7 Y Manufacturer Y-code 32110
DEVM-0004-0003 DI ABC001 8 Z Manufacturer Z-code 6A-55

DI data arranged horizontally (non-normalized) showing identifiers and SPDEVID on a single record (non-SDTM structure):

SPDEVID DEVTYPE MANUF MODEL BATCH LOT SERIAL IDENTIFIER Y IDENTIFIER Z

ABC001 STENT Acme Stents 45-JFI 2011-1307 45678 456789132-AXQ 32110 6A-55

13. The data in this domain may be derived (manually or electronically), captured on DI case report forms (CRFs), or a combination of these.
14. No date variables have been included in this domain because the characteristics defined in Study DI should not change over the course of the trial and
because temporal associations will generally be captured in other domains, for example, Device Exposure (DX) or Device Tracking and Disposition
(DT).
15. No additional variables can be added to this dataset.
16. DIPARMCD values are limited to 8 characters and cannot begin with a number or underscore, as they can be used as variable names when the dataset is
transposed to a non-normalized structure.
17. If FDAUDI is used, it is intended to hold the FDA’s UDI assigned after device approval. For post-approval studies, SPDEVID could be the FDAUDI
value only. If the device is pre-approval, this variable would be null.
18. If the FDAUDI can be populated, the DEVTYPE should still be included. Sponsors may include additional parameters as needed.
19. An incomplete list of DIPARMCD and DIPARM values is shown in the following table.

DIPARMCD DIPARM
FDAUDI FDA Unique Device Identifier
DEVTYPE Device Type
MANUF Manufacturer
MODEL Model
BATCH Batch identifier
LOT Lot Identifier
SERIAL Serial Number

20. Generally, the SPDEVID should include the set of parameters necessary for identifying the device uniquely, and would also have all of the higher level
parameters. For example, if Serial Number were sufficient to identify the device, generally Model and Manufacturer and Device Type would be
included (if available or relevant). Figure 4.1.1 shows the usual relationships among identifier parameters. In the smallest shapes, Lot, Batch, and Serial

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 15
December 12, 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

Number are usually considered to be on the same level. The FDAUDI is effectively a surrogate key for the rest of the identifiers, so the combination of
FDAUDI and DEVTYPE could be sufficient to identify each device for a post-marketing study. Alternatively, if information embedded in the FDAUDI
is needed for data aggregation, analysis, or appropriate interpretation of the data, other identifier variables can also be extracted from FDAUDI and
included.

Figure 3.1.1.1

Graphic showing common relationships between identifier parameters for devices.

3.1.2 Examples for the Device Identifiers Domain Model

Example 1
This example shows records for 2 devices where the sponsor felt that the type, manufacturer, model number, and serial number were necessary for unique
identification. In addition, there was a post-marketing UDI identifier available for the first device.

Rows 1-5: Show the records for a device given a SPDEVID of ABC001
Rows 5-8: Show the records for a device given a SPDEVID of ABC999

Row STUDYID DOMAIN SPDEVID DISEQ DIPARMCD DIPARM DIVAL

1 2011-001 DI ABC001 1 DEVTYPE Device Type MRI
2 2011-001 DI ABC001 2 MANUF Manufacturer Acme Imaging
3 2011-001 DI ABC001 3 MODEL Model Number 45-JFI
4 2011-001 DI ABC001 4 SERIAL Serial Number 456789132-AXQ
5 2011-001 DI ABC001 5 FDAUDI FDA Unique Device Identifier 456789123xyz
6 2015-001 DI ABC999 1 DEVTYPE Device Type MRI
7 2015-001 DI ABC999 2 MANUF Manufacturer Acme Imaging
8 2015-001 DI ABC999 3 MODEL Model Number 62-PLC
9 2015-001 DI ABC999 4 SERIAL Serial Number 215964564-NFS

Page 16 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
Example 2
This example shows a case where a single device was used for all subjects at a given site. The device under study is an extracorporeal shock wave treatment
(ESWT) for treatment of plantar fasciitis, and a single machine is used at each site. All devices in the study would be included in this table and therefore multiple
devices are listed. Because SITEID is not a part of identifying each device, this table does not include SITEID and therefore does not record what device went to
what site/device. The model and serial numbers are necessary to identify each device, and the device will be assigned to each subject via the Device-Subject
Relationships domain (DR).

Row STUDYID DOMAIN SPDEVID DISEQ DIPARMCD DIPARM DIVAL

1 ABCXYZ DI XYZ001 1 DEVTYPE Device Type ESWT
2 ABCXYZ DI XYZ001 2 MODEL Model UR4000
3 ABCXYZ DI XYZ001 3 SERIAL Serial Number 47821B
4 ABCXYZ DI QRS002 1 DEVTYPE Device Type ESWT
5 ABCXYZ DI QRS002 2 MODEL Model UR4000
6 ABCXYZ DI QRS002 3 SERIAL Serial Number 87232A

Example 3
This example shows records for a device for which it was important to collect the type and manufacturer, but no more granular information was needed.

Row STUDYID DOMAIN SPDEVID DISEQ DIPARMCD DIPARM DIVAL

1 2011-537 DI ABC003 1 DEVTYPE Device Type Cardiac Stent
2 2011-537 DI ABC003 2 MANUF Manufacturer Stents, Ltd.

Example 4
This example shows records for a study where 2 devices were used for treatment: a thrombectomy device, which was identified using the type, model and serial
number; and a stent, which was identified using only the type and a serial number.

Row STUDYID DOMAIN SPDEVID DISEQ DIPARMCD DIPARM DIVAL

1 ABCXYZ DI XYZ001 1 DEVTYPE Device Type Thrombectomy Device
2 ABCXYZ DI XYZ001 2 MODEL Model TR300
3 ABCXYZ DI XYZ001 3 SERIAL Serial Number 452209BB
4 ABCXYZ DI QRS002 1 DEVTYPE Device Type Coronary Stent
5 ABCXYZ DI QRS002 2 SERIAL Serial Number 87232A

Example 5
This example shows records for a device used in a study solely for obtaining measurements, and the device is not under study. The only record required is a
DEVTYPE record.

Row STUDYID DOMAIN SPDEVID DISEQ DIPARMCD DIPARM DIVAL

1 2011-537 DI ABC003 1 DEVTYPE Device Type MRI

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 17
December 12, 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

3.2 Device-In-Use (DU)

du.xpt, Device-In-Use - Findings, Version 1.1. One record per property or setting per time point per visit or test date per subject, Tabulation
Controlled Terms,
Variable
Variable Label Type Code List, or Role CDISC Notes Core
Name
Formata,b
STUDYID Study Identifier Char Identifier Unique identifier for a study. Req
DOMAIN Domain Char DU Identifier Two-character abbreviation for the domain. Req
Abbreviation
USUBJID Unique Subject Char Identifier Identifier used to uniquely identify a subject across all studies for all Exp
Identifier applications or submissions involving the product.
Expected in this domain as devices may have settings or uses that either may
not involve subjects (e.g., diagnostic tools) or devices that are removed from
the study prior to contact with a subject (e.g., device has malfunction).
SPDEVID Sponsor Device Char Identifier Sponsor-defined identifier for the device. Exp
Identifier It must be unique for each tracked unit of the device under study, and can be
at whatever level of granularity the device should be identified (e.g., model
or serial number, or combination of identifiers).
DUSEQ Sequence Number Num Identifier Sequence Number given to ensure uniqueness of device records within Req
subject records within a domain.
May be any valid number. It should be unique within every subject/device
combination.
DUGRPID Group ID Char Identifier Identifier for a group or block of related records. Perm
Used to tie together a block of related records in a single domain for a subject
or a group of subject related records (e.g., group records specifying all the
settings for a specific imaging scan, such as field strength, repetition time and
echo time).
DUREFID Reference ID Char Identifier Internal or external identifier. Perm
This could be a scan code or equivalent.
DUSPID Sponsor-Defined Char Identifier Sponsor-defined reference number. Perm
Identifier Perhaps pre-printed on the CRF as an explicit line identifier or defined in the
sponsor's operational database.
DUTESTCD Device-In-Use Char (DUTESTCD) Topic Short name of the measurement, test, or examination described in DUTEST. Req
Test Short Name It can be used as a column name when converting a dataset from a vertical to
a horizontal format. The value in DUTESTCD cannot be longer than 8
characters, nor can it start with a number (e.g., "1TEST"). DUTESTCD
cannot contain characters other than letters, numbers, or underscores.
Examples: "COILSTR", "CNTMEDIA".

Page 18 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
 Controlled Terms,
Variable
Variable Label Type Code List, or Role CDISC Notes Core
Name
Formata,b
DUTEST Device-In-Use Char (DUTEST) Synonym Verbatim name of the test or examination used to obtain the measurement or Req
Test Name Qualifier finding.
The value in DUTEST cannot be longer than 40 characters. Examples: "Coil
Strength", "Contrast Media".
DUCAT Category for Char * Grouping Defines a category of related records. Perm
Device-In-Use Qualifier It can be used to define the type of device for which settings are recorded if
DI is not used (e.g., if the device is not under study); may also be used to
record the type of setting (e.g., "HARDWARE" vs. "SOFTWARE").
DUSCAT Subcategory for Char * Grouping A further categorization of a measurement or examination. Perm
Device-In-Use Qualifier For example, if DUCAT = "SOFTWARE", DUSCAT might be
"NOMINAL" or "POST-ADJUSTMENT".
DUORRES Result or Finding Char Result Result of the measurement as originally received or collected. Exp
in Original Units Qualifier DUORRES should contain the setting or other device condition in effect at
the time the device was used.
DUORRESU Original Units Char (UNIT) Variable Original units in which the data were collected. Exp
Qualifier The unit for DUORRES. Examples: Tesla, mm.
DUSTRESC Result or Finding Char Result Contains the result value for all findings, copied or derived from DUORRES Exp
in Standard Format Qualifier in a standard format or standard units.
DUSTRESC should store all results or findings in character format; if results
are numeric, they should also be stored in numeric format in DUSTRESN.
For example, if a test has results "NONE," "NEG," and "NEGATIVE" in
DUORRES, and these results effectively have the same meaning, they could
be represented in standard format in DUSTRESC as "NEGATIVE".
DUSTRESN Numeric Num Result Used for continuous or numeric results or findings in standard format. Exp
Result/Finding in Qualifier Copied in numeric format from DUSTRESC. DUSTRESN should store all
Standard Units numeric test results or findings.
DUSTRESU Standard Units Char (UNIT) Variable Standardized unit used for DUSTRESC and DUSTRESN. Exp
Qualifier The unit for standardized results may or may not be the same as for the
original results.
VISITNUM Visit Number Num Timing A clinical encounter number. Exp
A Numeric version of VISIT, used for sorting.
VISIT Visit Name Char Timing Protocol-defined description of clinical encounter. Perm
May be used in addition to VISITNUM and/or VISITDY.
VISITDY Planned Study Day Num Timing Planned study day of the visit based upon RFSTDTC in Demographics. Perm
of Visit This value is usually derived.

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 19
December 12, 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

Controlled Terms,
Variable
Variable Label Type Code List, or Role CDISC Notes Core
Name
Formata,b
DUDTC Date/Time Device Char ISO 8601 Timing Date/time that the device was used with this setting. Exp
Used with Test/ This is not the date/time that the setting was set on the device, but rather that
Setting date/time that a measurement or test was done using that setting.
DUDY Study Day of Num Timing Study day of Device-In-Use measurement, measured as integer days. Perm
Observation Algorithm for calculations must be relative to the sponsor-defined RFSTDTC
variable in Demographics.
aAsterisk indicates variable may be subject to controlled terminology.
bParentheses indicates CDISC/NCI code list code value.

3.2.1 Assumptions for the Device-In-Use Domain Model

1. Definition: The Device In-Use (DU) domain represents properties of the study device or ancillary device that are intentionally set when the device is
used in the context of a study.
2. An “ancillary device” is a device used within a clinical trial to collect subject data/information (device or human subject), but that is not the target of the
study (e.g., an MRI or CT machine whose settings must be recorded in a clinical trial studying heart failure, as required in the protocol). If settings for
an ancillary device in a study need to be recorded and the device needs to be identified in the data, DI must be used for that identification.
3. Unlike Device Properties (DO), which describes device characteristics that do not change for the device during the trial, the DU domain captures
characteristics and properties of a device that can vary from subject to subject or usage to usage over the course of a study. For example,
a. The full range of field strengths for a given MRI machine might be 0.5 to 3 Tesla, and these values would be captured in DO. DU would record
the specific settings used for a given subject (e.g., the field strength for the MRI scan for Subject 123 was 0.5 T for Visit 1).
b. The software for a pacemaker may start at Version 1, and be updated to Version 2 during the study. This change can be captured here. It would
not go in DO, as DO holds only characteristics that do not change during the study.
4. There are two primary identifiers in this domain: USUBJID and SPDEVID. Both are Expected. Either one or the other or both must be used. For
example, a device under study will always have a SPDEVID, but may or may not have a USUBJID. An ancillary device (one not under study) for which
in-use data are required may have a USUBJID but may or may not have SPDEVID. In all cases where SPDEVID is used, it must be defined in the
Device Identifiers (DI) domain.
5. There are cases where settings on devices used in studies might be reported in Device Exposure (DX) or DU, such as when the settings are changed to
affect an efficacy response. Sponsors should confer with the appropriate regulatory authorities to determine where to submit this information
6. This domain is not intended to capture manufacturer-set (i.e., nominal) settings, but rather the customized settings for a given usage.
7. Because any number of device settings (e.g., coil strength, placement of leads) can be reported in this domain, each setting is represented by a separate
row and is defined in the topic variable DUTESTCD. The original result goes into DUORRES.
8. DUREFID is the identifier for a unique scan or other test result to link a group of settings (e.g., field strength or slice thickness in an MRI scan) to the
results obtained from the reading or interpretation of the test (e.g., the MRI image).
9. The DUSPID variable can be used to link this domain to other domains if necessary, such as Adverse Events (AE), Exposure, and/or Device Events.
10. Note that in some of the examples that follow, variables that would be blank may have been dropped to conserve space. This does not mean that the
variables cannot be used in the illustrated use case, merely that in the specific example they were not populated.

Page 20 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
 11. The following Qualifiers would not generally be used in DU: --MODIFY, --BODSYS, --POS,--ORNRLO, --ORNRHI, --STNRLO, --STNRHI, --
STNRC, --NRIND, --RESCAT, --REASND, --XFN, --NAM, --LOINC, --SPEC, --SPCCND, --LOC, --METHOD, --FAST, --DRVFL, --EVAL, --TOX,
--TOXGR, --SEV, --DTHREL, --LLOQ.

3.2.2 Examples for the Device-In-Use Domain Model

Example 1
This example shows data from 1 subject collected at 2 visits about parameters from an MRI imaging protocol. In this case, the image was used to obtain brain
volume measurements, and the results of the image interpretation are reported in the Neurological domain. The parameters in DU can be linked to the
measurement results using RELREC; see Section 4 Example 1. DUSPID is the same for each timepoint, as the device settings were collected on a single record
for each image taken.

Rows 1-7: Represent 7 example DU records collected at the screening visit for a given subject.
Rows 8-14: Represent 7 example DU records collected at the first treatment visit for the same subject.

Row STUDYID DOMAIN USUBJID SPDEVID DUSEQ DUGRPID DUREFID DUSPID DUTESTCD DUTEST DUORRES
1 STUDYX DU 2324-P0001 ABC174 1 DUNV1 222333-444555 1 COILSTR Coil Strength 1.5
2 STUDYX DU 2324-P0001 ABC174 2 DUNV1 222333-444555 1 ANTPLANE Anatomical Plane CORONAL
3 STUDYX DU 2324-P0001 ABC174 3 DUNV1 222333-444555 1 STHICK Slice Thickness 1
4 STUDYX DU 2324-P0001 ABC174 4 DUNV1 222333-444555 1 MATRIX Matrix 256X256
5 STUDYX DU 2324-P0001 ABC174 5 DUNV1 222333-444555 1 SFTWRVER Software Version 15.0
6 STUDYX DU 2324-P0001 ABC174 6 DUNV1 222333-444555 1 FLDVIEW Field of View 24
7 STUDYX DU 2324-P0001 ABC174 7 DUNV1 222333-444555 1 RCBDWTH Receiver Bandwidth 16
8 STUDYX DU 2324-P0001 ABC174 8 DUNV2 444555-666777 2 COILSTR Coil Strength 1.0
9 STUDYX DU 2324-P0001 ABC174 9 DUNV2 444555-666777 2 ANTPLANE Anatomical Plane CORONAL
10 STUDYX DU 2324-P0001 ABC174 10 DUNV2 444555-666777 2 STHICK Slice Thickness 2
11 STUDYX DU 2324-P0001 ABC174 11 DUNV2 444555-666777 2 MATRIX Matrix 256X256
12 STUDYX DU 2324-P0001 ABC174 12 DUNV2 444555-666777 2 SFTWRVER Software Version 15.1
13 STUDYX DU 2324-P0001 ABC174 13 DUNV2 444555-666777 2 FLDVIEW Field of View 25
14 STUDYX DU 2324-P0001 ABC174 14 DUNV2 444555-666777 2 RCBDWTH Receiver Bandwidth 16

Row DUORRESU DUSTRESC DUSTRESN DUSTRESU VISITNUM VISIT VISITDY DUDTC DUDY
1 (cont) T 1.5 1.5 T 1 SCREENING -7 2011-04-19 -7
2 (cont) CORONAL 1 SCREENING -7 2011-04-19 -7
3 (cont) mm 1 1 mm 1 SCREENING -7 2011-04-19 -7
4 (cont) 256X256 1 SCREENING -7 2011-04-19 -7
5 (cont) 15.0 15.0 1 SCREENING -7 2011-04-19 -7
6 (cont) cm 24 24 cm 1 SCREENING -7 2011-04-19 -7
7 (cont) kHz 16 16 kHz 1 SCREENING -7 2011-04-19 -7
8 (cont) T 1.0 1.0 T 2 IMPLANTATION 1 2011-04-26 1
9 (cont) CORONAL 2 IMPLANTATION 1 2011-04-26 1
10 (cont) mm 2 2 mm 2 IMPLANTATION 1 2011-04-26 1

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 21
December 12, 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

Row DUORRESU DUSTRESC DUSTRESN DUSTRESU VISITNUM VISIT VISITDY DUDTC DUDY
11 (cont) 256X256 2 IMPLANTATION 1 2011-04-26 1
12 (cont) 15.1 15.1 2 IMPLANTATION 1 2011-04-26 1
13 (cont) cm 25 25 cm 2 IMPLANTATION 1 2011-04-26 1
14 (cont) kHz 16 16 kHz 2 IMPLANTATION 1 2011-04-26 1

Example 2
This example shows a software update applied to a pacemaker during the study.

Row 1: Represents an example DU record collected at the screening visit; records the software version in use.
Row 2: Represents an update to the software for the same device in the same subject from Version 3.0 to Version 3.02.

Row STUDYID DOMAIN USUBJID SPDEVID DUSEQ DUGRPID DUREFID DUTESTCD DUTEST DUORRES DUORRESU
1 QL1059 DU 1059-001 BOEN37P 1 DUNV1 222333-444555 SFTWRVER Software Version 3.0
2 QL1059 DU 1059-001 BOEN37P 1 DUNV1 222333-444555 SFTWRVER Software Version 3.02

Row DUSTRESC DUSTRESN DUSTRESU VISITNUM VISIT VISITDY DUDTC DUDY

1 (cont) 3.0 3.0 1 SCREENING -7 2011-04-19 -7
2 (cont) 3.02 3.02 5 VISIT 4 21 2011-05-16 21

Page 22 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
3.3 Device Exposure (DX)
dx.xpt, Device Exposure - Interventions, Version 1.1. One record per recorded intervention occurrence or constant treatment interval per subject,
Tabulation
Controlled Terms,
Variable
Variable Label Data Code List, or Role CDISC Notes Core
Name
Formata,b
STUDYID Study Identifier Char Identifier Unique identifier for a study. Req
DOMAIN Domain Abbreviation Char DX Identifier Two-character abbreviation for the domain. Req
USUBJID Unique Subject Char Identifier Identifier used to uniquely identify a subject across all studies for all Req
Identifier applications or submissions involving the product.
SPDEVID Sponsor Device Char Identifier Sponsor-defined identifier for the device. Req
Identifier It must be unique for each tracked unit of the device under study, and can
be at whatever level of granularity the device should be identified (e.g.,
model or serial number, or combination of identifiers).
DXSEQ Sequence Number Num Identifier Sequence Number given to ensure uniqueness of device records within Req
subject records within a domain.
May be any valid number. It should be unique within every
subject/device combination.
DXGRPID Group ID Char Identifier Identifier that ties together a block of related records in a single domain Perm
for a subject.
For example, if a device is inserted that delivers radiation, DXGRPID
could be used to tie the records for the device and the radiation together
for each course of therapy.
DXSPID Sponsor-Defined Char Identifier Sponsor-defined reference number. Perm
Identifier Examples: a number pre-printed on the CRF as an explicit line identifier
or record identifier defined in the sponsor's operational database.
DXTRT Name of Device Char Topic Name of the device or the exposure outputs that are delivered or Req
Exposure or Output administered via the device. This should match the definitions as
described in the trial summary domain and/or the protocol.
Example: "coronary stent", "extracorporeal shock wave treatment",
"hyaluronic acid".
DXCAT Category for Device Char * Grouping Used to define a category of device exposures. Perm
Exposure Qualifier For example, for a subject who had radiation delivered through an
implanted catheter, DXCAT could be used to group the radiation records
versus the catheter records.
DXSCAT Subcategory for Char * Grouping A further categorization of device exposures. Perm
Device Exposure Qualifier If DXCAT captures the radiation versus catheter records (see DXCAT),
then DXSCAT might capture the type of catheter if more than one was
used.

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 23
December 12, 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

Controlled Terms,
Variable
Variable Label Data Code List, or Role CDISC Notes Core
Name
Formata,b
DXDOSE Exposure per Num Record Amount of DXTRT administered/delivered per administration. Perm
Administration Qualifier Dose if captured as a numeric value. Dose should only appear once in
DXDOSE, DXDOSTXT, or DXDOSTOT.
DXDOSTXT Device Exposure Char Record Exposure amount or a range of exposure information collected in text Perm
Description Qualifier form.
Units may be stored in DXDOSU. Example: 200-400, 15-20. Dose
should only appear once in DXDOSE, DXDOSTXT, or DXDOSTOT.
DXDOSU Device Exposure Char (UNIT) Variable Units for DXDOSE, DXDOSTXT, and DXDOSTOT. Perm
Units Qualifier Examples: "pulses", "ml".
DXDOSFRQ Device Exposure Char (FREQ) Variable Exposure frequency per interval. Perm
Frequency per Qualifier Usually expressed as the number of repeated administrations of
Interval DXDOSE within a specific time period. Examples: "CONTINUOUS",
"PRN", "Q2M" (every 2 months).
DXDOSTOT Total Daily Device Num Record Total daily exposure of DXTRT using the units in DXDOSU. Perm
Exposure Qualifier Total exposure over a period other than day could be recorded in a
separate Supplemental Qualifier variable.
DXDOSRGM Intended Device Char Variable Text description of the (intended) schedule or regimen for the Perm
Exposure Regimen Qualifier Intervention.
Examples: "TWO WEEKS ON, TWO WEEKS OFF".
DXROUTE Route of Char (ROUTE) Variable Route of administration for DXTRT. Perm
Administration Qualifier Examples: "EXTRACORPOREAL", "INTRA-ARTICULAR,
HEMODIALYSIS".
DXLOC Location of Device Char Record Anatomic location of exposure. Perm
Exposure Qualifier Examples: "Knee", "Eye".
DXLAT Laterality of Device Char Variable Qualifier for anatomical location further detailing laterality. Perm
Exposure Qualifier Examples: "RIGHT", "LEFT", "BILATERAL".
DXADJ Reason for Exposure Char Record Describes reason why the exposure was adjusted from protocol-specified Perm
Adjustment Qualifier or expected exposure levels.
Example: "PAIN".
DXSTDTC Start Date/Time of Char ISO 8601 Timing Start date and time of exposure. Exp
Device Exposure Defined by the sponsor.
DXENDTC End Date/Time of Char ISO 8601 Timing End date and time of exposure. Perm
Device Exposure Defined by the sponsor.
DXSTDY Study Day of Start of Num Timing Study day of start of exposure relative to the sponsor-defined RFSTDTC. Perm
Device Exposure
DXENDY Study Day of End of Num Timing Study day of end of exposure relative to the sponsor-defined RFSTDTC. Perm
Device Exposure

Page 24 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
 Controlled Terms,
Variable
Variable Label Data Code List, or Role CDISC Notes Core
Name
Formata,b
DXDUR Duration of Device Char ISO 8601 Timing Collected duration for a treatment episode. Perm
Exposure Used only if collected on the CRF and not derived from start and end
date/times.
aAsterisk indicates variable may be subject to controlled terminology.
bParentheses indicates CDISC/NCI code list code value.

3.3.1 Assumptions for the Device Exposure Domain Model

1. Definition: The Device Exposure (DX) domain records the details of a subject’s direct interaction or contact with a medical device or the output from a
medical device, usually but not always the device under study. This device may be used by the subject, on the subject, or implanted into the subject.
Examples include but are not limited to stents, drug delivery systems, and any other item under study that is defined as a device in the applicable
regulations.
2. The DX data may be captured on a CRF, downloaded from a device, or derived. The appropriate method is determined by the sponsor.
3. The structure of the DX domain is 1 record per exposure intervention episode or constant-exposure interval per subject. It is the sponsor's responsibility
to define an intervention episode. This definition may vary based on the sponsor's requirements for review and analysis. The submission dataset
structure may differ from the structure used for collection. One common approach is to submit a new record when there is a change in the exposure
regimen. Another approach is to collapse all records for an exposure to a summary level with exposure range. Other approaches may also be reasonable
as long as they meet the sponsor's evaluation requirements.
4. A DX domain is expected whenever there is individual subject exposure to a device under study. Device studies in which only pooled samples are used
(e.g., some diagnostic devices) may not require a DX domain. In these cases, a subject’s sample is part of a pooled sample, and the subject is never in
contact with the device, therefore there is no exposure to report. Note that contact can be directly between subject and device, or between subject and a
device output.
5. In cases where a device-drug combination is being studied, the device exposure data would generally be submitted in DX and the drug exposure data
would generally be submitted in EX, but each sponsor should confer with the appropriate regulatory authorities to determine the appropriate datasets.
6. There are cases where settings on devices used in studies might be reported in DX or Device In-Use (DU), such as when the settings are changed to
affect an efficacy response. Sponsors should confer with the appropriate regulatory authorities to determine where to submit this information.
7. Categorization and Grouping: DXCAT and DXSCAT may be used when appropriate to categorize treatments into categories and subcategories. For
example, if a study uses several different devices, DXCAT may be set to “ACTIVE COMPARATOR.” Such categorization may not be useful in most
studies, so these variables are permissible and not expected.
8. Device Exposure Treatment Description: DXTRT captures the name of the investigational medical device and is the topic variable. It is a required
variable and must have a value. DXTRT should avoid unnecessarily repeating characteristics found in the Device Properties (DO) domain.
9. Timing Variables: The timing of exposure to the study device is captured by the start/end date and start/end time of each intervention episode or
constant exposure interval, as defined by the sponsor.
10. Additional Interventions Qualifiers: Other additional Qualifiers from the SDTM Interventions Class may be added to this domain.
11. Note that in some of the examples that follow, variables that would be blank may have been dropped to conserve space. This does not mean that the
variables cannot be used in the illustrated use case, merely that in the particular example they were not populated.
12. The DXSPID variable can be used to link the DX domain to other domains if necessary, such as AEs, Exposure, and/or Device Events.

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 25
December 12, 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

3.3.2 Examples for the Device Exposure Domain Model

Example 1
In this example, the study is investigating the safety and efficacy of the device ‘Hyaluronic Acid’ given into the intra-articular space of the knee joint to relieve
the pain associated with osteoarthritis through lubrication. The product is administered once a week for three weeks. Hyaluronic acid provides physical
lubrication in the joint, and is considered to be a device by the manufacturer and the regulators, even though it has many of the characteristics of a drug.

Row STUDYID DOMAIN USUBJID SPDEVID DXSEQ DXSPID DXTRT DXDOSE DXDOSU
1 ABCXYZ DX 001-001 LOTABC 1 1 HYALURONIC ACID 2 mL
2 ABCXYZ DX 001-001 LOTABC 2 2 HYALURONIC ACID 2 mL
3 ABCXYZ DX 001-001 LOTXYZ 1 3 HYALURONIC ACID 2 mL

Row DXDOSFRQ DXDOSRGM DXROUTE DXLOC DXSTDTC DXENDTC DXSTDY DXENDY DXDUR
1 (cont) ONCE 1X/WK FOR 3 WEEKS INTRA-ARTICULAR LEFT KNEE 2010-05-02T12:15 2010-05-02T12:17 1 1
2 (cont) ONCE 1X/WK FOR 3 WEEKS INTRA-ARTICULAR LEFT KNEE 2010-05-09T13:15 2010-05-09T13:17 8 8
3 (cont) ONCE 1X/WK FOR 3 WEEKS INTRA-ARTICULAR LEFT KNEE 2010-05-13T13:15 2010-05-13T13:17 12 12

Example 2
In this example, a device that delivers shock wave pulses is used to treat plantar fasciitis (inflammation of the plantar fascia in the heel). The study is
investigating the safety and efficacy of this single device treatment that has is used in two orientations within the heel receiving pulses (in-line, and 45 deg medial
to plantar). The orientation information is captured in Device in Use (DU). This example shows a patient that had an aborted treatment due to an adverse event.

Row STUDYID DOMAIN USUBJID SPDEVID DXSEQ DXSPID DXTRT DXDOSE DXDOSTXT DXDOSFRQ DXDOSTOT DXDOSU
EXTRACORPOREAL
1 ABCXYZ DX 001-001 SERAZZ3 1 1 SHOCK WAVE 500 ONCE PULSES
TREATMENT
EXTRACORPOREAL
2 ABCXYZ DX 001-001 SERAZZ3 2 2 SHOCK WAVE 400 ONCE PULSES
TREATMENT

Row DXDOSRGM DXROUTE DXLOC DXADJ DXSTDTC DXENDTC DXSTDY DXENDY DXDUR
1 (cont) 500 pulses/treatment session Extracorporeal Right Plantar Fascia 2010-05-02T12:15 2010-05-02T12:30 1 1
2 (cont) 500 pulses/treatment session Extracorporeal Right Plantar Fascia Adverse Event 2010-05-03T14:31 2010-05-03T14:45 2 2

Example 3
This study is investigating the functional delivery of the radiation treatment to the breast via a balloon catheter system. The system is inserted into a tumor cavity
post excision. After surgery the catheter is left inside the cavity for 5 days. During the time of implant the radiation is delivered from a HDR device (“seed”)
through the part of the catheter system remaining outside the body twice per day in two separate fractions. In this example there is a recording of the surgical
placement of the catheter system, and the first 4 fraction records. The location of the placement and radiation delivery is coded. In this example, the radiation
information is submitted in DX, but there may be cases where it would more appropriately be recorded in Device In-Use (DU).

Page 26 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
Row STUDYID DOMAIN USUBJID SPDEVID DXSEQ DXSPID DXCAT DXTRT DXDOSE DXDOSFRQ DXDOSU
1 ABCXYZ DX 001-001 SER56XA 1 1 CATH ABC balloon catheter system ONCE
2 ABCXYZ DX 001-001 SER44531 1 2 RAD APBI 3.4 BID Gy
3 ABCXYZ DX 001-001 SER44531 2 3 RAD APBI 3.4 BID Gy
4 ABCXYZ DX 001-001 SER44531 3 4 RAD APBI 3.4 BID Gy
5 ABCXYZ DX 001-001 SER44531 4 5 RAD APBI 3.4 BID Gy

Row DXDOSTOT DXDOSRGM DXROUTE DXLOC DXSTDTC DXENDTC DXSTDY DXENDY DXDUR
1 (cont) ONCE Intradermal LUO 2010-05-02T12:15 2010-05-010T13:30 1 9
2 (cont) 5 DAYS Intradermal LUO 2010-05-03T08:31 2010-05-03T08:45 2 2
3 (cont) 5 DAYS Intradermal LUO 2010-05-03T15:31 2010-05-03T15:45 2 3
4 (cont) 5 DAYS Intradermal LUO 2010-05-04T08:31 2010-05-04T08:45 3 3
5 (cont) 5 DAYS Intradermal LUO 2010-05-04T15:31 2010-05-04T15:45 3 3
Abbreviation: LUO, left upper outer breast.

Example 4
This is an example of a study investigating the safety and efficacy of a cervical disc replacement. In this example there are two separate patients, one who had the
device implanted and evaluated throughout the study (001-001), and the second (002-001) who had the device explanted on Day 7.

Row STUDYID DOMAIN USUBJID SPDEVID DXSEQ DXSPID DXTRT DXDOSE DXDOSTXT DXDOSU DXDOSFRQ
1 ABCXYZ DX 001-001 SER45001 1 1 Artificial Cervical Disc 1 UNIT ONCE
2 ABCXYZ DX 002-001 SER86002 1 1 Artificial Cervical Disc 1 UNIT ONCE

Row DXLOC DXSTDTC DXENDTC DXSTDY DXENDY DXENRTPT DXENTPT

1 (cont) C3-4 2010-05-02T12:15 1 ONGOING CLOSEOUT
2 (cont) C3-4 2010-05-02T13:15 2010-05-09T13:17 1 8

Example 5
This is an example of a study investigating the safety and efficacy of a particular suture material in closing wounds. In this example, the same subject had two
wounds. One was on the left forearm and was sutured using the material under study, while the other was on the right thigh and was sutured using a control.

Row STUDYID DOMAIN USUBJID SPDEVID DXSEQ DXTRT DXDOSE DXDOSTXT DXDOSU
1 P47-923 DX 923-021 STRONG2 1 Strong Suture No 2 15 cm
2 P47-923 DX 923-021 COMP465 1 GenSuture 12 cm

Row DXLOC DXLAT DXSTDTC DXENDTC DXSTDY DXENDY

1 (cont) FOREARM LEFT 2011-12-24T15:25 2001-12-30T09:38 1 7
2 (cont) THIGH RIGHT 2011-12-24T15:45 2001-12-30T09:32 1 7

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 27
December 12, 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

3.4 Device Events (DE)

de.xpt, Device Events - Events, Version 1.1. One record per event per device, Tabulation
Controlled Terms,
Variable Data
Variable Label Code List, or Role CDISC Notes Core
Name Type
Formata,b
STUDYID Study Identifier Char Identifier Unique identifier for a study. Req
DOMAIN Domain Char DE Identifier Two-character abbreviation for the domain. Req
Abbreviation
USUBJID Unique Subject Char Identifier Identifier used to uniquely identify a subject across all studies for all Exp
Identifier applications or submissions involving the product.
Expected rather than required because events may happen to or with a
device that do not involved subjects, and may even be before the device
was in contact with a subject. In these cases there may not be a value for
USUBJID.
SPDEVID Sponsor Device Char Identifier Sponsor-defined identifier for the device. Req
Identifier It must be unique for each tracked unit of the device under study, and can
be at whatever level of granularity the device should be identified (e.g.,
model or serial number, combination of identifiers).
DESEQ Device Events Num Identifier Sequence Number given to ensure uniqueness of device records within Req
Sequence Number subject records within a domain.
May be any valid number. It should be unique within every subject/device
combination. If there is no USUBJID associated with the event, DESEQ
should be unique within each SPDEVID.
DESPID Sponsor-Defined Char Identifier Sponsor-defined reference number. Perm
Identifier Perhaps pre-printed on the CRF as an explicit line identifier or defined in
the sponsor's operational database. Note that it does not have to be numeric.
DETERM Reported Term for Char Topic Verbatim name of the observed event. Req
Device Event Examples: "Screw Breakage", "Fissure Formation", "Battery Issue".
DEMODIFY Modified Device Char Synonym The modified text for DETERM. Perm
Event Name Qualifier If DETERM is modified, then the modified text is placed here.
DEDECOD Device Events Char * Synonym Dictionary-derived form of the event described in DETERM. Req
Dictionary-Derived Qualifier Dictionary-derived text description of DETERM or DEMODIFY. The
Term name and version of the dictionary used to map terms must be provided in a
Define.XML ExternalCodeList element.
DECAT Category of Device Char * Grouping Used to define a categorization level for events. Perm
Event Qualifier For example, "MALFUNCTION" vs. "CALIBRATION".
DESCAT Subcategory of Char * Grouping Used to define a further category level for events. Perm
Device Event Qualifier For example, "EXTERNAL" vs. "INTERNAL".

Page 28 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
 Controlled Terms,
Variable Data
Variable Label Code List, or Role CDISC Notes Core
Name Type
Formata,b
DEPRESP Pre-Specified Char (NY) Record Used to indicate whether (Y/null) information about a specific event was Perm
Device Event Qualifier solicited on the CRF.
For example, DETERM could contain a list of malfunctions that are being
specifically evaluated. DEPRESP would identify those (Y), whereas any
spontaneous events would have DEPREST null.
DEOCCUR Device Event Char (NY) Record When information about specific events is solicited, DEOCCUR is used to Perm
Occurrence Qualifier indicate whether or not (Y/N) a particular pre-specified event occurred.
Values are null for events not specifically solicited.
DESTAT Device Event Char (ND) Record The status indicates that the pre-specified question was not answered. Perm
Collection Status Qualifier For example, if equipment operation requires checking, such as checking an
event log to detect events. Capturing that the checks were not completed
may be relevant to interpreting the study data.
DEREASND Reason Device Char Record Reason DESTAT was "NOT DONE". Perm
Event Not Collected Qualifier This variable should only be used if there are pre-specified events.
DESEV Device Event Char * Record Describes the severity of the event, (e.g., the severity of a malfunction). Perm
Severity Qualifier
DEACNDEV Action Taken with Char * Record Describes Action Taken with respect to the device. Perm
Device Qualifier Action Taken may include removal, calibration, reprogramming, and so on.
Action is usually in response to some event, for example, a subject's
adverse event.
VISITNUM Visit Number Num Timing Clinical encounter number. Exp
Numeric version of VISIT, used for sorting.
VISIT Visit Name Char Timing Protocol-defined description of clinical encounter. Perm
May be used in addition to VISITNUM and/or VISITDY.
VISITDY Planned Study Day Num Timing Planned study day of the visit based upon RFSTDTC in Demographics. Perm
of Visit This value is usually derived.
DEDTC Date of Device Char ISO 8601 Timing Date the device event information was collected. Perm
Event Data This may be reported if the event (e.g., malfunction) is discovered on a
Collection different date from the event.
DESTDTC Start Date/Time of Char ISO 8601 Timing Start date/time of the device event. Perm
Device Event If the event happened at a single point in time, DESTDTC is used.
DEENDTC End Date/Time of Char ISO 8601 Timing End date/time of the device event. Perm
Device Event If an event lasted over a period of time, DEENDTC can be used to capture
the end date/time.
DEDY Study Day of Start Num Timing Study day of Device Event observation, measured as integer days. Perm
of Tracking Event Algorithm for calculations must be relative to the sponsor-defined
RFSTDTC variable in Demographics.

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 29
December 12, 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

Controlled Terms,
Variable Data
Variable Label Code List, or Role CDISC Notes Core
Name Type
Formata,b
DESTDY Study Day of Num Timing Study day of start of Device Event, measured as integer days. Perm
Device Event Start Algorithm for calculations must be relative to the sponsor-defined
RFSTDTC variable in Demographics.
DEENDY Study Day of Num Timing Study day of end of Device Event, measured as integer days. Perm
Device Event End Algorithm for calculations must be relative to the sponsor-defined
RFENDTC variable in Demographics.
aAsterisk indicates variable may be subject to controlled terminology; sponsor will identify the controlled terminology in Define-XML.
bParentheses indicates CDISC/NCI code list code value.

3.4.1 Assumptions for the Device Events Domain Model

1. Definition: The Device Events (DE) domain captures information about a variety of activities that can occur to or with the device, for example,
malfunctions, calibrations, or parts replacement. It is an optional domain, to be used only if the sponsor has events that should be reported. Records are
specific to an individual device. The entries may be related to one or many subjects and visits, depending upon the type of device and scope of its use.
2. USUBJID is Expected in this domain. See CDISC Notes for further explanation.
3. In some cases, a device event may occur but have no effect on a study (e.g., a malfunction occurring if a device is damaged in transit or setup before its
use in a study). It is assumed that these events will be reported elsewhere.
4. Depending upon the type of device, an event such as a malfunction may affect 1 subject (e.g., implantable, disposable, single-use devices) or many
subjects, visits, and findings (e.g., diagnostic, imaging devices). This could require multiple records, one for each event for each associated subject
(USUBJID) or device, as appropriate. In this case, a single DEREFID value would identify multiple records representing the subject-by-subject impact
of the malfunction.
5. There are 2 broad cases in which device events (e.g., malfunctions) may be recorded: (1) the device is under study, or (2) the device is ancillary, that is,
used simply to obtain a finding, but some properties of the device are recorded within the study.
6. If there is a malfunction, Device Exposure (DX) and Device-In-Use (DU) may also be recorded. In some cases, it is possible that only the most general
definition of the device (e.g., X-Ray, CT, and ultrasound) may be identified.
7. If a malfunction or other event results in an adverse event, then that information should be recorded in the AE domain (see SDTM Implementation
Guide, SDTMIG, AE domain). The relationship between the AE and DE can be recorded on the CRF using DESPID and/or DEAENO. DEAENO
would be a data capture (CDASH) variable that is not submitted in SDTM-based datasets, but is used to create a RELREC that links the event records.
8. The present revision of DE assumes that a device event such as a malfunction is associated with one or more subjects and visits, and at most one AE per
subject. More complex cases are deferred to future revisions.
9. DEENDTC can be used, for example, if a malfunction occurs during a deployment and it is repaired.
10. If this domain is used to capture device malfunctions, and the FDA’s Device Problem Code (part of FDA’s MDR Reporting) controlled terminology list
is used, then any codes beyond the Preferred Term can be included as Supplemental Qualifiers. See SDTMIG Appendix C2 and SDTMIG v3.2 section
8.4 for information about including hierarchies of terms.
11. Note that in some of the examples that follow, variables that would be blank may have been dropped to conserve space. This does not mean that the
variables cannot be used in the illustrated use case, merely that in the particular example they were not populated.
12. The following Qualifiers would not generally be used in DE: --BODSYS, --SER,--ACN, --REL, --RELNST, --PATT, --OUT, --SCAN, --SCONG, --
SDISAB, --SDTH, --SHOSP, --SLIFE, --SOD, --SMIE, --CONTRT, --TOX, -TOXGR.

Page 30 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
3.4.2 Examples for the Device Events Domain Model
Example 1
In this example, 2 units of the device have suffered a series of failures. Each failure is recorded separately.

Row STUDYID DOMAIN USUBJID SPDEVID DESEQ DETERM DEDECOD DECAT DESEV DEDTC DESTDTC
2009-11-
1 ABCXYZ DE 1001 1001001 1 Minor screw breakage Screw breakage Equipment Failure Minor 2009-11-01
02
2009-12-
2 ABCXYZ DE 1001 1001001 2 Shallow fissure formation Fissure Equipment Failure Minor 2009-12-13
15
Battery charge 2009-10-
3 ABCXYZ DE 1002 999981 1 Battery will not charge Equipment Failure Major 2009-10-10
failure 13
Firmware Consistency Fail Firmware failure Software 2010-01-
4 ABCXYZ DE 1002 999981 2 Major 2010-01-03
103 103 Malfunction 03

Example 2
Row 1: Shows a malfunction of an MRI calibration affecting 1 subject. In this case the individual MRI unit is not under study (e.g., when the MRI is used
to obtain study measurements), and the sponsor decided to use the site number in SPDEVID.
Row 2: Shows a malfunction of the device under study where all subjects for the day were affected. If this single record is sufficient detail for the
sponsor’s requirements, then no further records would be added; if there were a need to associate the malfunction with each subject (e.g., it led to
several AEs), then a record could be added for each affected subject. USUBJID is null because this device malfunction was not specific to one
subject.
Row 3: Shows a malfunction for a specific device under study and the associated subject.

Row STUDYID DOMAIN USUBJID SPDEVID DESEQ DETERM DEDECOD DECAT DESEV DEDTC DESTDTC
1 ABC-123 DE 2022 Site 22 1 First calibration failed Calibration failed Calibration Failure Minor 2010-01-01 2009-12-28
2 ABC-456 DE 15033 1 Data Loss Data failure Data Storage Failure Major 2009-01-06 2009-01-05
3 ABC-789 DE 2222 334-XRS-09 1 Alignment Failure Calibration failed Calibration Failure Major 2009-01-05 2009-01-05

Example 3
This example shows how failures for implanted devices could be modeled.

Row STUDYID DOMAIN USUBJID SPDEVID DESEQ DETERM DEDECOD DECAT DESEV DEDTC DESTDTC
Equipment 2010-01-
1 ABCXYZ DE 2022 X1010785 1 Calibration Failed Calibration failed Medium 2009-12-28
Failure 01
Internal communication Communications Equipment 2009-01-
2 ABCXYZ DE 2133 15033 1 Medium 2009-01-05
failure failure Failure 05
334-XRS- Internal communication Communications Equipment 2009-01-
3 ABCXYZ DE 2133 2 Medium 2009-01-05
09 failure failure Failure 05

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 31
December 12, 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

Example 4
Row 1: Shows maintenance and calibration checks associated with a QA schedule of an MRI calibration where all subjects after the event were affected.
The DEDTC variable captures when the information was recorded and/or discovered. DESTDTC records when the event happened. In this case, a
software update occurred, and a maintenance event recorded some issue, which was only found subsequently on 6Jan2009. This allows sponsors to
determine if anything of importance happened during that interval (e.g., if any subjects were exposed to the device). If this single record is
sufficient detail for the sponsor’s requirements then no further records would be added, but if there were a need to associate the QA event with
each subject (e.g., if the information collected during the maintenance event were needed to calibrate results for subsequent cases) then a record
could be added for each affected subject.
Row 2: Shows a software version update for a specific device under study. USUBJID is null because the software update applies to all subjects.

Row STUDYID DOMAIN SPDEVID USUBJID DESEQ DETERM DEDECOD DECAT DESEV DEDTC DESTDTC
Routine device diagnostics Scheduled Scheduled 2009-01-
1 ABC-456 DE 15033 1 Minor 2009-01-05
performed Maintenance Maintenance 06
2009-01-
2 ABC-789 DE 15033 2 Control software updated Software Update Software Update Major 2009-01-05
05

Page 32 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
3.5 Device Tracking and Disposition (DT)
dt.xpt, Device Tracking and Disposition - Events, Version 1.1 One record per device tracking event, Tabulation
Controlled
Variable Variable
Type Terms, Code list Role CDISC Notes Core
Name Label
or Formata
STUDYID Study Identifier Char Identifier Unique identifier for a study. Req
DOMAIN Domain Char DT Identifier Two-character abbreviation for the domain. Req
Abbreviation
SPDEVID Sponsor Device Char Identifier Sponsor-defined identifier for the device. Req
Identifier It must be unique for each tracked unit of the device under study, and can be
at whatever level of granularity the device should be identified (e.g., model
or serial number, combination of identifiers).
DTSEQ Sequence Number Num Identifier Sequence Number given to ensure uniqueness of device records within Req
subject records (if applicable) within a domain.
May be any valid number. Should be unique within each SPDEVID.
DTTERM Reported Term for Char * Topic Verbatim or preprinted term for the activity that occurs. Req
the Tracking Event Example: "Shipped", "Returned", "Installed", "Implanted", "Explanted".
DTMODIFY Modified Reported Char Synonym Modified term entered to allow mapping of verbatim term to dictionary term. Perm
Term Qualifier If DTTERM is modified to facilitate coding, then DTMODIFY will contain
the modified text.
DTDECOD Standardized Char * Synonym Dictionary-derived text description of DTTERM or DTMODIFY. Perm
Tracking Term Qualifier If an external controlled terminology is used, the name and version of the
dictionary used to map terms must be provided in a Define-XML
ExternalCodeList element.
DTCAT Category for Char * Grouping Defines a categorization level for a group of related records. Exp
Device Tracking Qualifier Examples: categorize by tracking event type (e.g., "DOMESTIC" vs.
Event "INTERNATIONAL").
DTSCAT Subcategory for Char Grouping Defines a further categorization level for a group of related conditions or Perm
Device Tracking Qualifier events.
Event
DTPARTY Party Responsible Char * Record Person or organization accountable for the device at the conclusion of the Req
for the Device Qualifier action specified in DTTERM.
Describes the person or organization that is accountable for the device
defined in DTTERM.
For example, if DTTERM=SHIPPED, DTPARTY would contain the transfer
recipient (e.g., SITE). If DTTERM=IMPLANTED, DTPARTY would
contain SUBJECT.

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 33
December 12, 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

Controlled
Variable Variable
Type Terms, Code list Role CDISC Notes Core
Name Label
or Formata
DTPRTYID Responsible Party Char Variable An identifier for the responsible group/role (e.g. site, subject). Exp
Identifier Qualifier The value of the responsible party identified in DTPARTY.
For example, if DTPARTY is SUBJECT, DTPRTYID would contain the
subject number.
DTDTC Date/Time of Char ISO 8601 Timing Date/Time the tracking event information was collected. Perm
Tracking Event Will generally be the same as the date the tracking event started, but it can
Collection differ.
DTSTDTC Start Date/Time of Char ISO 8601 Timing Start date/time of tracking event. Req
Tracking Event A tracking event (e.g., SHIPPED, RECEIVED) is usually a point in time,
which is why only the start date/time is included. If an event occurs over a
longer period, the stop date/time may be included from the SDTM model.
aAsterisk indicates variable may be subject to controlled terminology; sponsor will identify the controlled terminology in Define-XML.

3.5.1 Assumptions for the Device Tracking and Disposition Domain Model
1. Definition: The Device Tracking and Disposition (DT) domain represents tracking events for a given device. This could include initial shipment,
deployment, return, destruction, loss, and so on. Different tracking events would be relevant to different types of devices. For example, an MRI machine
might be shipped to a hospital and remain there, whereas an implantable stent might be shipped to a site and then shipped back to the sponsor if found to
be defective.
2. Only tracking events that are the sponsor’s responsibility are captured in this domain. If that responsibility is formally passed to another entity, such as
hospital staff tracking an MRI machine within their facility, then tracking data will not generally appear in DT. This is governed by local regulations and
sponsor/site practices.
3. This domain is intended to demonstrate “device accountability,” and can be submitted in 2 ways. Tracking data can be captured and submitted that
indicate each party who is accountable for the device from the time it leaves the sponsor facility to its final state such that the dataset accounts for the
device at all times. The last record would effectively be the final disposition of the device. Alternatively, a single disposition record for each device
could be submitted, representing the status of each device at the time of submission; the individual tracking event information remains at the site and
sponsor locations and is available for inspection. This flexibility allows sponsors to track devices either at every move or only report a final disposition
at study end.
4. This domain is not intended to report details about the deployment of a device to a subject except insofar as the device is physically with the subject
(e.g., implantation of a stent). Subject-specific deployment information would usually more appropriately be captured in the Device Exposure (DX)
domain. In some cases this may result in some duplication of data between DX and DT, but the data are intended for very different purposes and will
often capture different details.
5. The level of granularity of the device identification in this domain will vary by device type and sponsor practice, and is defined in Device Identifiers
(DI). In cases where a group of devices is tracked together, such as a box of orthopedic screws, a given SPDEVID may represent multiple individual
units that are not individually tracked and may be split and shipped to different sites. Capture of this information may require the use of the Findings
About domain (see SDTMIG Section 6.4).

Page 34 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
 6. In cases where a device comprises a number of components (e.g., a pacemaker with leads and software), the sponsor may choose to track the overall
device using its SPDEVID or track the identifiers for the individual components, or both, whichever is more appropriate. Subsequent versions of this
document will address the details of tracking components and of associating them with a device.
7. If this domain is populated, there should be at least 1 record in this domain for every tracked unit of the device under study associated with a study that
leaves the sponsor’s facility or manufacturing location. There may be multiple records per device.
8. DTPARTY and DTPRTYID together identify the individual or organization that takes responsibility for the device as a result of the action in DTTERM.
For example, if DTTERM is SHIPPED, DTPARTY would be a general term defining the type of responsible party, such as SITE, and DTPRTYID
would contain the site identifier, such as 02.
9. Usually DTPARTY and DTPRTYID refer to who has possession of the device after the action in DTTERM. In the cases where a device is lost,
destroyed or removed, for example, DTPARTY and DTPRTYID may be null.
10. Tracking events do not have start and end dates because they do not span an interval (e.g. shipped date) but rather occur at a single date/time (e.g.,
implantation date).
11. Relative study days (--DY) are not included in this domain as there may be no association with a subject, and relative days are calculated in comparison
to a subject’s reference start date. If sponsors need to include this information, they may include –DY, but its derivation must follow the rules in the
SDTMIG.
12. The data in this domain may come from a variety of sources, such as a CRF, a shipping log or a transfer document (e.g., when devices are issued as
supplies or samples for engineers to take to sites), and may be partly or wholly derived.
13. Note that in some of the examples that follow, variables that would be blank may have been dropped to conserve space. This does not mean that the
variables cannot be used in the illustrated use case, merely that in the particular example they were not populated.
14. The following Qualifiers would generally not be used in DT: --BODSYS, --LOC, --SER,--ACN,--ACNOTH, --REL, --RELNST, --PATT, --OUT, --
SCAN, --SCONG, --SDISAB, --SDTH, --SHOSP, --SLIFE, --SOD, --SMIE, --CONTRT, --TOX, -TOXGR.

3.5.2 Examples for the Device Tracking and Disposition Domain Model
Example 1
These examples show individual device tracking at each change of location.

Rows 1-2: Device S001 was shipped to the site and implanted in the subject, where it is at the time of reporting. The device could be an orthopedic rod.
Rows 3-5: Device was shipped to Site 01, then it was returned to the sponsor, and then the same device was shipped to Site 02. The device could be a
diagnostic tool that is used on multiple subjects, so it is redeployed when the first site has completed use of it.
Row 6: Device was shipped to the site but no further activity has happened.
Rows 7-10: Device was shipped to the site, implanted in a subject, and then explanted and returned to the sponsor.
Rows 11-14: Device was shipped to the site and implanted in subject. Subsequently, the device was explanted and destroyed by site personnel.
Rows 15-17: The device, a tympanostomy tube, was shipped to the site and implanted in a subject. After the subject returned home, the tube dislodged and was
lost.

Row STUDYID DOMAIN SPDEVID DTSEQ DTTERM DTDECOD DTPARTY DTPRTYID DTCAT DTDTC DTSTDTC
1 ABC-123 DT S001 1 Shipped SHIPPED SITE 02 2010-06-25 2010-06-25
2 ABC-123 DT S001 2 Implantation IMPLANTED SUBJECT 02-1024 2010-07-15 2010-06-30
3 ABC-123 DT S002 1 Shipped SHIPPED SITE 01 2010-11-03 2010-11-03

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 35
December 12, 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

Row STUDYID DOMAIN SPDEVID DTSEQ DTTERM DTDECOD DTPARTY DTPRTYID DTCAT DTDTC DTSTDTC
4 ABC-123 DT S002 2 Returned RETURNED SPONSOR 2011-01-05 2011-01-05
5 ABC-123 DT S002 3 Shipped SHIPPED SITE 02 2011-01-15 2011-01-15
6 ABC-123 DT S003 1 Shipped SHIPPED SITE 05 2010-09-29 2010-09-29
7 ABC-123 DT S004 1 Shipped SHIPPED SITE 04 2010-08-30 2010-08-30
8 ABC-123 DT S004 2 Implanted IMPLANTED SUBJECT 04-1009 2010-11-05 2010-10-20
9 ABC-123 DT S004 3 Explanted EXPLANTED SITE 04 2010-11-05 2010-11-01
10 ABC-123 DT S004 4 Shipped SHIPPED SPONSOR 2010-11-02 2010-11-02
11 ABC-123 DT S005 1 Shipped SHIPPED SITE 04 2010-11-01 2010-11-01
12 ABC-123 DT S005 2 Implanted IMPLANTED SUBJECT 04-1009 2010-12-06 2010-11-12
13 ABC-123 DT S005 3 Explanted EXPLANTED SITE 04 2010-12-06 2010-12-01
14 ABC-123 DT S005 4 Destroyed DESTROYED 2010-12-10 2010-12-09
15 ABC-123 DT Z045-2 1 Shipped SHIPPED SITE 05 2010-12-06 2010-11-12
16 ABC-123 DT Z045-2 2 Implanted IMPLANTED SUBJECT 05-5005 2010-11-12 2010-11-16
17 ABC-123 DT Z045-2 3 Lost LOST 2010-11-18 2010-11-17

Example 2
Implantable Device – Disposition Usage Only. This example shows the tracking of an implantable device where the only information of interest is the final
disposition of the device, rather than tracking of every individual change of responsible party.

Row STUDYID DOMAIN SPDEVID DTSEQ DTTERM DTDECOD DTPARTY DTPRTYID DTCAT DTDTC DTSTDTC
1 ABC-123 DT S001 1 Implanted IMPLANTED SUBJECT 02-1024 2010-07-15 2010-06-30
2 ABC-123 DT S002 2 Shipped SHIPPED SITE 02 2011-01-15 2011-01-15
3 ABC-123 DT S003 3 Shipped SHIPPED SITE 05 2010-09-29 2010-09-29
4 ABC-123 DT S004 4 Shipped SHIPPED SPONSOR 2010-11-02 2010-11-02
5 ABC-123 DT S005 5 Destroyed DESTROYED 2010-12-10 2010-12-09
6 ABC-123 DT Z045-2 6 Lost LOST 2010-11-18 2010-11-17

Example 3
This example shows the tracking of a 2-part spray gun for applying skin cells to burns.

Rows 1, 3: The spray gun body is sent to the site and returned to the sponsor.
Rows 2-4: The disposable cartridge that holds the cells is shipped to the site, and then destroyed after use.

Row STUDYID DOMAIN SPDEVID DTSEQ DTTERM DTDECOD DTPARTY DTPRTYID DTDTC DTSTDTC
1 Z937m DT SSG124 1 Shipped SHIPPED SITE 01 2011-06-29 2011-06-29
2 Z937m DT SSC2160 2 Shipped SHIPPED SITE 01 2011-06-29 2011-06-29
3 Z937m DT SSG124 3 Shipped SHIPPED SPONSOR 2011-08-30 2011-08-30
4 Z937m DT SSC2160 4 Destroyed DESTROYED 2011-07-05 2011-07-05

Page 36 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
3.6 Device-Subject Relationships (DR)
dr.xpt, Device-Subject Relationships - Relationships, Version 1.1. One record per device/subject combination
Variable Controlled Terms,
Variable Label Type Role CDISC Notes Core
Name Code list, or Format
STUDYID Study Identifier Char Identifier Unique identifier for a study. Req
DOMAIN Domain Char DR Identifier Two-character abbreviation for the domain. Req
Abbreviation

USUBJID Unique Subject Char Identifier Identifier used to uniquely identify a subject across all studies for all applications Req
Identifier or submissions involving the product.
Required, as the purpose of this domain is to link each USUBJID to one or more
devices.
SPDEVID Sponsor Device Char Identifier Sponsor-defined identifier for the device. Req
Identifier It must be unique for each tracked unit of the device under study, and can be at
whatever level of granularity the device should be identified (e.g., model or serial
number, combination of identifiers) as defined in DI.

3.6.1 Assumptions for the Device-Subject Relationships Domain Model

1. Definition: The Device-Subject Relationships (DR) domain is a Relationships domain that links each subject to the associated device(s).
2. Information in this table may have been initially collected and submitted in other domains (e.g., Device Exposure, DX, Device Tracking and
Disposition, DT, Device Events, DE). This domain, however, provides a consistent location for the relationship between a subject and a device,
regardless of the device or the domain in which subject-related data may have been collected or submitted.
3. This domain is a Relationships domain and does not have a topic variable.
4. This domain allows for many-to-many relationships such that a single subject may be associated with several devices (e.g., blood glucose test meters), a
single device or class of devices may be associated with several subjects (e.g., an MRI machine), or several devices may be associated with several
subjects. In effect, this creates an index of the device-subject associations that permits other domains to determine the correct associations without
having to store all relationship data in every domain.
5. Sponsors are responsible for defining SPDEVID such that device-subject relationships are described with the necessary level of detail for the
submission.

3.6.2 Examples for the Device-Subject Relationships Domain Model

Example 1
In this example, the study requires collection of MRI data at specified time intervals. The MRI equipment is not under study; the product under investigation may
not even be a device. The study protocol requires collection of specific settings on the MRI equipment at each encounter, but there is no requirement to track the
specific MRI machine(s) with which subjects were scanned.

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 37
December 12, 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

Row STUDYID DOMAIN USUBJID SPDEVID

1 ABC-123 DR 101 MRI
2 ABC-123 DR 103 MRI
3 ABC-123 DR 201 MRI
4 ABC-123 DR 202 MRI

Example 2
In this example, the study protocol requires that some subjects be implanted with a pacemaker prior to enrollment, whereas others are not. The pacemakers are
not under study; the product under investigation may not even be a device. The study protocol requires analysis stratified by whether or not subjects have a
pacemaker, and if they do, the type of pacemaker (single- or dual-chamber). There is no requirement to track the specific pacemaker implanted in each subject.
At some point during the study, subject C13 has a single-chamber pacemaker replaced with a dual-chamber model. Information on when and why this happened
would not be discernible from DR, but could be captured in DX.

Row STUDYID DOMAIN USUBJID SPDEVID

1 ABC-456 DR A11 Dual Chamber Pacemaker
2 ABC-456 DR A12 Dual Chamber Pacemaker
3 ABC-456 DR B21 Single Chamber Pacemaker
4 ABC-456 DR C13 Single Chamber Pacemaker
5 ABC-456 DR C13 Dual Chamber Pacemaker

Example 3
In this example, a new coronary stent and delivery catheter system is being submitted for approval to market. Delivery catheters are tracked by manufacturing
lot; stents are tracked by individual unit serial number.

Subject 103 was exposed to 2 investigational stents, but the DR table provides no further information.

Subject 202 (Row 10) had an adverse event during the PCI procedure that was related to the Venotrate Introducer (a tool used in the procedure). The DR table
captures the relationship between the subject and the device, but all additional information about the AE would be captured in the AE domain.

Row STUDYID DOMAIN USUBJID SPDEVID

1 STUDY42 DR 101 Lot EZN123
2 STUDY42 DR 101 S/N BBS1001
3 STUDY42 DR 103 Lot EZN123
4 STUDY42 DR 103 S/N BBS1045
5 STUDY42 DR 103 S/N BBS1047
6 STUDY42 DR 201 Lot EZN201
7 STUDY42 DR 201 S/N BBS1067
8 STUDY42 DR 202 Lot EZN217
9 STUDY42 DR 202 S/N BBS1012
10 STUDY42 DR 202 Lot VI321

Page 38 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
3.7 Device Properties (DO)
do.xpt, Device Properties - Findings, Version 1.1 One record per property per device, Tabulation
Controlled Terms,
Variable
Variable Label Type Code List, or Role CDISC Notes Core
Name
Formata,b
STUDYID Study Identifier Char Identifier Unique identifier for a study. Req
DOMAIN Domain Char DO Identifier Two-character abbreviation for the domain. Req
Abbreviation
SPDEVID Sponsor Device Char Identifier Sponsor-defined identifier for the device. Req
Identifier It must be unique for each tracked unit of the device under study, and can be at
whatever level of granularity the device should be identified (e.g., model or
serial number, combination of identifiers).
DOSEQ Sequence Num Identifier Sequence Number given to ensure uniqueness of device records within subject Req
Number records within a domain.
May be any valid number. It should be unique within every subject/device
combination.
DOGRPID Group ID Char Identifier Used to tie together a block of related records in a single domain for a device. Perm
DOREFID Reference ID Char Identifier Internal or external identifier. Perm
This could be a scan code or equivalent.
DOSPID Sponsor-Defined Char Identifier Sponsor-defined reference number. Perm
Identifier
DOTESTCD Device Property Char (DOTESTCD) Topic Short name of the measurement, test, or examination described in DOTEST. Req
Short Name It can be used as a column name when converting a dataset from a vertical to a
horizontal format. The value in DOTESTCD cannot be longer than 8
characters, nor can it start with a number (e.g., "1TEST"). DOTESTCD cannot
contain characters other than letters, numbers, or underscores. Examples:
"SHLFLIFE", "INDC", "COMPOS".
DOTEST Device Property Char (DOTEST) Synonym Verbatim name of the test or examination used to obtain the measurement or Req
Test Name Qualifier finding.
The value in DOTEST cannot be longer than 40 characters. Examples: "Shelf
Life", "Indication for use", "Composition" (of device).
DOCAT Category for Char * Grouping Defines a category of related records. Perm
Device In-Use Qualifier For example, it can be used to define the type of property being defined, such
as "DIMENSIONS" versus "MATERIAL".
DOSCAT Subcategory for Char * Grouping A further categorization of a measurement or examination. Perm
Device In-Use Qualifier For example, if DOCAT = "DIMENSION", DOSCAT might be "LENGTH"
or "WIDTH" or "THICKNESS".

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 39
December 12, 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

Controlled Terms,
Variable
Variable Label Type Code List, or Role CDISC Notes Core
Name
Formata,b
DOORRES Result or Char Result Result of the Device Property as originally observed or collected. Exp
Finding in Qualifier DOORRES should contain the result or value of the property defined in
Original Units DOTEST. For example, if DOTEST is LIFE (shelf life), then DOORRES
might be 6 (months).
DOORRESU Original Units Char (UNIT) Variable Original units in which the data were collected. Exp
Qualifier The unit for DOORRES. Examples: "MONTHS", "cm".
aAsterisk indicates variable may be subject to controlled terminology; sponsor will identify the controlled terminology in Define-XML.
bParentheses indicates CDISC/NCI code list code value.

3.7.1 Assumptions for the Device Properties Domain Model

1. Definition: Device Properties (DO) is a Findings domain and defines important characteristics of a device that the sponsor wishes to include in the
submission but that do not form part of the unique sponsor-defined identification of the device. If there are no non-identifier characteristics to submit,
this domain may not be necessary.
2. Each property is identified using controlled terminology and is stored in DOTESTCD/DOTEST, which allows the property names to be values in
DOTESTCD in an SDTM-based vertical (normalized) structure and variable names in a CDASH horizontal (non-normalized) structure, if necessary.
The controlled terminology has not yet been identified.
3. There should be one record per device property.
4. Sponsors define the properties and levels of granularity that are appropriate to include in this domain.
5. DO supports all device types (e.g., implantable, imaging, diagnostic), although implementation may vary by device type.
6. This domain does not define the relationships between tracked components and the overall device. This will be addressed in a future version of the
standard.
7. DO should not contain characteristics that may change during the course of the study for a given device (e.g., dial settings on an imaging machine,
software versions). As a result, the domain does not include Timing variables (SDTM Table 2.2.5).
8. Sponsors may choose whether to include in DO characteristics of approved products or components that are used in the study in accordance with the
approved labeling.
9. The DO domain can contain data about devices that were not deployed, as there is no subject identifier in DO. It should contain only data that should be
submitted with the clinical data; additional manufacturing and quality data may exist elsewhere in the submission and do not need to be included in DO
unless the sponsor has a specific reason to do so.
10. DO data would generally be assembled by a sponsor, rather than by an investigative site. The data can be captured using a CRF, assembled on a
worksheet to support entry of the information into the clinical database, derived manually, or derived electronically from data in other domains or
elsewhere.
11. DOTESTCD values are limited to 8 characters and cannot begin with a number or underscore as they can be used as variable names when the dataset is
transposed to a non-normalized structure.
12. Note that in some of the examples that follow, variables that would be blank may have been dropped to conserve space. This does not mean that the
variables cannot be used in the illustrated use case, merely that in the particular example they were not populated.

Page 40 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
 13. The following Qualifiers would not generally be used in DO: --MODIFY, --BODSYS, --POS,--ORNRLO, --ORNRHI, --STNRLO, --STNRHI, --
STNRC, --NRIND, --RESCAT, --STAT, --REASND, --XFN, --NAM, --LOINC, --SPEC, --ANTREG, --SPCCND, --LOC, --LAT, --DIR, --METHOD,
--LEAD, --BLFL, --FAST, --DRVFL, --EVAL, --TOX, --TOXGR, --SEV, --DTHREL and LLOQ

3.7.2 Examples for the Device Properties Domain Model

Example 1
This example shows characteristics of 2 kinds of nylon mesh filter. The characteristics will not change, so the date is not relevant.

Row STUDYID DOMAIN SPDEVID DOSEQ DOTESTCD DOTEST DOCAT DOSCAT DOORRES DOORRESU
1 STUDYX DO ABC174 1 CLASS Class RISK PROFILE 3
2 STUDYX DO ABC174 2 PORESIZE Pore Size DIMENSION 20 um
3 STUDYX DO ABC174 3 THCKNESS Mesh Thickness DIMENSION 52 um
4 STUDYX DO ABC174 4 OPENAREA Mesh Open Area DIMENSION 14 %
5 STUDYX DO ABC259 1 CLASS Class RISK PROFILE 3
6 STUDYX DO ABC259 2 PORESIZE Pore Size DIMENSION 43 um
7 STUDYX DO ABC259 3 THCKNESS Mesh Thickness DIMENSION 35 um
8 STUDYX DO ABC259 4 OPENAREA Mesh Open Area DIMENSION 22 %

Example 2
The two data points being conveyed to the regulators are the color of the kit box and the Lot ID of the kit’s reagents. In this case, the color is associated with the
number of tests contained in the kit, with the red box containing 6 tests and the blue box containing 8 tests.

Row STUDYID DOMAIN SPDEVID DOSEQ DOTESTCD DOTEST DOORRES DOORRESU

1 ABC-125 DO 423-001 1 TESTNUM Number of Tests 6
2 ABC-125 DO 423-001 2 REAGLOT Reagent Lot ID 123-56
3 ABC-125 DO 876-523 1 TESTNUM Number of Tests 8
4 ABC-125 DO 876-523 2 REAGLOT Reagent Lot ID 123-60

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 41
December 12, 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

4 Cross-Domain Relationship Examples

4.1 Device-In-Use and Test Results
This section illustrates the way that the settings of the device used can be related to the results generated from the measurement or output of the device. This uses
the example in the Device-In-Use (DU) domain earlier in this document that shows settings on an MRI and relates it to Neurological results obtained from the
MRI scan.

Example 1
This example shows data about parameters from an MRI imaging protocol collected from 1 subject at 1 visit. It assumes the image was used for obtaining
neurological observations, as shown by the choice of DULNKID. DULNKID can be used to link to the Neurological Findings (NV) records, as shown below.

Rows 1-7: Represent 7 example DU records collected at the screening visit for a given subject.
Rows 8-14: Represent 7 example DU records collected at the first treatment visit for the same subject.

du.xpt
Row STUDYID DOMAIN USUBJID SPDEVID DUSEQ DUREFID DUSPID DULNKID DUTESTCD DUTEST DUORRES DUORRESU
1 STUDYX DU 2324-P0001 ABC174 1 223-45 1 DUNV1 COILSTR Coil Strength 1.5 T
2 STUDYX DU 2324-P0001 ABC174 2 223-45 2 DUNV1 ANTPLANE Anatomical Plane CORONAL
3 STUDYX DU 2324-P0001 ABC174 3 223-45 3 DUNV1 STHICK Slice Thickness 1 mm
4 STUDYX DU 2324-P0001 ABC174 4 223-45 4 DUNV1 MATRIX Matrix 256X256
5 STUDYX DU 2324-P0001 ABC174 5 223-45 5 DUNV1 SFTWRVER Software Version 15.0
6 STUDYX DU 2324-P0001 ABC174 6 223-45 6 DUNV1 FLDVIEW Field of View 24 cm
7 STUDYX DU 2324-P0001 ABC174 7 223-45 7 DUNV1 RCBDWTH Receiver Bandwidth 16 kHz
8 STUDYX DU 2324-P0001 ABC174 8 445-77 1 DUNV2 COILSTR Coil Strength 1.0 T
9 STUDYX DU 2324-P0001 ABC174 9 445-77 2 DUNV2 ANTPLANE Anatomical Plane CORONAL
10 STUDYX DU 2324-P0001 ABC174 10 445-77 3 DUNV2 STHICK Slice Thickness 2 mm
11 STUDYX DU 2324-P0001 ABC174 11 445-77 4 DUNV2 MATRIX Matrix 256X256
12 STUDYX DU 2324-P0001 ABC174 12 445-77 5 DUNV2 SFTWRVER Software Version 15.1
13 STUDYX DU 2324-P0001 ABC174 13 445-77 6 DUNV2 FLDVIEW Field of View 25 cm
14 STUDYX DU 2324-P0001 ABC174 14 445-77 7 DUNV2 RCBDWTH Receiver Bandwidth 16 kHz

Row DUSTRESC DUSTRESN DUSTRESU VISITNUM VISIT VISITDY DUDTC DUDY

1 (cont) 1.5 1.5 T 1 SCREENING -7 2011-04-19 -7
2 (cont) CORONAL 1 SCREENING -7 2011-04-19 -7
3 (cont) 1 1 mm 1 SCREENING -7 2011-04-19 -7
4 (cont) 256X256 1 SCREENING -7 2011-04-19 -7
5 (cont) 15.0 1 SCREENING -7 2011-04-19 -7
6 (cont) 24 24 cm 1 SCREENING -7 2011-04-19 -7
7 (cont) 16 1 kHz 1 SCREENING -7 2011-04-19 -7

Page 42 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
 Row DUSTRESC DUSTRESN DUSTRESU VISITNUM VISIT VISITDY DUDTC DUDY
8 (cont) 1.0 1.0 T 2 IMPLANTATION 1 2011-04-26 1
9 (cont) CORONAL 2 IMPLANTATION 1 2011-04-26 1
10 (cont) 2 2 mm 2 IMPLANTATION 1 2011-04-26 1
11 (cont) 256X256 2 IMPLANTATION 1 2011-04-26 1
12 (cont) 15.1 2 IMPLANTATION 1 2011-04-26 1
13 (cont) 25 25 cm 2 IMPLANTATION 1 2011-04-26 1
14 (cont) 16 16 kHz 2 IMPLANTATION 1 2011-04-26 1

Row 1-7: Represent 6 possible organ measurement tests and 1 physician interpretation at a screening visit. This shows data reported in the original result and unit
in NVORRES and NVORRESU and standardized in NVSTRESC, NVSTRESN, and NVSTRESU. It also shows the standard terminology for
NVTESTCD and NVTEST. NVLNKID can be used to capture the link to the device used to obtain the data listed in this table (e.g., the SPDEVID for
the device that performed the scan). NVREFID can hold the unique identifier for that specific scan and could link to the scan results in a different
domain (not shown).
Row 8-14 Represent the same data as Rows 1-7 but for Visit 2.
Row 15-20: Represent the same 6 tests run on a calibration sample (there are no interpretation or derived records for the calibration sample). The NVLNKID has
been set to CALIBRATION to distinguish it from the subject tests.

nv.xpt
Row STUDYID DOMAIN USUBJID NVSEQ NVREFID NVSPID NVLNKID NVTESTCD NVTEST NVORRES NVORRESU NVSTRESC
2324-
1 STUDYX NV 1 223-45 1 DUNV1 TOTVOL Total Volume 1120000 mm3 1120000
P0001
2324- 223-45
2 STUDYX NV 2 2 DUNV1 VOLUME Volume 2725 mm3 2725
P0001
2324- 223-45
3 STUDYX NV 3 3 DUNV1 VOLUME Volume 2685 mm3 2685
P0001
2324- 223-45
4 STUDYX NV 4 4 DUNV1 VOLUME Volume 15635 mm3 15635
P0001
2324- 223-45
5 STUDYX NV 5 5 DUNV1 VOLUME Volume 15650 mm3 15650
P0001
2324- 223-45
6 STUDYX NV 6 6 DUNV1 VOLUME Volume 7505 mm3 7505
P0001
2324- 223-45 Annualized Brain
7 STUDYX NV 7 7 DUNV1 ABBSI -1.5
P0001 Boundary Shift Int
2324-
8 STUDYX NV 8 445-77 1 DUNV2 TOTVOL Total Volume 1120000 mm3 1120000
P0001
2324- 445-77
9 STUDYX NV 9 2 DUNV2 VOLUME Volume 2725 mm3 2725
P0001
2324- 445-77
10 STUDYX NV 10 3 DUNV2 VOLUME Volume 2685 mm3 2685
P0001
2324- 445-77
11 STUDYX NV 11 4 DUNV2 VOLUME Volume 15635 mm3 15635
P0001

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 43
December 12, 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

Row STUDYID DOMAIN USUBJID NVSEQ NVREFID NVSPID NVLNKID NVTESTCD NVTEST NVORRES NVORRESU NVSTRESC
2324- 445-77
12 STUDYX NV 12 5 DUNV2 VOLUME Volume 15650 mm3 15650
P0001
2324- 445-77
13 STUDYX NV 13 6 DUNV2 VOLUME Volume 7505 mm3 7505
P0001
2324- 445-77 Annualized Brain
14 STUDYX NV 14 7 DUNV2 ABBSI -1.5
P0001 Boundary Shift Int
15 STUDYX NV 1 4567-8901 1 CALIBRATION TOTVOL Total Volume 1130000 mm3 1130000
16 STUDYX NV 2 4567-8901 2 CALIBRATION VOLUME Volume 2740 mm3 2740
17 STUDYX NV 3 4567-8901 3 CALIBRATION VOLUME Volume 2670 mm3 2670
18 STUDYX NV 4 4567-8901 4 CALIBRATION VOLUME Volume 15752 mm3 15752
19 STUDYX NV 5 4567-8901 5 CALIBRATION VOLUME Volume 15685 mm3 15685
20 STUDYX NV 6 4567-8901 6 CALIBRATION VOLUME Volume 7597 mm3 7597

Row NVSTRESN NVSTRESU NVLOC NVLAT NVMETHOD NVBLFL NVDRVFL VISITNUM VISIT VISITDY NVDTC NVDY
2011-04-
1 (cont) 1120000 uL BRAIN MRI Y 1 SCREENING -7 -7
19
BRAIN, 2011-04-
2 (cont) 2725 uL LEFT MRI Y 1 SCREENING -7 -7
HIPPOCAMPUS 19
BRAIN, 2011-04-
3 (cont) 2685 uL RIGHT MRI Y 1 SCREENING -7 -7
HIPPOCAMPUS 19
2011-04-
4 (cont) 15635 uL TEMPORAL LOBE LEFT MRI Y 1 SCREENING -7 -7
19
2011-04-
5 (cont) 15650 uL TEMPORAL LOBE RIGHT MRI Y 1 SCREENING -7 -7
19
BRAIN, 2011-04-
6 (cont) 7505 uL MRI Y 1 SCREENING -7 -7
VENTRICLE 19
2011-04-
7 (cont) -1.5 % BRAIN MRI Y 2 IMPLANTATION 1 1
26
2011-04-
8 (cont) 1120000 uL BRAIN MRI 2 IMPLANTATION 1 1
26
BRAIN, 2011-04-
9 (cont) 2725 uL LEFT MRI 2 IMPLANTATION 1 1
HIPPOCAMPUS 26
BRAIN, 2011-04-
10 (cont) 2685 uL RIGHT MRI 2 IMPLANTATION 1 1
HIPPOCAMPUS 26
2011-04-
11 (cont) 15635 uL TEMPORAL LOBE LEFT MRI 2 IMPLANTATION 1 1
26
2011-04-
12 (cont) 15650 uL TEMPORAL LOBE RIGHT MRI 2 IMPLANTATION 1 1
26
BRAIN, 2011-04-
13 (cont) 7505 uL MRI 2 IMPLANTATION 1 1
VENTRICLE 26
2011-04-
14 (cont) -1.5 % BRAIN MRI Y 2 IMPLANTATION 1 1
26

Page 44 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
 Row NVSTRESN NVSTRESU NVLOC NVLAT NVMETHOD NVBLFL NVDRVFL VISITNUM VISIT VISITDY NVDTC NVDY
2011-04-
15 (cont) 1130000 uL BRAIN MRI
18
BRAIN, 2011-04-
16 (cont) 2740 uL LEFT MRI
HIPPOCAMPUS 18
BRAIN, 2011-04-
17 (cont) 2670 uL RIGHT MRI
HIPPOCAMPUS 18
2011-04-
18 (cont) 15752 uL TEMPORAL LOBE LEFT MRI
18
2011-04-
19 (cont) 15685 uL TEMPORAL LOBE RIGHT MRI
18
BRAIN, 2011-04-
20 (cont) 7597 uL MRI
VENTRICLE 18

Rows 1-2: Represents the RELREC relationship between du.xpt and nv.xpt above. Note that CALIBRATION, the NVGRPID value for the calibration run,
does not appear here because there is no corresponding subject. See the SDTMIG (RELREC section) for further discussion and examples of
RELREC.

relrec.xpt
Row STUDYID USUBJID RDOMAIN IDVAR IDVARVAL RELTYPE RELID
1 STUDYX NV NVLNKID MANY NVDU1
2 STUDYX DU DULNKID MANY NVDU1

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 45
December 12, 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

Appendices
Appendix A: Glossary and Abbreviations
The following abbreviations and terms may be used in this document. Additional definitions can be found in the
CDISC Glossary available at http://www.cdisc.org/glossary/index.html.
Abbreviation/
Acronym/Term Definition
510(k) A kind of regulatory submission in which a device company requests permission from the FDA to market
a new device when the device is “substantially equivalent” in safety and efficacy to one that is already
marketed. Such devices are generally seen as lower risk, and do not necessarily require clinical trials for
FDA to clear them.
Ancillary Device A device used within a clinical trial to collect subject data information (device or human subject), but that
is not the target of the study (e.g., an MRI or CT machine whose settings must be recorded in the clinical
trial data, as required in the protocol)
BLA Biologics License Application: A submission made by the manufacturer of a licensed biologic that also
meets the definition of a medical device and which is subsequently subjected to scientific review by CBER
(or FDA) to determine the biologics’/device’s safety, purity and potency and the acceptability of the
manufacturing facilities before approval for marketing.
BRIDG Biomedical Research Integrated Domain Group
caBIG cancer Biomedical Informatics Grid™: An information network enabling all constituencies in the cancer
community—researchers, physicians, and patients—to share data and knowledge. Largely superseded by
NCIP.
CBER Center for Biologics Evaluation and Research: One of the divisions of the FDA responsible for regulatory
evaluation of medical devices, among other responsibilities.
CDASH Clinical Data Acquisition Standards Harmonization Project: The name for the project that delivers basic
data collection fields (this document).
CDISC Clinical Data Interchange Standards Consortium, a Standards Development Organization
CDM Clinical Data Management
CDRH Center for Devices and Radiological Health: One of the divisions of the FDA responsible for regulatory
evaluation of medical devices, among other responsibilities.
Class I Devicea A device proposed for regulatory review that is perceived to be low risk. Requirements for clearance for
marketing are “general controls” and include provisions that relate to adulteration; misbranding; device
registration and listing; premarket notification; banned devices; notification, including repair, replacement,
or refund; records and reports; restricted devices; and good manufacturing practices. Examples include
elastic bandages, handheld surgical tools, and examination gloves.
Class II Devicea Devices for which the controls for Class I are not considered sufficient to ensure safety and efficacy, and
thus additional controls are required. These may include special labeling requirements, mandatory
performance standards, and other controls. Examples include powered wheelchairs, infusion pumps, and
surgical drapes.
Class III Devicea A device for which Class I and Class II controls do not provide sufficient evidence for its safety and
efficacy. These devices are generally of higher risk to humans. Examples include implantable pacemaker,
pulse generators, HIV diagnostic tests, automated external defibrillators, and endosseous implants.
Collected Within this document, “collected” refers to information that is recorded and/or transmitted to the sponsor.
This includes data entered by the site on CRFs/eCRFs as well as vendor data such as core lab data. This
term is a synonym for “captured.”
Controlled A finite set of values that represent the only allowed values for a data item. These values may be codes,
Terminology text, or numeric. A code list is one type of controlled terminology.
CRF Case report form (sometimes, case record form) A printed, optical, or electronic document designed to
record all required information to be reported to the sponsor for each trial subject.
CTCAE Common Terminology Criteria for Adverse Events
Databased To have put (data) into a database.
Dataset A collection of structured data in a single file
Derived Within this document, “derived” refers to information that is not directly entered into the specific data
field by the investigator site or by a core lab. This category includes auto-encoded data, calculated data
and similar electronically generated data, but not prepopulated fields.
Domain A collection of observations with a topic-specific commonality about a subject

Page 46 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
eCRF Electronic case report form
EMA The European Medicines Agency: A decentralized body of the European Union whose main responsibility
is the protection and promotion of public and animal health, through the evaluation and supervision of
medicines for human and veterinary use.
Epoch Interval of time in the planned conduct of a study. An epoch is associated with a purpose (e.g., screening,
randomization, treatment, follow-up), which applies across all arms of a study.
EVS Enterprise Vocabulary Services
FAQs Frequently Asked Questions
FDA Food and Drug Administration: Part of the US Department of Health and Human Services Agency, the
regulatory authority for all pharmaceuticals (including biologics and vaccines) and medical devices in the
United States.
GCDMP Good Clinical Data Management Practices (GCDMP): SCDM publication on clinical data management
processes.
GCP Good Clinical Practice
HL7 Health Level 7
ICH International Conference on Harmonization of Technical Requirements for Registration of
Pharmaceuticals for Human Use
ICH E2A ICH guidelines on Clinical Safety Data Management: Definitions and Standards for Expedited Reporting
ICH E2B ICH guidelines on Clinical Safety Data Management: Data Elements for Transmission of Individual Case
Safety Reports
ICH E2C ICH guidelines on Clinical Safety Data Management: Periodic Safety Update Reports for Marketed Drugs
ICH E3 ICH guidelines on Structure and Content of Clinical Study Reports
ICH E4 ICH guidelines on Dose-Response Information to Support Drug Registration
ICH E5 ICH guidelines on Ethnic Factors in the Acceptability of Foreign Clinical Data
ICH E6 (R1) ICH guideline for Good Clinical Practice
ICH E9 ICH guidelines on Statistical Principles for Clinical Trials
ICH E11 ICH guidelines on Clinical Investigation of Medicinal Products in the Pediatric Population
ICH E14 ICH guidelines on the Clinical Evaluation of QT/QTc Interval
IDE Investigational Device Exemption. An IDE application is required by the U.S. FDA before some clinical
trials of a new medical device may be initiated.
IND Investigational New Drug. An IND application is required by the U.S. FDA before clinical trials of a new
drug or new biological agent may be initiated.
IRB Institutional Review Board. Under FDA regulations, an IRB is an appropriately constituted group that has
been formally designated to review and monitor biomedical research involving human subjects
ISO 8601 International Organization for Standardization document of character representation of dates, date/times,
intervals, and durations of time
Many-to-Many Describes the relationship between two sets of objects (e.g., data points or observations in datasets) where
each object in each dataset has a relationship with many objects in the other dataset. For example, one
subject could have many medical history conditions (e.g., headache, toothache, earache), and a given
medical history condition (e.g., headache) can be had by many subjects. See One-to-One and One-to-
Many.
MedDRA Medical Dictionary for Regulatory Activities: New global standard medical terminology designed to
supersede other terminologies (e.g., COSTART, ICD9) used in the medical product development process.
NCI National Cancer Institute (NIH)
NCI EVS National Cancer Institute (NIH) Enterprise Vocabulary Services
NDA New Drug Application
NICHD National Institute of Child Health and Human Development,
NIH National Institutes of Health
NLM National Library of Medicine
ODM Operational Data Model: Format for representing the study metadata, study data and administrative data
associated with a clinical trial.
One-to-One Describes the relationship between 2 sets of objects (e.g., observations in datasets) where each object in
each dataset has a relationship with 1 and only 1 object in the other dataset. For example, Subject 1 is
assigned only Lab Kit 1, and Lab Kit 1 is assigned only to Subject 1. See Many-to-Many and One-to-
Many.
One-to-Many Describes the relationship between 2 sets of objects (e.g., observations in datasets) where each object in
on1e dataset has a relationship with many objects in the other dataset, but the objects in the second dataset
each have only one relationship with 1 object in the first dataset. For example, Subject 1 could have many
lab tests, but each lab test is assigned only Subject 1. See Many-to-Many and One-to-One.
OTC Over the Counter.

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 47
December 12, 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

PhRMA Pharmaceutical Research and Manufacturers Association

PMAa Premarket Approval: A process of scientific review to ensure the device’s safety and effectiveness, which
must be completed for FDA to consider permitting marketing of the device. Class III devices typically
require PMAs.
PRBC Packed Red Blood Cells
Predicate Deviceb A legally marketed device that serves as the basis for comparison for a new device in a 510(k) pre-
marketing notification.
Pre-Printed Items that are part of the original printing on a paper CRF. For example, the unit required for a response,
such as “years” for an age question. These data may or may not be stored in the database.
Pre-Populated Items that are part of the eCRF (or data collection device) that are not enterable/modifiable. These data are
stored in the study database.
PRN Latin term, pro re nata, meaning “as needed.”
Protocol Deviation A variation from processes or procedures defined in a protocol. Deviations usually do not preclude the
overall evaluability of subject data for either efficacy or safety, and are often acknowledged and accepted
in advance by the sponsor. Note: Good clinical practice recommends that deviations be summarized by site
and by category as part of the report of study results so that the possible importance of the deviations to
the findings of the study can be assessed. Cf. Protocol Violation. See ICH E3.
Protocol Violation A significant departure from processes or procedures required by the protocol. Violations often result in
data that are not deemed evaluable for a per-protocol analysis, and may require that the subject(s) who
violated the protocol be discontinued from the study. Cf. Protocol deviation.
RCRIM Regulated Clinical Research Information Management
RIM Reference Information Model
SAP Statistical Analysis Plan
SCDM Society for Clinical Data Management,
SDS Submission Data Standards. Also the name of the team that created the SDTM and SDTMIG
SDO Standards Development Organization
SDTM Study Data Tabulation Model
SDTMIG SDTM Implementation Guide. When written just like this, it represents the original SDTMIG, in which
the experimental unit is a subject, as compared to SEND, for example, where the experimental unit is an
animal.
SDTMIG-MD SDTM Implementation Guide for Medical Device trials, where the experimental unit is the device.
SOCs System Organ Class (from MedDRA)
Study Treatment The drug, device, therapy, or process under investigation in a clinical trial which has an effect on outcome
of interest in a study (e.g., health-related quality of life, efficacy, safety, pharmacoeconomics). Synonyms:
intervention, therapeutic intervention, medical product.
TA Therapeutic Area
Uncoded Not coded. Not having or showing a code.
UUID Universally Unique Identifier
WHO World Health Organization
WHO ART World Health Organization Adverse Reaction Terminology (sometimes, WHO-ART) has been developed
over more than 30 years to serve as a basis for rational coding of adverse reaction terms.
WHO Drug World Health Organization Drug Dictionary
aDefinition drawn from:

“Device Classification”. Medical Devices. U.S. Food and Drug Administration.

“TITLE 21–FOOD AND DRUGS: CHAPTER I–FOOD AND DRUG ADMINISTRATION: DEPARTMENT OF
HEALTH AND HUMAN SERVICES: SUBCHAPTER H–MEDICAL DEVICES: PART 860 MEDICAL DEVICE
CLASSIFICATION PROCEDURES”. CFR – Code of Federal Regulations Title 21. U.S. Food and Drug
Administration.
“General and Special Controls”. Medical Devices. U.S. Food and Drug Administration.
bDefinition drawn from the FDA’s Medical Device page on “How to find a predicate device,” retrieved 31Aug2011

(http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/HowtoMarketYourDevice/PremarketSubmissions/Premark
etNotification510k/ucm134571.htm).

Appendix B: Revision History

Overview of Changes:
This release of the Medical Device Implementation Guide Version 1.1 finalizes the Provisional Version 1.0. The
changes from Version 1.0 are very minor, consisting primarily of changing Special Domains references to Study
References or Relationships and confirming the finalization of variables introduced in Version 1.0. A selection of
minor errors, grammar, and typos have also been addressed. The more significant changes include:

Page 48 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
Classification Type Section Domain Variable Description of Change
Major Deletion 4.2 DU All Removed language suggesting that DI might
be optional when information about a device
is collected in a study. This makes it
consistent with the Assumptions in DI.
Major Change 2.5, 4.1 DI TYPE/DEVTYPE The variable/controlled terminology term
TYPE was changed to DEVTYPE to make it
more specific. The change was reflected in
the Controlled Terminology standard
published 2Q2013.
Major Change 2.1, 2.2, 2.3, DR All Changed category of DR domain from
4.6 Special Purpose to Relationships, based on
its change in the SDTM model v1.7
Major Change 2.1, 2.2, 2.3, DI All Changed category of DI domain from
4.1 Special Purpose to Study References based
on its change in the SDTM model v1.7
Minor Deletion Several All Device SPDEVID, --PARTY, Removed references to the Device domains
domains --PARTYID, -- and variables as “new” domains, as they
ACNDEV have now been available for a number of
years
Minor Change 4.2, 5.1 MO/NV All MO variables Changed all domain references about the
morphology MO domain to Nervous System
Findings domain. These appear only in
examples. Morphology has been deprecated
and replaced by body system-specific
domains.
Minor Change Specification DT & DE DTDTC, DTDY, Updated labels to be less than 40 characters
tables DTSTDY, DEDY,
DESTDY
Minor Change Controlled DE DEDECOD Moved reference to FDA’s Problem Code
Terminology list from CT column to Assumptions
Minor Change 4.3 Example 3 DX DXGRPID Changed column header of DXGRPID to
DXCAT as the data in the variable are
categorizing rather than grouping the
records. See SDTM model for variable
definitions.
Minor Change Section 4 All All Changed specification structure to combine
specification Definition and Implementation Notes
tables columns into CDISC Notes to make them
consistent with tables in other IGs.
Minor Change Section 5 Cross-domain N/A Corrected the order of the columns in the
relationship example tables; corrected usage of --GRPID,
examples --LNKID, and --SPID in the example tables
and explanatory text.

Appendix C: CDISC Controlled Terminology

Terminology applicable to CDISC Device collection and submission fields is either in production or under
development by the CDISC Terminology Team. Production terminology is published by the
National Cancer Institute’s Enterprise Vocabulary Services (NCI EVS) and can be accessed at
https://www.cancer.gov/research/resources/terminology/cdisc.

Appendix D: Other Relevant Standards

Beyond those listed here, additional standards that may affect device clinical trials can be found on the FDA CDRH
website (http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/Standards/default.htm).

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 49
December 12, 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

Appendix D1: Unique Device Identifier (UDI)

The FDA Amendments Act of 2007 mandated a physical label on devices, the “unique device identifier” (UDI). The
labels have two components:

1. Device Identifier: manufacturer, make and model

2. Production Identifier: serial or lot number and expiration date

Guidelines on the UDI have been published and are available at The UDI attributes are available here. The UDI
Help Desk can be contacted here.

The UDI is intended to track individual device units once they are in the marketplace, and the information included
is largely only obtainable after manufacture for distribution. As a result, most studies using this SDTM
implementation guide for premarket research will be unlikely to require UDIs. If needed, the UDI can be included as
a characteristic in Device Identifiers (DI).

Appendix D2: Code of Federal Regulations

The primary U.S. federal regulations affecting medical devices that have an impact on the capture and submission of
clinical trials data to regulatory authorities are found in 21CFR:

• 21 CFR Part 601 Licensing

• 21 CFR Part 660 - Additional Standards for Diagnostic Substances for Laboratory Tests
• 21 CFR Part 812 Investigational Device Exemptions
• 21 CFR Part 807 ESTABLISHMENT REGISTRATION AND DEVICE LISTING FOR
MANUFACTURERS AND INITIAL IMPORTERS OF DEVICES, Subpart E Premarket Notification
Procedures
• 21 CFR Part 814 Premarket Approval of Medical Devices
• 21 CFR Part 803 Medical Device Reporting

Appendix D3: International Organization for Standardization (ISO)

The ISO 14155 standard was first developed in 2003 and updated in 2011. This standard “addresses good clinical
practice for the design, conduct, recording and reporting of clinical investigations carried out in human subjects to
assess the safety or performance of medical devices for regulatory purposes.” The following sections of the ISO
14155 relate to this CDISC Device standard:

• CRFs
• Device deficiencies
• Investigational device accountability

Appendix D4: Code Lists and Terminology

Beyond those defined by CDISC and managed by the NCI EVS (see Appendix A, the following code lists and
controlled terminologies may affect the structure and content of device study clinical data:

• Product Code Classification Database

http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/Overview/ClassifyYourDevice/ucm05
1637.htm
• Event Problem Codes
http://www.fda.gov/MedicalDevices/Safety/ReportaProblem/EventProblemCodes/default.htm

Appendix E: Participating Companies

Page 50 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018
These are the organizations at which the participants were working at the time the IG was developed.

Leadership Team Company affiliation

Carey Smoak Roche Molecular Systems, Inc.
Kit Howard Kestrel Consultants
Fred Wood Octagon Research Solutions
Rhonda Facile CDISC
Bob Pearsall Axon
Maureen Lyden BioStat Inc
Paul Franson Medtronic, Inc.
Jennifer Duggan St. Jude Medical
Marc Mucatel WL Gore
Parag Shiralkar Independent Consultant
Jennie Tedrow Boston Scientific

Participating Companies, Agencies and Institutions

Abbott Edwards Lifesciences
AdvaMed FDA-CBER
Alcon Labs FDA-CDER
Allergan FDA-CDRH
Bayer Genprobe
Becton Dickinson Harvard Clinical Research Institute
BioClinica Innoventz
Biomet Johnson & Johnson
Buckler Biomedical Sciences National Cancer Institute
Business Bridge PRA International
CDISC Premier Research
Cleveland Clinic Smith & Nephew
Covidien Stryker
Dexcom Synteract
eClinical Solutions Trireme Medical

Appendix F: Representations and Warranties, Limitations of

Liability, and Disclaimers
CDISC Patent Disclaimers

It is possible that implementation of and compliance with this standard may require use of subject matter covered by
patent rights. By publication of this standard, no position is taken with respect to the existence or validity of any
claim or of any patent rights in connection therewith. CDISC, including the CDISC Board of Directors, shall not be
responsible for identifying patent claims for which a license may be required in order to implement this standard or
for conducting inquiries into the legal validity or scope of those patents or patent claims that are brought to its
attention.

Representations and Warranties

“CDISC grants open public use of this User Guide (or Final Standards) under CDISC’s copyright.”

Each Participant in the development of this standard shall be deemed to represent, warrant, and covenant, at the time
of a Contribution by such Participant (or by its Representative), that to the best of its knowledge and ability: (a) it
holds or has the right to grant all relevant licenses to any of its Contributions in all jurisdictions or territories in

© 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved Page 51
December 12, 2018
CDISC Study Data Tabulation Model Implementation Guide for Medical Devices (Version 1.1 Final)

which it holds relevant intellectual property rights; (b) there are no limits to the Participant’s ability to make the
grants, acknowledgments, and agreements herein; and (c) the Contribution does not subject any Contribution, Draft
Standard, Final Standard, or implementations thereof, in whole or in part, to licensing obligations with additional
restrictions or requirements inconsistent with those set forth in this Policy, or that would require any such
Contribution, Final Standard, or implementation, in whole or in part, to be either: (i) disclosed or distributed in
source code form; (ii) licensed for the purpose of making derivative works (other than as set forth in Section 4.2 of
the CDISC Intellectual Property Policy (“the Policy”)); or (iii) distributed at no charge, except as set forth in
Sections 3, 5.1, and 4.2 of the Policy. If a Participant has knowledge that a Contribution made by any Participant or
any other party may subject any Contribution, Draft Standard, Final Standard, or implementation, in whole or in
part, to one or more of the licensing obligations listed in Section 9.3, such Participant shall give prompt notice of the
same to the CDISC President who shall promptly notify all Participants.

No Other Warranties/Disclaimers. ALL PARTICIPANTS ACKNOWLEDGE THAT, EXCEPT AS PROVIDED

UNDER SECTION 9.3 OF THE CDISC INTELLECTUAL PROPERTY POLICY, ALL DRAFT STANDARDS
AND FINAL STANDARDS, AND ALL CONTRIBUTIONS TO FINAL STANDARDS AND DRAFT
STANDARDS, ARE PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, WHETHER EXPRESS,
IMPLIED, STATUTORY, OR OTHERWISE, AND THE PARTICIPANTS, REPRESENTATIVES, THE CDISC
PRESIDENT, THE CDISC BOARD OF DIRECTORS, AND CDISC EXPRESSLY DISCLAIM ANY
WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR OR
INTENDED PURPOSE, OR ANY OTHER WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL,
FINAL STANDARDS OR DRAFT STANDARDS, OR CONTRIBUTION.

Limitation of Liability

IN NO EVENT WILL CDISC OR ANY OF ITS CONSTITUENT PARTS (INCLUDING, BUT NOT LIMITED
TO, THE CDISC BOARD OF DIRECTORS, THE CDISC PRESIDENT, CDISC STAFF, AND CDISC
MEMBERS) BE LIABLE TO ANY OTHER PERSON OR ENTITY FOR ANY LOSS OF PROFITS, LOSS OF
USE, DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, OR SPECIAL DAMAGES, WHETHER
UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS
POLICY OR ANY RELATED AGREEMENT, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE
OF THE POSSIBILITY OF SUCH DAMAGES.

Note: The CDISC Intellectual Property Policy can be found at:

http://www.cdisc.org/system/files/all/article/application/pdf/cdisc_20ip_20policy_final.pdf.

Page 52 © 2018 Clinical Data Interchange Standards Consortium, Inc. All rights reserved
December 12, 2018