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

Structured product labeling (SPL) is the FDA-mandated XML-based format for submitting prescription drug labeling, over-the-counter (OTC) drug labeling, and biological product labeling. SPL enables machine-readable, standardized product information exchange between manufacturers and regulatory authorities.

If you're preparing drug labeling for FDA submission, understanding SPL format requirements is not optional. Every prescription drug application (NDA, ANDA, BLA) requires SPL-formatted labeling, and errors in SPL structure or content can delay approval or result in FDA information requests.

The regulatory burden is real: a single SPL validation error can add weeks to your submission timeline, and non-compliant labeling can trigger FDA 483 observations during inspections.

In this guide, you'll learn:

• What structured product labeling is and why FDA requires it
• The complete SPL format specification and XML structure requirements
• How to validate SPL files against FDA requirements before submission
• Common SPL validation errors and how to prevent them
• Step-by-step process for creating compliant SPL documents
• The difference between SPL and other drug labeling formats

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 ( in header)
• Each section ( 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 elements
5. Tag all cross-references using 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 ,