Global Core Electronic Medicinal Product Information (ePI)
1.1.0 - trial-use International flag

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

Type 2 Product Identification

Page standards status: Informative

📋 Pre-requisites: Before starting Type 2, ensure you have completed the Pre-requisites on the Build ePI Type 1 page and have already built a working Type 1 ePI for the product. Type 2 extends Type 1 — it does not replace it.

What is ePI Type 2?

An ePI Type 2 extends the digital label (Type 1) by adding structured, machine-readable product information. This enables national drug catalogues, regulatory portals, and supply-chain systems to search, filter, and retrieve products by name, strength, ingredient, or authorisation number — without reading the narrative text.

You will add these FHIR resources (on top of Type 1)
📦 Bundle + 📄 Composition (from Type 1) 🏢 Organization 💊 MedicinalProductDefinition 📜 RegulatedAuthorization 📦 PackagedProductDefinition 🔬 ManufacturedItemDefinition 💉 AdministrableProductDefinition 🧪 Ingredient ⚗️ SubstanceDefinition
How the Type 2 resources connect
Organization
holder of RegulatedAuthorization
subject is MedicinalProductDefinition
comprised of PackagedProductDefinition
contains ManufacturedItemDefinition
made of Ingredient → SubstanceDefinition
relates to AdministrableProductDefinition
made of Ingredient → SubstanceDefinition

Step-by-Step Workflow

1
Gather your regulatory master data

Before authoring any FHIR resources, collect the structured data from the authorized label and your regulatory and supply-chain systems. This data that already exists — you are digitalising it, not inventing it. For example:

Data item Where to find it
Marketing Authorisation Holder (MAH) legal nameAuthorisation certificate / regulatory database
Authorisation number and dateAuthorisation certificate
Medicinal product name, strength, dose formThe label itself / product master data
Active substance(s) and INN namesThe label / pharmacopoeia
Package configuration (e.g. 30 tablets in a blister in a carton)Pack specifications / artwork brief
GTIN / barcode identifiers (optional)GS1 company database / packaging department
2
Create the Organization resource(s)

Create one Organization resource for each legal entity involved — typically the Marketing Authorisation Holder (MAH) and optionally the manufacturer. The Organization is referenced by several other resources, so build it first.

Field What to enter
identifierOrganisation ID such as DUNS number or SPOR OrgID
nameFull legal name as it appears on the authorisation
typeRole designation — e.g. Marketing Authorization Holder
contact.addressPhysical or postal address of the organisation
contact.telecomContact details including phone, email, and corporate website
💡 Tip: If the MAH and the manufacturer are the same legal entity, one Organization resource is sufficient. Reference it from both the MedicinalProductDefinition and the ManufacturedItemDefinition.
3
Build the product resource chain

Work through the product resources in the order below — each one references the previous. Your authoring tool may automate parts of this chain.

# Resource What it captures
iMedicinalProductDefinitionThe regulatory anchor: product name, type, and marketing status
iiRegulatedAuthorizationThe product licence: authorisation number, holder, validity dates
iiiManufacturedItemDefinitionThe physical item: dose form (e.g. tablet), presentation unit
ivAdministrableProductDefinitionThe product as administered: dose form and route (e.g. oral)
vPackagedProductDefinitionThe packaging hierarchy: carton → blister → tablets, with GTIN
viIngredientClarifies the role, function, and strength/quantity of each substance (e.g., active, excipient, binder)
viiSubstanceDefinitionThe chemical definition of each substance, with standard codes
Consult Local Guidance

Always consult your local regulator's implementation guidance when building this chain. While the Vulcan ePI profile defines this complete set of product resources, some regulators require the full chain, whereas others may only mandate a subset.

4
Define packaging characteristics and artwork

The PackagedProductDefinition fully describes the physical package. Use it to detail physical characteristics including layers (primary, secondary, tertiary), pack types, quantities, materials, machine-readable identifiers (like GTIN, NTIN, SKU), shelf life, and storage conditions. Furthermore, you can optionally attach pack artwork (carton images, label scans) using the native attachedDocument element, referencing a DocumentReference resource.

Recommended pattern
PackagedProductDefinition
  .attachedDocument → Reference(DocumentReference)

DocumentReference
  .type = pack-artwork
  .status = current
  .content[0].attachment.contentType = image/svg+xml
  .content[0].attachment.data = <base64-encoded image>
💡 Why this approach? attachedDocument is a native FHIR R5 element — no extension needed. The DocumentReference carries rich metadata (type, status, date) and can hold multiple formats (thumbnail + hi-res) in a single resource.
5
Link product to the Composition and validate

Update the Type 1 Composition to reference the newly created MedicinalProductDefinition via Composition.subject. Then add all new resources to the Bundle entries and validate.

🔗 Key linkage: Composition.subject → MedicinalProductDefinition. This is what connects the narrative text (Type 1) to the structured product data (Type 2).
✅ Validate: Run the completed Bundle against the Type 2 FHIR Profile. Fix any errors before submission. Full XML/JSON examples are in the Artifacts section.
6
Manage lifecycle and version control

Once your ePI is authorized and published, any future changes must follow a structured versioning process. A new version of the label requires careful updates to the Bundle, Composition, and List resources to maintain historical traceability.

🔄 See Version Control Guide

Before creating a v2.0 or subsequent version of this ePI, read the comprehensive Version Control guide. It explains how to deprecate old versions, link new versions to the historical record, and increment your identifiers correctly.

What's next?