EU MIR Form 7.3.1 Mandatory Update: What Changed From Version 7.2.1 and How to Prepare

Why This Update Matters

On May 1, 2026, the European Commission's Manufacturer Incident Report (MIR) Form version 7.3.1 became mandatory for all serious incident reporting under the Medical Devices Regulation (EU) 2017/745 (MDR) and the In Vit Diagnostic Regulation (EU) 2017/746 (IVDR). The previous version, 7.2.1, which had been in use since its last update in 2020, can no longer be submitted.

This is not a cosmetic revision. Version 7.3.1 introduces new data fields, restructures existing sections, updates territorial designations to reflect post-Brexit and post-MRA realities, adds EUDAMED-compatible XML/XSD schema files, and changes how manufacturers capture the relationship between incident awareness and reportability decisions. Every manufacturer placing devices on the EU/EEA market must update its vigilance SOPs, complaint management systems, and staff training to reflect these changes.

This guide covers every substantive change between versions 7.2.1 and 7.3.1, explains the revision history and which versions are currently acceptable, details the technical requirements for working with the form, and outlines the steps manufacturers must take now to remain compliant.

Timeline and Revision History

MIR Form 7.3.1 has had a turbulent path to mandatory adoption. The European Commission originally published it on May 5, 2025, with mandatory use planned for November 1, 2025. Stakeholders quickly discovered extensive bugs in the form, making the November deadline unworkable. Multiple corrective releases followed:

Which versions are acceptable now?

As of May 1, 2026, the European Commission accepts all MIR 7.3.1 versions from the December 2025 publication (SB-10781) onward:

• December 2025 (SB-10781) -- acceptable
• March 2026 (SB-11010) -- acceptable
• April 2026 (SB-11154) -- acceptable
• May 2026 (SB-11154) -- acceptable

Versions published prior to December 2025 (the initial release and SB-10573) can no longer be used. The earlier MIR 7.2.1 is also no longer accepted.

Section-by-Section Changes

The following analysis covers each substantive change between MIR 7.2.1 and 7.3.1, organized by form section.

Section 1.2: Manufacturer Awareness Dates

The single most consequential change in 7.3.1.

In version 7.2.1, manufacturers entered a single "date when the manufacturer became aware of the serious incident." This date served a dual purpose: it triggered the reporting timeline clock and it established when the manufacturer had enough information to determine reportability. In practice, these are often different dates. A manufacturer may learn of an incident on day one but may not determine that the event is reportable until days or weeks later, after gathering additional information from the reporter, reviewing the risk file, or consulting with regulatory affairs.

Version 7.3.1 splits this into two distinct fields:

1. Date when the manufacturer became aware of the serious incident -- retained from 7.2.1. This is the date the manufacturer first received information about the event.
2. Manufacturer awareness date of reportability (new field) -- the date on which the manufacturer received the information that determined the incident is reportable.

This change implements the guidance in MDCG 2023-3 (Question 15), which clarified the distinction between awareness of an event and awareness of its reportability. The regulatory timelines for initial MIR submission (immediately for serious public health threat, within 2 days for death/unanticipated serious deterioration, within 10 days for other serious incidents) continue to run from the date the manufacturer became aware, not from the reportability date. However, the separate reportability date gives competent authorities visibility into whether manufacturers are correctly applying the reporting decision logic.

In complaint management systems (e.g., Veeva Vault, Oracle Argus), this requires adding a new "Manufacturer Reportable Awareness Date" field to case layouts and mapping it to the corresponding XML element for MIR 7.3.1 export.

Section 2.1: Device Identification -- UDI Issuing Entity

Section 2.1 now includes a dropdown field for selecting the UDI issuing entity. This is the entity designated by the European Commission to operate a UDI assignment system (e.g., GS1, HIBCC, ICCBBA). Manufacturers must select the applicable issuing entity from the dropdown.

Key notes from the helptext:

• The dropdown includes a blank option for resetting the selection.
• Select "N/A" (not applicable) for devices where no issuing entity is involved, including old devices and legacy devices that do not have a UDI.
• For legacy devices registered in EUDAMED without a UDI, an EUDAMED DI is assigned instead of a Basic UDI-DI. The issuing entity field is N/A for these devices.

Device description and nomenclature, which were previously a choice between two text fields, are now captured in separate fields, improving data consistency and enabling structured search.

Section 2.4: Regulatory and Legislative Context

Section 2.4 has been substantially expanded with new fields to capture the regulatory status of the device:

• Applicable legislation unknown -- a checkbox or indicator to note when the applicable legislation (MDD, AIMD, MDR, IVDD, IVDR) cannot be determined. This is relevant for certain legacy or borderline devices.
• Device continued to be placed on the market after the MDR/IVDR date of application -- captures whether the device was still being placed on the EU market after the relevant regulation's date of application (May 26, 2021 for MDR; May 26, 2022 for IVDR). This is critical for legacy device tracking and transition provisions.
• References to specific MDR/IVDR articles -- new fields to indicate applicability of:
  • MDR Article 52(9) (conformity assessment for class III implantable devices, other than custom-made or investigational devices)
  • MDR Article 52(10) (conformity assessment for class IIb devices other than implantable)
  • IVDR Annex IX Section 5.2
  • IVDR Annex X Section 3.k

Section 2.4 also adds new fields for the name(s) of the medicinal substance(s)/product(s), tissue(s), cell(s) of human origin or their derivative(s) associated with the device. This applies to MDR devices of all classes and IVDR class C or D devices, including companion diagnostics. For companion diagnostics, manufacturers must provide the International Non-proprietary Name (INN) of the corresponding medicinal product.

A new field asks whether a scientific opinion was requested from a competent authority or agency consulted by the notified body for conformity assessment procedures described in MDR Article 48(3) and (4) or IVDR equivalents.

Section 2.5: Market Distribution -- Territorial Changes

Section 2.5 updates the territorial designations to reflect current legal realities:

• Switzerland removed. The Mutual Recognition Agreement (MRA) between Switzerland and the EU expired. Swissmedic now operates under its own framework. Swiss incidents are reported directly to Swissmedic using the same MIR 7.3.1 form but under separate Swiss guidance.
• Great Britain removed. Post-Brexit, Great Britain (England, Scotland, Wales) has its own reporting system through the MHRA MORE portal using a GB-specific MIR schema based on version 7.2.1.
• Northern Ireland added. Under the Northern Ireland Protocol, Northern Ireland continues to follow EU MDR/IVDR vigilance requirements. Incidents occurring in Northern Ireland are reported using the EU MIR form and are included in the EEA+TR+XI geographic scope.

The geographic scope abbreviation changes from EEA+CH+TR to EEA+TR+XI (where XI is the ISO 3166-1 alpha-2 code for Northern Ireland). This change propagates throughout the form, particularly in the similar incidents section.

Section 4.1: Manufacturer's Preliminary Comments

A new question has been added to Section 4.1:

"Suspicion of a relationship between the incident and the medicinal substance(s)/product(s), tissue(s), cell(s) of human origin or their derivative(s) associated with the device?"

This field appears only when the manufacturer has answered "Yes" in Section 2.4f (indicating the device incorporates or is used with a medicinal substance, tissue, or cells of human origin). For companion diagnostics, manufacturers should select "Yes" if there is a suspicion or confirmation that the corresponding medicinal substance contributed to the incident.

The field has implications downstream: if "Yes" is selected in Section 4.1b, then a confirmation or rejection of the suspicion becomes mandatory in Section 4.2c for final reportable and combined reports. The form logic enforces this dependency -- if "No" was selected in Section 2.4f but "Yes" in Section 4.2c, the system flags an inconsistency requiring the manufacturer to reconsider their earlier selection.

Section 4.3: Similar Incidents

The similar incidents section has been restructured:

• Annex C dropdown added. The "Similar Incident Analysis Based On" field now includes a dropdown option for Annex C, in addition to the existing Annex B and Annex D options. Annex C covers evaluation/investigation codes.
• EEA+TR+XI fields replace EEA+CH+TR fields. The geographic scope for counting similar incidents and devices now uses EEA+TR+XI, reflecting the removal of Switzerland and addition of Northern Ireland.

The legacy EEA+CH+TR fields are retained in some complaint management systems for displaying historical case data and for MIR 7.2.1 profile mappings, but they are not used in MIR 7.3.1 XML export.

Mandatory IMDRF Coding

While IMDRF adverse event coding was technically expected under 7.2.1, version 7.3.1 makes it an explicit mandatory requirement:

• IMDRF Annex E codes (clinical signs/symptoms) are required for all reports (initial, follow-up, and final).
• IMDRF Annex F codes (health impact) are required for all reports.
• IMDRF Annex G codes (device component codes) are required for final reports only. When specific components do not apply to the subject device, manufacturers must select G07001 ("Part/Component/Sub-assembly Term not Applicable") rather than leaving the field blank.

The IMDRF terminologies (IMDRF/AE WG/N43) were updated on March 3, 2025, with 37 new terms added, 56 terms modified, and 8 terms retired. A further update was released on March 3, 2026. Manufacturers must use the current IMDRF terminology version.

Usability Improvements

Extra Fields Section

Starting from version SB-10781 (December 2025), the form automatically duplicates all free-text field entries into an "Extra Fields" section at the end of the PDF. This addresses a long-standing usability problem: the form's input boxes display only 4-5 lines of text at a time, even though fields allow up to 4,000 characters. Users previously had to scroll through 10-15 pages to review their entries, then scroll back to make edits.

The duplicated content at the end of the form allows users to:

• Review all free-text entries in full paragraph format in one consolidated location
• Check for typographical errors before submission
• Verify completeness without navigating between form sections

This is an automatic feature -- no user action is required to trigger the duplication.

Split-View Capability

The form can be opened in split view within Adobe Acrobat Professional. This allows users to populate the small form fields on one side of the screen while viewing the duplicated text in the Extra Fields section on the other side. The helptext (Section 7) provides step-by-step guidance on configuring split view in Adobe Acrobat.

Updated Helptext

The MIR helptext document has been expanded with two new sections:

• Section 6: List of Extra Fields -- identifies all fields that will be duplicated at the end of the MIR form.
• Section 7: Guidance for Splitting the MIR PDF with Adobe Acrobat -- explains how to configure split-screen viewing.

The helptext also includes a comprehensive mandatory-property matrix showing which fields are required for each report type (combined initial and final, initial, follow-up, final reportable, and final non-reportable).

Technical Requirements

Adobe Acrobat Professional

Adobe Acrobat Professional (not Acrobat Reader, not browser-based PDF viewers) is required for:

• Saving completed MIR 7.3.1 PDF forms
• Digital signing of the form
• XML data import and export
• Split-view functionality

Browser plugins are generally not compatible with the interactive PDF form. The European Commission recommends downloading the form to a local drive and opening it directly in Adobe Acrobat Professional. Some browser-based PDF viewers will not render interactive features at all, leading to apparent form malfunctions that are simply software incompatibility.

Password Protection

The published MIR form is password-protected. Manufacturers can request the password from the European Commission for specific authorized purposes, such as:

• Translating the form into another language
• Implementing the form into in-house complaint management systems
• Customizing form fields for internal workflows

The password request process is handled through the European Commission's health directorate-general website.

EUDAMED XML/XSD Schema Files

The European Commission publishes XSD (XML Schema Definition) and XSL (Extensible Stylesheet Language) files alongside the PDF form. These files enable integration of the MIR form structure into manufacturer complaint management and pharmacovigilance databases, such as Oracle Argus Safety, Veeva Vault Safety, or other EQMS platforms.

Key points for system integration:

• A new interchange profile (EC-MIR V7.3.1 MESSAGE TEMPLATE) is provided with default export mappings. The existing MIR 7.2.1 profile is not updated -- manufacturers with EU reporting obligations are expected to migrate to the 7.3.1 profile.
• The XSD files were not affected by the SB-11010 PDF update (March 2026), which only corrected PDF bugs. However, SB-11154 (April/May 2026) did include XSD changes: date/version reference updates and a correction to Section 4.3.1a.
• New code lists and attributes have been added for Device UDI System, Risk Class Type, Issuing Entity, and other fields.
• Several field length limits have increased. For example, "Preliminary Comments" expanded from 2,000 to 4,000 alphanumeric characters, and "Rationale for Not Reportable" from 2,000 to 4,000 alphanumeric characters.

Jurisdictional Variations

Switzerland (Swissmedic)

Swissmedic has adopted MIR 7.3.1 with its own guidance document: CH Guide MIR v3.0, effective May 1, 2026. Key differences from the EU-only workflow:

• Incidents occurring in Switzerland are reported directly to Swissmedic, not through the EU system.
• Swissmedic requires specific additional entries in certain form sections (Sections 4, 5.1, 5.2, and 5.3 of the CH Guide).
• Section 4.3.3c of the CH Guide requires specifying whether similar incident counts are cumulative and whether the figure includes the serious incident being reported. Providing this information proactively may prevent subsequent queries from Swissmedic.
• The transitional period for MIR 7.3.1 has been deleted in CH Guide v3.0, meaning the form is mandatory immediately.

Manufacturers with devices on both the EU and Swiss markets must maintain two parallel reporting pathways: one using the EU MIR form submitted to the relevant national competent authority, and one using the same form (with Swiss-specific additions) submitted to Swissmedic.

United Kingdom (MHRA)

The UK MHRA operates a separate reporting system. Key facts:

• Great Britain uses its own GB MIR schema, which is based on MIR 7.2.1 (not 7.3.1).
• Reports are submitted exclusively through the MHRA MORE portal (not by PDF email).
• The GB MIR form became mandatory on October 16, 2025, following a four-month transition period during which the EU 7.2.1 form was accepted with GB-specific data.
• Northern Ireland follows the EU system (MIR 7.3.1), not the GB system.

This means manufacturers with devices in Great Britain, Northern Ireland, and the EU must manage three distinct reporting channels with different form versions, submission methods, and territorial scopes.

Future: EUDAMED Vigilance Module and PDF Retirement

The MIR PDF form is a transitional instrument. Once the EUDAMED Vigilance and Post-Market Surveillance module becomes fully functional (expected Q2 2027), electronic submission via EUDAMED will become the only compliant route for MIR and FSCA reports under MDR and IVDR. The PDF form will be retired at that point.

This has several implications:

• Structured electronic records. Every MIR will need to be submitted as a structured electronic record in EUDAMED, linked to the device's UDI-DI and the manufacturer's Single Registration Number (SRN). Free-text PDF submissions will no longer be accepted by national competent authorities.
• System investment now pays off later. Manufacturers who invest in integrating the XSD/XML schema into their complaint management systems today will have a significantly smoother transition when the EUDAMED Vigilance module becomes mandatory, because the data structure is already aligned.
• The IMDRF coding requirement in 7.3.1 is preparation for EUDAMED. Mandatory structured coding (Annexes E, F, G) in the PDF form mirrors what EUDAMED will require electronically. Building coding discipline now reduces rework later.

What Manufacturers Must Do Now

Immediate Actions (Required Before Next MIR Submission)

1. Download the current form. Obtain MIR 7.3.1 SB-11154 from the European Commission's PMSV reporting forms page. Ensure you have Adobe Acrobat Professional installed and configured.

2. Update complaint management system mappings. If you use Oracle Argus, Veeva Vault, or another platform, install the MIR 7.3.1 interchange profile and configure the new fields: Manufacturer Reportable Awareness Date, UDI Issuing Entity, EU Market After Application Date, Device Nomenclature Code, Applicable Legislation Unknown, and associated product fields.

3. Discard MIR 7.2.1 templates. Remove version 7.2.1 from all SOPs, work instructions, and system templates. Verify that no staff member is using a pre-SB-10781 version of 7.3.1 (the initial release or SB-10573).

4. Update IMDRF code tables. Ensure your complaint management system includes the 2025 and 2026 IMDRF/AE WG/N43 terminology updates (37 new terms, 56 modified, 8 retired from the 2025 update alone).

Process and SOP Updates

5. Revise your vigilance SOP to address:

   • The distinction between "became aware" date and "awareness of reportability" date. Define who makes the reportability determination and document the decision rationale.
   • The new Section 2.4 fields for legacy devices, continued marketing status, and applicable legislation.
   • The Section 4.1 medicinal substance/tissue/cell suspicion question and its dependency on Section 2.4f.
   • Updated territorial scope (EEA+TR+XI instead of EEA+CH+TR).

6. Train vigilance staff. All personnel involved in MIR preparation, review, and submission must be trained on the new form layout, field requirements, and usability features (Extra Fields section, split view). Document the training.

7. Establish a Swiss reporting pathway if you place devices on the Swiss market. Obtain the CH Guide MIR v3.0 from Swissmedic and integrate Swiss-specific requirements into your vigilance SOP.

8. Establish a GB reporting pathway if you place devices on the Great Britain market. Ensure your team understands that the GB system uses a different form version (based on 7.2.1) submitted exclusively through the MHRA MORE portal, not by PDF email.

Strategic Preparation

9. Invest in XML/XSD integration. The XSD files published by the European Commission enable structured data exchange between your complaint management system and the MIR form. Building this integration now prepares your organization for the EUDAMED Vigilance module transition expected in Q2 2027.

10. Monitor the revision cycle. The form has been updated roughly monthly since December 2025. Subscribe to updates from the European Commission's PMSV page and from your regulatory intelligence providers to ensure you always have the current acceptable version.

Summary of All Acceptable MIR 7.3.1 Versions

All versions from SB-10781 onward share the same data structure and field requirements. The differences between them are bug fixes in the PDF form logic and XSD corrections. The XSD files from SB-11154 (May 2026) represent the current schema for system integration.

Key Differences at a Glance

Resources

• MIR 7.3.1 PDF form (SB-11154), XSD/XSL files, helptext, and changelog: European Commission PMSV Reporting Forms page
• CH Guide MIR v3.0: Swissmedic materovigilance manufacturer page (www.swissmedic.ch/md-materovigilance-manufacturers)
• IMDRF/AE WG/N43 terminologies: IMDRF website (updated March 2025 and March 2026)
• MDCG 2023-3: Questions and answers on vigilance terms and concepts
• GB MIR and MHRA MORE portal: MHRA medical device reporting pages