Gap Analysis
Regulatory readiness review across classification, documentation, and QMS maturity.
Independent EU MDR consultancy · Copenhagen, Denmark
Former Notified Body assessor based in Copenhagen. One senior consultant with direct accountability from classification through NB submission — for Nordic and EU manufacturers.

6+years
Notified Body assessor
TÜV SÜD Denmark MHS & DNV
2NBs
Reviewed from inside
Know what auditors look for
7MDR codes
Active qualification scope
SaMD & software systems
1consultant
No agency hand-offs
You work directly with me
Is this a fit?
If several of these sound familiar, we should talk.
You are building SaMD, AI/ML-enabled, or software-heavy medical devices for the EU market.
You need a classification opinion you can defend — especially Rule 11 boundary cases.
You want technical documentation that survives Notified Body scrutiny, not template filler.
You need fractional PRRC coverage without hiring a full-time regulatory head.
You prefer one experienced consultant over a rotating agency team.
Quick check
Answer a few questions for indicative qualification and classification guidance — aligned with MDCG 2019-11 and related guidance.
Transparent services
Regulatory readiness review across classification, documentation, and QMS maturity.
Lean ISO 13485-aligned quality system sized for your stage and team.
Annex II/III technical files and clinical evaluation support for SaMD.
Submission readiness reviews and structured NB query response support.
Post-market surveillance design and Article 15 PRRC coverage.
Process
Classification & strategy · Intended purpose · NB selection
Documentation & QMS · IEC 62304 · Risk & cybersecurity
NB review prep · Query responses · Assessment meetings
PMS & vigilance · Change control · Fractional PRRC
Documentation lifecycle
A structured overview of the documentation lifecycle for software medical devices (SaMD) under EU MDR — from design inputs through post-market surveillance, QMS certification, and the parallel cybersecurity risk management track.
Intended use & classification
Rule 11 analysis, device scope
Applicable standards list
IEC 62304, ISO 14971, 62366
System requirements
Clinical, user & stakeholder needs
Design & development plan
Milestones and review gates
Risk management plan
ISO 14971, hazards and harms
Usability engineering plan
IEC 62366, use specification
Clinical evaluation plan
CEP, clinical strategy
Device description
BoM, drawings, labelling
Software lifecycle docs
IEC 62304, SDS, unit tests
Design FMEA
Risk control verification
Verification plans & records
Multi-level V&V protocols
Validation plan & report
Clinical environment testing
Summative evaluation
Use scenarios, hazard analysis
GSPR checklist
Annex I, applied standards
PMS plan
Post-market surveillance
PMCF plan
Post-market clinical follow-up
Clinical evaluation report
CER, literature review
Plan and report
PMS report / PSUR
Periodic safety update
PMCF report
Follow-up results
QMS development
ISO 13485, procedures, SOPs
NB stage 1 desk review
Technical file completeness
NB stage 2 onsite audit
QMS process audit
NB Q&A / negotiation
Deficiency responses
ISO 13485 certificate
QMS certification issued
CE mark certificate
Market release authorised
STED
Summary technical documentation
PRRC oversight
Article 15, ongoing compliance
Cybersecurity track
Runs in parallel across all phases
Intended use & assets
Threats and vulnerabilities
Cybersecurity risk analysis
Threat/vulnerability estimation
Risk control measures
Implementation and verification
Cybersecurity RM report
Residual risk evaluation
Post-production monitoring
Vulnerability disclosure, patches
Cybersecurity risk feeds into ISO 14971 safety risk management — adverse impacts must be evaluated jointly.
Expertise
Six years on the assessor side of the table, backed by engineering and clinical experience. Based in Copenhagen, serving SaMD and AI device teams across Denmark, the Nordics, and the wider EU.
Six years reviewing submissions at two Notified Bodies. I know which gaps stall assessments and which documentation patterns pass.
M.Sc. in biomedical engineering with hands-on firmware and DSP experience at GN Otometrics, GN ReSound, and B&O Medicom. I read your architecture diagrams.
Four years as a clinical engineer at Rigshospitalet — intraoperative monitoring during spinal surgery and hospital system rollouts. Real clinical risk context.
Background
Founder & Principal Consultant
MiBB Regulatory
Certified Technical Assessor
TÜV SÜD Denmark MHS
Certified Technical Assessor
DNV Business Assurance
Clinical Engineer
Rigshospitalet
Firmware Engineer
GN Otometrics
DSP / OS Engineer
GN ReSound
Software Engineer
Bang & Olufsen Medicom
About
I founded MiBB Regulatory in Copenhagen after six years inside two Notified Bodies — because SaMD and AI device teams across Denmark and the Nordics deserve a consultant who has actually reviewed their documentation, not just written it.
You work with me directly. No juniors, no hand-offs, no account managers.
Lean QMS, focused documentation, and clear priorities — sized for where you are, not where a Big Four firm assumes you should be.
Every output is structured the way assessors expect. The goal is submission success, not document volume.
FAQ
Straight answers to what manufacturers ask most — from classification through Notified Body submission.
EU MDR applies when software is intended for a medical purpose — defined by your intended purpose in labelling, instructions for use, and promotional material. General-purpose tools are out of scope; software that processes patient-specific data to support clinical decisions usually is. The first step is a written qualification and classification rationale before any technical documentation work begins.
Read our Rule 11 analysis →Rule 11 of MDR Annex VIII classifies software that provides information used for diagnostic or therapeutic decisions. Most SaMD falls into Class IIa or higher depending on the severity of the clinical decision and the population affected. Rule 11 is not a bright-line test — classification depends on intended purpose, clinical context, and how directly the output drives decisions. AI-enabled software that generates patient-specific outputs is almost always in scope.
Read our Rule 11 analysis →Under MDR Article 15, manufacturers must have a PRRC with the required qualifications and professional experience. For many start-ups and scale-ups, a full-time hire is not practical — fractional PRRC coverage lets you meet the legal requirement with a named, qualified person on your documentation without adding a permanent headcount.
Read our PRRC guide →From August 2026, high-risk AI system obligations apply to AI-enabled medical devices that fall under Annex III. If your device is MDR-regulated and uses AI, you likely face dual compliance under both frameworks. The good news: mature MDR documentation covers much of the foundation — but data governance, human oversight, and transparency requirements need explicit attention.
Read about the August 2026 deadline →Timelines vary by device class, NB workload, and documentation quality. Class IIa SaMD commonly takes 12–18 months from submission to certificate, but poor preparation — especially weak classification rationale, incomplete IEC 62304 evidence, or gaps in clinical evaluation — adds months of query cycles. Submission readiness review before you file is the highest-leverage step.
The earlier the better for classification and regulatory strategy — getting the intended purpose and class right before development locks in saves significant rework. For documentation and NB preparation, engage when you have a defined device and target market. For PRRC, engage before you need a named person on your declaration of conformity.
Every engagement has defined outputs — not open-ended consulting hours. Typical deliverables include classification rationale memos, technical files aligned to MDR Annex II/III, QMS procedures, NB submission readiness reviews, query response support, and fractional PRRC coverage. Scope, timeline, and deliverables are agreed before work starts.
Yes. MiBB Regulatory is based in Copenhagen and works with manufacturers across the Nordic region and the wider EU. All consultancy is delivered in English; Danish is also available. Remote collaboration is standard — most clients are outside Denmark.
Insights
Practical analysis with linked sources — plus weekly updates from EU regulators.
Before you write a single line of regulatory documentation, you need to answer one foundational question: does EU MDR apply to your software at all? Getting this wrong — in either direction — is costly.
Read article →
The EU AI Act's obligations for high-risk AI systems under Annex III apply from August 2026. For manufacturers of AI-enabled medical devices already navigating MDR, this creates a dual compliance challenge.
Read article →
Every EU manufacturer needs a Person Responsible for Regulatory Compliance — but what that means in practice, when you need one, and whether fractional coverage is legitimate are questions I hear constantly from SaMD start-ups.
Read article →
Filtered from EU health and EMA feeds. Refreshed weekly.
Last updated 13 Jul 2026
Medical Devices: Delegated acts on well-established technologies published
Read source ↗
New MDCG Position Paper: Management of SS(C)P in EUDAMED after mandatory use
Read source ↗
New guidance document on the “EU REP” symbol for authorised representatives
Read source ↗
New harmonised standards for the Regulations on medical devices
Read source ↗
Update MIR 7.3.1. form – Updated XSD-XSL files for field 4.3.3.d. and Changelog file (SB 11252)
Read source ↗
New Implementing Regulation sets out uniform requirements for conformity assessment and notified bodies
Read source ↗
Implementing Regulation (EU) 2026/977 – uniform requirements for conformity assessment and notified bodies (Annex VII)
Read source ↗
Update – Documents on European Medical Device Nomenclature (EMDN)
Read source ↗
Contact
Tell me about your device and where you are in the regulatory journey. Based in Copenhagen — available to Nordic and EU teams remotely. I will be direct about whether I can help and what the first step looks like.