Why Test Reports Get Rejected, and How to Self-Check

First work out which kind of rejection you have

A report can come back at three points, and the handling and the cost are entirely different. Identify which one you are dealing with before deciding how to fix it.

The third kind is not common, but the time it consumes is close to unrecoverable. And most of its triggers were locked in during the few minutes spent filling out the test request form. Self-checking therefore belongs on the request form, not on the report pages.

The request form is where the mines are

Seven fields on the request form decide whether the report will be accepted. Here is how each of them should be filled.

Product name. Keep it identical to the name used in the technical documentation and the quality system documents. Do not use a sales name, a project code or an internal shorthand. When the name does not line up, an external party cannot connect the report to the product, and that is a hard rejection to talk your way out of, because it involves no technical dispute at all, only traceability.

Model and specification. State which specific configuration is being submitted this time. If the intent is to cover a family with one configuration, the coverage relationship has to be stated at the time of ordering, with the rationale attached. It cannot be explained after the report is out, because the report is issued against the samples submitted and nothing can be added to it retroactively. How to write a coverage rationale is its own topic, covered in the knowledge center.

Intended use. It drives the choice of contact category, use environment and test conditions. Write it vaguely and there is no basis for method selection. Write it in a way that does not match reality and the entire method set may be wrong.

Sample condition. Whether the sample is the finished product, whether it has been sterilized, whether it has been aged, and whether it is submitted in its packaging. This is the field that gets filled in carelessly, and it is also where disputes concentrate when a report comes back.

Test methods applied. List only the methods actually performed this time. Piling in every standard in the framework that is remotely related leaves report elements that do not match the tests actually run, which widens rather than narrows the surface for challenge.

Decision rule. ISO/IEC 17025 expects the decision rule to be determined and agreed with the customer before a statement of conformity is given. If nothing was agreed on the request form but the report carries a conformity statement, that is a missing report element, and once it is pointed out the only remedy is a reissued version.

Relationship between the customer and the manufacturer. When the two are not the same entity, spell out the relationship. Under ISO 13485 the manufacturer has purchasing information and verification obligations for externally provided inspection services; a report that cannot be tied to a definite product identification and sample number does not go into the technical file and does not clear internal review.

Sample condition that does not match the goods is the most common source

The laboratory checks incoming samples against the description on the request form, and if they do not match, work cannot start. Four mismatches recur.

• The form says finished product, the goods are bare units without packaging.
• The form says sterilized, the goods carry no sterilization batch identification, so the condition cannot be confirmed.
• The form says a single model, the goods are several configurations mixed in one carton with no external distinguishing marks.
• The model designation on the form is written differently from the sample label, one with a hyphen and one with a space. It looks trivial, but on a report those are two different identifications.

The first two lead to the wrong method being selected. The last two break the traceability of the report. What they share is this: caught on the day the samples arrive, the cost is a phone call; caught while the report is in use, the cost is a fresh sample submission. Walk the pre-submission check against the service process.

Three typical ways method selection goes wrong

Using a general requirement in place of a particular one. Some products have a corresponding particular part alongside the general requirement, and doing only the general part leaves a report that looks incomplete to an external reviewer. Which particular part applies should be confirmed against the current valid version of the standard text.

Borrowing a method from a neighboring product category. Similar construction does not mean the same scope of application. The scope of a method is written in the scope clause of the standard, so confirm your product falls inside it before adopting it.

Target market and standards framework that do not match. The same technical requirement is expressed differently under different frameworks. Choosing the wrong framework does not stop the testing from being completed; it stops the report from being usable. Settle this before ordering rather than after the report is issued.

Frequent rejection points on active devices

Rejections on active medical electrical equipment rarely concern the test data itself. Most concern document consistency. Points that recur under the GB 9706.1 framework:

• Accompanying documents do not match the physical device, with the configuration in the instructions differing from the configuration of the unit submitted.
• Markings and rating plate information are incomplete, or contradict the accompanying documents.
• The configuration and accessory list is incomplete, accessories supplied with the device do not appear in the report, and an external party cannot judge what is covered.
• The operating mode is not declared, leaving the test conditions without a stated basis.
• Detachable parts and external interfaces are not listed in the report.

None of these ask whether the testing was done. They ask whether the report is internally consistent. Checking consistency costs almost nothing, one comparison pass. Failing it puts the credibility of the whole report in question.

How to word the conclusion page so it does not come back

Trouble on the conclusion page usually comes from writing too much, not too little. Four rules.

• The conclusion answers the order and nothing beyond it. What was ordered is what gets answered.
• No blanket statements such as "this product is compliant". Testing covers the samples submitted and the tests ordered.
• No judgement about market authorization outcomes. A test report does not carry that function.
• If opinions and interpretations are included, label them as opinions and interpretations and present them separately from test results. That is a basic ISO/IEC 17025 expectation for report wording.

One rule of thumb: every extra sentence beyond the scope of the order is one more opening for challenge. Restrained wording is harder to reject.

What an accreditation mark actually proves

An accreditation mark only demonstrates that the laboratory holds the corresponding technical competence within its accredited scope. It does not constitute a commitment regarding market access outcomes in the target market.

Three practical consequences follow. Assuming that the presence of an accreditation mark means the report can be used directly for registration in a given market is a common misreading. What actually needs confirming is whether the methods used fall inside the accredited scope, whether the report elements are complete, and whether the decision rule was agreed in advance. Confirm those three and the acceptance rate at the external party becomes predictable. Related questions are collected in the FAQ.

Self-check before submitting

• The product name matches the wording in the technical documentation and quality system documents, with no sales names or internal codes.
• The model designation matches the sample label character for character.
• Any coverage intent has been stated in writing at the time of ordering, with a difference description attached.
• The intended use description is specific down to contact location and use environment.
• The four elements of sample condition are confirmed: finished product or not, sterilized or not, aged or not, packaged or not.
• The methods listed are only those actually performed, and their scope of application has been confirmed.
• The decision rule was agreed before any statement of conformity was given.
• The relationship between customer and manufacturer is stated, and sample numbers map one to one onto definite products.
• For active devices, accompanying documents, markings and the accessory list have been compared against the physical unit.
• The expected wording of the conclusion page has been discussed in advance and contains nothing out of scope.

Running that list takes little time, but what it blocks is exactly the class of problem that can only be solved by doing the work over.

Have someone pre-review your request form

If you are preparing to submit, or you already have a rejected report and need to judge whether it can be salvaged, send us the request information, the sample condition description and the intended use. We will return a pre-review using the logic above, pointing out which fields will stall sample acceptance, which wording will cause trouble once the report is in external hands, and how the conclusion page should be phrased. 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, and keep what can be solved at the ordering stage out of the report stage.