The decision rule: these are not two names for the same thing, and whether a report can be used depends on the standards list, the sample condition and the issuing party's scope
Type testing answers the question "does this finalized product conform to every item of the standard it is built to?" Registration testing answers the question "does the test evidence used to support safety and performance in the submission dossier hold up?" The test methods overlap heavily, but the two are not equivalent when it comes to the list of applied standards, the condition of the samples, what the report is used for, and how each is handled after a change.
Treat them as one and the same and the typical outcome is that all the samples get tested, the report arrives, and then it turns out it cannot be used in the submission — so you build samples again and reschedule again. Almost all of this rework traces back to a single alignment conversation that did not happen before samples were shipped, not to anything that happened inside the laboratory.
Comparison table: the differences across six dimensions
| Dimension | Type testing | Registration testing |
|---|---|---|
| Trigger point | Product finalization, periodic review, after a significant change | Before submission, or as a supplement during review on request |
| Source of the basis | Every item of the product's applied standard | The list of standards the submission relies on, covering general, collateral and particular requirements |
| Sample condition | Normally finalized, production-representative units | Must match the submitted model, sterilization state and packaging form exactly |
| Coverage | Covers all items required by the applied standard | Covers the items the submitted evidence needs to support, which may be more or fewer than type testing |
| Use of the report | Internal release, system audits, supply to customers | Forms part of the submission dossier |
| Requirements on the issuing party | As agreed in the contract and system documents | Must meet the submission route's requirements on the issuing party and its scope of testing competence |
| Handling after a change | Change control decides whether it is repeated | Assessed on whether the change affects the submitted evidence |
| Form of the conclusion | Normally a pass/fail statement across all items | Must be expressed consistently with the wording of the dossier |
When you read this table, pay attention to the two-way relationship in the "coverage" row. Many people assume registration testing is a subset of type testing; in practice it runs in both directions. A submission may call for supplementary evaluation beyond the applied standard, and it may not need certain items that the applied standard contains. Assume a containment relationship and you will either miss items or overspend.
The key handoff actions: fix the list first, then the samples, then the form of the report
First, lock the standards list before shipping samples. This is the highest-value action in the whole chain. The list needs to cover three categories — general requirements, collateral requirements and particular requirements — with applicability determined by the product's construction, energy type and intended use, and confirmed against the current valid version of the standard text. Shipping samples with the list still open is a gamble.
Put the confirmation in writing, with each side keeping a copy. A verbal confirmation gives you nothing to point to when rework happens, and no way to reconstruct the reasoning that was applied at the time.
Second, the sample condition has to match the submitted condition. Spell out whether the units are production-representative, whether they are sterilized, whether they are in final packaging, whether they are finished product, and whether accessories and attachments are included. A mismatch in sample condition is one of the most frequent reasons a report becomes unusable, and it is the kind of problem that cannot be patched once the report is issued — you start over.
Third, sort out model coverage up front. The relationship between the model submitted for testing and the models it is meant to cover has to be documented at the request stage: construction differences, material differences, functional differences, and why the representative model covers the rest. If the coverage argument does not hold, the remaining models need fresh samples and fresh testing.
Fourth, raise report format and mark requirements early. Report language, accreditation mark requirements, how the conclusion is worded, hard copy versus electronic — raising these at the request stage costs nothing; raising them after the report is issued means reissuing the report.
Work through testing requirements item by item for the full pre-submission checklist, and see our process for the overall sequence of milestones.
What ISO/IEC 17025 and ISO 13485 each govern
ISO/IEC 17025 addresses the competence, impartiality and operation of testing and calibration laboratories. It constrains the party issuing the report: whether methods are validated, equipment is controlled, personnel are authorized, and results are traceable. What the client cares about here is whether the items being submitted fall inside the laboratory's scope of competence.
ISO 13485 addresses the manufacturer's quality management system — design and development verification and validation, change control, supplier management, record retention. A test report is one piece of evidence inside that system; it is not the system.
There is a common misreading between the two that is worth naming: clients assume that once the samples leave the building, responsibility for verification has transferred to the laboratory. It has not. The laboratory is responsible for the data on the items it tested. The manufacturer is responsible for whether those items are sufficient to support the safety and performance of the product. Judging whether the test list is enough is the client's job.
One more thing to state explicitly: laboratory accreditation marks only demonstrate that the laboratory holds the corresponding technical competence within its accredited scope; they do not constitute a commitment regarding market access outcomes. Seeing a mark and assuming the report can be used directly in any context is a high-risk assumption.
When a type test report cannot be used directly for registration
| Situation | What it looks like | Consequence |
|---|---|---|
| Incomplete standards list | Only general requirements listed; collateral or particular requirements missing | Missing items, additional testing on a separate schedule |
| Sample condition mismatch | Non-sterile or non-final-packaged samples were submitted | The affected data is unusable; new samples required |
| Insufficient model coverage | Only one model tested, with no coverage argument | Remaining models need fresh samples and testing |
| Issuing party's scope does not cover it | Some items fall outside its accredited or authorized scope | Results for those items are not accepted |
| Conclusion wording does not match | Report gives data but no verdict, or the basis for the verdict is vaguely worded | Report has to be reissued |
| Sample origin not traceable | No way to show whether the samples represent series production | The evidence chain breaks |
| Missing report elements | Required marks or statements absent | Report has to be reissued |
These seven share one feature: every one of them can be avoided with a single alignment conversation before samples ship, and none of them can be recovered cheaply after the report is issued. That is why experienced teams spend more time at the request stage than newcomers do and still deliver faster overall.
How to schedule so you do not end up reworking
Confirm the basis, then prepare the samples, then submit, then issue the report. The order looks like common sense, but on live projects it is routinely compressed into "ship the samples now and settle the basis while testing runs." The motivation is usually a deadline; the result is usually one extra full scheduling cycle.
The steadier approach is to treat confirmation of the basis as its own milestone, with a named owner and a defined deliverable — a signed standards list. Sample preparation becomes the second milestone, with a sample condition description and a model coverage argument as its deliverables. Only when both are in hand does testing start. Get those first two milestones right and the rest rarely surprises you.
If the product needs testing across several technical disciplines at once, confirm in advance whether those disciplines can run in parallel on the same batch or have to run in series. An unresolved serial dependency is a common source of schedule slippage. Look at how the disciplines combine under testing services before you decide how to split sample batches.
Three failure scenarios and what they cost
Scenario one: type testing was completed against an internal standards list, and at submission the collateral requirements turned out not to be covered. The samples had already been through destructive testing, so new samples had to be built and the whole schedule pushed out by a cycle. The time saved by skipping the basis-confirmation step came back several times over.
Scenario two: engineering prototypes were submitted instead of production-representative units, and after the report was issued the team was asked to demonstrate that the samples were representative — and could not. This is not something an additional document fixes; production units have to be submitted again. Corrected at the planning stage it costs nothing; corrected after prototypes are already on the bench it means rescheduling.
Scenario three: a multi-model product was submitted with a single model, and the coverage argument was left to be written later. When it came to writing it, the construction differences between models turned out to fall outside what could be covered. Every remaining model had to be tested, at a cost close to running the whole campaign again.
What these three have in common is that the failure was never in the laboratory's testing work — it was in the alignment between client and laboratory. When nobody owns that step, the probability of rework rises sharply. Exactly how the applied standards and acceptance criteria should be worded on the request form is a separate topic in its own right; for the questions that come up most often, start with the FAQ.
If you want both lines covered by one round of sample submission, 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. We work with both the type testing line and the registration submission line and know where their bases diverge. Before you ship samples, we can align the standards list, the sample condition and the model coverage relationship in one pass, so that as far as possible one batch of samples serves the evidence needs on both sides and you avoid duplicate sample builds and duplicate scheduling.
Call +86 132 4819 8029, or request a quote — send over the product construction, intended use and submission plan, and we will come back with a sample submission plan.