eCTD Viewer Software: Review, History, and Export

Assyro publishes this guide and is our first editorial recommendation to evaluate. That placement is not an independent test result. We reviewed official product descriptions and documentation on September 14, 2026; we did not operate the products or run a comparative benchmark. Exact software releases, commercial entitlements, and compatibility with your dossiers still need confirmation.

This guide is for a regulatory reviewer, publishing QC lead, or sponsor receiving an eCTD dossier from a partner. The immediate task is to inspect what is present, understand its history, and communicate findings without taking over submission production. Existing DnXT Reviewer users can also use the replacement section to identify which records and permissions must survive a change.

Download the viewer evaluation pack with a historical/current-view map and portable finding fields. It turns VIEW-A and F-01 from the worked example into editable records for an ordinary reviewer and a receiving publisher.

Download the editable evaluation pack (ZIP: CSV worksheets, diagram and instructions)

Shortlist by the review task

This is a selective shortlist of review workflows, not a complete market ranking. A platform may contain viewing, validation, and publishing, but that does not mean every reviewer license includes all three. Missing public documentation means a capability needs proof; it does not establish that the vendor lacks it.

If the scope includes package creation, compare eCTD submission software in addition to the viewing workflow.

Write the review requirement before choosing a viewer

“Open our eCTD” is too loose for a purchasing specification. It leaves unresolved which submission history, which documents, and which user role the demonstration must cover.

Write something closer to: “An external CMC reviewer must inspect the supplied application through the agreed sequence, open a referenced historical document, leave a finding against its exact version, and deliver a usable comment record without publishing privileges.” Then list the authority, application identifier, eCTD version, regional specification, included sequences, and any deliberately excluded content.

Make the functions explicit:

• Viewing provides navigation and access to the content selected for review.
• Technical validation checks the package against a defined rule set and produces findings. Opening the package is not a validation result.
• Publishing creates or updates a submission output. A reviewer should not need publishing authority merely to comment.
• RIM may supply application, activity, and registration context. A document viewer does not by itself establish a complete regulatory information record.

These are procurement boundaries. A vendor can combine them, but the proposal should identify which component performs each operation and who is responsible for it.

Also distinguish “all content available to this user” from “all content in the application.” A permission filter, an incomplete import, or an agreed due-diligence subset can all produce a smaller tree. The reviewer needs to know which situation applies before interpreting an absent document.

Require an explicit format and history statement

Ask for the supported eCTD version and regional configuration for the exact viewing operation. A platform announcement about eCTD v4.0 publishing does not establish v3.2.2 historical import. Likewise, a successful US example does not prove the regional structures needed for another market.

FDA maintains separate submission-standard references; its current v3.2.2 table links the ICH Modules 2–5 backbone specification and lists regional material separately. That makes an exact standards inventory a better starting point than a generic “eCTD compatible” label. FDA eCTD v3.2.2 and Regional M1 standards

For the comparison, record which sequences were supplied and successfully made available. “Current” should always be interpretable against that scope. Do not accept an unlabeled current view of an unknown subset as proof of a complete application review.

What each candidate brings to the evaluation

Assyro: evaluate the package-review and findings handoff

Assyro's viewer page presents a submission-oriented review offering with module structure, document previews, and review findings. It is a useful starting point when your team wants to inspect a package and connect observations to the work needed before a handoff. Assyro eCTD viewer

Keep that evaluation bounded. Assyro's confirmed scope does not support selecting it for an inherited v3.2.2 application, and a broad viewer description does not resolve that limitation. Historical import, full cross-sequence navigation, annotation export, and external reviewer permissions must each be demonstrated for the proposed workflow. Do not translate a general FDA product statement into support for every FDA application history.

Bring a permitted package in the supported format and a finding that a second person must resolve. Ask the reviewer to identify the document and its location, record the observation, then have the intended recipient retrieve that exact context. The recipient should not have to ask which of several identically titled files was reviewed.

The proposed output is an inspectable review record and a clear handoff to the responsible team. Confirm how that record is exported or retained, which roles can change it, and whether the original reviewed artifact remains available after correction. These are acceptance questions, not claims that every mechanism is already included.

If your mandatory task is legacy dossier review today, evaluate a candidate that can demonstrate that input directly. Assyro can still be considered for a separate supported preparation or review task, with the relationship between systems documented. Do not make replacement of the historical viewer a condition of evaluating a narrower improvement.

DnXT Reviewer: inspect annotation context and role configuration

DnXT distinguishes Reviewer from Publisher in its getting-started documentation: Reviewer is for reading and annotating dossiers; Publisher builds new submissions. Its current Reviewer product page describes cumulative/current views, version comparison, and dossier-scoped access. DnXT Reviewer getting started, Reviewer product scope

The more useful procurement detail is in its annotation help. It documents notes with assignment and status, filters, and spreadsheet export of all or filtered annotations. The Links panel provides a related workflow for hyperlink-verification tasks. DnXT document viewing and annotations

That gives a team a concrete reason to evaluate DnXT when comments must move between sponsor and publisher. During the trial, export one unresolved comment against a historical version and one resolved comment against a newer version. Inspect the actual columns and the recipient's ability to find the intended document. The help page establishes that export exists; it does not prove that every field in your required handoff is included.

Permissions need equal attention. DnXT's administrator guide describes configurable Reviewer, Lead Reviewer, Admin, and Read-Only role patterns; its example gives annotation export to the Lead Reviewer. Confirm your configuration rather than assuming everyone who can comment can also export. DnXT team setup

Specify the exact authority, format, browser, and import scope in the demonstration. The current product page's lifecycle language is not a version-by-region compatibility matrix. Also test any document type that drives your buying decision; an advertised rendering feature is a vendor statement until your chosen file works in the offered environment.

Source: DnXT Reviewer getting-started documentation · View original image. The official vendor image shows Import Dossiers, despite its dashboard filename; application release is not displayed. These controls illustrate the entry point for the import exercise, not proof that a particular dossier or historical sequence is supported.

EXTEDOpulse Submission Viewing: distinguish archived and working content

The current product is named EXTEDOpulse Submission Viewing. Its public page describes browser-based viewing, collaborative markup without directly editing the original content, and comparison of lifecycle versions. EXTEDOpulse Submission Viewing

The linked product-information PDF supplies further detail: single-sequence, cumulative, and current views; annotation creation, filtering, and consolidation; and review of in-progress submissions compiled in eCTDmanager. It describes eCTD v3/v4 support, but a buyer still needs the exact regional configuration and release for the proposed import. EXTEDOpulse Submission Viewing product information

This is a relevant candidate when reviewers need access both during preparation and after a submission has been archived. The resulting evaluation risk is confusing those states. Ask the operator to show a working document and a historical submitted output with the same title, then explain how the reviewer identifies which one is open.

Leave a comment on the historical output and update the working document. Your acceptance question is whether the original finding remains understandable and whether a recipient can distinguish “addressed in a draft” from “verified in the output selected for review.” Do not assume those statuses are supplied automatically; demonstrate the actual configuration and process.

Confirm that the quote names Submission Viewing and its dependencies. EXTEDO also lists Submission Publishing, Submission Reviewing, and Submission Validation. Similar names do not establish identical functions, access rights, or licensing. For external participants, require a proposed access model and comment export that works with your own publisher or archive arrangement, including any steps outside EXTEDO.

Certara GlobalSubmit REVIEW: confirm the generation being offered

Certara's current GlobalSubmit REVIEW page describes a cloud-based review environment and lists supported application types, including IND, NDA, ANDA, BLA, MAA, and others. Its wider GlobalSubmit page describes navigation and annotation capabilities across the platform. Current GlobalSubmit REVIEW, GlobalSubmit platform

Be precise about the product generation. Public documentation for GlobalSubmit 22.9.1 describes a REVIEW installation with Windows/Acrobat prerequisites and files prepared through VALIDATE. Those historical instructions should not be treated as the requirements of the current cloud offer. GlobalSubmit 22.9.1 REVIEW prerequisites

This distinction matters when an organization inherits an old review environment or receives vendor instructions copied from an earlier deployment. Ask the sales or implementation team to identify the actual version, how incoming packages are processed, and what the reviewer needs on their workstation. Use documentation for that configuration in the acceptance record.

The decisive task is a reviewer joining an application they did not assemble. Have them locate a historical reference, inspect the applicable sequence scope, create a finding, and pass the finding to a publisher using only the proposed reviewer permissions. Then confirm how another person retrieves the history after the review is closed.

If your team already uses GlobalSubmit, evaluate the incremental review configuration before assuming a platform change is necessary. If you use another publisher, test the supplied output and workflow explicitly. Neither the current page nor the older compatibility statement proves that a specific incomplete, malformed, or unsupported package will display correctly in your proposed deployment.

A worked evaluation record: the PDF opens, but the history is missing

Use this fictional record to define expected outcomes before a vendor demonstration. It is a specification for a review exercise, not a downloadable eCTD package, executable fixture, or result from testing these products. Have your publishing team or vendor supply a permitted package that implements the agreed scenario and identify its exact standards before running it.

The lifecycle portion is deliberately limited to a Modules 2–5 replacement example under ICH eCTD v3.2.2. The specification's Appendix 6, Case 2, describes retaining the original file for history while the replacing file becomes current. Do not apply this example's leaf operations to eCTD v4.0. ICH eCTD v3.2.2, 16 July 2008, Appendix 6, Case 2

Agree what is in the review set

Assume the fictional application is VIEW-A and the complete exercise set contains sequences 0000 and 0001. These are invented identifiers, not recommendations for numbering a real submission. The publishing owner establishes the valid regional package outside this simplified record.

Portable viewer review record

The diagram is restricted to the article’s synthetic v3.2.2 Modules 2–5 replacement example. It is not a runnable dossier or a v4.0 lifecycle model. Enter observed results only after testing an authorized package in the quoted configuration.

The content, comment, and page number are synthetic. The two overviews should have deliberately different visible revision labels, so the reviewer can tell which was opened. Preserve the original files used in the demonstration; a screenshot of a tree is not enough to reproduce the retrieval question later.

Run the complete set first. Ask the reviewer to select the current view through sequence 0001 and then navigate to the original overview in the history. Under the stated replacement example, OVERVIEW-B should be current and OVERVIEW-A historical. Next, follow the supplied reference from the revised overview to REPORT-A and record which file opens.

Record the product version, regional configuration, imported sequences, user role, displayed view scope, and actual retrieved identities. This is how the exercise becomes evidence. A statement that “the current view looked correct” omits the facts needed to review the result independently.

Repeat with an intentionally incomplete set

Now provide a separate exercise copy containing only sequence 0001, with its dependencies on the earlier sequence deliberately unavailable. Tell the demonstrator this is an incomplete test input. Do not modify or remove files from a real retained archive.

The immediate symptom may be that the revised overview opens successfully while its reference to the earlier report fails. Trace the result before blaming the rendering engine:

1. Is the referenced file present in the supplied set?
2. Was the relevant earlier sequence successfully imported?
3. Can the current user access it?
4. Does the reference resolve to the intended identity rather than a similarly named substitute?

Those checks distinguish missing input, failed import, permission scope, and incorrect resolution. They do not assume that every failed reference has the same cause.

For this procurement exercise, the expected outcome is a visible unresolved dependency or a documented limitation, with no claim that the full application history has been reviewed. A viewer may allow partial inspection; your acceptance rule should require that its scope remains clear. Treat silently substituting a different report as failure. Treat refusing the incomplete import with an actionable explanation as an acceptable controlled outcome if it fits your operating requirements.

Keep comments attached to the reviewed evidence

Return to the complete set and create F-01. Then introduce a corrected working copy outside the historical reviewed output. The purpose is to test the review handoff, not to create another regulatory lifecycle operation.

Ask the intended recipient to open the exported finding without the demonstrator's help. They need the application, sequence, document identity, location, comment, owner, and disposition—or another documented combination that reliably resolves the same context. A comment saying only “check page 12” is insufficient when several documents contain twelve pages.

Have the reviewer reopen the original finding after the working copy changes. Its location should still identify what was actually reviewed. If the tool offers annotation migration, ask how it distinguishes a verified reattachment from an uncertain one. Do not count a moved annotation as correct merely because it is visible on the new document.

Exercise the external reviewer role

Use an account with the intended external permissions. It should perform the authorized review tasks while being unable to publish a sequence or alter original submitted content. Test a second, unrelated application as a negative access case. Confirm who may export findings and whether that permission is included in the proposed role.

Finally, end the temporary review assignment and verify the agreed retained-access arrangement. The organization should retain the necessary findings and dossier evidence, while the external participant's access follows the agreed policy. A file export, a read-only archive license, and continuing access to an active workspace are different arrangements with different costs.

DNXT Reviewer alternatives: preserve the review work

If you are replacing DnXT Reviewer, write the reason first: an unsupported required input, an access model that does not fit your collaborators, an export that omits needed context, or a decision to consolidate review into another environment. Confirm the problem in your configuration before treating it as a general product limitation.

DnXT's help documents annotation filtering and spreadsheet export, and its setup guide distinguishes review roles from administrative rights. Those are concrete capabilities to preserve if your team uses them. Annotation/export help, role configuration

Stay with DnXT Reviewer when it already meets the required input, history, access, and comment workflow and the replacement cannot demonstrate continuity. A slow review caused by an incomplete package should first be traced to the input or import process; buying another viewer does not necessarily supply the missing history.

Evaluate Assyro first for a narrower supported review task if that is the actual bottleneck. For a full replacement, its format and retained-history gates must pass before selection. Evaluate EXTEDOpulse Submission Viewing when collaboration around both in-progress and archived content is central. Evaluate current GlobalSubmit REVIEW when a dedicated cloud review deployment fits the team's operating model. These are evaluation routes, not verified DnXT migration paths.

Use a small preservation worksheet:

Export one active review and one closed review from your actual DnXT deployment. Inspect the output before agreeing to migration. A spreadsheet may preserve comment text while requiring additional mapping for document identity, location, or history. That is an implementation task to price and prove, not automatic migration compatibility.

In the destination, have a reviewer reconstruct both cases without opening the old interface. If that is impossible, decide explicitly whether a retained DnXT archive is acceptable, whether additional transformation or manual reconciliation is required, or whether the switch should wait. This review did not test an import path between any of the listed vendors.

Keep DNXT Publisher separate in the decision. Retiring Reviewer does not establish that another tool can produce the next sequence, and retaining Publisher does not prove that all review records will remain accessible after Reviewer access ends. Confirm product entitlements, repository access, and the final handoff in writing. If package production also needs to change, give it separate replacement criteria.

If Publisher also changes, use the DNXT replacement-scope guide to keep publishing and viewing requirements separate.

Make the quote match the evidence

Ask each candidate for the same scope: required formats and regional configurations; historical import; internal and external roles; annotation/export rights; storage; support; implementation; and retained access after the active review ends. Identify any validation or publishing component needed to prepare input for the viewer.

Compare the first year and ongoing operation separately. Historical loading, repository mapping, permission setup, reviewer training, and export reconciliation can be one-time work; licenses, storage, support, and archive access can continue. This guide does not establish comparable vendor prices, so it assigns no cost winner.

Mark each must-have demonstrated, failed, or unresolved, supported by the actual input and output. An unresolved mandatory format or historical-reference requirement prevents selection until resolved. Optional features should not compensate for inability to read the required record.

Bring the review specification to an Assyro viewer evaluation, subject to the format limits above, and apply the same evidence standard to alternatives. The useful outcome is a reviewer who can explain exactly what was inspected, which history was available, and how each finding reaches the person responsible for it.

Apply the eCTD portability checklist to the review output and historical material the buyer must retain.