A product can be authorized while its operating data is scattered across the label, MDMA file, Saudi-DI, ERP, distributor catalogue and NUPCO offer. When those records use different device names, models, manufacturers or descriptions, the mismatch surfaces during supply, traceability, claims and change work. The remedy is an evidence-controlled product identity master rather than repeated manual copying.
The sources do not state that every NUPCO field must be a verbatim copy of every MDMA or UDI field. They show that SFDA requires defined identification and traceability data, while NUPCO uses standardized descriptions and codes to manage government-health demand. The linkage in this article is Basier's operating recommendation: make every channel describe the same product while preserving the purpose and limits of each system.
1 Start with the authorized regulatory unit
MDS-REQ 1 connects MDMA to the device and model scope supplied by the manufacturer. Technical documentation also covers device description, specifications, variants, accessories and manufacturer-supplied information. Every model or configuration should therefore have a known place in the approved scope, and a new marketing name should not conceal a technical difference that has not been assessed.
In a complex portfolio, first establish whether an item is a model within a single device, a family member, a component, an accessory or an independent product. The MDS-G028 bundling rationale defines how models relate in MDMA. It also determines the master-data fields needed to preserve that relationship, including the model identifier, family or system linkage and the evidence that covers the item.
2 The label faces the user and the market
The label and IFU carry intended purpose, manufacturer, identification, warnings and use information. A shortened catalogue name or altered description can broaden the commercial claim beyond the regulatory file. A model mismatch between the package and master data can also break the connection between an order, shipment and complaint.
To turn this analysis into a product-specific plan, review Technical File and Regulatory Readiness Review and the related regulatory insight.
The answer is not to turn every channel into a long copy of the IFU. Use controlled vocabulary for legal device name, trade name, generic description, model or catalogue number, manufacturer, an approved short intended-purpose statement and purchase-relevant restrictions. Each system may display the fields it needs, but each field should have a defined source of truth and owner.
3 UDI is an identity layer, not a label replacement
MDS-REQ 7 requires the manufacturer to manage UDI under an accepted issuing agency and states that UDI does not replace other marking or labeling requirements. UDI includes the UDI-DI, which identifies a manufacturer's device and links to Saudi-DI data, and UDI-PI for production identifiers on the label or package, such as lot, serial, software identification or expiry where applicable.
The requirement also calls for Saudi-DI data to be submitted and maintained, and identifies fields retrieved from SFDA databases such as manufacturer, authorized representative, brand or trade name, device description, risk class and GMDN. This makes data drift visible. If a website or catalogue description changes without review, it may move away from the approved or registered description. Some changes need a record update and some may trigger a new UDI-DI assessment; the answer depends on the change facts and current requirements.
4 The NUPCO catalogue describes demand, not authorization
NUPCO explains that its Unified Directory uses standardized general descriptions and basic codes for items and services needed by government health entities, and that the lists are updated periodically. Catalogue mapping is therefore important for understanding how a buyer sees the category and specification. A NUPCO code does not by itself prove that a specific model is within an MDMA scope.
Maintain a supplier crosswalk that records the NUPCO code and standardized description, then links them to the actual product: model, UDI-DI, MDMA scope, label and offered configuration. Where a standardized description is broader than the product, the offer should retain the product's actual limits. Where a live tender booklet is more specific, its current conditions control the procurement response rather than an old mapping file.
5 One data story matrix
6 Change control protects the market after authorization
A change to trade name, model structure, packaging level, software version or intended purpose should enter change assessment before systems are updated. The assessment identifies every affected record: label and IFU, MDMA, technical file, UDI-DI or Saudi-DI, ERP, distributor catalogue, NUPCO mapping, training material and website. The regulatory impact should determine update sequence rather than the ease of changing one channel.
Assign an owner, source hierarchy, effective date and affected-systems list to each field. After implementation, reconcile a sample across the product page, label file, Saudi-DI record, ERP and NUPCO crosswalk. This does not guarantee authorization or award. It reduces the chance that an item is sold, shipped or investigated under a name that the team cannot quickly trace to the correct regulatory scope.
Data cleanup is not a one-time exercise. Schedule review when a product changes, a catalogue is renewed or the NUPCO directory is updated, and maintain an exception report with the conflicting field, reason, owner and target resolution. Intended differences, such as a general procurement description versus a full intended purpose, should be documented. Unexplained differences in model, manufacturer or UDI-DI remain traceability issues until evidence closes them.
Where systems allow it, prevent a new item from being released until required identity fields and evidence links are complete. Data quality then becomes a defined gate for selling and shipping rather than a cleanup project after a buyer or regulator finds the mismatch.
| Identity element | Controlled reference | Consistency check |
|---|---|---|
| Legal manufacturer | MDMA, technical file and Saudi-DI | Name, address and AR where applicable |
| Trade name and device description | Label, MDMA and Saudi-DI | No broader claim on web or catalogue |
| Model or catalogue number | Approved scope, label and ERP | Every item links to a defined authorization |
| UDI-DI and UDI-PI | MDS-REQ 7, label and Saudi-DI | Device identifier connects to production data |
| NUPCO code and description | Current directory and tender booklet | Crosswalk to model, UDI-DI and MDMA |
| Change status | Change assessment | Owner, effective date and all affected systems |
Official sources
- Last verified
- Last verified
Turn the requirements into a clear plan for your case
Start with an assessment of the device and available evidence before deciding on submission.
-(110-x-70-byksl)-(300-x-200-byksl)-(80-x-80-byksl)-(85-x-85-byksl)-(shʿar).png)