Claude

IntuitionLabs is now a member of the Claude Partner Network – AI training and upskilling with Claude for pharma and biotech. Book a call.

IntuitionLabs
Back to Articles
IntuitionLabs

structured product labeling · spl

Structured Product Labeling (SPL): A Guide to Data Integrity

November 23, 2025
Updated September 7, 2026
35 min read

Updated 2026 guide to Structured Product Labeling (SPL) and data integrity. Covers FDA mandates, EMA ePI roadmap, Health Canada XML-PM, FHIR standards, and ALCOA+ compliance for pharmaceutical labeling.

Structured Product Labeling (SPL): A Guide to Data Integrity
Summary
  1. 01SPL supports structured exchange, validation, search, and reuse, but it does not itself establish data integrity or replace every PDF or paper process.
  2. 02Data integrity requires controlled authoring, approvals, audit trails, retention, access management, and validated systems beyond the SPL document.
  3. 03Structured labeling can improve interoperability and clinical decision support when paired with terminology mappings, governance, and downstream integrations.
  4. 04Regulatory adoption is advancing by jurisdiction, with FDA SPL requirements and phased electronic product-information initiatives elsewhere.
01

Executive Summary

Structured Product Labeling (SPL) is an FDA-adopted document-markup standard for exchanging product and facility information. It can support structured product-data exchange and validation, but it does not by itself establish data integrity or replace every PDF- or paper-based labeling process. ([1]) Regulatory authorities worldwide have mandated or encouraged electronic, XML-based labeling formats to improve accuracy, consistency, and interoperability ([2]) ([3]). Unlike static PDF inserts, SPL is a machine-readable, standards-driven format (HL7 SPL) that embeds rich product metadata and controlled vocabulary references. FDA began requiring prescription-drug label information in SPL in November 2005 under a phased framework. FDA currently identifies SPL as the standard electronic format for the content of prescription-drug labeling, including prescribing information and FDA-approved patient labeling; separate SPL requirements also apply to drug establishment registration and listing. ([4]; FDA SPL codes; FDA SPL resources) In the EU, EMA is developing electronic product information (ePI), which uses a semi-structured common standard based on FHIR; implementation remains phased and subject to jurisdiction-specific legal and operational requirements. ([5]) A 2007 study found that the SPL records available in its dataset covered about 78% of outpatient dispensing events; this historical result should not be treated as a current market-wide coverage estimate. SPL makes specified product information more amenable to structural validation, search, and reuse. ([6]) It does not itself provide audit trails, version control, approvals, or compliance with data-integrity expectations; those controls must be implemented and validated in the systems that author, manage, and publish the content. ([1]) By contrast, unstructured PDFs invite transcription errors, redundant manual workflows and delays ([7]) ([8]). As case studies reveal, leveraging SPL content (often linked to standard terminologies like UNII, SNOMED, NDC, etc.) dramatically improves regulatory workflows and patient safety – for instance, one analysis found an SPL-based system detected four times more drug-allergy issues than legacy methods ([9]). DailyMed makes SPL labeling available through regularly updated download releases. Health Canada began the first mandatory XML Product Monograph phase on July 18, 2025, for specified NDS and EUNDS, subject to stated exclusions. EMA made a draft ePI roadmap available in March 2026; it describes a planned phased transition linked to upcoming legal requirements. ([10]; Health Canada XML PM notice; EMA ePI) FHIR-based ePI standards are under active development for adoption across jurisdictions, but national requirements and implementation status must be confirmed with the relevant regulator. Structured labeling is a useful technical foundation for data-quality and interoperability objectives when supported by appropriate governance and quality controls. ([11])

2005

FDA began requiring prescription-drug label information in SPL

78%

Outpatient dispensing events covered in a historical SPL dataset

25

Products for which companies created ePIs under the common standard

02

Introduction and Background

Pharmaceutical labeling – the Patient Package Insert, Summary of Product Characteristics (SmPC), and related materials – is a critical controlled document. It is produced under Good Manufacturing Practices (GMP) and forms part of the drug’s regulatory submission dossier. Historically, approved label content was provided in paper or unstructured PDF form. However, as the digital age unfolds, regulators and industry alike recognize that static formats cannot ensure the accuracy, traceability, and reliability demanded by modern healthcare. ALCOA+ is a commonly used data-integrity framework describing attributes such as attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring, and available records. It should not be treated as an FDA labeling-specific requirement. Labeling organizations should apply applicable record-control, validation, and approval requirements to their own systems and processes. ([12]) As one industry expert notes, scattering data across different formats (Word, PDF, scanned images, etc.) makes it nearly impossible to keep information “accurate, complete, accessible and legible over time” ([13]). In short, lack of data integrity in labeling not only risks regulatory violations, it can endanger patient safety and delay treatments.

In contrast, Structured Product Labeling (SPL) represents a paradigm shift. SPL is an HL7/ISO-standardized XML format that encodes label content – indications, dosage, contraindications, packaging, etc. – into well-defined tagged fields ([14]) ([15]). This enables labels to be computer-processable in addition to being human-readable. For example, SPL supports structured product information and FDA-maintained terminology resources, including Unique Ingredient Identifiers (UNIIs), dosage forms, routes of administration, units, and coded section headings. Whether narrative clinical content is mapped to SNOMED CT or another clinical terminology depends on the specific indexing or downstream implementation. ([1]) The FDA and industry created SPL to facilitate rapid electronic exchange – the FDA’s 2005 Guidance mandated SPL-format submissions so that “consistent structure and standard terminology are employed to enhance the accuracy and reliability of product information” ([2]). Instead, SPL structures sections and specified product information; narrative content may remain text within coded sections, and SPL itself does not provide an audit trail.

SPL can support data-integrity objectives by making specified product information more structured and amenable to validation, search, and reuse. FDA guidance explains that a key data-integrity goal is ensuring that product information remains accurate and traceable across its lifecycle ([16]) ([17]). In practice, SPL can support schema and business-rule validation, while traceable change histories, approval records, multilingual publishing, and reuse across media depend on the organization’s authoring, quality, and publication systems. As one regulatory expert points out, having “approved, structured modular content… significantly simplifies content management in large organizations” and mitigates risk of errors ([18]). By comparison, manual PDF labeling requires painstaking proofreading and translation for every market, with no automated audit of changes ([19]).

Key Themes: This report examines SPL’s foundations and adoption, the limitations of unstructured labeling, implementation controls, and the current status of structured product-information initiatives. It distinguishes documented technical capabilities from controls that must be provided by an organization’s authoring, quality, and publication systems. Regulatory statements and original research are used for factual claims; vendor material is treated as attributed commentary rather than independent evidence.

F.01
SPL vs. Legacy Systems: Drug-Allergy Issue Detection
03

Traditional (PDF/Paper) Labeling and Its Limitations

Before the SPL era, pharmaceutical companies submitted labeling text as free-form documents (Word or PDF) within the CTD/eCTD module. These static formats are inherently unstructured: human-readable, but opaque to software. Updating or verifying information requires extensive manual effort. A recent industry review notes that static formats like PDF “fell short in the digital age”, leading to redundant manual processes, delayed updates across markets, and high risk of errors and non-compliance ([7]). Indeed, any change to a PDF (even fixing a typo) creates a new file version that must be re-tested for accuracy – a process prone to oversight. In multinational companies, different regional offices often translate or adapt PDFs independently, raising consistency issues.

From a data-integrity standpoint, this model is weak. PDFs are essentially “flat documents” – any data contained within is locked in text form and must be individually re-typed or scanned to be reused or validated. Schlafender Hase (a regulatory consultancy) illustrates the peril: a single misnamed file or missing version can render the information “hard to find and retrieve”, forcing manual curation or even recreating sections ([20]). These manual tactics threaten each element of ALCOA+. For example, Legibility and Consistency suffer when multiple copies or formats circulate, and Attribution is unclear when edits happen offline. The World of Pharma packaging expert Freyr Solutions finds that static labels entail “slow updates, [and] not user-friendly” and are obsolete as patient information becomes digital-centric ([7]).

Another limitation is integration. Modern healthcare systems (EHRs, CPOE, e-prescribing) cannot directly import data from a PDF label. Instead, third parties often maintain their own drug databases (First Databank, Cerner Multum, RxNorm, etc.) which must be cross-referenced manually against label text ([21]) ([22]). This breeds inconsistency: for instance, an error in a PDF label might never propagate to an EHR if ignored. By contrast, structured formats allow linking to central vocabularies (NDC, RxNorm, MeSH, etc.) so that an update in one place can cascade automatically.

Finally, regulatory compliance itself is moving beyond paper. Many agencies now expect electronic submissions (eCTD) and machine-readable content. The FDA has explicitly stated that “all drug labels be submitted electronically” and more user-friendly format under its “electronic labeling guidance” ([23]). Thus, PDF-based approaches increasingly fail to meet the spirit of regulatory data-integrity intent: ensuring that label changes are done systematically, with audit trails. The transition to structured approaches is driven by these shortcomings – the need for “one source of truth” and fine-grained auditability.

04

Structured Product Labeling (SPL): Standards and Scope

Definition and Structure. SPL is an XML-based standard (HL7 Substance Administration RIM) for drug information. The FDA describes it as a “document markup standard approved by Health Level Seven (HL7) and adopted by FDA” for exchanging detailed product and facility information ([24]). In practice, an SPL file contains two main parts: a header with metadata (product IDs, manufacturer data, versioning, package codes, etc.) and a body with discrete structured sections (indications, dosage, side effects, contraindications, storage, etc.) tagged by the SPL schema ([25]) ([26]). The body is organized into coded labeling sections and subsections. For human prescription-drug labeling, FDA instructs authors to select the appropriate LOINC codes for those sections and subsections and to enter the relevant text in each section. Structured product data and controlled terminology may be included where required, but narrative label text is not necessarily normalized into a separate named field for every clinical concept.

Under the hood, SPL leverages the HL7 Reference Information Model (RIM) ([27]) ([28]). In this shared ontology, a Medicine or PackagedProduct is represented as an entity with roles linking to ingredients, dosages, and packaging. For example, the HL7 RIM can model a tablet (PackagedProduct) containing 500 mg of Ingredient X, produced by Company Y, with a National Drug Code (NDC) of 12345-678. Gunther Schadow and colleagues demonstrate that SPL uses RIM to map “medicines, packages and ingredient-substances as entities related through roles” (such as “active ingredient of”) ([27]). This standardization ensures that two labels describing the same product (by NDC or UNII) use identical data structures, rather than free-text names.

Integration with Terminology. A major advantage of SPL is its ease of linkage to global drug databases. SPL uses structured product data and may use FDA-specified controlled terminology, such as UNIIs, dosage forms, routes of administration, units, package information, and coded section headings. FDA’s indexing guidance also describes machine-readable tags for selected labeling concepts. RxNorm, SNOMED CT, ICD, and FHIR can be used by external systems or specific implementations, but they are not universal embedded features of every SPL label. ([1]; FDA indexing guidance)

As a result, a label’s XML can serve as a hub connecting many terminologies. For instance, Schadow et al. describe SPL’s networking of NDC (specific drug), UNII (active moieties), NDF-RT/MeSH (drug classes), and SNOMED-CT (clinical conditions) to enable advanced decision support ([29]). Their “Figure 1” illustrates how a penicillin allergy (SNOMED) can be inferred through an SPL-coded RIM graph linking the patient’s data, the drug’s NDC, and the ingredient’s MeSH classification ([29]). In short, SPL turns package insert fragments into discrete, computable facts that align with pharmacovigilance and EHR systems.

Regulatory Scope. FDA uses SPL for several distinct purposes, including electronic submission of prescription-drug content of labeling, drug establishment registration and listing, and other specified product-data exchanges. FDA’s SPL resources distinguish those uses from eCTD, which is the standard format for many drug applications, amendments, supplements, and reports. FDA began requiring prescription-drug label information in SPL in November 2005 under a phased framework; the scope of a current submission should be confirmed against the applicable FDA guidance and technical specifications. ([4]; FDA SPL codes; FDA eCTD; FDA SPL resources)

DailyMed is maintained by the National Library of Medicine. It provides the most recent in-use labeling submitted to FDA by companies, spanning prescription and nonprescription drugs and additional product categories; its presence on DailyMed should not be read as an FDA verification or approval of every record. ([30]) Non-pharmaceutical product categories are catching up too: the FDA has since extended SPL to cosmetics (MoCRA requirements) and is considering it for medical devices and dietary supplements ([31]) ([32]).

Internationally, SPL or analogous schemas are emerging. The EMA’s ePI (electronic Product Information) initiative is built on ISO-IDMP/FHIR standards that mirror SPL’s goals. In 2022–2023, EU regulators adopted a common XML standard for ePI (covering SmPC, PL, outer label) and ran a multi-country pilot ([33]) ([34]). Likewise, Health Canada replaced its traditional monograph PDFs with a Structured Product Monograph (SPM), a format “similar to SPL” ([35]). Health Canada’s first mandatory XML Product Monograph phase took effect on July 18, 2025, for NDS and EUNDS. The notice excludes several NDS types, including administrative NDS, priority-review NDS, NDS-CV, certain NOC/c submissions, and ANDS; other submission types remain in voluntary transition unless an authorized XML PM triggers a subsequent filing requirement. ([36]) International adoption of structured product information is phased and jurisdiction-specific. In the EU, ePI uses a semi-structured common standard based on FHIR; EMA’s March 2026 roadmap is a draft plan for a phased transition linked to upcoming legal requirements. ISO IDMP/SPOR implementation is likewise phased, and the current mandatory data-submission format for authorised human medicines remains XEVPRM pending replacement in due course. ([5]; EMA SPOR master data)

Structured Product Labeling (SPL) can support pharmaceutical data integrity by providing a standardized, machine-readable representation of specified product and labeling information.

05

Data Integrity and Regulatory Compliance

Data integrity in pharmaceuticals concerns whether information remains accurate, complete, and trustworthy through its lifecycle. Applicable requirements depend on the record, system, and regulatory context. ALCOA+ is a widely used data-integrity framework, not an FDA labeling-specific rule. For labeling workflows, organizations should establish controlled authoring, review and approval, change management, retention, access management, and validation appropriate to the applicable regulatory requirements. ([12])

Structured labeling can make validation, search, and reuse easier than unstructured documents, but it does not inherently establish ALCOA+ compliance. XML schema and business-rule validation can identify specified structural or data-format problems. Controls such as attributable change histories, contemporaneous records, electronic signatures, approval workflows, retention, and access management must be designed, implemented, and validated in the authoring and quality systems that produce and manage the SPL submission. An SPL document may be an authoritative submitted representation, but organizations still need controlled source content and governed publication processes.

FDA’s Indexing SPL guidance addresses machine-readable tags that make selected label content searchable and support automated health-information exchange; audit trails and approval records remain controls of the systems used to author and manage SPL content ([3]; FDA SPL resources). This kind of indexation (e.g. marking the “Contraindication” section with SNOMED or MedDRA codes) is nearly impossible with raw PDFs. A historical AMIA study found that fewer than 70% of terms could be mapped to the terminology used in its SPL-based approach; in its tested system, the approach detected four times as many drug-intolerance issues and involved twice as many patients as the comparison approach ([9]). In short, excessive PDF usage is viewed as a “data integrity sin” – it fragments information and obstructs traceability ([20]) ([37]).

Conversely, the structured approach has been explicitly linked to regulatory outcomes like safety. The EU’s Pharmacovigilance legislation (IDMP/SPOR) and FDA’s Safety Reporting (ICSR) rules all rely on the same robust product identifiers that SPL encourages. When new safety data emerge, structured labels ensure that updates – such as adding a labeled warning – propagate accurately across international systems. Indeed, EMA’s ePI report lists “immediate, harmonized updates of product information” as a key advantage of structured labeling ([38]). By providing one authoritative dataset for each drug, SPL helps both manufacturers and regulators seek consistency – a core tenet of GMP data integrity.

06

Advantages of SPL over PDF: Evidence and Analysis

The case for structured labeling is supported by multiple lines of evidence. First, numerous regulatory and industry commentaries enumerate the practical advantages. For example, industry sources break down SPL’s benefits (Table 1):

T.01
Feature / AspectTraditional Labeling (PDF/Paper)Structured Product Labeling (SPL)
Format & StructureUnstructured static PDF or printed leafletXML-based schema; tagged data fields (machine-readable)
Content UpdatesManual edits per market; prone to transcription errors; slow roll-outAutomated/programmatic updates; version-controlled and centrally managed
Regulatory ValidationPrimarily manual review of documentsSchema-based checks and rule validation (automated QA)
Data ReusabilityMinimal (text locked in document)High (modular XML elements can be reused across media and markets)
Multilingual HandlingEach language version may be managed separatelyMultilingual publishing and consistency controls can be implemented in associated authoring and publishing systems; they are not built into SPL itself
Integration & InteroperabilityOften requires extraction or supplementary data servicesStructured content can support downstream integration, but EHR, API, and FHIR delivery require separate mappings, services, and governance

Table 1: Comparison of traditional labeling formats vs. SPL-based structured labeling.

This table condenses viewpoints from analysts and vendors ([39]) ([7]). In SPL, the format organizes labeling into coded sections and can include structured product data, rather than relying solely on unstructured document text. Updates can be scripted or tracked with digital workflows; in PDFs they are typically manual “word-for-word proofreading” steps prone to human error ([19]) ([7]). Importantly, structured formats are schema-validated: missing a required field will fail automated checks before submission ([18]) ([40]), whereas a PDF can pass human review while still omitting data.

Industry reports also highlight strategic benefits. For example, Billev Pharma (an EU regulatory consultancy) emphasizes that SPL’s strict format “reduces human error and improves data quality,” creating a single source of truth for each label ([41]). Similarly, Freyr Solutions articulates four principal exportable benefits of digital/SPL labeling (see Box 1):

  • Enhanced Compliance: SPL enables automated validation (e.g. XSD schema checks) so that labels automatically conform to regulatory standards. Freyr notes this removes manual guesswork in compliance and “align [s] easily with evolving regulatory requirements” ([42]).
  • Global Harmonization: With SPL’s modular content, updates can be propagated uniformly across countries. For instance, one core authoring stream can feed all local variations, ensuring every market label aligns with the Company Core Data Sheet ([43]).
  • Operational Efficiency: Structured labeling cuts labor. Instead of manually editing multiple Word docs or PDFs, companies automate assemblies of label content. According to Freyr, this “reduces manual workflows” and “saves time and resources during regulatory submissions and updates” ([44]).
  • Patient Safety & Engagement: Timely, accurate labeling directly affects safety. SPL supports “dynamic and interactive” label presentations (even linking to digital patient portals), ensuring that up-to-date information is “accessible to patients and healthcare providers” ([45]).

These points are borne out in practice. An industry market analysis projects that such regulatory compliance drivers will cause the structured label management market to grow at double-digit rates ([46]). Moreover, surveys by EFPIA show companies believe SPL/e-labeling can substantially reduce the risk of medication errors and supply disruptions (for example, real-time updates in ePI can mitigate shortages when a label is changed) ([38]) ([47]).

From a data perspective, SPL labels have also been shown to cover most real-world needs. In a 2007 study, Schadow et al. found that nearly 2,300 SPL labels (on DailyMed) covered about 78% of outpatient dispensing events in the U.S. ([22]). That is, major brand drugs (which make up most prescriptions) were already described in SPL. While SPL at that time covered only ~23% of distinct RxNorm drug entities ([22]), it was sufficient for the bulk of prescriptions. In short, structured labeling already represented the lion’s share of active products. That study concluded SPL content was “sufficient as an exclusive source for drug information” once the FDA’s nationwide listing rule was fully implemented ([48]).

Finally, SPL has demonstrated real clinical value. The 2009 JAMIA study showed that enriching CPOE allergy data with SPL’s structured content (linked to NDF-RT/MeSH) led to four times more detected drug-intolerance issues than previous methods ([9]). This underscores that SPL does not merely improve regulatory record-keeping – it can directly enhance patient decision support, because machine-readable labels can automatically trigger alerts when a patient’s chart has a matching coded allergy or risk factor.

F.02
Structured labeling enables validation and reuse that static documents cannot readily support
Traditional PDF or paperUnstructured
  • Static formats are human-readable but opaque to software.
  • Updating or verifying information requires extensive manual effort.
Structured Product LabelingMachine-readable
  • Labels can be computer-processable as well as human-readable.
  • Specified product information becomes more amenable to validation, search, and reuse.

Authoring, approval, audit-trail, and publication controls remain necessary.

07

Regulatory Initiatives and Standardization

Regulatory agencies have been instrumental in driving SPL adoption, recognizing its data-integrity advantages. In the U.S., the FDA’s regulatory framework now revolves around SPL. FDA’s SPL resources list the final guidance Providing Regulatory Submissions in Electronic Format—Content of Labeling among the applicable SPL guidance documents. The separate SPL Standard for Content of Labeling Technical Qs & As is an October 2009 draft, revision 1 of a December 2005 guidance, and FDA marks it “not for implementation”; it should not be presented as current final guidance. ([1]; FDA draft technical Qs & As) Likewise, the FDA’s Indexing SPL guidance highlights that machine-readable tagging of label content is key for building an “automated health information exchange system” ([3]).

FDA uses different electronic standards for different submission types. FDA identifies eCTD as the standard format for applications, amendments, supplements, and reports submitted to CDER and CBER. Its SPL resources separately cover content of labeling, drug establishment registration and drug listing, and other product-data exchanges. Submission requirements and the materials needed for a particular regulatory action should be confirmed against the applicable FDA guidance and technical specifications. ([49]; FDA SPL resources)

In the European Union, EMA is implementing ISO IDMP through SPOR in phases. Submission and maintenance of data on authorised human medicines is currently mandatory in the XEVPRM format; EMA states that this format will be replaced by an ISO IDMP-compatible format in due course. SPOR therefore should not be described as a generally completed mandate for ISO-IDMP submissions. ([50])

EMA released a beta version of the PMS Public API on 12 June 2026, after an April announcement of a planned June pilot. The beta makes selected public data on EU-authorised human medicines available through a controlled first release; EMA says a move to full public release depends on defined success criteria, including data-quality metrics. ([51]; EMA PMS pilot announcement)

Structured product-information initiatives are jurisdiction-specific. In Canada, the July 2025 XML Product Monograph requirement initially applies to NDS and EUNDS, with specified exclusions and a continuing voluntary transition for other submission types. DailyMed provides regularly updated SPL download releases, while EMA’s ePI pilot made pilot ePIs available through the PLM portal and an API. ([36]; DailyMed download releases; EMA ePI)

Official communications reinforce this. The FDA’s SPL Implementation Guide for cosmetics (under MoCRA) explicitly states that SPL enforces control over crucial product info and “defines the content and structure of product labeling required for submission to the FDA” ([52]). Under MoCRA, cosmetic facility registrations and product listings now use the SPL XML format via the Cosmetics Direct portal, with biennial renewals beginning in mid-2026 ([53]). EMA’s 2023–2024 ePI pilot informed implementation work. Its 2026 ePI roadmap is explicitly marked draft and describes a planned, phased voluntary rollout, including vaccine and oncology milestones, with further implementation detail to be defined following readiness assessment. The roadmap also states that ePI authoring/upload will initially be an additional step alongside current Word/PDF submission. ([5]; EMA draft ePI roadmap) EMA reports that its July 2023–August 2024 ePI pilot enabled companies to create and manage ePIs in regulatory procedures and made pilot ePIs available through the PLM portal and an API. EMA’s draft roadmap describes a phased transition aligned with upcoming legal requirements; these developments do not establish a general present-day replacement of PDF or paper labeling. ([5])

Structured product-information initiatives are advancing at different speeds across jurisdictions. In the EU, the 2023–2024 ePI pilot made pilot ePIs available through the PLM portal and an API, while EMA’s draft roadmap describes a planned phased transition that will evolve with implementation experience and upcoming legal requirements. These developments do not establish a general present-day replacement of PDF or paper labeling. ([5]; EMA draft-roadmap notice)

F.03
Structured product-information adoption is progressing through phased regulatory milestones
  1. 2005FDA prescription-drug labeling

    FDA began requiring prescription-drug label information in SPL under a phased framework.

  2. 2025Health Canada XML Product Monograph

    The first mandatory phase applied to specified NDS and EUNDS.

SPL itself does not provide version control, electronic signatures, workflow controls, or compliance with 21 CFR Part 11; those capabilities, where applicable, must be implemented and validated in the systems and processes used to author and manage the content.

08

Implementation and Technology Considerations

Transitioning to SPL requires new processes and tools. Fortunately, a robust ecosystem has developed. These tools allow non-technical users to input label content via forms or Word templates; the software then generates the underlying SPL XML. For example, FDA provides SPL XForms and the “Cosmetics Direct” portal to assist exporters in creating compliant XML ([54]) ([55]). Numerous vendors (Veeva Vault RIM, PTC/Arbortext, Citeline, IQVIA, Freyr, etc.) offer modules for managing SPL documents and maintaining audit logs. FDA identifies SPL software and conversion vendors as resources, but organizations should assess individual tools and validate their own intended use. SPL itself does not provide version control, electronic signatures, workflow controls, or compliance with 21 CFR Part 11; those capabilities, where applicable, must be implemented and validated in the systems and processes used to author and manage the content.

From a data-viewpoint, SPL adoption also drives harmonization of terminologies. To maximize data integrity, companies must align their internal labels (e.g. chemical names, indications) with regulated standards. The FDA publishes extensive SPL validation terminology lists (e.g. UNII, dosage forms, units) ([56]) that SPL files must comply with. This means a company’s list of ingredients must match the FDA’s UNII code table, and route of administration must come from the standard terms in the SPL schema ([56]). While this adds upfront work (mapping synonyms, updating databases), it massively improves consistency. For example, FDA’s SPL resources provide controlled terminology and validation files, helping submitters use consistent identifiers and terms where applicable. SPOR is EMA’s programme for phased implementation of ISO IDMP master data.

Of course, the switch to SPL is not without challenges. Companies need robust document change-control procedures (SOPs) to handle structured content. They also require IT infrastructure to store and transmit XML data (via FDA’s Electronic Submissions Gateway or EMA’s PLM portal). Training users on new tools is essential: for instance, AgencyIQ reports that EMA’s ePI portal initially had quirks (formatting issues, navigation bugs) that firms had to learn to work around ([57]). Smaller companies, in particular, may lack in-house expertise and outsource SPL preparation to service providers (IQVIA, Vantage, Schreiner MediPharm, etc.).

Integration is another technical hurdle. Organizations must connect their regulatory systems (often separate for pharma, medical devices, etc.) and possibly merge legacy content libraries. A major benefit is realized when SPL data flows downstream: e.g., into Quality Management Systems, labeling workflow tools, and even directly to pharmacy databases. Modern strategy is to treat SPL as master data: once encoded, label elements can feed into analytics (e.g. tracking how often a warning is cited), or populate e-learning modules. The industry trend is towards single-source publishing, where the same structured module provides both the regulation-required label and other outputs like marketing materials or patient leaflets, preserving data integrity at each step.

In summary, while implementing SPL requires discipline and possibly new investments, the consensus is that the gains far outweigh the costs. Expert advisories emphasize automated validation and integration as key: “automated schema checks, reducing human error and regulatory rejections,” and “integration with ePI by positioning companies for long-term digital transformation” ([58]). The payoff in data integrity is the elimination of many manual steps (and errors) that plagued legacy workflows.

09

Case Studies and Evidence from Practice

Clinical Decision Support Enhancement: Schadow et al. (JAMIA, 2009) provide a concrete health-IT case. They compared a traditional allergy checking system with a new system based on SPL-spun data supplemented by standard terminologies ([59]) ([9]). Running both on 30 years of patient data, the SPL-based approach “detected four times as many drug-intolerance issues on twice as many patients” ([9]). This striking result came even though <70% of SPL terms were mapped – implying that as SPL content deepens, clinical decision support (CDS) can vastly improve. The implication is clear: structured labeling is not merely a bureaucratic checkbox, but a rich data source for patient safety.

FDA DailyMed and Vendor Data: An AMIA 2007 study examined how well SPL labels cover the medication market. ([60]). It loaded all ~2,200 labels on DailyMed and assessed them against RxNorm (the standard drug vocabulary). Results: SPL labels already described 78% of actual dispensed drugs ([22]), despite covering only 23% of RxNorm’s list (because it captured the most common ones). Crucially, the study found that SPL descriptions agreed well with RxNorm, demonstrating consistency. They concluded that once the FDA’s listing rule mandates all products, “SPL can be used as the primary source of drug information for e-prescribing systems” ([48]). In other words, within a few years, a physician’s EHR could rely directly on SPL data rather than third-party databases – relying on SPL’s inherent data integrity.

EMA/ePI Pilot and Roadmap: The European Medicines Agency (EMA) and several national agencies ran a one-year ePI pilot (Jul 2023–Aug 2024), which EMA declared a success ([61]). Under the common standard, companies created ePIs for 25 products in 4 countries (Denmark, Netherlands, Spain, Sweden). The first seven ePIs were publicly published via EMA’s PLM portal as bundled documents (SmPC + Patient Leaflet + labeling) built online and available via API ([34]). Building on this success, EMA and the network made a draft ePI roadmap available in March 2026. The EMA Management Board noted the draft roadmap; it did not approve a final roadmap ([5]; EMA Management Board highlights). The roadmap sets concrete therapeutic-area timelines: voluntary ePI submission for vaccines (ATC J07) beginning Q3 2026, oncology products (ATC L01, L04) in Q4 2026, with progressive rollout across all centrally authorised products. Mandatory ePI for all newly authorised medicines will take effect once the revised EU pharmaceutical legislation enters into application. EMA’s analysis emphasizes that ePI “allows companies to create and manage ePIs during regulatory procedures and make them available via an API,” underscoring data integrity in action ([62]).

Industry Transition (Middle East Case): An IQVIA case study details a global pharma company’s shift to e-labeling across 15+ Middle East markets ([63]). The company sought to harmonize labeling (including artwork) for Saudi Arabia, UAE, Egypt, Bahrain, etc., and to implement digital labels (paperless labeling). Key challenges included navigating diverse local e-labeling regulations and integrating new tech infrastructure ([64]). IQVIA provided regulatory strategy, IT integration, localization, stakeholder coordination, and training ([65]). With this support, the company achieved compliance in all target countries and greatly reduced its labeling cycle time. This real-world example highlights that adopting structured labeling requires cross-functional planning but yields tangible compliance and efficiency gains.

Belgium/Luxembourg ePI Pilot: The Belgium/Luxembourg ePI pilot is one example of electronic product-information implementation. Operational pilot findings alone do not establish that paper leaflets can be generally replaced without affecting patient safety; any replacement remains subject to the applicable legal framework and evidence. EMA defines ePI as authorised statutory product information adapted for electronic handling and dissemination via the web, e-platforms, and in print. ([5])

Market Growth and Compliance: Market research underscores the momentum: verified industry analyses report that the Structured Content & Product Label Management market was valued at approximately USD 65 billion in 2025 and is projected to grow at 12.5% CAGR, reaching USD 73.1 billion in 2026 ([66]). Cloud-based deployment is projected to account for approximately 65% of the market by 2026. Regulators are cited as a chief driver: “Recent guidelines from agencies like the FDA and EMA mandate standardized content structures and terminologies for product labels” ([46]). In other words, SPL isn’t just an academic concept but a lucrative market, as software providers race to help companies meet these mandates.

10

Discussion: Implications and Future Directions

The transition from PDF to SPL has far-reaching implications. Patient safety and therapeutic efficacy are likely to improve as labeling data become more reliable and accessible. For example, with structured labels, an app could quickly display the latest kidney-dose adjustments for a drug, or a web portal could automatically show a patient their medication in their preferred language and format. Data integrity here means the patient is getting the right information at the right time in a verifiable way.

On the regulatory front, SPL supports structured exchange and FDA provides schemas, terminology files, and validation resources for applicable SPL submissions. The extent of automated validation, review, pharmacovigilance use, and cross-jurisdictional interoperability depends on the applicable system, data elements, and regulatory process; it should not be inferred from SPL alone. ([1])

Data interoperability is another key upshot. Once on SPL, label data can flow into electronic health records (EHRs), clinical decision support, supply-chain systems, and even consumer health apps. The linkage between SPL and FHIR (HL7’s modern data exchange standard) is now concrete: the HL7 Global Core ePI Implementation Guide (v1.1.0) provides a universal starting point, while the European Medicines Regulatory Network ePI FHIR IG v1.0.0 (built on FHIR R5) was published in early 2025 ([67]). The HL7 Vulcan ePI project is developing a global FHIR standard for medicinal product information and encourages adopters to pilot region-specific implementations. ([11]) Structured product information can be mapped for use in prescribing software, hospital systems, and decision support, but those uses require separate integrations, terminology mappings, governance, and validation. Structured format alone does not guarantee clinical alerts or data-integrity outcomes.

Challenges and Considerations: Naturally, this shift demands careful attention to technology governance. Companies must ensure their SPL data is secured and backed up (ALCOA’s Enduring/Available) and that quality systems validate SPL outputs. Audit trails in QMS must extend to the XML content – for example, any automated conversion from an approved Word PL to SPL still requires verification. Regulatory authorities will also need harmonized validation rules across regions; inconsistencies (e.g. differing allowable terminology lists) could undermine the global benefits of SPL. Additionally, as structured labeling permeates supply chains, issues like serialization (drug barcodes) and blockchain for traceability may intersect with SPL. Though not yet mainstream for labeling content, emerging tools (see Journal of Pharma Innovation 2023) suggest blockchain could one day further guarantee label data immutability.

Future Outlook: Structured product-information initiatives may expand as regulators, industry, and health-information systems gain implementation experience, but timelines and legal requirements remain jurisdiction-specific. EMA describes its March 2026 ePI roadmap as a draft, phased transition aligned with upcoming legal requirements. In the United States, FDA’s current guidance on the scope and application of 21 CFR Part 11 is dated September 2003; organizations should evaluate applicable electronic-record and electronic-signature requirements for their own systems. ([5]; FDA Part 11 scope and application guidance)

Importantly, this evolution enhances transparency and auditability. Drugmakers and regulators can query label versions, compare past and current text, and even share label content openly (e.g. API feeds on DailyMed, FDA’s Label Archive). This audit-friendly setup can support data-integrity objectives when it is combined with controlled authoring, approvals, audit trails, retention, and validated systems. For industry, compliance becomes less a chore and more a byproduct of well-architected data systems.

11

Conclusion

Structured Product Labeling (SPL) can support pharmaceutical data integrity by providing a standardized, machine-readable representation of specified product and labeling information. It does not, by itself, establish compliance: controlled authoring, approval, audit-trail, electronic-record, validation, retention, and publication processes remain necessary. FDA provides SPL schemas, terminology, and validation resources for applicable submissions. ([1]) These resources support structural validation and consistent exchange of specified product information. Data-integrity objectives require separate, validated controls for authoring, approval, audit trails, electronic records, retention, and publication.

Real-world initiatives—including DailyMed, which is maintained by the National Library of Medicine, and EMA’s ePI pilot and draft March 2026 implementation roadmap—show that structured product-information systems are operational and continuing to evolve. Historical studies suggest that structured drug information can improve clinical decision support and examined SPL coverage in particular datasets; their coverage results should not be treated as current market-wide estimates. SPL may also streamline specified regulatory data exchanges when paired with suitable authoring and workflow systems. ([68]; AMIA study) Health Canada’s first mandatory XML PM phase began in July 2025 for specified NDS and EUNDS, while structured product-information initiatives in other jurisdictions continue to develop under jurisdiction-specific requirements and timelines. Demand for structured-labeling solutions and the applicable regulatory requirements vary by product type and jurisdiction; organizations should verify them against current primary-source guidance.

In conclusion, organizations subject to SPL requirements should use the applicable standards and technical specifications. Where structured labeling is adopted, it can support validation, reuse, and interoperability when combined with controlled authoring, approval, change-management, and publication processes.

References: This article cites regulatory documents, original research, and industry commentary. Regulatory requirements and implementation timelines should be verified against current primary-source guidance. ([69]) ([2]) ([3]) ([24]) ([14]) ([70]) ([7]) ([71]) ([33]) ([42]) ([9]) ([22]) ([46]) ([47]) ([72]) ([27]), among others. Each citation points to a credible source detailing these findings and regulations.

Sources / 72
Adrien Laurent

Need Expert Guidance on This Topic?

Let's discuss how IntuitionLabs can help you navigate the challenges covered in this article.

I'm Adrien Laurent, Founder & CEO of IntuitionLabs. With 25+ years of experience in enterprise software development, I specialize in creating custom AI solutions for the pharmaceutical and life science industries.

Disclaimer

The information contained in this document is provided for educational and informational purposes only. We make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability, or availability of the information contained herein. Any reliance you place on such information is strictly at your own risk. In no event will IntuitionLabs.ai or its representatives be liable for any loss or damage including without limitation, indirect or consequential loss or damage, or any loss or damage whatsoever arising from the use of information presented in this document. This document may contain content generated with the assistance of artificial intelligence technologies. AI-generated content may contain errors, omissions, or inaccuracies. Readers are advised to independently verify any critical information before acting upon it. All product names, logos, brands, trademarks, and registered trademarks mentioned in this document are the property of their respective owners. All company, product, and service names used in this document are for identification purposes only. Use of these names, logos, trademarks, and brands does not imply endorsement by the respective trademark holders. IntuitionLabs.ai is an AI software development company specializing in helping life-science companies implement and leverage artificial intelligence solutions. Founded in 2023 by Adrien Laurent and based in San Jose, California. This document does not constitute professional or legal advice. For specific guidance related to your business needs, please consult with appropriate qualified professionals.

Related Articles

Need help with AI?

© 2026 IntuitionLabs. All rights reserved.