Turning an ISO 14971 Risk Analysis into a Test List

The conclusion first: a test list is the verification evidence for risk control measures

The question we field most often is "what tests does my product actually need". There is only one disciplined answer: the test list comes from the verification needs of your risk control measures, not from copying out the table of contents of some standard. The logic chain in ISO 14971 is explicit - identify hazards, analyse foreseeable sequences of events, estimate risk, implement control measures, then verify both the implementation and the effectiveness of those measures. Every item on the list should be able to answer one question: which control measure does it verify?

The reverse holds too. If a line item in a test report has no matching line in your risk management file, it is either redundant spending or evidence that the risk analysis missed something. "The risk management report and the test report do not match" is a very common category of deficiency, and it is usually not closed out by supplying one more report, because what the reviewer is questioning is the adequacy of the analysis, not a particular data point.

To be clear, this article deals with the correspondence at the methodological level. Clause numbers, test parameters and acceptance limits are governed in every case by the currently effective version of the standard text; no second-hand summary can serve as the basis for submitting samples.

Why "copying the standard's table of contents" eventually fails

Copying a standard's contents page fails in three characteristic ways.

Insufficient coverage. A standard generalises the common risks of a product family; it cannot cover risks specific to your device. New structure, new material, a new drive principle, or an intended use different from what the standard assumed - home use rather than institutional use, paediatric rather than adult - and there is simply no corresponding item in the contents page. Run only the standard items and the hazard identified in your analysis is left in limbo: raised, but never verified.

Excessive coverage. Standards contain a great many requirements that do not apply to a given product. Testing everything indiscriminately stretches the schedule and raises the cost, and if the justification for the not-applicable items is poorly written it generates fresh questions of its own.

Missing justification. Reviewers care not only about what you tested, but why testing those things was enough. That "enough" argument can only grow out of the risk analysis.

From hazard to test item: three steps in between, and skipping one gets it wrong

Step one: write the hazard as a foreseeable sequence of events. "Insufficient frame strength" cannot be converted into a test item. It has to be written as a full chain: user weight combined with dynamic impact creates a stress concentration at a particular welded joint; a crack develops there over prolonged use; the joint then fails suddenly in service, causing a fall and injury. Written to that level of granularity, the verification approach almost presents itself - static strength plus fatigue-type verification, with the critical location already identified.

There is a simple self-test for whether the sequence of events is detailed enough: hand that line to an engineer who was not involved in the design and see whether they can state where to load, how to load, and what failure mode to look for. If they cannot, you are still describing a hazard rather than a sequence of events.

Step two: choose the type of measure according to the control priority. ISO 14971 sets out an order of priority for risk control options (the exact wording is governed by the currently effective version): inherent safety by design first, then protective measures in the device itself or in the manufacturing process, and only then information for safety - instructions, labelling, training. That order directly determines whether a given risk becomes a test item. Risks controlled by design or by protective measures normally need objective evidence of effectiveness, and testing is the main form that evidence takes. Risks controlled by information for safety are usually verified through usability evaluation, label review and instructions review, not bench testing.

Step three: separate implementation verification from effectiveness verification. Whether the measure was implemented is implementation verification - drawings, process documents and first-article inspection will confirm it. Whether the measure works is effectiveness verification, and that is the true source of test items. The shortcut we see in practice is to do only the first and cover the second with a sentence such as "reinforced in the design". The risk management report then reads as complete while resting on no objective data at all.

Mapping hazard categories to verification directions

The table below is a generic mapping framework for turning the output of a risk analysis into an executable test request. Which items are actually run, and against what criteria, has to be confirmed line by line against product structure and intended use, and is governed by the currently effective version of the standard text.

Read the table left to right, not right to left. Sequence of events first, then control measure, and only then the test item. Teams used to working right to left - fixing the item list first and back-filling the risk analysis - tend to produce risk management files that are visibly reverse-engineered.

Note too that one hazard often spans two or even three rows of the table. Take a product with electrical drive: the hazard "moving parts trap the user" may be controlled simultaneously by an anti-trap clearance in the structure, by stall detection and cut-off logic in software, and by a warning in the instructions. Those three measures imply three different verification directions - dimensional and strength verification for the structure, functional-safety-related verification and fault injection for the software logic, and label and instructions review for the warning. Verify only one of them and the other two control measures are still sitting there without evidence.

Which risks should not become test items

This gets overlooked, and the list grows without limit as a result. For the following categories, testing is not the right form of verification:

• Risks controlled by information for safety. These are verified through label and instructions review and usability evaluation. Forcing them into a test request only wastes budget.
• Risks eliminated by process control. These belong to process validation and process monitoring under the ISO 13485 quality management system, evidenced by batch records and process capability data. Type testing does not substitute for that.
• Risks that can only converge on post-market information. ISO 14971 emphasises the collection and feedback of production and post-production information. Some low-probability, long-horizon risks can only be verified progressively through monitoring data, and forcing a pre-market test creates a false sense of certainty.

Sort these three out and the test request gets noticeably shorter, with a defensible reason behind every remaining item. Conversely, if you cannot say what measure controls a given risk or where its verification evidence comes from, the problem is not in the test plan - the risk analysis is not finished.

The traps that come up in real projects

Trap one: treating "complies with the standard" as "risk is acceptable". Standards compliance is an important input to risk acceptability, but it is not the whole of it. Where the product has characteristics the standard does not cover, those still need to be justified separately.

Trap two: control measures written so they cannot be verified. Phrases such as "optimised the structural design" or "increased material strength" cannot be turned into any executable test item. A measure has to be written to the point where the object, the location and the intended effect can all be identified.

Trap three: residual risk never written back. Once results are in, the risk management file has to be updated - has risk been reduced to an acceptable level, how is residual risk evaluated, does anything need disclosing in the instructions for use. Many teams stop at filing the report, and this loop is left open.

Trap four: not revisiting the risk table after a change. A new supplier, a modified mould, an adjusted sterilisation process, a software upgrade - any of these can invalidate an existing test conclusion. The test is whether the change affects a sequence of events already identified or a control measure already implemented. Take a change of raw material grade: even if physical properties are claimed to be equivalent, a body-contacting part may still have a different leachables profile, so the biological evaluation conclusion needs revisiting. If the change is to an internal part that does not contact the body, the impact concentrates in the mechanical and durability direction. The question is always "which sequence of events was disturbed", not "how big was the change".

Trap five: no coverage justification. For products with multiple sizes and models, the choice of which configuration represents the family has to be justified through worst-case analysis. "We picked the model with the highest sales" does not stand up. The worst case is often not the same model in different verification directions: mechanically it points to the least favourable combination of load capacity and dimensions; biologically to the largest contact area and longest contact duration; electrically and for EMC to the configuration at the top of the power range or with the most complex circuitry. Submitting different representative samples from one family for different items is normal, and more rigorous.

What to prepare before submitting samples

Ideally the first thing the laboratory receives is not a sample but your risk documentation. Before placing the request, assemble the following and check them off against the sample submission requirements:

• The risk management plan and the completed hazard analysis list, marking which control measures are intended to be verified by testing
• Structural drawings, the bill of materials, and a description of the parts in direct contact with the body, including the nature of the contact and the expected contact duration - the prerequisite for deciding the biocompatibility evaluation route
• Power supply arrangement, whether there are electrical parts, whether software is included - this decides whether electrical safety and electromagnetic compatibility come into scope; if software is included, state which safety-related functions it performs
• Intended use, use environment, target population, and the foreseeable misuse scenarios associated with them
• A statement of the configuration coverage of the samples and the rationale for the worst case, broken down by verification direction where necessary
• If this is post-change testing, the change description and impact analysis, indicating which existing conclusions you propose to continue relying on

The clearer the material, the fewer rounds of clarification during plan confirmation. In our experience, projects with complete risk documentation move from request to plan appreciably faster than projects where only samples arrive and the laboratory has to infer the item list backwards. In the latter case it is also common to discover halfway through testing that the sample condition or configuration was wrong, requiring rescheduling and further samples.

After testing: write the data back into risk management

Receiving the report is not the end point. A complete loop involves citing the test results in the risk management file as objective evidence of control measure effectiveness; re-evaluating individual and overall residual risk; making corresponding arrangements in the instructions for use and labelling for residual risks that are unacceptable or require disclosure; and feeding the output of this round into the monitoring plan for production and post-production information. Only then do the risk management file and the test report interlock, instead of being two independent sets of documents.

When a result is a failure, the loop still has to be completed, and how it is handled says more about the quality of the risk management file than anything else. The sound path is to go back to the sequence of events and ask whether the failure mode matches the one originally identified. If it matches, the control measure was not strong enough and has to be reinforced and re-verified. If it does not match, a failure path the original analysis did not cover has appeared, so the risk analysis has to be extended first and the verification plan re-derived from it. Simply retesting a different sample, or reading the acceptance criteria generously, leaves traces that surface later in review.

About us

SUNGO Lab (Shanghai Shage Medical Technology Co., Ltd.) is a third-party medical device testing laboratory accredited by CNAS, CMA and IAS (USA), with laboratories in Shanghai and Hefei. We cover electrical safety, electromagnetic compatibility, biocompatibility, sterilisation, packaging and transport, and shelf life, and before you place a request we can help map the conclusions of your risk analysis onto test items - which items have to be run, and which can be answered with other forms of evidence. To be clear, an accreditation mark only demonstrates that the laboratory holds the corresponding technical competence within its accredited scope; it does not constitute a commitment as to market access outcomes in any target market, and whether a product is approved for registration still depends on the regulator's assessment of the complete submission.

If you have a project to scope, call +86 132 4819 8029 or request a quote. We will look at your risk documentation and product information first, then come back with a plan and a schedule.