Skip to content
GearDock

Reference · Product information

The Product Data a Medical Device Catalog Actually Needs

Most catalogs fail not because a field is missing but because three kinds of fact were stored in one place, so nothing can be trusted at the level it is used.

Reviewed · 5 min read

The Short Answer

A medical device catalog record separates into three layers. Identity says which product this is: manufacturer, model or reference, device identifier, GTIN, and a nomenclature code. Device facts are true of every unit of that model: specifications, dimensions, materials, sterility, intended use and storage conditions, each of which should trace to a manufacturer document. Unit facts are true of one physical unit only: condition, serial number, hours of use, accessories included, warranty, price and availability. Keeping the three apart is what lets a catalog answer a buyer question at the right level, and collapsing them is what makes a listing wrong the moment a unit sells.

At a Glance

Layer 1, identity
Manufacturer, model or reference, device identifier, GTIN, nomenclature code
Layer 2, device facts
Specifications and characteristics true of every unit of the model
Layer 3, unit facts
Condition, serial, hours, accessories, warranty, price, availability
The rule for layer 2
Every value should trace to a manufacturer document, not to a previous listing
The rule for layer 3
Never inherited from the model, and never written once and reused
Where buyers actually filter
Identity and a small number of layer 2 attributes, almost never free text

Ask a catalog team what data they are missing and you will get a list of fields. Ask a buyer why they left the site and you will get something else entirely: they could not tell whether the specification on the page described the model in general or the specific unit being sold. Those are the same problem seen from two ends, and adding fields does not fix it.

Three Layers, Not One Record

Layer 1IdentityManufacturer, model or reference, device identifier, GTIN, nomenclature code.Answers: which product is this?Layer 2Device factsSpecifications, dimensions, materials, sterility, intended use, storage conditions.True of every unit of the model. Needs a source.Layer 3Unit factsCondition, serial number, hours, accessories included, warranty, price, availability.True of one unit only. Never inherited from the model.One catalog record, three kinds of factCollapsing layer 3 into layer 2 is what makes a listing wrong the moment the unit sells.
One device record can carry many unit records beneath it. A catalog that has no layer three has to lie about something.

The layers are not a modelling preference. They correspond to how the facts behave over time. Identity is fixed. Device facts change only when the manufacturer changes the device, which is rare and documented. Unit facts change constantly, and the moment one unit sells, every unit fact on that listing is stale.

Layer One: Identity

Identity is the smallest layer and the one everything else depends on. If a row does not resolve to a specific device, no amount of good writing beneath it is worth anything, because it is attached to the wrong thing.

Identity fields and what each one is for
FieldWhy it existsCommon failure
ManufacturerNarrows candidates faster than any other fieldStored as free text with six spellings of the same company
Model or referenceWhat a buyer types into searchMerged with an internal SKU or a condition note in one cell
Device identifierThe machine readable product keyStored as a whole scanned barcode, so every unit looks new
GTINThe device identifier under the GS1 systemAssumed universal, so HIBCC and ICCBBA records get rejected
Nomenclature codeGroups the device into a recognised categoryAbsent, so category pages are built from guesswork
Internal SKUYour own key for your own systemsUsed as product identity, which nobody outside your company shares

Nomenclature Is the Field Teams Skip and Then Rebuild Badly

Category structures invented in house drift immediately and cannot be reconciled with anything a buyer, a group purchasing organisation or a hospital system uses. A recognised nomenclature code gives category pages a spine that survives a replatform.

Layer Two: Facts About the Model

This is the layer that data synchronisation networks were built for. In the wider healthcare supply chain, manufacturers publish standardised product attributes to distributors, group purchasing organisations and providers through the Global Data Synchronisation Network, using GS1 standards and certified data pools. The attributes exchanged there are a useful guide to what a serious catalog holds, because they are what the buying side asked for.

  • Physical characteristics: dimensions, weight, packaging hierarchy and how many units sit at each level of packaging.
  • Clinical and safety attributes: sterility and method, latex content, MRI safety status, single use or reusable.
  • Materials and construction, where the manufacturer states them.
  • Storage and handling conditions, including temperature and humidity ranges.
  • Intended use as the manufacturer describes it, which is a bounded statement rather than a marketing sentence.
  • Documents: instructions for use, service manuals, datasheets and images, which are attributes in their own right.

Each of these needs a source. Not a citation formatted for a journal, just a traceable answer to the question of where the number came from. A specification that arrived by being copied from a competitor listing is not a specification. It is a rumour with a unit of measurement attached.

Layer Three: Facts About the Unit

Anyone selling used, refurbished or ex demonstration equipment lives in this layer, and it is the one most catalog software has no place for, because most catalog software was built for new goods where every unit is identical.

Unit level fields, and why they cannot live in layer two
FieldWhat it describesWhat goes wrong if it is shared
ConditionThe state of this specific unitEvery unit of the model inherits one unit's condition
Serial numberThis unit and no otherBecomes meaningless, or worse, wrong on the invoice
Hours or cyclesAccumulated use on this unitA buyer decides on the strength of another unit's number
Accessories includedWhat is physically in this boxBuyers receive a different bundle from the one they read about
WarrantyWhat you are offering on this saleA model level statement becomes an unintended promise
Price and availabilityThis unit, todayThe catalog keeps selling something that left the building

How to Find Out What You Are Missing

  1. Define the Target Shape First

    Decide what a complete record looks like for each product type you sell. Without a target, completeness is an opinion and every review meeting reopens it.

  2. Measure the Catalog Against It

    Count how many records have each field populated. The result is usually uncomfortable and always more useful than a sample.

  3. Separate Missing from Unsupported

    A field that is empty and a field that is filled with something nobody can trace are different problems. The second is worse and looks better.

  4. Rank by What Buyers Filter On

    Completing a field nobody searches is work with no return. Start with identity, then the three or four attributes that drive your category filters.

  5. Publish by Coverage, Not Alphabetically

    The records that are ready should go live while the rest are still being worked. Alphabetical order is the enemy of shipping.

GearDock does this measurement as a matter of course. It detects gaps against the target shape, completes what an attached document supports, and reports the rest as gaps rather than filling them. The output that matters is the list of what could not be supported, because that is the list somebody has to act on.

One Thing This Page Is Not

This page explains how a rule is written and what it means for catalog data. It is not legal or regulatory advice, and it does not describe your specific obligations. Confirm those with your own regulatory counsel before acting on them.

Questions

What People Ask About This

What attributes does a medical device catalog need at minimum?

At minimum: manufacturer, model or reference, a device identifier where one exists, and a category. That is enough to identify a product unambiguously. Everything beyond it improves the listing but does not change what the listing is about, and a catalog that gets those four right can be improved incrementally, while one that gets them wrong has to be rebuilt.

What is the difference between a device record and a unit record?

A device record describes a model and is true of every unit of it. A unit record describes one physical item: its condition, serial number, accumulated use, included accessories, warranty and price. Sellers of used and refurbished equipment need both, because the model level facts are stable and the unit level facts change with every sale.

Do I need GDSN to sell medical equipment?

Not to sell, no. The Global Data Synchronisation Network is how manufacturers publish standardised product data to trading partners such as distributors, group purchasing organisations and providers. Whether you participate depends on who you sell to. The attribute set it uses is worth studying regardless, because it reflects what the buying side of the industry actually asks for.

Should I copy attribute values from a manufacturer website?

Copying a value is fine. Copying it without recording where it came from is the problem, because six months later nobody can tell a manufacturer specification from a guess. Keep the source with the value and the catalog stays defensible as it grows.

How do I handle attributes that vary by configuration?

Treat a configuration that has its own identifier as its own record rather than as a variant note in free text. If two configurations of a device carry different device identifiers, they are different records in every system that will ever consume your data, and modelling them as one will not survive contact with a buyer.

Sources

Where This Comes From

Regulatory statements on this page trace to the documents below. They are the authority; this page is a reading of them for catalog teams.

Private Beta

Bring This into Your Own Catalog

GearDock resolves what each product is, writes from the documents you attach, and holds back anything they do not support. A pilot runs it on your catalog with us present.