Start with the framing: a test is verification evidence for a control measure, not a box to tick
Risk management files and test lists written in isolation from each other is a recurring problem in wheelchair technical documentation. It looks like this: the risk file lists dozens of hazards at length, there is a stack of test reports, and there is not one traceable line connecting the two.
Under the logic of ISO 14971 the chain is clear: hazard, then foreseeable sequence of events, then hazardous situation, then risk estimation, then control measure, then verification of the effectiveness of that control measure, then evaluation of residual risk. A test sits at the verification step. It is evidence that a particular control measure genuinely works.
So the question when deciding whether an item should be run is not "does the standard contain this item". It is "what evidence am I going to use to show that this control measure is effective against this hazardous situation".
The reverse also holds. If a test has no control measure in the risk file that corresponds to it, then either the risk analysis missed a hazard, or that item genuinely does not apply to this product. The two cases are handled completely differently, but both must be written down. Neither may be left blank.
Three typical disconnects, with different consequences
Disconnect one: the hazard is there, the verification is not. The risk file says "frame fracture causes the user to fall", the control measure says "structural design includes a margin", and that is where it stops. How large the margin is, and how anyone knows it is enough, has no supporting evidence at all. Control measures left hanging like this get questioned item by item during document review, and closing them out usually means arranging new tests.
Disconnect two: the tests are there, the citation is not. Strength, stability and braking reports all exist, but the risk file never mentions any of them. What a reviewer sees is a self-referential risk evaluation next to a pile of isolated reports. This one is actually easy to fix and cheap - add the citations - yet plenty of manufacturers leave it until someone challenges them.
Disconnect three: the residual risk conclusion has no evidence behind it. The conclusion says residual risk is acceptable, and the basis for accepting it is a judgement call rather than a verification result. This is the more serious of the three, because it undermines the credibility of the entire risk file.
Hazards mapped to verification routes
The table below is a commonly used set of links. Add to it and cut from it according to your own structure, user population and use environment.
| Hazard category | Typical hazardous situation | Common control measures | Where the verification evidence comes from |
|---|---|---|---|
| Structural failure | Frame or seat support fractures in use and the user falls | Design margin in the structure, control of material and welding process | Strength items, covering the static, impact and fatigue assessments addressed by ISO 7176-8 |
| Whole-device tipping | The device tips over on a slope, crossing an obstacle or turning | Centre of gravity layout, anti-tip devices, use limitations in the documentation | Items in the corresponding stability part, plus the use limitation information in the instructions |
| Brake failure | Rolling away on a ramp, unable to slow down while travelling | Brake system design and redundancy, independent parking brake | Items in the corresponding braking part |
| Electrical | Abnormal heating, insulation failure, control anomaly | Component selection, protection circuits, wiring and fixing | Items in the corresponding electrical and battery parts, plus component-level evidence |
| Use error | Folding mechanism used before it locks, accessory not fully fitted | Mechanical interlocks, visible status indication, warning markings, instructions | Usability-related verification, plus checks on marking durability and visibility |
| Material contact | Prolonged contact with a part causes skin discomfort | Material selection and surface treatment | Material evidence and supplier consistency documentation |
| Environmental | Malfunction after use in damp, dusty or thermally variable conditions | Protective design, sealing and drainage | Items in the corresponding environmental part |
The related requirements under GB/T 18029 can be read across the table in parallel; confirm the applicable parts against the current valid version of the standard text. It helps to map the overall test scope against standards and regulations first, then come back and build the links.
Making strength items connect properly to the risk file
The three assessments under ISO 7176-8 address three completely different failure mechanisms. Static loading addresses a one-off overload, impact addresses sudden external force, and fatigue addresses cumulative damage from repeated use over time.
Many risk files carry a single line - "insufficient frame strength" - hang one static item off it, and call the verification done. The problem: the sequence of events described as "cracking accumulates after long-term use" is simply not covered. A user transferring in and out repeatedly, riding over kerbs repeatedly, is not the same thing as a single overload event.
A practical way to write it: break hazards down by failure mechanism, not by part. Rather than writing "insufficient frame strength", "insufficient seat support strength" and "insufficient footrest strength" as three entries, write "overload causes instantaneous fracture of a load-bearing member", "external impact causes failure at a joint" and "long-term cyclic loading causes cumulative damage to a load-bearing member". Then hang the matching verification route on each. The first style looks like more entries but covers less; the second has fewer entries, and every one of them can point to specific evidence.
Four questions for deciding whether an item applies
For each hazard, in order:
- Does this product have this hazard? That is decided by the structural form, the user population and the use environment. Hazard lists for manual products and powered products differ substantially - do not copy another product's template straight across.
- What is the current control measure? Distinguish between design control, protective measures and information for safety. The three differ in effectiveness, and they differ in how they are verified.
- What evidence shows this control measure is effective? Test data, calculation and analysis, data from comparable previous products, usability verification - all can serve as evidence, but write down why this evidence is sufficient.
- Does the condition the evidence applies to match the condition the product ships in? Sample configuration, accessories, software version, material grade: if any one of them does not line up, the weight of the evidence has to be reassessed.
Question four is where projects come unstuck. The submitted sample was hand-assembled, used better material and had the full accessory set, while the production unit is not in that state. There is a gap between the evidence and the product, and nothing in the risk file shows it.
What to change in the risk file when a test does not pass
The wrong move first: lowering the risk level so the conclusion turns acceptable by itself. That inverts the logic. A failed test tells you the control measure is ineffective. The risk level itself has not changed.
Three workable routes:
- Change the design. Eliminate or reduce the hazard at source, then re-verify. Expensive, but the outcome is definite.
- Add or strengthen control measures. Add protection, add an interlock, add redundancy, then verify again against the new measure.
- Restrict the intended use and conditions of use. Narrow the scope of application, revise the instructions to match, and re-evaluate the residual risk under the narrowed scope.
Restricting the intended use is not a universal escape hatch. Once the scope narrows, foreseeable misuse still has to be evaluated - whether users will use the device in the way you excluded, and how serious the consequences of that excluded use would be. Where misuse is both likely and serious, a single restrictive sentence in the instructions will not hold the position.
One more point: after any revision, the risk file is not finished by adding a line to the record. Residual risk evaluation and the judgement on overall risk acceptability both have to be run again.
Information-type control measures need verification too
Instructions, warning markings and accompanying documentation belong to the weaker end of the control measure hierarchy, but weaker effectiveness does not mean no verification. What to look at:
- Whether the marking is in a position the user can actually see. A position obscured by an accessory or a cushion does not count.
- Whether the marking stays legible under the expected conditions of use - after wiping, sun exposure and rain.
- Whether the target user population can understand the wording of the instructions, which deserves particular attention where elderly users and carers are involved.
- Whether key safety notices are buried among other information.
All of this needs an inspection record in the file, not a line saying it has been mentioned in the instructions.
Self-check before the file goes out
| Check | Pass criterion | Common problem |
|---|---|---|
| Hazard to verification traceability | Every hazard points to matching verification evidence or a documented non-applicability statement | Control measures left hanging |
| Verification to hazard traceability | Every report is cited by at least one control measure | Reports sitting in isolation, never mentioned in the file |
| Evidence matches product state | Sample configuration, version and material match series production | The submitted sample differs from the production unit |
| Basis for residual risk | The conclusion cites specific verification results | The conclusion is a judgement call |
| Handling of failed items | Design changed, measures added or use restricted, and re-verified | The risk level was simply lowered |
| Verification of information measures | Records exist for position, durability and comprehensibility | Only a note saying it has been mentioned |
Where a product falls in terms of classification directly affects the starting point of its hazard list, so settle that during the planning stage and the rework later is far smaller. For related test packages, see testing services and case studies.
When the mapping will not come together, work through it with someone
SUNGO Mobility Testing Lab is the dedicated wheelchair and mobility aid testing lab within our group, accredited by CNAS, CMA and IAS (USA), with laboratories in Shanghai and Hefei. We handle third-party testing of wheelchairs and related assistive products on an ongoing basis, and during the planning stage we can put the hazard list from your risk management file side by side with the tests you intend to run, then confirm line by line which have matching evidence, which are left hanging and which are non-applicable and need a documented reason - so that the mismatch does not surface after every report has already been issued. To discuss a test plan or pricing, call +86 132 4819 8029, or send your existing risk file and test list through request a quote for a first comparison. Please note that accreditation marks only demonstrate that the laboratory has the corresponding technical competence within its accredited scope; they do not constitute a commitment regarding market access outcomes.