Your MD / non-MD status stays unclear, and every decision becomes a gamble.
Hesitation on status, MDR or IVDR class, CE marking pathway. Without a clear foundation, obligations, first steps, and priorities stay open.
Service · Regulatory strategy
The right regulatory course, before the file.
MDR/IVDR classification and CE pathway, clarified.
A prioritized roadmap before the file.
30-min call · no commitment
They trust us.
+35 projects accompanied.
The problem we solve
Without a clear regulatory path,
every choice is a gamble
For manufacturers of software and AI systems in healthcare, the fog starts before the technical file: MD vs non-MD status still open, generic advice that doesn't fit the product, tech choices made without MDR/IVDR or AI Act safeguards. The stakes are the same: set the frame before the roadmap is built backwards.
Generic advice ignores your architecture, use cases, and maturity.
Every medical software product is unique: architecture, risks, maturity stage. A one-size model for all SaMD gives neither direction nor actionable priorities.
Tech moves ahead without MDR / AI Act safeguards, and the file costs you later.
Shipping fast without anticipation creates detours toward the technical file. Uses, data, product logic, and AI need to be challenged now, not after.
Our approach
We challenge in the workshop.
We formalize the report.
Two complementary levers: a session to set status, classification, and structural choices on your product, then a strategy report that locks the course before you commit file and teams.
How we deliver
The regulatory workshop
Challenge session (~2 h) with your product, tech, and clinical teams. We anchor the frame in your architecture, use cases, and maturity.
You leave with
The regulatory strategy report
A structured write-up: product analysis, target markets, operational recommendation, and the quality deliverables to build next.
This framing is the entry point to our Programme PULSE (CE marking offer).
They clarified their path with us
From confusion
to a trajectory
Alexandra (QARA PULSE) brought real clarity to our regulatory positioning. A highly professional, structuring exchange, adapted to our operational reality and proportionate for our organization.
As an early-stage medtech startup, regulation can quickly become a wall. Alexandra and QARA PULSE turned that wall into a roadmap. If you are a medtech looking for a regulatory partner, not just a vendor, go with QARA PULSE.
What comes next
From framing
to operational compliance
CE marking · Programme PULSE
ISO 13485 QMS, technical file and support through the notified body.
eQMS deployment
Digital QMS in Notion, Atlassian (Jira / Confluence), GitHub or GitLab.
Internal audit
ISO 13485, MDR / IVDR checkpoint to secure the rhythm before external review.
Qapsule
If the foundation is in place: continuous compliance in your tools (does not replace eQMS).
FAQ
The first questions we get asked.
Is my software a medical device under the MDR?
It depends on the claimed medical purpose (diagnosis, monitoring, treatment, and so on), not on being "health" software alone. We anchor the analysis in your architecture, intended use and maturity, then formalize the medical device qualification — medical device or not. That framing avoids building a file on the wrong foundation.
How do you classify medical software under MDR Rule 11?
Once the software is recognized as a medical device, Rule 11 sets its class (I, IIa, IIb or III) based on the intended purpose and the risk linked to the information provided.
For diagnostic or therapeutic decision support, you move up to IIa, IIb or III depending on how serious the possible consequences are. Monitoring physiological processes generally leads to IIa, or IIb for critical vital parameters. Some software remains class I.
Class drives the QMS, the technical file, clinical evidence and whether a notified body is required. A strategy workshop helps apply this framework to your product.
Should we plan for the AI Act together with the MDR for health AI software?
Yes when the AI has a medical purpose: MDR and the AI Act stack; neither replaces the other. We challenge use cases, data and product logic early to avoid costly detours at file time. The roadmap prioritizes what actually blocks the CE path.
What does a regulatory strategy report include before the technical file?
A structured readout: product analysis, target markets, MDR/IVDR classification (and AI Act if relevant), priorities and quality deliverables to build. It is the entry point before committing the file and teams, notably toward Programme PULSE (CE marking).
Ready to clarify your regulatory strategy?
30 minutes to set the right regulatory course.