Pharma — Market access tool for a fertility treatment

Brief

A leading pharmaceutical group’s field team — the informatori scientifici del farmaco who work directly with clinicians, hospital pharmacists, and procurement decision-makers — needed a tool to support market access conversations around one of their fertility treatments for medically assisted procreation.

The brief was a web platform that could model the cost-benefit case for using the treatment: weighing the clinical and economic outcomes against the alternatives, and presenting the results in a form that is useful inside a medical meeting, not just legible to a data analyst. Users authenticate through the client’s corporate directory. The platform is live in the field.

The constraints

Two constraints shaped the architecture from the start.

The first was authentication. The client operates on Active Directory, and the platform needed to respect that — not introduce a parallel identity system, not require a separate set of credentials, and not create an authentication gap that IT security would flag. SSO via the corporate directory was the requirement, not a preference.

The second was the deployment platform. Vercel was chosen for its deployment model and developer experience. Vercel runs on a serverless execution model, which is well-suited to React frontends and API routes but carries a specific constraint: functions are stateless, instances spin up and down independently, and in-memory state does not persist between invocations. Session management, which relies on continuity, does not map cleanly onto this model.

Approach

The Active Directory integration was handled via OAuth 2.0 / OpenID Connect against the corporate Azure AD tenant. This is the path that works reliably in serverless environments — rather than maintaining an LDAP connection, authentication is delegated to the identity provider and the application receives and validates tokens. The user authenticates once against the client’s own directory; the application never touches credentials directly.

Session storage was the harder problem. The initial approach used Redis, the conventional choice for session state in Node.js applications. In a serverless context on Vercel, Redis behaved incorrectly — connections were not reliably available across function invocations, and session state was inconsistent in ways that were difficult to reproduce and debug deterministically.

We moved session storage to PostgreSQL. Sessions are written as rows with a creation timestamp and an explicit expiry field. A cleanup routine handles expired records. The result is slower than an in-memory cache — it is a database write — but it is consistent, queryable, and behaves identically regardless of which serverless instance handles a given request. In a field tool used by representatives in medical meetings, a session that drops unpredictably is not acceptable. Consistency was worth the trade-off.

The cost-benefit model at the core of the platform handles the clinical and economic parameters relevant to medically assisted procreation: treatment cycles, success rates, and the downstream costs that follow. The output is designed to support a conversation, not replace one — the representative uses it to frame the clinical-economic case; the clinician or payer reads it in the context of their own institution.

What we delivered

• A Node.js and React platform for market access presentations, deployed on Vercel
• Active Directory authentication via Azure AD OAuth 2.0 / OpenID Connect — single sign-on with no separate credentials
• PostgreSQL-based session management with explicit expiry, replacing a Redis implementation that behaved inconsistently in the serverless environment
• A cost-benefit modelling interface for a fertility treatment, usable in the field during clinical meetings

Outcome

The platform has been in production since 2023 and is actively used by the field team. The session reliability issue was resolved before go-live; it has not recurred. Active Directory authentication has operated without incident.

What we took away

Serverless platforms simplify deployment considerably and introduce constraints that are easy to underestimate. Session state is the canonical example: the standard solution works in a conventional server environment and fails silently in a stateless one. The lesson is not to avoid serverless — it was the right choice here — but to verify early which parts of the stack actually depend on persistence, and to test session behaviour explicitly before it becomes a problem in production.

PostgreSQL is not the elegant answer to session storage. It is the answer that works.