Custom medical QMS software development
A quality management system for medical devices is not a folder of approval stamps. It is the system that shows you that a complaint leads to a corrective action, that action leads to a revised procedure, and that procedure leads to retraining of precisely the people who work with it. Appfront builds such software to measure, and says so when a validated off-the-shelf package is the better fit.
Your quality system is something different from your product software
Two topics are often confused. The first is software that is itself a medical device or forms part of one. That falls under IEC 62304:2006+A1:2015 with safety classes A, B and C, is linked to ISO 14971, and follows one product through to market approval. If that is your question, go to building medical device software.
This page covers the second: the internal system through which your organisation governs its processes across all products. It exists even before a single line of product code has been written. It covers document control, complaints, CAPA, change management, training, suppliers, internal audits and management review.
Usually you need both. Your product software is assessed within the technical documentation for that product; your quality management system is assessed as a system, year after year.
The trail an auditor follows
An audit is sampling, not a check of approval stamps: the auditor picks one case and follows it through your organisation to see whether there is evidence at every link.
Take a complaint from the field. First question: is this a complaint within the meaning of the standard, or merely feedback? ISO 13485:2016 separates the two in clauses 8.2.1 and 8.2.2 and requires you to document how you make that judgement. Second question, with a clock attached: is it reportable, for which clause 8.2.3 requires a procedure? That clock starts when you become aware of it; if your complaint handling is spread across a mailbox, a service tool and a spreadsheet, that moment cannot be defended.
If a CAPA follows, it carries a root cause and an action. Suppose that action changes a work instruction: that document had a previous version on which people were trained, and clause 6.2 requires not only that you train, but that you assess the effectiveness of that training. The auditor will therefore ask who worked from the old version, who has been retrained, when, and what shows that it has taken hold. And whether the employee who joined two weeks later was ever assigned that instruction.
A single entry point for all signals, with a recorded moment of awareness.
Links back to the complaint and forward to what the action affects: procedures, risk analysis, batches.
The new version assigns training to roles, including anyone who joins later.
A scheduled task with its own evidence. As long as it is open, the file stays open.
Why CAPA files close while the problem remains
Most organisations have their CAPA process neatly described on paper. Things go wrong at almost the same point every time: the action is carried out, someone ticks that it happened, and the file is closed. What is missing is the later finding that the problem is genuinely gone. Implementation is not effectiveness. Only when that complaint category stops recurring, or a sample shows that work is being done differently, have you demonstrated anything.
Clause 8.5.2 also requires something that is often skipped: verifying that the corrective action itself does not adversely affect regulatory compliance, or the safety and performance of the device. An action that addresses one risk while introducing another is not a solution.
CAPA procedures have for years been among the most frequently cited shortcomings in FDA inspection observations, with the same thrust: closed without a substantiated effectiveness assessment. Software can enforce that by treating the assessment as a separate task rather than a field on a form.
- An assessment date separate from the implementation date
- Pre-defined evidence that must demonstrate effectiveness
- A closure rule that keeps the file open until that assessment is complete
What such a system must actually carry
The modules are the easy part; any organisation can build document control, a complaints register and a CAPA list. The distinction lies in the coherence, and in whether it holds up as people, versions and products change.
Relationships are the product
Complaint, deviation, CAPA, procedure, training assignment, supplier, batch number: each object refers to the others, in both directions. If those are typed-in text references, the trail exists only in the head of the quality manager and leaves with him.
Approval date and effective date
A document has an approval moment and a moment it becomes effective; between them sits the retraining. A system that only knows the status 'approved' cannot show who was permitted to work to which version on which day. Assign training to roles, not to a name list entered once.
Permissions, signature and logging
Who may approve is a role question, not a personal one; otherwise the system breaks down as soon as someone changes position. The audit trail records the old value, the new value, who made the change, when and why, and cannot be altered by anyone.
Data that feeds the management review
The management review requires a fixed set: complaint trends per product family, CAPA turnaround times, effectiveness reviews that are overdue, outcomes of internal audits and supplier performance. Anyone who compiles these manually from four systems is running a reporting project.
The frameworks this system must fit within
ISO 13485:2016 is the current edition, the third. In Europe, EN ISO 13485:2016+A11:2021 applies, with annexes ZA and ZB showing, clause by clause, which requirements of the MDR and the IVDR are covered fully, partly or not at all. Those annexes show where you need to do more than the standard asks.
The obligation derives from MDR (EU) 2017/745. Article 10(9) requires manufacturers to establish, document, implement, maintain and continuously update a quality management system, proportionate to the risk class and type of device, and lists what it must cover: regulatory strategy, risk management, clinical evaluation, change management, post-market surveillance and UDI.
A notified body is a conformity assessment body designated by a Member State and listed in the NANDO database; the Netherlands has four. For Class I devices without a sterile, measuring or reusable function, you declare conformity yourself; where those features apply, Annex IX of the MDR requires a surveillance audit at least annually and an unannounced audit at least once every five years. Market surveillance rests with the IGJ.
If you export outside Europe, more applies: the US Quality Management System Regulation has been in force since 2 February 2026 and incorporates ISO 13485:2016 by reference into 21 CFR part 820; through the Medical Device Single Audit Program, a single audit can serve Australia, Brazil, Canada, Japan and the United States. If your system handles patients' personal data, your GDPR compliance platform is also in play.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →The validation burden you take on
This point often comes up too late in conversations about building your own system. ISO 13485:2016 clause 4.1.6 requires you to validate the use of computer software in your quality system before it is first used, and again after changes to the software or to how it is applied, to a degree proportionate to the risk, retaining the evidence.
With a purchased eQMS, the supplier supplies much of that file. If you build it yourself, that burden shifts to you, every time a release touches a quality process. Every handy improvement to the CAPA workflow then calls for an assessment, a round of testing and documentation.
This is manageable and sometimes worth it, but it is a structural line item in your quality organisation, not a project cost. Anyone who does not plan for it will discover it during the first surveillance audit.
- Risk class per system function, with the matching depth of validation
- Test evidence at go-live and for every change that affects it
- A change procedure that determines when revalidation is required
- Validation records that outlive the system's lifetime
When custom development is not the answer
For a considerable number of medtech organisations, a validated eQMS is the more sensible choice, and it would be dishonest not to say so. Packages such as Greenlight Guru, Qualio, MasterControl, Veeva Vault QMS and Matrix Requirements are built around the structure of ISO 13485 and carry part of the validation burden. If your portfolio and processes are fairly standard, building is almost always the more expensive and slower route to the same result.
Custom development only becomes a reasonable trade-off in four situations. The first is a process that genuinely differs, for example an organisation that produces medical devices and also delivers a self-regulated service under one system. The second is heavy integration, where the record-keeping only works if the system connects with your PLM, MES, production line or requirements tooling. The third is a package that forces your organisation into a rigid mould, so that everyone builds workarounds in Excel. The fourth is being stuck on a supplier's roadmap.
There is an intermediate form that often works well: the standard package remains the record for the core processes, and custom development is limited to the part that deviates. That requires an interface that keeps traceability across the system boundary, and two environments that are both validated under 4.1.6. We therefore start with the question of where you deviate; if that shows that a package fits better, we will say so.
Frequently asked questions about medical QMS software
The questions quality managers ask just before they make a decision.
For many medtech organisations, that is indeed the better choice. Packages such as Greenlight Guru, Qualio, MasterControl, Veeva Vault QMS and Matrix Requirements are built around the structure of ISO 13485:2016 and are supplied with validation documentation. Custom development only becomes sensible if your processes genuinely differ, or if you need to integrate heavily with your own development or production systems.
You, as the manufacturer. Clause 4.1.6 of ISO 13485:2016 requires you to validate the use of computer software in the quality management system before it is put into use, and again after changes, in proportion to the risk. With a purchased eQMS, the supplier provides much of that file; if you build it yourself, you prepare it for every release that affects a quality process.
It assesses your processes, not your supplier's software. It will, however, ask for your validation file under clause 4.1.6 and for traceability: can you follow a complaint through to the effectiveness review of the related CAPA? Under Annex IX of the MDR this happens at least annually, and at least once every five years unannounced.
Usually not. Software built around processes you have not yet settled will lock in the wrong processes and become harder to change afterwards. Get your process architecture in order first, and only automate what has proven stable. If you are working towards a first certificate, you are better served by a validated standard package.
Agree in advance who owns the source code, where the validation file is held, and in what format you can extract your data, including the audit trail and the links between records. Ask for documentation that another party can read. These requirements apply just as much to a package supplier.
MDR (EU) 2017/745 Article 10 requires that technical documentation, the EU declaration of conformity and any certificates remain available for at least ten years after the last device has been placed on the market, and for at least fifteen years for implantable devices. For the system, this means exportable formats and a migration path.
Related services
These projects most often run alongside a quality management system.
Developing medical device software
For software that is itself a medical device: development in line with IEC 62304, risk management in line with ISO 14971, and technical documentation for market approval.
Building a GDPR compliance platform
If you process patient personal data, the processing register, retention periods and data breach records come into play as well: a dedicated file with its own oversight.
Discuss where your quality system differs
Tell us which processes don't fit what a standard package assumes, and which systems need to be involved. We'll go through which part you're better off buying, which part justifies building, and what the validation under 4.1.6 will require of you.