What Veeva Vault PromoMats needs from a website screenshot package

Ask three people what PromoMats requires from a website screenshot package and you will get three answers, because there is no single Veeva specification. Veeva Vault is a document system; it will take almost any file and render it for review. The actual requirements come from three places: how Vault handles what you upload, what your MLR reviewers need to see to approve a site, and what the FDA will eventually need when the sponsor submits the site on Form FDA 2253.

This guide takes each in turn, quotes the sources, and ends with a checklist for a package that satisfies all three. It is written by RouteShot, which produces this kind of package, and the last section covers the two common ways to build one. It is not regulatory advice. Your client’s Vault configuration and regulatory team decide the details, and, as Veeva’s own agency guide puts it, “Field names and usage may vary between Clients.”

What Vault does with what you upload

Vault creates a viewable copy of the source file each time a new version is uploaded. Reviewers work on that rendition, not on your original: they add note annotations, and they add link annotations that tie a claim on the page to an anchor in a reference document. When you upload a new version, annotations from the previous version can be brought forward, and they re-link automatically unless the content they point at has changed, in which case someone re-links them by hand.

If the client has configured Veeva Web2PDF, there is a second path. The document type carries a Staging URL field, optional credential fields for protected sites, and optional Device and Orientation picklists offering desktop, smartphone and tablet in portrait or landscape. A user action on the document sends the crawl to Web2PDF, the PDF arrives by email, and it is uploaded as the viewable rendition.

Three consequences follow for the package:

• It ends up as a PDF. Whether Vault renders your upload or Web2PDF produces it, what reviewers annotate is a PDF rendition. A package of loose PNGs works, but a compiled PDF with one capture per page is what reviewers expect and what a submission needs.
• Page order must be stable between versions. Brought-forward annotations land by position. If page 7 was the dosing page last round and is the safety page this round, every annotation on it is now wrong. Fix the order, in navigation or sitemap order, and keep it.
• Naming has to survive a client’s metadata. Document names, material IDs and version labels are client-configured. Put the site, the date, the width and the state in the capture filenames so the package is self-describing whatever the Vault fields are called.

What reviewers need to see

MLR reviewers are approving the site a visitor will experience, not a rendering of its HTML. The set they need has grown over the years as sites have become more dynamic, and it is now fairly standard across sponsors:

• Every page, including legal, privacy and the pages nobody visits. A page that was left out is a page that was not reviewed.
• Two widths. Desktop and mobile, because the layout, the ISI presentation and sometimes the content differ.
• Above-the-fold and full-page. The first is what a visitor sees on arrival; the second is the whole page with nothing hidden.
• ISI states. The tray as it appears on load, the full-page shot with the tray hidden and the in-flow ISI complete, the expanded state, and the collapsed state if the tray loads open. Our guide on capturing a sticky ISI covers why each exists.
• Consent states. The cookie banner and its settings panel, before dismissal, because they are promotional-page content a visitor sees.
• Interactive states. Accordions open, modals and inline panels shown, carousels stepped, navigation menus open, forms in their empty and validation-error states. The FDA is explicit that static images “may not adequately convey how complex interactive promotional materials convey promotional messages,” and reviewers take the same view.
• The date, the source URL and the environment. Staging or live, captured when, by whom. This is what a reviewer needs when a later version is compared with an earlier one.

What the FDA will eventually need

The sponsor submits the site to the Office of Prescription Drug Promotion on Form FDA 2253 at the time of first use. The agency does not file it, but the package the agency builds is what goes in. The relevant guidance is Providing Regulatory Submissions in Electronic and Non-Electronic Format: Promotional Labeling and Advertising Materials for Human Prescription Drugs (FDA, April 2022), the Form FDA 2253 instructions, and the eCTD Technical Conformance Guide. What they say about websites:

• The whole site, at first use. “A firm must submit its entire product website at the time of first use. If the firm then updates one page or section of the website, the firm need only submit the updated page or section with a cross-reference to the original submission of the website noted on Form FDA 2253, including the date of the original submission. If the website is substantially revised, the firm must submit the revised website in its entirety.” Every capture set needs a date, and a page-level set makes the update submission possible.
• Professional and consumer sections apart. “Websites with distinct sections for health care professionals and consumers should be divided into two separate submissions.” A site with an HCP gate needs its captures grouped by audience.
• The reviewer should be able to use the site. “The submission should allow the FDA reviewer to click on links within the website and view videos or other animations as an end user will experience while using the site. If the firm is unable to provide active links within the electronic submission, the firm should provide electronic images of each web page in conjunction with videos.” And in a footnote: “Firms should not send links to websites, even if they are password-protected.”
• PDF in practice. The Technical Conformance Guide allows HTML, but “submission of HTML files that depend on JavaScript, PHP or server-side scripts that generate dynamic content should not be submitted,” and “an acceptable alternative for these types of HTML files is to utilize PDF.” Almost every modern pharma site depends on JavaScript, so the submitted website is, in practice, a PDF of page images plus video files for anything that moves.
• Clean, and optionally annotated. The postmarketing submission carries a clean version of the material in eCTD section 1.15.2.1.1. Annotated versions, cross-referencing claims to the label and references, are encouraged but not required for 2253 submissions.
• The right material type. The Form 2253 instructions list www-website for an Internet website and www-mobile for “smartphone or tablet app/widget, quick response (QR) codes, mobile websites,” alongside www-banner, www-video and others. A responsive site is usually one www-website item; a separate mobile site or app is its own line.
• Twelve pages for advisory review. If the sponsor requests voluntary advisory comment on core launch materials, a “professional and/or DTC product website” is limited to 12 printed, legible pages. That is a pre-dissemination ceiling on what OPDP will look at, not a limit on the site or on the eventual 2253 submission.

The package, as a checklist

Two ways to build it

Veeva Web2PDF, from inside Vault. It is free, it is already in the review flow if the client has configured it, and it crawls a site from its sitemap to a single PDF with device and orientation options. It has two costs. Dynamic content, including the ISI, renders correctly only when the site carries Veeva Hints markup, such as data-vv-isi="true" on the page and data-vv-action attributes on the elements to click, which is developer time on every site build. And crawls are limited: 25 pages per crawl for non-subscribers and 100 for Vault subscribers, at 2 and 20 crawls per hour, with a hard cap of 1,000 pages, so a larger site is split or trimmed at each milestone. The PDF arrives by email and is uploaded as the viewable rendition.

RouteShot. It captures the whole site from the sitemap or a URL list with nothing added to the page, at the organization’s standard desktop and mobile widths, above-the-fold and full-page, with the ISI, consent and interactive states as their own labelled artifacts. Staging credentials are saved once, encrypted and write-only. Failed pages retry on their own. Every job records who ran it, when, against which URLs, with a per-page outcome, which is the cross-reference the update submission needs. Output today is an organized ZIP; a compiled review PDF with a cover page and one labelled capture per page is the next release. RouteShot does not push into Vault; the package is uploaded like any other source file.

If the client’s Vault has Web2PDF wired in and the site already carries Hints, use it and stay inside the crawl limits. If the site has no Hints, the review needs the ISI and interactive states as separate artifacts, or the job repeats at every milestone across many pages, the package is the product RouteShot exists to make. Request access and we will run one of your sites so you can put the output in front of your regulatory lead.

Sources

• FDA, Providing Regulatory Submissions in Electronic and Non-Electronic Format: Promotional Labeling and Advertising Materials for Human Prescription Drugs, Guidance for Industry, April 2022. Sections on audience, websites and electronic interactive programs, and the submission examples.
• FDA, Instructions for completing Form FDA 2253, material type codes.
• FDA, eCTD Technical Conformance Guide, section 3.1.6 on advertisements and promotional labeling material.
• Veeva, About Veeva Web2PDF and Configuring Veeva Web2PDF User Actions, Vault Help.
• Veeva, Web2PDF Help and Web2PDF Hints.
• Veeva, Vault PromoMats Quick Reference Guide, Agency User.

Written by the RouteShot Editorial Team from primary sources, cited inline. How we write and review guides · Report an error