You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

  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 applicant 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 applicant 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). Applicants 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 applicant 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 applicant 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. 

    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), TOBA-517 - Getting issue details... STATUS 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. Applicants 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). 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.
  • No labels