Automatyzacja i Zarządzanie Ryzykiem Raportowania ZSMOPL w Firmach Farmaceutycznych (Microsoft Dynamics i Hogart Data Transformation Platform)

Sekcja 1: Zintegrowany System Monitorowania Obrotu Produktami Leczniczymi (ZSMOPL) – Wprowadzenie i Kontekst Compliance

1.1. Definicja i Rola Systemu ZSMOPL

Zintegrowany System Monitorowania Obrotu Produktami Leczniczymi (ZSMOPL) stanowi fundamentalne narzędzie kontroli w polskim prawie farmaceutycznym, którego wprowadzenie do obiegu danych obowiązywało od 1 kwietnia 2019 roku. System ten został ustanowiony w celu zwiększenia przejrzystości i kontroli nad łańcuchem dostaw produktów leczniczych, aby zapobiegać ich nielegalnemu wywozowi lub dystrybucji.

ZSMOPL ma za zadanie wspomóc kluczowe organy administracji publicznej w Polsce, w tym Departament Polityki Lekowej i Farmacji Ministerstwa Zdrowia (MZ), Główny Inspektorat Farmaceutyczny (GIF), Wojewódzkie Inspektoraty Farmaceutyczne (WIF) oraz Urząd Rejestracji Produktów Leczniczych, Wyrobów Medycznych i Produktów Biobójczych (URPL). Wymienione podmioty wykorzystują zgromadzone dane do strategicznej analizy wielkości obrotu oraz struktury tego obrotu. Integralność i terminowość przekazywanych komunikatów są zatem krytyczne, ponieważ wszelkie błędy lub braki w raportowaniu są traktowane jako poważne naruszenia regulacyjne, niosące ryzyko sankcji prawnych i finansowych. Konieczność dokładnego i terminowego raportowania uzasadnia inwestycję w zaawansowane mechanizmy walidacyjne i audytowe, które minimalizują ryzyko nieświadomego wysłania nieprawidłowych danych do organów państwowych.

1.2. Identyfikacja Podmiotów i Granularność Raportowania

Obowiązek przekazywania komunikatów do ZSMOPL dotyczy szerokiego spektrum podmiotów prowadzących obrót produktami leczniczymi. Wśród podmiotów zobowiązanych do raportowania znajdują się przedsiębiorcy prowadzący działalność polegającą na prowadzeniu hurtowni farmaceutycznej, podmioty odpowiedzialne (MAH), apteki oraz działy farmacji szpitalnej.

Kluczową cechą raportowania w Polsce jest wymóg lokalizacyjny. W przypadku aptek i hurtowni farmaceutycznych, dane nie są raportowane wyłącznie na poziomie podmiotu gospodarczego, lecz z poziomu konkretnego Miejsca Prowadzenia Działalności (MPD). Ten wymóg szczegółowej granularności danych zwiększa złożoność techniczną procesu ekstrakcji i wymaga precyzyjnego mapowania transakcji w systemach źródłowych ERP.

Sekcja 2: Architektura Rozwiązania Automatyzującego ZSMOPL – Model Dwupoziomowy

2.1. Architektura Systemowa: System Źródłowy ERP vs. Compliance Middleware

Zaprojektowanie efektywnego i odpornego na zmiany systemu raportowania ZSMOPL wymaga przyjęcia architektury dwupoziomowej, separującej stabilny system transakcyjny od dynamicznie zmieniającej się logiki regulacyjnej.

System ERP, taki jak Microsoft Dynamics (Business Central – BC, lub starsze wersje, np. Navision), pełni rolę podstawowego repozytorium danych transakcyjnych i Master Data. Natomiast Platforma wymiany Danych Hogart  funkcjonuje jako niezbędny middleware (warstwa pośrednicząca), koncentrując w sobie całą logikę związaną z compliance i transmisją.

Zadaniem  jest zarządzanie kompleksowym procesem wymiany danych, w tym konwersją formatu, walidacją, obsługą protokołów bezpieczeństwa (certyfikaty) i finalną komunikacją z bramką ministerialną Ministerstwa Zdrowia. Takie rozdzielenie ról minimalizuje potrzebę ciągłego modyfikowania kodu źródłowego stabilnego korporacyjnego systemu ERP. Ma to kluczowe znaczenie w środowiskach farmaceutycznych, gdzie utrzymanie stabilności systemów jest priorytetem, a dynamiczne zmiany prawne, takie jak wprowadzanie nowych schem XML ZSMOPL, są absorbowane wyłącznie na poziomie middleware. Ta izolacja ryzyka regulacyjnego zapewnia ciągłość operacyjną.

2.2. Skalowalność Korporacyjna i Integracja Heterogeniczna

Platforma wymiany Danych Hogart została zaprojektowana z myślą o dużych korporacjach i strukturach wielopodmiotowych (wielo-oddziałowych). Platforma wymiany Danych Hogart umożliwia centralne raportowanie dla wielu podmiotów – niezależnie od tego, czy są to hurtownie, apteki czy podmioty odpowiedzialne (MAH) – z poziomu jednego scentralizowanego rozwiązania.

Kolejną zaletą tej architektury jest jej agnostyczność wobec systemów ERP. Platforma wymiany Danych Hogart nie ogranicza się wyłącznie do współpracy z ekosystemem Microsoft Dynamics (Navision/BC). Choć w sektorze farmaceutycznym dominują systemy jak SAP, Platforma wymiany Danych Hogart zapewnia możliwości integracji z innymi popularnymi systemami korporacyjnymi, takimi jak SAP, Oracle czy IFS, co jest niezbędne dla globalnych grup kapitałowych. System umożliwia pobieranie danych z różnych źródeł za pomocą elastycznych mechanizmów, w tym API, procedur składowanych do określonego systemu ERP, czy też za pomocą bardziej tradycyjnych metod, jak pliki płaskie lub dane wyeksportowane do Excela.

2.3. Funkcje Centralne Platformy wymiany Danych Hogart w Zarządzaniu Transmisją

Zarządzanie dużą skalą danych i komunikacją z infrastrukturą ministerialną wymaga zaawansowanych funkcji po stronie middleware. Platforma wymiany Danych Hogart pełni rolę centrum zarządzania transmisją. Po odebraniu danych źródłowych system jest odpowiedzialny za ich konwersję do prawidłowej schemy pliku XML, zgodnej z aktualnymi wymogami Ministerstwa Zdrowia.

Ponadto, w kontekście transmisji, Platforma wymiany Danych Hogart odpowiada za obsługę certyfikatów i tokenów niezbędnych do bezpiecznej autoryzacji. Krytycznym elementem jest również mechanizm priorytetyzacji wysyłek oraz dzielenia dużych paczek danych na mniejsze części. Ta funkcja ma na celu optymalizację transmisji i unikanie problemów związanych z przepustowością portali ministerialnych, które historycznie występowały w Polsce, na przykład w przypadku dużych plików JPK czy KSeF.

Sekcja 3: Etap I: Prekonfiguracja i Ekstrakcja Danych Źródłowych w Systemach Microsoft Dynamics

3.1. Adaptacja i Mapowanie Słownikowe (Customizacja Atteli)

Skuteczność procesu raportowania rozpoczyna się od precyzyjnego przygotowania danych w systemie źródłowym. Dzięki współpracy z partnerami IT, takimi jak firma Atteli, Microsoft Dynamics Business Central/Navision jest dostosowywany do wymogów lokalizacyjnych w ramach specjalnej prekonfiguracji.

Kluczowym elementem tej adaptacji jest mapowanie słownikowe. Rodzaje dokumentów transakcyjnych oraz klasyfikacja podmiotów (np. odbiorców i dostawców) muszą zostać zdefiniowane i zasłownikowane bezpośrednio w systemie ERP, aby były natychmiast zgodne z wymogami Ministerstwa Zdrowia. Takie zdefiniowanie słowników u źródła gwarantuje, że dane wysyłane do Platforma wymiany Danych Hogart są już wstępnie strukturyzowane pod kątem regulacyjnym.

3.2. Selekcja Danych i Wymogi Granularności

Proces ekstrakcji danych ZSMOPL musi być wysoce selektywny. Raportowaniu podlegają wyłącznie produkty lecznicze i licencjonowane. Zgodnie z przepisami, z raportowania wyłączone są produkty pośrednie luzem, materiały wyjściowe czy opakowaniowe. Odfiltrowanie tych pozycji jest niezbędne dla optymalizacji wydajności i zmniejszenia wolumenu danych przesyłanych do dalszego przetwarzania.

Raportowane dane muszą charakteryzować się wysoką granularnością – są one zbierane z dokładnością do serii producenta. Oznacza to, że pojedyncza faktura lub ruch magazynowy może generować wiele wierszy raportowych, jeśli dotyczy różnych serii. W tym kontekście, kluczową informacją, która musi być poprawnie utrzymana w Master Data, jest data ważności serii. Jej brak lub nieprawidłowość jest automatycznie wykrywany jako błąd krytyczny. Demonstracja tego błędu (braku daty ważności) uwypukla fakt, że system automatyzacji ZSMOPL pełni funkcję krytycznego weryfikatora integralności danych GxP, wymuszając wysoką jakość Master Data w systemie źródłowym.

3.3. Automatyzacja Procesu Ekstrakcji

W celu zapewnienia terminowego i cyklicznego raportowania (często w trybie dziennym) wykorzystywany jest dedykowany mechanizm w systemie ERP. W BC/Navision zaimplementowany jest raport, który umożliwia szybkie pobranie wierszy transakcyjnych do dedykowanej tabeli wysyłkowej.

Proces ekstrakcji jest w pełni automatyzowany. Wykorzystuje się standardową funkcjonalność kolejki zleceń (job queue) w Microsoft Dynamics, która jest ustawiana na automatyczne uruchamianie, zazwyczaj w godzinach nocnych (np. o północy). Umożliwia to procesowanie dużych wolumenów danych poza godzinami szczytu operacyjnego. Jednocześnie, w fazie wdrożenia i testów, system zachowuje możliwość ręcznej ekstrakcji i wysyłki wybranych wierszy, co jest niezbędne do weryfikacji poprawności działania procesu.

Sekcja 4: Etap II: Przetwarzanie, Walidacja i Zarządzanie Błędami na Platformie wymiany Danych Hogart

4.1. Przepływ Danych i Wstępna Weryfikacja w Platforma wymiany Danych Hogart

Po przesłaniu z systemu ERP, pakiety danych lądują w Platforma wymiany Danych Hogart w buforze oznaczonym jako „robocze”. Proces weryfikacji i walidacji rozpoczyna się automatycznie już na etapie ładowania danych, sprawdzając ich zgodność ze schemą i regułami ZSMOPL.

Wizualizacja w systemie Platforma wymiany Danych Hogart ułatwia identyfikację nieprawidłowości. Pakiety danych zawierające błędy są natychmiast oznaczane wyraźnym komunikatem wizualnym. Operator systemu może użyć funkcji podglądu, aby zidentyfikować, gdzie dokładnie występuje błąd – czy jest to problem w danych nagłówkowych, czy, jak w przykładzie celowo wprowadzonym w prezentacji, brak daty ważności serii w szczegółach transakcji. Szybka identyfikacja problemu jest kluczowa dla dotrzymania dziennych terminów raportowania.

4.2. Dualistyczna Strategia Korekty Danych

Architektura Platforma wymiany Danych Hogart przewiduje dwie ścieżki postępowania w przypadku zidentyfikowania błędów krytycznych, co świadczy o dojrzałości systemu w kontekście zarządzania ciągłością działania (Compliance BCP):

1. Ścieżka I (Preferowana i Audytowana): Korekta w Systemie Źródłowym. Standardową procedurą jest powrót do systemu ERP (Navision/BC), skorygowanie Master Data (np. uzupełnienie brakującej daty ważności serii), usunięcie błędnej paczki z bufora Platforma wymiany Danych Hogart, a następnie ponowne uruchomienie procesu ekstrakcji danych. Ta metoda utrzymuje integralność danych w całym łańcuchu.
2. Ścieżka II (Awaryjna i Kontrolowana): Bezpośrednia Edycja w Platforma wymiany Danych Hogart. W sytuacjach krytycznych, gdy poprawa danych w ERP jest niemożliwa ze względu na bariery czasowe, różnice w strefach czasowych w korporacjach międzynarodowych, czy brak dostępów, system umożliwia bezpośrednią edycję danych transakcyjnych w aplikacji Platforma wymiany Danych Hogart. Funkcja ta pozwala na szybką interwencję, na przykład w celu uzupełnienia daty ważności serii, co jest kluczowe, aby uniknąć braku raportowania i wynikających z tego sankcji prawnych. Aby ta ścieżka była zgodna z wymogami GxP, jest ona ściśle powiązana z mechanizmem audytu zmian, który jest omawiany w Sekcji 5.

Podział Ról Funkcjonalnych w Procesie ZSMOPL (ERP vs. Platforma wymiany Danych Hogart)

Sekcja 5: Etap III: Zapewnienie Audytowalności i Kontroli Zmian

5.1. Mechanizm Audytu Zmian (Audit Log)

W regulowanym środowisku farmaceutycznym (GxP), każda ręczna interwencja w dane transakcyjne musi być w pełni udokumentowana i audytowalna. W tym celu Platforma wymiany Danych Hogart posiada wbudowany, rygorystyczny mechanizm Audytu Zmian.

Funkcja ta rejestruje wszystkie manualne korekty wprowadzone bezpośrednio na platformie. Rejestracja jest wysoce szczegółowa, obejmując informacje o użytkowniku, czasie dokonania zmiany, rekordzie, a przede wszystkim o pierwotnej wartości i wartości zmienionej (np. zmiana daty ważności serii z wartości Null na 2 października). Ten szczegółowy log zmian jest niezbędny, aby manualna edycja awaryjna w Platforma wymiany Danych Hogart mogła być uznana za zgodną z wymogami regulacyjnymi. Możliwość wygenerowania raportu z tych zmian zapewnia pełną transparentność i umożliwia uzasadnienie każdej modyfikacji danych transakcyjnych przed organami kontrolnymi.

5.2. Kontrola Dostępu Poprzez Role Użytkowników

W celu zachowania zasady separacji obowiązków, dostęp do krytycznych funkcji Platforma wymiany Danych Hogart, w szczególności do opcji bezpośredniej edycji danych, jest ściśle kontrolowany poprzez zaawansowany system ról i uprawnień.

Definicja uprawnień pozwala administratorowi systemu odebrać możliwość edycji danych użytkownikom operacyjnym, przyznając ją wyłącznie ściśle wyznaczonym osobom z działów Compliance lub administracyjnych. System jest w pełni konfigurowalny i oparty na decyzjach projektowych. Umożliwia to zapewnienie, że pracownicy operacyjni mogą jedynie przeglądać statusy i dane, podczas gdy administratorzy mają kontrolę nad bezpośrednią korektą, gwarantując, że nawet awaryjne interwencje są dokonywane pod pełną kontrolą odpowiedzialnych za compliance.

5.3. Wersjonowanie Komunikatów i Dostosowanie Regulacyjne

Polskie prawo farmaceutyczne, podobnie jak inne regulacje (np. KSeF), charakteryzuje się dynamicznymi zmianami w wymaganych strukturach danych. Aby zagwarantować ciągłą zgodność, Platforma wymiany Danych Hogart zarządza wersjonowaniem komunikatów.

System przechowuje i kontroluje różne wersje schem XML dla poszczególnych typów komunikatów ZSMOPL, takich jak raporty obrotów i stanów. Dzięki temu mechanizmowi, Platforma wymiany Danych Hogart dynamicznie dobiera właściwą strukturę XML w zależności od bieżących wymogów ministerialnych i okresu sprawozdawczego, z którego pochodzą dane. Ta funkcjonalność, wspierana przez ciągłe aktualizacje maintenance, minimalizuje obciążenie wewnętrznych zespołów IT związane z dynamiczną adaptacją do zmian regulacyjnych.

Sekcja 6: Faza Końcowa: Wysyłka, Potwierdzenie i Zamknięcie Obiegu Transakcji

6.1. Akceptacja i Przygotowanie do Wysyłki

Po przejściu pomyślnej walidacji i ewentualnych korektach, paczka danych jest akceptowana przez użytkownika lub system. Akceptacja oznacza, że dane są konwertowane do finalnego, zgodnego formatu pliku XML. Następnie pakiet jest przenoszony do bufora wysyłkowego, zwanego statusem „przygotowane do wysyłki”.

Ten bufor pełni funkcję poczekalni. W trybie w pełni zautomatyzowanym (typowym dla dużych korporacji), wysyłka z tego bufora następuje automatycznie po krótkim, zdefiniowanym czasie (np. 15 minut). W trybie testowym lub na życzenie klienta, transmisja może być również inicjowana ręcznie, co zapewnia kontrolę nad momentem przekazania danych.

6.2. Proces Transmisji i Odbiór Potwierdzenia

Faza transmisji danych wymaga użycia mechanizmów bezpieczeństwa. System Platforma wymiany Danych Hogart automatycznie pobiera certyfikat kwalifikowany, niezbędny do autoryzacji i bezpiecznego podpisania pakietu danych, a następnie przesyła plik do bramki Ministerstwa Zdrowia (na środowisko testowe lub produkcyjne).

Po pomyślnej transmisji, system niezwłocznie oczekuje na informację zwrotną od strony ministerialnej. Kluczowe jest uzyskanie Urzędowego Potwierdzenia Odbioru (UPO) oraz wygenerowanie unikalnego Identyfikatora ZSMOPL dla przesłanego dokumentu.

6.3. Pętla Zwrotna i Archiwizacja Compliance

Kluczowym wyróżnikiem dojrzałego rozwiązania compliance jest automatyczne zamknięcie pętli transakcyjnej. Samo wysłanie danych do Platforma wymiany Danych Hogart, a nawet do bramki MZ, nie stanowi pełnego raportowania. Dopiero uzyskanie identyfikatora ZSMOPL potwierdza skuteczność rejestracji.

W ramach integracji Hogart-Atteli, otrzymany unikalny Identyfikator ZSMOPL jest automatycznie przesyłany z powrotem i zapisywany w systemie źródłowym (Navision/Business Central). Identyfikator ten jest przypisywany do konkretnych transakcji (ruchów magazynowych, sprzedaży, zakupu), stanowiąc w systemie ERP niepodważalny dowód, że dany obrót został prawidłowo zarejestrowany na portalu Ministerstwa Zdrowia. Jeśli transakcja w ERP nie ma przypisanego ID ZSMOPL, stanowi to otwarte ryzyko regulacyjne.

Wszystkie paczki danych, statusy, UPO i finalne identyfikatory ZSMOPL są archiwizowane w systemie Platforma wymiany Danych Hogart. To archiwum zapewnia możliwość podglądu i weryfikacji danych, co jest fundamentalne w przypadku wewnętrznych audytów, kontroli zewnętrznych lub sporów prawnych.

Sekcja 7: Podsumowanie Architektoniczne i Korzyści Operacyjne

7.1. Centralizacja i Efektywność Zarządzania Compliance

Wdrożenie Platforma wymiany Danych Hogart jako warstwy pośredniczącej przynosi znaczące korzyści operacyjne i strategiczne. Platforma wymiany Danych Hogart służy jako pojedyncze, zunifikowane centrum kontroli dla wielu regulacji prawno-informatycznych w Polsce. Oprócz ZSMOPL, platforma obsługuje inne krytyczne procesy, takie jak Krajowy System e-Faktur (KSeF), Jednolity Plik Kontrolny (JPK), a także ewidencje akcyzowe (np. CEWA).

Unifikacja interfejsu i logiki compliance na jednej platformie minimalizuje potrzebę szkolenia użytkowników w różnych środowiskach i znacząco obniża złożoność utrzymania wielu rozwiązań. Możliwość podłączenia systemów Navision/BC oraz innych systemów ERP (SAP, Oracle) do jednej platformy ułatwia zarządzanie zgodnością w scentralizowanych, międzynarodowych grupach kapitałowych.

7.2. Optymalizacja Kosztów Utrzymania i Ryzyka

Model architektury dwupoziomowej jest optymalny dla korporacji farmaceutycznych, ponieważ separuje złożoną i zmienną logikę regulacyjną od krytycznej, ale stabilnej logiki biznesowej ERP. Preintegracja rozwiązania Hogart z customizacją Atteli dla Microsoft Dynamics (Navision/BC) znacząco przyspiesza implementację i redukuje koszty dostosowania kluczowego systemu źródłowego.

Ponadto, usługa maintenance i ciągłe śledzenie zmian regulacyjnych (wersje schem XML) przez dostawcę rozwiązania oznacza przejęcie znacznej części ryzyka IT związanego z dynamiczną regulacją. W przypadku wystąpienia niestabilności systemów zewnętrznych, takich jak ministerialne portale (co miało miejsce w przypadku KSeF), Platforma wymiany Danych Hogart pełni funkcję bufora. Mechanizmy, takie jak dzielenie paczek danych i priorytetyzacja wysyłek, zwiększają odporność procesu na awarie i zapewniają terminowość raportowania nawet w trudnych warunkach infrastrukturalnych.