Three preconditions, and missing one is enough to sink it
Let us be blunt about this. A coverage rationale is not a paragraph of prose, it is a chain of reasoning someone else can verify. Three things have to hold at the same time.
First, the configurations being covered genuinely share one design basis, and that basis is traceable in the documentation rather than reconstructed after the fact. Second, the differences between configurations can be listed exhaustively, each supported by a design document, with nothing left unexplained. Third, the representative configuration selected is no less severe than any covered configuration on every dimension being tested.
If any one of the three fails, the rationale fails. In practice the second is the one that usually fails. The difference list was compiled by the commercial side from a model table rather than by engineering from design outputs, so internal component substitutions and firmware branches drop out of it. Caught at the planning stage, that costs one document revision. Caught after units have arrived, it costs a new representative selection and a new place in the queue.
Step one: pin the platform definition down
A platform is not a marketing concept, it is a scope that documents can define. Defining it lands on design inputs, design outputs and change control under ISO 13485. Same platform means a shared design input and a shared set of key design outputs, with the differences captured in controlled change records.
Three questions decide whether you are entitled to talk about a platform at all.
- Can every configuration you intend to cover be traced back to the same design input?
- Can each difference between a configuration and the representative be found item by item in the change records?
- Is there a record of when each difference was introduced, what the review concluded, and what the verification produced?
If all three have answers, it is worth moving on to the difference matrix. If they do not, fix the documentation first. Fixing documentation costs far less than shipping extra units and being turned back anyway.
Step two: the difference matrix decides how many units ship
The difference matrix is the vehicle for the whole rationale. Difference dimensions down the left, coverage verdict and supporting argument on the right. Once the table is complete, the number of units is counted rather than debated.
| Difference dimension | Coverable | Supporting argument | What to add when it does not hold |
|---|---|---|---|
| Exterior color, silkscreen, packaging artwork | Usually yes | Does not touch the formulation or the load-bearing structure of body-contacting materials | If the masterbatch formulation differs and contact is involved, add the relevant contacting material evaluation |
| Dimensional differences across a size range | Conditional | Show that the representative sits on the more severe side for load-bearing and structural dimensions | Add structural tests at both ends of the size range |
| Body-contacting material or formulation | Usually no | A material change alters contact risk directly and is hard to replace with reasoning | Add the corresponding contact evaluation for the changed material |
| Power supply arrangement, adapter or supply module | Usually no | A change in the supply path affects electrical safety and disturbance characteristics | Submit samples for each supply arrangement |
| Main control board, drive circuitry | Usually no | A change in circuit topology changes the failure modes | Submit samples for each hardware platform |
| Firmware version or control strategy | Conditional | Show that the difference does not touch safety-related functions or protective logic | Confirm branches that touch safety-related functions separately |
| User interface and display module | Conditional | Show that alarm, prompt and operating logic are unchanged | Differences touching alarms and status indication need separate confirmation |
| Accessory and consumable types | Usually no | Accessories take part in actual use and are part of the configuration | Add the corresponding tests per accessory type |
| Sterilization method or packaging form | No | It changes the finished-product condition directly | Prepare samples for each condition |
| Intended use environment | No | The use environment is an input to the test conditions | Confirm each environment separately |
The table has a second, implicit use. Pull out the rows marked as not coverable and you have the list of configurations that must be submitted this time, at which point the argument about quantity is over. How many units each of those configurations itself needs is a sampling question rather than a coverage question, and the sampling material in the knowledge center deals with it.
Step three: the representative is a set, not a single unit
Here is the point that gets dropped most often. The representative configuration does not have to be the same unit for every test family.
Take an active device. Under IEC 60601-1, the work tied to electrical safety, temperature rise and single fault conditions tends to favor the configuration with the longer power path and the less favorable heating conditions as its representative, while EMC work tends to favor the configuration with more interfaces and more complex communication links. Those two conditions frequently sit on different models. Force one unit to serve both and neither side ends up on solid ground.
The right approach is to select a representative per test dimension and say so in the rationale document: electrical safety work this time is represented by configuration A, because A sits on the more severe side across the listed dimensions; EMC work is represented by configuration B, because B carries the interface set that covers the rest. The dimensions that matter for each can be checked against the focus areas of electrical safety testing and EMC testing.
One more piece of discipline in choosing a representative: do not pick the volume seller, pick the one under less favorable conditions. Picking the volume model is the common instinctive mistake, because it is convenient for the business, but the logic runs backward. A permissive configuration cannot be used to cover a severe one, and no conclusion follows from trying.
Step four: anchor the rationale in risk management
The difference matrix answers what the differences are. Risk management answers whether they matter. ISO 14971 supplies exactly that vocabulary: for each difference, answer two questions. Does it introduce a new hazard? Does it change the probability or the severity of a hazard already identified?
Two noes and the difference is a candidate for coverage. A yes to either and you either add testing or add analytical evidence. Writing that reasoning into the rationale document puts it in a different class from a single sentence saying the structure is the same and safety is not affected.
In practical terms, add one more column to the right of the difference matrix that cites the item number of the corresponding entry in the risk management file, so a reviewer can follow the index through. Documents that point at each other is a large part of why a rationale gets accepted.
Differences that form hard limits
A few categories of difference generally cannot be covered no matter how carefully the rationale is written. Accepting that early is cheaper than trying repeatedly.
- A change in body-contacting material or surface treatment.
- A change in sterilization method, or a move from non-sterile to sterile supply.
- A change in the power supply or battery arrangement.
- A change of main control hardware platform.
- An expansion of the intended use environment or the intended user population.
- A new functional mode, particularly one involving alarm or protective logic.
What these share is that the difference lands directly on the input side of the test conditions. When the input changes, the conclusion does not transfer. That is a matter of logic, not of how the document is written.
Common failure scenarios and their cost
| Failure scenario | Where it surfaces | Cost |
|---|---|---|
| Difference list compiled from a sales model table, internal component substitutions missing | During testing or when the report is used | The coverage conclusion is overturned, and the omitted configurations are submitted again |
| The volume seller chosen as representative | Rationale review | The argument runs backward, a new representative has to be chosen and rescheduled |
| One representative unit shared across all tests | When the report is used | Some tests lack a representative basis and additional testing is requested |
| Coverage intent never stated in writing at the ordering stage | After the report is issued | The report covers only the samples submitted, and nothing can be added afterwards |
| Firmware branches left out of the difference matrix | At the next change | Historical coverage cannot be explained and has to be reconstructed |
| Rationale and risk file do not cite each other | Review | The rationale reads as subjective narrative and carries little weight |
The row with the widest cost gap is the fourth. Coverage intent has to be raised in writing at the ordering stage, because the report is issued against the samples submitted; there is no technical way to slot an unsubmitted configuration into the coverage scope afterwards. That step costs one extra paragraph on the request form and saves a full cycle.
How to lay the rationale document out
It does not need to be a long report. A three-part structure is enough.
- Platform definition and configuration list, stating the intended coverage scope.
- The difference matrix, giving for each dimension the difference description, the coverage verdict, the supporting argument and the risk file index.
- The representative selection conclusion, stated per test dimension with the configuration chosen and the reason for choosing it.
Attach an evidence index after that, listing the item numbers of the design documents, change records and risk management file. What a reviewer wants is verifiability, not length. For how projects with this structure are organized in practice, see the case studies.
Have someone judge whether your coverage holds
The value of a coverage rationale is that it pushes the unit count down from the number of models to the number of dimensions, but push it in the wrong direction and the units you saved come back as a full test cycle. Send us the configuration list, the difference description and the target tests, and we will return a judgement in the framework above: which differences can be covered, which configurations must be submitted separately, how the representative should be chosen for each test family, and where the rationale needs additional evidence indexes. 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. Call +86 132 4819 8029 or request a quote.