Besides the interaction of the individual EUDAMED modules and the assurance of data quality within the European database, versioning in EUDAMED is one of the main challenges. Different reasons can lead to changes in the product data already stored in EUDAMED. After updating the data, the new version is shown in EUDAMED, and the versioning can be tracked. But how do companies implement the versioning of their product data? All data stored in the UDI module of the European database for medical devices need to be kept up to date at all times.
Changes to the product master data in EUDAMED, or more precisely in the UDI module, can have various causes. Theoretically, changes can already occur shortly after the manual entry or upload of the data. This is always the case when errors have crept in. However, the more likely reason for a necessary change is that, for example, the distribution markets or notes on storage have changed. When product data is adjusted, new versioning must also be assigned.
What are the options for adjusting data?
If changes have to be made to the product data in the UDI module of EUDAMED, this can be done in different ways. In all cases, it is important not to lose sight of the correct versioning for the database.
Option 1: Manual changes
Many data can easily be changed manually in the individual entry in the UDI module. But, especially in the area of quality assurance, manual changes are not easy to implement. Depending on the documentation requirements, it must be independently tracked where what was changed and when. A manual change is always a good idea if only a small number of data records are affected.
Option 2: Bulk upload
As with the initial creation of data records in EUDAMED, the changes can also be stored in the UDI module via upload as an .xml file. For this purpose, the file must contain all information about the products, including the changes and the new version number. Error messages may occur during this process. Which parts of the data set are incorrect is currently not reported back. Companies must search the errors themselves. Depending on the scope, the search can be quite time-consuming.
It is also important that the version number of the respective data set is correct. This is not automatically generated with each new upload in EUDAMED. Instead, it is stored independently in the upload file. Therefore, during the preparation of the data set, mass processing is usually not possible. For each product data record, it must be checked which version it is and whether higher versioning must be assigned. As a result, it is often necessary to go through all the data again to ensure that no detail is overlooked, resulting in errors in or due to the versioning. However, pre-validation of the master data can be a helpful tool to circumvent this issue.
Option 3: Machine-to-Machine (M2M) connection
Another option is to use an interface of a software solution. The data is not entered directly in EUDAMED, see the first two possibilities, but is managed in an external system and transferred to EUDAMED via a direct interface. Changes to the product master data are usually detected automatically in the MedTech software solutions, and the versioning is adjusted independently. Afterward, the new data record can be reported to EUDAMED via the interface (M2M) simply with one click. The data transfer into EUDAMED via an external software solution is useful if you
- need an audit trail
- need automatic tracking when reimporting data
- would like to be shown where exactly an error has sneaked into a data record
- would like to receive an automatic request for reporting to EUDAMED as soon as changes have been made to attributes
- want to have an overview of which changed/new data records have been stored in EUDAMED
- need a clear process for changes, which is also supported by the system itself.
Keeping product data up to date
Manufacturers deposit a high number of different optional and mandatory product data in EUDAMED, depending on the product. Once the data has been created, it must of course be kept up to date. After all, the public database is a reference for patients and physicians, i.e., all those who work with medical devices daily. Critical Warnings about a product or information about use and storage are examples of product data that can change over time. They fall into a special category when changes occur, as they require the assignment of a new UDI-DI, see “For which changes must a new UDI-DI be assigned?”.
How time-consuming are changes to product data in the UDI module?
Mandatory details, such as export markets, are also susceptible to change. Let’s take a concrete example: A product exists in different sizes and colors. Accordingly, several UDI-DIs refer to products of this group. If this product is not only sold in Germany but also delivered to Italy in variants 2 and 5, this must be noted accordingly in the EUDAMED. With two product variants, a manual change is not necessarily difficult to implement. However, if you have to make changes to a large number of products, for example, because the entire range is being supplied to an additional market, the manual change is not possible or is at least time-consuming. Questions that companies should ask themselves regarding versioning changes to product data in the UDI module in EUDAMED:
- How much time do I have to plan for the changes?
- How often does my product data change?
- Do I have to keep track internally, as part of quality management, of which entries I have (already) made changes to? How long do I have to keep this information?
- Is it possible to make the changes without losing track of which version number is correct for which product?
- How do I keep my tables for bulk upload so that they do not contain errors?
For which changes must a new UDI-DI be assigned?
There are two criteria where not only a change of the data stored in EUDAMED becomes necessary. Whenever a change could lead to “misidentification of the product and/or ambiguity in its traceability” (source: EU UDI Helpdesk), a new UDI-DI must be assigned.
This includes the following elements:
- product or trade name
- product version or model
- labeling as a single-use product
- sterile packaging
- need for sterilization before use
- number of individual products contained in a package
- critical warnings
- contraindications
- CMR/endocrine disruptors
The versioning of product data and the corresponding processes for documentation, or preparation of the data, are important. Especially when thinking about the long-term work with EUDAMED.
With mytracekey MedTech, we give you a suitable software solution for an M2M connection to EUDAMED, simple versioning of product master data, and a solution for product master data management that is designed for the long term.