O czym jest ten artykuł: Architektura techniczna platform benefitów GLP-1 finansowanych przez pracodawców – integracja z ubezpieczycielami, orkiestracja przepływu recept, weryfikacja uprawnień i decyzje backendowe, które decydują o tym, czy platforma przeżyje na produkcji. Na podstawie pięciu lat doświadczenia przy budowie 9am.health – wirtualnej kliniki obsługującej m.in. Amazon, Novo Nordisk i stan Georgia.
Table of Contents
Czym jest platforma benefitów GLP-1 dla pracodawców?
Platforma benefitów GLP-1 to oprogramowanie, które pozwala pracodawcom objąć leki z grupy GLP-1, w tym semaglutyd (Wegovy, Ozempic) i tirzepatyd (Zepbound, Mounjaro), firmowym programem świadczeń pracowniczych. Platforma zarządza całym przepływem: od weryfikacji uprawnień, przez wystawienie recepty, po rozliczenie z ubezpieczycielem.
W odróżnieniu od konsumenckich aplikacji telemedycznych, tego typu systemy muszą jednocześnie integrować się z pracodawcą, ubezpieczycielem, pharmacy benefit managerem (PBM) i apteką, weryfikując pokrycie kosztów na każdym etapie, zanim recepta zostanie wystawiona lub lek wydany.
Według badania Mercer dotyczącego strategii świadczeń zdrowotnych na 2026 rok, 77% dużych pracodawców (500 i więcej pracowników) uważa kontrolę kosztów GLP-1 za kwestię ekstremalnie lub bardzo ważną. Popyt jest realny. Infrastruktura, która go obsłuży, to dopiero wyzwanie.
Dlaczego platformy GLP-1 są technicznie trudniejsze niż standardowa telemedycyna
Większość platform telemedycznych obsługuje prosty przepływ: pacjent się rejestruje, płaci kartą, rozmawia z lekarzem, dostaje receptę. To działa w wielu przypadkach. Nie działa w modelu benefitów pracodawcy.
Model pracodawcy wprowadza cztery strony zamiast dwóch:
| Strona | Rola | Wymagana integracja |
|---|---|---|
| Pracodawca | Podpisuje kontrakt z platformą, pokrywa koszty | Weryfikacja rejestracji, rozliczenia |
| Pracownik | Użytkownik końcowy | Weryfikacja tożsamości i uprawnień |
| Ubezpieczyciel / PBM | Finansuje leki i usługi kliniczne | Eligibility API w czasie rzeczywistym, składanie roszczeń |
| Apteka | Wydaje leki | Integracja z e-prescribing, weryfikacja zwrotu kosztów |
Każdy etap ścieżki pacjenta (rezerwacja wizyty, wystawienie recepty, odbiór leku) wymaga potwierdzenia, że pokrycie istnieje i że zostanie rozliczone. Recepta wystawiona bez potwierdzonego pokrycia tworzy odpowiedzialność prawną dla platformy, lekarza i apteki.
„Zanim pozwolimy pracownikowi skorzystać z platformy, zarezerwować wizytę, dostać receptę i odebrać lek z apteki — na każdym z tych etapów musimy mieć pewność, że będzie to pokryte przez ubezpieczenie. Ubezpieczyciel finansujący każdy z tych etapów musi mieć pewność, że pracodawca zapłaci za to ubezpieczenie”. – Łukasz Sobisiak, Senior Backend Engineer, fireup.pro
Zmiana rynku GLP-1: co się zmieniło w bazie użytkowników platformy
9am.health startowało jako platforma do zarządzania cukrzycą. W ciągu ostatnich dwóch lat skład użytkowników zmienił się fundamentalnie.
Niektóre prognozy analityczne wskazują, że rynek GLP-1 osiągnie 150 miliardów dolarów do 2030 roku. W praktyce ta zmiana jest już widoczna na poziomie platformy: większość nowych użytkowników trafiających przez programy benefitów pracodawcy przychodzi po leki GLP-1 (Ozempic, Wegovy, Zepbound), nie wyłącznie po zarządzanie cukrzycą.
Dostęp do leków GLP-1 stał się realnym argumentem w walce o pracownika. Pracodawcy tacy jak Amazon, Novo Nordisk czy stan Georgia korzystają z platform tego typu właśnie dlatego, że dostępność GLP-1 stała się narzędziem rekrutacji i retencji.
Tylko w 2026 roku 9am.health pozyskało 40 000 nowych użytkowników przez programy benefitów pracodawcy to wzrost, który wymagał wcześniejszego przygotowania architektury pod skalę.
Jak faktycznie działa przepływ recepty: architektura techniczna
Podstawowy problem techniczny jest następujący: jedno zdarzenie receptowe angażuje wiele sekwencyjnych weryfikacji w zewnętrznych systemach, z których każdy ma własne API, własny profil latencji i własne tryby awarii.
Przepływ recepty krok po kroku
Krok 1: Weryfikacja rejestracji u pracodawcy. Przy rejestracji platforma weryfikuje zatrudnienie i uprawnienia pracownika w systemie HR pracodawcy, zwykle przez EDI 834 lub bezpośrednią integrację z Workday albo ADP.
Krok 2: Sprawdzenie uprawnień ubezpieczeniowych. Przed jakąkolwiek interakcją kliniczną platforma odpytuje eligibility API ubezpieczyciela (przez EDI 270/271 lub FHIR) i potwierdza: czy pracownik jest objęty planem tego pracodawcy, które usługi są pokryte (wizyta, badania, leki), jaka jest struktura dopłat.
Krok 3: Wizyta kliniczna i wystawienie recepty. Lekarz analizuje wyniki badań, historię pacjenta i odpowiedzi z ankiety. Platforma podpowiada dawkowanie na podstawie poprzednich badań i raportowanych wyników. Recepta jest wystawiana, ale nie przesyłana do momentu realizacji kroku 4.
Krok 4: Weryfikacja pokrycia w PBM. Zanim recepta trafi do apteki, platforma weryfikuje z PBM, że konkretny lek jest na liście refundacyjnej, że pokrycie pacjenta obejmuje ten lek i że apteka otrzyma zwrot kosztów za jego wydanie.
Krok 5: E-prescribing do apteki. Po potwierdzeniu pokrycia recepta jest przesyłana elektronicznie przez standard NCPDP SCRIPT. Apteka realizuje zamówienie; platforma śledzi status realizacji.
Krok 6: Follow-up po realizacji. Dwa tygodnie po wydaniu leku platforma wysyła do pacjenta automatyczną ankietę. Odpowiedzi trafiają z powrotem do dashboardu klinicznego i informują lekarza przy kolejnej decyzji o dawkowaniu.
„Wyzwanie polega na tym, że na każdym etapie musimy integrować się z różnymi serwisami, które pozwalają odpowiedzieć na jedno pytanie: czy możemy podać tej osobie lek i czy apteka na pewno dostanie za to zwrot od ubezpieczyciela?”. – Łukasz Sobisiak, Senior Backend Engineer, fireup.pro
Co się psuje przy skali: decyzje architektoniczne, które mają znaczenie
9am.health przeszło od zera do produkcji w cztery miesiące, a od startu do obsługi dużych pracodawców w niecałe pięć lat. Oto decyzje backendowe, które to umożliwiły.
1. DDD od pierwszej linii kodu
Platforma została zbudowana z użyciem Domain-Driven Design z wyraźnym podziałem odpowiedzialności od samego początku. Każda domena (kliniczna, uprawnienia, recepty, apteka, rozliczenia) ma własny bounded context z zdefiniowanymi interfejsami.
Dlaczego to ma znaczenie przy skali: kiedy 40 000 nowych użytkowników trafia przez jeden kontrakt pracodawcy, domena kliniczna musi skalować się niezależnie od domeny rozliczeniowej. Monolityczna architektura z powiązanymi domenami to uniemożliwia bez przebudowy.
2. CQRS dla separacji odczytu i zapisu
Command Query Responsibility Segregation oddziela ścieżkę zapisu (recepta złożona, uprawnienia sprawdzone, apteka powiadomiona) od ścieżki odczytu (dashboard lekarza, historia pacjenta, wyniki badań).
Na platformie obsługującej jednocześnie weryfikacje uprawnień, zdarzenia receptowe i aktualizacje statusu z apteki – CQRS zapobiega blokowaniu krytycznych operacji zapisu przez operacje odczytu.
3. Architektura event-driven dla koordynacji wielu stron
Przepływ recepty angażuje asynchroniczne zdarzenia w zewnętrznych systemach: eligibility API, systemy PBM, sieci aptek. Każdy ma inne charakterystyki latencji i niezawodności.
Podejście event-driven odsprzęga te integracje: platforma publikuje zdarzenia (uprawnienia sprawdzone, recepta wystawiona, realizacja potwierdzona) i obsługuje każde asynchronicznie, z retry logic i dead-letter queues dla przypadków awarii.
4. Konteneryzacja i skalowanie horyzontalne od początku
Platforma była konteneryzowana i wdrożona na infrastrukturze przystosowanej do skalowania horyzontalnego, dodawania instancji zamiast modernizacji serwerów. Kiedy stan Georgia wszedł na pokład z tysiącami użytkowników, platforma przeskalowała się bez zmian architektonicznych.
5. Testy architektoniczne w CI
Standardowe code review wyłapują błędy logiki. Testy architektoniczne wyłapują naruszenia strukturalne na przykład developer importujący zależność z domeny rozliczeniowej do domeny klinicznej. Platforma koduje reguły architektoniczne jako automatyczne testy uruchamiane w CI, dzięki czemu separacja odpowiedzialności jest egzekwowalna, a nie tylko zalecana.
Warstwa compliance: HIPAA przy każdej integracji
Każda zewnętrzna integracja w przepływie recepty dotyka chronionych danych zdrowotnych (PHI). Weryfikacje uprawnień zawierają identyfikatory ubezpieczeniowe. Recepty zawierają diagnozy i szczegóły leków. Wyniki badań zawierają dane kliniczne.
W planach komercyjnych i grupach pracodawców adopcja GLP-1 przyspiesza: badanie Health Affairs/KFF z 2025 roku pokazało, że 43% firm zatrudniających ponad 5000 pracowników pokrywa teraz GLP-1 dla utraty wagi, w porównaniu do 28% rok wcześniej. Wraz z rosnącą adopcją rośnie też nadzór regulacyjny nad platformami zarządzającymi tymi danymi.
Wymagania HIPAA wpływające na architekturę platformy:
| Wymaganie | Implikacja architektoniczna |
|---|---|
| Szyfrowanie PHI w spoczynku i w tranzycie | Każdy magazyn danych i każde API call szyfrowane |
| Minimalny niezbędny dostęp | RBAC na poziomie domeny |
| Audit logging | Każde zdarzenie dostępu do PHI logowane i przechowywane |
| Business Associate Agreements | BAA wymagany przy każdej zewnętrznej integracji |
| Powiadomienie o naruszeniu | Workflow detekcji i powiadomień wbudowany, nie doklejony |
To nie są checkboxy do odhaczenia po launchcie. To wymagania architektoniczne, które determinują sposób budowania systemu od pierwszego sprintu.
Co jest potrzebne, żeby przejść od MVP do 40 000 użytkowników w jednym kontrakcie
9am.health przeszło od pierwszej linii kodu do produkcji w cztery miesiące. Było to możliwe dzięki decyzjom podjętym zanim pojawił się pierwszy użytkownik.
API-first development. Backend API zostało zbudowane i zwalidowane zanim ruszyło prace nad frontendem. To wymusiło precyzyjne zdefiniowanie kontraktów między serwisami i wyeliminowało niejednoznaczność co do przepływów danych, w tym przepływów PHI, od samego początku.
Żadnych skrótów przy weryfikacji uprawnień. Pokusa we wczesnych platformach healthcare to mockowanie weryfikacji uprawnień i dodanie prawdziwej integracji później. Problem: prawdziwa integracja ujawnia edge case’y, pracownicy z kilkoma warstwami pokrycia, zmiany planów w trakcie roku, wykluczenia z listy refundacyjnej, których dane mockowe nie pokazują. Budowanie prawdziwej integracji uprawnień od początku, nawet przy małej bazie użytkowników, pozwala uniknąć kosztownych poprawek.
Skalowalna struktura zespołu. W miarę wzrostu platformy zespół podzielił się na dwa podzespoły zorientowane na domeny produktowe, nie na warstwy techniczne. To odzwierciedla strukturę DDD kodu i pozwala zespołom dostarczać niezależnie, bez koordynacyjnego narzutu.
Nasze projekty healthcare na produkcji
Od 2018 roku fireup.pro buduje oprogramowanie dla firm z sektora digital health w USA i Europie. Projekty obejmują m.in. 9am.health (wirtualna klinika – Amazon, stan Georgia), mySugr (1,8 mln użytkowników, Roche, Wiedeń) i Mentalyc (AI dokumentacja terapeutyczna, HIPAA, SOC 2 Type II).
Budujesz platformę GLP-1 lub benefit zdrowotny dla pracodawcy? Porozmawiaj z naszym zespołem.
