Mapping the Risk Management File to Your Test Reports

The bottom line: that correspondence is, in practice, one traceability table

The relationship between the risk management file and the test report is usually described in the abstract, as testing verifying the effectiveness of risk control measures. True, but not executable. In practice it is a table. On the left, every risk control measure identified under an ISO 14971 framework. On the right, the evidence that verifies it, which may be a specific item in a test report, or an internal verification record, a design review conclusion, or a warning statement in the accompanying documents.

Build that table and the risk management file and the test report line up on their own. Fail to build it and no amount of descriptive text fills the hole. So what follows is not concepts; it is how to design the table, how to fill it in, and who maintains it.

Which columns the table needs

The column count should stay small, but every column needs an explicit filling rule; otherwise each person fills it according to their own reading and the table becomes a new problem in itself. The skeleton below can be used as it stands.

The source of verification evidence column is where the value of the whole table sits. The difference between writing "see the test report" and writing the specific item name is that the latter lets any external assessor walk the entire verification chain without your explanation. Without that, the table is just a memo for your own use.

Three ways it fails to line up, and how to handle each

Case one: the risk management file has a measure and no matching item exists in the test report.

This comes up often. Usually the cause is a measure written too abstractly, along the lines of preventing user contact with live parts through appropriate structural design. Wording like that cannot be mapped onto a specific test. The handling is not to hunt through the report for something that fits, but to go back and break the measure down further, until every line points at something verifiable. Once broken down, some entries land on test items and some land on internal verification or design review, which is normal. Not every risk control measure is verified by external testing. Teams that miss this distinction get stuck in a loop asking why the report does not contain the item.

Case two: the test report has an item and the risk management file has no matching hazard.

This says the risk analysis has a gap. The handling is to extend the risk analysis, not to leave that row blank in the traceability table or to write "not applicable" in it. Note that once the risk analysis is extended, the risk management file goes up a version and the version column in the traceability table follows it, otherwise the next reconciliation runs into the same mismatch.

Case three: both sides have an entry, but the conclusions do not agree.

For instance, the risk management file judges a residual risk acceptable on the basis that it has been verified by testing, while the report's actual conclusion for that item is conditional or carries limitations. In an audit this kind of contradiction does real damage, because it says outright that the two documents were never genuinely reconciled. The handling is to take the report's actual conclusion as authoritative and to go back and revise the wording in the risk management file, not the other way around.

Residual risk wording: do not contradict yourself

Residual risk is where this table most often goes wrong. A few principles that can be applied directly.

First, the basis for a residual risk judgement has to be evidence that already exists, not a plan. Writing that something will be verified by testing while the testing is unfinished builds the conclusion on the future, and one question at audit exposes it.

Second, where a measure is of the information-for-safety type, meaning the risk is controlled by a warning in the accompanying documents, the actual text of that warning is copied into the traceability table rather than replaced with "see the instructions for use". One revision of the manual can void the control measure, and normally nobody goes back to check. How the accompanying documents themselves are verified clause by clause during testing is a separate topic, covered under testing knowledge.

Third, many requirements under an IEC 60601-1 framework are, in substance, general risk control measures. Passing the tests means the general requirements are met; it does not mean the risks specific to your product are covered. Make that distinction explicit in the file, or you invite the impression that a passing report means there is no residual risk, and that impression costs a good deal at review.

Who maintains it, and when it gets updated

Ownership should be singular. If several departments each fill in a slice, the wording will end up inconsistent. Let whoever owns risk management maintain the table, with development and the testing contact supplying input rather than editing it directly.

Fix the update triggers in writing as the following, any one of which starts an update:

• The risk management file is revised.
• Any design change, large or small.
• Any new test report received, or a report correction.
• A change to safety-related content in the accompanying documents.
• A target market is added, or the submission route is adjusted.

Updating on receipt of a new report is the trigger that gets skipped. By the time the report arrives, the project team is normally busy with the next thing, and the table stays on the previous version. Sorting it all out at once before submission then costs far more effort than routine maintenance would have, and by that point memories are vague, so a good deal of the mapping has to be reconstructed from old email.

Where the table sits in the quality system

The traceability table should itself be a controlled document, inside the scope of document control under ISO 13485. In practice there are two placements: as an annex to the risk management report, controlled alongside it, or as a standalone record with its own number. Both work, and the deciding factor is update frequency. Where design changes are frequent, a standalone number is more flexible, because you do not have to disturb the version of the risk management report every time.

Whichever placement you choose, one thing has to hold: the current version has to be findable on the system document list, and that current version has to agree with the version of the risk management file in use. Fail on this and the table becomes a deduction at audit rather than an asset, because it demonstrates an uncontrolled link between documents.

What gets asked at audits and reviews

Working backwards from the questions is the quickest way to see where the table is thin. The frequent ones are these:

• Point at a risk control measure at random and ask where the verification evidence is, with the expectation that you turn to it on the spot.
• Point at an item in a test report at random and ask which risk control it corresponds to.
• Ask why a particular residual risk was judged acceptable, and on what basis.
• Ask which verification evidence is affected after the risk management file was revised, and whether it was re-assessed.
• Ask for the exact wording of an information-for-safety measure and whether it matches the actual text in the accompanying documents.

Answering all of those on the spot shows the correspondence was genuinely built, rather than assembled at the last minute to satisfy an audit. How this has been handled on past projects is shown under case studies, and the material to have ready before submission is listed under submission requirements.

A timing point that gets overlooked

When the traceability table is created decides whether it is a tool or a burden. Created during the planning stage, it works backwards to guide the choice of test items: which measures need external evidence and which are adequately verified in house becomes obvious at a glance, and the scope of work is defined accurately as a result. Created after all the reports are in, its only remaining function is retrospective assembly, and nine times out of ten the assembly reveals gaps, at which point additional testing gets scheduled and costed on somebody else's terms.

The difference is concrete: extra effort at the planning stage is something you can budget for. A gap found after the reports are in costs you a whole cycle.

A note on accreditation scope

One point should be stated plainly: an accreditation mark only demonstrates that the laboratory has the corresponding technical competence within its accredited scope, and does not constitute a commitment regarding market access in the target market. Whether the risk management file is accepted by the competent authority in the target market depends on the local review basis, which is a separate matter from the report itself. Keeping the two apart avoids a fair amount of unrealistic expectation, and saves some backtracking.

Electrical safety items appear frequently in these traceability tables, and their composition is described under electrical safety testing.

Getting the table right the first time

The difficulty in a traceability table is not the format; it is the granularity of the measure breakdown and the mapping of the evidence. Teams doing it for the first time usually rework the step where measures were written too coarsely, taking two or three passes before it settles.

If you want someone to walk the traceability relationships against your existing risk management file and issued reports, or to define during the planning stage which measures should be verified by external testing, call +86 132 4819 8029 with the product type and the submission route, or request a quote directly. SUNGO Lab (Shanghai Shage Medical Technology Co., Ltd.) is a medical device testing laboratory accredited by CNAS, CMA and IAS (USA), with laboratories in Shanghai and Hefei.