DSUR, PSUR and PBRER Writing Software: A Buyer Guide

Assyro publishes this guide and is our first option to evaluate for the eligible document-workflow use case. That ordering is an editorial preference, not an independent performance result. This is a documentary comparison of public product material checked October 6, 2026; we have not run these products against the exercise below.

The guide addresses aggregate reports for medicinal products. It does not evaluate medical-device PSUR software or recommend replacing a pharmacovigilance system with a writing assistant.

Shortlist by the work you need to change

These are selected options with a relevant public workflow, not an exhaustive market ranking. Their software editions, licensed functions and deployment arrangements need to be named in the proposal. A capability described online establishes a question worth testing; it does not establish your configured result.

Also inspect what your incumbent already provides. Veeva Vault Safety documentation describes aggregate-report templates, authoring and approval workflows. PVgenix describes case-based listings and tabulations. Neither source, by itself, proves that an additional narrative-writing purchase is necessary. Identify whether the bottleneck is assembling reliable data, drafting prose or coordinating approval before buying another application.

Define DSUR, PSUR and PBRER before comparing support

These labels cannot be treated as three interchangeable export buttons.

DSUR is the development safety update report addressed by ICH E2F. Its scope includes drugs under development and marketed drugs undergoing further study. “DSUR means preapproval only” is therefore an unsafe procurement shortcut. ICH E2F's current Step 4 text is dated August 17, 2010; FDA's final adoption guidance is dated August 2011. ICH E2F, FDA E2F guidance.

PBRER is the periodic benefit-risk evaluation report described in ICH E2C(R2), covering marketed products. Its framework includes evaluation of benefits and risks, rather than simply collecting adverse-event counts. The current ICH document incorporates the December 17, 2012 correction to the November 2012 Step 4 text. ICH E2C(R2).

PSUR remains the term used in the EU for periodic safety update reports with content based on the PBRER framework. EMA's final GVP Module VII, Revision 1, sets out that relationship. A vendor's separate “PSUR” and “PBRER” templates may represent different configured outlines; ask which authority, report specification and version each implements. EMA GVP Module VII, Revision 1.

Regional procedures still matter. FDA's November 2016 guidance describes conditions and procedures for using a PBRER in place of specified US periodic reports. Selecting “PBRER” in software does not make that substitution appropriate for every application. FDA postmarketing periodic-report guidance.

For procurement, record the report type, product and development status, applicable authority, reporting interval, data lock point and selected template revision. Have the responsible safety/regulatory owner establish these inputs. Do not let a vendor's default calendar determine your obligation. Our DSUR reporting guide and PSUR guide provide the broader reporting background.

Four options, with different evaluation tasks

1. Assyro: evaluate the document workflow around the report

Assyro is our starting recommendation when approved source documents, their versions and the review handoff are the immediate problem. Its public Document Management page describes version history, approval state and source links. Its Regulatory Writing page describes source-linked drafting and tracked revisions in submission work.

Those are adjacent capabilities. Dedicated aggregate safety-report generation is not confirmed, and this guide does not claim that Assyro calculates safety tabulations, interprets signals or produces a complete DSUR, PSUR or PBRER. A buyer whose mandatory requirement is a ready-to-use aggregate-report generator should keep that requirement unresolved for Assyro and evaluate the dedicated options below.

A useful scoped demonstration begins with one approved exposure document, a superseded version and a paragraph already written by your safety team. Ask how the chosen version remains identifiable through review, how a replacement source affects the working document, and what a successor reviewer can retrieve after export. Establish whether the exact document format and proposed operation are supported before widening the exercise.

This can be a narrower purchase than replacing your safety database. It also leaves a clear dependency: the safety team or its existing systems must supply qualified data and own the report's medical assessment. Include that retained work in the proposal. An attractive document workspace does not satisfy an unproven pharmacovigilance requirement.

2. AlphaLife AuroraPrime RMA: evaluate authoring across report types

AlphaLife's AuroraPrime RMA page explicitly names DSUR, PBRER and PSUR authoring. It describes bringing together evidence, preparing first drafts and supporting cross-functional review. That makes it a relevant candidate when a team wants to assess development and marketed-product report writing in the same authoring environment. These are the vendor's descriptions, not results from our testing. AuroraPrime RMA safety-report section.

The decisive comparison is between two separately scoped jobs. Bring one development-report source inventory and one marketed-product inventory. Require the supplier to identify the sources, report outline and unresolved inputs for each. A reusable writing environment is useful only if reuse preserves the differences between the reports.

Pay particular attention to the connection between source data and narrative revision. Suppose the exposure owner issues a corrected table after the first draft. Ask the operator to identify every affected number and passage, show the proposed changes and retain the review decision. Merely replacing a document in a folder is not evidence that its consequences were reviewed.

For implementation, establish who prepares the incoming files and which interfaces or mapping work are part of the quoted scope. Record the proposed product edition and configuration; the public page does not specify the buyer's installed build. Progress the candidate when it demonstrates the required report types and change handling on your representative inputs. Do not extrapolate one successful section into an entire approved safety report.

3. Asthra: distinguish available PSUR/PBRER from planned DSUR

Asthra describes PSUR/PBRER drafting from inputs such as prior reports, line listings, exposure data, literature material and signal-detection outputs. Its public workflow includes a reporting-period source set and review of the generated draft. This is a relevant authoring evaluation when approved input material already exists and the buying question is how to turn it into a reviewable marketed-product report. Asthra PSUR/PBRER workflow.

The availability distinction is consequential: its DSUR page explicitly says that DSUR drafting is not yet available and is on the near-term roadmap. The current FAQ makes the same separation. A DSUR-only purchase cannot treat that planned module as available because it shares an engine with PSUR drafting. Asthra DSUR availability, current FAQ.

For a PSUR/PBRER demonstration, inspect the evidence behind a generated sentence rather than accepting a citation icon as sufficient. Can the reviewer identify the source version, reporting interval and exact table row? When the exposure input is stale, does the draft expose that gap or produce a plausible-looking denominator? Retain the draft and its supporting evidence together so the finding remains inspectable outside the live session.

The handoff deserves its own acceptance check. Agree which editable document, comments and supporting records the buyer receives, then open those deliverables in the team's normal review environment. Include the effort required to prepare the source set and correct the output. Public workflow descriptions do not establish your first-cycle workload or a guaranteed reduction in review time.

4. Nirnāśā Aggregate Manager: evaluate the governed reporting cycle

Nirnāśā's Aggregate Manager page describes templates for PSUR, PBRER and DSUR, optional AI drafting at section level, manual writing, review stages and versioned DOCX/PDF exports. The combination makes it a different evaluation from buying only a prose generator: the reporting calendar, authorship and review process are part of the proposed workflow. Aggregate Manager product description.

The supplier also states that its products can operate individually or as connected modules. An aggregate-report buyer should therefore establish the data dependency in the proposed arrangement: existing external safety system, additional Nirnāśā modules, controlled imports or manual preparation. Do not assume that a demonstration using the vendor's own case data proves your external handoff. Nirnāśā module FAQ.

Ask for a report with one completed section, one edited section and one section waiting for an input. Inspect what each state means, who can change it and whether a later generation overwrites an author's accepted correction. Then inspect the final exported version and the retained review record. The result should make unfinished work visible to the next owner.

Treat scheduling as configuration that requires evidence. Have your regulatory owner supply a known report profile and expected dates, then reconcile the calendar output against that record. Publicly advertised cycles or default date offsets are not a universal rule for every product and jurisdiction. The buyer benefit depends on the configured calendar and source handoff matching the actual reporting process.

Keep data preparation, writing and safety assessment separate

An aggregate-report purchase can cross four jobs: selecting the relevant data, producing tables, drafting text and reviewing the medical interpretation. Assign each to a named system or responsible person.

For example, a writing application may accept a spreadsheet that the safety database already generated. In that arrangement, checking whether the draft repeats the spreadsheet accurately does not establish that the database selected the correct cases. Conversely, a correct case listing does not establish that a benefit-risk conclusion is supported.

Document the boundary explicitly: approved input → selection and reconciliation → working draft → medical review → accepted output. Keep a record of the transformations and decisions between those steps. The source-traceability evaluation guide develops the document-level checks in more detail.

A team retaining its PV platform might shortlist Assyro for a bounded document-control problem and Asthra for a current PSUR/PBRER drafting requirement. A team needing DSUR generation now has a different shortlist: AlphaLife and Nirnāśā publicly name that scope; Asthra's roadmap and Assyro's unconfirmed dedicated support do not satisfy it. A team struggling primarily with report scheduling may first assess its incumbent workflow before adding a writer. These are conditional purchasing paths, not product performance rankings.

Run a reporting-period and source-reconciliation exercise

The following small exercise is synthetic. Every identifier, count and date is invented. It is a buyer demonstration of data handling, not a complete report, a clinical analysis or an agency-prescribed test. No vendor has been run against it.

Use the exercise only after confirming the proposed product supports the intended operation. A document-workflow tool can be assessed on preserving supplied sources and reviewer findings without pretending it calculates a safety database's output.

Establish the source packet and selection rule

For fictional development program CEDAR, set the reporting interval to July 1, 2025 through June 30, 2026, inclusive, with a June 30 data lock point. These are supplied exercise settings, not dates inferred by the tool.

The case table is the entire case history supplied for this exercise. Count distinct case IDs first received within the interval. A follow-up row does not create a second case. This narrow training rule is not a substitute for the selection rules governing an actual report's listings and tabulations.

Provide these additional source records. Trial A and Trial B have disjoint participant populations by the exercise specification; the unit is cumulative participants exposed, not cases, treatment-days or patient-years.

Give the operator a deliberately faulty draft sentence: “The interval contained five new cases, 200 participants were exposed at June 30, and there were no new safety signals.” Require a discrepancy record before proposing a replacement.

Inspect the worked result

The expected interval count is three distinct cases: C01, C02 and C03. C00 belongs to earlier history. C01's follow-up must not be counted twice. C04 is outside the defined interval and should appear in a separate exception record for the safety owner to assess; this exercise does not decide whether later information belongs elsewhere in a real report.

The supplied history contains four distinct cases through data lock: C00–C03. That is a separate count from the interval count. Neither number is a count of affected participants or an adverse-event incidence rate.

The June 30 combined exposure total is unresolved. Adding 120 and 80 gives 200 mathematically, but combines different cutoffs. Missing Trial B exposure cannot be treated as zero, and the approved May document cannot silently become a June estimate. The absent signal log also cannot support “no new safety signals.”

A suitable intermediate passage would read: “The defined interval query identifies three distinct cases. The combined cumulative exposure total at June 30 remains unresolved because Trial B's supplied source ends May 31. Signal status requires the missing source and safety review.” Label it a working passage, not an approved report conclusion.

Now supply EXP-B-2: 85 cumulative participants exposed as of June 30, 2026, approved, superseding EXP-B-1 for this task. The corrected combined exposure is 120 + 85 = 205 participants. Retain the old result, the replacement source and the reason for revision. The signal conclusion remains unresolved. Do not calculate a rate by dividing three case IDs by 205 participants: the exercise provides no case-to-participant mapping or appropriate rate definition.

For the missing-data variant, withhold EXP-B-2 or label it draft rather than approved. The accepted combined total must remain unresolved under the exercise's approved-input rule. A newer timestamp is not approval. Also verify that RSI-3 does not automatically replace the baseline selected in the report plan. The responsible reviewer must decide any change and preserve the rationale.

Copy this evaluation worksheet into the procurement record

Complete one record per product and configuration. Record: vendor; product/edition/build; report type; authority; interval and data lock; template revision; supplied source versions; proposed integrations; operator; buyer witness; run date; output locations.

Use Pass, Fail, Unknown or Not applicable. Pass requires retained evidence against an agreed expected result. Unknown includes a skipped step or unavailable evidence. Not applicable requires an approved scope reason and identification of whoever still performs the excluded work. A required failure or unknown cannot be averaged away by good performance elsewhere.

Agree the responsibilities before the session. If your team supplies the counts, evaluate whether the writer preserves them and flags contradictory prose; do not credit it with independently performing the case query. If the proposed software performs that query, retain its selection evidence as well. Both arrangements can work, but they leave different work and risk with the buyer.

Compare the first reporting cycle with ongoing operation

Request comparable commercial scope rather than a generic seat price. Specify the number and types of reports, products, source systems, authors, external reviewers and expected revision cycles. Separate setup and template configuration from recurring licensing, usage, support and any medical-writing service. Comparable public package prices were not established for this assessment, so this guide does not rank vendors by cost.

For the first cycle, assign owners for the report inventory, source mapping, template approval, access configuration, qualification evidence, training and the accepted output. Keep your current reporting route available until the replacement's required tasks have passed. A deadline approaching does not turn an unverified integration into a completed handoff.

For later cycles, test whether the team can start the next period without overwriting the accepted prior report. Record how source corrections, template changes and software updates are assessed. Confirm what remains retrievable if a collaborator leaves or the contract ends: the report alone may not preserve the evidence needed to explain its content.

The useful commercial comparison is the work left after the demonstration. One proposal might require manual source preparation but produce an editable, traceable draft. Another might reduce assembly work while adding configuration and data-migration responsibilities. Estimate those tasks with your own workload; avoid assigning a financial benefit to an untested automation claim.

Bring a bounded task to the next conversation

Start an Assyro workflow discussion when the defined need concerns source documents and a supported preparation/review task. Bring the report type, current safety-system boundary and one permitted source-version example. Confirm the exact supported operation before treating it as part of your reporting process.

If dedicated DSUR or PSUR/PBRER generation is mandatory, use the shortlist and completed worksheet to evaluate that requirement explicitly. The buying decision should identify which product performs each task, which evidence demonstrates it and which safety decisions remain with qualified people.