EU VIGILANCE · MANUFACTURER INCIDENT REPORT
MIR Reporting with GSP and GUDI: a structured incident reporting workflow
Bring case information together, check entries and organise a traceable reporting process: Europe IT Consulting supports MIR Reporting through the Global Submission Portal and through GUDI in the SAP environment.
A Manufacturer Incident Report (MIR) is a manufacturer’s report of an incident involving a medical device in the European vigilance context. It focuses on a specific case, not on registering a product master record. UDI data helps identify the product but does not replace the description and assessment of the incident.
In GSP, you work with a structured Excel template and automatic validation. GUDI provides the SAP-based approach. The reporting environment and submission method are determined according to the authority’s implementation status and your project. Your company remains responsible for content assessment and approval.
Two solutions for your MIR workflow
The decision starts with your working environment: should the vigilance team provide case information through a portal, or should the process be based in the SAP environment?
PORTAL + EXCEL
MIR in the Global Submission Portal
You enter case information in the designated Excel template. After upload, GSP checks the data for completeness and plausibility. Validation findings can be addressed before approval.
- Structured data collection instead of individually designed case lists.
- Automatic pre-validation in the portal.
- Status tracking for the configured processing workflow.
- Result files, logs and available responses in the Download Centre.
Suitable for: Teams that want to use Excel as an input format and work through a central portal.
SAP + GUDI
MIR with GUDI in the SAP environment
Europe IT also offers MIR Reporting through GUDI. This gives companies using SAP an alternative to the portal-based approach.
For implementation, we review your existing data sources, the required case information and responsibilities in the reporting process. The specific scope of data collection, checking, approval and submission is agreed for the MIR module being used.
Suitable for: Companies that want to organise the MIR process within their SAP and GUDI landscape.
Product master data alone is not enough for an incident report: case-specific information and the manufacturer’s assessment are also required.
From case information to a traceable report
A clear MIR process separates content handling, technical validation and dispatch. The sequence below is a working model, not a promise that an EUDAMED production function has already been enabled.
-
Bring case information together
Your team collects information about the affected product, the incident, the parties involved and the current investigation status. Define who reviews the content and approves the report.
-
Provide structured data
In GSP, you use the MIR template. For GUDI, data provision is defined within the SAP project. Case information is assigned to the correct report; product identification and the description of the event remain distinct.
-
Address validation findings and approve
In GSP, automatic pre-validation takes place after upload. The customer corrects content errors. Passing a technical check does not replace an assessment of reporting obligations or the manufacturer’s approval of the content.
-
Use the approved reporting route
Before dispatch, the target authority, accepted format, permissions and available environment must be clear. M2M is a technical transmission method, not content approval. Submission requires an authority connection that is actually available and configured.
-
Check results and assign follow-up work
Your team checks processing status and available responses. If corrections or resubmission are required, the customer handles and initiates them. A technical success status is not a final authority assessment of the incident.
What information belongs in a MIR?
A MIR combines administrative details, product information, the description of the incident and the manufacturer’s analysis. The exact fields depend on the report type and the applicable form or schema version. For preparation, it is useful to organise these information areas separately:
- Report and parties involved
- Case reference, report type, manufacturer and responsible contacts.
- Affected product
- Product identification and the device information needed for the case.
- Incident
- Description of the event, timing and known consequences.
- Manufacturer’s analysis
- Investigation status, assessment and other relevant information.
This structure is also reflected in the official MIR guide for the EUDAMED Playground . The guide describes the test environment; it is not evidence of a production reporting route.
MIR, UDI registration and FDA eMDR are different tasks
| Task | Subject | Starting point |
|---|---|---|
| MIR Reporting | Manufacturer’s report of an incident in the EU vigilance context. | This page |
| EUDAMED UDI/Devices | Registration and maintenance of product and UDI data. | EUDAMED UDI overview |
| FDA eMDR | Electronic Medical Device Reporting to the US FDA: a separate reporting process. | FDA eMDR data submission |
One software platform can support several of these tasks. This does not mean that data fields, formats and authority responses are identical.
Frequently asked questions about MIR Reporting
Can Europe IT support MIR through GSP and GUDI?
Yes. Europe IT offers MIR Reporting through the Global Submission Portal and GUDI. GSP uses Excel-based data collection with automatic pre-validation; the GUDI approach is implemented in the SAP context. The specific submission function depends on the agreed module scope and the available authority route.
Is a MIR Excel template the same as an EUDAMED UDI template?
No. The MIR template collects case information for an incident report. The UDI template is for product registration. The appropriate template depends on the task, not just on the authority’s name.
Which MIR version should I use?
Before using a form, check the European Commission’s official forms page. On 4 September 2026, it lists MIR 7.3.1, PDF SB 11154, and XSD/XSL files and changelog SB 11252. Accepted form versions and the software mapping used must be compatible; the version number alone is not enough.
Does the software also assess the incident itself?
Technical validation and content assessment are different tasks. Validation rules can identify incomplete or implausible entries. Your responsible specialist team must decide whether a case is reportable and what the report should contain. Software is not an automatic compliance guarantee.
Can I send real patient data for a test?
For an initial process discussion or demonstration, use anonymised sample data only. Do not send identifying patient information through the general contact form. Requirements for handling sensitive case data are clarified separately before implementation.
Does Europe IT correct content errors in the data?
The customer is responsible for correcting content. Europe IT provides the agreed software and process support. Responsibilities for feedback, corrections and resubmission should be clearly defined before use.
Official sources for preparation
- European Commission: PMSV reporting forms – access to the MIR form, guidance, technical files and change log.
- European Commission: EUDAMED overview – current module and implementation status.
- EUDAMED Playground: Register a new MIR – technical guidance for the test environment.
- FDA: Electronic Medical Device Reporting – explanation of the separate US reporting process.
You can find further starting points in our EUDAMED resource links. These sources describe authority requirements; they do not certify Europe IT solutions.
How should your MIR process work?
Tell us about your working environment, intended reporting route and whether you want to use GSP or GUDI. Together, we clarify the available case information, appropriate module scope and steps needed before use.
To get started, information about your system landscape, target countries and process is sufficient, without confidential case data.
