A safety warning in a medicinal product document changes. The medical writer updates the QRD document in Word. Regulatory Affairs reviews the text using track changes. Comments, language versions and final approval follow.
At that point, the content is ready, but the electronic product information is not. For European electronic Product Information (ePI), the same approved text must also be available as structured FHIR.
Solving that step through copy and paste effectively starts a second authoring round. A paragraph, section code, language or table can then differ from the version that was just approved.
That is exactly the problem we have addressed: we do not replace Word, we connect the existing Word workflow to structured ePI.
Word and FHIR each have a different job
Word is strong at writing, editing and visual comparison. Teams know the tool, reviewers can follow changes and the document fits existing approval processes.
FHIR serves another purpose. It records not merely that something looks like a heading, but which official ePI section it represents, which document type and language the content belongs to, and how another system can reuse it.
The European Medicines Regulatory Network ePI Implementation Guide models this information in FHIR. EMA also states that organisations may create ePI with external tools and upload it as FHIR. EMA does not provide a Word-to-FHIR plugin.
The two worlds will continue to coexist for now. Conventional Word/PDF product information remains part of the regulatory process, while ePI adds structured, reusable information. Track changes is also currently unavailable in the ePI editor. It therefore makes sense that teams do not simply abandon their existing document workflow.
A concrete variation without duplicated work
Suppose a variation changes section 4.4 of the SmPC and the corresponding passage in the package leaflet. A controlled pipeline could work as follows:
- The specialist updates the text in the controlled QRD DOCX.
- Reviewers assess the change in their existing Word process.
- After approval, the conversion recognises the official documents and sections.
- The text is linked to the correct FHIR profiles, section codes and language.
- A preflight checks the file before upload.
- A comparison shows what changed since the previous version and whether all text and structure were preserved.
- A readable Word document for quality control can be generated from the same structure.
The gain is not only time. More importantly, it creates one demonstrable transition between the approved text and the digital publication.
Why an ordinary document converter is not enough
A generic converter can extract text from DOCX. For medicinal product information, that is only the beginning.
Our ePI bridge is therefore designed to:
- recognise QRD and ePI sections by meaning, not just font size;
- record document type, language and official section codes correctly;
- convert lists, tables, links, footnotes and inline formatting in a controlled manner;
- validate against the current FHIR and ePI profiles;
- visibly preserve unknown sections instead of silently removing them;
- provide a reviewable difference report for both text and structure;
- operate reproducibly across products, variations and language versions.
This is why “it produces XML” is not an acceptance criterion. The relevant question is whether Regulatory Operations and Quality can demonstrate that the right content was transferred into the right structure without unexpected loss.
What we have built
Elk Solutions has built an open, self-hostable transformation core for this purpose. FHIR is authoritative, while DOCX remains the adapter for authoring, review and quality control. The core requires neither a Microsoft Office server nor a proprietary document runtime.
The working core:
- inspect an ePI FHIR Composition and its nested sections;
- create a DOCX with recognisable content controls for each section;
- inspect the section tags in such a DOCX;
- link known compatibility tags to official ePI codes;
- preserve unknown FHIR sections;
- test the pipeline with public EMA examples.
The technical core of the bridge is therefore in place. We are now extending it with DOCX to FHIR, normative preflight and a complete round-trip difference report. These are targeted extensions to a proven architecture, not a new technical gamble.
Who already faces this problem
This solution is directly relevant to:
- ePI and Regulatory Operations teams at marketing authorisation holders;
- medical writers and product-information or labelling specialists;
- service providers supporting several medicinal product portfolios;
- RIM and integration teams fitting FHIR into existing processes;
- quality staff who must demonstrate equivalence between versions.
European implementation is phased, and language versions are currently imported one at a time. This is therefore not a one-off conversion job, but reusable infrastructure for a portfolio of variations, documents and languages.
Sources and current status
- EMA ePI Frequently Asked Questions
- EMRN ePI Implementation Guide
- EMA ePI user guide for applicants
- EMA: draft ePI implementation roadmap
The cited EMA FAQ was updated on 8 April 2026. The roadmap and functionality continue to evolve; always consult the latest official guidance before making an implementation decision.