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 1

Page standards status: Informative

ePI Type 1 focusess on the Narrative Reproduction of official label templates (e.g., Summary of Product Characteristics, Patient Information Leaflet). It serves as the digital replacement for traditional DOCX or PDF labels.

Structural Outline

The ePI Type 1 document is a FHIR Bundle containing a Composition (the narrative backbone). Any necessary images are contained within the Composition as Binary resources.

graph TD
B[Bundle: document] --> C[Composition]
subgraph "Composition Resource"
C --> S1["Section: 1. Name"]
C --> S2["Section: 2. Strength"]
C --> SN["Section: n. ..."]
C -. "contained" .-> BI["Binary: Image 1"]
C -. "contained" .-> BJ["Binary: Image 2"]
end

Key Elements Checklist

  • [Bundle]
    • id: Unique logical ID for the resource.
    • meta: Must include versionId, lastUpdated, and profile (e.g., bundle-epi-type1).
    • type: Must be set to document.
    • identifier: Unique business ID for the document instance.
    • timestamp: The date/time the bundle was assembled.
    • entry: Reference to the Composition resource.
  • [Composition]
    • status: Workflow state (e.g., preliminary, final).
    • type: Identifies the document type (e.g., SmPC, PIL).
    • subject: Link to the associated medicinal product.
    • date: The official authorization or revision date.
    • author: The Organization responsible for the content.
    • title: The human-readable title of the document.
    • contained: List of Binary image resources.
    • section: Hierarchical sections containing the XHTML narrative.
      • id: Each section must have a unique id attribute (e.g., a UUID) to serve as an anchor for hypertext linking.
      • entry: Can be used to reference related structured ePI resources (e.g., MedicinalProductDefinition, Ingredient).
  • [Binary]
    • contentType: The image MIME type (SVG preferred).
    • data: The Base64-encoded image data.

Resource & Element Details

The following table maps the core resources to their purpose and specific implementation requirements in Type 1.

Resource Purpose Key Elements & Notes
Bundle The physical container for the ePI document. Must use type: document. The first entry must be the Composition. Any referenced Binary resources must also be included in the entries.
Composition Organizes the narrative structure. Uses section.code to identify standard sections (e.g., dosage). section.text contains the div with XHTML content.
Binary Stores embedded media. Images are stored as Base64. SVG is the preferred format for accessibility and scalability.

Conceptual Workflow

While implementation may vary based on your tech stack, the general flow for building a Type 1 ePI is:

  1. Extract Narrative: Convert existing label content into clean, semantic XHTML.
  2. Prepare Media: Convert images to SVG and encode as Base64 for the Binary resources.
  3. Define Structure: Create the Composition resource, mapping narrative sections to the correct regulatory codes.
  4. Assemble Bundle: Package the Composition and Binary resources into a Bundle.
  5. Validate: Verify against the Type 1 Profile to ensure compliance.

Implementation Examples

Refer to the following examples for a technical starting point:

  • JSON Example: SmPC Type 1 (Source)
  • JSON Example: PIL Type 1 (Source)