One managed environment for ePI. Before and after EMA.

One managed environment for creating, checking, approving and tracking ePI — before and after submission to EMA. That is the core proposition.

A medical writer changes approved medicinal product information in Word. The organisation must then not only deliver the same meaning as FHIR, but also know which source, rules, review and version led to that delivery — and whether the same result became available after publication.

EMA's PLM Portal includes an ePI editor. The current EMA FAQ also explicitly permits marketing authorisation holders to create FHIR ePI using their own systems or providers and then import it. The portal is therefore the official destination; it need not be the daily management environment or the organisation's only source of truth.

Elk Solutions is therefore developing a specialised ePI control layer rather than a second standalone editor. The existing transformation core already proves the controlled Word↔FHIR transition. The surrounding management environment is in its design-partner phase.

One environment, one demonstrable chain

Word, FHIR and the EMA portal do not need to do the same job.

Word remains suitable for writing, track changes, comments and established approval processes. FHIR records which document, language and official ePI section a text represents. The value appears when both sides demonstrably refer to the same content.

The transformation core treats FHIR as the canonical structure and creates a controlled DOCX from it. Each section receives a stable identity, source hash and content fingerprint. After a Word change, only demonstrably changed section narratives are written back. A semantic diff then shows what did and did not change.

The intended management environment brings together what is easily scattered today:

• products, marketing authorisations, documents and languages;
• the organisation's own QRD templates, terminology and business rules;
• import of Word and existing FHIR ePI;
• version management and meaningful differences between versions;
• separate roles for author, reviewer and final accountable owner;
• recorded checks, comments and approvals;
• automatic FHIR generation and local validation;
• a complete and reproducible EMA submission package;
• a visible status: draft → checked → approved → ready for EMA → submitted → published;
• after publication: retrieve the ePI through EMA's public API and automatically compare it with the approved version.

EMA currently documents a public read API for published ePI, but no public write API for automated submission. The portal action therefore remains an explicit part of the chain instead of the solution implying automation that does not exist.

Action outside the system required

Upload package EP-2026-0042 in the PLM Portal. SHA-256, version, approver and date have been recorded.

Once EMA publishes the ePI, the environment retrieves the result through the public API. Only a semantically green comparison closes the evidence chain.

The product boundary: a control layer, not RIM or DMS

The environment does not replace a general document management or Regulatory Information Management system. It connects existing sources and systems to the official EMA process and controls precisely the ePI transition:

Existing sources and systems
             ↓
   ePI management environment
   structure · check · review
       prove · export
             ↓
       EMA PLM Portal
             ↓
      Published ePI API
             ↓
    automatic final check

The environment can be supplied in two forms:

• managed private environment: Elk Solutions operates the technology; the client manages content, roles and rules;
• self-hosted/private cloud: source information and management remain entirely within the organisation's own infrastructure.

This makes “under your control” a demonstrable system choice rather than a marketing claim.

What the trial proves today

The current demonstrator completes one full, bounded chain:

1. it reads a public EMA FHIR example;
2. it turns the 32 nested SmPC sections into a controlled Word document;
3. exactly one visible text change is applied;
4. only that changed narrative is patched into the original FHIR;
5. 31 other sections and non-narrative content remain preserved;
6. a semantic difference report makes the outcome reviewable;
7. the official HL7 FHIR Validator with the EMRN ePI profile reports 0 errors and 0 warnings.

The automated suite contains 27 tests. The Java code reaches 88.44% line coverage and 75.04% branch coverage. That supports the technical evidence, but does not replace a practical test with your own document workflow.

What the management environment does not yet prove

The boundary matters as much as the green result.

• The working round trip uses a DOCX controlled by the solution; arbitrary historical QRD documents are not yet recognised freely.
• The full trial uses one public English CAP SmPC example; multilingual portfolio processing is not yet a product feature.
• Portfolio and language management, user roles, approval flows, organisation rule sets, delivery registration and RIM integration have not yet been implemented as a production service.
• Comparison with published ePI through the EMA API is a designed next step; the current demonstrator does not yet perform this closing verification.
• EMA currently offers no publicly documented ePI write API. Import, formal submission and publication therefore remain steps in the PLM Portal and with the competent regulator.
• The official validator checks FHIR and profile rules. A green validator does not independently prove that every regulatory content decision is correct.
• No public software licence has yet been chosen for the project’s own code.

This is therefore a working core with a management environment in its design-partner phase, not a finished ePI platform.

Where the first practical value lies

The first saleable value is neither “making a DOCX” nor “another editor”. It lies in three decision points:

• preflight before upload: find technical and profile problems earlier in the submission process;
• round-trip evidence after a change: show which sections changed, which were preserved and what still requires human review.
• management evidence around delivery: trace which source, rules, approval and package version went to the PLM Portal and verify what became available after publication.

This is particularly relevant to Regulatory Operations, product-information and labelling teams, medical-writing agencies, submission service providers and RIM integrators. A service provider or integrator with several client workflows is likely to be the strongest first design partner.

Why now

European introduction is phased. EMA’s roadmap describes voluntary operational use for centrally authorised products from late 2026, starting with vaccines, followed by oncology and then broader use. Word and PDF will initially continue alongside ePI.

That makes this the right time not merely to learn how to produce FHIR, but to make the entire route from managed source to published result verifiable.

Sources

• EMA ePI Frequently Asked Questions
• EMRN ePI Implementation Guide
• EMA ePI user guide for applicants
• EMA public API for published ePI
• EMA ePI implementation roadmap