The conclusion up front
To place a wheelchair on the EU market, technical documentation is not a stack of test reports bound together. It is a chain of evidence that has to be self-consistent: device description and classification determination, item-by-item demonstration of conformity with the general safety and performance requirements (GSPRs), design and manufacturing information, verification and validation (type test reports live here), risk management, clinical evaluation, and post-market arrangements. What gets assessed is whether that chain has any breaks — not whether one report, read on its own, shows a pass.
Manufacturers usually lose in one of two places. First, testing is arranged before the documentation, and only afterwards does it emerge that the product configuration in the reports does not match the product family described in the file. Second, the conformity checklist is treated as a fill-in-the-blank exercise, with "complies" written in each row but no evidence reference and no page number. Neither is a technical problem; both are problems of sequence. So this note follows the order in which an assessor reads the file, not the numbering of the standards.
One clarification first: the specific clause numbering of the regulation and standards, the classification rules, the test parameters and the acceptance limits are all governed by the current effective editions of the regulation and standard texts. This note covers structure and decision logic; it does not restate numbering.
The modules, and how they depend on each other
Technical documentation is not a set of parallel folders. The modules have a definite order. Until classification is settled you do not know whether a notified body is involved; until the conformity checklist is drawn up you do not know which tests to run; until the tests are done, the verification column against each risk control measure is empty. Working in dependency order removes a great deal of rework.
| Module | Core content | Usually led by | Frequent reasons for rejection |
|---|---|---|---|
| Device description and specification | Product family, variants, configurations, intended purpose, target population, use environment | Manufacturer R&D + regulatory | No basis given for the model family split; vague intended purpose |
| Classification determination | Argue each determining factor, then apply the classification rules in the regulation text and record the reasoning | Manufacturer regulatory | Copying the class straight off a competitor's certificate |
| GSPR conformity checklist | Each requirement → applicability → method of conformity → location of evidence | Regulatory + R&D | Only "complies" written, no traceable evidence |
| Design and manufacturing information | Design inputs and outputs, drawings, critical processes, suppliers and outsourcing | R&D + production | Missing supplier information for critical components |
| Verification and validation | Type test reports, electrical safety and EMC, biological evaluation, software documentation | Third-party laboratory | Product configuration in the reports differs from the file description |
| Risk management | Risk management file to ISO 14971 and residual risk justification | R&D + regulatory | Risk control measures with no corresponding verification evidence |
| Clinical evaluation | Evaluation plan, equivalence argument or own data, evaluation report | Regulatory + clinical | Cannot obtain sufficient technical data on the equivalent device |
| Post-market | Post-market surveillance plan, PMCF plan or justification for non-applicability, vigilance and complaint process | Quality | Left blank at submission, to be "added after certification" |
| QMS interface | Change control, design transfer and record retention under ISO 13485 | Quality | Technical file and QMS documents contradict each other |
Device description and model family: this is the foundation
The first job is to separate three levels cleanly — product family, variant, configuration. Do different seat widths, battery packs and controllers on the same platform belong in one technical file? That cannot be decided by feel; it depends on whether the change touches parameters related to safety and performance. For wheelchairs, at minimum these need individual consideration: frame construction and welding method, drive wheel and castor specification, motor and controller combination, battery chemistry and capacity, the seating system's mounting interface to the frame, and the braking mechanism type. If any one of them changes, the corresponding type testing has to be re-assessed for whether the lead model still covers it.
The common industry practice is "test the lead model, write a difference statement for the rest". That route is workable, but the difference statement has to land on specific test items and explain why the load path and failure modes of the variant match the lead model. This is engineering analysis, not a statistical conclusion, so set out the reasoning: where the load enters, through which joints it passes, which section carries it, in which posture the worst case occurs, and whether the change alters that path. Two concrete illustrations. Widen the seat and the cross-member span increases; under the same occupant load the bending moment on the cross-member rises with span, so the stress state along that path has changed and coverage by the lead model is hard to argue for strength tests. Conversely, change only the armrest covering material and the load path is untouched — strength coverage can be argued, but the biological evaluation line has to be walked again. An assessor will not accept "structurally similar". What they want to see is: which path is unchanged, and therefore which test need not be repeated.
Classification: argue the determining factors, do not cite rule numbers
The classification conclusion governs how everything downstream is done, yet in many technical files this section is a single line of conclusion with no reasoning. The correct approach is to set out each determining factor with its factual basis, then apply the classification rules in the regulation text to reach a conclusion. For wheelchairs and similar products, at least these four factors need to be addressed:
- Invasiveness: does the product enter the body or a body orifice in any way? For wheelchairs, scooters and walking aids this is normally clear-cut, but the conclusion must be written out, not silently omitted.
- Active or not: does it depend on electrical or other energy for its function? Manual wheelchairs, powered wheelchairs and mobility scooters already diverge here, and this is the first watershed at which their classification conclusions may differ.
- Duration of use: which band does contact with the body or continuous use fall into? What matters is the actual use scenario; long-term daily mobility and short-term intra-hospital transfer are argued differently.
- Wording of the intended purpose: is it claimed for rehabilitation training, for specific patient populations, for road or outdoor environments? This is where manufacturers most often write too broadly — sales language gets transplanted verbatim into the intended purpose, and classification and downstream requirements rise with it.
Set out the factual basis for those four, apply the classification rules from the regulation text, and retain the full reasoning. Which rule applies and which class results is governed by the current effective edition of the regulation text. Do not copy a competitor's certificate: their configuration and intended purpose may differ from yours, and the classification conclusion does not necessarily transfer.
Only once the class is fixed do you know whether a notified body is involved and which conformity assessment route applies — and only then can you work back to the timing of UDI assignment, authorised representative appointment and EU database registration. All of those schedules hang off the classification conclusion, so changing the classification once means replanning the whole project. That is precisely why it has to be done first.
The GSPR checklist: write it as requirement / method / evidence location
The GSPR checklist is the index to the whole technical file and the assessor's way in. A poor checklist has two columns: the requirement, and "complies". A checklist that holds up has three columns, each filled a particular way.
| Column | What this column answers | How to fill it for a wheelchair | Common faults |
|---|---|---|---|
| Requirement | The substance of the requirement and whether it applies to this product; non-applicable entries must state why | Restate the substance in your own words, then judge applicability — for a passive manual wheelchair, state that energy-supply requirements are not applicable and why | Copying the regulation text verbatim with no applicability judgement; leaving non-applicable rows blank |
| Method of conformity | What demonstrates conformity: which standard, which method, which argument | Cite the corresponding method in EN 12183, EN 12184 or ISO 7176; it may also be a risk analysis conclusion, design verification or a measure in the instructions | Naming a standard without the method; stuffing many standards into one requirement so it is unclear which does the work |
| Evidence location | Where the evidence is: document number + version identifier + page or section | Report number plus page, drawing number plus revision, instructions version plus the relevant paragraph | Writing only "see test report"; the evidence document is later revised and the checklist is not updated |
The clause numbering, grouping and total count are governed by the current effective edition of the regulation text; this note only covers how to fill those three columns. A few requirement categories are especially prone to being handled vaguely for wheelchairs:
- Performance requirements around stability, strength and braking. The evidence is the type test report, but check whether the test configuration in the report (simulated occupant load, seat settings, accessory fitment) represents all the configurations you declare.
- Requirements on chemical and biological safety. The evidence is the biological evaluation documentation, not a sentence saying "the material is a common plastic".
- Requirements on information supplied with the device. The evidence is the actual version of the instructions and labelling, with version numbers stated. Assessment will check against the instructions you submit, and translations are within scope too.
- Requirements on alarms and energy supply. For powered wheelchairs these involve the battery and control system; be clear which are product functions and which depend on user action, with the latter implemented in the instructions.
Choosing standards: EN 12183, EN 12184 and the ISO 7176 series
On the EU route, manual wheelchairs generally map to EN 12183 and powered wheelchairs and scooters to EN 12184, and both standards draw heavily on the ISO 7176 series for test methods. There are two practical consequences.
First: the ISO 7176 part tests you complete under electric wheelchair testing and manual wheelchair testing can mostly serve directly as supporting evidence for the EN standards, without being redone. That is also why we advise clients to complete the ISO 7176 series in one pass — testing in instalments lets the prototype state drift, and consistency between reports then becomes harder to explain, not easier.
Second, and more often missed: EN 12183 and EN 12184 are not only collections of test methods. They also contain requirement clauses on the product itself — information marking, required content of the instructions, and requirements on materials and construction. Run the ISO 7176 tests without checking against those requirement clauses one by one and the technical file is missing an entire block, which is normally picked up in the first round of assessment.
Which parts are cited, and the test conditions and acceptance limits of each, are governed by the current effective editions. One detail worth flagging: the standard edition printed on a report cover must match the edition declared in the conformity checklist. A standard revised without the report being updated is a very common nonconformity. The standards we cover are listed on the standards page.
GB/T 18029 reports: what can be reused and what has to be added
The conclusion for this product category, without circling: the GB/T 18029 series corresponds technically to the ISO 7176 series, so the raw data and test records from testing already done in China have reuse value — but the boundaries of that reuse are clear.
Normally reusable are items where the test method is consistent across both regimes and the prototype state is traceable: static strength, fatigue and impact structural strength, static and dynamic stability, braking performance, dimensional and mass parameters, and for powered products range and speed performance. The preconditions are that the report can show the method it relied on corresponds to the method cited on the EU route, and that the prototype configuration is documented. Lose either precondition and the reuse claim does not stand.
Normally requiring additional work are three categories. First, the product requirement clauses unique to EN 12183 and EN 12184: information marking, required content of the instructions, material and construction requirements. Chinese reports do not cover this block at all; it has to be checked clause by clause with conformity evidence retained, and this is the main reason reuse ratios get overestimated. Second, items with insufficient configuration coverage: domestic testing is often run on a single standard configuration while the declared configuration range is wider, so the gap must either be tested or supported by a coverage argument that holds. Third, items whose basis cannot be traced: a report showing only a Chinese standard number, with no visible mapping to an international method, usually has to be redone at assessment.
On the broader question of "an accreditation mark makes a report universally accepted" — that belongs to the general topic of cross-market report reuse and is not covered here. One thing to retain: an accreditation mark demonstrates the laboratory's technical competence within its accredited scope only, and is not a commitment as to market access. What is actually assessed in a technical file is always whether three things line up — method, prototype state and configuration coverage.
| Point of focus | Common practice for domestic testing | What EU technical documentation expects | Recommended handling |
|---|---|---|---|
| Standard cited | Report cites the relevant GB/T 18029 part | Must be traceable to the corresponding EN and ISO method and edition | Require the report to cite the corresponding ISO 7176 basis before testing starts |
| Prototype identification | Model number only | Model + configuration + serial number + critical component batch | Record the full configuration on the test request form and keep photographs |
| Test configuration | Run on the standard configuration | Must cover the declared configuration range or explain the coverage logic | Build the configuration matrix first and decide the test combinations |
| Report language | Chinese | An English version is required for assessment | Issue bilingual reports rather than translating afterwards |
| After changes | Minor changes not retested | Change control records must correspond to the reports | Maintain a mapping from bill of materials to test items |
Biocompatibility and materials: define contact first, then the test items
A wheelchair is not an implant, but plenty of components contact the body: cushion and backrest fabrics, armrest coverings, handrims, joystick grips, footplate surfaces, leg rest straps. Following the ISO 10993 approach, the first step is to determine the nature and duration of contact, and on that basis decide which biological endpoints are required — not to order a full battery of tests at the outset. Which endpoints and which test methods apply is governed by the current effective edition of the standard text and by the product's actual contact conditions.
The trap in real projects is supplier substitution. The fabric mill changes a coating batch, the foam supplier changes formulation, and the existing biological evaluation documentation may no longer hold. So the technical file needs a mapping table from contact components to materials, tying together material grade, supplier and change history. Without it, change control has nothing to grip, and at assessment you cannot answer whether this batch is the same material as the batch that was tested.
Risk management and clinical evaluation: not two unrelated documents
The risk management file established to ISO 14971 has to reconcile in both directions with the conformity checklist and the test reports. A concrete example: tip-over risk is identified, and the control measures are recorded as "stability assured by structural design" plus "warning in the instructions". The stability test report is then the evidence for the first half, and the corresponding page of the instructions is the evidence for the second. Assessment follows that thread; if it does not lead anywhere, the residual risk has not been closed out. For products with a higher centre of gravity and more varied use scenarios — mobility scooters in particular — this thread gets pulled repeatedly; see mobility scooter testing for the relevant test scope.
For clinical evaluation, wheelchairs generally follow an equivalence argument or existing data plus literature. Equivalence has to be argued across technical, biological and clinical dimensions, and sufficient technical documentation on the equivalent device has to be obtainable — this is where projects frequently stall, having named a competitor as the equivalent device without any access to their technical detail. The alternative is post-market data on your own products plus published literature, on condition that your historical data is in order. Whichever route, the clinical evaluation conclusion has to support the safety and performance claims in the conformity checklist rather than standing apart from them.
Post-market work does not start after certification
The post-market surveillance plan, the PMCF plan or a justification for its non-applicability, and the vigilance and complaint handling process all have to be in the technical file at submission, not added after certification. Field feedback on wheelchairs is information-rich: footplate cracking, brake fade, battery swelling, controller faults, loosening of seat fixings — all natural surveillance inputs. Define the distributor feedback channel, the data collection frequency and the triggers for re-evaluation at the documentation stage. Leaving it blank tells the assessor that you are not actually running the process.
The technical file also has to interface with the ISO 13485 QMS documents: which process design changes follow, whether a change triggers retesting, where records are kept, and who approves. The technical file saying A while the QMS documents say B is a conspicuous nonconformity.
What to have ready before testing
Based on the projects we have run, settling the following before kick-off avoids a great deal of back-and-forth:
- Product family and configuration matrix: list every model, seat width, drive option and battery option you intend to export, mark which are to be declared together, and write one line of justification for each grouping. This table is the input to every later decision, and the laboratory needs it to fix the test combinations.
- Test prototypes and state records: the number of prototypes depends on how destructive the tests are and whether they can run in parallel — confirm this with the laboratory in advance. Record configuration, serial number and critical component batch for each unit, with photographs before and after disassembly. Destructive tests essentially consume the prototype, so if you intend to run further tests on the same unit, the test sequence has to be fixed beforehand rather than negotiated on arrival.
- Complete bill of materials and critical component documentation: supplier information and material declarations for battery, controller, motor, fabrics and cushion materials. For powered products in particular, draw the responsibility boundary between battery and controller clearly — which parameters the supplier warrants and which are covered by whole-product verification. If that boundary is unclear you will be exposed when the assessor asks.
- Formal versions of instructions and labelling, including the language versions intended for the EU market. These are direct evidence against several requirements and must be technically consistent with the test reports; they cannot be left to a casual sales translation.
- Existing domestic reports and historical test records, supplied together with the prototype configuration of the time, so that reusability can be judged. A conclusions page alone is not enough — the laboratory will have to go back to the raw records anyway.
- The current version of the risk management file: even incomplete, it beats reverse-engineering one after testing. Hazards already identified in the risk analysis often determine directly whether test items need adding.
Recurring traps
One: testing before documentation. Prototype configuration is decided casually at submission, and only when the conformity checklist is written does it emerge that the reports do not cover the lead model — so retesting follows. Two: drawing the model family too wide, forcing structurally distinct products into one file, and being told to split it. Three: the English instructions being technically inconsistent with the test reports. Four: battery and control system documentation supplied by the vendor, with the manufacturer unable to articulate the boundary when questioned. Five: changes not recorded, so that a year later "how does this version differ from the one tested" has no answer.
What these have in common is that none is a difficult test problem. They are all failures to establish correspondence between the documents and the physical product. Test reports are only evidence; the technical file is the logic that organises evidence into a conclusion.
What we can do
SUNGO Mobility Testing Lab focuses on wheelchairs, mobility scooters, walkers and crutches, and is accredited by CNAS, CMA and IAS (USA), with laboratories in Shanghai and Hefei. To be clear, these accreditation marks demonstrate the laboratory's technical competence within its accredited scope and are not a commitment as to market access in any target market. Around EU technical documentation we can run testing to the ISO 7176 series and to EN 12183 and EN 12184 and issue bilingual reports; help you work through the product family and configuration matrix before testing, fixing prototype state and test combinations so that the reports do cover the models you declare; and work with you on evidence traceability in the conformity checklist, mapping report numbers and page references to individual requirements.
If you need to assess which tests your product requires, or how much of your existing domestic reporting can be reused, come to us with the model list and the current reports: +86 132 4819 8029, or request a quote.