It is the interface, content, links and behaviour a user can actually encounter—potentially after software updates, database changes or a redirect.
That distinction creates a specific compliance risk. Certification can be valid at the point of review and cease to describe the live asset later. The resulting variance is not merely technical: it can alter a claim, change the balance of information, or expose users to material the signatory never reviewed. Medical signatory review of digital health apps therefore depends on controlling both the certified content and the mechanisms that can change it.
The final-form dilemma: certifying dynamic digital interfaces
The ABPI requirement is clear: promotional material must not be issued until its final form has been certified. The difficult part is defining that form when the asset is a functioning application rather than a static document.
A review package may include a build of the app, screenshots, text strings and a description of user journeys. Each can be useful. None is sufficient if the released product behaves differently. A screen may load content from a remote database. A button may redirect to a new destination. A user may see different information depending on profile, location or an interaction earlier in the journey. The signatory’s task is not to certify an abstract concept of the app; it is to assess the promotional material that will be issued.
That assessment has a practical boundary. Medical signatories review promotional accuracy, scientific validity and compliance with the relevant code. They are not thereby made responsible for software coding defects or cybersecurity controls. Those risks require their own governance. The review process should nonetheless identify technical features that can alter certified content, because a change in behaviour may create a change in promotional meaning.
A defensible assessment starts by separating the asset into components:
1. Fixed content: text, images, claims, references and safety information embedded in a release.
2. Variable content: material populated from a database, user profile or other external source.
3. Navigation: buttons, links, redirects and pathways between screens.
4. Conditional behaviour: content shown only after a selection, threshold or other event.
5. Release controls: the process for changing, approving and deploying any of the above.
The distinction is material. A typographic correction may not affect a claim. A revised eligibility threshold, reordered risk statement or changed destination page may do so. The change-control process needs a threshold for renewed review, not a blanket assumption that every software update is either harmless or a complete recertification event.
A certificate applies to the material reviewed, not to every future state the software can produce.
For each release, the evidence should allow a reviewer to reconstruct what was certified. This includes the relevant version identifier, the screens and pathways reviewed, the content source for dynamic fields, and the approved destinations for links. Where a feature cannot be represented in a static capture, the review record should describe its behaviour and the conditions under which it appears.
Where SaMD oversight meets promotional compliance
Digital health products can sit across more than one regulatory framework. An app may have a medical function that brings it within Software as a Medical Device oversight under EU MDR or MHRA rules, while also containing promotional content governed by the ABPI Code or other self-regulatory requirements. These are related assessments, not interchangeable ones.
The medical review of software as a medical device considers the product’s intended purpose and applicable device requirements. Promotional review asks whether communications comply with the relevant code. A product’s classification does not, by itself, answer whether its screens or communications are promotional. Nor does a non-promotional label automatically remove content from review where the app includes promotional material.
The overlap becomes operationally significant when one change affects both function and communication. A modification to a clinical threshold may change how the software behaves and what the interface tells the user. A new feature may introduce a product claim, even if the original app was designed as a clinical tool. Conversely, a change to the wording of a promotional screen may not alter the device’s intended purpose but can still require signatory assessment.
A useful governance model maintains separate decisions while linking their records:
| Change type | Device assessment | Promotional assessment |
|---|---|---|
| Revised clinical function or intended purpose | Assess whether classification, performance or device documentation is affected | Assess whether claims, user-facing explanations or product references have changed |
| New or revised product claim | Assess whether the claim reflects the device’s intended purpose and evidence | Review for scientific validity, accuracy and code compliance |
| UI or navigation change | Assess whether the change affects safe and effective use | Assess whether content order, prominence or user journey changes the promotional impression |
| Database or content update | Assess whether the update affects device function or outputs | Determine whether the new content is promotional and whether certification remains applicable |
| Link or destination change | Assess whether the destination alters device-related information or functionality | Review the destination and the route by which users reach it |
The table is not a substitute for a classification assessment. It makes the central point explicit: one release can trigger two review streams, and clearance in one does not automatically satisfy the other.
For applications classified as Class IIa or higher under the relevant EU MDR framework, the device-control implications may be more extensive. That classification does not set the promotional status of every screen. Teams should avoid collapsing device classification, intended purpose and code classification into one decision. Each has a distinct threshold and a distinct record.
Clause 12, QR codes and the destination-page problem
The 2024 ABPI Code, implemented on 1 October 2024, permits prescribing information under Clause 12 to be supplied through QR codes on printed and certain digital promotional assets. This is a delivery mechanism, not a reduction in review scope. If the printed or digital asset directs users to prescribing information, the signatory needs to review both the code and the destination landing page.
The QR code itself carries little content. Its compliance significance lies in the path it creates. A code can resolve to a page that changes after certification, or to a redirect whose destination is controlled separately from the approved asset. The review record therefore needs to establish not only that the code was tested, but also which destination it reached and what information appeared there at the time of certification.
A controlled review should capture at least:
- the QR code as displayed in the final asset;
- the resolved URL and any redirect behaviour;
- the complete landing page, including prescribing information;
- the route back to the promotional asset, if present;
- the owner and change process for the destination page.
Where a page is responsive or displays different content across devices, the review should account for those material variations. A signatory should not be asked to infer that a mobile view is equivalent to a desktop capture when layout, visibility or navigation differs. Presentation can affect prominence and interpretation even when the underlying wording is unchanged.
The same logic applies to links embedded in an app. A destination that is compliant on the day of certification can become non-compliant after an update, a content-management change or a redirect. The code and the page form one user-facing route. Treating them as unrelated assets leaves a gap in the certification record.
Post-certification drift in agile CMS environments
A content management system can change a live asset without changing the application binary. Remote content, redirected URLs and dynamic interface components all create routes for post-certification drift. The compliance question is therefore not only whether the original build passed review. It is whether the live state remains within the certified boundary.
A workable control begins with an inventory of mutable elements. Each should have an owner, an approval route and a defined change threshold. That threshold determines whether a proposed change can proceed under an existing certification or needs fresh medical signatory review. The decision should be based on impact, not on whether developers classify the change as “minor.”
For example, an adjustment to spacing may leave meaning and prominence intact. Reordering a benefit and risk statement may alter the overall impression. Replacing a reference can affect the scientific basis of a claim. Updating a database field may change what a user sees without a new app release. The review process must identify these differences before deployment.
A controlled workflow can be expressed as a sequence:
1. Baseline the certified state. Record the version, content, user journeys, destinations and relevant configurations reviewed by the signatory.
2. Classify each change. Identify whether it affects claims, evidence, risk information, audience, navigation, clinical functionality or the destination of a link.
3. Apply the review threshold. Route changes with a potential effect on promotional meaning or compliance for medical signatory assessment before release.
4. Preserve traceability. Retain the change description, assessment, approval and deployed version so the live asset can be compared with the certified state.
5. Monitor the released experience. Confirm that the production app, remote content and linked pages continue to match the approved configuration.
This is not a demand for a signatory to approve code. It is a method for preventing technical change from bypassing the review of the material users actually receive. The allocation of responsibility should remain explicit: engineering manages implementation; medical and regulatory functions assess the relevant content and claims; governance ensures that approval precedes release where required.
The review record also needs to handle rollback. If a post-release issue is detected, teams should be able to identify the affected versions and restore a previously approved state or remove the disputed content. Without version-level traceability, mitigation depends on reconstructing events after the fact. That increases both response time and uncertainty about the scope of exposure.
Digital platforms, influencers and third-party content
Digital compliance does not end at the app boundary. Pharmaceutical companies may use social platforms, influencers or other third parties to communicate health content. The PMCPA’s updated social media and digital interaction guidance, published on 2 February 2026, establishes responsibilities for companies engaging third parties in this area. The practical implication is that delegation does not eliminate governance.
A company may not control every technical feature of a third-party platform. It can, however, define the content it commissions, the claims it authorises, the review route and the monitoring expected after publication. A post that links to an app or landing page can form part of the same user journey. If the app is certified but the surrounding communication overstates its role, the overall interaction may still create a compliance problem.
The review scope should reflect the actual communication pathway. That means considering the post, the profile or context in which it appears, any linked destination, and the subsequent app experience. A promotional claim cannot be assessed in isolation if the user is directed into a sequence of screens that qualifies, expands or contradicts it.
The ABPI Code also requires advance notification to the MHRA Advertising Standards and Outreach Unit and the PMCPA of the names and qualifications of nominated medical signatories under Clause 14.4. This is an administrative requirement with operational consequences: signatory appointments and changes need a defined process, not an informal handover. Certification authority is part of the control environment and should be traceable alongside the assets it covers.
Clause 28 provides a framework for internet and digital platform compliance. It does not remove the need to assess each asset against its function and content. Teams should map where the app, promotional material, linked pages and third-party communications fall within the relevant requirements, then document the decision for each component.
A review model built around change, not screenshots
A static pack remains useful evidence. It is not a complete control for a product whose content can move independently of its release cycle. The central compliance task is to connect certification to the live system through versioning, change thresholds and traceable ownership.
For medical affairs and regulatory teams, the resulting model has three tests:
- Content test: Does the signatory’s record identify the claims, evidence, prescribing information and user-facing content actually reviewed?
- State test: Can the organisation identify the version, configuration, journey and destinations that were live at release?
- Change test: Does every material change pass through a documented assessment before it reaches users?
A negative answer to any one of these tests creates variance between the certified asset and the issued asset. The variance may be narrow or consequential; its existence is the control failure. Effective mitigation does not require the signatory to inspect every line of code. It requires the organisation to prevent unreviewed changes from altering promotional material, and to preserve evidence that the live product remains within the approved scope.
Medical signatory review of digital health apps is therefore not a one-time approval event. It is a release control connected to a changing product. Where dynamic content, QR destinations and third-party communications are left outside that control, the certificate may remain on file while the certified state no longer exists.