Structured Product Labeling: Complete SPL Format Guide for FDA Drug Labeling 2026

Structured Product Labeling: Complete Guide to FDA's SPL Format Requirements

Key Takeaways

What Is Structured Product Labeling?

Structured product labeling (SPL) is an XML-based document markup standard developed by Health Level Seven (HL7) and adopted by the FDA for electronic submission of product labeling information. SPL uses the HL7 Clinical Document Architecture (CDA) to create machine-readable, structured representations of drug product information.

Key characteristics of structured product labeling:

• XML-based format that encodes labeling content, metadata, and hierarchical structure
• HL7 V3 compliant using the Clinical Document Architecture Release 2.0 specification
• Mandatory for all FDA drug submissions including NDAs, ANDAs, BLAs, and annual labeling updates
• Supports multiple labeling types including prescribing information, patient package inserts, and medication guides
• Enables automated processing of labeling data by FDA systems, healthcare databases, and clinical decision support tools

Why FDA Requires Structured Product Labeling Format

The FDA's mandate for SPL format stems from critical needs in drug safety surveillance, labeling consistency, and public health information access.

Regulatory Background

Prior to SPL implementation, drug manufacturers submitted labeling in unstructured formats (PDF, Microsoft Word) that required manual processing by FDA reviewers. This created several problems:

• Manual data entry errors when FDA staff transcribed labeling into DailyMed
• Delays in making updated labeling information publicly accessible
• Inability to automatically compare labeling across similar products
• Challenges in identifying labeling deficiencies during application review

The FDA's adoption of structured product labeling addresses these issues by requiring machine-readable, standardized format that can be:

1. Automatically validated against FDA labeling requirements
2. Immediately published to DailyMed upon approval
3. Systematically analyzed for safety signal detection
4. Programmatically compared across therapeutic classes

Legal Requirements

FDA labeling requirements for SPL are codified in:

• 21 CFR 314.50(l)(2) for NDA applications
• 21 CFR 314.94(a)(8)(iv) for ANDA applications
• 21 CFR 601.14 for BLA applications
• 21 CFR 314.70(b) for annual labeling updates

Failure to submit compliant SPL can result in:

• Refusal to file (RTF) actions
• Complete response letters citing labeling deficiencies
• Regulatory holds on application approval
• Warning letters for commercial products with non-compliant labeling

SPL Format Structure and Technical Specifications

Core SPL Document Components

Every SPL document consists of three primary structural elements:

XML Namespace Requirements

SPL documents must declare specific XML namespaces to be valid:

The HL7 V3 namespace (urn:hl7-org:v3) is required for all SPL elements. Any SPL file that does not properly declare this namespace will fail FDA validation at the gateway.

Document Header Elements

The SPL header must contain these required elements:

Document Body Structure

SPL format organizes labeling content into numbered sections that correspond to the Physician Labeling Rule (PLR) section ordering:

SPL Section Encoding

Each section must be encoded with the correct LOINC code to ensure proper display in DailyMed and other downstream systems:

SPL FDA Requirements: What Makes Labeling Compliant

Mandatory Content Requirements

FDA labeling requirements for structured product labeling go beyond just XML format compliance. The content itself must meet specific regulatory standards.

Prescription Drug Labeling (PLR Format)

For prescription drugs approved after June 2001, SPL must follow the Physician Labeling Rule content and format requirements:

• Highlights section limited to 0.5 pages
• Boxed warning (if applicable) must appear in both Highlights and Full Prescribing Information
• Recent Major Changes must include section references and dates
• Table of Contents must be auto-generated from section codes
• Specific population subsections must follow standardized ordering (pregnancy, lactation, pediatric, geriatric)

Established Name and Proper Name

SPL format requires specific encoding of drug names:

Product Information Encoding

Beyond the labeling text, SPL must encode structured product data:

Required product elements:

• Active ingredients with UNII codes
• Inactive ingredients (for certain product types)
• Dosage form (using FDA dosage form vocabulary)
• Route of administration (using FDA route vocabulary)
• Product and package NDC codes
• Imprint codes (for solid oral dosage forms)

Example active ingredient encoding:

How to Create SPL Documents: Step-by-Step Process

Step 1: Select the Appropriate SPL Document Type

Different submission types require different SPL document type codes:

Step 2: Generate Unique Document Identifiers

Every SPL document requires a globally unique identifier (GUID) for:

• The document itself (<id root=""> in header)
• Each section (<id root=""> in section)
• The set ID that links all versions of the same labeling

Best practice: Use UUID version 4 format: 550e8400-e29b-41d4-a716-446655440000

Many SPL authoring tools auto-generate these IDs, but manual creation requires UUID generation following RFC 4122.

Step 3: Structure Content into Required Sections

Map your labeling content to the mandatory section structure:

1. Review approved labeling (for supplements/amendments) or draft labeling (for original applications)
2. Identify all required sections based on product type and application type
3. Assign LOINC codes to each section from the FDA-published SPL section vocabulary
4. Nest subsections properly using <component> elements
5. Tag all cross-references using <linkHtml> elements

Step 4: Encode Active Ingredients with UNII Codes

The FDA requires all active ingredients to be tagged with Unique Ingredient Identifiers (UNII):

Where to find UNII codes:

• FDA Global Substance Registration System (GSRS): https://gsrs.ncats.nih.gov/
• Search by ingredient name, CAS number, or chemical structure

Common UNII encoding errors:

• Using CAS numbers instead of UNII codes
• Incorrect UNII for salt vs. base forms
• Missing codeSystem attribute (2.16.840.1.113883.4.9)

Step 5: Validate SPL Against FDA Requirements

Before submission, all SPL documents must pass multiple validation layers:

Step 6: Generate Package and Product Information

For each NDC code associated with the product, create structured package information:

Required package elements:

• NDC code in 5-4-2 format
• Package description
• Package quantity
• Package type (bottle, blister, etc.)

SPL Validation: Common Errors and How to Fix Them

Top 10 SPL Validation Errors

Based on FDA submission data and validation tool reports, these are the most frequent SPL errors:

How to Fix: Missing Required Sections

Error message:

Solution:

1. Review FDA section requirements for your product type
2. Add missing section with correct LOINC code
3. Ensure section has required <code>, <title>, and <text> elements
4. Re-validate against SPL schema

How to Fix: Invalid UNII Codes

Error message:

Solution:

1. Search FDA GSRS for correct UNII: https://gsrs.ncats.nih.gov/
2. Replace incorrect code with valid UNII
3. Verify codeSystem attribute is 2.16.840.1.113883.4.9
4. For combination products, ensure all active ingredients have UNII codes

How to Fix: Malformed XML

Error message:

Solution:

1. Ensure <paragraph> is nested inside <text> element
2. Validate XML structure against SPL XSD schema
3. Use XML editing tool with real-time validation
4. Check for unclosed tags and proper nesting hierarchy

SPL Format vs. Other Drug Labeling Formats

SPL vs. PDF Labeling

SPL vs. eCTD Module 1.3.1

SPL is submitted as part of the eCTD (electronic Common Technical Document) but serves a different purpose:

The key difference: SPL is the authoritative, structured representation of approved labeling, while eCTD Module 1.3.1 contains all labeling-related documents for the submission, including SPL files.

SPL vs. Labeling Text Files

Prior to SPL adoption, sponsors submitted labeling as text files (.txt format). Key differences:

SPL Authoring Tools and Software Options

FDA-Recognized SPL Authoring Tools

Recommended Approach by Company Size

Small biotech (1-10 products):

• Use XML editor (Oxygen or XMLSpy) with SPL templates
• Validate with FDA SPL Validator
• Consider CRO support for first submission

Mid-size pharma (10-50 products):

• Invest in commercial SPL authoring software
• Implement labeling change control workflows
• Train in-house regulatory labeling specialists

Large pharma (50+ products):

• Enterprise labeling management system required
• Integration with global labeling repositories
• Automated validation and submission workflows

SPL Submission Process and FDA Review

Where to Submit SPL Files

SPL documents are submitted through the FDA Electronic Submissions Gateway (ESG) as part of:

1. Original Applications: NDA, ANDA, BLA - SPL in eCTD Module 1.3.1
2. Labeling Supplements: Changes Being Effected (CBE), Prior Approval Supplements (PAS)
3. Annual Reports: Updated SPL reflecting all approved labeling changes
4. Standalone SPL Updates: For minor editorial corrections

SPL Validation at FDA Gateway

When you submit through ESG, the gateway performs automatic SPL validation:

Validation checkpoints:

• XML well-formedness (can the file be parsed?)
• Schema validation (does structure match SPL XSD?)
• Terminology validation (are LOINC, UNII, NDC codes valid?)
• Document ID uniqueness (is this a duplicate submission?)

Possible outcomes:

FDA Review of SPL Content

Beyond automated validation, FDA labeling reviewers assess:

• Consistency with approved indications - Does labeling match what FDA approved?
• Accuracy of safety information - Are warnings, precautions, adverse reactions current?
• Compliance with PLR format - Does structure follow Physician Labeling Rule?
• Completeness - Are all required sections present with appropriate content?
• Clarity and readability - Is labeling understandable to target audience?

FDA may issue information requests or require labeling revisions even if SPL validation passed.

Maintaining SPL Compliance: Ongoing Requirements

When SPL Updates Are Required

FDA regulations require SPL updates in these situations:

SPL Version Control Best Practices

Every time you update labeling, you must create a new SPL version:

Required version changes:

• Increment <versionNumber> by 1
• Update <effectiveTime> to new effective date
• Generate new <id> (document ID) - each version has unique ID
• Keep same <setId> - links all versions of the same product

Example version progression:

DailyMed Monitoring

After FDA approval, your SPL is automatically published to DailyMed (https://dailymed.nlm.nih.gov/).

Monitor DailyMed for:

• Correct display of all labeling sections
• Proper rendering of tables and formatting
• Accurate product metadata (NDC, ingredients, etc.)
• Broken links or display errors

If you identify DailyMed display issues, contact FDA's Labeling Team or submit corrected SPL.

Key Takeaways

Next Steps

Preparing compliant structured product labeling requires expertise in FDA regulations, XML structure, and terminology systems. Labeling errors delay approvals and create regulatory risk.

Organizations managing regulatory submissions benefit from automated validation tools that catch errors before gateway rejection. Assyro's AI-powered platform validates eCTD submissions against FDA, EMA, and Health Canada requirements, providing detailed error reports and remediation guidance before submission.

References