CASE STUDY · DENTAL DEVICES · SAP
UDI data management with GUDI in SAP: from scattered maintenance to a controlled authority submission process
How data migration, responsibilities, approvals and submission can be connected within an existing SAP environment.
This anonymised Europe IT Consulting project description concerns a German dental device manufacturer with international sales. It focuses on UDI data for FDA GUDID and EUDAMED, reuse of existing SAP data and a traceable approval process.
The approach is an implementation of the Europe IT GUDI solution, not an isolated generic M2M interface installed at the customer. Project experience cannot automatically be transferred to other portfolios and organisations.
The starting point
The manufacturer develops and produces dental devices, including implant systems, surgical instruments and digital planning solutions. Its internationally marketed portfolio creates varied data requirements and recurring updates.
The previous approach relied on manual activities and distributed responsibilities. Product management, Regulatory Affairs and quality teams had to coordinate information across departments. At the same time, the company wanted to avoid introducing data maintenance disconnected from SAP.
The core task: make existing device information usable, distinguish shared data from authority-specific details and define which approved version may be submitted.
The target structure: connect data management and transfer
In this approach, GUDI handles UDI-specific data management within SAP. Shared information and additions for each authority are organised together with roles and approvals. An Excel import can support initial data migration without making Excel the permanent leading system.
The current product description is on the GUDI product page. Functions and authority modules configured for each project are determined from its requirements.
Implementation in four phases
Requirements and system setup
Processes, data sources and gaps were analysed at the outset. The project report describes workshops with participating departments, the focus on FDA and EUDAMED and an organisational structure by product area. This formed the implementation plan.
Data migration and quality
Existing device information was imported using structured Excel templates, checked and cleaned. The task was not just to copy fields but to map them clearly to devices and authority requirements.
Approvals and training
The project includes a three-stage approval process, training for product management, Regulatory Affairs and quality teams, and testing with realistic examples. Responsibilities needed to be understandable and workable in daily operations.
Authority process and rollout
Rollout was phased using selected device groups. Submission to FDA GUDID and EUDAMED was integrated into the configured process. The customer team needed a clear way to handle status, feedback and later changes.
The project description highlights ongoing coordination with Europe IT. Content questions, training and technical setup were handled as connected activities.
What changes in the workflow
| Starting point | Described solution approach |
|---|---|
| Repeated manual maintenance | Reuse existing data and bring UDI information together within SAP. |
| Coordination across departments | Assign responsibilities and approval steps organisationally. |
| Different authority requirements | Separate common data from additions for each target authority. |
| Changes after initial submission | Treat data versioning, revalidation, approval and transfer as a recurring process. |
| Evidence held in different places | Associate available workflow, change and submission results with the relevant data version. |
This case illustrates organisational and technical implementation. It does not promise a specific time saving, error rate or audit outcome. Measurable results require a defined baseline, measurement period and traceable data.
After go-live: the customer remains in control
In today’s GUDI process, the customer submits directly from GUDI to authorities. Submission status and authority feedback can be retrieved and displayed. The customer resolves substantive data errors and initiates resubmissions.
For documentation, approved data versions and their results should remain accessible together. The UDI Evidence Pack guide describes a possible evidence structure without assuming specific exports for every configuration.
Lessons for other projects
- Involve departments early: do not wait until the first upload to clarify data origin, responsibility and approval.
- Roll out in stages: representative device groups help check relationships and roles before wider use.
- Base training on your process: users need to know what to maintain, review, approve and correct after feedback.
- Organise data quality for the long term: regular checks and a controlled change process belong in operations.
- Assess extensions separately: additional markets, PLM connections and further analytics are separate initiatives, not automatically included outcomes.
The original report’s considerations about PLM, analytics and further markets are future possibilities. This page does not claim all those extensions have since been implemented.
A similar starting point in your SAP system?
Discuss with Europe IT which UDI data is available, where authority-specific information is missing and how validation, approval and submission should work together.
Editorial status: 4 September 2026. Anonymised case based on the existing Europe IT project publication. No attribution to a named reference customer.
