Assembling a sequence and finalising its documents happen at the same time. A publisher places a draft clinical overview into 2.5 so the structure and links can be built while the author finishes it. A late annex is dropped into 3.2.R while it is still in review. That overlap is how deadlines are met, and a publishing system should allow it.

The risk is at the end. If nothing connects the document’s approval state to the publishing step, a draft can go out in a filed sequence — and once a sequence is filed, it cannot be taken back. The fix becomes a new sequence, an explanation, and a lifecycle entry that will sit in the application’s history for good.

Warn on placement, block on publishing

The design question is where to put the gate. Block too early, and publishers cannot assemble with drafts at all, which slows every submission. Block too late — or not at all — and the check depends on someone remembering to look.

DnXT’s answer is simple: warn on placement, block on publishing.

  • When a document from the eDMS is placed, its status is visible beside it. Drafts are allowed while the sequence is being assembled.
  • When the sequence moves into publishing, DnXT checks every live document from the eDMS. If any is not approved or effective, the move is refused, and the refusal names each document — its number, file, status and version.
  • The refusal is recorded in the audit trail as a blocked status change.

Which step counts as “publishing”?

There is a subtlety that a name-based check gets wrong. Every company configures its own submission workflow, and the state that actually triggers publication differs. In one workflow it is a state called Published. In another, the publish step is attached to In Validation, because the company publishes and validates together.

A gate that looks for a state named “Published” would let a draft through in the second workflow. So DnXT asks the workflow itself: does the state this sequence is about to enter fire the publish action? If it does, the gate applies — whatever the state is called.

Fail closed

The other design choice is what to do when the answer is uncertain. If the eDMS cannot confirm a document’s status, the gate names it as unconfirmed and refuses. If the sequence’s table of contents cannot be read, it refuses and asks the user to try again. It never assumes a document is approved because it could not find out.

Only documents that will actually ship are checked. Documents superseded within the sequence and deletion entries are skipped, and each document is checked once even if it appears in more than one place.

Why it belongs in the system

Most regulatory teams already have a rule that only approved documents are submitted. The rule is in an SOP, and it is followed by a person reading a list. That works until the day the list is long, the deadline is close and one annex was approved in the publisher’s mind but not in the system.

Putting the rule in the system changes what an inspector sees. Instead of “our SOP requires approved documents”, the evidence is that the system refuses to publish anything else — and records each time it did.

It also connects two records that are too often kept apart. The document management system knows what is approved; the publishing system knows what is in the sequence. A gate between them is a small piece of software that closes a large gap.

DnXT builds eCTD publishing, submission planning, document management and dossier review software for regulatory operations teams. Book a demo to see the approval gate stop a draft before a sequence is published.