Gdy dostawca nie odpowiada. Jak Pharma Flow ma uporządkować komunikację apteki szpitalnej z kontrahentami

Zamówienie nie zostało zrealizowane. Dostawca proponuje zamiennik, ale nie wiadomo, czy odpowiada on warunkom umowy. Inna hurtownia deklaruje dostępność produktu, lecz nie potwierdza terminu dostawy.

W takich sytuacjach problemem nie jest wyłącznie brak leku. Problemem staje się również komunikacja — rozproszona pomiędzy skrzynkami pocztowymi, telefonami, dokumentami i wiedzą poszczególnych pracowników.

W projekcie Pharma Flow chcemy zbadać, jak sztuczna inteligencja może pomóc uporządkować ten proces. Nie chodzi wyłącznie o szybsze pisanie wiadomości. Chodzi o przejście od niepowiązanej korespondencji do procesu, który można monitorować, mierzyć, audytować i bezpiecznie przekazywać pomiędzy pracownikami.

Szersze wprowadzenie do projektu i wykorzystania AI w gospodarce lekowej znajdziesz w artykule Zanim zabraknie leku. Jak chcemy wykorzystać AI w gospodarce lekowej szpitala.

Komunikacja zaczyna się od umowy i zamówienia

Apteka szpitalna współpracuje z wieloma dostawcami, a każda dostawa jest częścią większego procesu. Obejmuje on między innymi:

• zawartą umowę i jej warunki;
• konkretne zamówienie;
• potwierdzenie dostępności;
• wymaganą ilość;
• cenę;
• termin i miejsce dostawy;
• ewentualny zamiennik;
• korespondencję wyjaśniającą;
• dokumenty przyjęcia oraz rozliczenia.

Dopóki wszystko przebiega zgodnie z planem, komunikacja może wydawać się prostą czynnością administracyjną. Sytuacja zmienia się, gdy kontrahent informuje o braku produktu, dostarcza tylko część zamówienia, proponuje inny lek albo nie odpowiada w terminie.

Personel apteki musi wtedy szybko ustalić:

1. co dokładnie przewiduje umowa;
2. czy wystąpiła niezgodność wymagająca wyjaśnienia;
3. czy zaproponowany odpowiednik może zostać zaakceptowany;
4. jak pilna jest potrzeba uzupełnienia zapasu;
5. których innych dostawców można zapytać o dostępność;
6. jak porównać odpowiedzi sporządzone w różnych formach;
7. jaka procedura zakupowa jest dopuszczalna;
8. kto powinien zatwierdzić dalsze działanie.

Dzisiaj duża część tej pracy jest wykonywana ręcznie. Pharma Flow ma zbadać, które elementy można bezpiecznie powierzyć inteligentnemu agentowi, a które muszą pozostać pod kontrolą człowieka.

Skrzynka pocztowa nie jest systemem zarządzania procesem

E-mail jest wygodnym i powszechnym kanałem, ale sam w sobie nie tworzy uporządkowanego procesu.

Informacje dotyczące jednego zamówienia mogą znajdować się w kilku wątkach. Odpowiedź może trafić do pracownika, który zakończył dyżur lub jest nieobecny. Dostawca może podać termin dostawy w treści wiadomości, cenę w załączniku, a informację o częściowej dostępności przekazać telefonicznie.

Dodatkowym problemem jest brak jednolitego sposobu udzielania odpowiedzi. Jeden kontrahent napisze, że produkt jest „dostępny od ręki”, drugi poda konkretną liczbę opakowań, a trzeci zaproponuje odpowiednik bez jednoznacznego określenia wszystkich parametrów.

W efekcie farmaceuta nie tylko komunikuje się z dostawcami. Musi również:

• pilnować terminów;
• łączyć wiadomości z właściwą umową i zamówieniem;
• wyodrębniać najważniejsze informacje;
• porównywać odpowiedzi sformułowane w różny sposób;
• przypominać o brakujących danych;
• dokumentować podstawę podjętej decyzji;
• przekazywać sprawę kolejnej osobie bez utraty kontekstu.

Automatyzacja nie powinna więc polegać wyłącznie na zwiększeniu liczby wysyłanych e-maili. Jej celem powinno być przekształcenie korespondencji w kontrolowany, mierzalny i audytowalny proces.

Od wykrycia problemu do przygotowania komunikatu

Planowana koncepcja Pharma Flow łączy komunikację z innymi obszarami gospodarki lekowej. Impulsem do rozpoczęcia procesu może być między innymi:

• brak wymaganego potwierdzenia realizacji zamówienia;
• zbliżający się lub przekroczony termin dostawy;
• dostarczenie mniejszej ilości produktu;
• informacja o braku dostępności;
• zaproponowanie zamiennika;
• rozbieżność pomiędzy ceną w umowie i dokumentem dostawy;
• prognozowany spadek zapasu poniżej ustalonego poziomu;
• brak obowiązującej umowy obejmującej potrzebny produkt.

Agent nie powinien rozpoczynać od wygenerowania przypadkowej wiadomości. Najpierw musi odtworzyć kontekst zdarzenia: wskazać produkt, zamówienie, dostawcę, odpowiednie zapisy umowy, wymagany termin oraz historię dotychczasowych działań.

Dopiero wtedy może przygotować projekt właściwego komunikatu, na przykład:

• prośbę o potwierdzenie terminu realizacji;
• pytanie o brakującą ilość;
• prośbę o wyjaśnienie opóźnienia;
• prośbę o wskazanie parametrów zaproponowanego zamiennika;
• zapytanie o dostępność skierowane do alternatywnych dostawców;
• wezwanie do uzupełnienia niekompletnej oferty.

Wniosek o dofinansowanie Pharma Flow zakłada prowadzenie prac nad metodami przetwarzania języka naturalnego, które mają wspierać analizę kontraktów, generowanie korespondencji i standardowe interakcje z dostawcami. Planowane rozwiązanie ma także badać możliwość pozyskiwania ofert w sytuacjach interwencyjnych i przedstawiania ich personelowi do oceny. Są to jednak cele prac badawczo-rozwojowych, a nie funkcje gotowego produktu.

Jak mógłby wyglądać taki proces?

Wyobraźmy sobie, że apteka zamówiła lek objęty obowiązującą umową. Dostawca nie przesłał wymaganego potwierdzenia, a termin realizacji zbliża się do końca.

Planowany agent mógłby:

1. rozpoznać brak potwierdzenia;
2. odnaleźć zamówienie i powiązany kontrakt;
3. ustalić termin wynikający z umowy;
4. przygotować wiadomość z prośbą o potwierdzenie dostawy;
5. przekazać projekt uprawnionemu pracownikowi albo — dla uprzednio zatwierdzonego, niskiego ryzyka scenariusza — wysłać techniczne przypomnienie;
6. monitorować odpowiedź;
7. odczytać z niej deklarowaną ilość i termin;
8. oznaczyć odpowiedź jako pełną, niepełną albo niejednoznaczną;
9. zarejestrować całą sekwencję zdarzeń.

Jeżeli kontrahent poinformuje, że nie może zrealizować dostawy, system mógłby zaproponować uruchomienie kolejnego, wcześniej skonfigurowanego scenariusza:

• wskazać dostawców dopuszczonych do kontaktu;
• przygotować ujednolicone zapytanie o dostępność;
• wysłać je po zatwierdzeniu;
• zebrać odpowiedzi;
• wyodrębnić ceny, ilości i terminy;
• zaznaczyć niekompletne lub niejednoznaczne oferty;
• przedstawić personelowi uporządkowane porównanie.

To człowiek powinien zdecydować, czy którakolwiek oferta może zostać przyjęta i jaka procedura zakupowa jest właściwa.

Ujednolicone pytanie daje porównywalną odpowiedź

Jedną z największych korzyści automatyzacji może być standaryzacja komunikacji.

Zapytanie generowane przez system powinno jednoznacznie określać:

• produkt lub dopuszczalny zakres odpowiedników;
• postać, dawkę i wielkość opakowania;
• potrzebną ilość;
• wymagany termin;
• miejsce dostawy;
• termin udzielenia odpowiedzi;
• informacje, które musi zawierać oferta;
• identyfikator sprawy umożliwiający przypisanie odpowiedzi.

Dzięki temu agent nie tylko wysyła wiadomość. Z góry tworzy strukturę, według której później oceni jej kompletność.

Jeżeli dostawca nie poda terminu, system może przygotować prośbę o jego uzupełnienie. Jeżeli poda cenę bez informacji o dostępnej ilości, odpowiedź zostanie oznaczona jako niepełna. Jeżeli zaproponuje inny produkt, agent może skierować sprawę do osobnego procesu weryfikacji zamiennika.

NLP ma rozumieć znaczenie, a nie tylko szukać słów

Prosty mechanizm może wykrywać słowa takie jak „brak”, „dostępny” czy „zamiennik”. W praktyce to za mało.

Porównajmy trzy odpowiedzi:

Produkt jest dostępny.

Dostępne jest 20 opakowań, wysyłka w ciągu dwóch dni roboczych.

Produkt chwilowo niedostępny. Możemy zaproponować inne opakowanie pod warunkiem potwierdzenia do godziny 12:00.

Każda z nich dotyczy dostępności, ale ich znaczenie operacyjne jest zupełnie inne.

Model powinien próbować rozpoznać:

• którego produktu dotyczy odpowiedź;
• jaka ilość jest dostępna;
• czy cena jest netto czy brutto;
• jaki jest termin dostawy;
• jak długo obowiązuje oferta;
• czy produkt odpowiada zapytaniu;
• czy pojawiły się dodatkowe warunki;
• czego nadal brakuje do podjęcia decyzji.

NIST wskazuje, że generatywna AI może tworzyć treści fałszywe, nieuzasadnione albo pozornie wiarygodne, dlatego jej wykorzystanie wymaga zarządzania ryzykiem, dokumentowania działania i odpowiedniego nadzoru człowieka.[2]

Pharma Flow nie powinien więc „domyślać się” ceny, ilości ani terminu. Brak danych musi pozostać brakiem danych, a informacja niejednoznaczna powinna zostać skierowana do wyjaśnienia.

Automatyzacja nie wybiera podstawy prawnej zakupu

Szczególnej ostrożności wymaga pojęcie zamówienia interwencyjnego lub zamówienia „z wolnej ręki”.

Nie każda pilna potrzeba zakupu leku pozwala zastosować niekonkurencyjny tryb. Urząd Zamówień Publicznych wskazuje, że zastosowanie art. 214 ust. 1 pkt 5 ustawy Prawo zamówień publicznych wymaga łącznego spełnienia ustawowych przesłanek. Sytuacja musi mieć charakter wyjątkowy, nie wynikać z przyczyn leżących po stronie zamawiającego, być niemożliwa wcześniej do przewidzenia i wymagać natychmiastowego wykonania zamówienia w warunkach, w których nie można zachować terminów innych trybów.[1]

Agent może zatem:

• zebrać informacje o potrzebie;
• wskazać brak realizacji kontraktu;
• przygotować chronologię zdarzeń;
• pozyskać informacje o dostępności;
• uporządkować możliwe oferty;
• przygotować roboczy materiał lub projekt dokumentu.

Nie powinien jednak samodzielnie rozstrzygać, że zostały spełnione przesłanki określonej procedury, ani zatwierdzać zakupu w imieniu osoby uprawnionej.

AI może przygotować materiał do decyzji. Nie może przejąć odpowiedzialności za legalność zakupu.

Człowiek powinien pozostać w punktach decyzyjnych

Nie każda wiadomość musi być zatwierdzana ręcznie. Techniczne potwierdzenie odbioru albo przypomnienie o terminie może być wysyłane automatycznie, jeżeli placówka zatwierdziła wcześniej dokładnie określony scenariusz.

Inaczej należy traktować wiadomości, które:

• formułują zarzut naruszenia umowy;
• zawierają interpretację warunków kontraktu;
• rozpoczynają negocjacje;
• akceptują zamiennik;
• potwierdzają wybór oferty;
• tworzą zobowiązanie finansowe;
• składają zamówienie;
• zmieniają termin lub warunki realizacji.

W takich przypadkach właściwy jest model human in the loop: agent przygotowuje treść, porządkuje dane i wskazuje możliwe działanie, natomiast uprawniona osoba zatwierdza, poprawia albo odrzuca propozycję.

Unijny AI Act wprowadza obowiązki zależne od sposobu wykorzystania i poziomu ryzyka systemu. Oficjalne materiały Komisji podkreślają znaczenie przejrzystości, rejestrowania aktywności, nadzoru człowieka, dokładności, odporności i cyberbezpieczeństwa.[3][4] Ostateczne obowiązki Pharma Flow będą zależały od przyjętej architektury i kwalifikacji prawnej konkretnego zastosowania.

Projekt powinien również przewidzieć jasną informację dla kontrahenta, gdy prowadzi on bezpośrednią interakcję z agentem AI. Sposób i zakres takiej informacji wymagają jednak odrębnej analizy prawnej.

Każda wiadomość powinna pozostawić ślad

W procesie dotyczącym leków, umów i środków finansowych nie wystarczy wiedzieć, jaka była ostatnia odpowiedź dostawcy.

Potrzebna jest historia pozwalająca ustalić:

• jakie zdarzenie uruchomiło komunikację;
• na podstawie której umowy agent działał;
• jakie dane otrzymał;
• jaką wiadomość przygotował;
• kto ją zatwierdził;
• kiedy została wysłana;
• jaka odpowiedź wpłynęła;
• jakie informacje zostały z niej odczytane;
• co poprawił użytkownik;
• kto zatwierdził dalsze działanie.

Taki rejestr ma znaczenie dla kontroli wewnętrznej, audytu, reklamacji, bezpieczeństwa i późniejszej oceny jakości modelu.

Pozwala również odtworzyć powód rekomendacji. Najtańsza oferta nie musi być najlepsza, jeżeli nie gwarantuje odpowiedniej ilości lub terminu. Agent powinien pokazywać kryteria porównania, a nie tylko wskazywać jednego dostawcę.

Automatyczna skrzynka staje się elementem krytycznym dla bezpieczeństwa

Agent, który czyta zewnętrzną korespondencję i może przygotowywać wiadomości lub inicjować proces zakupowy, wymaga szczególnie mocnych zabezpieczeń.

ENISA podkreśla potrzebę wzmacniania cyberhigieny i odporności podmiotów ochrony zdrowia.[5] Z kolei materiały NIST dotyczące generatywnej AI obejmują ryzyka związane z integralnością informacji, nieprawidłowymi treściami i wykorzystaniem systemu poza jego zamierzonym zakresem.[2]

W przypadku agenta komunikacyjnego trzeba brać pod uwagę nie tylko tradycyjny phishing. Zewnętrzna wiadomość lub załącznik mogą zawierać treść próbującą wpłynąć na zachowanie modelu, na przykład polecenie zignorowania zasad, ujawnienia informacji albo wysłania danych na inny adres.

Dlatego architektura powinna zakładać między innymi:

• traktowanie każdej korespondencji zewnętrznej jako niezaufanej;
• oddzielenie treści wiadomości od instrukcji systemowych;
• ścisłą listę operacji dostępnych agentowi;
• weryfikację nadawcy, domeny i adresatów;
• skanowanie i izolację załączników;
• zakaz samodzielnej zmiany numeru rachunku, miejsca dostawy albo odbiorcy;
• odrębne uprawnienia do przygotowania, wysłania i zatwierdzenia zamówienia;
• limity liczby wiadomości i wartości operacji;
• rejestrowanie działań bez ujawniania sekretów;
• możliwość natychmiastowego zatrzymania automatyzacji;
• bezpieczny tryb ręczny na wypadek awarii.

Najbezpieczniejszy agent nie powinien mieć nieograniczonego dostępu do całej skrzynki, wszystkich umów i wszystkich funkcji systemu aptecznego.

E-mail może być początkiem, ale nie powinien być końcem

Poczta elektroniczna jest powszechna i pozwala komunikować się również z dostawcami, którzy nie udostępniają interfejsów integracyjnych. Dlatego może być praktycznym kanałem pierwszego etapu.

Docelowo część komunikacji może przechodzić do bardziej ustrukturyzowanych form:

• formularzy dostawcy;
• portali kontrahentów;
• komunikatów EDI;
• interfejsów API;
• ustrukturyzowanych potwierdzeń;
• elektronicznych faktur i dokumentów dostawy.

W europejskich zamówieniach publicznych stosowane są między innymi eForms, TED i mechanizmy eInvoicing. Ich wspólną wartością jest zwiększanie strukturyzacji i możliwości maszynowego przetwarzania informacji.[6]

Podobna zasada może przyświecać Pharma Flow: e-mail pozostaje źródłem danych, ale jego treść jest zamieniana w uporządkowane zdarzenie procesowe.

Od lokalnej korespondencji do obrazu dostępności

Automatyzacja komunikacji może również dostarczać danych o powtarzających się zjawiskach:

• dostawcach często opóźniających realizację;
• produktach regularnie zgłaszanych jako niedostępne;
• typowych powodach odmowy realizacji;
• średnim czasie odpowiedzi;
• częstości proponowania zamienników;
• różnicach cen i terminów;
• sezonowych zmianach dostępności.

Na poziomie europejskim EMA wykorzystuje European Shortages Monitoring Platform do gromadzenia danych o dostępności, podaży i popycie, aby wspierać zapobieganie niedoborom, ich wykrywanie i zarządzanie nimi.[7]

Pharma Flow nie ma zastępować systemów regulacyjnych. Może natomiast pomóc szpitalowi lepiej wykorzystywać jego własne dane operacyjne i wcześniej zauważać, że pojedyncze problemy zaczynają tworzyć wzorzec.

Jak mierzyć użyteczną automatyzację?

Liczba wysłanych automatycznie wiadomości nie jest dobrym miernikiem sukcesu. System może generować setki e-maili, a mimo to zwiększać chaos.

Znacznie bardziej użyteczne będą wskaźniki takie jak:

• czas od wykrycia problemu do pierwszego kontaktu;
• czas uzyskania kompletnej odpowiedzi;
• odsetek projektów wiadomości poprawianych przez człowieka;
• trafność przypisywania odpowiedzi do spraw;
• poprawność odczytania ceny, ilości i terminu;
• liczba brakujących danych wykrytych automatycznie;
• liczba zbędnie wysłanych zapytań;
• czas przygotowania porównania ofert;
• odsetek rekomendacji zaakceptowanych przez personel;
• liczba incydentów i prób nieuprawnionego wpływania na agenta;
• czas pracy personelu przed i po wdrożeniu.

We wniosku Pharma Flow przyjęto jako jeden z docelowych parametrów automatyzację co najmniej 80% określonych czynności dotyczących zamówień interwencyjnych. Jest to cel badawczy wymagający dopiero precyzyjnego zdefiniowania i zweryfikowania, a nie wynik osiągnięty przez działający system.

Nie chodzi o pisanie większej liczby wiadomości

Największą wartością inteligentnego agenta nie będzie samo generowanie poprawnie brzmiących e-maili. Taką funkcję można dziś stosunkowo łatwo zademonstrować.

Znacznie trudniejsze jest stworzenie systemu, który:

• rozumie, dlaczego wiadomość powinna zostać przygotowana;
• zna kontekst umowy i zamówienia;
• potrafi zinterpretować niejednoznaczną odpowiedź;
• wie, kiedy poprosić o brakujące informacje;
• nie przekracza przyznanych uprawnień;
• zachowuje pełną historię działań;
• przekazuje decyzję człowiekowi we właściwym momencie.

To właśnie ten problem chcemy badać w ramach Pharma Flow.

Jesteśmy na początku drogi. Nie wiemy jeszcze, jaka część korespondencji okaże się wystarczająco powtarzalna, aby ją bezpiecznie automatyzować, jak będą reagować dostawcy ani ile interwencji człowieka pozostanie niezbędnych.

Przyszłością nie powinna być skrzynka pocztowa, w której każdy problem trzeba od początku odtwarzać z kilkunastu wiadomości.

Przyszłością może być proces, w którym technologia porządkuje informacje, pilnuje kolejnych kroków i przygotowuje możliwe działania — a farmaceuta zachowuje wiedzę, kontrolę i odpowiedzialność za ostateczną decyzję.

O projekcie

• Nazwa komunikacyjna: Pharma Flow
• Numer projektu: FENG.01.01-IP.02-0638/25
• Oficjalny tytuł: „Opracowanie inteligentnego agenta Pharma Flow wykorzystującego sztuczną inteligencję oraz sfederowane uczenie maszynowe do optymalizacji gospodarki lekowej oraz przejęcia rutynowych, czasochłonnych zadań personelu farmaceutycznego w szpitalach”
• Beneficjent: Infotower Business Solutions sp. z o.o.
• Okres realizacji projektu: 1 marca 2026 – 29 lutego 2028
• Planowany okres wdrożenia rezultatów: 1 marca 2028 – 31 sierpnia 2028
• Wartość projektu: 22 137 373,39 zł
• Dofinansowanie: 16 146 083,00 zł
• Program: Fundusze Europejskie dla Nowoczesnej Gospodarki — Ścieżka SMART
• Obecny etap: początek realizacji prac badawczo-rozwojowych

Projekt jest współfinansowany ze środków Unii Europejskiej.

Źródła i dalsza lektura

1. Urząd Zamówień Publicznych, „Dopuszczalność udzielenia zamówienia w trybie z wolnej ręki na podstawie art. 214 ust. 1 pkt 5 ustawy Pzp (…)”: gov.pl
2. NIST, „Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile”, NIST AI 600-1: nist.gov
3. Komisja Europejska, „AI Act”: digital-strategy.ec.europa.eu
4. Komisja Europejska, „Understanding the standardisation of the AI Act”: digital-strategy.ec.europa.eu
5. ENISA, „A good practice guide for a robust and resilient EU health sector”: enisa.europa.eu
6. Komisja Europejska, „Digital procurement”: single-market-economy.ec.europa.eu
7. European Medicines Agency, „European Shortages Monitoring Platform”: European Medicines Agency
8. Wniosek o dofinansowanie projektu Pharma Flow, FENG.01.01-IP.02-0638/25 — wewnętrzne źródło celów, harmonogramu, budżetu i planowanych funkcjonalności.

Artykuł opisuje cele i hipotezy projektu badawczo-rozwojowego znajdującego się na początku realizacji. Planowane funkcje i wskaźniki nie są wynikami osiągniętymi przez gotowy produkt. Tekst nie stanowi porady prawnej, zakupowej ani medycznej.