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.
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. Many regulatory teams spend 20-40 hours per label just formatting XML and validating against FDA schemas.
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 typically within 1-5 business days
- Address validation errors if submission is rejected
- Resubmit corrected SPL if changes are required
FDA's ESG typically processes SPL submissions within 24-48 hours, but validation errors can extend this timeline by 1-2 weeks depending on the complexity of required corrections. Always validate your SPL file locally using FDA's official validator before submission to avoid processing delays.
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:
SPL XML Format: Content Encoding and Formatting
Beyond structural requirements, SPL format has specific rules for encoding the actual labeling text content.
Allowed HTML Elements in SPL Text
Within SPL
| Element | Purpose | Example |
|---|---|---|
| `<paragraph>` | Standard text paragraph | `<paragraph>Take with food.</paragraph>` |
| `<list>` | Bulleted or numbered lists | `<list listType="unordered"><item>Item 1</item></list>` |
| `<table>` | Tabular data presentation | Used for dosing tables, safety data |
| `<content>` | Inline formatting (bold, italic) | `<content styleCode="bold">WARNING</content>` |
| `<sub>`, `<sup>` | Subscript and superscript | H<sub>2</sub>O or x<sup>2</sup> |
| `<renderMultiMedia>` | Reference to images or graphics | Links to product photos or chemical structures |
| `<linkHtml>` | External hyperlinks | Links to full prescribing information |
Special Characters and Encoding
SPL XML requires proper encoding of special characters to maintain valid XML:
- Ampersand (&) must be encoded as
& - Less than (<) must be encoded as
< - Greater than (>) must be encoded as
> - Quotation marks (") must be encoded as
"when used in attributes - Apostrophe (') must be encoded as
'when used in attributes
Tables in SPL Format
Tables are commonly used for dosing regimens, adverse reaction frequencies, and pharmacokinetic parameters:
Common SPL Format Errors and How to Fix Them
Even experienced regulatory professionals encounter SPL validation errors. Understanding the most common issues saves hours of troubleshooting.
Top 10 SPL Validation Errors
The most effective error prevention strategy is to create an SPL template from a previously-approved, FDA-validated submission for your product or a similar product. Using an existing validated structure as your baseline reduces the risk of structural errors by over 90% and eliminates entire categories of common mistakes like incorrect namespace declarations or missing required elements.
| Error Type | Cause | Fix |
|---|---|---|
| Invalid LOINC code | Wrong section code for content type | Cross-reference FDA's SPL Implementation Guide section codes |
| Missing required sections | Omitted mandatory sections like Dosage and Administration | Add all sections required for prescription drug labeling |
| Incorrect UUID format | Document IDs not properly formatted | Use lowercase UUIDs with hyphens: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx |
| Invalid NDC format | NDC doesn't follow 10 or 11-digit structure | Format as 5-4-2 or 5-3-2 with hyphens: 12345-678-90 |
| Unescaped special characters | &, <, > used without encoding | Replace with `&`, `<`, `>` |
| Incorrect namespace declarations | Missing or wrong xmlns attributes | Copy exact namespace URIs from FDA examples |
| Invalid effectiveTime format | Date not in YYYYMMDD format | Use 20260124, not 2026-01-24 or 01/24/2026 |
| Mismatched setId between versions | Changed setId when updating label | Always use the same setId root for all versions of a product |
| Empty required elements | Elements present but containing no content | Either populate with required data or remove if truly optional |
| Invalid styleCode values | Non-standard formatting codes | Use only FDA-approved styleCodes: Bold, Italics, Underline |
SPL Validation Tools
Several tools can catch SPL format errors before FDA submission:
1. FDA SPL Validator
- Official FDA tool available at https://www.fda.gov/ForIndustry/DataStandards/
- Validates against current SPL schemas and business rules
- Free to use but requires manual file upload
2. Commercial SPL Editors
- Software like PakMed, Apollo, and Labeling Solutions provide real-time validation
- Built-in templates for common section structures
- Automated LOINC code assignment based on content
3. Open-Source Validators
- XML editors with schema validation (Oxygen XML, XMLSpy)
- Can validate structure but may miss FDA-specific business rules
“Best Practice: Always validate SPL documents using FDA's official validator as the final check before submission, even if using commercial tools during authoring.
Differences Between SPL Format Versions
SPL format has evolved since its initial adoption. Understanding version differences prevents submission errors when updating older labels.
SPL Format Evolution
SPL format has been updated multiple times since its initial release in 2005. Key milestones include:
- 2005: Initial HL7 CDA-based format established
- 2009: SPL became mandatory for electronic drug labeling submissions; Highlights section requirements introduced
- Subsequent updates: FDA has periodically revised the SPL Implementation Guide to enhance product information sections, improve support for combination products and biosimilars, and expand international coding support
Consult the current FDA SPL Implementation Guide for the latest version requirements.
Migrating Between SPL Versions
When updating an older SPL document, these elements typically require revision:
- LOINC codes - Some codes deprecated or reassigned to new concepts
- Highlights structure - Earlier formats may lack proper Highlights section
- Product identification codes - NDC format requirements tightened over time
- Stylesheet references - Newer stylesheets render content differently
Migration checklist:
- Update schema references to current FDA-approved version
- Verify all LOINC codes against current SPL Implementation Guide
- Restructure Highlights section if originally absent
- Validate NDC codes follow current 10 or 11-digit standard
- Test rendering with current FDA stylesheets
- Increment version number appropriately
SPL Format vs Other FDA Electronic Formats
Understanding where SPL fits in the broader FDA submission landscape helps regulatory professionals choose the right format for different submission types.
SPL Format vs eCTD
| Aspect | SPL Format | eCTD Format |
|---|---|---|
| Primary Use | Product labeling only | Complete regulatory submission (all modules) |
| Structure | Single XML document | Multi-file hierarchy (modules, folders, PDFs) |
| Content Type | Human-readable labeling text | Clinical data, CMC, nonclinical studies, labeling |
| When Required | Labeling updates, establishment registration | NDA, ANDA, BLA, IND submissions |
| Validation | SPL schema + business rules | eCTD validation + SPL validation for Module 1.14 |
| Submission Gateway | FDA ESG (standalone) or within eCTD | FDA ESG (eCTD envelope) |
Key Point: SPL documents are often included within eCTD submissions as Module 1.14 (Draft Labeling) but can also be submitted standalone for post-approval labeling changes.
SPL Format vs FHIR
Some regulatory professionals confuse SPL with newer FHIR (Fast Healthcare Interoperability Resources) standards:
| Characteristic | SPL (HL7 V3) | FHIR (HL7) |
|---|---|---|
| Technology Base | XML with HL7 CDA | JSON/XML with RESTful APIs |
| FDA Requirement | Mandatory for drug labeling | Not currently required |
| Data Structure | Document-centric | Resource-centric |
| Use Case | Regulatory labeling submissions | Real-time healthcare data exchange |
| Adoption | Universal in pharma submissions | Growing in EHR integration |
| Validation Tooling | Mature, FDA-provided | Emerging, vendor-dependent |
FDA continues to require SPL format for all labeling submissions despite the healthcare industry's broader shift toward FHIR for other data exchange purposes.
Creating SPL Format Documents: Best Practices
Successfully creating compliant SPL documents requires a systematic approach combining technical accuracy with regulatory knowledge.
SPL Authoring Workflow
Step 1: Prepare Source Content
- Finalize all labeling text in approved format (Word document typically)
- Ensure all required sections present per FDA labeling regulations
- Obtain approval signatures before technical formatting begins
Step 2: Convert to SPL XML
- Use SPL editor software or manual XML authoring
- Assign correct LOINC codes to each section based on content type
- Generate unique UUIDs for document, set, and section IDs
- Encode all special characters properly
Step 3: Add Product Identification Data
- Insert correct NDC codes for all product presentations
- Add UNII codes for all active ingredients
- Include DUNS number for labeler/manufacturer
- Populate product characteristics (dosage form, route, strength)
Step 4: Validate Locally
- Run SPL through commercial validator or XML schema checker
- Verify all required elements present and properly nested
- Test rendering with FDA XSLT stylesheet
- Review human-readable output for formatting issues
Save copies of your SPL file at each validation stage and document all errors found and corrected. This creates an audit trail demonstrating due diligence in validation and gives you a quick reference if similar errors appear in future submissions. FDA appreciates seeing this level of documentation in your submission package.
Step 5: FDA Validation
- Submit to FDA SPL Validator before official submission
- Address all validation errors and warnings
- Revalidate after any corrections
- Document validation results for submission package
Step 6: Package and Submit
- Create submission folder structure per FDA requirements
- Include SPL XML, images, and supporting files
- Generate MD5 checksum
- Submit through ESG with appropriate metadata
Quality Checks Before Submission
Before submitting any SPL document to FDA, verify these critical elements:
- [ ] SetId matches previous submissions for this product (if updating)
- [ ] Version number incremented correctly from previous submission
- [ ] EffectiveTime reflects current label approval date
- [ ] All NDC codes formatted as 10 or 11-digit with proper segmentation
- [ ] LOINC codes match section content appropriately
- [ ] All required sections present for submission type
- [ ] No unescaped special characters (&, <, >) in text content
- [ ] Tables and lists properly formatted and nested
- [ ] Images referenced correctly with renderMultiMedia elements
- [ ] XSLT stylesheet rendering produces readable output
- [ ] FDA SPL Validator shows zero errors
SPL Format Compliance: Regulatory Context
Understanding the regulatory framework behind SPL format requirements helps contextualize why technical details matter so much.
Legal Basis for SPL Requirements
FDA's authority to require SPL format stems from several regulatory provisions:
21 CFR 314.50(l)(1) - Requires prescription drug labeling in an electronic format that FDA can process, review, and archive. SPL satisfies this requirement.
21 CFR 207 - Establishes drug registration and listing requirements, mandating electronic submission using SPL format for all listing information.
Section 505(b)(1) of FD&C Act - Requires submission of complete labeling with NDAs. SPL is the required format for this labeling.
Enforcement and Non-Compliance
FDA can take regulatory action for SPL non-compliance:
- Refuse to File (RTF) - FDA may refuse to file an NDA/BLA if labeling not submitted in proper SPL format
- Complete Response Letter - Labeling deficiencies including SPL format errors can trigger submission denial
- Warning Letters - Failure to update labeling in SPL format after approval can result in warning letters
- Marketing Prohibition - Products cannot be legally marketed without current labeling in FDA's SPL database
FDA regularly issues Complete Response Letters citing labeling format deficiencies, and SPL validation errors represent a notable share of these issues. Proper validation before submission significantly reduces this risk.
International SPL Adoption
While SPL format is a US FDA requirement, some international regulators have adopted similar or compatible standards:
- Health Canada - Accepts SPL format for some drug submissions but doesn't mandate it
- European Medicines Agency (EMA) - Uses different structured labeling formats (ePI initiative)
- Japan PMDA - Does not currently accept SPL format; requires different electronic formats
- Australia TGA - Exploring SPL adoption but not yet required
Regulatory professionals working on global submissions must maintain multiple labeling formats for different markets.
Tools and Resources for SPL Format Work
Efficient SPL creation requires appropriate tools and access to authoritative resources.
Software for SPL Creation
| Tool Category | Examples | Best For |
|---|---|---|
| Dedicated SPL Editors | PakMed Author, Labeling Solutions, Apollo Health | Full-featured SPL authoring with validation |
| XML Editors | Oxygen XML Editor, XMLSpy, Notepad++ with XML plugins | Manual SPL coding, schema validation |
| Conversion Tools | Word-to-SPL converters, PDF-to-SPL tools | Migrating existing labeling to SPL format |
| Validation Services | FDA SPL Validator, commercial validation APIs | Pre-submission validation |
Official FDA SPL Resources
| Resource | URL | Purpose |
|---|---|---|
| SPL Implementation Guide | fda.gov/ForIndustry/DataStandards/StructuredProductLabeling | Complete technical specifications |
| SPL Resources Page | fda.gov/industry/fda-resources-data-standards/structured-product-labeling-resources | Tools, examples, guidance documents |
| FDA ESG | fda.gov/industry/electronic-submissions-gateway | Submission portal |
| DailyMed | dailymed.nlm.nih.gov | View published SPL documents |
| SPL Validator | Available through SPL Resources page | Official validation tool |
HL7 and Standards Organizations
- HL7 International (hl7.org) - Maintains the underlying CDA standard that SPL extends
- LOINC (loinc.org) - Maintains the section codes used in SPL documents
- FDA UNII (fda.gov/unii) - Substance identification codes for active ingredients
Learning Resources
For regulatory professionals new to SPL format:
- FDA SPL Implementation Guide - Start here for official requirements
- HL7 CDA Release 2 Specification - Understand the underlying document architecture
- FDA Guidance: Providing Regulatory Submissions in Electronic Format - Contextualizes SPL within broader submission requirements
- Professional Training - RAPS, DIA, and other organizations offer SPL format courses
Key Takeaways
Structured Product Labeling (SPL) format is an HL7-based XML standard required by FDA for submitting prescription drug labeling, package inserts, medication guides, and drug establishment registration information. SPL format encodes both the content and structure of drug labeling in a machine-readable format that FDA uses to populate its drug databases including DailyMed and the NDC Directory.
Key Takeaways
- SPL format is mandatory: All prescription drug labeling submitted to FDA must use the Structured Product Labeling XML format as specified in the SPL Implementation Guide.
- Validation is multi-layered: SPL documents must pass XML schema validation, business rule validation, and stylesheet rendering tests before FDA will accept them.
- SetId consistency is critical: The setId root must remain identical across all versions of a product's labeling; changing it creates a new product registration rather than updating an existing one.
- LOINC codes drive section identification: Each labeling section requires the correct LOINC code matching its content type, as specified in 21 CFR 201.56 and 201.57 for prescription drugs.
- Common errors are preventable: The majority of SPL validation failures stem from incorrect UUID formatting, invalid NDC codes, unescaped special characters, and mismatched section codes - all detectable before submission using proper validation tools.
- ---
Next Steps
Understanding SPL format is essential, but manually creating and validating complex XML labeling documents remains time-consuming and error-prone. A single misplaced tag or incorrect LOINC code can delay your submission by days or weeks.
Need help with compliant SPL submissions? Assyro's AI-powered platform validates labeling content automatically against FDA requirements, catching SPL format errors before they become rejection letters. Our system checks LOINC codes, NDC formatting, section structure, and XML validation in real-time - ensuring your labeling submissions pass FDA gateway validation the first time.
[See how Assyro streamlines SPL compliance →]