Medical software that passes review, not just review boards.
We build FDA-aware medical device software, digital therapeutics, and clinical platforms - with the design controls, risk documentation, and validation evidence your regulatory pathway requires.
Discuss your MedTech projectFDA Submissions Supported
510(k) & De Novo
Standards Coverage
IEC 62304 · ISO 14971 · ISO 13485
Post-Market
MDR reporting & PMCF
MedTech product types
Software as a Medical Device (SaMD)
AI-powered diagnostic, monitoring, and treatment-support software classified under FDA 21 CFR and IEC 62304. We build with design history files from day one.
Digital Therapeutics (DTx)
Evidence-based software interventions for disease management - from chronic condition monitoring to cognitive behavioural therapy platforms.
Medical IoT Platforms
Device connectivity middleware, remote patient monitoring, and wearable data ingestion pipelines - with real-time alerting and clinical-grade data integrity.
Clinical Trial Software
eCRF platforms, CTMS integrations, randomisation systems, and EDC tools built for GCP compliance and regulatory submission readiness.
Regulatory landscape
What each framework means for your software development process - and how we address each.
FDA
- 21 CFR Part 820 (QSR)
- 510(k) premarket notification
- De Novo classification pathway
- SaMD action plan alignment
- Predetermined change control plans
CE Mark
- MDR 2017/745 compliance
- Annex I GSPR documentation
- Notified body technical files
- UDI implementation
- Post-market surveillance plan
ISO 13485
- Quality management system
- Design control procedures
- CAPA process documentation
- Internal audit readiness
- Supplier management controls
Software as a Medical Device - classification levels
Low risk. General controls only. Most wellness apps and administrative software. Minimal FDA oversight.
Moderate risk. Special controls + 510(k) or De Novo required. Most diagnostic support AI falls here.
High risk. PMA required. Life-sustaining or implantable device software. Highest regulatory burden.
Our FDA-aware development process
MedTech tech stack
"Class II SaMD cleared via De Novo pathway - AI-powered wound assessment tool shipped in 14 months."
Full design history file, IEC 62304 documentation, and clinical validation study. Integrated with hospital EHR via FHIR. Post-market surveillance pipeline active from day one.
MedTech AI - outcomes by the numbers
14 mo
Time to De Novo clearance for a Class II AI-powered wound assessment SaMD
IEC 62304
Full lifecycle documentation coverage on every medical software project
96%
Clinical validation accuracy for remote patient monitoring alerting models
FHIR R4
All patient data interfaces built to HL7 FHIR R4 for interoperability
Safety & trust
How we de-risk medical software development
Design History File from day one
DHF maintained throughout development - not assembled at submission time. Every design decision documented with rationale, review records, and traceability to requirements.
ISO 14971 risk management
Hazard analysis and FMEA completed before architecture is finalised. Risk controls embedded in design, not bolted on in testing.
Cybersecurity by design
Medical device cybersecurity per FDA 2023 guidance. Threat modelling, SBOM maintenance, post-market vulnerability monitoring, and coordinated disclosure process.
Validation evidence packages
IQ/OQ/PQ protocols prepared for software, infrastructure, and AI model components. Evidence packages formatted for submission readiness.
Usability engineering
IEC 62366 formative and summative usability studies for any software with a user interface that could affect patient safety or clinical decision-making.
Continuous post-market surveillance
Complaint handling, MDR reporting, PMCF protocol, and periodic safety update reports managed as an ongoing service after device clearance.
Common questions
What medical device teams ask us first
When do we need to start regulatory documentation?
From the first design meeting. Design inputs, risk analysis, and architecture decisions all feed the DHF - retroactively reconstructing this from code is significantly harder and often incomplete. We structure development so documentation is a natural output of each sprint, not a last-minute task.
Can you work with our existing QMS?
Yes. We adapt our development process to your existing ISO 13485 QMS rather than imposing a new one. We provide process-level documentation in the format your quality team requires, and participate in design reviews per your procedure.
What is the difference between verification and validation for SaMD?
Verification confirms the software does what it was designed to do (unit, integration, system tests). Validation confirms it does what the user needs in the intended clinical context. Both are required, and both must be documented with protocols, execution records, and deviations addressed.
Does AI in a medical device always require a 510(k)?
Not always - it depends on intended use, device class, and the IMDRF SaMD framework classification. Many AI-assisted tools fall under Class II and require a 510(k) or De Novo. We help you determine classification before committing to a regulatory pathway.
Regulatory Engineering
We understand that in medtech, the code is only half the story. Regulatory compliance, documentation, and validation are equally critical to getting your product to market.
DHF Documentation & Validation
Complete design history files, risk management, and traceability matrices