Compliance in a medical charger program is a shared responsibility with clear boundaries: the buyer owns the device classification, the supplier owns the evidence and the process, and the two agree on change notification and re-certification. When the boundaries are written down, compliance stops being a negotiation and becomes a contract. This guide explains the buyer's responsibility, the supplier's responsibility, change notification, how to put the responsibilities in the contract, and a responsibility matrix template.
Key takeaways
- The buyer owns the device classification; the supplier owns the evidence and process.
- Change notification and re-certification are agreed in writing before volume.
- A responsibility matrix makes the split explicit and auditable.
Content updated: August 2026 — confirm current standards editions and model-specific details before ordering.
Scope note: This guide is industry information, not legal advice; the responsibility framework is general industry practice and should be reviewed with qualified advisers.
The Buyer's Responsibility: Device Classification
The buyer owns the device classification because it is a regulatory determination about the device and its intended use. The buyer's QA or regulatory team confirms which framework applies — whether the IEC 60601 family or a consumer standard — and that determination drives everything downstream.
The classification is the input the supplier needs before quoting. A supplier cannot decide whether the charger must be evaluated against a medical framework; it can only provide evidence for the framework the buyer names. When the buyer supplies the classification, the supplier can propose the right configuration and document set.
The buyer also owns the use context. The environment, the duty cycle and the market list are inputs to the compliance story, and they are confirmed by the buyer with the clinical and commercial teams. The classification and the context are the buyer's half of the matrix.
The buyer's ownership also includes the decision record. The classification determination, the market list and the document requirements are written down and dated, because the record is what the supplier relies on and what an audit reads. A buyer who documents the decision has made it; one who leaves it in a conversation has deferred it.
The buyer's responsibility is not diminished by outsourcing. A third-party consultant or a supplier's advice can inform the classification, but the buyer's QA or regulatory team confirms it and owns the consequence. The ownership cannot be delegated, only informed.
The Supplier's Responsibility: Evidence and Process
The supplier owns the evidence and the process: the certificate and test report for the configuration, the production test flow and the batch records. The evidence is the supplier's deliverable, and it must name the exact configuration the buyer ordered.
The supplier's process responsibilities include:
- Maintaining the certificate and test report for the current configuration.
- Running the production tests and keeping the batch records.
- Operating change control so the shipped configuration matches the certificate.
- Notifying the buyer of any change that affects the evidence.
The evidence is not a courtesy; it is the supplier's half of the compliance story. A supplier that cannot produce the evidence has not delivered the product, whatever the hardware does.
The supplier's evidence responsibility also includes currency. Standards are revised, configurations change and certificates expire or are refreshed, and the supplier keeps the evidence current for the configuration it sells. A certificate that was valid last year but names a superseded edition is not current evidence, and the supplier owns the refresh.
The process responsibility extends to the supplier's own suppliers. Component-level traceability feeds the batch story, and the supplier manages its upstream chain so the batch records can be followed to components when needed. The evidence chain is only as strong as its upstream links.
Change Notification and Re-Certification
Change notification is the boundary where the two responsibilities meet. When the supplier changes a component, a test limit or a layout detail, the change may affect the certificate coverage — and the supplier's obligation is to notify and review, not to decide alone.
The re-certification decision follows the change's impact. A change that does not touch the electrical configuration may pass with documentation; a change that does should trigger a review of the certificate and test coverage. The decision is recorded, and the file shows what changed, when and who approved it.
The notification process is agreed in advance: which changes require notification, the format of the notice and the response time. A process agreed before volume is a process that runs; one improvised at the first change is a process that stalls.
The notification format matters as much as the obligation. A change notice that names the change, the affected configurations and the certificate impact can be reviewed and decided quickly; one that describes a change without the impact restarts the analysis. The format is specified in the agreement, and the file records the notices.
The notification also covers the buyer's changes. When the buyer changes the device, the market or the document requirement, the supplier should be notified so the evidence can be re-reviewed. The responsibility runs in both directions, and the matrix records it.
Putting Responsibilities in the Contract
The contract is where the split becomes enforceable:
| Contract item | What it states |
|---|---|
| Classification ownership | The buyer confirms; the supplier relies on it |
| Evidence deliverables | What documents ship with each order |
| Change notification | Which changes are notified, in what format |
| Re-certification ownership | Who reviews, who pays, who decides |
| Batch records | What records travel with each shipment |
The contract items are written before volume, and each has an owner and a review point. A contract that names the split prevents the compliance conversation from restarting at every order.
The contract also records the commercial consequence of a gap. When a shipment arrives without its evidence, the contract states what happens — the hold, the inspection and the correction. The consequence makes the responsibility real.
The contract should also name the review cadence. Compliance is reviewed on a schedule — with each reorder, at each change and at each market addition — rather than once at launch. The cadence is written down, and the reviews are recorded, so the compliance story stays current with the program.
The contract language is reviewed with qualified advisers before signing, because the responsibility split has legal and regulatory weight. The framework in this guide is a starting point for the conversation, not the final word.
A Responsibility Matrix Template
| Responsibility | Buyer | Supplier |
|---|---|---|
| Device classification | Owns | Relies |
| Evidence deliverables | Reviews | Provides |
| Change notification | Decides impact | Notifies |
| Re-certification | Confirms requirement | Runs the testing |
| Batch records | Reviews at receipt | Maintains |
The matrix is the program's compliance map in one table. Each row names who owns the action, and the file records the answers per configuration.
The matrix is reviewed when the configuration or the market changes. A new market adds a row, a configuration change re-reviews the evidence rows, and the file stays current. The matrix is a living document, and the review calendar keeps it honest.
The matrix also serves the supplier conversation. When both sides work from the same table, the compliance discussion is about rows and owners rather than vague responsibility. The matrix is the shared reference, and it is updated with the agreement, not beside it.
The compliance story closes with the same evidence standard as the rest of the cluster: the classification is confirmed, the documents name the configuration and the batch records follow every order. The responsibility split is the mechanism that makes the story hold together across the program's life.
The responsibility matrix needs a concrete platform list, and the GaN Charger Category at WECENT provides it, sorted by power and ports, the Quality Control page describes the production test flow and records, and the WECENT FAQ answers the certification questions that come up during selection. To agree the responsibility matrix for a configuration, submit the device list and target markets to WECENT's project engineering team — the review returns the evidence deliverables and change process for the program.
The Quality Control page at WECENT describes the production test flow and records, and the WECENT FAQ answers the certification questions that come up during selection. To agree the responsibility matrix for a configuration, submit the device list and target markets to WECENT's project engineering team — the review returns the evidence deliverables and change process for the program.
Frequently Asked Questions
Where does the standard decision sit in the responsibility matrix?
As one named row: the buyer's QA or regulatory team owns the standard decision, and the supplier's row is the evidence. Making the split visible in the matrix keeps it enforceable at every reorder.
What does the supplier own in compliance?
The evidence and the process: certificates, test reports, production tests, batch records and change control. The evidence must name the exact configuration.
When does a change require re-certification?
When the change touches the electrical configuration or the tested coverage. The impact review is the supplier's obligation, and the decision is recorded.
Why put compliance responsibilities in the contract?
Because an unwritten split restarts the conversation at every order. The contract names the owner, the evidence and the consequence, making compliance enforceable.
How do I use the responsibility matrix?
Fill one row per responsibility, name the owner and review the matrix when the configuration or market changes. The matrix is the program's compliance map.