UDI and Quality Records: Linking Device ID to Complaint and Service History

Unique Device Identification is useful when quality records actually carry the identifier. FDA's UDI rule (21 CFR 801 Subpart B, 21 CFR 830, and 21 CFR 821 for some tracking) and EU MDR Article 27 plus the UDI and device registration work in EUDAMED are labeling and database requirements. The quality payoff is traceability: a complaint, a service event, a nonconforming implant, and a recall consignee list that all point at the same device instance or lot.

This article is about linking UDI (DI plus PI) into complaint, CAPA, service, shipping, and device-history records so PMS and recalls do not start as a reconstruction project.

DI, PI, and what to store

The Device Identifier (DI) identifies the version or model and the labeler. The Production Identifier (PI) includes lot, serial, expiration, and/or manufacturing date as applicable (21 CFR 801.40; EU uses similar PI elements under MDR Annex VI).

For quality records:

• Catalog-level analysis (complaint rates by model): store DI.
• Lot-level manufacturing and sterility issues: store lot or batch PI.
• Implantable and serialized devices: store serial as well as lot.
• Software as a medical device: store version as PI and treat version like a lot for PMS.

If the complaint form only has free-text product name, you will never trend by DI. Make DI a controlled field, scanned from the label or selected from a validated product list.

Where the identifier must appear

Map each record type:

• Device history / production record: UDI-PI applied or associated at manufacture (21 CFR 820.184 DHR; EU manufacturing records under the QMS).
• Shipping and distribution: DI plus PI on the pack and in the electronic ship record. This is the recall denominator.
• Installation, if applicable: serial and software version at the site.
• Service and repair: incoming serial, software version found, parts lots used, outgoing configuration.
• Complaint (21 CFR 820.198; MDR PMS): DI, PI, software version, accessory UDIs if relevant.
• MDR and MIR vigilance: UDI fields the forms already request.
• CAPA: the scope statement should list DI and lots, not "various pumps."
• Nonconforming product: lot or serial of the rejected units.
• Returned product / RMA: scan UDI on receipt before anyone peels the label.

ISO 13485:2016 clause 7.5.9 (traceability) and 8.2.2 (complaint handling) are the QMS hooks. For implants, clause 7.5.9.2 and MDR implant-card rules add patient-facing identifiers. Quality may not store patient names in the complaint file beyond what vigilance requires. Store the device UDI and the account, and keep patient identity in the legally required channel.

Scanning beats typing

Human-typed serials are a deviation source. Use barcode or AIDC on incoming complaints and service benches. GUDID (accessgudid.nlm.nih.gov) and EUDAMED UDI modules let you verify that a DI exists and matches the name the customer used.

When a customer sends a photo of a damaged label, train complaint staff to read both human-readable text and AIDC. Partial UDIs still belong in the file with a note.

Service history is PMS data

Field service often sees failures before complaint systems do if the customer booked a repair and never opened a complaint. Close that gap.

Require a complaint decision on every service event that involves death, serious injury, or a malfunction that would be reportable if it recurred (21 CFR 803.3 and 803.50; EU serious incident definitions in MDR Article 2(64)-(65) and reporting in Articles 87-89). Even when not reportable, log the UDI and failure code in a service quality extract that PMS reviews.

Parts used in repair have their own lots. A bad capacitor lot across serialized devices is a UDI-PI problem on the spare, not only on the finished device. Link spare UDIs or lot numbers in the service record.

Complaints without UDI

The SOP should say what happens when the customer cannot provide UDI: two contact attempts, request for photo, check shipping history by account and date, then code as UDI unknown with a reason. Do not skip the field. Unknown rate is itself a quality metric. If 40 percent of complaints lack PI, recall effectiveness and rate calculations will be weak, and that is a CAPA.

Building rates that survive an inspection

Pick a denominator you can query: units shipped with that DI in the period, or implant-years if you have serial-level implant dates. Numerators: complaints, reportable events, service malfunctions, by DI then by lot.

A lot that is 3 percent of volume and 30 percent of complaints is a manufacturing or supplier signal. Without PI on complaints, you will only see a noisy model-level rate.

Recalls and corrections

21 CFR 806 and Part 7, and EU FSCA under vigilance, need consignees of specific lots or serials. Distribution records that store UDI-PI make the consignee list a query. Distribution records that store "10 each, catalog 123" make it a project.

For software, the lot is the version in the field. Service records and, where legally available, connected-device data tell you who is still on the bad version.

Labeling control and UDI

UDI on the label is a labeling process. Wrong DI on a correct device is a mix-up with vigilance consequences. Include UDI in artwork control, barcode verification (ISO/IEC 15415 or the grade your procedure specifies), and incoming label inspection.

A printer template change is a labeling change. It needs the same change control as an IFU rewrite.

GUDID and EUDAMED as quality references

The published DI record is a controlled public description of your device. When you change a critical attribute, update the database on the legal clock and update the quality product master in the same change. Complaint staff should see the same device name GUDID shows, or they will mis-code.

Do not treat GUDID as a marketing site. It is a regulatory database. Quality should have read access and a procedure for who may submit changes.

Integration pattern that works

1. Product master: one row per DI with model name, class, sterile flag, serial/lot configuration, software flag.
2. Manufacturing: PI generated or captured at release, stored on the DHR.
3. ERP ship: DI plus PI on every line.
4. Complaint and service: scan or select DI, capture PI, validate against master (unknown DI is a hard stop or a documented override).
5. PMS extracts: join complaints to shipments on DI, and to DHR on lot or serial.

This can live in an eQMS with integration to ERP, or in tightly controlled interfaces. Spreadsheet masters drift.

Complaint form fields that survive an inspection

Minimum fields on the complaint record:

• DI (required if the product is UDI-labeled; override with reason if not)
• PI elements applicable to that DI (lot, serial, expiry, manufacturing date, software version)
• Accessory or constituent DI if a system complaint
• Date of awareness versus date of event
• IMDRF device and patient problem codes
• Service work order number, if any
• Ship-to account and original ship date (looked up, not guessed)

Validate DI against the product master on save. A DI that is not in the master is a counterfeit or gray-market unit, a data entry error, or a device you forgot to load after a new version. All three are quality events.

DHR to ship to complaint: one serial, three records

For a serialized device, the path is:

1. DHR shows serial S, lot L, software version, release date, and the applied UDI-PI.
2. Ship record shows serial S to account A on date D.
3. Complaint or service shows serial S, same DI, and a failure code.

If step 2 is missing serials (only quantity by catalog), you can still trend by DI but you cannot prove which hospital has the unit. That may be acceptable for some class I commodity lots. It is not acceptable for implants and most durable equipment.

Run a monthly reconciliation: serials released minus serials shipped minus scrap and samples. The residual is inventory or a hole. Holes become CAPA.

Kits, procedure packs, and convenience kits

Kits have a kit DI and component DIs. Complaints often name the component the user saw. Store both. FDA UDI guidance on convenience kits and MDR kit rules expect the kit to carry UDI; components may have their own. Write a double-count rule: event coded to the component DI for engineering, kit DI for distribution and recall if the kit lot is the shipping unit.

Reprocessed and returned devices

If you allow returns to service stock, scan UDI-PI on the way in. A unit that went out as v2.1 and comes back as v2.3 without a service record is an uncontrolled change. Quarantine it.

For single-use devices that appear reused, capture the UDI and note reuse as a use scenario. Do not invent a lot history you cannot support.

Third-party servicers

You may not control their records. You can still require UDI on parts you sell them and on complaint files when a hospital reports through you. Distribution of spare boards by lot is how you catch a bad component in the field even when the independent shop does not share work orders.

International PI formats

EU UDI-PI and FDA PI are aligned in concept and not always in barcode syntax (GS1, HIBC, ICCBBA for blood-related devices). Train receiving and complaint staff on the issuing agency you actually use. Do not mix human-readable lot strings that omit the application identifier with scanned strings that include it, or your joins will fail.

Store the issuing agency in the product master. GUDID already has this; copy it.

Auditors will pick one serial

Expect an investigator to hand you a serial from a complaint and ask for DHR, ship-to, service history, and whether that serial was in any FSCA. If those four answers take more than a short query, the UDI program is labeling-only.

Run that drill quarterly with a random serial. Record time-to-file. Put slow drills into CAPA.

Metrics for the PMS dashboard

• Percent of complaints with complete PI
• Percent of service events with serial captured
• Time to retrieve DHR, ship, and complaint for a random serial
• Number of DIs in complaints not in the product master
• Lots with complaint rates above a pre-set control limit

These metrics beat a slide that says UDI implemented.

Training

Complaint and service staff need a short module: how to read a UDI, what DI versus PI is, when to photograph the label, how to handle unreadable marks. Add it to the training matrix next to the complaint SOP.

What good looks like

A PMS packet includes a table of top DIs by complaint rate, a lot alert list, and a UDI-unknown percentage under a defined cap. A recall table lists serials with ship-to and contact status. The CER and PSUR use the same DI groupings.

UDI then does the job the regulations implied: identify the device in every quality story you tell about it.

If complaint, service, and production records need to share one device master, a validated platform helps. cloudtheapp.com/demo is available for a walkthrough. The UDI values on the label remain your regulatory submission.