Guide

QA for pharma approved email: the build against the approved rendition

A pharma email is not approved as copy. It is approved as a picture of itself. The medical, legal and regulatory review signs off a rendition: the designed email, exported to PDF by the regulatory system, with the functional spec written on top of it. The HTML that goes out to healthcare professionals or patients has to match that PDF element by element, and the agency has to be able to show that it did.

This guide is for agency teams building rep-triggered or mass approved email: what the rendition carries, where builds drift from it, what QA checks, and the record that follows.

What “approved” means in pharma

In most marketing email, “approved” means a client replied to a proof. In pharma it means a document passed medical, legal and regulatory review (MLR) inside the regulatory system, for example Veeva Vault PromoMats, and that document has a number, a version and a signature page.

The document is the rendition. The designed email is exported to PDF: the desktop view on the first page, the mobile view after it, then the signature page. Above the design sits a metadata block:

• From and To. The sender name and the audience. A rep-triggered email often reads “Recipient is dynamic”.
• Subject line and pre-header options. Labeled SL1 and PH1, SL2 and PH2, laid out side by side. They are alternatives: a send carries one approved option, not all of them.

Around the design, the reviewer adds callouts. These notes are the functional spec, and they were reviewed as carefully as the copy:

Everything in that PDF was reviewed. Nothing outside it was.

Why the build is checked against the rendition, not a Word deck

Many agencies keep a working copy deck in Word. It is what the team edited on the way to review, not what was approved. The last review changes often land in the rendition and nowhere else: a word in the safety information, a reference number, a new landing page. Check the build against the Word file and you have confirmed it matches a draft. The only reference that holds up is the rendition, at the signed-off version.

Where builds drift from the approved rendition

The build is HTML assembled by a person from a design, often under deadline. The same differences come back campaign after campaign:

• A subject line that was not an approved option. It was reworded in the sending platform, carried over from an earlier version of the rendition, or paired with the wrong pre-header.
• A link that does not match its callout. The callout names one URL; the build points to the previous landing page, a staging host, the home page instead of the deep link, or an older prescribing information PDF.
• Alt text typed differently. The ALT TEXT callout is approved copy. The developer shortens it, paraphrases it, or reuses last email’s.
• Safety information cut or reordered. The safety block is long and easy to break: a paragraph lost across table rows, two bullets swapped, a “continued below” with nothing below it, or the block set as an image.
• Footer lines changed. The approval code and date, the unsubscribe line and the postal address sit where nobody reads, so a placeholder code survives to the send.
• References and superscripts dropped. A citation mark lost in a paste, a reference list that no longer runs in order, a registered sign missing from one mention of the product name.
• A mobile view with a difference. The mobile page usually repeats the desktop copy. Sometimes a line is shortened or a module dropped, and the build has to carry that difference exactly where the rendition does.

What a QA pass covers, element by element

Walk the rendition from top to bottom. Every element in the PDF needs a match in the HTML, and every element in the HTML needs a source in the PDF.

1. Subject line and pre-header. The subject is one of the approved options, word for word, including punctuation and any trademark sign. The pre-header is the option approved with it, and it is in the HTML, not only in a platform setting.
2. Headline and body. Each section against the rendition, in order, including words set on the hero image.
3. Links. Each “Upon click” callout against the href on the element it points to: the exact URL and the text or image the callout sits beside. A phone callout means a tel: link on the number the copy shows; an email callout means a mailto: link.
4. Alt text. Each ALT TEXT callout against the alt attribute of its image, word for word. The email accessibility checklist covers what else images need.
5. Indication and safety information. Live text, complete and in the rendition’s order, with the boxed warning first where there is one.
6. References and footnotes. Every citation mark has its reference, the list runs in order, and superscripts sit where the rendition put them.
7. Footer. The approval code and date match the approved document, not a placeholder. The address and the unsubscribe line are present.
8. Mobile. Note what the mobile page changes from the desktop page, then check the build at mobile width for exactly those changes.

Log each difference against the rendition element it breaks, quoting both sides in full. That is a one-minute fix; “alt text wrong” costs a round. The copy deck comparison guide covers comparing copy line by line without drowning in whitespace and entity noise.

The audit trail a client or regulator expects

Pharma email is looked at again after it is sent, by the client’s compliance team or in an audit. The questions do not change:

• Which rendition? The document number and version the build was checked against.
• Which build? The exact HTML that was checked, not “the email in the platform”, which may have changed since.
• Who approved it, and when? A named person, a timestamp, and whether a second person signed.
• What was found and what was waived? Each difference, how it was resolved, and the reason for any waiver.

The weak link is the second question. A screenshot cannot prove which HTML went out. A SHA-256 hash of the approved HTML can: change one character and the hash changes. Recorded at sign-off, it lets anyone check a file later with tools that ship with the operating system. The guide to proving the sent email matches the approved one covers how to hash, what the hash covers and how to compare it with the copy that arrived.

How SendLint reads a rendition

SendLint takes the rendition PDF as the copy deck. When a PDF carries two or more reviewer callouts (“Upon click” or “ALT TEXT” notes), or a side-by-side subject line and pre-header block, it is read as a rendition instead of a table deck:

• Subject lines and pre-headers. The SL and PH options in the metadata block become alternatives. The subject check compares the email’s subject with the options, says which one the email uses, and names the closest one when neither matches.
• Body sections. The copy is cut into sections at the design’s own headings: lines set at least 1.2 times the body font size. The first heading is the headline, and a block above it that reads as an indication is labeled Indication.
• Footer and legal. The last section is split at the first legal line, such as a copyright line or “If you no longer wish…”.
• A link matrix. Each “Upon click” callout becomes a link, anchored to the nearest text line, or to the nearest ALT TEXT callout when the link is on an image. Phone and email callouts become tel: and mailto: links on the number or address in the copy.
• Alt text. Each ALT TEXT callout becomes the approved alt text for an image.
• The approval number. The document number on the signature page is kept with the deck, where the Approval Code check reads it.

From there it is the same analysis as any deck: Links vs Deck and Alt Tags Match Deck check the build against the callouts, and the Regulated Content checks cover safety information, boxed warning, indication, references and approval code.

What it does not read yet

• Only the desktop page. The mobile view is taken to repeat the desktop copy, so a mobile-only difference has to be checked by eye.
• A desktop view split across pages. When the regulatory system paginates the desktop design onto several pages, only one of them is read. It is tracked as a follow-up.
• From and To. The metadata block’s sender and audience lines are not compared with the email.
• Scans. The PDF has to be a text export. A scanned or flattened rendition has no text to read.

Sign-off and byte-level proof

A round can only be approved when it passes the client’s compliance policy: unresolved failures block, waivers are recorded, and an override needs a typed reason that stays on the record. Approval mints a certificate that freezes the SHA-256 of every approved email’s exact HTML, with the round, the language, the check counts, the waivers and who approved. With two-party approval it records who requested it and that a Reviewer granted it.

Anyone can check a file at sendlint.com/verify by certificate id, SHA-256 or the .html file itself; hashing runs in the browser. A newer approval supersedes the old certificate, which names its successor. The compliance PDF carries the hash list and the verify URL.

That answers the four questions in one place. To see rounds, the variance log and a certificate on a full campaign, open the free demo. Its sample is a retail campaign, not a rendition, but the round workflow is the same.