Architecture, Governance & Scale. The complete framework for building, approving, deploying, and compounding modular content in pharmaceutical commercial operations — from component taxonomy to AI integration to multi-market governance.
MLR review is the most significant structural constraint on commercial content velocity — and the most misunderstood, because it is treated as a process problem when it is an architecture problem.
The process critique — MLR takes too long, reviewers are too cautious, revision cycles are too many — is often accurate but not the root cause. The unit of MLR review is wrong. Pharmaceutical organisations submit finished assets — eDetails, leave-behinds, email campaigns — containing 8–15 distinct claims each requiring individual validation, cross-claim interaction assessment, and market-specific compliance verification. At that complexity per review unit, a 6–14 week cycle is a rational response to the review burden — not a process inefficiency. Making the process faster without changing the architecture just increases reviewer error rate.
The modular architecture changes the review unit from a finished asset to a discrete component — a single claim or claim cluster, typically 250–800 words, with defined scope, evidence base, and approved uses. Review complexity falls by 70–85%; cycle time follows. Once approved, the component is a permanent commercial asset, deployable in any channel, market, or format for which it has approval, without re-review. Assembly into finished assets is a selection and sequencing activity — not a new production or review cycle.
A structured library of pre-approved, claim-specific content components from which compliant materials are assembled — four operative terms, each architecturally significant.
A complete BCB modular architecture contains 38–60 components organised into six functional categories, covering the full commercial and medical education requirement with no out-of-library gaps.
| Category | Component Types | Audience | Funnel Stage |
|---|---|---|---|
| 01 · Disease & Category | Epidemiology summary · Unmet need framing · Diagnostic criteria guide · Underdiagnosis data | HCP · Payer · Patient | Unaware → Aware |
| 02 · Mechanism & Science | Mechanism of action · Pharmacokinetics · Differentiation vs. comparator · Evidence hierarchy | HCP (Independent, Knowledge Seeker) | Aware → Interested |
| 03 · Efficacy & Evidence | Primary endpoint summary · Subgroup analysis · RWE · Long-term outcomes | HCP · Payer | Interested → Evaluating |
| 04 · Safety Profile | Safety summary · Adverse event data · Risk management · Monitoring requirements | HCP · Payer · Patient | Interested → Evaluating |
| 05 · Patient Selection & Access | Identification criteria · Dosing guide · Reimbursement status · Support programme | HCP · Patient · Transactional HCP | Evaluating → Prescribing |
| 06 · Value & Outcomes | Pharmacoeconomic model · Budget impact · QoL data · Payer value story | Payer · Formulary Committee · C-suite | Evaluating → Formulary approval |
Beyond the six core categories, a complete architecture includes three supporting functions: peer and advocacy components (KOL endorsements, congress abstracts, case report frameworks) serving the Advocate stage; patient-facing components (disease management guides, adherence support content) requiring separate DTC/DTP regulatory pathway planning by market; and formulary and institutional components (value dossiers, budget impact summaries) operating on a distinct governance track for the Institutional Gatekeeper audience.
Building a component library is an architectural design project that happens to produce content. The sequence matters — decisions made before the first component is written determine reusability, scalability, and MLR efficiency.
Map the complete claim universe — every approved claim, every supporting study, every market-specific regulatory constraint. This mapping is the single source of truth for the library, and identifies claim interdependencies that become the assembly rules governing how components can be combined.
Each component is specified before writing: claim scope, evidence base, audiences, funnel stages, channel formats, market applicability, required safety context, and expiry conditions. The specification is submitted to MLR before production — catching scope and compliance issues before cost is incurred.
Components are written to the approved specification and reviewed as standalone units by a smaller, more focused review group. Cycle time for component-level MLR is typically 2–3 weeks — the 4.5-week total includes both component and assembly-level review, vs. 11 weeks for full asset MLR.
Defines required components by asset type, optional components by audience or market, excluded components by regulatory constraint, mandatory safety pairs, and maximum claim density. Approved by MLR as a document — assets built to it require only a compliance check, not a new review cycle.
A modular architecture requires a governance model structurally different from asset-based governance — four domains require explicit design.
Reuse rate — the percentage of deployed content assembled from previously approved components — is the clearest economic expression of the modular architecture’s value.
An organisation at 12% reuse produces 88% of deployed content as a new production cycle every time, with full cost. At 68% reuse, it pays production cost for only 32% — a 65% reduction in the variable cost of commercial content on a growing deployment base.
Reuse does not improve linearly. In the first 6 months, reuse is typically 15–25% as the library and playbook are not yet fully embedded. Between months 6 and 18, reuse accelerates to 50–65% as the library reaches critical coverage. Beyond 18 months, mature deployments reach 65–80% — continuing to improve as the library is enriched with performance data and AI-optimised recommendations. At 68% reuse, deploying a new asset in a new market costs approximately 32% of what it costs at 12% reuse; across a 14-market franchise deploying 40–60 assets per year, the cumulative three-year cost differential is typically 3–5× the total cost of building the modular architecture.
A modular content architecture is the enabling infrastructure for three AI-driven commercial capabilities unavailable in an asset-based architecture.
A defined six-stage sequence. Parallel or skipped stages typically produce an unstructured component collection that does not achieve the MLR, reuse, or AI-readiness benefits of a properly sequenced deployment.
Audit all currently approved content — every approved claim, its evidence base, market-specific restrictions, and expiry conditions. Typically reveals significant duplication and gaps in claims required for competitive positioning.
Confirm the component library will be built to the BCB Brand Objective before building components — components without a Brand Objective anchor tend to produce an internally inconsistent, difficult-to-assemble library.
Write and submit specifications for all planned components. For a 45-component library, pre-approval typically identifies 8–12 components requiring scope revision — days at specification level vs. weeks at finished component level.
Build components in order of commercial deployment urgency — HCP detail and patient identification components first, formulary dossier and RWE components in later phases. First reuse benefits realised within 3–4 months.
The playbook is written and submitted to MLR as a governance document. Its approval enables assembly-level review rather than full asset review for materials built in strict accordance with its rules.
The approved library is loaded into DAM with full BCB tagging — audience, funnel stage, channel, market approval, claim type, expiry. This tagging schema is the interface to AI personalisation and NBA systems.