Registration dossier life cycle
and eCTD submissions to the SEC
An enterprise solution for pharmaceutical manufacturers and applicants: it takes a medicinal product from the first dossier through all procedures and sequences — CTD structure, documents, section history, validation against the criteria of the State Expert Centre (SEC) of the Ministry of Health of Ukraine, package assembly, an immutable archive of what was submitted.
- 1–5CTD modules under MoH order No. 1789
- 76SEC criteria for the assembled package
- 3Independent levels of control
Key functions
- Dossier register: owner, current procedure, registration validity dates
- SEC procedure as an entity: groups sequences, has a status and the MoH order that closes it
- CTD Modules 1–5 tree, with branches multiplied by composition and indications
- Section life cycle across sequences:
new/replace/deletewith history
- Documents: PDF/ODT upload, conversion with embedded fonts, versions, MD5 control
- Three-level validation: document → assembled package → independent cross-check
- Backbone XML and ZIP package assembly, file list for the cover letter, locking of what was submitted
- QES, antivirus scanning, correspondence with the SEC, applicant portal, audit logs
Key features
What sets the system apart
Nine principles at its core: a submission must be accepted the first time, and the dossier history must remain provable through every procedure.
Checked by the regulator's rules
The system includes a literal port of the SEC's official validation script. Not an implementation "inspired by the original": the logic is reproduced line by line and sealed with hash control, so the applicant knows the regulator's answer before submitting.
line-by-line port of the SEC check · hash control
A life cycle, not just package assembly
The system knows not only which documents exist now, but the history of every section across all sequences: what was submitted, replaced or removed. The SEC procedure is a separate entity that groups submissions and keeps the order that closes it.
procedure → sequence → section → document
Three independent levels of control
A document is checked on upload (fonts, text layer, bookmarks, PDF protection), the assembled sequence against SEC criteria, and the finished package by an independent cross-check: after export the dossier is verified by a separate immutable script built on a different technology, so an error in one implementation does not go unnoticed. A warning counts as a rejection.
document → package → independent cross-check
The system fixes, not just complains
File names are brought in line with the SEC rule automatically, ODT is converted to a compliant PDF with embedded fonts and bookmarks, and references to documents of the previous sequence are filled in automatically. Authors work in their usual editor.
ODT → PDF · file names · auto-references
What is submitted becomes immutable
Locking a submission is a legally significant boundary: the sequence is locked for editing, a baseline of checksums of all package files is written to the log, and attributes already submitted are frozen. Not even an administrator can change them retroactively.
lock → MD5 baseline → append-only
Data stays inside the perimeter
Capsule model: one system instance — one customer virtual machine, one submission country. Documents and the database stay inside; outbound requests go through the corporate proxy and an allowlist of hosts. The private QES key never reaches the server.
one country = one capsule
Requirements are changed by the administrator
Submission type profiles, QES rules, life cycle rules, the requirements matrix by legal basis of the application, the register of controlled documents — all of this is configuration, not code. When the SEC changes its requirements, the response takes hours, not a quarter waiting for a release.
profiles · rules · legal-basis matrix
No "starting from scratch"
Dossiers submitted earlier by any means are imported from eCTD ZIP archives together with their full sequence history. Import correctness has been verified by an "import → assemble → compare" cycle on reference submissions already accepted by the SEC.
eCTD ZIP → dossier with procedure history
Updates do not change what was submitted
Reference snapshots serve as a regression net: backbone XML and trees of all sequences, validator verdicts on real files, cross-validator verdicts on assembled and reference packages. Every code change is compared with them byte for byte.
golden backbone · byte-for-byte comparison
Competitive advantages
Compared with typical ways of preparing submissions
Criteria that decide whether a submission is accepted the first time and whether the dossier keeps its history through every procedure.
| Criterion | This system | Manual preparation + SEC script | Generic publisher | File share + Excel |
|---|---|---|---|---|
| Knowledge of SEC requirements and MoH order No. 1789 | Built into structure and checks | In the specialist's head | Generic ICH rules | None |
| When an error is found | On document upload | After assembly | At publishing | After SEC rejection |
| Section life cycle between submissions | Per SEC practice | Manually, in Excel | Per ICH practice | None |
| Procedure as an entity grouping submissions | With status and MoH order | Folder and correspondence | Partly | None |
| Response to changed regulatory requirements | Administrator configuration | Rewriting instructions | Request to the vendor | Nothing changes |
| Antivirus scan of the package (SEC requirement) | On upload and locking | Manually, no report | Not provided | None |
| Audit evidence | Immutable logs | No logs | Depends on the product | None |
| Data location | Customer's capsule | Company perimeter | Vendor's cloud | Company perimeter |
| Migration of existing dossiers | ZIP import with history | Not applicable | Paid service | Not applicable |
| Cost of ownership | No licence fees | "Free" + risk of rejection | Per-user licences | Zero |
The "generic publisher" column describes the typical picture for such solutions and is not a comparison with a specific product based on tests.
← All solutions · Questions and proposals — office [at] rdsoft.com.ua