Archiwum EZAMOWIENIACPV 30000000 · Maszyny biurowe i komputeryCPV 79000000 · Usługi biznesowe i zarządzanie Podkarpackie KPO
Zakup, dostawa, wdrożenie i integracja systemu digitalizacji dokum. medycznej w ramach
Pełna nazwa postępowania: Zakup, dostawa, wdrożenie i integracja systemu digitalizacji dokum. medycznej w ramach rozwoju usług cyfrowych w ochronie zdrowia oraz zakup i wdrożenie systemów zwiększających cyberbezp. (PAM/DLP)
Centrum Opieki Medycznej·NIP 7921805707·Jarosław
Wartość szac.
—
nie podano
Termin składania
29.07.2026
postępowanie zakończone
Otwarcie ofert
—
nie podano
Opublikowano
21 lipca 2026
źródło: EZAMOWIENIA
Streszczenie SWZ
Streszczenie AI · Janusz
Widzisz połowę każdej z 10 sekcjiDruga połowa — łącznie 26 zdań z warunkami, dokumentami i analizą ryzyka — odsłania się po założeniu darmowego konta.
Przedmiot zamówienia: Zakup, dostawa, wdrożenie i integracja systemu digitalizacji dokumentacji medycznej oraz zakup i wdrożenie systemów zwiększających cyberbezpieczeństwo (PAM/DLP)
Tryb: Postępowanie w trybie podstawowym bez prowadzenia negocjacji na podstawie art. 275 pkt 1 PZP
Postępowanie prowadzone jest w trybie podstawowym bez prowadzenia negocjacji na podstawie art. 275 pkt 1 ustawy Prawo zamówień publicznych (PZP) w związku z art. 30 ust. 4 PZP. (+ 3 zdania — pełna treść po zalogowaniu)
Zamawiający nie podał w dokumentacji wartości szacunkowej zamówienia ani informacji o budżecie rocznym. Przedsięwzięcie realizowane jest w ramach Krajowego Planu Odbudowy i Zwiększenia Odporności, Inwestycja D1.1.2 „Przyspieszenie procesów transformacji cyfrowej ochrony zdrowia poprzez dalszy rozwój usług cyfrowych w ochronie zdrowia”, nr umowy KPOD.07.03-IP.10-0342/25/KPO/1002/2025/441. (+ 2 zdania — pełna treść po zalogowaniu)
Zamawiający określił następujące warunki udziału w postępowaniu w zakresie zdolności technicznej lub zawodowej:
Pakiet 1: Wykonawca musi wykazać, że w okresie ostatnich 3 lat przed upływem terminu składania ofert (a jeżeli okres prowadzenia działalności jest krótszy – w tym okresie) wykonał należycie:
co najmniej jedno zamówienie na dostarczenie systemu digitalizacji dokumentacji medycznej pacjenta wraz z możliwością tworzenia wersji papierowej i elektronicznej, zintegrowanego z HIS AMMS, o wartości nie mniejszej niż 200 000,00 zł brutto;
Podwykonawstwo: Wykonawca może powierzyć część zamówienia podwykonawcy, o ile nie jest to zastrzeżone do osobistego wykonania. Należy wskazać zakres prac i firmę podwykonawcy w formularzu ofertowym. Odpowiedzialność za należyte wykonanie zamówienia spoczywa na Wykonawcy.
Zmiany umowy: Zamawiający nie przewiduje skorzystania z opcji (art. 441 PZP) ani udzielania zaliczek.
Zasady środowiskowe (DNSH): Realizacja zamówienia musi być zgodna z zasadą "nieczynienia poważnych szkód dla celów środowiskowych" (DNSH).
Z każdej z 10 sekcji pokazujemy połowę. Załóż darmowe konto, żeby odsłonić pozostałe 26 zdań — pełne warunki udziału, dokumenty i analizę ryzyka Janusza. Bez karty, 14 dni za darmo.
14 dni za darmo Bez karty płatniczej Rezygnacja w 1 klik
Opis przedmiotu zamówienia
Streszczenie AI · Janusz
Część 1 (usługa/dostawa): wdrożenie systemu digitalizacji dokumentacji medycznej zintegrowanego z systemem HIS AMMS, obejmujące dostawę systemów do skanowania i cyfryzacji dokumentów.
Część 2 (dostawa i wdrożenie): systemy zwiększające cyberbezpieczeństwo klasy PAM (dla min. 5 użytkowników) oraz DLP (dla min. 500 użytkowników) wraz z 3-letnimi licencjami i serwisem.
Pytania i odpowiedzi
Wyjaśnienia treści SWZ udzielone przez zamawiającego. Odpowiedzi wiążą wszystkich wykonawców — także tych, którzy nie zadali pytania.
Czy Zamawiający w zakresie pkt 4 OPZ (dotyczącego wsparcia dla protokołów bez rejestracji sesji) dopuści rozwiązanie, które zapewnia natywne bezagentowe wsparcie dla kluczowych silników baz danych (MS SQL, MySQL, PostgreSQL), a dla pozostałych wymienionych systemów/relacyjnych baz danych realizuje bezagentowy dostęp za pośrednictwem dedykowanych integracji API lub publikowanych aplikacji zdalnych (np. RemoteApp / serwer pośredniczący)?
Wymaganie dotyczy zapewnienia w ramach oferowanego systemu pełnego, bez agentowego wsparcia dla wszystkich protokołów i technologii wskazanych w pkt 4 OPZ. OPZ nie narzuca wewnętrznego sposobu implementacji tej funkcjonalności. Wykonawca może zastosować własne mechanizmy techniczne, w tym integracje, o ile dla każdej z wymaganych technologii zapewnią one co najmniej taki sam zakres funkcjonalny, bezpieczeństwo, dostępność i obsługę poświadczeń jak rozwiązanie bezagentowe oraz nie spowodują konieczności zakupu dodatkowych licencji, wdrożenia dodatkowej infrastruktury ani ponoszenia przez Zamawiającego dodatkowych kosztów.
Samo wskazanie obsługi natywnej wyłącznie dla MS SQL, MySQL i PostgreSQL oraz niesprecyzowanych integracji API albo publikowanych aplikacji zdalnych dla pozostałych technologii nie potwierdza spełnienia pełnego wymagania. Każda technologia wymieniona w pkt 4 OPZ musi być obsługiwana i podlegać weryfikacji podczas odbioru. Treść pkt 4 OPZ pozostaje bez zmian.
Czy Zamawiający w odniesieniu do pkt 5d OPZ dopuści realizację dostępu dla klientów serwerów bazodanowych (w tym DBeaver) poprzez bezpieczne udostępnianie dedykowanej aplikacji w trybie zdalnym (RemoteApp) na serwerze pośredniczącym, co zapewnia pełne izolowanie sesji oraz ochronę poświadczeń?
Zamawiający nie uwzględnia wniosku jako zamiennika wymagania określonego w pkt 5 lit. d OPZ PAM i podtrzymuje wymóg dostępu z wykorzystaniem klienta serwerów bazodanowych, w tym co najmniej DBeaver.
Zamawiający wymaga zachowania możliwości korzystania z narzędzi klienckich funkcjonujących w jego środowisku bez uzależniania tej funkcjonalności od dodatkowego serwera RemoteApp/RDS, dodatkowych licencji, dodatkowej maszyny wirtualnej ani odrębnego punktu administracyjnego i awarii. Udostępnienie aplikacji w trybie zdalnym może stanowić funkcjonalność dodatkową oferowanego rozwiązania, ale nie może zastępować wymagania z pkt 5 lit. d OPZ ani powodować dodatkowych kosztów po stronie Zamawiającego. Treść pkt 5 lit. d OPZ pozostaje bez zmian.
Czy Zamawiający w zakresie pkt 7 OPZ dopuści dostarczenie komponentu Pośrednika w formie gotowej, dedykowanej maszyny wirtualnej (Virtual Appliance dla środowisk VMware / Hyper-V) lub urządzenia fizycznego, zamiast obrazu kontenera Docker, pod warunkiem zachowania pełnej funkcjonalności, wyskalowalności i braku konieczności instalacji agentów na urządzeniach docelowych?
Zamawiający nie uwzględnia wniosku o zastąpienie obrazu kontenera Docker dedykowaną maszyną wirtualną albo urządzeniem fizycznym i podtrzymuje wymaganie określone w pkt 7 OPZ PAM.
Podstawowa platforma systemu PAM ma zostać dostarczona jako zamknięta platforma wirtualna możliwa do wdrożenia w posiadanym przez Zamawiającego środowisku Hyper-V, zgodnie z częścią „Ogólne – architektura” OPZ. Odrębny wymóg z pkt 7 dotyczy sposobu udostępnienia komponentu Pośrednika. Obraz Docker jest wymagany ze względu na przenośność, powtarzalność wdrożenia, standaryzację aktualizacji i możliwość uruchomienia komponentu bez wprowadzania dodatkowego urządzenia fizycznego albo odrębnej, utrzymywanej przez Zamawiającego maszyny wirtualnej. Wykonawca może zapewnić środowisko uruchomieniowe zgodne z posiadaną infrastrukturą Hyper-V, jednak komponent Pośrednika musi zostać dostarczony również w postaci wymaganego obrazu Docker i spełniać wszystkie pozostałe wymagania OPZ. Treść pkt 7 OPZ pozostaje bez zmian.
Czy w pkt 32 OPZ Zamawiający dopuści rozwiązanie, w którym parametry nagrywania sesji (FPS, jakość klatek, format obrazu) są zoptymalizowane fabrycznie przez producenta w celu zagwarantowania maksymalnej wydajności i ciągłości rejestracji bez wpływu na systemy docelowe, przy jednoczesnym zapewnieniu pełnej możliwości konfiguracji okresu przechowywania nagrań przez administratora?
Zamawiający dopuszcza rozwiązanie, w którym parametry nagrywania sesji, tj. liczba klatek na sekundę, jakość klatek oraz format obrazu, są zoptymalizowane fabrycznie przez producenta, pod warunkiem zapewnienia pełnej możliwości konfiguracji okresu przechowywania nagrań przez administratora oraz zachowania pełnej funkcjonalności rejestrowania, przeszukiwania, odtwarzania i pobierania nagrań wymaganej w OPZ.
Czy Zamawiający dopuści rozwiązanie, w którym wsparcie dla systemu MacOS (wersja 12 i nowsze) zostanie dostarczone w ramach planowanej aktualizacji oprogramowania w I kwartale 2027 r., przy jednoczesnym zapewnieniu od dnia odbioru 100% funkcjonalności DLP dla środowisk Windows (Windows 10, Windows 11)?
Zamawiający podtrzymuje wymaganie określone w pkt 1 lit. c OPZ DLP. Pełne wsparcie dla macOS 12 lub nowszego musi być dostępne w oferowanej, produkcyjnej i wspieranej przez producenta wersji systemu najpóźniej w dniu odbioru.
Zamawiający nie może uznać za spełnienie wymagania funkcjonalności zapowiadanej dopiero na I kwartał 2027 r. Funkcja opisana wyłącznie w planie rozwoju producenta nie jest funkcją dostarczoną, możliwą do zweryfikowania i odebrania. Wymóg wynika z potrzeby objęcia jednolitą ochroną wszystkich wspieranych stacji roboczych Zamawiającego oraz z obowiązku odebrania kompletnego przedmiotu zamówienia w terminie wynikającym z dokumentacji postępowania i zasad finansowania KPO. Treść pkt 1 lit. c OPZ DLP pozostaje bez zmian.
Czy Zamawiający dopuści rozwiązanie, w którym Serwer Administracyjny DLP wykorzystuje wydajną bazę danych typu Open-Source (np. PostgreSQL), a funkcja analizy i ochrony danych wrażliwych (DLP) obejmuje również skanowanie oraz zabezpieczanie danych w zewnętrznych bazach MS SQL?
Zamawiający dopuszcza wykorzystanie przez Serwer Administracyjny DLP bazy PostgreSQL w aktualnej, stabilnej wersji oficjalnie wspieranej przez producenta oferowanego systemu, pod warunkiem zapewnienia pełnej funkcjonalności i wydajności systemu dla wymaganej liczby użytkowników, pełnego wsparcia producenta oraz braku dodatkowych kosztów licencyjnych po stronie Zamawiającego. Wszystkie pozostałe wymagania OPZ muszą zostać spełnione.
Czy Zamawiający w odniesieniu do pkt 8 OPZ dopuści rozwiązanie, które w trybie braku połączenia klienta z serwerem zarządzającym egzekwuje polityki i reguły DLP lokalnie na znanych i przetworzonych plikach, a logi z zebranych zdarzeń buforuje na stacji roboczej do czasu przywrócenia łączności?
Zamawiający podtrzymuje wymaganie określone w pkt 8 OPZ DLP. Przy braku łączności klienta z serwerem zarządzającym wszystkie aktywne polityki i reguły DLP przypisane do danego użytkownika lub urządzenia muszą być egzekwowane lokalnie, również wobec plików nowych, skopiowanych, zmienionych albo wcześniej nieprzetworzonych.
Ograniczenie ochrony offline wyłącznie do „znanych i przetworzonych plików” pozostawiałoby poza kontrolą nowe dane powstające lub pojawiające się na stacji w czasie braku łączności, co nie zapewnia ciągłości ochrony wymaganej przez Zamawiającego. Lokalne buforowanie logów do czasu przywrócenia łączności jest dopuszczalne i odpowiada pkt 9 OPZ, ale nie może ograniczać zakresu egzekwowanych polityk. Treść pkt 8 OPZ DLP pozostaje bez zmian.
Czy Zamawiający w pkt 27 OPZ dopuści rozwiązanie, które realizuje pełny zakres reguł DLP (blokowanie/zezwalanie na zapisywanie, przenoszenie, wysyłkę e-mail, udostępnianie w chmurze i komunikatorach), lecz w zakresie operacji drukowania zapewnia pełne audytowanie i raportowanie zdarzeń bez możliwości twardego blokowania wydruku na poziomie agenta?
Zamawiający podtrzymuje wymaganie określone w pkt 27 OPZ DLP. System musi umożliwiać zarówno zezwalanie, jak i blokowanie operacji drukowania dla plików skategoryzowanych, stosownie do skonfigurowanej reguły DLP.
Samo audytowanie i raportowanie wydruków nie zapobiega ujawnieniu lub nieuprawnionemu wyniesieniu danych, w tym danych medycznych i danych osobowych szczególnych kategorii. Możliwość prewencyjnego zablokowania wydruku jest zatem wymaganą funkcją ochronną, a nie wyłącznie funkcją raportową. Treść pkt 27 OPZ DLP pozostaje bez zmian.
Czy Zamawiający w odniesieniu do pkt 32 OPZ potwierdza, że spełnieniem wymogu odnośnie do możliwości zmiany domyślnego serwera SMTP jest opcja modyfikacji odpowiednich wpisów konfiguracyjnych bezpośrednio w pliku konfiguracyjnym serwera przez uprawnionego administratora?
Zamawiający podtrzymuje wymaganie określone w pkt 32 OPZ DLP. Zmiana domyślnego serwera SMTP musi być możliwa z poziomu konsoli administracyjnej.
Ręczna zmiana pliku konfiguracyjnego na serwerze może stanowić dodatkowy techniczny sposób konfiguracji, lecz nie spełnia wymagania dostępu przez konsolę. Wymóg konsoli ogranicza konieczność przyznawania administratorom DLP uprawnień do systemu plików serwera, zmniejsza ryzyko błędów konfiguracyjnych i zapewnia spójny, wspierany przez producenta sposób administracji. Treść pkt 32 OPZ DLP pozostaje bez zmian.
Czy Zamawiający w pkt 33 OPZ dopuści rozwiązanie, w którym konsola webowa służy do weryfikacji wersji oraz dezaktywacji oprogramowania klienta, natomiast dystrybucja i instalacja aktualizacji agenta odbywa się automatycznie za pomocą systemów centralnych (np. reguł Active Directory / GPO / SCCM/MECM)?
Zamawiający podtrzymuje wymaganie określone w pkt 33 OPZ DLP. Konsola webowa systemu musi umożliwiać nie tylko weryfikację wersji i dezaktywację oprogramowania klienta, lecz również jego aktualizację do nowej wersji.
Narzędzia zewnętrzne, takie jak GPO albo SCCM/MECM, mogą być wykorzystywane dodatkowo, jeżeli oferowane rozwiązanie je obsługuje. Nie mogą jednak zastępować funkcji aktualizacji dostępnej w ramach dostarczanego systemu, ponieważ prowadziłoby to do uzależnienia kompletności rozwiązania od infrastruktury i licencji niewchodzących w zakres zamówienia. Treść pkt 33 OPZ DLP pozostaje bez zmian.
Czy Zamawiający wyrazi zgodę na wydłużenie terminu dostarczenia/udostępnienia funkcjonalności opisanych w pkt 40 (tryb standardowy/łagodny dla polityk dynamicznych) oraz pkt 42 (cykliczne raporty podsumowujące z rekomendacjami) do 3 miesięcy od momentu produkcyjnego wdrożenia systemu?
Zamawiający podtrzymuje wymagania określone w pkt 40 i 42 OPZ DLP. Funkcjonalności te muszą być dostępne w produkcyjnej, oficjalnie wspieranej przez producenta wersji oferowanego systemu najpóźniej w dniu odbioru.
Nie dopuszcza się dostarczenia tych funkcjonalności w terminie do trzech miesięcy po produkcyjnym wdrożeniu systemu. Odroczenie oznaczałoby odbiór niekompletnego przedmiotu zamówienia, brak możliwości weryfikacji wszystkich wymaganych funkcji przy odbiorze oraz ryzyko dla terminowej realizacji i rozliczenia przedsięwzięcia finansowanego z KPO. Prace konfiguracyjne, testowe i szkoleniowe mogą być prowadzone zgodnie z harmonogramem realizacji, ale nie zmienia to obowiązku zapewnienia wszystkich funkcji przed odbiorem. Treść pkt 40 i 42 OPZ DLP pozostaje bez zmian.
Czy Zamawiający dopuści rozwiązanie, które w ramach pkt 43 i 44 zbiera informacje, klasyfikuje oraz nakłada indywidualne polityki dostępu dla ścieżek sieciowych, lokalnych oraz podłączanych pamięci USB, z wyłączeniem rejestrowania i nakładania polityk na fizyczne drukarki sieciowe/lokalne?
Zamawiający podtrzymuje wymagania określone w pkt 43 i 44 OPZ DLP. System musi zbierać informacje również o drukarkach lokalnych i sieciowych oraz umożliwiać objęcie ich zasadami przewidzianymi w tych punktach.
Druk stanowi istotny kanał przetwarzania i możliwego nieuprawnionego ujawnienia danych medycznych oraz innych danych chronionych. Wyłączenie drukarek powodowałoby powstanie luki pomiędzy kategoryzacją danych, regułami dotyczącymi drukowania z pkt 27 OPZ oraz kontrolą miejsc docelowych z pkt 43 i 44 OPZ. Treść pkt 43 i 44 OPZ DLP pozostaje bez zmian.
