GUDID portfolio preparation: identifiers, package hierarchy and submission ownership
The acquired GUDID guidance distinguishes the primary device identifier, package identifiers and production-identifier flags. It also separates account roles from web-interface or HL7 SPL submission. Map those relationships and ownership before choosing a tool; a public UDI listing is not regulatory approval.
Evidence retrieved 2026-10-06. Source versions and topic-specific limits are listed below.
Sourced criteria · US
What changes the service scope?
Decision or task
What the source describes
What to prepare
Who owns the account and data quality?
The guidance describes regulatory-contact, coordinator/entry and third-party submission roles, with labeler account responsibilities. [1]
Assign authoritative field owners, approval/access roles and third-party responsibilities; keep private account contact details out of public requirements.
Web entry or HL7 SPL transmission?
The guidance describes a labeler account supporting web-interface and HL7 SPL submission choices. [2]
Compare actual portfolio/change volume, validation, response handling and support; verify current transmission specifications separately.
Which facts belong to the DI record?
The guidance distinguishes device identifiers from production identifiers; production-identifier attributes are represented by flags rather than individual serial/lot values. [3]
Map model/version identity and flags; do not import confidential batch/serial production data as public DI facts.
How do packages relate to the base device?
The guidance describes primary/base and package identifiers for different package configurations, with quantities and relationships. [4]
Prepare a package hierarchy and change log before migration; group package variants in buyer comparisons rather than creating a page per DI.
The acquired guidance is dated; current required/conditional fields, exceptions, XML/HL7 schemas, update status and account onboarding must be verified for the actual portfolio. This is not approval or a complete validated upload.
A scoped evidence and handoff plan
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.
Who owns the account and data quality?
Assign authoritative field owners, approval/access roles and third-party responsibilities; keep private account contact details out of public requirements.
Useful evidence: Role/approval matrix, labeler identity and data-quality responsibilities without credentials.
Web entry or HL7 SPL transmission?
Compare actual portfolio/change volume, validation, response handling and support; verify current transmission specifications separately.
Useful evidence: Portfolio/change counts, system readiness and current method/version register.
Which facts belong to the DI record?
Map model/version identity and flags; do not import confidential batch/serial production data as public DI facts.
Useful evidence: Model/version identity, issuer/DI evidence and documented production-identifier flags.
How do packages relate to the base device?
Prepare a package hierarchy and change log before migration; group package variants in buyer comparisons rather than creating a page per DI.
Useful evidence: Base/package DI hierarchy, quantities, configurations and ownership/change checks.
Work packages and dependencies
Conditional: Portfolio identity, package relationships and submission-method preparation — For this work package, agree the supported criteria, evidence access, covered entities/products and unresolved facts in the table above. Additional services require their own justified scope.
Questions for providers
Which exact actor, product or processing facts support the quoted scope, and what is still unresolved?
How will the listed records reach the responsible people, and who owns each change or authority request?
Which tasks and entities are excluded from the agreement, and which additional services need a separate assessment?
Sources and data dates
Read the official document in context. The audit details identify the precise locators and preserved versions used for this page.
