Global Core Electronic Medicinal Product Information (ePI), published by HL7 International - Biomedical Research & Regulation Work Group. This guide is not an authorized publication; it is the continuous build for version 1.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/emedicinal-product-info/ and changes regularly. See the Directory of published versions

Version Control

This page describes the recommended approach for versioning an ePI document throughout its lifecycle. This includes from drafts submitted for review, updates during label assessment, approvals, withdrawals, ePI merges or ePI split.

Overview

The ePI document is represented as a FHIR Document Bundle containing a Composition resource and other related resources. Only the Bundle and Composition resources are needed to support this version control method.

The following sections describe how to use the relevant Bundle and Composition elements to achieve the desired outcomes for version control, audit trails, and traceability.

Bundle Version Elements

• Bundle.id: A server-managed Universally Unique Identifier (UUID) that uniquely identifies the Bundle resource instance on the server. This ID is not persistent across versions. As a server managed id it will be overwritten each time it is moved or copied to a different FHIR server.
• Bundle.meta.versionId: A server-managed version number, incremented with each update to this ePI (e.g., 1, 2, 3, 4).
• Bundle.meta.lastUpdated: A server-managed timestamp indicating the last modification time of this Bundle.
• Bundle.identifier: A business-managed UUID that remains the same across all versions of a specific ePI. This identifier is used to group a set of ePIs together across versions.
  Unlike the server-managed identifier, this identifier is assigned by a business user's structured authoring software. This identifier remains unchanged by FHIR servers even if the ePI is copied or moved to a different server. This identifier serves as a common identifier for use across organizations or departments.

Composition Version Elements

• Composition.identifier: A business-managed UUID that is unique for each version of the ePI. A new UUID is generated for each version to distinguish this ePI from any other versions.
• Composition.version: A business-managed version number (e.g., 1, 2, 3, 4), incremented with each update to this ePI.
• Composition.status: Indicates the lifecycle status of the ePI, with values restricted to preliminary, final, cancelled, entered-in-error, or deprecated.
• Composition.relatesTo: Used to establish a lifecycle link between two or more related ePIs. E.g., a draft label is related to the authorized label it was copied from.

Composition.status Terminology

Value	Purpose / Use Case in ePI
preliminary	The ePI is a draft (e.g., during initial submission, variation, renewal or any update process). It is still under review by the company or regulatory authority and not yet approved for use.
final	The ePI has been officially approved by the regulatory authority and is the current authorized electronic product information in force.
cancelled	A draft ePI that was abandoned (e.g., submission withdrawn before approval or a parallel variation draft that is no longer pursued).
entered-in-error	The ePI was created or published by mistake and must be ignored (e.g., accidental duplicate).
deprecated	A previously approved (final) ePI that has been officially superseded or withdrawn (e.g., marketing authorisation revoked, product discontinued, or replaced by a newer approved version).

Composition.relatesTo Terminology

Value	Purpose / Use Case in ePI
derived-from	Used when creating a new draft ePI by copying content from an existing approved (final) ePI as the starting point (e.g., for a variation, renewal, or safety update).
amends	Used when a new approved ePI modifies or adds content to a previous approved ePI, especially in merge scenarios where content from multiple approved ePIs is consolidated into one.
replaces	Used when a newer version (draft or final) completely supersedes an earlier version of the same ePI lineage (e.g., subsequent drafts during review, or a new approved version replacing the previous approved one).
retracts	Used to formally withdraw or invalidate a previous version (usually in combination with status = deprecated or entered-in-error).

Version Control Scenario Example

Step 1: Creating a New Version

1. A new Bundle is created with a new Bundle.id and an initial Bundle.meta.versionId of "1".
2. The Bundle.identifier remains the same as in previous versions to maintain continuity.
3. A new Composition is included with a new Composition.identifier and an updated Composition.version.
4. The Composition.relatesTo field references the prior version’s Composition, if applicable.

Step 2: Updating an Existing Version

1. The server updates the existing Bundle, incrementing Bundle.meta.versionId and updating Bundle.meta.lastUpdated.
2. The Bundle.identifier remains unchanged.
3. The Composition may be updated with a new Composition.identifier and Composition.version if the update constitutes a new document version.

Step 3: Tracking and Audit

1. Both Bundle.identifier and Composition.identifier allow tracking of the ePI document across systems.
2. The Composition.relatesTo field provides a version history by linking to prior Compositions.
3. Server-managed fields (Bundle.id, meta.versionId, meta.lastUpdated) ensure compliance with FHIR versioning.

Viewing ePI Lifecycles

Tabular view of an ePI lifecycle

#	ePI Document	Action	bundle.identifier	composition.identifier	composition.version	composition.status	composition.relatesTo	Notes
1	Initial ePI	Company creates initial draft	UUID-1	UUID-A1	1	preliminary	-	Submitted as part of MAA to EMA
2	Initial ePI	Company updates draft	UUID-1	UUID-A2	2	preliminary	replaces UUID-A1	First update to initial draft
3	Initial ePI	Company updates draft	UUID-1	UUID-A3	3	preliminary	replaces UUID-A2	Second update to initial draft
4	Initial ePI	EMA approves ePI	UUID-1	UUID-A4	4	final	replaces UUID-A3	Approved ePI for use
5	Safety Update ePI	Company creates draft from approved ePI	UUID-1	UUID-B1	5	preliminary	derived-from UUID-A4	New ePI for safety update, submitted to EMA
6	Stability Update ePI	Company creates draft from approved ePI	UUID-1	UUID-C1	6	preliminary	derived-from UUID-A4	New ePI for stability update, submitted to EMA
7	Safety Update ePI	Company updates draft	UUID-1	UUID-B2	7	preliminary	replaces UUID-B1	First update to safety draft
8	Safety Update ePI	Company updates draft	UUID-1	UUID-B3	8	preliminary	replaces UUID-B2	Second update to safety draft
9	Stability Update ePI	Company updates draft	UUID-1	UUID-C2	9	preliminary	replaces UUID-C1	First update to stability draft
10	Stability Update ePI	EMA approves ePI	UUID-1	UUID-C3	10	final	replaces UUID-C2	Stability update approved by EMA
11	Safety Update ePI	EMA approves ePI	UUID-1	UUID-B4	11	final	replaces UUID-B3	Safety update approved by EMA after stability update
12	Stability Update ePI	Merge content from approved safety update	UUID-1	UUID-C4	12	final	amends UUID-C3, derived-from UUID-B4	Updated stability ePI incorporates safety update content

Graphical view of an ePI lifecycle

The version-control metadata in the ePI Bundle/Composition can easily be rendered as a diagram (e.g., using Mermaid, GraphViz, draw.io). See the following figures for examples.

Figure 1 – From initial draft to first approved ePI

​

Figure 2 – Parallel safety and stability variations with final merge

​

Figure 3 – Deprecation / withdrawal of an authorised ePI

​