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 approach to versioning ePI documents, along with an example lifecycle illustrating how ePI documents evolve through drafting, updates, submissions, approvals, and content merging.

Overview

The ePI document is represented as a FHIR Document Bundle containing a Composition resource and other related resources. Versioning is managed at both the Bundle and Composition levels to ensure traceability.

Bundle Versioning

• Bundle.id: A server-managed UUID that uniquely identifies the Bundle resource instance on the server. This ID is not persistent across versions.
• Bundle.meta.versionId: A server-managed version identifier, incremented with each update to the Bundle (e.g., "1", "2"). This supports FHIR resource versioning.
• Bundle.meta.lastUpdated: A server-managed timestamp indicating the last modification time of the Bundle.
• Bundle.identifier: A business-defined UUID that remains persistent across all versions of the ePI document. This identifier enables tracking of the same logical document across systems and versions.

Composition Versioning

• Composition.identifier: A business-defined UUID that is unique for each version of the ePI document. A new UUID is generated for each version to distinguish it from previous versions.
• Composition.version: A human-readable string (e.g., "1", "2") indicating the version of the document, managed by the business or authoring system.
• Composition.status: Indicates the lifecycle status of the document, with values restricted to preliminary, final, amended, corrected, appended, entered-in-error, or deprecated.
• Composition.relatesTo: Used to link to related Composition resources, such as previous versions, with a type of derived-from, appends, corrects, replaces, or retracts. For example, a new version may use relatesTo with a type of replaces to reference the prior version’s Composition.

Version Control Process

1. Creating a New Version:
   • A new Bundle is created with a new Bundle.id and an initial Bundle.meta.versionId of "1".
   • The Bundle.identifier remains the same as in previous versions to maintain continuity.
   • A new Composition is included with a new Composition.identifier and an updated Composition.version.
   • The Composition.relatesTo field references the prior version’s Composition, if applicable.
2. Updating an Existing Version:
   • The server updates the existing Bundle, incrementing Bundle.meta.versionId and updating Bundle.meta.lastUpdated.
   • The Bundle.identifier remains unchanged.
   • The Composition may be updated with a new Composition.identifier and Composition.version if the update constitutes a new document version.
3. Tracking and Audit:
   • Both Bundle.identifier and Composition.identifier allow tracking of the ePI document across systems.
   • The Composition.relatesTo field provides a version history by linking to prior Compositions.
   • Server-managed fields (Bundle.id, meta.versionId, meta.lastUpdated) ensure compliance with FHIR versioning.

ePI Document Lifecycle Example

The following table outlines an example lifecycle of ePI documents submitted to the European Medicines Agency (EMA) as part of a Marketing Authorisation Application (MAA). It tracks an initial ePI, a safety update ePI, and a stability update ePI through drafting, updates, submissions, approvals, and content merging. Each ePI is represented as a FHIR Bundle containing a Composition resource, with versioning managed as described above.

Stage	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	appends UUID-C3, derived-from UUID-B4	Updated stability ePI incorporates safety update content

Lifecycle Notes

• bundle.identifier: A persistent business UUID that remains constant for all versions of the same logical ePI document (e.g., UUID-1 for all ePI versions).
• composition.identifier: A unique UUID for each version of the Composition, changing with each draft or approved version.
• composition.version: A human-readable version number (e.g., 1, 2, 3) incremented as per business rules.
• composition.status: Reflects the document's lifecycle state (preliminary for drafts, final for approved ePIs).
• composition.relatesTo: Links to prior versions or related ePIs with a type of derived-from, appends, corrects, replaces, or retracts (e.g., replaces for updates to the same ePI, derived-from for creating a new ePI from an approved one, appends for merging content).
• The final stage (merging) assumes the approved stability update ePI is updated to include relevant content from the approved safety update ePI, creating a new version (12) with relatesTo indicating the merge.

Composition.relatesTo Values

The following table defines the allowed values for the Composition.relatesTo element, specifying their purpose in linking related Composition resources.

Value	Definition
derived-from	for creating a new ePI from an approved one.
appends	for adding content to an existing ePI. Particularly when merging two or more ePIs.
corrects	for correcting errors or inaccuracies in a previous version.
replaces	A new draft supersedes an earlier draft, modifying or updating existing content by adding new information or revising content.
retracts	for withdrawing or invalidating a previous version, indicating it should no longer be used.