How We Built a Pharma Compliance Training Platform

In early 2025, a global pharmaceutical company came to 1Raft with a problem that's common in pharma but rare in most tech conversations: their 4,200 sales representatives across 11 countries were failing compliance certifications.

Not because they didn't know the material. Because they couldn't access the training.

The legacy LMS - a well-known enterprise platform - required a desktop browser, took 12 clicks to reach a course, and had zero mobile support. Sales reps spend their days driving between hospitals and clinics. Asking them to find a desktop computer, log in through a VPN, and complete a 45-minute module was asking them to do unpaid overtime.

The result: 14% of reps had lapsed certifications at any given time. The company was spending $2.8M annually flying reps to regional training centers for in-person workshops. And the compliance team tracked certification expiration dates in spreadsheets.

This is the story of how we replaced all of that in 12 weeks.

The Problem Wasn't Training Content - It Was Delivery

The pharma company had excellent training content. Their medical affairs team had written thorough, regulation-aligned modules covering product knowledge, adverse event reporting, promotional compliance, and country-specific guidelines.

The content wasn't the problem. The delivery mechanism was.

When we analyzed the existing system, we found three root causes:

Access friction killed completion rates. The legacy LMS required VPN access, worked only on desktop browsers, and had a navigation structure that buried courses behind category trees, search filters, and registration workflows. Each training module required 12 interactions before the first content screen appeared. For a sales rep with 15 minutes between client meetings, this was unusable.

No offline support meant lost time. Sales reps travel extensively - driving between hospitals, flying to different cities, waiting in clinics. These are natural windows for training. But without offline support, reps needed reliable internet connectivity to access modules. In India, rural coverage is inconsistent. In markets like parts of Africa and Southeast Asia, it's worse.

Compliance tracking was manual. Different countries have different certification requirements. India requires certain product-specific training. EU markets require pharmacovigilance training. The US requires adverse event reporting training. The compliance team maintained a spreadsheet mapping each rep's role, country, and product assignments to their required certifications - and manually checked expiration dates weekly.

Architecture Decisions That Shaped Everything

We made three architectural decisions in the first week that defined the entire project.

Decision 1: Mobile-First, Not Mobile-Friendly

Mobile-friendly means a desktop application that adjusts its layout on smaller screens. Mobile-first means designing for the phone as the primary device and treating desktop as the secondary experience.

For pharma field sales teams, mobile isn't an alternative - it's the only realistic access point. We designed every screen, interaction, and content format for a phone held in one hand during a 10-minute break between appointments.

This meant:

• 5-8 minute modules that could be completed in a single sitting
• Vertical video instead of widescreen presentations
• Swipe-based navigation instead of click-through menus
• One-tap resume that picks up exactly where the rep left off

Decision 2: Offline-First Architecture

We built the training platform using a service worker architecture that pre-downloads module content to the device. Reps can download their assigned modules over Wi-Fi (hotel, office, home) and complete them anywhere - on a plane, in a clinic waiting room, in a car between meetings.

The offline engine handles three scenarios:

Content delivery. Training modules (video, interactive scenarios, text content) are packaged as self-contained bundles that download in the background. The app tracks download progress and notifies reps when new modules are ready for offline access.

Assessment completion. Assessment questions download with the module content. When a rep completes an assessment offline, results are stored locally with a cryptographic timestamp. When connectivity returns, results sync to the server with the original completion timestamp - so the compliance record reflects when the training was actually completed, not when it synced.

Conflict resolution. If a rep starts a module on their phone and later opens it on a tablet, the system resolves the conflict by preserving the furthest progress point from either device. This seems like an edge case, but it happened frequently enough during testing that we built explicit handling for it.

Decision 3: Compliance Engine as a First-Class System

Most LMS platforms treat compliance as a reporting layer on top of training data. We built the compliance engine as the core system that drives everything else.

The compliance engine works like this:

Each rep has a compliance profile generated from four inputs: their role (medical representative, area manager, regional director), their country, their assigned product lines, and their territory type (hospital, retail pharmacy, specialty).

The profile maps to a set of required certifications - each with specific training modules, passing criteria, validity periods, and recertification requirements. When any input changes (rep transfers to a new country, gets assigned a new product line), the compliance engine automatically recalculates their requirements and notifies them of new training obligations.

Automated escalation handles overdue certifications: reminders at 30 days, 14 days, and 7 days before expiration. If a certification lapses, the rep's manager receives an alert. If it remains lapsed for 14 days, the regional compliance director is notified. This escalation chain replaced the manual spreadsheet tracking entirely.

SCORM 2004: The Standard That Makes Auditors Happy

Pharma companies use SCORM (Sharable Content Object Reference Model) for a specific reason: regulatory auditors need standardized proof that training was completed and passed. SCORM 2004 provides a data model that tracks:

• When the learner started each module
• How long they spent on each content element
• Every assessment attempt with question-level detail
• Pass/fail status with the exact score
• Completion status with timestamp

We integrated SCORM 2004 tracking into the offline-first architecture. The SCORM runtime operates locally on the device, tracking all interactions as they happen. When the device syncs, the complete SCORM data package uploads to the server - giving the compliance team the same audit trail they'd get from a connected desktop session.

The tricky part was SCORM's sequencing model. SCORM 2004 supports complex sequencing rules - prerequisites, remediation paths, branching based on assessment performance. We implemented the core sequencing engine, then worked with the client's medical affairs team to define sequencing rules that matched their compliance requirements without creating navigation friction for reps.

Country-Specific Compliance: The Hardest Engineering Problem

The compliance mapping across 11 countries was the most complex business logic in the system. Not because the logic itself was complicated, but because the rules were different everywhere and changed frequently.

Examples of the variation:

• India requires product-specific training within 30 days of a new product assignment, plus annual recertification on adverse event reporting
• EU markets require pharmacovigilance training per EU Directive 2010/84/EU, with country-specific additions (Germany requires HWG compliance training, France requires Charte de la Visite Médicale training)
• US requires FDA REMS training for specific product categories, plus annual refresher on the PhRMA Code

We built the compliance engine as a rules engine with country-level configuration. Each country has a compliance profile template that defines:

• Required certification categories
• Module assignments per category
• Validity periods per certification
• Passing criteria per assessment
• Recertification grace periods
• Escalation timelines

When a regulatory requirement changes - which happens 2-3 times per year across 11 countries - the compliance team updates the rule configuration without engineering involvement. This was a critical design decision. If every regulatory change required a code deployment, the system would become a maintenance burden that eventually gets abandoned.

Results: What Changed After Launch

The platform launched after 12 weeks of development. Results within the first 90 days:

Certification completion went from 86% to 98%. The 14% lapsed certification rate dropped to under 2%. The remaining 2% were reps on extended leave or transitioning between roles.

Training costs dropped 72%. The $2.8M annual spend on in-person workshops dropped because most training moved to mobile delivery. The company maintained a small number of in-person sessions for high-complexity topics (advanced clinical training, leadership development), but the compliance training that previously required travel was fully digital.

Average module completion time was 6.2 minutes. This validated the 5-8 minute module design. Reps completed modules between meetings, during lunch breaks, and during commutes. The usage data showed peak training times at 8-9 AM (before first meetings), 1-2 PM (lunch), and 7-8 PM (evening).

Compliance team time shifted from tracking to strategy. The automated escalation engine and dashboard eliminated 15-20 hours per week of manual spreadsheet tracking. The compliance team redirected this time to proactive compliance strategy - updating training content ahead of regulatory changes instead of chasing expired certifications.

Engineering Lessons for Pharma Software

Building for pharma taught us patterns that apply to any regulated industry:

Compliance is architecture, not a feature. If you bolt on audit trails and electronic signatures after building the core product, you'll spend more time on the retrofit than you did on the original build. Design the compliance layer first, then build the product on top of it.

Offline-first is mandatory for field teams. Any pharma application targeting medical representatives, field monitors, or site inspectors needs to work without connectivity. This isn't a nice-to-have - it's the difference between adoption and abandonment.

Build the compliance engine as configuration, not code. Regulatory requirements change. If every change requires a code deployment, you've created a system that will eventually fall behind regulations. Build the rules engine to be configurable by the compliance team directly.

Sprint-integrated validation eliminates the bottleneck. The traditional pharma software model - build everything, then spend 4-8 weeks on IQ/OQ/PQ - is the primary reason pharma projects take 6-12 months. We execute validation protocols alongside development sprints, so the system is audit-ready when it launches.

If you're building training, compliance, or field force software for a pharma company, the architecture patterns from this project transfer directly. The regulatory framework, offline requirements, and compliance tracking needs are consistent across pharma applications - the domain specifics change, but the engineering discipline is the same.

Read the full case study for the complete project details, or get in touch if you're building something similar.