Type 4 Dynamic Digital Label

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

Page standards status: Informative

Highlight text changes?

📋 Pre-requisites: Type 4 builds on top of Types 1, 2, and 3. Before starting here, ensure you have validated Type 1, Type 2, and Type 3 ePIs for the product.

What is ePI Type 4?

An ePI Type 4 is a fully structured representation where narrative text is decomposed into discrete atomic components and mapped to individual FHIR resources. Each atomic component is coded using controlled terminologies (SNOMED CT, MedDRA, etc.) and appropriate metadata. The goal is to create explicit, stable links between narrative content and its corresponding structured content — enabling regulatory, clinical, and digital health systems to interpret and consume the information automatically.

Conceptual examples included within this implementation guide are provided exclusively for illustrative purposes to facilitate understanding of ePI Type 4 requirements.

Resources used in Type 4 (on top of Types 1, 2 & 3)

All Type 1, 2 & 3 resources 🔗 Granular Composition Sections 📎 section.entry references 🏷️ <span> annotations 🧬 Atomic components

🎯 What Type 4 enables

For Regulatory & Industry:

Granular regulatory traceability
Statement-level updates without affecting neighbouring content
Clear alignment between narrative text and coded data
Machine-readable linking for automated processing

For End Users & Systems:

Potential for personalised information extraction
Retrieval of data from harmonised, structured sources
Structure-based information extraction by AI tools
Dynamic content generation and filtering

Type 4 Composition Hierarchy

Composition

contains Concept (≈ Chapter) e.g. "4. Clinical Particulars"

groups Domain (≈ Section) e.g. "4.1 Therapeutic Indications"

contains Topic (≈ Subsection) one discrete clinical/regulatory message

has text + entry → links to FHIR resource(s)

Key Differences from Types 1–3

Difference 1 — Composition Granularity

⚠ Type 1–3: Large Sections

Section 4.1 — Therapeutic Indications
All indications listed as a single block of text under one QRD heading, even if they contain multiple clinically distinct concepts.

One section → multiple concepts → no machine-level separation

✓ Type 4: Granular Topics

      Section 4 ← container only (no text/entry)

        Section 4.1 ← context (no text/entry)

          Section 4.1.1 → Indication #1 + entry

          Section 4.1.2 → Indication #2 + entry

Each topic has its own section + linked entry

Difference 2 — Mandatory section.entry References

⚠ Type 1–3: No entry linking

Composition sections contain narrative text but do not use section.entry to reference structured resources. The connection between narrative and data is implicit.

Text and data exist side by side — not explicitly linked

✓ Type 4: Mandatory entry linkage

Every content-bearing section must include an entry referencing the structured FHIR resource(s) representing that section's meaning:
• Section 1 → MedicinalProductDefinition
• Section 4.1.1 → ClinicalUseDefinition
• Section 2 → ManufacturedItemDefinition + Ingredient

Difference 3 — Semantic Span Annotations in Narrative

⚠ Type 1–3: Plain narrative

<text>

Do not take Diflucan if you are allergic to fluconazole, amoxicillin or sulphonamides.

</text>

Plain text — no programmatic link to resources

✓ Type 4: Span-annotated narrative

      <text>

        Do not take <span class="cud-contra-1">Diflucan</span>
      if you are allergic to <span class="substance-fluconazole">fluconazole</span>

      </text>

      Each span links directly to a resource ID

Step-by-Step Workflow

Create the overall content structure for the ePI template

Set up the document structure according to the regulatory template (e.g. QRD), as with ePI Type 1–3. Divide the information into separate Concepts (corresponding to Chapters), then into Domains (corresponding to Sections), and finally into Topics (corresponding to Subsections).

Example mapping: QRD → Type 4 hierarchy

          Concept (Chapter): "4. Clinical particulars"

            Domain (Section): "4.1 Therapeutic indications"

            Domain (Section): "4.2 Posology and method of administration"

              Topic (Subsection): "Posology"

              Topic (Subsection): "Method of administration"

💡 Concept Definitions: A Topic represents a statement with one discrete clinical or regulatory message. Topics of the same regulatory intent are grouped within a Domain. A Concept groups Domains together and acts as the technical analogue of a document chapter.

Decompose content into granular parts of information

Instead of adding all content as plain narrative text (as in Type 1), structure the content as a hierarchy of discrete meaning. Each information part applies to a specific situation, further divided into separate smaller information elements as applicable. In Type 4, the same implicit approach authors already use with formatting and sub-headings is applied more explicitly and consistently, down to individual statements.

Example — Dosing Decomposition

⚠ Not recommended (Type 1 style)

"2 tablets for elderly, 1 tablet for children."

Combined statement — two populations in one unit

✓ Recommended (Type 4 style)

Statement 1: "2 tablets for elderly."
Statement 2: "1 tablet for children."

Discrete statements — each is its own structural unit

Example — Handling Indications in Narrative

Pattern A — One indication per section:
Authored text: Paracetamol is used for the treatment of Entry: CUD indication#1 → headache

Pattern B — Multiple codable indications in one section:
Authored text: Paracetamol is used for the treatment of Entry: CUD#1 → headache and Entry: CUD#2 → menstrual pain

Pattern C — Codable indication + text-only narrative:
Authored text: Paracetamol is used for the treatment of Text-only: mild to moderate pain such as Entry: CUD#1 → headache and Entry: CUD#2 → menstrual pain

Map to FHIR resources for each concept and divide into Topics

Categorise chapters and sections by regulatory meaning and map statements to the appropriate FHIR resource type. A chapter should refer to a certain domain. A single topic should represent the meaning of one regulatory or clinical message.

SmPC Chapter	Primary FHIR Resource	Type 4 Domain
Chapter 1	MedicinalProductDefinition	Product naming (separate name elements)
Chapter 2	SubstanceDefinition, Ingredient, ManufacturedItemDefinition	Qualitative/quantitative composition
Section 4.1	ClinicalUseDefinition (type: indication)	Therapeutic indications
Section 4.2	MedicationKnowledge	Posology, method of administration
Section 4.3	ClinicalUseDefinition (type: contraindication)	Contraindications
Section 4.4	ClinicalUseDefinition (type: warning)	Special warnings
Section 4.5	ClinicalUseDefinition (type: interaction)	Interactions
Section 4.8	ClinicalUseDefinition (type: undesirable-effect)	Undesirable effects

Apply subdomains to statements

One topic could be divided into separate statements on which subdomains, narratives, integrated coding and attributes could be applied. Subdomains refine a particular dimension, condition, or type of information conveyed by the Topic.

Break statements into atomic components

Specify statements into atomic components to make the information even more specific for personalised search options. An atomic component is one piece of information within a statement that is meaningful on its own.

Example — Diflucan Contraindication Decomposition

"Do not take Diflucan if you are allergic to fluconazole, amoxicillin or sulphonamides."

Atomic #1

"Do not take"

= contraindication

Atomic #2

"Diflucan"

= trade name

Atomic #3

"if you are allergic"

= condition

Atomic #4

"fluconazole"

= active substance

Atomic #5

"amoxicillin"

= substance

Atomic #6

"sulphonamides"

= therapeutic class

💡 Note: These components may be formulated as separate sentences and/or when rendering a complete document, presented together as either one or several sentences. A standard sentence such as "Do not take <trade name> if you are allergic to <active substance>" may also be coded as being derived from RMS (SPOR database) in the EU region.

Populate resource narrative text (<text>)

To make use of structured resources and facilitate narrative-data linking, parts of the narrative text are proposed to be generated from structured resource content, rather than authored independently. Each resource (ClinicalUseDefinition, etc.) includes a narrative block in the <text> element.

📝 Narrative Types in Type 4

AUTH Authored narrative text: Human-written, authoritative text entered directly into <text>. Unlike generated text, its origin is human authoring, and it frequently contains annotations linking to structured resources (e.g., "Paracetamol is used for the treatment of mild to moderate pain").

GEN Generated display text: Rendered automatically from structured, coded data elements.

VAL Value-based narrative elements: Short textual values from structured data fields (dose amounts, frequencies, durations).

ANN Annotated narrative text: Includes <span class="…"> markup linking specific phrases to structured FHIR resources.

TXT Text-only narrative: Human-written descriptive filler or "glue" phrases (e.g., "such as") used purely for readability. It has no corresponding structured resource and represents no formal clinical concept.

Example — Diflucan Contraindication narrative

          <text>

            <status>generated</status>

            <div xmlns="…">

              Do not take Diflucan if you are allergic to fluconazole.

            </div>

          </text>

Apply semantic text annotation (<span> tagging)

Embed <span class="…"> within narrative text to bind specific words to structured FHIR resources. Together with section.entry, spans create a fully traceable link between narrative and structure.

Rules for Span Tags

A span class must correspond to the ID of the referenced structured resource
Spans should wrap the minimal phrase representing the formal coded concept
Span classes must be stable identifiers matching the resource ID
Required when text mentions age/sex/condition constraints or coded concepts
Optional when text does not refer to any structured resource

Three span variants

A — Class-based (extension)

<span class="substance wheat-starch">wheat starch</span>

Requires Gravitate Health HtmlElementLink extension

B — UUID-based (direct)

<span id="69ea7db9-…">wheat starch</span>

Direct link to ClinicalUseDefinition UUID

A+B — Combined

<span class="…" id="69ea…">wheat starch</span>

Redundant but valid — both approaches together

Apply relationships between topics

A main topic (such as an interaction) may be connected to other information that should be read in conjunction. Type 4 ePI requires explicit relationships between related topics.

Example — St. John's Wort / Ritonavir Interaction

Drug-drug interaction: Ritonavir levels may increase on stopping St John's wort.
→ Relationship to posology: The dose of ritonavir may need adjusting.
Effect: The inducing effect may persist for at least 2 weeks after cessation.
→ Relationship to CUD Contraindication + AnchorLink: (see section 4.3).

Assign attribute labels

Attribute labels support regulatory granularity, filtering, and automation. Information applicable only to a certain population should be marked with attributes for that group.

Population Type	Diflucan Example
Age range	Premature neonate: 0–30 days
Sex	Male only conditions
Physiological state	Pregnancy, lactation
Comorbidity	Renal impairment requiring dose adjustment

💡 Tip: If the indication applies to all patients, no population attribute is required. If using a modal structure, an option where no active choice results in the attribute "All" may apply.

Apply controlled terminology, coding, and finalise

Use controlled terminology and coded data where available. Portions of text can then be generated automatically from structured resources rather than authored manually.

Component	Terminology	Rationale
Clinical content (indication, etc.)	SNOMED CT	Detailed clinical concepts
Adverse effects	MedDRA	Regulatory standard for pharmacovigilance
Substances	SNOMED CT	Substance hierarchy fits clinical contexts
Age groups	SNOMED CT	Standardised age group concepts

✅ Finalise: Package the updated Type 4 content into the official ePI Bundle. Validate against the Type 4 FHIR Profile. Full examples are in the Artifacts section.

What's next?

Build a List of ePIs

Learn how to group and track multiple ePI documents across products, jurisdictions, and languages.

← Previous

Type 3 Clinical Information

Return to the clinical information step to review structured ClinicalUseDefinitions.