swissdamed: reconcile product changes under control

1. Separate Swiss and European data flows

Swissmedic does not automatically import product data from EUDAMED. EUDAMED is also relevant for affected devices on the EU market. Define the destination systems and the person responsible for the business assessment for each product family. A shared data source can feed several outputs; approval and transfer status should remain visible for each destination. Successful transfer to one register does not demonstrate that the other has been updated. [1] [2]

2. Make the reason for change visible

Start with a concrete example from your company, such as a changed product description. Record the previous and new values, affected identifier, reason, source and owner. Regulatory Affairs assesses the affected information and downstream processes. Technical implementation follows that decision. Avoid treating a general save button as business approval. A decision not to trigger a register change should also be retrievable together with its rationale.

3. Preserve an approved baseline

Assign a system of record to each relevant field. Technical attributes may come from PLM, regulatory decisions from RIM and supporting master data from ERP. Before submission, create a clearly identified data baseline. Include approved values, the mapping used for the destination format and the approval time. Preserve that baseline in your controlled repository so that subsequent changes do not overwrite the original evidence. This also gives business and technical teams a common reference when investigating a discrepancy.

4. Test against current technical documentation

Swissmedic’s documentation lists version 2.6.0 from 1 October 2026, with changes to mandate status and an importer link. Check which functions your particular workflow actually uses. Record the specification version and test environment. Use a limited dataset and test a rejection and an interrupted transfer alongside the normal path. The central question is whether the team can unambiguously establish what has been processed. [3]

5. Distinguish submission, acceptance and reconciliation

Three states are useful for project control: submission initiated, processing confirmed and business reconciliation completed. Technical success alone does not establish the final state. Compare available destination information with the approved baseline. Record discrepancies, owners and the next review date. Before repeating an operation, establish whether the previous attempt already took effect. This prevents an unclear error from turning into an uncontrolled second operation. Agree who can authorise the next attempt and what evidence they need.

6. Accept the workflow as a team

Have business and IT owners work through one complete change case together. Check deputy arrangements, error handling and retrieval of evidence. In multilingual Swiss teams, German, French, Italian and English working documents should rely on the same approved facts. Assess the process against your own criteria, such as unresolved discrepancies and time to resolution. This organisational acceptance does not replace a product-specific regulatory assessment.

A manageable next step

Bring one product family, the relevant systems and a typical change case to an initial discussion with VALNARO. Together, we can define a limited verification path: source, ownership, approval, transfer and reconciliation. The objective is a traceable decision on the next implementation step, with clearly identified open questions and an appropriate service scope.

Explore the next steps

Sources and context