The decision rule: applied standards and acceptance criteria are not two ways of filling in the same box
These two fields on the test request form often get filled in with the same sentence, or only one of them gets filled in at all. They answer two different questions. The applied standard answers "which method do we test by, and which items do we test." The acceptance criterion answers "against which requirement do we judge pass and fail."
In many cases both answers do point at the same document, but they separate as soon as there is a company technical requirement, an additional customer requirement, or several standards in use together. Get it wrong and the direct consequence is a report that can only present data and not a verdict, or a verdict expressed in a form that does not fit its downstream use — either way the report gets reissued. Reissuing a report is not a matter of editing a few words; it means running the full review and authorization cycle again.
Key fields on the request form
| Field | Common mistake | Suggested entry | What the mistake costs |
|---|---|---|---|
| Product name | Trade name or internal code | Generic name plus a description of construction | Report name does not match the documents it will sit alongside; reissue |
| Model and specification | Only the one being submitted | List all models, marking the representative model and the coverage relationship | Coverage fails; remaining models need fresh samples and testing |
| Sample condition | Sterilization and packaging state omitted | State whether sterilized, whether in final packaging, whether production-representative | Biological and packaging results become unusable |
| Applied standards | A single general standard only | List general, collateral and particular requirements individually | Missing items, additional testing on a separate schedule |
| Acceptance criteria | Left blank or "as per applied standard" | State whether judgement is against the product standard, a technical requirement or a customer requirement | Report can give data but no verdict |
| Category of testing | Left blank | State whether exploratory, type, contract or another purpose | The report's usability is limited |
| Sampling method | Left blank | State whether samples were submitted or drawn on site, and describe their origin | Representativeness cannot be explained; the evidence chain breaks |
| Sample disposal | Left blank | State whether samples are returned after testing or disposed of by the laboratory | No samples left for retesting after destructive tests |
| Report requirements | Raised after the fact | State mark, language, number of copies and format at the request stage | Report has to be reissued |
| Contact and approver | Sales contact only | Name someone who can decide technical questions | Confirmations stall mid-project and the schedule idles |
This table is worth printing and taping next to the request form. The person filling in the form is often not the person who sets the technical position, and the information gap between the two is one of the main sources of rework.
Listing the applied standards in full: two different approaches for active and non-active products
Active products normally have a layered set of applied standards: a general requirement covering basic safety and essential performance, then collateral requirements grouped by hazard type, then particular requirements grouped by product category. GB 9706.1 is an example of the general layer; a specific product still stacks the applicable collateral and particular requirements on top of it, with the scope of application confirmed against the current valid version of the standard text.
The frequent mistake when filling in the form is to write only the general layer and leave collateral and particular requirements blank. The laboratory works to the form, so the resulting report is complete at the general layer — but the moment it is used in a context that requires full coverage, the missing items get flagged. Electromagnetic compatibility is normally handled as its own body of work; whether it is needed and which class of requirement applies should be written down at the request stage. See how the items combine under EMC testing and electrical safety testing.
Non-active and protective products work differently and usually land directly on a product standard. Take a product standard such as YY 0469: the standard itself gives both the methods and the requirements, so the applied standard and the acceptance criterion look like one and the same. But as soon as the company technical requirement contains a specification stricter than the product standard, or a customer adds a requirement, the two fields have to be written out separately. For the related combination of items, see mask testing.
Whichever approach applies, one action is common to both: once the standards list is drafted, go back through it line by line and ask "which characteristic of my product does this one correspond to?" Delete the ones that do not map. Add the ones that map but are missing. It does not take long and it blocks most missing-item problems.
Three ways to write the acceptance criteria, and what each leads to
Option one: acceptance criteria identical to the applied standard. This fits products where the standard carries its own requirements and the company has no stricter specification. Having the same content in both fields is reasonable here — but write it out explicitly rather than leaving the field blank. Blank and stated do not carry the same weight.
Option two: acceptance criteria are the company technical requirement. This fits cases where company specifications are stricter than the product standard, or where the product standard does not cover certain characteristics. Submit the technical requirement text with the request form, and make sure the specifications in it are actually judgeable — a qualitative description with nothing to compare against leaves the laboratory unable to issue a verdict.
Option three: data only, no verdict. This fits exploratory testing, development-stage verification and competitor benchmarking. Tick this explicitly on the form so that expectations about the form of the conclusion match on both sides when the report is issued. Choosing this deliberately at the exploratory stage is in fact the economical move — you do not have to run the full item list just to manufacture a verdict.
None of the three is inherently better than the others; only choosing the wrong one costs you. The test is simple: who will read this report in the end, and what are they using it to demonstrate?
Accreditation mark requirements belong at the request stage
Whether the report needs an accreditation mark depends on how the report will be used and what the receiving party requires, and it needs to be settled at the request stage. The reason is that on a report carrying a mark, all the items must fall within the laboratory's corresponding accredited scope. If part of the requested work falls outside that scope, the split has to be arranged in the planning stage rather than discovered when the report is being authorized.
At the same time, be clear that 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. Reading the mark as a pass to anywhere is a common misjudgement. ISO/IEC 17025 constrains the laboratory's technical competence and operating discipline; whether a report satisfies a particular downstream use still has to be confirmed by the client against the receiving party's requirements.
Preparing samples and information
Set the sample quantity against how destructive the test items are, with margin built in for retesting and retained samples. Send the bare minimum and a single retest sends you back to building samples, pushing the schedule straight out.
Write the sample condition description so it is traceable: batch number, production state, whether it has been sterilized, packaging form, whether accessories are complete. Leave out any one of these and the representativeness of the related results can be questioned.
The accompanying documents usually include a product description or construction drawing, the technical requirement text, the model coverage statement, and material information where relevant. How complete these are decides directly how many rounds of back-and-forth the plan confirmation takes. Prepare against the full list in testing requirements.
Self-check before the form goes out
One: in the applied standards field, have all three categories — general, collateral and particular — been considered, and have the ones that do not apply been marked as not applicable?
Two: in the acceptance criteria field, does the entry point at a specific requirement document that can actually be compared against?
Three: does the sample condition description let someone who has never seen the product work out what state it is in?
Four: is the model coverage relationship written out, and was the coverage argument submitted with the form?
Five: are the mark, language and format requirements for the report written on the form, rather than mentioned verbally in a group chat?
Six: does the person signing off have authority to decide technical questions?
These six questions together take very little time and block the large majority of rework. If you hit a wording you are unsure about while filling in the form, ask before you submit rather than letting the laboratory act on a literal reading — the laboratory can only work to what the form says, and it will test what is written.
Three failure scenarios and what they cost
Scenario one: the acceptance criteria field was left blank, so the laboratory treated it as data-only. Once the report was in hand, the receiving party wanted a verdict; going back, the raw records for some items did not contain the full measurements a verdict would require. The outcome was new samples and a full retest. One extra line on the form turned into a complete scheduling cycle.
Scenario two: a multi-model product was submitted with only the tested model written on the form, with the coverage statement left for later. When it was written, the construction differences between models turned out to exceed what could be covered, and every remaining model had to be tested. Writing the coverage argument at the request stage is documentation work; writing it afterwards means new samples and a new schedule.
Scenario three: the sterilization state was left out of the sample condition field, non-sterile samples arrived, and some items required finished-product condition. The mismatch surfaced after testing and the data was unusable. Corrected at the planning stage it costs nothing; corrected after the samples have been through destructive testing it means sourcing material again.
All three point at the same conclusion: the request form is not an administrative document, it is the technical input to the entire test campaign. If the input is unclear, every step downstream amplifies the deviation.
If you want someone to walk the form with you, talk to us
SUNGO Lab (Shanghai Shage Medical Technology Co., Ltd.) is a third-party testing laboratory for medical devices and assistive products, accredited by CNAS, CMA and IAS (USA), with laboratories in Shanghai and Hefei. Confirming standards lists, aligning how acceptance criteria are expressed, building model coverage arguments and defining sample condition is our day-to-day work. Tell us the product construction, the intended use and what the report is ultimately for, and before the formal request goes in we can walk the form with you and pull out the points that would otherwise force a reissue.
Call +86 132 4819 8029, or request a quote and we will put together a submission plan and test list for your product.