The Bottleneck in Agentic Engineering Was Never the AI
September 3, 2026
Some markets have five patients on a launched therapy. Five. The therapy is approved, a support program would visibly improve adherence, and the business case for building one never closes. Zelthy is an AI-native, open-core platform for life sciences, trusted by companies like BMS, Novartis, and AstraZeneca; patient support program (PSP) deployments on Zelthy span 80+ countries and programs managing over 1M patients, with a pre-built PSP template that turns each new market into configuration rather than a new build. This post lays out the model we build for exactly that situation: a global PSP template engineered once, deployed per market with local nuance. It is written for global patient services and launch leads planning rollouts outside the US.
The short answer: a global PSP platform engineers hosting, the core template, SSO, e-signature, and analytics once, then launches each country as an isolated, configured application. First market live in twelve weeks, each subsequent market in three to four, running in parallel streams, with cost that scales by patient volume, not by build.
Why patient support stops at the small-market border
Most conversations about patient support programs assume a patient population large enough to justify the machinery: a call center, trained nurses, a patient app, enrollment operations, adverse event handling. In the US that assumption mostly holds. Outside the US it breaks constantly, and it breaks hardest in rare disease.
The EU defines a rare disease as one affecting fewer than 1 in 2,000 people (EURORDIS). Spread a rare disease therapy across its international launch footprint and the per-country patient counts get small fast. A hundred patients in one country, thirty in another, five in a third.
We have seen this exact problem for years, in Southeast Asia and in markets like New Zealand. The program fees don't shrink with the patient count. A company gets quoted the same market setup cost whether it has five patients or five hundred, and the finance team does what finance teams do: runs the business case, and says no.
Below roughly 100 to 150 patients, the standard PSP model doesn't kick in at all. What exists instead is a lighter setup, usually outsourced to a vendor and paid as opex rather than capex, and below a few dozen patients even that collapses. Three things decide it: the patient count, the drug's price in that market, and how the company gets compensated there. When none of those line up, the market gets no program.
Today those patients mostly reach therapy through clinical trials, expanded access, or compassionate use routes (FDA overview). Those pathways get the drug to the patient. They don't provide adherence support, nurse education, or anyone noticing when a patient silently drops off therapy. For a portfolio launching across a dozen or more countries, the common starting position is patient support live in none of them.
The per-country business case is the wrong unit of analysis
Everybody assumes small markets mean smaller challenges. Wrong, and the error costs launches. The regulatory burden doesn't shrink with the patient count. The enrollment documentation you need in a small market can exceed what a large market requires. Consent rules, adverse event reporting windows, data residency: all of it applies to a five-patient program exactly as it applies to a five-thousand-patient program.
What changes in a small market is the budget available to deal with all that. Which is why the unit of analysis has to move from the country to the portfolio. Priced per country, a multi-market rollout produces a stack of bad business cases, one per market. Engineered as one platform with per-market configurations, the economics invert: the expensive work happens once, and each additional market pays only for what is local to it.
Every serious buyer eventually asks the sharp version of the question: if we put ten countries on one setup, does it cost the same as ten separate applications? Because if the cost curve is linear, the platform hits the same wall the bespoke builds did. Our answer is a commercial structure that matches the architecture: a one-time setup fee per market, then a license fee that scales with patient volume, in both directions. Volume drops, the annual cost drops. That last part matters more than it looks. It's what makes a five-patient country worth switching on at all.
What a global PSP template builds once
The architecture mimics the structure of the business itself. A global pharma organization shares infrastructure, standards, and governance centrally while every market operates with its own workflows and rules. The platform should look the same. That's the first-principles version of the whole proposal.
Concretely, the build-once layer has five levels. At the bottom, region-pinned hosting: an EU region for European markets under GDPR residency, a separate APAC region for markets like Korea, Japan, and Australia with their own privacy regimes, and where a market like China requires an in-country deployment, that runs as its own isolated instance. Above that sits Zango, the open-source framework Zelthy built for exactly this shape of problem. Django, which Zango extends, doesn't support multi-tenancy natively, so we adapted it: many isolated applications on shared infrastructure, with permissions, workflow, and append-only audit logging enforced at the framework level where local configuration can't weaken them.
The third level is the Zelthy PSP template, a working patient support program rather than a development toolkit: enrollment and e-consent, a Patient 360, case queues, a benefits engine, early access handling, adherence management, an HCP portal, adverse event capture. The fourth is where it becomes yours: the company's own PSP template, built by customizing ours to the program's requirements. Branding, benefit catalogue, workflow variants, role models, integration designs, all defined once as the master baseline. Company SSO and e-signature plug in here, once, and every market that follows reuses them unchanged.
Every market application is then instantiated from that baseline. A market launched in month 18 inherits every refinement made for all the markets before it.
What stays local: configuration, not code
Every platform architect who has run a shared monolith knows the fear: deploy something for one country, break something in another, because the markets share data and code paths.
The answer is isolation by architecture. Each market runs as a logically separate application: its own data models, its own user roles, its own access points. No two applications talk to each other unless a pipeline is explicitly built between them. A configuration change in Spain cannot regress Japan, because Spain and Japan share a template lineage, never a runtime.
So what differs per market? More than most global teams expect:
- Enrollment documents. Most Asian markets enroll on a prescription. Other markets want a signed HCP consent form, with rules about how recent it must be.
- Consent text and its lifecycle, versioned per market, with withdrawals and re-consents tracked.
- Approval workflows: who reviews an application, in what order, with which checks.
- Communication channels. WhatsApp in one market, WeChat in another, SMS or email where messengers aren't acceptable to regulators or patients.
- Data residency and retention rules, set by the geography.
- Adverse event reporting windows, configured to each market's pharmacovigilance clock.
- Local vendor integrations where a market's operations demand them.
Every item on that list operates as configuration in the market application layer. No software release, no regression testing across live markets, no engineer on the critical path. When a market needs something the template has never seen, that gets built as a versioned package, and the next market that needs it gets it for free.
How long does it take to launch a PSP in a new market?
The timeline a launch team demands is blunt: first country live in three months, every subsequent country in under a month, twenty countries in a year.
Our delivery plan runs in three overlapping steps. Step one builds the company's PSP template and takes the first market live, twelve weeks. Step two activates markets from that template: region provisioning, one isolated country application per market, local configuration, market UAT, training, go-live. Three to four weeks per market once the foundation exists, with three parallel launch streams so a delay in one market never stalls the others. Step three, the data warehouse and portfolio analytics, rolls out from the first go-live instead of waiting for full deployment.
Less of the time goes into engineering than anyone expects. It goes into agreement signing, then sitting with the global team, then the local market team. The recurring surprise is that clients often don't know what use cases their own markets need covered. That's where a delivery partner has to do more than take orders. We advise on what the right product is for the use case, and sometimes that means telling the client that what they asked for is a one-off that will hurt them in market five, and the right move is building the product properly and getting people to follow the process. That costs a week and saves the portfolio.
Two caveats on speed. A market that needs a new integration or a new benefit feature takes longer than one activated purely from existing capability. And the pace assumes what our fastest projects have always had: a client team that moves. Deployments on Zelthy have gone live globally within three months of kickoff, and every one of those had a client team that cleared decisions in days, never weeks.
Vendors, safety, and who owns the record
Three governance questions come up in every serious evaluation of this model, usually within hours of a technical team getting demo access.
Where do PSP vendors work? Inside the pharma company's environment. The reasoning is about data ownership, and we make the case to the pharma company rather than to the vendor: it is your patient data being worked on, and if it lives in the vendor's system, the vendor can hold you when you want to change vendors. On the platform, vendor staff log in through their own employer's identity provider, work their queues with SLA tracking, run guided calls, capture adverse events, and lose access automatically the day they leave their employer. Their telephony and ordering systems integrate where needed. The case file stays yours. Where several vendors serve one portfolio, the same logic extends to unifying multiple PSP vendors under one data layer.
Where does automation stop in safety workflows? An adverse event signal from any patient interaction can automatically populate a structured intake draft. It advances no further without a human. That line is deliberate. The EU AI Act, among other regimes, constrains what an autonomous system may decide in this territory, and safety cases are where you want a person accountable before a case moves. The same principle runs through the platform's AI features for patient support programs: enrollment document checks, call transcription and summarization, adherence risk flags, all of them draft and recommend, with human confirmation required wherever an output touches a patient-facing decision.
Who is the system of record? You can't be rigid about this on a platform that has to coexist with enterprise CRMs and existing patient services systems. Some data objects live natively on the platform and sync outward. Others are owned by an existing system with the platform as a downstream consumer. Both directions run over REST APIs, webhooks, and event subscriptions, with audit trails logged regardless of where an object is owned. Things get messy in one specific case: when an incumbent enterprise system won't cooperate with its own customer. That, more than any feature gap, is why companies increasingly want a partner that will integrate with what exists, or replace it if asked, and hand over the keys either way.
On analytics, one design choice does most of the governance work: every market application writes to one shared data model, so a portfolio view exists from the day each market goes live. The global team sees de-identified data across the whole estate, country teams see their own market and nothing else, safety and audit get the pharmacovigilance evidence they're scoped to, and vendor staff see only their assigned patients. Nobody builds custom reporting per market, and pharma personnel handle pseudonymous identifiers rather than patient-identifiable data.
What this model doesn't do
We ourselves believed something here that turned out wrong: that pharma companies would eventually deploy a single platform for their entire global operations, US included. The market has two models, and they aren't converging. In the US, an established hub-services ecosystem runs patient support, and a company-owned platform is the exception (see how pharma runs PSPs in the US and EU). Outside the US, in global launches across many small and mid-sized markets, the ownership model wins. That's where this architecture belongs. If someone tells you one platform will run Ohio and Osaka the same way, ask which hub vendor they've priced in Ohio.
The platform also doesn't replace the humans in the program. Nurses, coordinators, field counselors: the platform gives them queues, guided workflows, and context, and takes documentation load off them with transcription and summarization. The support itself remains human work.
And one open question we haven't settled, recorded here deliberately: the economics of AI agents at scale. What an agent costs in practice to analyze a case, build a report, answer a query across a multi-market portfolio, and how to price that predictably. We are learning it from live deployments. Anyone who claims they've solved AI agent unit economics in regulated patient programs is ahead of us, and we suspect ahead of themselves.
Evidence from the field
Three deployments shape our conviction here.
A top-10 global pharma runs PSP governance and monitoring on Zelthy across 80+ countries with more than 4,000 users, covering safety, compliance, country teams, vendors, audits, and leadership. It went live within three months of kickoff. That project taught us what "global foundation" has to mean in practice: 50+ country configurations on one platform, each country seeing its own data, the central team seeing everything.
An oncology PSP in Australia, deployed on the platform, improved therapy adherence by 45%, cut onboarding time by 60%, and reduced program costs by 30%, with 85% patient engagement. Small-to-mid market, full program. The economics worked because the build didn't start from zero.
And the one that taught us the most about local nuance: an injection-device support program in a Southeast Asian market, run by a regional healthcare services company on our platform. The program needed device returns, serial numbers tagged to patients, warranty windows, replacement workflows. Reverse logistics inside a PSP. No template anticipates that, because it was a new business process. We absorbed it by repurposing existing packages instead of custom-building from scratch, and that experience is much of why the package architecture exists in its current form. Templates cover the 80%. The packaging model is what keeps the other 20% from becoming a rebuild.
Frequently Asked Questions
What software do pharma companies use to run patient support programs outside the US?
Mostly a mix: enterprise CRM platforms adapted to PSP work, vendor-owned systems run by local PSP providers, and increasingly purpose-built platforms like Zelthy, where a pre-built PSP template is configured per market. The ex-US pattern differs from the US, where hub-services vendors dominate program operations.
How long does it take to launch a PSP in a new country?
On Zelthy, once a company's global template exists, activating a new market is a configuration exercise: language, consent, service catalogue, workflows, roles, integrations, then market UAT and training. The plan we currently propose runs three to four weeks per market, with the first market, including the foundational build, at twelve weeks.
Does a PSP make sense for a market with only a handful of patients?
Under per-country build economics, usually no, and that is exactly why many small markets have no program today. On a shared platform the marginal market carries only its own configuration and a license that scales with patient volume, which changes the answer for markets with even five or ten patients.
Can local PSP vendors work inside the pharma company's platform instead of their own?
Yes, and they should. Vendor staff authenticate through their own employer's identity provider, work assigned queues, and see assigned patients only. The pharma company keeps the data and can change vendors without a migration project. Vendor-side telephony or ordering systems integrate via APIs where required.
How is patient data kept separate between countries on one platform?
Each market runs as a logically isolated application with its own data models, roles, and retention rules, enforced below the application layer. Hosting is region-pinned for residency. Cross-market analytics run on de-identified data over a shared model, with each audience scoped to exactly the portion they govern.
Who owns the application when it's built on a vendor's platform?
On Zelthy, the framework core is open source, the commercial template layers are licensed with source access, and the application layer, meaning configurations, workflows, custom modules, integrations, and data, belongs to the client outright, exportable at any time and self-hostable in the client's own cloud.
Ask your team one question first
Launching patient support across many markets comes down to one decision made early: which layer of the program is global, which is local, and an architecture that enforces the split. If you're planning an ex-US rollout, ask your team one question first: how quickly could we launch our next market today? Then ask your vendor how open they are to absorbing local nuance, integrating your local partners, and giving your country teams their own data. If either answer is unsatisfying, ask us for a working demo environment configured to your portfolio. We'd rather show you software than slides.
