MDR/IVDR MIR vigilance workspace
Build a narrow serious-incident operations room for small medtech manufacturers, authorised representatives and specialist regulatory consultancies managing EU MDR/IVDR vigilance intake, reportability decisions, MIR 7.3.1 readiness, follow-up reports, authority questions and evidence handoff.
This is a credible, narrow opportunity if it is positioned as vigilance incident-ops around the MIR, not as a general QMS, PMS, PSUR or regulatory-information-management platform. The strongest signal is first-party: the European Commission says the new MIR PDF 7.3.1 is mandatory from 1 May 2026, accepts only December 2025-or-later 7.3.1 versions until further notice, and says pre-December 2025 MIR 7.3.1 versions can no longer be used. That creates a forcing function for anyone still running vigilance through old forms, local spreadsheets, consultant email threads, and ad hoc evidence folders.
The product gap is not “submit the official report for me.” The useful job is before, around and after submission: capture the event, determine whether it may be a serious incident, collect device/UDI/operator/patient/outcome fields, coordinate the manufacturer/AR/consultant/authority handoff, maintain the right MIR version, preserve why an event was reportable or non-reportable, manage initial/follow-up/final report loops, and export an evidence pack that survives audit and consultant turnover.
The wedge is strongest for repeat operators: EU authorised representatives, boutique vigilance consultancies, regulatory affairs freelancers, and small manufacturers with several devices but no mature enterprise postmarket stack. Direct one-device manufacturers may have painful incidents but episodic software demand; consultants and ARs repeat the workflow across clients and can buy margin protection.
Best initial buyer: EU authorised representatives and specialist MDR/IVDR vigilance consultancies serving non-EU or small EU manufacturers.
Why this is better than selling only to manufacturers:
Secondary buyer: small medtech and IVD manufacturers with lean RA/QA teams, multiple EU-listed products, and enough complaints/vigilance exposure to maintain internal readiness. These buyers may already have a QMS, but still need a practical MIR-specific operating layer.
Weak ICP: enterprise medical-device manufacturers with established systems such as MasterControl, Veeva, ArisGlobal-style safety systems, TrackWise, or heavily configured eQMS/RIM stacks. They may like the checklist logic but are more likely to implement it internally.
The first pain signal is the regulatory forcing function. The European Commission PMSV reporting forms page states: “MIR PDF 7.3.1 (update 7 May 2026),” “New MIR form - mandatory as from 1st May 2026,” and “MIR form 7.3.1 versions published prior to December 2025 (SB 10781) can no longer be used.” It also lists December 2025, March 2026, April 2026 and May 2026 7.3.1 versions as acceptable until further notice. That is a very practical operations problem: teams must know which form/template they used, which incident files need migration, and which client/procedure work instructions still point to stale form versions.
The second pain signal is deadline complexity. MDCG 2023-3 rev.2 says serious-incident reporting timelines are calendar days beginning from the manufacturer’s awareness of a potentially serious incident. It describes reporting no later than 15 calendar days for serious incidents, no later than 10 days for death or unanticipated serious deterioration, and no later than 2 days for a serious public-health threat. It also clarifies that if an incident was initially assessed as non-reportable but later information changes reportability, the reporting period begins when the manufacturer receives the information that makes the incident reportable. This maps directly to a workspace feature: awareness-date capture, reportability rationale, deadline calculator, late-risk warnings, and a history of what information changed the assessment.
The third pain signal is cross-party intake. MDCG 2023-3 explicitly treats information sources as broad: healthcare professionals, patients/users, competent authorities, economic operators such as authorised representatives, importers or distributors, and the manufacturer’s own post-market surveillance/post-market clinical follow-up/post-market performance follow-up activities. That means the “incident file” is rarely born cleanly inside one system. It can start as a complaint email, distributor escalation, AR message, authority query, PMCF/PMPF finding or support ticket. A narrow workspace can be the intake bridge from messy external signals into a MIR-ready record.
The fourth pain signal is the MIR form itself. The MIR 7.3.1 helptext is not just a simple PDF instruction sheet; extracted text runs over 100k characters and covers helptext, rules, EMDN coding, IMDRF adverse-event terminology, risk class and notified-body properties, XML field maps, extra fields, and even guidance on splitting the PDF. It warns users to follow the form numbering top-down, notes free-text field limits, defines initial/follow-up/final/combined report types, and contains field-by-field mandatory-property tables. That complexity is well suited to form-readiness checks, not legal advice.
The fifth pain signal is follow-up and authority continuity. The MIR helptext includes fields for NCA reference numbers, EUDAMED reference numbers once available, report submission dates, report type, initial/follow-up/final statuses, manufacturer contacts, authorised representative contacts, device identifiers, UDI-DI/EUDAMED IDs, IMDRF codes and supporting data. Emergo’s EU vigilance service page describes the real workflow as: determine timeline under MDR Article 87/IVDR Article 82, complete the MIR and submit to the competent authority, respond to authority questions about devices/time on market/design changes, determine whether an FSCA is necessary, submit final MIR or FSCA reports, and add vigilance reports plus evidence to the QMS. That sequence is an operations workflow with ownership, evidence and version-control problems.
The sixth pain signal is that existing public guidance and services focus on compliance expertise, not lightweight coordination. MDSS tells manufacturers and authorised representatives to align vigilance procedures, internal workflows and IT systems with MIR 7.3.1. Emergo offers vigilance/incident-reporting services. SimplerQMS and Greenlight Guru frame complaint handling, PMS, CAPA and vigilance inside broader eQMS. MasterControl sells broad medical-device reporting and postmarket software. These validate budget and seriousness, but leave room for a narrower client-facing incident workspace for teams that do not want to buy or configure an enterprise postmarket suite.
1. MIR 7.3.1 cutover. The 1 May 2026 mandatory date and deprecation of older 7.3.1 publications create a near-term reason to update SOPs, templates, client checklists and training.
2. EUDAMED transition pressure. The Commission says EUDAMED has six modules including Vigilance and post-market surveillance. Its overview says the first four modules become mandatory from 28 May 2026 after a November 2025 functionality notice; the Vigilance module is still part of the eventual operating environment. MIR helptext already references EUDAMED incident reference numbers that will become mandatory as soon as available. Teams need a bridge that works now and can track future EUDAMED identifiers later.
3. MDCG guidance revision. MDCG 2023-3 rev.2 adds and clarifies reportability concepts, awareness-date handling, and MIR 7.3.1 field references. That gives a product concrete, current rules to encode.
4. Small teams are under-tooled. The broad eQMS market is mature, but many small manufacturers, ARs and consultancies still use email, PDF forms, Excel trackers and shared drives for the high-stakes part of vigilance. A narrow tool can land as “MIR incident room” rather than “replace your QMS.”
Build the smallest version as a hosted or single-tenant MIR 7.3.1 incident room for consultancies/ARs handling client matters.
Core objects:
MVP workflow:
1. AR or consultant opens a client incident room from a “MIR 7.3.1 serious incident triage” template.
2. Client/distributor enters the event through a guided intake link.
3. Workspace calculates deadline scenarios from awareness/reportability dates and highlights missing fields needed for initial MIR.
4. Consultant assigns device, clinical, complaint-investigation and manufacturer-contact tasks.
5. System creates a MIR readiness checklist and records the version used.
6. Consultant exports a competent-authority submission pack and later appends follow-up/final-report evidence.
Do not build direct submission to competent authorities or EUDAMED first. Do not promise reportability determinations. Start with readiness, tasking, evidence custody, deadline/rationale tracking and export packs.
Start with firms that already publish or sell EU authorised-representative, UK responsible-person, importer, vigilance or MDR/IVDR consulting services. The pitch is operational:
Practical GTM:
| Substitute | What it covers | Gap for this wedge |
|---|---|---|
| Email + Excel + PDF MIR + shared drive | Default small-team workflow; flexible and cheap | Weak version control, deadline logic, missing-field checks, follow-up continuity and evidence custody. |
| Consultants / authorised representative services | Expertise, regulatory interpretation, submission help | Validates budget; tool can make the service repeatable, auditable and client-facing. |
| Broad eQMS platforms (Greenlight Guru, Qualio, SimplerQMS, MasterControl, TrackWise-type systems) | Complaint handling, CAPA, document control, quality events, sometimes adverse-event reporting | Too broad/heavy for AR/client incident coordination; may not be MIR 7.3.1-specific or consultant-client oriented. |
| Regulatory intelligence / RIM suites | Enterprise regulatory data and submissions | Overkill for small manufacturers and ARs needing one incident room and evidence pack. |
| EUDAMED / competent authority portals | Official regulatory interaction where available/applicable | Not the pre-submission client evidence room; MIR helptext still references fields and evidence teams must assemble before/after official submission. |
| Custom SharePoint/Teams workflows | Familiar collaboration, documents, approvals | Requires each consultancy to rebuild MIR-specific checklists, clocks, role rules and audit logs manually. |
The main competition is not a named startup; it is “good enough” consulting labour plus spreadsheets. That is both the opportunity and the risk.
Pursue as a consultant/AR-first MIR 7.3.1 incident workspace, not a manufacturer-only QMS module. The first product should make a single serious-incident file easier to intake, triage, evidence, version, hand off and close across initial/follow-up/final MIR reports. The cutover to MIR 7.3.1 creates timely outreach, while the durable value is repeatable vigilance ops for service providers who manage many small manufacturers.
The biggest uncertainty is demand density. Serious incidents are urgent but not always frequent for a single small manufacturer, so a standalone SaaS may churn unless sold to ARs/consultancies or bundled with broader complaint/vigilance SOP support. Public pain-language evidence is thin; regulatory professionals do not usually complain about MIR workflows in open forums, so the argument relies heavily on official complexity, service-provider pages and substitute analysis. The opportunity may also be absorbed by existing eQMS vendors if they add MIR 7.3.1 templates quickly. Finally, the product will touch sensitive health and device data, which makes procurement, hosting, validation and liability harder than the narrow MVP might imply.
A MIR 7.3.1 serious-incident operations room for EU authorised representatives, vigilance consultancies and lean medtech manufacturers managing reportability, evidence, deadlines, follow-up reports and authority handoff.