Global Core Electronic Medicinal Product Information (ePI), published by HL7 International / Biomedical Research and Regulation. 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
Build List of ePIs
What is an ePI Tracking List?
The FHIR List resource is a versatile configuration tool within the ePI ecosystem. It is primarily used to track and manage collections of ePI documents, acting as a real-time registry of authorized product information.
Primary Use Cases
There are four primary industry use cases for implementing the ePI Tracking List:
💊
Medicinal Product
A list of ePIs for a given medicinal product. Regulators or MAHs use this to track all localized languages and document types (e.g., SmPC, PIL) for a single authorized product.
👉 View Showcase
🗂️
Medicinal Product Group
A list of ePIs for a given class or category. Track all ePIs related to a specific therapeutic category, such as all approved respiratory vaccines or oncology products.
👉 View Showcase
🏛️
Jurisdiction
A list of ePIs authorized by a health authority within their jurisdiction. For example, all ePIs authorized by PMDA for use in Japan, or all ePIs centrally authorized by EMA.
🌍
Jurisdiction Group
A list of ePIs authorized by multiple health authorities for a region. Track approved ePI documents across an entire region (e.g., all ASEAN member countries).
👉 View Showcase
How to Build the List
Building an ePI Tracking List from a business process perspective is simple:
1
Create a new FHIR List resource. Immediately set the status to current to indicate it is published, and set the mode to working because ePI tracking lists are living documents that evolve as new products are approved, updated, or withdrawn.
2
Define the Scope and Metadata
Assign the correct list classification code based on the 4 use cases, and apply the appropriate metadata extensions. Fill in the core list elements below:
| Element |
Description |
extension | Captures the list's VersionNumber, Jurisdiction, MedicineDomain, and RegulatoryAgency. |
identifier | Carries the persistent UUID that spans across versions. |
code | The classification (medicinal-product, jurisdiction, etc). |
subject | Reference to the medicinal product(s). Heavily used in single-product lists. |
source | The organization that instantiated the list. |
3
As new ePI Bundles are approved by the health authority, append a new entry object to the List.
| Element |
Description |
entry.item.identifier | Should strictly point to the newly registered ePI Bundle UUID. |
entry.item.display | Use this to provide an immediate human-readable title/context. |
entry.flag | Explicitly label the class of document (e.g. smpc, pil, pack-artwork). |
4
Maintain history across versions
An entry should only be soft-deleted (by setting entry.deleted to true) if it is no longer needed (e.g., Marketing Authorization is withdrawn) or if the ePI's bundle.identifier has fundamentally changed.
🔄 See Version Control Guide
Since an ePI's Bundle.identifier persists across normal version updates, the existing List entry will naturally point to the current version without needing to be marked as deleted. See the Version Control guide for deep-dive examples.
What's next?
|
Propose a change