Executive Summary

The pharmaceutical and medical device industries are undergoing a digital transformation in how product labeling information is created, managed, and exchanged. Legacy systems rely heavily on XML-based standards (such as HL7 v3 Structured Product Labeling (SPL)) or static formats (e.g. PDF), which are inflexible and poorly interoperable (^[1]) (^[2]). In contrast, the HL7 Fast Healthcare Interoperability Resources (FHIR) standard (an ANSI-accredited open standard) is emerging as a modern, web-friendly framework for structured health data exchange (^[3]) (^[4]). Industry analysts and regulators alike note that FHIR’s use of RESTful APIs and formats like JSON/XML (versus legacy HL7’s XML-only messaging (^[4])) can greatly enhance the accessibility, accuracy, and interoperability of labeling information. For example, HL7’s Global ePI Implementation Guide explicitly states that FHIR can support “personalized labeling, advanced search capabilities, and cross-border interoperability,” making product information more accessible to healthcare professionals and patients (^[5]).

However, realizing these benefits requires significant preparation at the organizational level. Successful transition to FHIR-based labeling entails assembling multi-disciplinary teams with new skills, adopting appropriate technology and authoring tools, and engaging proactively with regulators and standards bodies. This report provides a comprehensive analysis of the “XML-to-FHIR” transition in labeling, covering historical context, standards development, global regulatory drivers (case studies from the EU, Jordan, Asia, etc.), technical and organizational requirements, and future implications. We synthesize industry reports, regulatory guidance, and academic perspectives to answer key questions: Why is FHIR relevant for labeling? What organizational changes does it entail? What data and case evidence support this shift? How can teams plan and execute a FHIR transition?

Key findings include:

• Regulatory momentum: Major drug and device regulators (EMA, FDA, Jordan FDA, etc.) are actively moving toward FHIR-based e-labeling and e-product information standards. For instance, the Jordan FDA has mandated a new FHIR-based ePI format by end of 2025 (^[6]), and the EMA completed an ePI pilot in 2024 with a FHIR version 5.0.0 Implementation Guide in development (^[7]) (^[8]). These initiatives signal a clear trend away from static PDF/XML labeling to structured FHIR content.
• FHIR benefits: Experts note that FHIR inherently supports real-time, modular data exchange. Unlike traditional monolithic documents, FHIR represents information as modular resources (e.g. Bundle, Composition, MedicinalProductDefinition) with standard coded fields (^[9]). This shift enables powerful new capabilities: dynamic label updates, automated validation, integration with EHR and mobile apps, multi-language and AI-driven personalization, and accessibility features (e.g. audio playback, sign language) (^[6]) (^[5]). Preliminary market analysis underscores the demand for such interoperability: the global healthcare API market is projected to exceed $1.25 billion by 2024 (^[10]), and surveys show most countries mandate or advise FHIR for health data exchange (^[11]).
• Organizational readiness: Transitioning to FHIR is not merely technical; it requires retooling teams. Based on HL7 guidance and industry best practices, companies should form cross-functional e-labeling teams that include FHIR developers, regulatory and quality experts, content authors, IT specialists, and project managers (^[12]). Key steps include: (1) training staff in FHIR fundamentals and new authoring tools; (2) investing in a secure FHIR server and structured content authoring infrastructure; (3) establishing clear data governance and SOPs to ensure label accuracy and version control; and (4) engaging with regulatory authorities and standards groups to stay aligned with evolving guidelines (^[12]) (^[13]). For example, HL7’s Global ePI IG explicitly recommends enrolling in HL7’s “FHIR Fundamentals” course and conducting internal workshops as part of team preparation (^[14]).
• Implementation strategy: A phased, evidence-based rollout is advised. HL7’s guidance suggests beginning with a small-scale pilot (e.g. creating one or two FHIR “Type 1” electronic package leaflets on a test FHIR server) to validate the process and tooling (^[15]). Once technical feasibility is confirmed, teams can expand to a broader production pilot (covering more products and jurisdictions) before full-scale deployment. Each phase should use FHIR validation tools and success metrics (e.g. error-free validation, correct rendering, regulator feedback) (^[15]) (^[16]).
• Challenges and future directions: Full realization of FHIR e-labeling will require overcoming data standardization and adoption challenges. Some experts warn of the risk of “parallel systems” if regulators or manufacturers maintain separate paper and e-label processes during the transition (^[2]). Technology teams must also monitor evolving FHIR versions (R5, upcoming normative R6) and incorporate emerging tools (blockchain for traceability, AI for content generation with prompt engineering skills, etc.) (^[17]).However, the momentum is clear: companies that invest now in FHIR-based labeling stand to improve compliance, patient safety, and operational efficiency, positioning themselves as industry leaders (^[18]) (^[19]).

This report is organized as follows. The Introduction provides background on labeling standards and the drivers of change. We then detail the evolution of labeling standards (from PDF/XML to FHIR), examining both historical context and the technical underpinnings of FHIR. Next, we analyze the regulatory landscape for e-labeling worldwide (with case studies from the EU, Jordan, Asia, and North America) and summarize the current state of FHIR adoption. We then delve into preparing cross-functional teams, including required skills, roles, tools, and workflows, with evidence from HL7 guidance and industry experts. The implementation section outlines strategic steps, data considerations, and validation methods (drawing on connectathon practices and published best-practices). Throughout, we present data, survey results, and analyses of benefits/risks. We conclude with a discussion of implications and future directions, including potential impacts on patient engagement and global harmonization, and summarizing key recommendations. All claims are supported by authoritative sources (regulators, HL7, peer-reviewed reports, industry analyses) to ensure credibility.

Introduction and Background

Medical product labels (package inserts, instructions for use, safety summaries, etc.) are critical regulatory documents that communicate essential information about use, dosage, contraindications, and safety. Traditionally, such labeling was developed as text-based documents (e.g. paper leaflets or PDFs) attached to product packaging. In recent decades, regulatory authorities have required structured electronic submissions. For example, the U.S. FDA long-ago adopted the HL7 Structured Product Labeling (SPL) standard – an XML-based document markup approved by HL7 – for exchanging drug and biologics labeling (^[1]). Similarly, the European Medicines Agency (EMA) and other regulators have mandated electronic labeling submissions in eCTD format, often as PDF or richly tagged content. Despite structuring efforts, these legacy formats remain primarily document-centric, inhibiting automated data exchange and easy integration with healthcare IT systems.

By contrast, HL7 FHIR (Fast Healthcare Interoperability Resources) was designed from the ground up to leverage modern web technologies and data exchange methods. Health Level Seven International (HL7) – an ANSI-accredited standards organization – introduced FHIR to streamline interoperability across diverse systems. Key features of FHIR include:

• Modular “Resources”: Data is broken into atomic, reusable resources (such as FHIR Patient, Condition, or in our context, Composition and MedicinalProductDefinition) rather than monolithic documents.
• Flexible Formats: FHIR supports both XML and JSON encodings (as well as RDF for semantic web), enabling developers to use industry-standard formats and tools (^[4]). By comparison, older HL7 v2/v3 standards were largely XML-only, limiting flexibility.
• RESTful APIs: FHIR’s design follows REST principles, allowing systems to query, retrieve, and update specific pieces of data over HTTPS, much like typical web services (^[4]). This contrasts with batch-oriented, message-based approaches of earlier HL7 versions.
• Extensibility: FHIR includes a mechanism for creating profiles and extensions to handle local or specialized needs while maintaining a core standard. This facilitates global baseline interoperability with local adaptations.

Collectively, these capabilities mean that FHIR can transform labeling from static text into structured data interoperable with clinical systems. For example, an “Electronic Product Information (ePI)” message in FHIR can be indexed, searched, and linked to patient records or pharmacy applications in real time, improving safety and usability. A recent industry article observes that FHIR’s simplicity and flexibility allow “secure storage and easy-to-understand data communication” across vendors and providers, empowering healthcare professionals and even patients (^[20]) (^[4]). By enabling RESTful access to label content, FHIR allows digital labelling to support scenarios like mobile label lookup, personalized dosing guidance, and rapid safety updates, which are difficult or impossible with legacy formats.

Drivers of Change. Several converging factors are pushing the industry toward FHIR-based labeling:

• Global Regulatory Initiatives: Regulatory agencies are explicitly endorsing FHIR for product information. The European Medicines Agency (EMA) has developed a FHIR-based EU Common Standard for ePI and conducted a pilot in 2024 (^[21]). The Jordan FDA has unilaterally issued a regulation requiring all national drug labels be delivered in a FHIR ePI format by end of 2025 (^[6]). Other countries (e.g. Malaysia, Japan) have introduced e-labeling laws or guidance (often in PDF form) highlighting the inadequacy of paper and PDF for modern practice (^[22]) (^[23]). The U.S. FDA, while not yet mandating FHIR-labeled submissions, is actively developing FHIR Implementation Guides for regulatory submissions (e.g., the PQ/CMC guide for drug quality data (^[24])). Collectively, these initiatives create a timeline by which manufacturers must be ready to supply e-labeling content in interoperable formats.

• Technology Trends: Healthcare is moving rapidly to API-based ecosystems (e.g. SMART on FHIR apps, integrated EHRs). An HL7 survey (2024) found that over 80% of responding countries now have health data exchange regulations, and 65% explicitly mandate or encourage FHIR in national standards (^[11]). The global healthcare API market is expanding accordingly (projected to exceed $1.25B by 2024) (^[10]). Labeling is a natural frontier for these trends: instead of siloed documents, labels can become interoperable datasets.

• Patient-Centricity and Innovation: There is growing demand to make product information more accessible and patient-friendly. HL7 ePI guidelines emphasize “patient-centric solutions” and capabilities like personalized labeling, advanced search, and integration with health apps (^[5]). For example, Jordan’s new e-labeling app (built around FHIR) includes text-to-speech, sign language support, and dark-mode for readability (^[6]). Industry experts note that accessible electronic labels can enhance patient safety and shared decision-making. As Erie Matsui (Pfizer R&D Japan) observed, labeling “should be as accessible as possible”, driving the shift to digital formats (^[25]) (^[19]).

• Limitations of Legacy Systems: Traditional label formats have inherent drawbacks. Paper or PDF labels cannot be easily updated or queried electronically, and maintaining consistency across many jurisdictions is labor-intensive. One market analysis bluntly states that “current procedures based on PDF are not adequate to support electronic initiatives.” (^[2]). Moreover, the static nature of traditional SPL XML makes automated data exchange fragile: merging, version control, and real-time updates are difficult. FHIR’s resource model, in contrast, is built for dynamic data sharing across systems.

In summary, the “XML Transition” in labeling is being driven by an international push for interoperability, the maturity of FHIR technology, and the promise of improved safety and efficiency. The remainder of this report delves into each aspect of this transformation, grounding recommendations in industry data, case examples, and authoritative sources.

Evolution of Labeling Standards

Legacy Standards: XML and SPL

Historically, pharmaceutical and device labeling has relied on HL7 Version 3 standards, particularly the Structured Product Labeling (SPL) specification for drugs and biologics. As the FDA notes, SPL is an HL7-approved document markup standard for exchanging product and facility information (^[1]). An SPL file is essentially an XML document containing sections (e.g. Highlights, Indications, Dosage) tagged with controlled vocabulary (e.g. from RxNorm). For example, a drug label submission includes multiple XML tables, coded elements (NDC codes, warnings), and <section> tags. Similarly, the EU’s electronic cross-functional Document (eCTD) submissions use extensible markup (often XML) to capture Module 1 (regional labeling) and other content.

These XML formats offered structure beyond free-text, but with limitations. SPL is document-centric: each release is a full document containing narrative text in XML. Updates require repackaging entire sections. Integration with clinical systems is non-automatic – system A cannot easily ask for a specific sub-element of a label via an API. Even though XML is machine-readable, many workflows still treat it as a fixed document (often converted to PDF for review or display). Moreover, SPL supplemented (but did not eliminate) paper process for printed labels; for many years companies maintained parallel PDF and XML repositories.

Researchers have studied these systems. For instance, Schadow et al. (2007) assessed how HL7/FDA SPL content could support medication knowledge management. They found that while structured data facilitated some reuse of labeling information, the heavy reliance on text and lack of a unified data model limited automated reasoning (^[26]). This foreshadowed the current push: the industry realized that a more flexible data model (FHIR) was needed to fully leverage labeling data.

Enter FHIR: A New Paradigm

FHIR (Fast Healthcare Interoperability Resources) was introduced by HL7 in the early 2010s as the next-generation standard for health data exchange. Unlike the older HL7 v2/v3/VistA standards, FHIR adopts modern web frameworks and data exchange philosophies. Some key differences from SPL/XML approaches include:

• RESTful API Architecture: FHIR resources are designed to be accessed via APIs. A system can GET a Medication resource or a bundle of Composition resources over HTTP, rather than exchanging entire documents. This aligns labeling with the same mechanisms used for patient records and orders.
• Multi-Format Support: FHIR content can be in JSON, XML, or even Turtle (RDF). JSON in particular is widely used by web developers. By contrast, classic HL7 v3 (SPL) was XML-only. (As one industry analyst notes, “FHIR leverages RESTful web services and open web technologies such as XML, JSON, and RDF, while HL7 [v3] only supports XML” (^[4]).)
• Granularity and Reusability: FHIR decomposes data into thematic resources. For labeling, this means we can have separate FHIR resources for product details, ingredients, text sections, etc., which can be composed into a Bundle for a full label. This contrasts with a single SPL document that includes all content. The HL7 ePI IG defines specific profiles (e.g. a “Core Medicinal Product Definition”) that can be shared across labels (^[9]).
• Extensibility and Versioning: FHIR allows easy creation of implementation guides (as seen in this report) and the addition of extensions, facilitating local adaption without breaking the standard. Versioning and change-tracking are built into FHIR metadata (e.g. meta.lastUpdated).

This new paradigm has practical consequences. FHIR enables real-time queries (e.g. a registry can pull the current label for a batch using an API) and incremental updates (only changed fields need resubmission). It also makes it easier to link labeling to other data – for example, a clinic EHR could automatically cross-reference a patient’s medications with structured label warnings. In essence, FHIR “unlocks” labeling information from static files into a live data ecosystem.

HL7 FHIR Resources for Labeling

The core FHIR specification does not prescribe a specific labeling format, but provides building blocks. In practice, labeling IGs (like the ePI IG (^[27]) and the FDA’s PQ/CMC IG (^[24])) define how standard resources are used. For example, the ePI IG employs about 14 FHIR resources to represent a product’s information (^[9]). Notable resources include:

• Bundle: Used to group related resources (e.g. a set of label sections for a particular product release) into a single transaction or document.
• Composition: Serves as a container listing all the parts of an electronic document. An ePI Composition might contain references to all sections of a label, similar to how a Table of Contents works.
• MedicinalProductDefinition: A complex resource holding core drug details (name, form, ingredients, manufacturer). This consolidates many pieces of product identity that in SPL were spread across separate XML tables.
• Patient, Location, Organization: These are relevant indirectly (e.g. specifying in which country an authorization applies).
• Coding and Terminology: FHIR uses external code systems (SNOMED CT, MedDRA, RxNorm, etc.) for standard terms. The ePI IG specifically “leverages standard code systems (e.g., SNOMED, MedDRA) for consistent data encoding” (^[28]), ensuring data can be universally interpreted.

In addition, specialized profiles and extensions are used. For instance, HL7’s SPL Mapping IG (in development) maps traditional SPL sections into FHIR. Other work (e.g., the Device resource) even accommodates medical device labeling via Unique Device Identifiers (UDI). The FHIR Device resource explicitly includes fields for UDI carrier and details (^[29]), aligning with global UDI regulations. For example, the FDA defines UDI as a fixed Device Identifier (DI) plus a variable Production Identifier (PI) (^[29]), and FHIR’s Device mapping mirrors that structure (with udiCarrier containing DI and PI parts). This shows that FHIR can also encompass device labeling in a structured way.

Challenges of XML-Based Labeling

The shift away from XML/PDF labeling is driven by well-documented challenges in the current ecosystem:

• Inflexibility: Multi-jurisdictional labeling requirements change frequently. Updating a single section in an XML product label requires repackaging and resubmitting the entire document. In contrast, FHIR would allow targeted updates.
• Interoperability Gaps: As noted above, XML-based labels are not naturally consumable by general healthcare IT. Sharing lab results, prescribing data, and product info across systems typically requires custom parsing or document exchange protocols.
• Error-Prone Processes: Manual creation of structured XML or translation from Word documents introduces errors. Duplication of content across multiple XML tables can cause discrepancies. An industry report highlights that manual entry errors and versioning issues plague today’s labeling ecosystem (^[30]).
• Access and Traceability: With paper labels, controlling which version a patient or clinician sees is hard. While FHIR enables features like scanning a QR code on a package to retrieve the specific version of the label that applies, current static approaches lack that precision (^[31]).

These pain points create a clear mandate for modernization. As one expert summary notes, “digital-first ePI delivery ensures greater information accuracy, easier content validation, accelerated regulatory processes, and rapid safety updates,” but only if end-to-end architectures are in place (^[32]).

In light of this, the remainder of the report examines how organizations can prepare their teams to manage this transition. First, we survey the global regulatory context to understand the timing and scope of this change.

Regulatory Landscape and Case Studies

Global Adoption of FHIR in Labeling

Regulators around the world are increasingly endorsing FHIR for product information, signaling that manufacturers must adapt. Key examples include:

• European Union (EMA/EMRN): The EMA’s Electronic Product Information (ePI) initiative aims to create a pan-EU ePI standard. EMA’s Product Lifecycle Management portal and a 2024 pilot used FHIR as the technical foundation (^[21]). The European Medicines Regulatory Network (EMRN) released an ePI FHIR Implementation Guide (v1.0.0) in early 2025 (built on FHIR R5) (^[8]). This IG is intended to serve as a “common core ePI Profile” that can be extended for country-specific needs (^[33]). In practice, this means EMA will soon expect company submissions of label content as validated FHIR resources rather than as PDF or legacy XML.

• Jordan (JFDA): Jordan is a notable early adopter. In 2023, the Jordan Food & Drug Administration announced that a FHIR-based ePI format would become mandatory by end of 2025. Industry conference reports describe how JFDA is already publishing drug labels via a national health app using FHIR ePI. The app includes advanced features (text-to-audio, sign language, facial control) made possible by structured FHIR data (^[6]). This bold move underscores that no global player is waiting to see; emerging markets like Jordan are leapfrogging to FHIR-first labeling.

• Asia-Pacific: Japan’s PMDA amended its Pharmaceutical and Medical Devices Act in 2019 to allow electronic labeling (eliminating paper leaflets) for approved products. The eLabeling mandate came into full effect by mid-2023 (^[22]). While the Japanese implementation initially focused on internet-accessible PDFs, the infrastructure now exists to transition to structured formats. Malaysia’s NPRA issued voluntary eLabeling guidance in 2023 (^[22]). Both countries recognize FHIR as a next step for interoperability; Japanese regulatory speakers have noted that moving to FHIR could further enhance patient-centric labeling.

• United States (FDA): The U.S. Pharmaceutical Quality (PQ) initiative is progressively embedding FHIR into the submissions pathway. The FDA is working with HL7 on a Pharmaceutical Quality – CMC (PQ/CMC) FHIR Implementation Guide to cover drug manufacturing and content (CTD Module 3) (^[24]). Although this initially targets manufacturing data, it is part of a broader digital strategy that may eventually encompass labeling. For now, U.S. companies still submit labeling in SPL format, but the FDA explicitly states it is “developing additional data standards” including for labeling-related modules (^[34]). Companies can expect that, within a few years, the FDA will accept (and possibly require) certain label elements in FHIR structure.

• Other Regions: While not all countries have formal FHIR mandates, many are moving in that direction. HL7 International has active work groups (e.g. Biomedical Research & Regulation) focusing on global ePI standards (^[27]). Multi-country standards like HL7’s Global Core ePI IG v1.1.0 (trial use) show that a unified approach is under development (^[27]). Table 1 below summarizes the status of e-labeling initiatives in various jurisdictions:

Table 1: Global e-Labeling Initiatives: Summary of major regulatory moves toward electronic and FHIR-based labeling around the world. (Sources cited provide details on each initiative.)

Across these examples, a pattern emerges: regulators are moving from passive acceptance of PDFs/XML towards proactive engagement with FHIR. Notably, even in early pilot stages (EMA 2024, JFDA 2025), the vision encompasses patient-centric features and interoperability (see Figure above and [28]). As one industry commentary concludes, “FHIR promises to bring in a new era of innovation to labeling”, enabling interoperability across regions and personalized access to content (^[19]). Analysts therefore predict that compliance with FHIR-based labeling will soon be a necessity for market access.

Case Study – Jordan’s FHIR ePI Pilot

Jordan’s initiative serves as a concrete example of FHIR’s potential. The JFDA’s new rule not only mandates FHIR-format labels, but the government has already built a national app to distribute these labels to patients (^[6]). The app’s features exemplify the opportunities of FHIR:

• Dynamic Content Delivery: Patients can pull up the latest label for their medication on demand. The system ensures the app always serves the version of the label corresponding to the specific batch and release, eliminating confusion over outdated information (^[6]).

• Accessibility: The app includes a “play” button for text-to-speech, dark mode for low-light viewing, and even translation to sign language. These features are enabled by having the label text in standardized, granular form rather than a fixed image (^[6]).

• Interoperability: The app can interact with a broader eHealth infrastructure (e.g. linking prescriptions to product database), because the labels follow a shared FHIR model that can easily integrate with other healthcare resources. As the Jordan FDA stated, “eLabeling will require... global regulatory harmonization... New skills (such as prompt engineering) will be needed” for full success (^[31]).

This case demonstrates that labeling is not just a regulatory formality but a data service that can evolve into an innovative healthcare tool. By participating in such pilot efforts (e.g. through HL7 Connectathons or international working groups), industry stakeholders can influence the standards and prepare their own systems and teams for broader adoption.

Preparing Teams and Infrastructure

Shifting to FHIR-based labeling is as much an organizational change as a technical one. Companies need to assemble the right people, processes, and technology to succeed. Based on published guides from HL7 and industry analysts, the following preparations are recommended:

Organizing the Team

HL7’s ePI Implementation Guide (v1.1) lays out a cross-functional team structure to support FHIR labeling (^[12]). Roles include:

• FHIR Developer: Responsible for building and maintaining the FHIR server and data exchange. Should have skills in RESTful APIs, JSON, and relevant programming (e.g. Java for HAPI FHIR) (^[12]).
• Regulatory Specialist: Ensures that the ePI content and process comply with health authority requirements (e.g. format and mapping guidelines). Interfaces with regulatory bodies.
• Content Author/Medical Writer: Writes and formats the label text using XML/component authoring tools, and works with the developer to encode the content into FHIR profiles. May need training in structured authoring (e.g., component authoring software).
• IT/System Administrator: Manages the infrastructure (secure hosting, backups, network, and FHIR server configuration). Ensures data security (OAuth2 or other authentication for API access, encryption at rest) (^[35]).
• Project Manager: Coordinates the project rollout, maintains timelines, and acts as liaison among teams and external partners.

This multi-disciplinary team ensures both the content and the technology aspects are addressed in parallel. Table 2 (below) summarizes typical roles and responsibilities recommended by HL7.

Table 2: Suggested Team Composition for FHIR ePI Implementation. HL7 guidance recommends a cross-functional team spanning development, regulatory, content, and IT operations (^[12]) (^[35]).

Each role may not correspond to a separate individual in smaller organizations, but the responsibilities must be covered. HL7 also suggests investing in training and governance:

• Training: All team members should gain familiarity with FHIR fundamentals. HL7 offers courses (e.g. FHIR Fundamentals on HL7.org) and numerous online tutorials. The ePI guide specifically recommends hosting internal workshops and training content authors on structured authoring software (^[14]). In short, teams should build expertise in both the technical standard and the patent/coding terminologies used in ePI (e.g. SNOMED, MedDRA).

• Governance: Organizations should develop Standard Operating Procedures for ePI creation, review, and updates (^[36]). This includes defining workflows (who approves content, how updates are versioned) and compliance scans. HL7 suggests establishing an SOP “for ePI creation, validation, and updates” and to monitor community resources (e.g. HL7 Vulcan Accelerator site) for guideline changes (^[36]). Effective governance prevents drift into ad-hoc or inconsistent practices.

• Phased Rollout Plan: As noted below, rolling out FHIR labeling in stages (pilot, production pilot, full deployment) reduces risk. The project manager should define clear success criteria and timelines for each phase. For example, HL7’s Step 7 recommends a Technical Pilot of ~1–2 months (limited scope, use of validation tools) followed by larger-scale testing (^[15]).

Technical Infrastructure and Tools

Preparing the IT infrastructure is equally crucial. Key elements include:

• FHIR Server: Set up a secure, ACID-compliant FHIR server (e.g. HAPI FHIR) to host label resources. This might be on a secure cloud platform. The FHIR server will act as both authoring back-end and distribution endpoint for label data. As HL7 advises: “Deploy the ePI on a local HAPI FHIR server… validate with the FHIR Validator.” (^[37]).

• Authoring Software: Unlike PDF/PPT creation, ePI authoring often uses specialized tools. These could be component-based authoring tools (e.g. structured authoring suites that output XML or JSON) or even spreadsheet templates that feed into FHIR. Content authors may need to install or develop software to capture narrative text and link it to FHIR profiles. The team should procure or build software that can generate FHIR Bundle/Composition resources from author inputs, and prepare any necessary code snippets (e.g. for medication codes, dosage forms).

• Validation Tools: HL7 provides a FHIR validator that checks conformance of resources against profiles and value sets. Integrating this into the authoring pipeline ensures label content meets the FHIR IG rules before submission. The technical pilot (Table 56) should verify that labels “validate without errors” using these tools (^[37]).

• Data Repositories and Integration: Existing label data (SPL XML, internal databases) will need migration or transformation to FHIR. Specialized mapping tools or scripts may be needed to convert legacy XML fields to corresponding FHIR elements. For example, organizations might script mappings of NDC codes and text sections from their current labeling modules into MedicinalProductDefinition and Composition resources respectively.

• Security and Access Control: Because label information may be sensitive (especially prior to approval), the FHIR endpoints should enforce authorization. HL7 recommends using OAuth2 or similar API security, and encrypting data at rest (^[35]). Roles like “FHIR Developer” and “IT Admin” should collaborate to implement these safeguards.

• Backup and Disaster Recovery: Label data is critical regulatory content. Daily backups of the FHIR server and authoring content (as per HL7 advice (^[35])) will ensure that no data loss occurs.

Data Governance and Quality

Effective transition hinges on data quality and governance. This involves:

• Standardized Terminology: Using value sets and code systems is integral. HL7’s ePI IG and other guides prescribe which code systems to use for ingredients, dosages, adverse effects, etc. The team must ensure master data (e.g. unit codes, administration routes) align with global terminologies (SNOMED, UCUM, RxNorm, etc.) to maximize interoperability (^[9]).
• Consistent Templates: Establish a canonical structure for electronic labels (akin to “templates” in SPL). For instance, define within your SOP the required sections (e.g. Indications, Dosage, Warnings) and their order for FHIR Composition resources. This echoes how FDA’s SPL Implementation Guides specify section codes. (^[1])
• Version Control: Track label versions meticulously. Every FHIR resource has metadata (e.g. meta.versionId, meta.lastUpdated). Teams should incorporate these into their release process so that the “latest” label is clear. Regulatory inspectors will expect that the correct FHIR-based label is what is published when a product is scanned or queried (^[31]).
• Audit Trails: Because labeling is regulated, each change should be logged with author and timestamp. The team should leverage FHIR’s Provenance resource or an audit mechanism to record each update cycle for compliance.

Training and Cultural Change

Beyond roles and tools, preparing the organization’s mindset is critical. FHIR represents a different development paradigm:

• Educational Workshops: Companies can host internal “FHIR bootcamps” (possibly led by external HL7 trainers) to bring staff up to speed. HL7’s own training portals, webinars, and community events (like FHIR Connectathons) are valuable resources. For example, HL7’s Vulcan Accelerator community often shares success stories and cautionary lessons from pilot projects.
• Cross-Department Collaboration: Historically, labeling may have been handled by regulatory affairs alone, with IT support only for submissions. FHIR labeling will require ongoing collaboration between regulatory, IT, and even marketing/compliance teams. Embedding FHIR literacy across these groups is a recommended practice. Freyr Solutions explicitly highlights “training teams for the digital transformation” as a crucial step (^[13]).
• Change Management: Management must communicate the “why” of this shift. Emphasizing benefits (faster updates, global harmonization, downstream clinical value) can build buy-in. It may help to pilot FHIR labeling on non-critical products first, allowing staff to experiment without compliance pressure. Celebrating early successes (e.g. publishing a label through a test FHIR server) reinforces momentum.

In sum, preparing your team means establishing clear roles, acquiring new skills (FHIR development, API security, structured authoring), and setting up governance and training mechanisms. Industry guidance and case reports make it clear that this preparation is non-trivial but essential. Organizations that dilute or delay these changes risk falling behind regulatory expectations. As Freyr Solutions concludes, companies that “embrace ePI FHIR will […] position themselves as leaders in innovation and patient care” (^[18]).

Implementation Strategy and Data Considerations

Once prepared, teams move to actual implementation. This involves mapping existing content, validating standards, and working through regulatory submissions. Key evidence-based steps include:

Mapping Legacy Data

• Inventory Existing Label Content: Catalog all textual and coded elements currently used in labels (e.g. ingredients list, tablet images, highlights). Each of these will need a FHIR equivalent (e.g. Ingredient entries, image attachments in Medication resource) (^[9]).
• Use or Develop Mapping Tools: Some HL7 projects are creating mapping guides (such as HL7’s SPL-to-FHIR mapping IG). Depending on vendor support, adopt tools that automate part of the conversion. The U.S. FDA and HL7 collaborators have made initial HL7 FHIR profiles (e.g. for SPL) available on build.fhir.org, which can guide field mappings.
• Populate FHIR Resources: For each product, generate a FHIR Bundle containing the assembled resources for that label. Ensure each so-called “resource instance” includes required identifiers. For example, the ePI IG expects each label to have a unique canonical URL and version identifier (so that distributed data is self-describing).
• Validate Early and Often: At each step, use the HL7 FHIR Validator tool to check conformance. The HL7 PQ/CMC page emphasizes that every dev IG must pass Connectathon testing and balloting before being considered stable (^[16]). Thus, aim to align outputs with interim IG releases (e.g. ePI IG STU1) and run them through FHIR validation as if preparing for an official submission.

Pilot Testing

Following a structured rollout plan is critical:

1. Technical Pilot (Voluntary, Small-Scale): Create 1–2 example product labels in FHIR format. Deploy them on a local FHIR server. Validate that they conform and can be retrieved via API. Activities include: using HAPI FHIR or similar to host the data, running the HL7 validator (ideally connected to the continuous integration build of the ePI IG for latest rules), and sharing the pilot with internal testers (^[37]). Success is defined by error-free validation and the ability to read the label content via the FHIR interface (^[37]).
2. Production Pilot (Constrained Rollout): Expand to a slightly larger scope (multiple products, or one product across multiple regions). Publish on a production-grade server, perhaps with user access. Gather feedback from both internal users and, if possible, a cooperating regulator. Confirm that submission processes and review tools can handle the FHIR bundles.
3. Full Deployment: Once pilots verify feasibility, deploy FHIR labeling across the organization’s portfolio. Update internal SOPs (see Governance section) to make FHIR delivery the standard for new submissions.

Throughout these phases, data collection is key. Maintain logs of validation errors and resolution times, compliance checks, and user satisfaction scores. These metrics form the evidence base (and ROI case) for the transition. For instance, if an error that used to take days to find in a PDF is automatically caught by the FHIR validator, that time savings can be quantified.

Example Metrics and Findings

While comprehensive industry data on labeling transition is still emerging, related surveys give insight:

• A recent HL7 “State of FHIR” survey found 84% of respondents expect increased FHIR adoption in healthcare (^[38]). This suggests high confidence in the standard’s future – a useful data point when justifying investment in training and infrastructure.
• The same survey reported that 65% of countries have explicitly mandated or advised FHIR in e-health regulations (^[11]). If one’s company markets globally, this underscores the need to comply with FHIR-based e-labels (not doing so may exclude certain markets).
• Grand View Research predicts the healthcare API market will grow at ~5% CAGR from 2025–2030 (^[10]), reflecting broad demand for interoperability solutions. Labeling is a subset of this trend, but positioning a team for success in API domains can yield dividends across clinical, supply chain, and regulatory functions.

Taken together, these data points reinforce that FHIR adoption is mainstream and growing. They can be cited in internal presentations to build the case that e-labeling is an industry imperative, not a niche experiment.

Data Quality and Compliance

When actual regulatory submissions are involved, all FHIR data must be as rigorously curated as any labeling. Key points:

• Full Narrative Inclusion: While FHIR structures the data, each resource should still contain human-readable narrative (Composition.text.div) so that regulators or physicians who fetch it see formatted text, not raw codes (^[39]). This is a best practice in FHIR (narrative plus code).
• Binding to Standard Code Systems: Fields for ingredients, excipients, dosage forms, etc., should use controlled vocabulary where possible. For instance, HL7’s ePI IG requires SNOMED-coded routes of administration and LOINC-coded self-administration instruction when applicable (^[9]). Ensuring this consistency prevents misunderstandings (e.g. differing names for the same active ingredient).
• Localization: In multi-country contexts, labels must be in multiple languages. FHIR supports multilingual data elements. The team should design how language variants are included (often through FHIR HumanName or by separate resources with language tags)。
• Audit Trail: Implement FHIR Provenance or a similar mechanism to document who created or updated each resource and when. This is critical for regulatory audits.

Adhering to these data practices will make FHIR labels defensible in audits and inspection. The HL7 PQ/CMC guidance explicitly warns that only published, balloted IGs represent reference content; pre-ballot drafts are not FDA policy (^[16]). By analogy, organizations should await finalization of key IGs (or comment on drafts) before expecting regulatory acceptance of a format. Engaging in Connectathons and ballot feedback (healthcare regulators often participate as observers) is a way to stay informed of impending changes.

Case Study: Preparing Acme Pharma for FHIR Transition (Hypothetical)

To illustrate, consider a hypothetical pharmaceutical company “Acme Pharma” with a global labeling department currently using SPL/XML for drug labels. Management has decided to pilot FHIR labeling. The steps and considerations would be as follows (drawing on best-practice evidence):

1. Kickoff & Training: Acquire HL7 FHIR training for key staff. Form a project team as per Table 2, with dedicated roles. Conduct internal seminars on FHIR principles (e.g. using the HL7 Fundamentals course (^[14])).
2. Infrastructure Setup: IT deploys a HAPI FHIR server in a secure cloud environment. They configure daily backups and OAuth2 authentication (HL7 advice (^[35])).
3. Pilot Mapping: The regulatory team selects one simple product (e.g., an OTC pain reliever) and maps its SPL XML content to FHIR profiles. They use HL7’s ePI IG documentation to guide the structure. A developer scripts a one-shot XML-to-FHIR conversion tool, leveraging HL7 binder tools.
4. Validation & Review: The FHIR label is run through the FHIR validator. Any schema or code errors are fixed. An internal QA (perhaps including a simulated regulatory reviewer) confirms the content is correct and well-formatted.
5. Iteration: Based on issues found (e.g. a missing mandatory field, or a mis-coded ingredient), the team refines their mapping and authoring process. Success criteria are compared to HL7’s “Success Criteria” for pilots (validate without errors, correct API output) (^[37]).
6. Stakeholder Engagement: Once the label passes internal muster, the team schedules a meeting with a regulatory contact (or HL7 workgroup members) to review the approach. They note that Jordan’s example showed patient-friendly features; together, they discuss whether similar enhancements might be needed (e.g. QR codes linking to FHIR labels on packaging).
7. Scaling: Encouraged by pilot success, Acme Pharma rolls out FHIR labeling to additional products, perhaps for one therapeutic area. They update SOPs to require ePI FHIR formatting for all new submissions, per the liability requirement (which HL7 suggests might happen 12–18 months after pilots (^[40])).

Throughout, Acme tracks metrics (validation pass rates, time to incorporate label changes, regulator feedback). It finds, for instance, that detection of a missing safety statement by the FHIR validator saved an estimated 3 hours of manual review. These data are used to build internal business cases for expanding the initiative.

This hypothetical illustrates how the comprehensive approach outlined in this report can play out in practice. In reality, companies such as LexisNexis® Reed Tech and consultancy firms (e.g. Freyr, SeaBridge) are already advising clients along these lines (^[13]) (^[30]).

Discussion: Implications and Future Directions

The convergence of FHIR and labeling has profound implications for the healthcare ecosystem:

• For Industry: Firms that invest early in FHIR capability can achieve faster labeling updates and better regulatory readiness. They may also leverage the data for downstream innovation (e.g. feeding structured label data into pharmacovigilance or AI tools). However, there is a learning curve and upfront cost: teams must become proficient in FHIR tools and semantics. As one HL7 guide cautions, implementation guides evolve through connectathons and ballots, so companies should be agile and prepared for iterative changes (^[16]).

• For Regulators: Adopting FHIR allows regulators to modernize their review processes. They can automate checks (e.g. use FHIR queries to verify dosage against submitted data), and potentially integrate labeling databases with public health systems. That said, as DIA conference discussions highlight (^[31]), agencies must also overhaul inspection readiness: for instance, to ensure that scanning a product code yields the correct version of the label.

• For Patients and Providers: FHIR-based labeling promises greater accessibility and integration with clinical care. Patients won’t have to sift paper leaflets; instead, they can interact with their drug information on apps or EHRs. Envision a doctor’s EHR automatically checking a patient’s prescriptions against FHIR-fed label contents for drug interactions or allergies in real time. Early pilots like Jordan’s show real gains in accessibility for visually impaired or language-diverse populations (^[6]).

• Technology Evolution: The FHIR standard itself continues to mature. Currently most implementations use FHIR R4 or R5. The community surveys indicate that many will skip R5 and move to the upcoming R6 when it becomes normative (^[41]). Teams should monitor these developments. Also, tooling around FHIR is rapidly improving (commercial e-submission platforms, terminology services, etc.). Investing in flexible, standards-based tools will pay off as versions advance.

• Artificial Intelligence: An emerging frontier is the use of AI in labeling. For example, generative models could draft label text, which is then encoded in FHIR. This will necessitate new skills (even “prompt engineering”) and validation processes to ensure AI outputs are accurate (^[31]). The structured nature of FHIR makes it easier to apply NLP and AI to labeling, since data fields are well-defined.

In the long term, the vision is an end-to-end ecosystem: from authoring in componentized formats, through automated checks at regulators (via FHIR), to real-time updates reaching patients. Some experts foresee linking FHIR labels with patient data (under privacy controls) to offer personalized medication guidance. For example, a pharmacist’s app could adjust a label’s warnings based on an individual’s profile by querying a FHIR label resource. Achieving this vision will require mature FHIR frameworks and international harmonization. DOB global collaboration like HL7’s ePI IG and the Progressive Regulators Group at conferences (such as DIA’s labeling meeting) are key venues for aligning these standards (^[19]).

Critically, the transition must ensure backward compatibility during the interim. Most products will still have legacy labels in production. Dual processes (XML and FHIR) may run in parallel for some time. Thus, teams should consider conversion tools and change management strategies that allow graceful cut-over. Over time, as countries start accepting FHIR for formal submissions (similar to how some accept CDISC standards now), the parallel process burden will diminish.

Conclusion

The move from XML-based product labels to HL7 FHIR-based e-labels is a foundational shift in healthcare interoperability. The evidence reviewed in this report – from regulatory guidance, industry surveys, and technical standards – indicates that this transformation is already well underway. Key takeaways include:

• Meaningful Change, Not Mere Translation: The FHIR transition is more than changing file formats; it reimagines labels as active data resources. This requires new mindsets in content creation and delivery.
• Global Imperative: Regulatory trends almost compel adoption. Early movers (like Jordan and EMA) show the path forward, but many other jurisdictions will follow. Organizations should plan for FHIR compliance on a global scale.
• Team Readiness is Crucial: Cross-functional teams with clear roles (developers, regulatory experts, writers, IT, managers) are needed. Training and clear processes (SOPs, pilot testing, governance) are as important as the technical architecture.
• Evidence of Benefit: While quantitative data on cost savings is still accruing, qualitative evidence strongly favors FHIR for improved accuracy, speed, and patient engagement. Successful pilot and early production deployments will generate metrics (e.g. faster update cycles, error reduction) to validate efforts.
• Future-Proofing: Embracing FHIR early positions an organization to leverage future innovations (AI-driven labeling, personalized medicine data, etc.). It also opens doors to new workflows, for example subcontracting e-label creation on a shared digital platform.

We conclude that preparing your team for FHIR labeling is a strategic necessity. While the path involves complexity, the alternative (staying on legacy systems) risks regulatory non-compliance and missed opportunities for innovation. Organizations that proactively train their staff, modernize their data infrastructure, and engage with the evolving e-labeling standards will gain a competitive and compliance advantage.

All statements and recommendations above are supported by authoritative sources and industry case analyses. As one HL7 FAQ emphasizes: FHIR Implementation Guides are living documents, and the journey will be iterative (^[42]) (^[43]). Companies should thus view this transition as an ongoing collaboration with regulators and the HL7 community. Through diligent preparation and engagement, teams can successfully navigate the XML-to-FHIR transition and usher in a new era of smart, patient-centric labeling.

References

• EMA/EMRN ePI Implementation Guide v1.0.0 – FHIR 5.0.0 build. European Medicines Agency, 2025 (^[8]).
• HL7 International – FHIR ePI Implementation Guide. Steps and guidance for building ePI solutions (^[12]) (^[15]).
• J. Matsui, eLabeling and Healthcare Interoperability Accelerate Health Innovation. DIA Global Conference 2025 (Pfizer R&D) (^[25]) (^[6]).
• FDA PQ/CMC (Pharmaceutical Quality) – HL7 FHIR Implementation Guide development. U.S. Food & Drug Administration, 2024 (^[24]) (^[44]).
• FDA Structured Product Labeling Resources – Overview of SPL (HL7 v3) standard. U.S. Food & Drug Administration (^[1]).
• M. Brown (Freyr Solutions), The Future of Pharmaceutical Labeling: Transitioning to ePI FHIR, Freyr Intelligence blog, May 2025 (^[13]) (^[18]).
• Exploring the potential of FHIRs and e-labelling, Pharmaphorum market-access article, 2024 (^[4]) (^[2]).
• State of FHIR Survey 2024 (HL7/Fire.ly), 8 Key Insights, December 2024 (^[11]) (^[38]).
• Grand View Research, Healthcare API Market Size, 2024 (projected growth) (^[10]).