What this article covers: The technical architecture behind employer-sponsored GLP-1 benefit platforms, including multi-party insurance integration, prescription flow orchestration, eligibility verification, and the backend decisions that determine whether a platform survives at scale. Based on five years of production experience building 9am.health, a virtual clinic serving clients including Amazon, Novo Nordisk and the State of Georgia.
What is a GLP-1 employer benefits platform?
A GLP-1 employer benefits platform is software that enables employers to offer GLP-1 medications, including semaglutide (Wegovy, Ozempic) and tirzepatide (Zepbound, Mounjaro), as a covered employee benefit, managing the entire flow from eligibility verification through prescription, entire instant care flow and insurance reimbursement.
Unlike consumer-facing telehealth apps, these platforms must integrate simultaneously with employers, insurers, pharmacy benefit managers (PBMs), and pharmacies verifying coverage at every step before a prescription is written or a drug is dispensed.
According to Mercer’s Survey on Health & Benefits Strategies for 2026, 77% of large employers (500 or more employees) say managing their overall GLP-1 costs is extremely or very important. The demand is real. The infrastructure to serve it is the hard part.
Why GLP-1 platforms are technically harder than standard telehealth
Most telehealth platforms handle a simple flow: patient registers, pays by credit card, sees a doctor, receives a prescription. This works for many use cases. It does not work for employer-sponsored GLP-1 benefits.
The employer benefits model introduces four parties instead of two:
| Party | Role | Integration required |
| Employer | Contracts with the platform, covers cost | Enrollment verification, billing |
| Employee | End user, accesses care | Identity verification, eligibility check |
| Insurer / PBM | Finances medication and clinical services | Real-time eligibility API, claims submission |
| Pharmacy | Dispenses medication | e-prescribing integration, refund verification |
Every step in the patient journey, booking an appointment, receiving a prescription, picking up medication, requires verification that coverage exists and will be reimbursed. A prescription written without confirmed coverage creates liability for the platform, the physician and the pharmacy.
„Before we let an employee come to us as a user, before we let them book an appointment with a doctor, prescribe a medication and deliver it to a pharmacy, at every single stage we have to be certain it will be covered by insurance. The insurer financing each of those stages has to be certain the employer will pay for that insurance”. – Łukasz Sobisiak, Senior Backend Engineer, fireup.pro, 5 years building 9am.health
The GLP-1 shift: what changed in the platform’s user base
9am.health launched as a diabetes management platform. Over the past two years, the user mix has fundamentally changed.
Some analyst projections show the GLP-1 market reaching $150 billion by 2030. In practice, this market shift is already visible at the platform level: the majority of new users arriving through employer benefit programs are now coming for GLP-1 medications (Ozempic, Wegovy, Zepbound) not exclusively for diabetes management.
Healthcare coverage choices have always influenced job decisions, but the demand for GLP-1s is making that dynamic more visible and more urgent. Employers including Amazon, Novo Nordisk and the State of Georgia are now using platforms like 9am.health specifically because GLP-1 access has become a competitive hiring and retention tool.
In 2026 alone, 9am.health added 40,000 new users through employer benefit programs, growth that required the platform to have been architecturally prepared for scale from the beginning.
How the prescription flow actually works: technical architecture
The core technical problem is this: a single prescription event involves multiple sequential verifications across external systems, each with its own API, latency profile and failure mode.
The prescription flow step by step
Step 1: Employer enrollment verification When an employee signs up, the platform verifies their employment status and benefit eligibility with their employer’s HR system. This is typically done via EDI 834 (benefit enrollment) or direct API integration with HR platforms like Workday or ADP.
Step 2: Insurance eligibility check Before any clinical interaction, the platform queries the insurer’s eligibility API (typically via EDI 270/271 or a real-time FHIR-based alternative) to confirm:
- Is this employee covered under this employer’s plan?
- Which services are covered (clinical visit, lab tests, medication)?
- What is the copay or cost-sharing structure?
Step 3: Clinical visit and prescription The physician reviews lab results, patient history, and survey responses. The platform surfaces dosage recommendations based on previous bloodwork and patient-reported outcomes. A prescription is written, but not transmitted until Step 4.
Step 4: Pharmacy benefit verification Before the prescription reaches the pharmacy, the platform verifies with the PBM that:
- The specific medication is on the formulary
- The patient’s coverage applies to this drug
- The pharmacy will receive reimbursement for dispensing it
Step 5: e-Prescribing to pharmacy Once coverage is confirmed, the prescription is transmitted electronically via NCPDP SCRIPT standard. The pharmacy fulfills the order; the platform tracks fulfillment status.
Step 6: Post-fulfillment follow-up Two weeks after dispensing, the platform sends an automated patient survey. Survey responses feed back into the clinical dashboard, informing the physician’s next dosage decision.
„The challenge is that we have to integrate with different services at every stage that allow us to answer the question: can we give this person the medication and will the pharmacy definitely get reimbursed for this person from the insurer?” – Łukasz Sobisiak, Senior Backend Engineer, fireup.pro
What breaks at scale: the architecture decisions that matter
9am.health went from zero users to production in four months and from initial launch to serving major employers in under five years. These are the backend decisions that made that possible.
1. Domain-Driven Design from day one
The platform was built using DDD (Domain-Driven Design) with explicit separation of concerns from the first line of code. Every domain, clinical, eligibility, prescriptions, pharmacy, billing, has its own bounded context with defined interfaces.
Why this matters at scale: when 40,000 new users arrive through a single employer contract, the clinical domain needs to scale independently of the billing domain. Monolithic architecture where these concerns are entangled makes this impossible without rebuilding.
2. CQRS for read/write separation
Command Query Responsibility Segregation separates the write path (prescription submitted, eligibility checked, pharmacy notified) from the read path (physician dashboard, patient history, lab results display).
In a platform handling concurrent eligibility checks, prescription events, and pharmacy status updates, CQRS prevents read-heavy operations from blocking write-critical flows.
3. Event-driven architecture for multi-party coordination
The prescription flow involves asynchronous events across external systems – eligibility APIs, PBM systems, pharmacy networks. Each has different latency and reliability characteristics.
An event-driven approach decouples these integrations: the platform publishes events (eligibility requested, prescription written, fulfillment confirmed) and handles each asynchronously, with retry logic and dead-letter queues for failure cases.
4. Containerization and horizontal scaling from the start
The platform was containerized and deployed on infrastructure designed for horizontal scaling – adding instances rather than upgrading servers. When State of Georgia came onboard with thousands of users, the platform scaled without architectural changes.
5. Architecture tests enforced in CI
Standard code reviews catch logic errors. Architecture tests catch structural violations: a developer importing a billing dependency into the clinical domain, for example. The platform encodes architectural rules as automated tests that run in CI, making the separation of concerns enforceable rather than advisory.
The compliance layer: HIPAA across every integration
Every external integration in the prescription flow touches protected health information (PHI). Eligibility checks contain insurance identifiers. Prescriptions contain diagnoses and medication details. Lab results contain clinical data.
In commercial plans and employer groups, GLP-1 adoption is accelerating: a 2025 Health Affairs/KFF survey found that 43% of firms with 5,000+ employees now cover GLP-1s for weight loss, up from 28% in 2024. As adoption grows, so does regulatory scrutiny of the platforms managing this data.
HIPAA requirements that affect platform architecture:
| Requirement | Architectural implication |
| PHI encryption at rest and in transit | Every data store and API call encrypted |
| Minimum necessary access | Role-based access control at the domain level |
| Audit logging | Every PHI access event logged and retained |
| Business Associate Agreements | BAA required with every external integration |
| Breach notification | Detection and notification workflow built in, not bolted on |
These are not post-launch compliance checkboxes. They are architectural requirements that determine how the system is built from the first sprint.
What it takes to go from MVP to 40,000 users in one employer contract
The 9am.health platform moved from first line of code to production in four months. This was possible because of decisions made before the first user arrived:
1. API-first development. The backend API was built and validated before the frontend was started. This forced explicit definition of contracts between services and eliminated ambiguity about data flows, including PHI flows, from the beginning.
2. No shortcuts on eligibility. The temptation in early-stage healthcare platforms is to mock eligibility verification and add real integration later. The problem: real integration reveals edge cases, employees with multiple coverage layers, mid-year plan changes, formulary exclusions, that mock data hides. Building real eligibility integration early, even when the user base is small, avoids expensive retrofits.
3. Scalable team structure. As the platform grew, the team split into two sub-teams aligned to product domains, not to technical layers. This mirrors the DDD structure of the codebase and allows teams to ship independently without coordination overhead.
Our Healthcare projects in production
Since 2018, fireup.pro has been building software for digital health companies in the US and Europe. Projects include 9am.health (virtual clinic – Amazon, State of Georgia), mySugr (1.8M users, Roche, Vienna) and Mentalyc (AI therapy documentation, HIPAA, SOC 2 Type II).
About this project
fireup.pro has been the engineering partner for 9am.health since the platform’s first line of code in 2021. Łukasz Sobisiak (Senior Backend Engineer) has led backend development for five years, building the clinical and back-office systems that power care delivery for employees of Amazon, Novo Nordisk and the State of Georgia.
The platform was built using TypeScript, Node.js, DDD, CQRS and AWS infrastructure, containerized from the first deployment and designed for horizontal scaling.
fireup.pro builds backend systems for healthcare platforms operating in regulated US and European markets, including HIPAA-compliant architectures, multi-party insurance integrations and employer benefit platform infrastructure.
🚀 Building a GLP-1 or employer health benefit platform?Talk to our team.
