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

Build ePI Type 2

Page standards status: Informative

ePI Type 2 focusess on Product Identification. It extends the narrative reproduction of Type 1 by adding structured resources for organizations, product definitions, and regulatory context. This type enables machine-level lookup in national drug catalogues.

Structural Outline

The ePI Type 2 document is a FHIR Bundle that includes the narrative Composition and a suite of "Product" resources. Any images remain contained within the Composition.

graph TD
B[Bundle: document] --> C[Composition]
B --> ORG[Organization]
B --> MPD[MedicinalProductDefinition]
B --> RA[RegulatedAuthorization]
B --> PPD[PackagedProductDefinition]
B --> MID[ManufacturedItemDefinition]
B --> APD[AdministrableProductDefinition]
B --> ING[Ingredient]
B --> SUB[SubstanceDefinition]

subgraph "Composition Resource"
C --> S1["Section: ..."]
C -. "contained" .-> BI["Binary: Image"]
end

MPD --> ORG
RA --> MPD
RA --> ORG
PPD --> MPD
PPD --> MID
MID --> ORG
APD --> MID
ING --> SUB

Key Elements Checklist

  • [Bundle]
    • id: Unique logical ID for the resource.
    • meta: Must include versionId, lastUpdated, and profile (e.g., bundle-epi-type2).
    • type: Must be set to document.
    • identifier: Constant document tracking ID.
    • entry: References to all resources in the bundle (Composition, Product, etc.).
  • [Composition]
    • status: Typically final for released labels.
    • relatesTo: Used to link this ePI to a previous version for automated diffs.
    • subject: Reference to the MedicinalProductDefinition.
    • author: Reference to the Organization (MAH).
    • contained: Includes Binary image resources.
  • [MedicinalProductDefinition]
    • name: The full name of the medicinal product.
    • type: Standardized product type (Human medicinal product).
    • marketingStatus: The current commercial status.
  • [Organization]
    • name: Legal name of the MAH or Regulatory Authority.
    • type: Role designation (e.g., Marketing Authorization Holder).
  • [ManufacturedItemDefinition]
    • manufacturedDoseForm: The physical form (e.g., Tablet).
    • unitOfPresentation: The presentation unit (e.g., 100 mg Tablet).
  • [AdministrableProductDefinition]
    • administrableDoseForm: The form as administered (e.g., Solution for injection).
    • routeOfAdministration: How it is given (e.g., Intravenous).
  • [SubstanceDefinition]
    • code: Standardized chemical code (e.g., SNOMED CT).
    • name: Official substance name.

Resource & Element Details

The following table maps the additional resources required for Type 2.

Resource Purpose Key Elements & Implementation
MedicinalProductDefinition The regulatory "anchor" for the product. Must include a unique identifier and a reference to the Organization.
Organization Details the MAH or Regulator. Provide the name and identifier (e.g., DUNS or SPOR OrgID).
RegulatedAuthorization Documents the product license. Links the subject (Product) and holder (Org). Include the identifier (license number).
PackagedProductDefinition Describes the presentation (e.g., box of 20). Include package hierarchy and containedItem (linking to the manufactured form).
ManufacturedItemDefinition Focuses on the physical item produced. Specify manufacturedDoseForm and reference the Organization (manufacturer).
AdministrableProductDefinition Details the product in its final usable state. Define administrableDoseForm and routeOfAdministration.
Ingredient Details the chemical makeup. Define role (active/excipient) and strength. Links to the SubstanceDefinition.
SubstanceDefinition Technical definition of the chemical substance. Provide code and name. Required for all active ingredients.

Pack Artwork

Pack artwork (e.g., carton images, blister images, label scans) should be attached to the relevant PackagedProductDefinition using the native PackagedProductDefinition.attachedDocument element, referencing a DocumentReference resource.

This is preferred over using a Binary resource directly or a custom extension because:

  • attachedDocument is a native FHIR R5 element — no extension is required.
  • The DocumentReference carries rich metadata: document type code, status, effective date, and content format.
  • Multiple formats can be attached in a single DocumentReference (e.g., thumbnail and hi-res in separate content.attachment entries).
  • The association is explicit and portable within a self-contained ePI Bundle.
PackagedProductDefinition
  .attachedDocument → Reference(DocumentReference)

DocumentReference
  .type    = <code for "pack-artwork">
  .status  = current
  .date    = <approval date of artwork>
  .content[0].attachment.contentType = image/png
  .content[0].attachment.data        = <base64-encoded image>
  .content[0].attachment.title       = "Box 30 Tablets — Pack Artwork"

The entry.flag value pack-artwork on a List entry indicates that the ePI Bundle referenced in that entry contains pack labeling artwork attached via this pattern.

Conceptual Workflow

Building a Type 2 ePI requires integrating regulatory Master Data with the narrative content:

  1. Map Master Data: Extract product IDs, MAH details, and authorization dates from your regulatory systems.
  2. Generate Structured Resources: Create FHIR representations of the Product, Org, Authorization, and Ingredients.
  3. Cross-Link Resources: Ensure the MedicinalProductDefinition is correctly linked to the MAH (Organization) and the Authorization.
  4. Reference Product in Composition: Update the Composition.subject to point to the MedicinalProductDefinition.
  5. Assemble and Validate: Package all resources into a Bundle and validate against the Type 2 Profile.

Implementation Examples

Refer to the following examples for a technical starting point:

  • JSON Example: SmPC Type 2 (Structured) (Source)
  • JSON Example: PIL Type 2 (Structured) (Source)