QMS vs Post-Market Surveillance Platform: What MedTech Teams Get Wrong About This Decision

What an eQMS was built to do

Electronic Quality Management Systems emerged as digital replacements for paper-based quality documentation. Their core functionality addresses the quality management requirements defined in ISO 13485, FDA 21 CFR Part 820 (and the forthcoming QMSR alignment with ISO 13485), and EU MDR Annex IX quality management system requirements.

Document control is the foundation. Version management, review and approval workflows, controlled distribution, and retention of SOPs, work instructions, specifications, and design files. Every eQMS does this well because it is the original problem these systems were built to solve.

Training management tracks who has been trained on which procedures, schedules recertification, and maintains the compliance records that auditors review during inspections. This is tightly connected to document control because training requirements change when documents are revised.

Design controls manage the product development lifecycle: design inputs, design outputs, design verification, design validation, and design transfer. The design history file (DHF) is maintained within the eQMS as the authoritative record of how the device was developed.

Audit management covers internal audit scheduling, finding documentation, CAPA tracking, and corrective action verification. This includes both internal quality audits and preparation for external audits by Notified Bodies and regulatory authorities.

These are legitimate, necessary capabilities. If your primary challenge is managing quality documentation and maintaining ISO 13485 compliance across pre-market processes, an eQMS is the right tool. The question is whether it is the right tool for what happens after the device reaches the market.

‍

Where eQMS platforms reach their architectural limit

An eQMS treats a complaint as a quality event within the quality management system. It creates a record, assigns an investigator, tracks the investigation to closure, and links it to a CAPA if warranted. That workflow handles individual complaint management adequately.

1. Post-market surveillance is not about individual complaints. It is about what complaint data tells you in aggregate across products, across time periods, across jurisdictions, and across the entire device portfolio. This requires capabilities that eQMS platforms were not designed to provide.
2. Regulatory reporting is absent or disconnected. When a complaint triggers an MDR under 21 CFR Part 803, someone on the Regulatory team has to leave the eQMS, open a separate reporting tool (historically the FDA's eSubmitter, now transitioning to ESG NextGen API submissions), re-enter data from the complaint record, write a narrative from scratch, and submit through a channel the eQMS does not connect to. The complaint and the MDR live in different systems. They are not linked. When the same event triggers reports in multiple jurisdictions (FDA MDR, EU MIR, Health Canada CVR), the manual effort multiplies for each market.
3. PMS report generation does not exist. A PSUR under EU MDR requires complaint trend data, adverse event summaries, investigation outcome analysis, risk management inputs, and literature review findings compiled into a structured report. An eQMS stores complaints but does not calculate trend rates, aggregate adverse event data across reporting periods, or generate formatted reports from that data. Someone on your team exports data to Excel, builds pivot tables, writes narrative sections manually, and assembles the report over 100 to 200 hours.
4. Recall management is not included. When a field safety corrective action is required, an eQMS can generate a CAPA. It cannot track affected lot numbers across the distribution chain, send notifications to hundreds of healthcare facilities, monitor acknowledgement responses, or provide a portal where recipients confirm receipt. That workflow requires either a separate system or a spreadsheet and a significant amount of manual coordination.
5. IMDRF coding is treated as a text field rather than an intelligent classification system. eQMS platforms store whatever code the specialist enters. They do not suggest codes based on event descriptions, validate code consistency across the complaint portfolio, or sync codes bidirectionally with regulatory reports. The 9% mismatch rate between complaint codes and MDR codes that one Smarteeva customer identified before implementation is typical of organizations relying on eQMS text fields for classification.
6. Signal detection requires external analysis. Identifying emerging safety signals from complaint patterns requires trending algorithms, threshold alerts, and the ability to compare complaint rates across products, time periods, and event types. An eQMS provides complaint records. Turning those records into safety intelligence requires exporting data and analyzing it outside the system.
7. Complaint-adjacent operational functions are completely absent. A complaint does not end with investigation and closure. It triggers customer follow-ups to communicate resolution back to the reporter. It triggers sales follow-ups when the complaint involves a commercial relationship that needs attention. It generates credit memos when the complaint results in a return or financial adjustment. It creates regulatory requests when authorities ask for additional information about a reported event. It requires risk assessments that evaluate how the complaint event affects the device’s overall risk profile under ISO 14971. These functions are part of every complaint lifecycle, and they are seldom handled within the QMS. An eQMS stores the complaint record. The customer follow-up happens in email. The credit memo happens in the ERP. The sales follow-up happens in the CRM. The risk assessment happens in a separate document. None of these are connected to the complaint record, which means none of them is traceable from the complaint file during an audit.

What a purpose-built PMS platform does differently

A post-market surveillance platform starts where the eQMS stops. It assumes that complaint data is the beginning of a regulatory and surveillance workflow, not an isolated quality event.

The architectural difference is that a PMS platform connects complaint records to every downstream process: IMDRF coding, reportability assessment, regulatory form assembly, submission, PMS report generation, recall notification, and trend analysis. These are not separate modules bolted onto a document management system. They are workflows that operate on the same data model.

Smarteeva is built natively on Salesforce. Complaint records, device master records, customer records, reporter information, IMDRF codes, regulatory reports, investigation findings, and recall notifications all exist in a single environment. Because the platform runs on Salesforce, the operational functions that eQMS platforms cannot reach are native: customer follow-ups are tracked against the complaint record, sales follow-ups link to the commercial account, credit memos connect to the financial workflow, regulatory authority requests are documented in the complaint timeline, and risk assessments reference the complaint data directly. There is no export step between the complaint and the MDR. There is no reconciliation step between the complaint count and the PSUR trend data. There is no separate system for recall notification tracking or customer communication.

The practical impact is visible in the numbers. AI-powered complaint intake processes unstructured emails in under 60 seconds with 96% first-pass accuracy. IMDRF codes are suggested at the point of intake with ranked confidence scores. MDR forms are pre-populated from connected data and submitted directly to the FDA via the ESG NextGen API in 3 minutes. PSURs are generated from the connected data model in 8 minutes. Recall notifications are tracked across 100,000+ recipients with acknowledgment monitoring.

35% of all FDA MDRs are filed through Smarteeva. 50,000+ users across 80+ countries rely on the platform for post-market surveillance. These numbers reflect what happens when the post-market workflow runs in a connected system rather than across disconnected tools.

When an eQMS is not sufficient

An eQMS was never designed to run post-market surveillance. The question is not whether your eQMS can handle complaints. The question is whether it can do anything useful with complaint data after it captures it. If you sell one device in one market, file fewer than 10 regulatory reports per year, and have someone on your team with the capacity to assemble PMS reports manually in Excel, an eQMS will get you through. It will log the complaint. Your team will do everything else. That works until it does not.

The moment it stops working is when your team spends more time moving data between systems than analyzing it. When your Regulatory specialist is copying fields from the eQMS into a separate MDR tool for the third time this week. When a single complaint triggers reports in four jurisdictions and each one requires a different form filled out from scratch. When your PSUR takes six weeks to assemble because the complaint data, adverse event data, and risk data live in three places that do not talk to each other. When complaint volume grows past what your team can process manually, and the only option your eQMS gives you is to hire another person to do data entry.

At Smarteeva, our position is straightforward: keep your eQMS for what it was built for. Post-market surveillance is a different discipline with different data requirements, different regulatory outputs, and different operational demands. It deserves its own platform. Smarteeva owns everything that happens after the device reaches the market.

‍

‍

‍