AccessGUDID record keys and versions: reconcile updates without losing identity
FDA’s acquired reference distinguishes the public device record key, public version number, public version date and public version status. The record key identifies a record even if the primary DI changes. Keep those system-generated values separate from the DI and commercial-distribution status when reconciling full releases or updates.
Evidence retrieved 2026-10-06. Source versions and topic-specific limits are listed below.
Observed FDA field relationships
Which fields change this workflow?
FDA Data Elements Reference Table; acquired link labelled December 17, 2024. Entry conditions and edit rules below are transcribed from that version.
The Primary Device Identifier (DI) is the DI portion of the UDI placed on the lowest package level of a device that is required to meet UDI label requirements. If the device is not packaged, the UDI may be on the device itself, thereby satisfying both the UDI label and the direct mark (DM) requirement if the UDI is intended to be permanent. The primary DI is the main (primary) lookup for a medical device and meets the requirements to uniquely identify a device through its distribution and use.
Recorded entry notes and format
Enter the Device Identifier (DI) Number.
If using GS1 as an issuing agency, ensure the check digit is correct and valid as per the GS1 guidelines.
If using HIBCC or ICCBBA as an issuing agency, do not include the check digit/character as part of your DI.
Data type and field length are determined by the individual Issuing Agency structure.
IF Device IS Packaged
Primary DI = DI portion of the UDI on the lowest package level
OR
IF Device is NOT Packaged
Primary DI = DI on the device itself, could be DM DI
GS1: Numeric (Num.), DI may be 12, 13 or 14 digit numeric value. System will append zeros to the left or beginning of DI to save a 14 digit value, include the check digit as part of the DI
HIBCC: Alphanumeric (Alphanum.), with 6-23 characters, DO NOT include the check digit as part of the DI
ICCBBA: Alphanum., with 10 or 16 characters
Data type: Type:
Num. or Alphanum.
Length: min-6, max-23*
*defined by Issuing Agency structure
Indicates whether the device is in commercial distribution as defined under 21 CFR 807.3(b).
Recorded entry notes and format
Auto populated based on Commercial Distribution End Date. If no Commercial Distribution End Date is entered, the status is 'In Commercial Distribution'
Data type: NA
Entry values: In Commercial Distribution; Not in Commercial Distribution
System generated status of a device record associated with a record version change.
Recorded entry notes and format
Auto populated by GUDID system
Data type: Type: Alphanum.
Entry values: New; Update; Delete
Reference limits and edit-rule footnotes
Add = Addition of new data is allowed; Delete = Deletion of entered data is allowed; Edit = Editing of entered data is allowed; None = NO edit, add, or delete are allowed; NA = data element is not able to be changed directly; most are ‘auto-populated’ fields whose information depends on another data element
Note: The above do not apply if the device is “unlocked” for editing. For more information on “unlocking” device records for editing, please visit www.fda.gov/udi [7]
See 21 CFR 830.310 and 830.340 for required data elements. [8]
Most of the information presented here is applicable to GUDID HL7 SPL submissions, but there are some differences pertinent to each submission option. Please refer to the HL7 SPL Implementation package of files for additional details on HL7 SPL xml file submission option. [9]
These are dated FDA reference-table fields, not an automated legal applicability assessment or validated submission. The AccessGUDID download schema is different from the FDA HL7 SPL submission implementation package. No quarantined schema is used.
A mapping worksheet for this workflow
Use this checklist to gather your business or product details before speaking with a specialist. The items below explain what to record and suggest useful supporting documents. You can add your own answers in the editable project brief.
Retain both identities
Keep the source record key and primary DI as separate columns, with source release/version; do not key a migration only by product name.
Useful evidence: Source-to-target identity mapping and prior versions.
Interpret the event in context
Review new/update/delete version status separately from commercial-distribution status and date; investigate changes in the actual source records.
Useful evidence: Version diff and event/status comparison.
Reconcile the imported release
Check missing, changed and unresolved records before promoting a refreshed mapping; preserve prior source bytes and decisions.
Useful evidence: Count reconciliation, exception queue and rollback-ready import receipt.
Work packages and dependencies
Conditional: AccessGUDID record keys and versions: reconcile updates without losing identity — Review the controlled source evidence, prepare the field/relationship mapping described here, resolve exceptions and reconcile the intended records before confirming submission scope.
Questions for providers
Which key anchors record identity when a primary DI changes?
How are public-version events separated from distribution status?
How will you verify a full release and the documented update chain before promotion?
Sources and data dates
Read the official document in context. The audit details identify the precise locators and preserved versions used for this page.
