Table of Contents
Device Identifier (DI) Record: Key Points
The present article addresses the matters related to the Device Identifier (DI) Record, which together with the Product Identifier (PI) creates a UDI. According to the guidance, the DI, together with associated data attributes, constitutes a DI Record in the GUDID and contains identifying information for a particular device version or model. The FDA also mentions that the clarifications provided in the guidance are applicable for both submission options (Web Interface and HL7 SPL XML file submission).
First of all, the guidance outlines the main features of a DI Record, namely:
- DI is the only element of a UDI contained in the database. At the same time, the appropriate entry would still contain references indicating the particular PI attributes contained in the label.
- Primary DI: each DI record will have a Primary DI, which is the primary key for the record, the DI of the lowest level of a medical device package containing a full UDI.
- According to the applicable regulation, each medical device model should have only one Device Identifier associated thereto. Since the identifiers could be assigned by more than one issuing agency, a party responsible for a medical device should indicate the Primary DI and Secondary DI(s) – the one issued by another issuing agency.
- Apart from the Secondary DI, the Device Identifier could contain other identifiers, such as Unit of Use DI, Direct Marking DI, and Package DI.
It is important to mention that a specific DI could be used only once – the authority additionally emphasizes that it could not be reused, even if the device it was initially assigned to is no longer available on the market. Such a device would still be listed in the database with the appropriate notice: “Not in Commercial Distribution”.
The particular information to be addressed in a DI record should be compliant with the respective regulatory requirements. The FDA also encourages laborers to provide additional information, even though such information is not mandatory.
Class I Software Medical Devices
Class I is the lowest class under the application classification system and applies to the devices with the lowest risk associated thereto. Hence, the applicable regulatory controls are quite low as well. In the case of software-based medical devices, this class applies for the devices that are:
- Intended to monitor the state or progression of a disease;
- Providing information that does not indicate if an individual may be in danger;
- Associated with a low public health risk.
Class IIa Software Medical Devices
This category applies to medical devices associated with medium risk. An example provided by the TGA describes diabetes diagnosis software that is intended to be used by a healthcare professional. Thus, such a product is a Class IIa medical device as the device provides information to a relevant health professional to inform the diagnosis of a serious disease. This category also covers risk prediction software, as well as the tools that record data from a patient monitor or images directly from an MRI scanner (provided that such software does not impact the operations of a scanner itself).
Class IIb Software Medical Devices
This category applies to medical devices associated with medium-high risk. For instance, such classification should be applied to a product that is intended to analyze a cardiac MRI in order to provide information used in making diagnoses of related diseases. As in the previous example, the software is intended to provide information to healthcare professionals only. As described in the guidance, Class IIb applies to medical software that is intended by the manufacturer (the software developer) to provide information to a relevant health professional to inform the diagnosis of a serious disease. Other examples of Class IIb products include tools intended to be used to diagnose an acute arterial occlusion due to the severity of potential consequences of this disease if the necessary treatment is not applied. This category also covers software products that are intended to provide recommendations for treatment or intervention on the basis of input data (e.g., a coronary angiogram). As in the previous cases, such software should be used only by healthcare professionals. Consequently, a Class IIb software-based medical device is the one that is intended to:
- Recommend a treatment or intervention to a relevant health professional for the purposes of making a decision about the treatment or intervention; and
- Be used in cases when the absence of a treatment or a treatment itself could result in severe health deterioration or other adverse consequences.
The same classification applies to wearable devices intended to collect and analyze data for screening for serious heart diseases, as well as questionnaire apps intended to analyze the information provided by a patient and provide a diagnostic output.
Package Information in GUDID
As prescribed by FDA legislation, it should be a specific package for each model of a medical device marketed in the US. Hence, each package configuration should be associated with the respective identifier to ensure traceability. As an example, the authority states that in case the device is supplied in several levels of packaging, separate Device Identifiers should be duly assigned to each level.
In terms of package information in GUDID the authority states the following:
- The Primary DI number for a DI record identifies the lowest level of medical device packaging containing a full UDI; also known as the base package. The Primary DI, therefore, is also the base package DI.
- The Device Count attribute provides the number of medical devices in the base package.
- Package configurations of the base package are part of the base package DI record.
- Package configurations inherit base package attribute values. Therefore, Package DIs do not need their own DI record; instead, package information may be entered in the Package DI section of the Primary DI record for that device.
About the last point, the document indicates that the mandatory attributes include Package Device Identifier, Contains DI Package, Quantity per Package, Package Type, Package Discontinue Date, Package Status.
Thus, according to the FDA guidance, an individual device package, as well as any other packaging level should have its Device Identifiers, containing information regarding respective attribute values.
Global Medical Device Nomenclature (GMDN)
As described by the FDA, each DI record in GUDID requires entry of at least one GMDN Preferred Term (PT) code. It is important to mention that the applicable regulation allows to indicate several PTs, however, such an approach should be applied only when it is reasonably necessary, while in most cases a single PT would be sufficient.
The aforementioned Global Medical Device Nomenclature is intended to facilitate the exchange of information related to medical devices by harmonizing descriptions thereof. The GMDN terms cover medical devices of all kinds and types. As further explained by the Agency, each GMDN Preferred Term (PT) has 3 components: Preferred Term Code (5-digit number), Preferred Term Name, and Preferred Term Definition. The authority also mentions that GMDN PT codes are subject to updates regularly to ensure they cover new devices appearing.
On a side note, the document mentions that GUDID is the first case when the GMDN is applied in the context of the US regulatory framework.
Thus, to ensure the accuracy of information to be included in the respective entry, an entity responsible for labeling should:
- Identify and obtain appropriate GMDN terms for devices requiring GUDID submission.
- Check the regulatory status of the device, as it could be different due to the discrepancies between the regulatory frameworks applied.
- When applying GMDN terms that are already used at the moment of submission, a responsible party should ensure their validity for submission. In particular, their status should be “active”.
Upon submission, the labeler remains to be the one responsible for ensuring continuous validity and accuracy of the information provided. Hence, GMDN terms should be subject to regular updates, should it be necessary to introduce the appropriate changes, since, at the moment, GMDN terms used in the context of the GUDID could not be updated automatically. Under the applicable regulatory requirements, an entity responsible for a medical device should amend the information provided no later than 10 business days from the date the changes occurred.
In summary, the present FDA guidance highlights the main points related to the Device Identifier and its use in the context of the GUDID. The document provides additional clarifications regarding the information it should contain and the way such information should be provided.
Sources:
How Can RegDesk Help?
RegDesk is a next-generation web-based software for medical device and IVD companies. Our cutting-edge platform uses machine learning to provide regulatory intelligence, application preparation, submission, and approvals management globally. Our clients also have access to our network of over 4000 compliance experts worldwide to obtain verification on critical questions. Applications that normally take 6 months to prepare can now be prepared within 6 days using RegDesk Dash(TM). Global expansion has never been this simple.
