Build vs Buy: Medical Device Complaint Handling and MDR Software

Buy: the manufacturers a configured platform serves properly

If you sell one device family into one or two markets and handle fewer than roughly a hundred complaints a year, configure a commercial quality platform and move on. Veeva Vault QMS, ETQ Reliance, AssurX, MasterControl and Sparta Systems TrackWise all model complaint records, workflows and CAPA linkage credibly, and they arrive with validation packages that shorten your own qualification effort considerably.

Buy the document control and CAPA layer in almost every case, even if you build elsewhere. That part of the quality system is well served, it is the part auditors are most familiar with seeing in a commercial tool, and rebuilding it wins you nothing beyond a validation burden you did not need.

Buy when your distribution is direct. A manufacturer selling directly to hospitals with its own field service organisation has one intake channel it controls, and the awareness date problem that drives most build cases barely exists.

Buy when your regulatory affairs function is small. A configured platform ships with a defensible default structure written by people who do this across many clients. Custom software assumes somebody owns the decision logic, and if that person does not exist, defaults are safer than bespoke.

One vendor behaviour to plan for. These platforms are usually priced per named user with modules licensed separately, and complaint handling touches far more people than quality assurance: service coordinators, distributor managers, clinical support and regional regulatory staff. The seat count that makes the business case at signature is not the seat count you need for intake to work everywhere it happens. Price the full population before you compare, because the alternative is intake staying outside the system, which is the exact failure the platform was bought to prevent.

When building is the defensible decision

The build case turns on one fact: the reporting clock starts at manufacturer awareness, including awareness through a distributor or service partner acting on your behalf, not when a complaint file is opened. Everything expensive follows from that.

The first trigger is distributed intake. If complaints arrive as service tickets, distributor emails, returned goods authorisations and sales calls, and the gap between first contact and complaint file creation is measured in days, no configuration of a quality platform fixes it, because the systems where intake happens are not systems that platform touches. A custom layer can put thin capture inside the tools people already use, propose a complaint automatically from a service ticket carrying particular fault codes, and stamp an immutable awareness date at every path.

The second is market breadth. In the United States, 21 CFR Part 803 sets a thirty calendar day report for most reportable events and a five working day report where remedial action is needed to prevent an unreasonable risk of substantial harm. Under the European Medical Device Regulation, serious incidents are reported no later than fifteen days, with ten days for death or unanticipated serious deterioration and two days for a serious public health threat. Other markets add their own. When your decision tree changes with every new registration and every competent authority view, treating it as versioned configuration your regulatory team edits beats a configuration project per change.

The third is portfolio breadth. Implants, software as a medical device and capital equipment have incompatible failure taxonomies, and forcing them into one template serves none of them.

The fourth is trending that is not real. If your failure modes are free text typed by whoever handled the case, you cannot detect a statistically significant increase in anything, and you will learn about the pattern from a regulator.

Licence, build and validation: the real numbers

Buying. Per user licensing plus module licensing plus implementation, and implementation for complaint handling is substantial because the workflows carry regulatory consequence and must be validated. Add annual uplift, add configuration work each time you enter a market or add a device family, and add the cost of the intake gap: the people who currently notice complaints late, and the exposure carried by every day of delay.

Building. A first release covering multi channel intake with protected awareness dates, device identity resolution, a versioned reportability decision record and multi market clock management runs roughly $80,000 to $170,000 across 14 to 20 weeks. A full platform adding returned device investigation, coded failure classification with trending and signal review, electronic submissions with follow up tracking, CAPA and risk file links and a distributor portal runs roughly $220,000 to $500,000 phased across 8 to 16 months.

Then validation, which is not optional and is frequently left out of quotes. This system holds quality records, so it needs its own requirements, risk assessment, traceability, executed test evidence and electronic signature controls. Budget it as a named workstream with your quality unit involved from the first requirement, and budget 15 to 20 percent of build cost annually thereafter, since every change to a validated system carries its own evidence obligation.

The hybrid usually wins on cost: keep a commercial platform for CAPA and document control, build intake, decisioning and investigation around it.

Budget lines that surprise manufacturers

Regulator submission channels. Each authority has its own format, transport and test cycle, and getting through a regulator's test environment is a scheduling problem as much as an engineering one. Treat each market's submission channel as a separate deliverable with its own timeline rather than assuming one integration covers reporting.

The follow up report nobody scheduled. The quiet failure in this process is not the initial report, it is the follow up or final report that was promised and never tracked. Make those obligations tasks with owners and due dates from the first release, because they are the ones an investigator finds by reading your own submissions back to you.

Distributor portal usability. A distributor in a market where you sell modestly might submit four reports a year, in their own language, on a mobile device. Build for that person or they will keep emailing your regional inbox and the awareness date problem persists. Language support and radical simplicity here are not polish, they are the mechanism.

Vocabulary agreement. Coded classification at three points, being reported problem, investigated device problem and patient consequence, requires quality, regulatory and clinical to agree on controlled lists. That negotiation routinely takes longer than the software that consumes it.

Historical migration. Old complaints often stay where they are, and that is usually the right decision. Moving them into a new structure can imply coding rigour that never existed.

Try reproducing one decision not to report

Pick three complaints from at least two years ago, at least one of which was assessed as not reportable, and at least one that arrived through a distributor. Then ask four questions and time the answers.

• What was the awareness date, how was it established, and can you show it was never quietly altered?
• Which decision tree version was applied, what were the answers to each question, and who answered them?
• For the distributor case, how many days passed between their first contact and your complaint file opening?
• Can you produce the full determination per market, including markets where the device was not registered and therefore not reportable?

Read the result honestly. Clean answers in under an hour means your configured platform is doing its job and a build is not the priority. If the not reportable rationale is a paragraph of free text, or the distributor gap is measured in days, you have located precisely the exposure that enforcement attention concentrates on, since findings in this area are usually about the reasoning being unreproducible rather than the conclusion being wrong.

Put the same three cases in front of any vendor. Ask how an old decision is replayed against the tree that applied at the time. Vagueness there is your answer.

Sequencing this properly from here

First, write down your reportability decision logic and get regulatory affairs, quality and clinical to sign it. This is free, it takes weeks rather than months, and it is the single fastest thing a manufacturer can do, because no build or configuration can encode a rule those three functions are still arguing about.

Second, measure the intake gap. For the last fifty complaints, record the date of first contact anywhere in your organisation and the date the complaint file opened. The distribution of that gap tells you whether your problem is decisioning or intake, and they have different solutions.

Third, if you buy, price the full population of people who touch intake rather than the quality assurance headcount, and ask the vendor how their system handles a complaint originating in a service ticket in a system they do not own.

Fourth, if you build, keep your commercial platform for CAPA and document control and scope the first release around intake, awareness dates, device identity and the decision record. That is the highest exposure and the lowest cost place to start.

On partner selection, ask what the awareness date is and how they would protect it. A developer who designs it as immutable with versioned amendment understands the system's purpose. One who treats it as a created timestamp does not. Digital Heroes works PRD first, so the decision tree model, awareness date handling and coded vocabularies are approved by regulatory affairs before development, and the validation package is planned from the first requirement rather than retrofitted. The team is 50 plus people across 2,000 plus delivered projects, holds Fiverr Vetted Pro status, and publishes to 2.5 million subscribers on YouTube. India LLP, US LLC and UK LTD entities keep contracting and IP assignment in your jurisdiction.

Own the repository and the infrastructure. Complaint records are retained for the life of the device and are the first thing an investigator asks for.

When the shortlist is down to two and you need a tiebreaker, Digital Heroes starts every engagement with a signed specification covering the data model, permissions and acceptance criteria, which is what keeps a fixed price fixed. The document is yours whichever way you go.