This is a wiki version of the documentation that is expected to be added to the SDTM model and the SDTM Implementation Guide for Medical Devices.
For inclusion in SDTM:
Definition
RELDEV is a relationship table that allows devices and their components to be related to each other. The structure permits the relating of multiple components to one parent device. Components can also have components, meaning that a component can also function as a parent. There is theoretically no limit to the number of levels of components associated with a given parent.
Specification
reldev.xpt, Device Relationships. One record per device relationship.
Variable Name | Variable Label | Type | Controlled Terms, Codelist or Format | CDISC Notes | Core |
STUDYID | Study Identifier | Char |
| Unique identifier for a study. | Req |
SPDEVID | Sponsor Device Identifier | Char |
| Sponsor-defined identifier for a device. | Req |
PARENT | Device Parent | Char |
| Identifies the parent device or collection of which the device is a part. PARENT is null for devices at the highest level. | Exp |
LEVEL | Device Level | Num |
| Identifies the component level for the device in numeric format, with the highest level being represented by 1. | Req |
Additional Materials for inclusion in SDTMIG-MD:
Assumptions
- There must be at least one record with LEVEL =1 in the table, meaning there must be at least one parent, as the purpose of the table is to relate components to their parent device(s).
- Every device that appears in the PARENT column must also appear as an SPDEVID, but not every SPDEVID must be a parent, as some components can be just components and not parents to other components.
- Other identifiers, such as USUBJID, would generally not be used in RELDEV as it is about relating parts of devices to each other independently of any subject. Associations among devices, components and subjects would be expected to appear in DR, DX or potentially other domains.
- It is theoretically possible to have one component associated with multiple parents.
- There is no inherent requirement determining when components should be defined and related to parent devices. It is determined by whether the components are referenced separately from the device as a whole in the protocol. For example, if one study needs to track pacemaker leads separately from the pacemaker generators, then RELDEV should be used to associate the leads with the generator. If the entire pacemaker is treated as one unit and leads are not referenced separately from the generator, then no RELDEV is necessary, and just identifying the overall device in DI is sufficient.
- The number of levels of components is determined by the level of granularity required in the protocol.
- There are cases where determining what constitutes a parent vs a component can be ambiguous. For example, an ECG machine and the associated analytical machine and its software are used together, so it might make sense to treat them as a single unit (requiring no RELDEV). However, if there is a need to track software updates over time, it may make sense to treat them as 2 components of an overall device.
- When evaluating the relationship to the device and actions taken with the device with respect to adverse events, the sponsor determines the level at which the device/components are assessed. For example, if a study is using a pacemaker comprising a generator with 2 leads, the sponsor may choose to evaluate each adverse event against the device as a whole (the parent), or against each individual component (generator, lead 1, lead 2). It would be determined by how the device data are being analyzed (e.g,. safety events summarized for the whole event, or differentiating between generator and leads).
Examples
Example 1
Row 1: Identifies the MRI and its workstation together as the parent, or upper level, device.
Row 2: Relates the MRI machine to the combined device.
Row 3: Relates the workstation to the combined device.
Row | STUDYID | SPDEVID | PARENT | LEVEL |
1 | YEWK | MRIWRK | 1 | |
2 | YEKW | 9438-23U | MRIWRK | 2 |
3 | YEKW | MR9438 | MRIWRK | 2 |
Example 2 (Note: typographic variations in the variable values are solely for ease of reading the example, and would not be used in actual study data).
Row 1: Identifies a complex device (LSKDH23).
Rows 2-3, 9: Identify the individual devices which collectively make up LSKDH23.
Rows 4-6: Identify the components of 29384LHS, which is itself a component of LSKDH23.
Rows 7-8: Identify devices at the fourth level which make up 389EW, which is a component of 29384LHS (which is a component of LSKDH23).
Row 10: Identifies another complex device (24398HAS).
Rows 11-12: Identify the pieces of 24398HAS.
Row | STUDYID | SPDEVID | PARENT | LEVEL |
1 | YARRR | LSKDH23 | 1 | |
2 | YARRR | 237YALU | LSKDH23 | 2 |
3 | YARRR | 29384LHS | LSKDH23 | 2 |
4 | YARRR | 242TT | 29384LHS | 3 |
5 | YARRR | O8234 | 29384LHS | 3 |
6 | YARRR | 389EW | 29384LHS | 3 |
7 | YARRR | P1R473-1 | 389EW | 4 |
8 | YARRR | P1R473-2 | 389EW | 4 |
9 | YARRR | 8HAWER | LSKDH23 | 2 |
10 | YARRR | 24398HAS | 1 | |
11 | YARRR | 238LH2 | 24398HAS | 2 |
12 | YARRR | D82B39 | 24398HAS | 2 |