Services · First-time submitters, vendor transitions, and teams whose QMS has no software procedures
Quality & Compliance
The software quality system is where medical device software most often stalls. RND builds the software spine of your quality system, the IEC 62304, ISO 14971, and 21 CFR Part 820.30 procedures and records software needs, remediates the gaps QMSR exposed, and tells you exactly where your software and its documentation stand before you file. We are not a regulatory consultant: we build and verify the software and the evidence a submission relies on.
Request a readiness or QMS assessment
Two problems, one team
Most teams reach us with one of two quality-and-compliance problems: a submission coming up and no clear picture of where the software stands, or a quality system that covers the instrument and the manufacturing line but has nothing in it for software. Both are our home ground. We assess where your software stands against what FDA expects, and we build or remediate the quality system underneath it.
Where we fit
To be clear about our lane: RND builds and verifies the software and produces the software and quality-system evidence a submission relies on. We are not a regulatory consultant. Your regulatory lead, or the regulatory consultant you choose, owns the submission, the pathway, and the conversation with the FDA. Our job is to make sure the software and its documentation hold up when they get there.
FDA readiness assessment
We review the software evidence an FDA reviewer will expect to see, and tell you where it stands:
- Design controls documented to 21 CFR Part 820.30, and mapped to the QMSR alignment with ISO 13485.
- IEC 62304 software lifecycle artifacts, matched to your software safety classification and your SOUP inventory.
- ISO 14971 risk management, traced from hazards through to software requirements and verification.
- Cybersecurity against FDA Section 524B and current premarket guidance, including whether you have an SBOM.
- 21 CFR Part 11 controls where your software creates electronic records or signatures.
It comes in three tiers:
- Readiness assessment, a full review ahead of a 510(k), De Novo, or PMA.
- Technical assessment, a targeted deep-dive into a specific concern, such as software safety classification or traceability.
- Vendor-transition assessment, an independent review of software built by another vendor, with a plain-language verdict and a scope to make it submission-ready.
Software quality system remediation
Software is the core of what RND does, so building the software spine of a quality system, or remediating one with gaps, is exactly the work we are set up for. Two ways in:
- Build your own software QMS. We create the procedures and templates for software risk assessment, development, and verification, adapted to your document numbering and approval workflow, and train your team to run them after we leave.
- Assess what you have. Send us your existing SOPs and process documents and we return a prioritized findings report against QMSR, IEC 62304, ISO 14971, and 21 CFR Part 820.30, with a recommended path to close each gap.
QMSR changed who owns this
With 21 CFR Part 820 now incorporating ISO 13485:2016, software and cybersecurity activities are design controls with auditable records. A quality system that has no software risk-management procedure is now everyone’s problem, not just the software team’s. We close that gap before an audit or a submission finds it.
What you get
A prioritized, submission-ready gap list, findings mapped to the applicable regulation and a concrete path to close each one. Not a grade, and not a guarantee of any regulatory outcome: a clear account of where your software and its quality system stand, and what it takes to close the distance. It pairs naturally with independent verification and validation and, for cyber devices, the cybersecurity quality system.
- 25+
- 25+ years in business
- 15+ yrs
- Engineers average 15+ years of experience
- 2 teams · 1 QMS
- Separate development and V&V teams under one quality system
One partner, end to end
Software built alongside the instrument.
RND writes and verifies the software. Gener8 designs and manufactures the instrument, cartridges, and consumables around it, mechanical, electronics, optics, and microfluidics, under one roof. Software, device, and disposables from a single partner.
Explore Gener8 capabilitiesFrequently asked questions
- What is an FDA readiness assessment?
- It is a structured review of your medical device software against FDA expectations before you submit. RND evaluates your design controls (21 CFR Part 820.30), your IEC 62304 software lifecycle artifacts, your ISO 14971 risk management file, and your cybersecurity documentation, then returns a prioritized list of gaps and the work needed to close them.
- Does IEC 62304 apply to my device?
- If software is part of your medical device, or your product is Software as a Medical Device (SaMD), IEC 62304 applies. The assessment confirms your software safety classification (Class A, B, or C) and checks that your lifecycle documentation matches that classification.
- We have an ISO 13485 quality system but nothing for software. Can you help?
- Yes, that is the most common reason teams call us, and it is where we do our best work. Delivering medical device software is the core of what we do, so we build the software procedures, templates, and records your existing QMS is missing, adapted to your document numbering and approval workflow.
- What is QMSR and does it change our obligations?
- QMSR is the update to 21 CFR Part 820 that incorporates ISO 13485:2016. In practice it means your cybersecurity and software activities are design controls with records an auditor can ask for, a software quality system assembled once for a single submission, outside your QMS, becomes a finding waiting to happen.
- We are already working with another software vendor. Can you still help?
- Yes. A common reason teams call us is declining confidence in an incumbent vendor ahead of a submission. We run an independent technical assessment of the existing software and documentation, tell you plainly where it stands against 21 CFR Part 820.30 and IEC 62304, and scope what it would take to get it submission-ready.
- How does your work fit our 510(k), De Novo, or PMA?
- Your regulatory lead owns the pathway decision; it turns on your device's classification and predicate landscape, not on the software, and choosing it is not something we do. What we do is make sure the software evidence and documentation line up with whichever pathway you are pursuing, whether that is a 510(k), De Novo, or PMA.
Last reviewed .