What Pharma Companies Need to Know About ePI FHIR
When the European medicines regulatory network adopted the EU ePI Common Standard, which is based on HL7 FHIR, many pharma professionals heard the decision as a technical mandate. It was not. The decision affected every team responsible for drug labeling. The European Medicines Regulatory Network ePI Implementation Guide describes how HL7 FHIR is used to generate ePI according to the EU ePI Common Standard.
Understanding why FHIR was chosen and how it structures electronic product information is essential for anyone authoring, reviewing, or managing pharma labeling. This walkthrough approaches FHIR not as abstract specification, but as practical framework that reshapes how content is organized in FHIR pharma labeling and ePI XML format.
Why FHIR for ePI?
Before FHIR, pharmaceutical labeling existed primarily as documents. A Summary of Product Characteristics was a single PDF or Word file. Content was flowing narrative prose with sections that varied by company, region, and regulatory history. This format works for human reading. It fails for data exchange and computational processing.
FHIR stands for Fast Healthcare Interoperability Resources. It was originally developed for clinical data exchange across healthcare systems. It uses a standardized, machine-readable format that breaks information into structured components, each with defined attributes and relationships.
FHIR is central to the EU ePI Common Standard because it enables three key capabilities. First: structured data that can be processed computationally. Second: relationships between components that can be explicitly defined and queried. Third: more granular version control and change tracking instead of document-level change management. The EMRN describes the EU ePI Common Standard as the basis for harmonized ePI across the EU, and the guide presents the FHIR resources used to create ePI under that standard.
In practical terms, FHIR enables questions like “which contraindications apply to this dosage form?” Document-based systems cannot answer them. FHIR-structured content can: traceable, accurate, queryable.
The FHIR ePI Implementation Guide
The European Medicines Regulatory Network ePI Implementation Guide describes how HL7 FHIR is used to generate ePI according to the EU ePI Common Standard. This is the practical technical reference that helps pharmaceutical companies and technology providers prepare for future ePI submissions to EU regulators.
Current EMRN materials describe the guide as a draft provided for preview purposes, with a formal published version expected before ePI implementation. That distinction matters because teams should prepare now, but avoid treating every preview detail as final production policy. The current EMRN ePI FHIR Implementation Guide preview should be treated as a readiness reference, not a substitute for final implementation requirements.
The Implementation Guide defines resource types: the basic building blocks of ePI content. Current HL7 ePI materials identify resources including List, Bundle, Composition, Organization, RegulatedAuthorization, MedicinalProductDefinition, AdministrableProductDefinition, ManufacturedItemDefinition, Ingredient, SubstanceDefinition, PackagedProductDefinition, ClinicalUseDefinition, and Binary.
These are not abstract concepts. When your Regulatory Affairs team prepares ePI for EU workflows, the submission model depends on FHIR XML files that can be validated against the EU ePI Common Standard and managed through PLM Portal-related tooling. For teams building ePI readiness programs, structured content for ePI becomes the operational layer between authoring, validation, and reuse.
The Implementation Guide also defines the structure and constraints that systems must respect when generating ePI XML. Your authoring system must capture information in a way that can be mapped, validated, and exported against applicable ePI profiles. If it only allows free-form labeling prose, it will struggle to produce reliable FHIR ePI output.
Resource Types: The Core Building Blocks
Understanding the major resource types is essential for authoring teams, even when authors never see raw FHIR XML.
- Bundle, List, and Composition resources help organize the ePI as a structured package of content rather than a static document. This matters because ePI is exchanged as linked FHIR resources, not as one flat file. HL7’s electronic medicinal product information materials identify Bundle, List, and Composition among the FHIR resources used for electronic medicinal product information.
- MedicinalProductDefinition contains the drug name, therapeutic classification, active ingredients, and organization responsible. Your Regulatory Affairs team will author this content.
- PackagedProductDefinition describes the physical packaging: vial, blister pack, pen injector, and its relationship to the MedicinalProductDefinition. This is critical because dosage and storage instructions often vary by package type.
- MedicinalProductIngredient specifies active and inactive ingredients where the applicable profile requires that level of product detail. This differs from a simple ingredient list in traditional labeling. Each ingredient has attributes: strength, role, source organism if applicable, and specification reference.
- RegulatedAuthorization represents regulatory approval. A single drug may have multiple RegulatedAuthorizations, one per region or approval date. Each references a MedicinalProductDefinition and specifies the approving authority.
- ClinicalUseDefinition is used in broader ePI modeling for clinical safety information such as indications, contraindications, warnings, and drug interactions, where applicable to the implementation profile.
Understanding these resources helps authors grasp why ePI requires different authoring practices than traditional labeling. Content is not written as flowing narrative. It is authored as structured data.
ePI XML Format Versus SPL XML
Many pharma professionals are familiar with SPL, the Structured Product Labeling format that has been the standard for FDA submissions. ePI XML is different. The FDA describes Structured Product Labeling as an HL7-approved document markup standard adopted by FDA for exchanging product and facility information.
SPL uses XML elements that correspond to document sections. A contraindication section contains contraindication text. The ePI XML format uses FHIR resources and attributes that are more granular and more explicitly linked to regulatory and clinical data structures.
An SPL file is essentially a structured document. An ePI file is a collection of structured data resources. The distinction matters because it changes what you can do with information. SPL content can be searched and displayed. ePI content can be searched, displayed, filtered, and computationally processed.
Your authoring systems must support this different structure. A system that exports traditional labeling to SPL will not produce valid ePI content. The underlying conceptual model is different.
Authoring Systems and FHIR Complexity
Most pharma professionals should not write raw FHIR XML. This is where the gap between technical standards and practical authoring emerges.
Your authoring system should abstract FHIR complexity. Regulatory Affairs professionals should work with familiar interfaces: fields for product name, lists of active ingredients, sections for indications and contraindications. Behind the interface, the system maps information to FHIR resources and generates valid ePI XML.
When you evaluate authoring platforms for ePI, assess whether they provide this abstraction and whether they can support FHIR XML validation against the EU ePI Common Standard as regulatory expectations mature. A system that requires authors to understand FHIR resources and write XML directly will struggle with adoption and increase error rates.
The system should validate content against the FHIR ePI Implementation Guide as authors work. When a required field is missing or data entry violates a constraint, the system should flag it immediately. For teams modernizing labeling operations, Docuvera for Global Labeling supports modular labeling content, reuse, and multiformat publishing across regulated workflows.
Governance and Version Control
FHIR’s component-based structure enables more granular governance and version tracking, but only if your governance system supports it.
When a single warning in ePI needs updating, the goal is to manage that change at the relevant structured content component instead of treating the entire label as one undifferentiated document. Other components should remain traceable and governed through their relationships to the updated content.
Your governance framework must define how component versions are tracked, how changes are approved, and how relationships between updated and unchanged components are maintained. This is more complex than document versioning but more powerful. That is why regulatory compliance and risk mitigation depend on traceability, auditability, controlled reuse, and consistent governance across labeling content.
Moving Forward
FHIR is not simply a burden imposed by regulators. It is infrastructure that can enable safer, more accurate, more traceable pharmaceutical labeling when paired with the right governance, authoring, and validation processes. Understanding its structure and logic is essential for teams authoring, reviewing, and maintaining ePI content.
Your authoring platforms must shield teams from FHIR complexity while ensuring FHIR compliance. This is where governance-driven structured content platforms become essential infrastructure.
Frequently Asked Questions
1. What is the FHIR ePI Implementation Guide?
The FHIR ePI Implementation Guide describes how HL7 FHIR is used to generate electronic product information according to the EU ePI Common Standard. For pharmaceutical teams, it translates the ePI standard into practical resource structures, profiles, and constraints that systems must be able to support.
2. Is the FHIR ePI Implementation Guide final?
Current EMRN materials describe the guide as a draft provided for preview purposes. A formal published version is expected before implementation of ePI, so teams should use the current EMRN ePI FHIR Implementation Guide preview for readiness planning while monitoring future updates.
3. How is ePI XML different from SPL XML?
SPL XML is organized around structured document sections and is used by FDA as a mechanism for exchanging product and facility information. ePI XML uses HL7 FHIR resources to represent product information as linked, machine-readable data. That difference matters because FHIR ePI is designed for interoperability, validation, and more granular downstream use.
4. Do labeling teams need to write raw FHIR XML?
No. Most regulatory, labeling, and safety teams should not need to write raw FHIR XML. The authoring platform should abstract the FHIR layer, guide authors through familiar content fields, and generate valid ePI XML behind the scenes.
5. Why does FHIR matter for pharma labeling?
FHIR matters because it moves pharma labeling from static documents toward structured, interoperable product information. That shift supports better validation, traceability, reuse, and delivery of authorized product information across digital channels.
6. What should companies evaluate in an ePI authoring system?
Companies should evaluate whether the system can capture structured labeling content, map that content to FHIR resources, validate against the applicable ePI profiles, preserve governance and approval workflows, and generate FHIR ePI XML without forcing authors to work directly in XML.