SPL Format: Complete Technical Guide to FDA Structured Product Labeling
Structured Product Labeling (SPL) is the FDA-mandated XML format required for all prescription drug labeling submissions. It's an HL7-based electronic standard that encodes both the content and structure of drug labels in machine-readable format, which FDA uses to populate drug databases like DailyMed and the NDC Directory. SPL replaced paper-based labeling in 2005 and remains mandatory for all electronic drug registrations, listing submissions, and labeling updates.
Key Takeaways
Key Takeaways
- SPL is an HL7-based XML standard that replaced paper-based labeling in 2005 and is mandatory for all electronic drug registrations and listing submissions.
- FDA uses SPL data to populate DailyMed and the NDC Directory; a single formatting error can delay submissions by weeks.
- SPL is required under 21 CFR 314.50 (NDA content/format) and 21 CFR 207 (establishment registration and listing).
- SPL authoring and validation can be labor-intensive, especially when organizations manage labeling changes manually.
- A Structured Product Labeling (SPL) format is the FDA-mandated XML standard for submitting prescription drug labeling, package inserts, and medication guides. This standardized electronic format replaced traditional paper-based drug labeling submissions in 2005 and remains the required format for all electronic drug registrations and listing submissions.
- If you're a regulatory affairs professional, labeling specialist, or technical writer preparing drug submissions, understanding SPL format is non-negotiable. A single formatting error can delay your submission by weeks or trigger FDA rejection letters.
- The complexity of SPL XML structure, combined with strict FDA validation requirements, makes manual SPL creation time-consuming and error-prone. Teams that build or revise SPL files manually should expect careful technical review and validation before submission.
- In this guide, you'll learn:
- What SPL format is and why FDA requires it for all drug labeling
- The complete SPL XML structure and required elements
- FDA SPL submission requirements and validation rules
- Common SPL format errors that cause submission rejections
- Best practices for creating, validating, and submitting SPL files
- Tools and resources for SPL format compliance
- ---
What Is SPL Format?
Structured Product Labeling (SPL) is an HL7-based XML document standard that encodes both the content and structure of prescription drug labeling in a machine-readable format. FDA mandates SPL for all electronic submissions of drug establishment registration, drug listing information, and post-approval labeling changes. SPL documents are processed through FDA's Electronic Submissions Gateway (ESG) and automatically populate regulatory databases including DailyMed and the National Drug Code (NDC) Directory.
The Structured Product Labeling (SPL) format is an HL7 (Health Level Seven International) document markup standard that uses XML to encode the content and structure of prescription drug labeling. FDA requires SPL format for all electronic submissions of drug establishment registration and drug listing information.
Key characteristics of SPL format:
- XML-based structure using HL7 Version 3 document architecture with specific schemas for drug labeling content
- Mandatory for all prescription drugs marketed in the United States since June 2009 per FDA regulations
- Includes comprehensive labeling data such as product information, ingredients, dosage forms, routes of administration, warnings, and adverse reactions
- Machine-readable and human-readable allowing both automated processing and visual presentation through XSLT stylesheets
FDA processes a large volume of SPL submissions annually through its Electronic Submissions Gateway (ESG), making it one of the most common regulatory submission formats in use today.
The SPL format serves as the foundation for FDA's National Drug Code (NDC) Directory, DailyMed database, and various drug safety surveillance systems. Without properly formatted SPL documents, pharmaceutical manufacturers cannot legally market prescription drugs in the United States.
Understanding SPL XML Format Structure
The SPL XML format follows a hierarchical structure defined by the HL7 Clinical Document Architecture (CDA). Every SPL document contains a header section with metadata and a body section with the actual labeling content.
Core SPL XML Components
Every valid SPL document must include these essential elements:
| Element | Purpose | Required |
|---|---|---|
| Document Root | Defines XML namespaces and schema references | Yes |
| Header (id, code, title) | Contains document identifiers and classification | Yes |
| Author | Identifies the labeling author (typically the sponsor) | Yes |
| Component/structuredBody | Contains the actual labeling sections | Yes |
| Section | Individual labeling sections (warnings, dosage, etc.) | Yes |
| Code | LOINC codes identifying each section type | Yes |
SPL Header Structure
The SPL header contains critical metadata that identifies the drug product and submission:
Required Document Identifiers
SPL documents use specific UUID-based identifiers that must remain consistent across submissions:
- Document ID (id root) - Unique identifier for this specific version of the label
- Set ID (setId root) - Persistent identifier that remains the same across all versions of a product's labeling
- Version Number - Sequential number incremented with each label update
“Critical Requirement: The setId root must never change for a given product. Changing the setId creates a new product registration rather than updating an existing one.
FDA SPL Requirements and Submission Standards
FDA regulations specify strict requirements for SPL format submissions under 21 CFR 314.50 and related guidance documents. Understanding these requirements is essential for submission acceptance.
Mandatory SPL Submission Types
The FDA requires SPL format for these submission categories:
| Submission Type | SPL Document Code | When Required |
|---|---|---|
| Prescription Drug Labeling | 34391-3 | All marketed Rx drugs |
| OTC Drug Facts Labeling | 34390-5 | All marketed OTC drugs |
| Medication Guide | 42230-3 | High-risk medications requiring patient counseling |
| Patient Package Insert | 42231-1 | Oral contraceptives, estrogens, progestins |
| Drug Establishment Registration | 51726-8 | All drug manufacturing facilities |
| Drug Listing | 53409-4 | All marketed drug products |
SPL Validation Requirements
Before submission, all SPL documents must pass multiple levels of validation:
Use a three-tier validation strategy: (1) Local XML schema validation using an editor like Oxygen XML, (2) Business rule validation with commercial SPL software, and (3) Final FDA validation using the official SPL Validator. This layered approach catches errors early and significantly reduces submission rejection risk.
1. Schema Validation
- Document must validate against FDA's SPL Implementation Guide schemas
- All required XML namespaces must be declared correctly
- Element nesting must follow HL7 CDA hierarchy rules
2. Business Rule Validation
- LOINC codes must match section content appropriately
- NDC codes must follow the correct 10-digit or 11-digit format
- UNII codes for active ingredients must be valid FDA Substance Registration System codes
- DUNS numbers must match registered manufacturer information
3. Stylesheet Validation
- SPL must render correctly using FDA's reference XSLT stylesheets
- Human-readable output must be legible and formatted appropriately
- All sections must display in the correct order per FDA labeling regulations
FDA ESG Submission Process
SPL documents are submitted through FDA's Electronic Submissions Gateway (ESG) using this workflow:
- Package SPL XML with associated files (images, stylesheets) in eCTD format
- Generate MD5 checksum for integrity verification
- Submit through ESG with appropriate submission metadata
- Receive acknowledgment and any validation or processing messages through FDA's electronic submission channels
- Address validation errors if submission is rejected
- Resubmit corrected SPL if changes are required
Validate the SPL file locally before submission and confirm that the document renders correctly using FDA-recognized tools and resources. Processing timelines vary depending on the submission pathway and whether validation issues need correction.
SPL Submission Format: Section-Level Requirements
The body of an SPL document contains multiple sections, each identified by specific LOINC codes that dictate the content type and required structure.
Required Labeling Sections (Prescription Drugs)
For prescription drug labeling (PLR format), FDA requires these specific sections:
| Section Name | LOINC Code | Content Requirements |
|---|---|---|
| Highlights of Prescribing Information | 34391-3 | Summary box with key safety info, must be ≤ 1/2 page |
| Indications and Usage | 34067-9 | FDA-approved uses for the drug product |
| Dosage and Administration | 34068-7 | Recommended dosing, route, administration instructions |
| Dosage Forms and Strengths | 43678-2 | Available presentations (tablets, vials, etc.) |
| Contraindications | 34070-3 | Situations where drug should not be used |
| Warnings and Precautions | 43685-7 | Important safety information and monitoring |
| Adverse Reactions | 34084-4 | Side effects observed in clinical trials |
| Drug Interactions | 34073-7 | Known interactions with other drugs |
| Use in Specific Populations | 43684-0 | Pregnancy, pediatric, geriatric considerations |
| Description | 34089-3 | Chemical structure, active ingredients, formulation |
| Clinical Pharmacology | 34090-1 | Mechanism of action, pharmacokinetics, pharmacodynamics |
| Nonclinical Toxicology | 34091-9 | Animal study safety data |
| Clinical Studies | 34092-7 | Pivotal clinical trial results supporting approval |
| How Supplied/Storage and Handling | 34069-5 | Package configurations, storage requirements |
| Patient Counseling Information | 34076-0 | Information to communicate to patients |
Section Nesting and Hierarchy
SPL sections can contain subsections up to 5 levels deep. Proper nesting is critical for validation: