SPL, IDMP and eCTD: a CCMS buyer’s guide

Three regulatory-content standards have converged on the same architectural principle by 2026. FDA Structured Product Labeling treats labeling content as XML. ISO IDMP treats substance, product, and packaging information as structured master data. The eCTD format has been the submission backbone since 2003 and continues to expand its envelope. The principle underneath all three: regulated content is data, not documents.

This is a problem for the substantial majority of pharma content estates, which were built around documents.

This guide is for regulatory-affairs and quality leaders evaluating a CCMS specifically against the demands of SPL, IDMP, and eCTD. Most CCMS platforms can handle parts of the picture. Few handle all of it. The four capabilities that decide whether a CCMS keeps up with the three standards are below.

Why this matters more in 2026 than it did in 2024

Two regulatory shifts have raised the bar in the last twenty-four months.

The convergence the CCMS choice has to anticipate: SPL on one regulatory side, IDMP on the other, both feeding the same labeling estate. Choosing a CCMS that handles only one of the two is a near-term decision with a known migration ahead.

FDA QMSR effective 2 February 2026. The Quality Management System Regulation replaced 21 CFR Part 820 and aligned US medical-product quality systems with ISO 13485:2016. The traceability requirements across clinical, manufacturing, and post-market documentation tightened. Quality content that was previously document-managed is now expected to carry component-level traceability through the lifecycle. The structural shift is towards the same component-management posture that SPL and IDMP already assume.

IDMP implementation phases at EMA. EMA has moved through phased IDMP implementation since 2022; the substance and product identifier layers are now in production for new substances, and the back-catalog compliance window is closing. The practical effect is that pharma organizations that have been holding IDMP master data in spreadsheets or in fragmented databases now have to migrate to a structured-content posture that can feed the EMA SPOR services directly.

The CCMS evaluation question changes shape under these two pressures. The traditional question was “does the CCMS publish to PDF cleanly?” The current question is “does the CCMS hold the structured master data, the narrative content, and the relationships between them, and can it publish to SPL, eCTD, and the SPOR services without a manual reconciliation step in the middle?”

Capability 1: Labeling stored as components, not documents

The Company Core Datasheet is the canonical example. CCDS sets the approved global wording for a product’s labeling: indications, contraindications, dosing, safety statements, pharmacology, pharmacokinetics. Every market-specific label (SmPC for the EU, USPI for the US, every local pack insert and patient information leaflet) derives from CCDS. When the CCDS changes, typically driven by a pharmacovigilance signal or a regulatory update, every downstream label has to refresh.

In a document-centric posture, that refresh is a manual reconciliation across the country labels, and the audit failure mode is well-known: the safety language in market X is not the same as the approved CCDS, because someone forgot to update the Brazilian variant after the last revision.

In a CCMS that holds the labeling as components, the same approved warning is one component referenced from every label that uses it. A change to the CCDS component propagates automatically to every downstream label. The audit question, “which version of which warning is currently in the Brazilian label”, is a query, not an archaeology project.

This is the same component-management argument that applies to any DITA-based CCMS in pharma. We made the wider structural case in Component content management vs document management, the only distinction that actually matters, and the original 2017 articulation in The Value of Structured Content Management in Life Sciences holds with very little revision.

What the SPL standard adds is a publishing-target requirement on top of the component model. The labeling sections have to be expressible in HL7 v3 / LOINC-coded XML at submission time. A CCMS that holds labeling as DITA topics with the right metadata can transform to SPL on demand; a CCMS that holds labeling as documents has to run a separate transformation pipeline.

Capability 2: IDMP master data held alongside the narrative content

IDMP introduces a master-data layer alongside the narrative content. The substance data, the product data, the manufactured item data, the packaged medicinal product data: all of it has to be held in a structured form that can feed EMA’s SPOR services (Substances, Products, Organizations, Referentials) and can be referenced from the narrative labeling that talks about it.

This is the part of the picture most CCMS platforms handle poorly. The CCMS world grew up around content reuse, the same paragraph in many documents, rather than around master-data management. IDMP needs both: the structured master data and the narrative content that references it, with the relationships between them kept coherent.

The architectural answers we have seen work in production fall into two camps. The first keeps the IDMP master data in a dedicated regulatory information management (RIM) system and uses the CCMS for the narrative content, with integration between the two systems mediated by middleware. The second holds the IDMP master data in the CCMS itself, using DITA’s data-modeling primitives (topics with controlled metadata, key references, controlled vocabularies) to express the substance and product entities as first-class content. Both can be made to work; the first is more common at large pharma; the second has lower integration cost and tighter audit posture but requires a CCMS that can express the data model coherently.

The diagnostic question for any CCMS evaluation in pharma in 2026: “How do you handle IDMP substance data, and if it lives outside the CCMS, how do you keep the narrative pharmacology section synchronized with it?” The answer reveals more about the platform than any feature checklist.

Capability 3: Publishing to SPL and eCTD without a separate transformation step

eCTD has been a CCMS publishing target since the format was finalized in the early 2000s. Most credible CCMS platforms can produce an eCTD-conformant submission package. The question that matters in 2026 is whether the publishing pipeline runs cleanly from the structured content to the submission package, or whether there is a manual transformation step in the middle.

SPL is the newer of the three. The publishing requirement is that labeling content sections (the prescribing information, the patient package insert, the SPC equivalents) have to be expressible as SPL XML at submission time. The cleanest architectures hold the labeling as DITA topics with section-type metadata that maps to LOINC section codes, and run a DITA-to-SPL transformation as part of the publishing pipeline. The less clean architectures hold the labeling as documents and require a separate SPL authoring tool downstream.

The same logic applies to the IDMP submission feeds. EMA’s SPOR services accept structured submissions in defined formats; a CCMS that holds the master data and the narrative content together can produce both the SPL labeling and the SPOR feed from one publishing run.

This is the half of the evaluation where the DITA-on-SharePoint architecture has structural advantages that are not obvious from a feature list. Because the content is held as DITA components with strict schema validation, the transformation to SPL is mechanical. Because the SharePoint substrate carries the audit and identity posture, the publishing pipeline does not need a separate compliance review. The combined effect is that the SPL/eCTD/SPOR publishing path runs through one platform with one set of approvals, rather than through three platforms that have to be reconciled.

Capability 4: Component-granularity audit answers

The audit posture is the half of the CCMS value proposition that survives every economic cycle. Regulators ask who approved a specific statement, when, and against which version of which regulation. The answer either fits inside the response window or it does not.

For SPL and IDMP specifically, the window is set by the regulator’s response expectations on labeling and master-data changes. For EMA pharmacovigilance, the window is seven days. For FDA labeling supplements, the timelines are defined in the relevant guidance documents and have tightened in the QMSR era.

The diagnostic question: “When a regulator asks who approved the current version of section 4.4 of the EU SmPC for product X, can the system answer at the component level or only at the document level?” If the answer is document-level, every label that includes section 4.4 has to be reviewed by hand to find the right approval record. If the answer is component-level, the question is a query against the metadata.

This is not a SPL-specific or IDMP-specific requirement. It is a regulated-content requirement that the SPL and IDMP standards have intensified, by raising the publishing-frequency and traceability bars across the labeling and master-data layers.

What the four capabilities mean for an evaluation

A pharma CCMS evaluation in 2026 should test the four capabilities concretely, not on a feature checklist:

• Capability 1. Ask the vendor to show how the CCDS feeds the SmPC, USPI, and a representative local pack insert as components. Watch the change propagation from a CCDS update to the downstream labels; ask what triggers the propagation and what manual reconciliation steps remain.
• Capability 2. Ask the vendor where the IDMP substance, product, and packaging data lives in their architecture, and how a change to a substance record propagates to the pharmacology sections of every label that references that substance.
• Capability 3. Ask the vendor to publish a representative labeling section to SPL XML and the surrounding submission to eCTD. Watch whether the transformation runs cleanly from the structured content, or whether there is a separate authoring step in between.
• Capability 4. Ask the vendor to answer “who approved the current version of section X of the EU SmPC for product Y, when, and against which version of which regulation”. Watch whether the answer is a query or a reconstruction.

DitaExchange Dx5 is the implementation of this picture in the Microsoft-native architecture: labeling components in DITA, IDMP master data expressible as structured topics, SPL and eCTD publishing through the DITA Open Toolkit pipeline, component-level approval and audit trail through the SharePoint substrate. The product expression is on the Life Sciences industry page and the DxChecker product page covers the regulatory-language rule enforcement that pairs with the architecture. For the category-level treatment of CCMS independent of any specific vendor, see the CCMS pillar page.

The 2026-2028 trajectory

Two things to watch over the next two years.

IDMP back-catalog compliance. EMA’s IDMP back-catalog window is closing. Pharma organizations that have been holding off on the IDMP migration are running out of room. The CCMS architectures that survive the transition cleanly will be the ones that can ingest IDMP master data into the structured-content estate, not the ones that bolt on a separate IDMP tool.

SPL adoption beyond the US. SPL is FDA-specific in 2026. EMA’s structured-labeling work (ePI: electronic product information) is moving in a similar direction, with the same architectural premise: labeling is data, not documents. The CCMS architectures that publish to SPL today have a clean path to publish to ePI tomorrow. The architectures that treat SPL as a one-off integration will have to do the work again.

For organizations standardized on Microsoft 365, the DITA-on-SharePoint architecture is the structural answer to both questions in one platform decision. For everyone else, the same four capabilities apply but the implementation path will look different.