Your SmPC stays in FHIR. Your authors stay in Word. epieditor moves the text between them, section by section, and reports what it changed and what it left alone.
1. Name of the medicinal product
ProductXDemoMed CompanyY 100 mg hard capsules
ProductX CompanyY 400 mg hard capsules
1 word removed · 1 word added · EU/1/26/DEMO/001 · SmPC · en
FHIR R5 · returned<section> <title value="1. NAME OF THE MEDICINAL PRODUCT"/> <code><coding><code value="200000029792"/></coding></code> <text><div xmlns="http://www.w3.org/1999/xhtml"> <p>DemoMed CompanyY 100 mg hard capsules</p> <p>ProductX CompanyY 400 mg hard capsules</p> </div></text> </section> 31 other sections byte-identical to source source sha256:c1ddad33…e55c6755 output sha256:1ec3d914…b6640a9c1 validator HL7 FHIR Validator 6.9.12 · 0 errors · 0 warnings
Drag the handle, or use the arrow keys.32 read · 1 changed · 31 preserved · 0 validator errorsA real run on EMA's public sample (MedicineX), 11 September 2026. Download the five files.
ePI is the structured form of the SmPC, the package leaflet and the labelling: FHIR R5, with the official QRD section codes. EMA lets marketing authorisation holders create that FHIR with their own tooling, but supplies no Word-to-FHIR plugin. Word and PDF remain part of eCTD and assessment.
According to EMA's ePI FAQ, the ePI editor in the PLM Portal has no tracked changes, and language versions are imported one at a time.
So text moves by hand between Word, the portal and a validator. Every copy and paste is a chance to lose formatting, or to change a word nobody meant to change. You find out at upload, or later.
Each QRD section becomes a heading in a fixed style. The original FHIR travels inside the DOCX, with its hash.
Tracked changes, comments, the section numbers your authors know by heart. Nothing new to learn.
Sections are matched on their official code, not their position. Narratives that demonstrably changed are written back; the rest is not touched.
A word-level comparison per section, then the HL7 FHIR Validator against the EMRN ePI profile, before you upload to the PLM Portal.
Whichever door your authors use, the return route is identical: only edited sections go back, compared with the approved source, checked by the official validator, written up in the evidence report.
For teams whose authors live in Word
The full review round with comments and tracked changes, in the tool your medical writers and regulatory authors already use. One edit gave 32 read, 1 changed, 31 preserved, 0 errors, 0 warnings. That is the run shown above, and you can download it.
For companies that want ePI editing inside their own tooling
Not every change needs a Word round. nodekind is our browser editor that reads the FHIR narrative schema and offers only what is allowed at that spot, so an invalid section cannot be produced by accident. It is built into the epieditor console, and it embeds in your RIM, portal or DMS with one message in and one message out.
load · getXml · validate · state · comments your application asks ready · xml · changed · findings the editor reports npm i nodekind · iframe or WebView2 · Apache-2.0 core
The shared working version between colleagues comes with a pilot. For a full review round with comments and tracked changes, Word stays the route. Try nodekind on its own with a package leaflet.
1. Name of the medicinal product
ProductX DemoMed CompanyY 100 mg hard capsules
ProductX CompanyY 400 mg hard capsules
Changed in the Word document. Patched back into this section only.
Preserved. The narrative is identical to the source, word for word, and was not touched.
One mark per section, in QRD order. The stripe is the section that changed. Choose any other section to see that it came back untouched.
| Claim | Tested property | Input and output |
|---|---|---|
| One edit, one section | An edit in section 1 changes the narrative of section 1 only; all other narratives are byte-identical to the source. | EMA's public sample (MedicineX), FHIR R5 → Word → FHIR R5, plus the evidence report. The files below. |
| Two edits, two sections | 32 read, 2 changed, 30 preserved, no validator errors or warnings. | Same sample, two sections edited in nodekind in one working version. |
| Reordered headings | Sections are matched on their official code, not their position in the document. | A Word document with headings moved; text lands in the right section. |
| Not claimed | That every Word edit survives. Tables, footnotes and images have limits; unsupported changes are reported, not silently dropped. | The pilot report lists them for your document. |
run c564a3af-8f05-4399-a03d-0f280e16b914 · 11 September 2026 dossier EU/1/26/DEMO/001 · SmPC · en source sha256:c1ddad33bf5157d9a27d26f3e1b800dfb225b041c163f5b8d520fd6ae55c6755 output sha256:1ec3d914fef49ebe8e731bd6d1cabf8594a5375d34e65f73d262ae7b6640a9c1 rule set EMRN ePI + QRD base set 1.0.0 (pinned) sections 32 read · 1 changed · 31 preserved · non-narrative content preserved validator HL7 FHIR Validator CLI 6.9.12 · EMRN ePI 1.0.0 · passed · 0 errors · 0 warnings
The demo edit was applied to the DOCX by the demo route itself, so that every run is reproducible. In a pilot your authors make the edits, in Word, with tracked changes.
The dossier EU/1/26/DEMO/001 and the product names are fictional; the text is EMA's sample. A green validator means the file conforms to the profile. It is not regulatory approval, and it does not replace your medical review.
Prices exclude VAT. No seats: the price does not grow with the number of authors or reviewers.
Managed: you get every dossier, source, run and evidence report as FHIR, DOCX and PDF. We delete the environment within 30 days.
Self-hosted: your installation keeps working. Updates for new profile and validator versions stop.
Every authorised SmPC is public on the EMA website, so there is nothing confidential to share. We run it through the round trip and return the Word document, the evidence report and the validator outcome. Free of charge.
Elk Solutions · Netherlands · elk.solutions