Set the ground rule first: accompanying documents are an object of test, not an attachment
A common habit on the supplier side is to finish the sample first and drop a hastily typeset manual into the crate at the last moment. That order is backwards. Under the testing logic of GB 9706.1 and IEC 60601-1, the accompanying documents, meaning the instructions for use, the technical description, labels and markings, and package identification, are themselves verified clause by clause. The laboratory does not simply "refer to" them; it treats them as part of what the product claims and verifies them on that basis. Whatever function the document states, a matching part has to be found on the sample. Whatever use environment the document defines, the tests are organised around that environment. Whatever symbol meanings the document gives, the matching marking has to be found on the equipment.
From that follows a single ground rule: an error in the accompanying documents lands on the report as a non-conformity, not as "documentation pending". Those two cost different orders of magnitude to clear. Documentation pending means sending over one more file. A non-conformity means the clause is assessed again, and where a test is involved, run again. Settle this rule first, because every judgement below rests on it.
The error types that keep coming back, and what each one costs
The table below is distilled from samples that were sent back. It covers most of the reasons a project stalls. Walking through it before shipping gets you further, faster, than reading the standard text.
| Error type | What it looks like | Consequence in testing | Cost of the fix |
|---|---|---|---|
| Claims exceed the hardware | The document states a function or accessory that is not present on the sample | The matching test cannot be run; the clause is left open or judged non-conforming | Deleting the claim means re-typesetting and syncing every language version; adding the hardware means re-scheduling |
| Hardware exceeds the claims | The device has ports or removable parts whose purpose and limits appear nowhere in the document | Handled as undeclared, so the assessment can only take the conservative side | Once the text is added, completed related clauses have to be reviewed again |
| Use environment described loosely | Nothing beyond "for indoor use", with no environment category or limiting conditions defined | Test conditions cannot be fixed and the project sits waiting for confirmation | One clarification round, and the whole schedule slips behind it |
| Markings do not match the document | A symbol on the rating plate or the enclosure has no explanation anywhere in the document | The marking verification clause is judged non-conforming outright | Re-silkscreening or re-labelling, and the sample normally has to be shipped again |
| Intended use and user population left fuzzy | No statement of whether the operator is a professional or a lay user | Shifts the assessment basis across several clauses, so it is not a single-point problem | A top-level setting; changing it pulls the submission dossier along with it |
| Language versions disagree | Safety warnings differ between the export version and the domestic version | Both versions are verified and every discrepancy is queried line by line | A full section-by-section version comparison has to be redone |
Of everything in that table, hardware exceeding the claims is the item most often underrated. Engineers tend to assume that what was never written down will never be looked at. In practice, anything the laboratory can see has to be accounted for, and anything not clearly accounted for is handled conservatively.
Deciding it cleanly: change the document, or change the design
When the document and the hardware disagree, two camps usually form internally: amend the document to match reality, or amend the design to match the document. Do not settle it on instinct. Ask these three questions in order and the answer generally falls out.
Is this claim already written into the submission dossier? If it is, deleting the sentence does not close the matter. Once deleted, the dossier and the test report no longer agree, and you will be back here later filling the gap. Cases like this leave two options only: change the design, or send an additional sample.
Does this claim carry a safety meaning? Any statement tied to the means of protection, the power supply arrangement, removable parts or alarm signalling puts the product into an undeclared state the moment it is deleted, and the laboratory can then only assess on a more conservative basis, which is usually harder to pass than the original wording. These cannot simply be struck out either.
Is this claim purely promotional? If it sits in neither the submission dossier nor the safety argument, deletion is the cheaper route. Remember, though, that deleting it in one place means the packaging, the brochure, the foreign-language versions and the online product page all follow. Whatever you miss becomes next round's problem.
Once those three questions are answered, the handling is essentially decided. The hard part is rarely the judgement itself; it is that nobody on the team wants to be the one who admits the claim should never have been written.
When you find it decides what it costs
The same error costs entirely different things depending on the stage at which it surfaces. This section is worth pasting straight into the project chat.
- Found at design review: amend the document, and that is all. Effectively free.
- Found before the sample is built: amend the document and the drawings, run one internal change cycle, and nothing external moves.
- Found after the sample has arrived and testing has started: completed related items may be voided, the sample goes back for re-labelling, and the project is re-scheduled.
- Found at draft report stage: the report has to be withdrawn and reissued, and if the draft already went to a downstream customer or fed an internal decision, the version difference has to be explained as well.
- Found after the report has been issued: a report correction process, with a real cost in both time and credibility.
The conclusion is blunt: finalise the accompanying documents before the sample is frozen, not after. That one habit heads off more trouble than any amount of expedited scheduling can buy back.
The pre-submission self-check: five moves you can make on your own
The order is flexible, but do all five.
- Pull out every sentence in the document that begins with "the device can", "the device supports" or "the device is suitable for", and point at the matching part or function on the sample, one by one. Anything you cannot point at is something to deal with.
- Copy down every marking, symbol and rating plate entry visible on the sample, then go back into the document and look each one up. Anything you cannot find is something to add.
- Lift out the three statements covering intended use, user type and use environment, read them side by side, and confirm they do not contradict one another.
- Confirm that the cover or the footer carries a version identifier, and that this identifier is written into the test application form exactly as printed.
- Where several language versions exist, run a section-by-section comparison, paying particular attention to safety warnings and contraindications.
The engineering time this takes is limited, and it heads off a meaningful share of returns. That is exactly why we schedule the document review ahead of sample receipt; the sequence of milestones is set out under testing process, and what you need to have ready is listed under submission requirements.
Versions: document, sample and report have to point at one state
When the laboratory issues the report, it cites the version identifier of the accompanying documents. If the document was edited during testing while the identifier stayed put, you end up with two files that differ in content and share an identifier, which is an easy thing for a later audit to catch.
The workable practice: fix the document version identifier on the test application form; raise the version for any edit made during the testing period; and tell the laboratory each time you raise it, stating what changed and which completed items it might touch. Do not expect the laboratory to guess which edits are substantive. That judgement needs supporting input from the development side.
Products containing software carry one more layer, because the software version and the document version have to line up. That subject runs long, and a more detailed breakdown sits under testing knowledge, so it is not repeated here.
Do not let the quality system thread break
Accompanying documents are controlled documents. Under an ISO 13485 framework, their preparation, review, approval, issue and amendment all leave a trace. A frequent misstep during testing is that the laboratory raises a document issue, the engineer edits a version on the spot and sends it straight over, and no corresponding change record exists in the system. Come the next audit, you land in the awkward position where the document version cited in the test report cannot be found on the system document list.
The correct handling is that even a temporary clarification made during testing goes through the controlled route; you simply move that route faster. When a document version changes, the list to update includes at minimum the system document list, the submission dossier, the printed packaging artwork, the production work instructions and the after-sales training material. Miss any one of them and it will be pulled out at the next audit.
There is one more detail that tends to get skipped: the change record for a controlled document should state that this change was triggered by a finding during testing. Recording the source is what lets a later review see which problems are systemic rather than treating each one as a one-off.
In electrical safety work, document issues weigh more than people expect
Across electrical safety projects, non-conformities caused purely by documents are no fewer in number than those caused by construction or electrical performance. The reason is not hard to see: structural issues have someone watching them from the design stage, while documents are often rushed out just before delivery. Managing the accompanying documents as a formal design output, rather than as a wrap-up task before shipping, is a shift in mindset that pays back directly. The scope and composition of these projects is described under electrical safety testing.
A note on accreditation scope
You will see various accreditation marks when choosing a laboratory. To be clear on one point: 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 accompanying documents satisfy the target market depends further on how the local competent authority reviews them. So it pays to state the target market, the submission route and the language requirements for the accompanying documents up front, rather than repairing the situation afterwards.
When you want an outside pair of eyes
Problems in accompanying documents have one characteristic: whoever wrote them is too close to the product to spot them. Hand the documents and the sample together to someone whose only job is to check them clause by clause against the standard, and a single pass usually produces a list of issues. We do this at the intake stage rather than waiting until testing is scheduled.
For a pre-submission review of your accompanying documents, or to work out which test items your product actually needs, call +86 132 4819 8029 with the product type and target market, or request a quote for a plan that includes the document review step. 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.