+86 16650237703
Author:Kangdi 28-10-2026
Post-Market Surveillance 2026: What Pain Patch Brands Must Report, and to Whom
Wondering what post-market surveillance actually requires of a pain patch brand, and where the data is supposed to come from? This page is a working reference for the PMS obligations that apply to a pain patch in the five main markets: what a PMS plan must contain, what a PSUR or PMCF report must say, which markets require periodic reporting versus event-triggered reporting, and the data-collection design that makes the whole system survivable. It is built for regulatory leads and quality managers who have to produce these documents, not for people writing a strategy memo.
By the end of this page you will know the 4 components of a PMS system and which one is usually missing, the 5-market comparison of reporting obligations, the 3 report types and their cycles, and the 6 data sources a pain patch brand needs to have wired before the first shipment.
There is a structural problem in this category that is worth stating before the requirements, because it explains why so many PMS systems exist on paper and fail in practice: a pain patch brand usually does not own the point of contact with the consumer. The pharmacy chain receives the complaint. The distributor handles the return. The marketplace aggregates the review. The brand, which is legally responsible for the PMS report, is two or three steps removed from the events it is required to analyse. A PMS system that does not solve this data-access problem is a template exercise, and a regulator who asks "show me the complaint trend for this SKU" will discover that within one request.
Bottom line. PMS is not a document you write when a regulator asks. It is a data-collection design that has to be wired into your distribution agreements, your complaint channel, and your batch records before the first shipment. The four components are a plan, a data pipeline, a review cycle, and the reports. Most brands have the plan and the reports and are missing the pipeline, which is why the reports turn out to be composed of anecdote rather than data. Fixing the pipeline costs one clause in the distributor agreement and one form in the customer service process, and it takes about a month to put in place.
Table of Contents
- The 4 components of a PMS system, and which one is usually missing
- The 5-market comparison of reporting obligations
- The 3 report types and their cycles
- What a PMS plan must actually contain
- The data pipeline: 6 sources to wire before the first shipment
- Complaint coding: how to make the data analysable
- The trend analysis that regulators actually look for
- PMCF for pain patches: what is proportionate
- The 7 PMS failures that show up in inspections
- FAQ: PMS questions pain patch brands ask most
- About Kangdi Medical and our PMS data support
1. The 4 Components of a PMS System, and Which One Is Usually Missing
A functioning PMS system has four components. Three of them are documents and one of them is an operational process, and the operational one is the one that is almost always missing.
| # | Component | What it is | Typical state in a pain patch brand | What "good" looks like |
|---|---|---|---|---|
| 1 | PMS plan | A document defining what data will be collected, how often, by whom, and how it will be reviewed | Usually present, usually generic, usually copied from a template | Names the data sources, the review cadence, the named owner, and the thresholds that trigger an escalation |
| 2 | Data pipeline | The operational mechanism by which complaint, return, and adverse event data reaches the brand from the channel | Frequently missing. The brand relies on the distributor to forward complaints "if something serious comes up" | A defined form, a defined timeline, a named contact at each distributor, and a monthly summary obligation |
| 3 | Review cycle | A scheduled review of the collected data against the plan, with documented conclusions | Usually happens only when a report is due, which means the review is written backwards from the conclusion | A quarterly review with minutes, a trend chart per SKU, and a documented decision on whether any action is required |
| 4 | Reports | The PSUR, the PMS report, the trend report, or whatever the market requires, at the required frequency | Usually present, because this is the part the regulator asks for by name | Composed of the data from the pipeline and the conclusions from the review, not written from scratch |
Component 2 is where the system breaks, and the failure is structural rather than negligent. A brand selling through a pharmacy chain has no direct view of the consumer complaint. A brand selling on a marketplace sees aggregated reviews but not individual adverse events. A brand selling through a distributor relies on the distributor's willingness to forward information that creates work for the distributor and no revenue. Without a contractual obligation and a form, the information does not arrive, and the brand discovers this at the moment it needs to write a report.
2. The 5-Market Comparison of Reporting Obligations
The table below compares the PMS obligations across the five markets that matter most for a pain patch exporter. It is not a legal opinion, and each market has detail beyond the table, but it captures the structural differences that determine what you have to build.
| Market | Framework | Periodic report | Cycle | Event-triggered reporting | The structural difference that matters |
|---|---|---|---|---|---|
| EU | MDR 2017/745, Articles 83-86, plus the PSUR and PMCF requirements | PSUR (Periodic Safety Update Report), with a PMS report for Class I | Class I: PMS report on request or when required. Class IIa: every 2 years. Class IIb: annually | Serious incident reporting, with a defined timeline from awareness | Class I devices, which includes most pain patches, need a PMS report rather than a full PSUR, but the report can be requested at any time and must be producible |
| US | 21 CFR Part 803 (MDR reporting) and Part 806 (corrections and removals), plus postmarket surveillance under Section 522 where applicable | No routine periodic report for a Class II device; annual report only if a 522 order applies | Event-driven | MDR report within 30 calendar days; 5 working days for a report that requires immediate action | The US is event-driven for most devices, which creates a false sense of low burden until a single reportable event arrives and the 30-day clock starts |
| UK | UK MDR 2002 as amended, MHRA guidance | Post-market surveillance report on request; periodic summary reports where required | Typically annual or on request | Adverse incident reporting to MHRA, with a defined timeline from awareness | A separate system post-Brexit. An EU PMS report does not satisfy the UK obligation, and the MHRA expects its own filing |
| Australia | Therapeutic Goods Act, TGA post-market monitoring | Annual report for some product categories; periodic review on request | Annual where applicable | Immediate reporting of serious adverse events to the TGA | The Sponsor, not the manufacturer, holds the reporting obligation, which means the brand needs a Sponsor arrangement that includes the reporting duty |
| GCC | SFDA and national authority requirements | Periodic safety reporting varies by state; SFDA requires a periodic report for most device categories | Typically annual | Field safety corrective action and adverse event notification to each national authority | GCC central registration does not mean central reporting. Each state expects its own notification, and Arabic-language reporting is often required |
The row that surprises most brands is the US. Because there is no routine periodic report for a Class II device, it is easy to conclude that the US burden is low. What that misses is the 30-day clock on an individual MDR report, and the fact that a single serious event starts it. A brand that has not built the pipeline in Section 5 will discover the event late, and the 30 days runs from awareness, not from when the report is convenient to write.
3. The 3 Report Types and Their Cycles
Three report types cover most of the obligation. The table below sets out what each one is for, who it is for, and what a proportionate version looks like for a pain patch.
| Report | Purpose | Markets | Cycle | Proportionate length for a pain patch |
|---|---|---|---|---|
| PMS report | Summarise the post-market data for a device and conclude whether the benefit-risk profile remains acceptable | EU (Class I), UK, Australia in various forms | On request, or when required by the class | 6-15 pages. A 40-page report for a Class I menthol patch is a sign that the author did not understand the class |
| PSUR | The fuller periodic safety update, with a benefit-risk analysis and a discussion of the clinical evidence | EU (Class IIa and above) | Every 2 years for IIa; annually for IIb | 20-40 pages for a Class IIa device, with the data appendices being the bulk of it |
| Trend report | Identify a statistically significant increase in the frequency or severity of an incident that is not itself serious | EU, and increasingly expected in the UK | As defined in the PMS plan, typically quarterly or annually | 2-6 pages plus a chart set. The chart is the report; the narrative explains what the chart shows |
The trend report is the one that is most often skipped and most often asked for. A regulator's interest in a pain patch is usually not a single serious event, which is rare; it is a slow increase in minor complaints that suggests a formulation or manufacturing drift. A brand that reports only serious events and never tracks the complaint rate per thousand units is missing the signal that the trend report exists to catch.
4. What a PMS Plan Must Actually Contain
The PMS plan is the document that defines the system. A plan that says "the manufacturer shall collect and review post-market data" is not a plan. The table below sets out the sections a workable plan contains.
| Section | Content | What makes it work rather than decorative |
|---|---|---|
| Scope | Which devices, which markets, which SKUs, effective date | Names the SKUs, not the category. A plan covering "all transdermal products" cannot be executed against a specific SKU |
| Data sources | Each source, the data it provides, the frequency, and the responsible party | Names the distributor contact and the form number. "Distributor feedback" is not a data source; "the monthly complaint summary submitted by the distributor on Form PMS-02" is |
| Data elements | The specific fields captured for each event: batch, symptom, severity, outcome, reporter type | Matches the coding scheme in Section 6, so the data can actually be aggregated |
| Review cadence | The frequency of review, the participants, and the output | Specifies quarterly with minutes and a named reviewer, not "regularly" |
| Escalation thresholds | The conditions that trigger an immediate escalation rather than waiting for the review | Specific numbers: a complaint rate above X per thousand units, any serious event, any batch with a cluster of three or more complaints |
| Report obligations | Which reports, for which markets, at what frequency, and who authors them | Maps to Section 3, with the author named rather than the department |
| Interfaces | How the PMS output feeds the risk management file, the CAPA system, and the technical documentation | This is the section regulators read to check that the PMS is connected to a decision process rather than being a filing exercise |
The escalation thresholds row is the most useful part of the plan and the part most often left vague. A plan with no numeric threshold means every escalation decision is a judgement call made by whoever is on duty, and the decision will differ between the person who takes the call in January and the person who takes it in July. Three specific numbers — a complaint rate ceiling, a serious-event trigger, and a batch cluster trigger — convert the plan from a document into a rule.
5. The Data Pipeline: 6 Sources to Wire Before the First Shipment
This is the operational section, and it is where the system either exists or does not. The six sources below are the ones a pain patch brand needs. The table sets out what each provides and the mechanism to put in place.
| # | Source | What it provides | Mechanism to put in place | Effort |
|---|---|---|---|---|
| 1 | Direct customer contacts (email, website form, phone) | Adverse events and complaints from consumers who reach you directly | A single intake form with the required fields, and a rule that every contact is logged even if no action is taken | 1 day |
| 2 | Distributor complaint summaries | The complaints that consumers report to the distributor rather than to you, which is most of them | A clause in the distribution agreement requiring a monthly summary on a defined form, plus a named contact at each distributor | 1 clause plus 1 form |
| 3 | Retailer and chain quality notices | Batch-level quality holds, complaints aggregated by the chain, and any delisting discussion | A named contact at each chain's quality team, and a request to be copied on any quality notice about your SKU | 1 introduction per chain |
| 4 | Marketplace and review aggregations | Consumer-perceived defects that never become formal complaints: the adhesion complaints, the "smells different" reviews | A monthly export of reviews for your SKU, coded against the same scheme as the formal complaints | 2 hours per month |
| 5 | Your own returns and receiving inspection | Defects that you can verify physically, with the batch number | Every return logged with the batch number and a defect classification; every receiving inspection recorded | Process change only |
| 6 | Factory batch and deviation data | The production-side context: which batch, which line, which deviation | A clause requiring the factory to send a batch summary with each shipment, plus notification of any deviation | 1 clause |
Source 4 is the one that most brands ignore and the one that produces the earliest signal. A pain patch that has a developing adhesion problem will show it in marketplace reviews as "it fell off" long before the complaints reach a formal channel, because a review is easier to write than a complaint. A brand that codes its reviews monthly against the same scheme as its complaints has a leading indicator that costs two hours a month.
Source 6 is the one that closes the loop, and it is the one that requires a contract clause rather than a process change. Without the batch data, a complaint cluster cannot be attributed to a batch and therefore cannot be investigated. The quality agreement clauses on deviation disclosure and batch record access, covered in the quality agreement guide, are what make this source available.
6. Complaint Coding: How to Make the Data Analysable
A PMS system that stores complaints as free text cannot produce a trend. The table below is a coding scheme that works for the pain patch category, with the top five defect categories that actually appear.
| Code | Defect category | Typical complaint language | What it usually indicates | Severity band |
|---|---|---|---|---|
| AD-01 | Adhesion failure | "It fell off", "would not stick", "peeled in the shower" | Adhesive lot variation, release liner residue, or die-cut tolerance | Minor to moderate |
| SK-02 | Skin reaction | "Redness", "rash", "itching after removal" | Contact dermatitis, sensitisation, or a formulation or liner residue issue | Moderate to serious |
| EF-03 | Efficacy below expectation | "No cooling", "did not work", "no effect" | Underloaded assay, degraded active, or a mismatch between the claim and the formulation | Moderate |
| PK-04 | Packaging failure | "Pouch was open", "dried out", "box damaged" | Seal integrity, transit damage, or a storage excursion | Minor to moderate |
| LB-05 | Labelling or instruction error | "Wrong language", "instructions unclear", "expiry unreadable" | Artwork version error, print quality, or a translation issue | Minor, but a regulatory finding if systematic |
The severity band column is where the coding connects to the reporting obligation. A SK-02 coded as moderate is a trend item; the same code with a hospitalisation in the outcome field is a serious event with a reporting clock. The coding scheme should therefore carry a separate outcome field (resolved without treatment / treated by a clinician / hospitalised / other serious) rather than trying to encode severity into the category, because the same defect can produce either outcome and the regulator cares about the outcome.
7. The Trend Analysis That Regulators Actually Look For
Three analyses are what a regulator looks at when reviewing a PMS report for a pain patch. All three are straightforward, and all three require the coding discipline in Section 6.
| Analysis | What it shows | The threshold that matters | What to do when it trips |
|---|---|---|---|
| Complaint rate per thousand units sold | Whether the defect frequency is changing over time, independent of volume growth | An increase of more than 50% against the trailing 4-quarter average, sustained for 2 quarters | Open an investigation into the batch range and the production window, even if no single complaint is serious |
| Batch clustering | Whether the complaints concentrate in one or two batches rather than spreading across all of them | Three or more complaints from a single batch within 90 days | Request the batch record and the deviation log for that batch; this is the fastest route to a root cause |
| Defect mix shift | Whether the proportion of complaints by category is changing, which often precedes an absolute increase | A category moving from below 10% to above 20% of total complaints over 2 quarters | Review the formulation and the packaging for that category specifically; a mix shift is an early warning |
The batch clustering analysis is the highest-value one and the cheapest to run, because it only requires that the batch number is captured on every complaint. A brand that records batch numbers can answer "is this one bad batch or a systemic drift" in an afternoon. A brand that does not is reduced to guessing, and guessing in a PMS report is the finding that leads to an inspection.
8. PMCF for Pain Patches: What Is Proportionate
Post-market clinical follow-up is the part of PMS that brands worry about most and need to worry about least, for most pain patch SKUs. The table below sets out what is proportionate.
| Device situation | PMCF obligation | Proportionate activity | Cost |
|---|---|---|---|
| Class I pain patch, well-established technology, long clinical history | PMCF generally not required; a documented justification is | A literature review covering the state of the art and any new safety signals, refreshed annually | USD 800-2,500 per year via a consultant |
| Class IIa pain patch, novel formulation or novel claim | PMCF plan required, with defined activities | A structured complaint analysis plus a user survey or a small post-market study, depending on the claim | USD 5,000-25,000 depending on the design |
| Any class, new active ingredient or new delivery mechanism | PMCF plan with a formal clinical activity | A post-market clinical investigation or a registry-based follow-up | USD 30,000 and up |
| Any class, claim that is central to the marketing | PMCF activity proportionate to the claim | Real-world use data supporting the specific claim, not just general safety | Depends entirely on the claim |
The first row covers most pain patch SKUs, and the proportionate answer is a literature review plus a documented justification for why a formal PMCF activity is not required. That justification is the document a Notified Body will ask for, and it is a page, not a study. The brands that overspend on PMCF are usually the ones that did not write the justification, and the brands that underspend are usually the ones that assumed no PMCF was needed at all without documenting why.
9. The 7 PMS Failures That Show Up in Inspections
The seven failures below are the ones that appear most often when an inspector reviews a pain patch brand's PMS system. Each is specific and each is preventable.
| # | Failure | What the inspector finds | How to prevent it |
|---|---|---|---|
| 1 | No data pipeline from the channel | A complaint log with 4 entries for a product that sold 200,000 units, and no explanation of why the rate is implausibly low | The distributor clause and the monthly form in Section 5, sources 2 and 3 |
| 2 | Reports written backwards from a conclusion | A PSUR that concludes "no new safety concerns" without any trend data to support it | A quarterly review with minutes, so the report is a summary of reviews rather than a standalone document |
| 3 | No batch numbers on complaints | An inability to answer whether a cluster is one batch or systemic | The batch field as a mandatory field on the intake form, not an optional one |
| 4 | Escalation decided by judgement, not by rule | Two similar events handled differently in different months, with no documented reason | The three numeric thresholds in the PMS plan |
| 5 | PMS disconnected from CAPA | A trend that triggered no investigation, and a CAPA system with no PMS-linked actions | The interfaces section of the plan, with the CAPA reference recorded on every escalation |
| 6 | No PMCF justification on file | A Notified Body request for the justification, and no document exists | A one-page documented justification for the SKUs where PMCF is not required |
| 7 | Report produced late or on request only | A report dated after the regulator's request rather than at the defined cycle | A calendar entry with a named owner, set at the start of the period rather than the end |
Failure 1 is the one that is hardest to defend, because the inspector's arithmetic is simple. A product that sold 200,000 units will generate complaints, and a log with four entries is not evidence of quality — it is evidence that the complaints went somewhere else. The defence is not a better log; it is a documented channel design showing where the complaints are received and how they reach the brand.
10. FAQ: PMS Questions Pain Patch Brands Ask Most
10.1 Does a Class I pain patch need a PSUR?
No. Under the EU MDR, Class I devices need a PMS report rather than a PSUR, and the report is produced when required rather than on a fixed biennial cycle. That is a lighter obligation than it sounds, because the report must be producible on request, and a report that cannot be produced because the data pipeline does not exist is a finding regardless of the cycle. The practical requirement is a system that can generate the report within a reasonable period, not a document that sits on a shelf.
10.2 How long must PMS records be retained?
In the EU, the technical documentation including the PMS output must be retained for at least 10 years after the last device has been placed on the market, or 15 years for an implantable device. For a pain patch, the 10-year period applies. In practice that means the complaint data, the review minutes, and the reports are retained for a decade, which has a direct implication for your systems: a spreadsheet that gets overwritten each quarter is not a retention system.
10.3 Do I need a PMS plan for every SKU?
No, but you need the plan to cover every SKU explicitly, and the data to be separable by SKU. One plan covering a product family is normal and efficient. A plan covering a family where the data cannot be separated by SKU is a plan that cannot produce a per-SKU trend, which is the analysis that matters when a single SKU develops a problem.
10.4 What counts as a serious incident for a pain patch?
The definition turns on the outcome, not the defect. An adhesion failure is not serious; the same adhesion failure that leads to a fall and a fracture is. A skin reaction is not serious; a skin reaction that requires hospital treatment is. The practical rule is that the intake form must capture the outcome separately from the defect category, because the same defect code can produce either classification and the reporting obligation follows the outcome.
10.5 How do I get complaint data from a distributor who will not share it?
Put it in the distribution agreement as an obligation with a defined form and a defined timeline, and make the obligation a condition of the relationship rather than a request. A distributor that will not report complaints is a distributor that is exposing you to a reporting failure you cannot see, and that is a contractual issue rather than a data issue. If the agreement is already signed and the clause is missing, add it at the next renewal and start with a voluntary monthly summary in the meantime.
10.6 What is the difference between PMS, PMCF, and vigilance?
PMS is the overall system: the collection, review, and reporting of post-market data. PMCF is a specific activity within PMS, focused on clinical data, and it is only required where the clinical evidence is insufficient without it. Vigilance is the event-triggered reporting of serious incidents and field safety corrective actions to the authority. A brand needs all three, but they have different cycles: PMS runs continuously, PMCF runs on a defined plan, and vigilance runs on a clock that starts when an event is known.
10.7 Can I use a consultant to run my PMS?
You can and often should use a consultant for the reports, the literature review, and the PMCF justification. What you cannot outsource is the data pipeline, because the data lives in your sales channel, your customer service inbox, and your distributor relationships. A consultant who is asked to write a PMS report without a data pipeline will write a report based on whatever is available, which produces exactly the failure in Section 9. The right division is: you own the pipeline, the consultant owns the analysis and the document.
10.8 How often should the PMS review happen?
Quarterly for any brand with more than about 50,000 units a year in a market, and semi-annually below that. The review is a 60-90 minute meeting with the data in front of the participants, minutes recorded, and a documented conclusion on whether any action is required. A brand that reviews only annually is reviewing 12 months of data at once, which means it discovers a trend 9 months after it started.
10.9 What happens if I miss a reporting deadline?
It depends on the market and the severity, and the range is wide. A late PSUR in the EU is a finding in the next inspection. A late serious incident report is a more serious matter, and in several jurisdictions the lateness is treated as a separate violation from the incident itself. The practical mitigation is to notify as soon as the omission is discovered, with an explanation and a corrective action, rather than waiting for the next scheduled contact — a self-reported late filing is treated very differently from a late filing discovered by the authority.
10.10 Can Kangdi provide the batch and deviation data a PMS system needs?
Yes, and it is part of our standard shipment documentation rather than a special request. Every shipment includes the batch numbers with production dates, the certificate of analysis per batch, and a deviation summary for any batch that deviated from the validated process. We can also provide a monthly batch summary in a format your PMS system can import, and the batch record on request within 10 business days, which is the retention and access obligation in our quality agreement. Email us with "PMS Data" and your SKU list, and we will send the batch summary format and a sample of the deviation report.
11. About Kangdi Medical and Our PMS Data Support
Henan Kangdi Medical Devices Co., Ltd has manufactured transdermal patches since 1989 from a GMP-certified facility in Zhoukou, Henan, China, and we ship to 200+ brand buyers and distributors across 40+ countries. Batch-level data and deviation disclosure are part of our standard shipment documentation, because a customer's PMS system cannot work without them.
Three steps to get our PMS data package. (1) Email us with "PMS Data" as the subject line, including your SKU list and the markets you report into. (2) We will send the batch summary format, a sample deviation report, and the certificate of analysis template, within 3 business days. (3) We will set up the monthly batch summary as a standing report on your account, so the data arrives before you need to write the annual report.
- Step 1: Email export@kangdimedical.com with "PMS Data" as the subject line, including SKU list and reporting markets.
- Step 2: Receive the batch summary format, a sample deviation report, and the CoA template within 3 business days.
- Step 3: Set up the monthly batch summary as a standing report, with the batch record available on request within 10 business days.
Tell us your SKU list and reporting markets, and we will send the PMS data package within 3 business days.