Załącznik nr 3a do SIWZ – Pakiet 4

I. System Zarządzania Procesami Szpitala (SZPS) – wymagania funkcjonalne

Zamówienie obejmuje dostarczenie i wdrożenie Systemu Zarządzania Procesami Szpitala składającego się z oprogramowania zintegrowanego z systemami wewnętrznymi będącymi w posiadaniu Zamawiającego umożliwiając tym samym automatyczną dwukierunkową wymianę danych oraz objęcie gwarancją i nadzorem autorskim zakupionego systemu przez okres 36 miesięcy.

Wdrożony system powinien umożliwiać optymalizację kluczowych procesów zachodzących w Szpitalu w szczególności w zakresie korespondencji wpływającej oraz korespondencji wewnętrznej miedzy innymi w zakresie:, zamówień wewnętrznych, zapotrzebowań, zleceń oraz obsługi faktur zakupowych (wersja tradycyjna – papierowa i elektroniczna) skracając tym samym czas związany z wymianą dokumentów oraz powoduje ograniczenie fizycznego kontaktu pracowników szpitala.

Lokalizacja Szpitala: Wojewódzki Szpital Obserwacyjno-Zakaźny im. T. Browicza w Bydgoszczy, ul. Św. Floriana 12, 85-030 Bydgoszcz.

Licencje:

W ramach realizacji Zamówienia wykonawca dostarczy licencję na SZPS umożliwiającą pracę minimum. 20 użytkownikom jednocześnie.

Zamawiający wymaga dostarczenia licencji bezterminowych na każdy z elementów oferowanego systemu informatycznego, tzn. wszystkie funkcjonalności systemu muszą być dostępne przez cały okres użytkowania systemu przez Zamawiającego, także w przypadku wygaśnięcia umów gwarancyjnych i serwisowych,

wskazana liczba jako ilość licencji określa ilość użytkowników jednocześnie zalogowanych w systemie.

Integracja z systemami posiadanymi przez Zamawiającego

Warunki organizacyjne przeprowadzonej integracji:

1. Zamawiający oświadcza, iż zgodnie z wiążącą go umową licencyjną z twórcami posiadanych systemów informatycznych, nie jest w posiadaniu kodów źródłowych modułów tych systemów,

2. Uzyskanie opisów interfejsów lub innych sposobów wymiany danych do integracji z wymienionymi w SIWZ systemami i/lub wykonanie integracji zgodnie z art. 75 ust. 2 pkt 3) Ustawy o prawie autorskim i prawach pokrewnych leży po stronie Wykonawcy,

3. Zamawiający nie przewiduje pośredniczenia w rozmowach z firmami trzecimi dotyczących integracji z ich systemami. Zamawiający wyjaśnia, że koszty integracji są częścią kosztu oferty składanej przez Wykonawcę w niniejszym postępowaniu.

4. Wykonawca zobowiązany jest uwzględnić w ofercie pełny koszt wykonania integracji uwzględniający również, o ile będzie to konieczne, wykonanie modyfikacji interfejsów wymiany danych posiadanych systemów oraz zakup niezbędnych do integracji licencji.

5. Zamawiający dopuszcza na podstawie art.75 ust. 2 pkt 3 ustawy o prawie autorskim i prawach pokrewnych dokonanie przez Wykonawcę dekompilacji modułów systemów, dotychczas wykorzystywanych przez Zamawiającego, poprzez zwielokrotnienie kodu lub tłumaczenie jego formy w rozumieniu art.74 ust.4 pkt 1 i 2 ustawy Prawo autorskie (Dz.U. 2006, nr 90, poz.631), jeżeli będzie to niezbędne do uzyskania informacji koniecznych do osiągnięcia współdziałania modułów tych systemów z systemem dostarczonym w ramach realizacji zamówienia. Wykonawca będzie zobowiązany wykonać czynności dekompilacyjne na własny koszt i ryzyko, w pełnym koniecznym zakresie z zastrzeżeniem, że czynności te będą odnosiły się tylko do tych części modułów tych systemów, które będą niezbędne do osiągnięcia współdziałania tych modułów z systemami dostarczonymi przez Wykonawcę, a uzyskane informacje nie będą:

a. wykorzystane do innych celów niż osiągnięcie współdziałania niezależnie stworzonego programu komputerowego;

b. przekazane innym osobom, chyba że jest to niezbędne do osiągnięcia współdziałania niezależnie stworzonego programu komputerowego.

c. wykorzystane do rozwijania, wytwarzania lub wprowadzania do obrotu programu komputerowego o istotnie podobnej formie wyrażenia lub do innych czynności naruszających prawa autorskie.

6. Informacje uzyskane przez Wykonawcę w toku wykonania czynności, o których mowa w art.75 ust.2 pkt 3 ustawy o prawie autorskim i prawach pokrewnych stanowią tajemnicę przedsiębiorstwa, w rozumieniu Ustawy o zwalczaniu nieuczciwej konkurencji z dnia 16 kwietnia 1993 r. i podlegają ochronie w niej przewidzianej.

Zamawiający poniżej przedstawił wykaz oczekiwanych funkcji Oprogramowania Aplikacyjnego. Przedstawione wymagania posegregowane są wg. grup funkcjonalnych (Modułów). Zamawiający dopuszcza, aby poszczególne funkcje były realizowane w innych modułach niż przypisano poniżej pod warunkiem dostarczenia wymaganej ilości licencji modułów w których występuje dana funkcja.

Minimalne wymagania funkcjonalne Systemu Zarządzania Procesami Szpitala (SZPS):

Wymagania ogólne systemu SZPS

1. Oprogramowanie musi w całości posiadać polskojęzyczny interfejs i instrukcję obsługi w języku polskim.

2.Oprogramowanie musi przechowywać wszystkie dane w postaci bazy danych. Dopuszcza się przechowywanie poza bazą danych plików w postaci repozytorium dyskowego. Ich integralność z systemem musi być zapewniona przez metadane opisujące poszczególne pliki

3.

System ma być zbudowany w architekturze trójwarstwowej, złożonej z:a) kodu generowanego do interpretacji przez przeglądarkę internetową,b) serwera aplikacji (pośredniczącego między żądaniami programu klienckiego, a motorem

bazy danych), motoru bazy danych, zarządzającego SQL-ową bazą danych

4. Oprogramowanie musi działać w środowiskach systemowych bazujących na systemach operacyjnych dostarczanych wraz ze sprzętem niezbędnym do uruchomienia SZPS

5. Oprogramowanie może działać w oparciu o przeglądarkę internetową, co najmniej Mozilla Firefox, Google Chrome, Opera w najnowszych wersjach

6. System musi cechować się interfejsem użytkownika opartym na nowoczesnych rozwiązaniach: wykorzystywać menu, listy, formularze, przyciski, referencje (linki), kafelki itp.

7. Interfejs użytkownika Systemu stosuje oznaczenia pól wymaganych na formularzu ekranowym w sposób wyróżniający te pola, a w przypadku ich błędnego wypełnienia jednoznacznie wskazywał

na pola błędnie wypełnione.

8.System musi być w pełni skalowalny. Skalowalność ma występować pod kątem zwiększania się ilości danych, jak i zmian funkcjonalności wynikających ze zmian prawnych i warunków praktycznych.

9.System musi posiadać widok indywidualny. Użytkownik ma wgląd tylko do modułów, do których posiada uprawnienia. Użytkownik powinni mieć możliwość zastosowania na ekranie głównym aplikacji skrótów najczęściej wykorzystywanych funkcjonalności systemu.

10.

System musi posiadać pomoc kontekstową, umożliwiającą:a) wyświetlanie zdefiniowanych okien z pomocnymi informacjami dotyczącymi

najważniejszych obszarów systemu. b) edycję zawartości pomocy zawartości okna pomocy przez uprawnionych użytkowników,c) powinna istnieć możliwość edytowania jej zawartości bezpośrednio z miejsca systemu, w

którym jest wyświetlana lub z poziomu dedykowanego rejestru dostępnych okien pomocy.

d) pomoc kontekstowa powinna być definiowana za pomocą edytorze WYSWIG umożliwiającym estetyczne formatowanie prowadzonej treści jak i wstawiania obrazów, hiperłączy lub popup.

11.

System musi zapewniać udostępnienie danych innym systemom w formie i zakresie ustalonym w trakcie wdrożenia, w sposób automatyczny lub na żądanie operatora w określonym czasie, wykorzystując jeden ze standardowych formatów wymiany danych m.in. csv, xml, txt, xls, rtf, html. Format powinien być zgodny z wymaganiami rozporządzenia Rady Ministrów z dn. 12 kwietnia 2012 o Krajowych Ramach Interoperacyjności. Udostępnienie danych dotyczy etapu wdrożenia.

12. System powinien posiadać funkcje współpracy na stanowiskach klientów z popularnymi programami biurowymi m.in. eksport danych do arkuszy kalkulacyjnych MS

13. Oprogramowanie posiada możliwość pracy na platformach systemowych: Windows 7, Windows 8, Windows 10, każda w wersjach 32 i 64 bitowych.

14. System musi posiadać wersję mobilna (smartfon, tablet) umożlwiającą akceptację dokumentów oraz akceptację faktur.

Dokumenty wpływające i wychodzące (Kancelaria)15. System musi umożliwiać prowadzenie Rejestru Przesyłek Przychodzących (RKP) umożliwiający co

najmniej:a) filtrowanie oraz sortowanie zawartości rejestru, b) filtrowanie:

łączne – wynik wyszukiwania musi spełniać łącznie wszystkie wybrane kryteria, rozdzielne – wynik wyszukiwania musi spełniać przynajmniej jedno z wybranych

kryterium, c) filtrowanie powinno umożliwiać określenie parametrów niezbędnych do wyszukania

dokumentu takich jak: d) Dane dokumentu: identyfikator, zakres identyfikatorów numer RKP, zakresy numeracji

RKP, tytuł oraz rodzaj dokumentu, sposób dostarczenia, znak sprawy, etc.,e) Informacje o dekretacjach: użytkownik dekretujący, na kogo zadekretowano, przypisani

użytkownicy, działy, daty dekretacji, przedziały dat dekretacji.f) Okresie wprowadzania dokumentów: data na piśmie, data nadania, data wpływu

przesyłki, data rejestracji, przedziały dat, osoba rejestrująca dokument, etc., g) Danych interesanta: dane adresowe, dane identyfikacyjne h) wyświetlanie danych wg co najmniej następujących widoków:

Wszystkich pozycji rejestru, Dokumentów bez dekretacji, Dokumentów zwróconych, Dzisiaj zarejestrowanych,

Anulowanych.i) użytkownik musi mieć możliwość indywidualnego parametryzowania widoku co najmniej

w zakresie: Określenia rodzaju listy (czy rejestr ma być wyświetlany w formie tabeli czy

kafelków), Parametryzacji widoczności kolumn co najmniej w zakresie widoczności

poszczególnych kolumnę rejestru, definiowania kolejności kolumn (metodą przeciągnij upuść),definiowanie szerokości kolumn (definiowanie rozmiaru poprzez przesuwanie krawędzi kolumny za pomocą kursora myszy),

Parametryzacja powiadomień poprzez określenie czasu, w którym ma wyświetlać się powiadomienie, definiowania koloru podświetlenia pozycji w rejestrze.

j) system musi pozwalać na drukowanie całości rejestru lub wybranych pozycji. Musi umożliwiać możliwość drukowania rejestru z miejscem na podpis ułatwiając przy tym potwierdzanie otrzymania korespondencji papierowej – w przypadku pracy w niepełnym trybie SZPS.

k) wykonywanie akcji grupowych na dokumentach: możliwość zaznaczania wybranych lub wszystkich pozycji rejestru oraz

dekretacja, możliwość zaznaczania wybranych lub wszystkich pozycji rejestru oraz

umieszczenie ich w dodatkowych rejestrach,

16. System musi obsługiwać rejestrację dokumentów przychodzących zarówno w formie papierowej, jak i elektronicznej (przekazywanych za pośrednictwem: ePUAP oraz poczty elektronicznej)

17.

Formularz rejestracji przesyłki wpływającej musi pozwalać na wprowadzenie co najmniej następujących danych:

a) wybór interesanta: wybranie interesanta znajdującego się w bazie danych, wprowadzenie do bazy danych nowego interesanta znajdującego bez

konieczności opuszczania formularza rejestracji, możliwość edycji istniejącego interesanta poprzez aktualizację lub korektę pozycji

znajdującej się w bazie danych bez konieczności opuszczania formularza rejestracji,,

możliwość przypisania kilku interesantów do danego dokumentu oraz określenie charakteru w jakim występuje,

możliwość importu interesanta / interesantów z pliku, Import i interesanta / interesantów z wcześniej wprowadzonych dokumentów.

b) data widniejąca na piśmie,c) data nadania przesyłki,d) data wpływu przesyłki,e) godzina wpływu przesyłki,f) rodzaj dokumentu,g) tytuł dokumentu,h) znak przesyłki,i) sposób dostarczenia,j) typ danych,k) opis dokumentu,l) tagi usprawniające wyszukiwanie korespondencji.

18.

System musi posiadać mechanizm zapamiętywania zapisanych wartości formularza rejestracyjnego pozwalający na szybkie wprowadzenie informacji dla kolejnego pisma, np. tego samego nadawcy lub tego samego typu korespondencji. System musi umożliwiać zapisywanie wartości w szablonach rejestracji dokumentu, Musi istnieć możliwość tworzenia szablonów dokumentów bezpośrednio z formularza rejestrowanego pisma.

19.

System musi posiadać wbudowany edytor formularzy pozwalający na:a) Tekstowe redagowanie i podgląd formularzy, co najmniej w zakresie:

rozszerzania formularza o Java skrypt definiowany do każdego pola formularza, podziału na grup metadanych: podstawowe – zgodne instrukcją kancelaryjną,

dodatkowe – definiowane w edytorze formularzy definiowania triggerów zgodnych z SQL i umieszczania ich w dowolnym miejscu

definicji procesu podczas edycji definicji procesu i zapisie zmian system pozostawia istniejące już i

uruchomione instancje procesu bez zmian istniej możliwość dynamicznej modyfikacji osób przydzielonych do zadania

poprzez edycję zadania i zmianę przypisania bez potrzeby redefiniowania całego procesu

b) Przypisanie stworzonego formularza do rodzajów dokumentów takich jak: Dokument przychodzący Dokument wychodzący Akt Sprawy Pismo wewnętrzne Sprawa

20.

System umożliwia odebranie poczty elektronicznej za pomocą wbudowanego klienta pocztowego POP3 oraz SMTP i umożliwić rejestrację w rejestrze przesyłek wpływających lub bezpośrednie dołączenie wiadomości z załącznikami do akt sprawy. Klient pocztowy powinien składać się, co najmniej z następujących elementów:

a) skrzynka odbiorcza – z której poziomu musi istnieć możliwość rejestracji wiadomości w RKP lub dołączanie dokumentów do istniejącej sprawy.

b) kopie roboczec) elementy wysłaned) elementy usuniętee) spamf) książka adresowa

21.

System musi umożliwiać skanowanie, z wykorzystaniem interfejsu, np. HTML5, poszczególnych dokumentów, wchodzących w skład przesyłki wpływającej (jedna przesyłka może składać się z wielu dokumentów). Interfejs do skanowania powinien posiadać, co najmniej następujące narzędzia edycji:

a) obrót obrazu o dowolny kątb) przerzucania obrazu (poziomo-pionowo)c) zamiany kolejności strond) zapis do PNG, PDF, JPEGe) zmiana kontrastu,f) wybór rozdzielczości. g) usuwania stron, h) wybór skanowania dwustronnego.

22. System musi umożliwiać korzystanie z wielu skanerów jednocześnie, użytkownik musi mieć możliwość wyboru urządzenia skanującego

23.

System musi posiadać wbudowany mechanizm masowego, zautomatyzowanego skanowania zarejestrowanej korespondencji umożliwiający użytkownikowi szybką rejestrację korespondencji:

a) mechanizm musi rozpoznawać kody kreskowe, które zostały wcześniej wygenerowane i naklejone na dokument, a które pełnią rolę separatorów,

b) mechanizm musi przypisywać zeskanowane grupowo dokumenty do odpowiednich, wcześniej zdefiniowanych metadanych,

c) operacja automatycznego przypisania dokumentów do metadanych może odbywać się podczas skanowania (w tle) lub po zeskanowaniu grupy dokumentów.

24.Dla dokumentów papierowych nie podlegających skanowaniu oraz dla dokumentów na nośnikach elektronicznych niepodlegających kopiowaniu do systemu musi być możliwość stworzenia metryki, z co najmniej takimi danymi, jak: tytuł, identyfikator, opis dokumentu

25.Podczas rejestracji korespondencji, system musi umożliwiać wybór interesanta z bazy Interesantów oraz musi umożliwiać dodanie nowego Interesanta w przypadku jego braku w bazie danych

26. System musi umożliwiać dodanie jednego lub więcej interesantów dotyczących danej przesyłki oraz określenie roli w jakiej występuje (wartość słownikowa).

27. System na etapie rejestracji musi umożliwiać import grupy interesantów z plików (zewnętrznej bazy interesantów) lub import z wcześniej zarejestrowanych pozycji

28.SZPS musi umożliwiać generowanie i drukowanie naklejek z kodami kreskowymi na dokumenty papierowe oraz nośniki i odnajdywanie na podstawie zeskanowanej nalepki odwzorowania cyfrowego bądź metryki danego dokumentu

29. System musi umożliwiać generowanie potwierdzenia przyjęcia przesyłki wpływającej przez punkt kancelaryjny, w ramach potwierdzenia musi występować kod kreskowy przesyłki

30. System musi pozwalać na rejestrację zwrotów przesyłek w przypadku ich niedoręczenia oraz pocztowych potwierdzeń odbioru (zwrotek)

31. System pozwala na prowadzenie wielu punktów kancelaryjnych rejestrujących przesyłki, przy czym w systemie SZPS jest prowadzony jeden rejestr przesyłek wpływających dla całego podmiotu

32.System musi posiadać wbudowany mechanizm pozwalający na sprawdzenie, czy otrzymane pismo nie zostało już zarejestrowane. Mechanizm ten musi weryfikować, co najmniej znak dokumentu oraz dane nadawcy

33. System w momencie rejestracji dokumentu musi umożliwiać wybór rodzaju dokumentu ze słownika konfigurowalnego w Systemie

34. System musi umożliwiać przypisanie rejestrowanego dokumentu do składu chronologicznego.

35. System posiada opcję pozwalającą na automatyczne wypożyczenie nośnika ze składu do osoby, na którą dokument jest zadekretowany

36. System pozwala na wprowadzenie informacji o lokalizacji dokumentu papierowego/nośnika

37. System umożliwia umieszczenie przesyłki w dodatkowym rejestrze co pozwala na segregowanie tematyczne przesyłek

38. System musi posiadać opcje dekretacji dokumentu z poziomu Kancelarii39. System musi umożliwiać rozdzielanie przesyłek z poziomu Kancelarii.40. System musi posiadać możliwość wybrania osoby dekretującej

41.

System musi posiadać mechanizm optymalizacji przekazywania pism papierowych. System zapewni możliwość przypisania do każdego użytkownika unikalnego, jednoznacznie identyfikującego go kodu kreskowego wykorzystywanego w celu potwierdzenia odbioru pisma papierowego. Funkcjonalność umożliwi potwierdzenie odebrania kilku dokumentów na podstawie jednokrotnego odczytania kodu kreskowego użytkownika odbierającego.

42. System musi umożliwiać określenie osoby odpowiedzialnej za ostateczne załatwienie sprawy

43. System musi umożliwiać na etapie dekretacji wprowadzenie uwag. Odbiorca dokumentu będzie mógł zapoznać się z wprowadzoną uwagą.

44. System musi pozwalać na zarejestrowanie przesyłki przychodzącej bez konieczności wykonania dekretacji. Zarejestrowany dokument można zadekretować w późniejszym czasie.

45.

W module przesyłek wpływających muszą znajdować się widoki w których będą znajdowały się określone dokumenty, co najmniej:

a) Wszystkie,b) bez dekretacji,c) zwrócone,d) zarejestrowane dzisiaj,e) anulowane.

46. System musi umożliwiać sprawdzenie historii dokumentu. Każdy wpis w historii dokumentu musi

zawierać co najmniej datę zmiany, imię, nazwisko pracownika dokonującego zmiany oraz opis zmiany.

47.

System musi umożliwiać umieszczanie komentarzy w dokumentach, użytkownik musi posiadać możliwość zarządzania dostępem do umieszczanego wpisu co najmniej w zakresie:

a) Dodawania wpisów publicznych – dostęp do komentarza mają wszyscy użytkownicy, którym został udostępniony dokument,

b) Wybór pracowników – dostęp do komentarza mają wybrani użytkownicy,c) Prywatny - dostęp do komentarza ma jedynie osoba dodająca wpis.

Użytkownik po dodaniu wpisu musi mieć możliwość jego edycji oraz zarządzania dostępnością.

48. Dekretacja może odbywać się na pojedynczego pracownika lub na Kierownika Działu lub na kilku użytkowników

49. System pozwala na wysyłkę powiadomienia e-mail w momencie dekretacji50. System pozwala na określenie terminu realizacji dla dekretowanego dokumentu51. System umożliwia eksport listy przesyłek wpływających do CSV52. System umożliwia eksport do druku listy przesyłek wpływających53. System umożliwia anulowanie błędnie dodanego dokumentu z poziomu Kancelarii

54. System umożliwia na skanowanie kodu kreskowego nadanego w Systemie i naklejonego na dokument w celu jego szybkiego wyszukania

55. System musi umożliwiać prowadzenie rejestru kancelaryjnego przesyłek wychodzących56. System musi umożliwiać oznaczenie dokumentu do wysłania jako wysłanego

57.

System musi zapewnić możliwość drukowania kopert, zwrotek, książki pocztowej zgodnie z wymaganiami Poczty Polskiej lub wzorami będącymi załącznikami do umowy z Pocztą Polską. System musi pozwalać na hurtowy wydruk danego rodzaju dokumentu dla wielu przesyłek jednocześnie

58. System musi pozwolić na łączenie wielu przesyłek wychodzących w jedną kopertę, w przypadku, gdy użytkownik stwierdzi, iż dotyczą one tego samego adresata

59. System musi umożliwiać cofnięcie przesyłki z przesyłek wychodzących

60. system daje możliwość umieszczenia przesyłki w dodatkowym rejestrze co pozwala na segregowanie tematyczne przesyłek

61. System musi umożliwiać sporządzenie pocztowej książki nadawczej do zróżnicowanych wymagań występujących w różnych urzędach pocztowych

62.

System musi umożliwiać przygotowanie oraz przekazanie pocztowej książki nadawczej bezpośrednio do operatora pocztowego, w szczególności do systemy Elektroniczny Nadawca udostępnianego przez Pocztę Polską. Dzięki funkcjonalności książki nadawcze tworzone w systemami będą automatycznie przekazywane do operatora pocztowego.

63. system umożliwia eksport listy dokumentów do CSV

64. System umożliwia skanowanie kodu kreskowego nadanego w Systemie i naklejonego na dokument w celu jego szybkiego wyszukania

65. System umożliwia eksport do druku listy przesyłek wychodzących

66. System musi posiadać możliwość dołączenia kopii wysyłanego dokumentu do składu chronologicznego

67.System musi posiadać funkcjonalność pozwalającą na odnotowywanie i przechowywanie w Systemie informacji o odebraniu przez adresata korespondencji wychodzącej. Taka informacja musi być łatwo dostępna dla nadawcy korespondencji.

68. Rejestr Korespondencji Wychodzącej (RKW) powinien umożliwiać co najmniej:a) filtrowanie oraz sortowanie zawartości rejestru, b) filtrowanie powinno umożliwiać określenie parametrów niezbędnych do wyszukania

dokumentu takich jak: c) Dane dokumentu: identyfikator, zakres identyfikatorów numer RKW, zakresy numeracji

RKW, tytuł oraz rodzaj dokumentu, etc.,d) Informacje o wysyłającym, sposobie wysyłki.

e) Okresie wprowadzania dokumentów: data na piśmie, data nadania, data rejestracji, przedziały dat, etc.,

f) Danych interesanta: dane adresowe, dane identyfikacyjne g) wyświetlanie danych wg co najmniej następujących widoków:

wszystkich pozycji rejestru, wysłane, niewysłane, bez książki nadawczej, koperty.

h) użytkownik musi mieć możliwość indywidualnego parametryzowania widoku co najmniej w zakresie:

określenia rodzaju listy (czy rejestr ma być wyświetlany w formie tabeli czy kafelków),

parametryzacji widoczności kolumn co najmniej w zakresie widoczności poszczególnych kolumnę rejestru, definiowania kolejności kolumn (metodą przeciągnij upuść,

parametryzacja powiadomień poprzez określenie czasu, w którym ma wyświetlać się powiadomienie, definiowania koloru podświetlenia pozycji w rejestrze.

i) system musi pozwalać na drukowanie całości rejestru lub wybranych pozycji,j) wykonywanie akcji grupowych na dokumentach:

możliwość zaznaczania wybranych lub wszystkich pozycji drukowanie kopert, możliwość zaznaczania wybranych lub wszystkich pozycji dodawanie do książki

nadawczej, możliwość zaznaczania wybranych lub wszystkich pozycji dodawanie wysyłanie

przesyłek,

Integracja z platformą ePUAP

69.

Integracja z platformą ePUAP powinna być umożliwiona w co najmniej następującym zakresie:a) możliwości automatycznego odbierania oraz wysyłania dokumentów na platformę ePUAP

bezpośrednio z poziomu SZPS,b) pełnej komunikacji z ePUAP bez konieczności logowania się na platformie ePUAP,c) pobierania dokumentów wraz z UPP (Urzędowe Poświadczenie Przedłożenia) lub UPD

(Urzędowe Poświadczenie Doręczenia) ze skrzynki ePUAP z rozdzieleniem na skrytki zdefiniowane w obrębie skrzynki (konta)

d) pobierane dokumenty z platformy ePUAP powinny trafiać na listę dokumentów oczekujących na rejestrację w dedykowanym rejestrze,

e) SZPS powinien posiadać mechanizm automatycznego wyszukiwania w swojej bazie interesantów informacji o tym czy dany podmiot znajduje się już w bazie. Jeśli tak – dane opisujące nadawcę są automatycznie wypełnione na etapie rejestracji dokumentu lub scalane w przypadku aktualizacji,

f) automatycznego dołączania UPO do odebranych/wysyłanych wiadomości bez konieczności rejestracji w rejestrze pism wpływających,

g) podpisania dokumentów profilem zaufanym,h) możliwość utworzenia sprawy na podstawie odebranego dokumentu,i) umożliwia automatyczne odesłanie odpowiedzi na pismo wpływające z ePUAP do

wszystkich stron zainteresowanych w prowadzonej w systemie sprawie,j) obsługi wielu skrytek ePUAP Zamawiającego.

Obsługa spraw i dokumentów – przesyłki przychodzące70. System musi posiadać rejestr dokumentów zadekretowanych na użytkownika71. System umożliwia założenie sprawy z dokumentu otrzymanego przez użytkownika72. System pozwala na dołączenie otrzymanego dokumentu do już prowadzonej sprawy

73. System musi umożliwiać zwrócenie dokumentu, jeżeli nastąpiła pomyłka w dekretacji74. System musi umożliwiać dalsze przekazanie otrzymanego dokumentu75. System musi umożliwiać odłożenie dokumentu jako nie tworzącego akt sprawy76. System umożliwia eksport listy dokumentów do CSV

77. System umożliwia eksport do druku listy przesyłek przychodzących zadekretowanych na użytkownika

78.

Rejestr dokumentów zadekretowanych na użytkownika powinien umożliwiać co najmniej:a) filtrowanie oraz sortowanie zawartości rejestru, b) filtrowanie powinno umożliwiać określenie parametrów niezbędnych do wyszukania

dokumentu takich jak: 1. filtrowanie:o łączne – wynik wyszukiwania musi spełniać łącznie wszystkie wybrane kryteria, o rozdzielne – wynik wyszukiwania musi spełniać przynajmniej jedno z wybranych

kryterium, 2. Dane dokumentu: identyfikator, numer, opis dokumentu, data pisma, data

nadania, data wpływu, data rejestracji, znak obcy, typ dokumentu, typ danych, sposób dostarczenia, lokalizacja etc.,

3. Informacje o dekretacjach: użytkownik dekretujący, rejestrujący dokument, przypisana komórka,

4. Okresie wprowadzania dokumentów: data pisma, data nadania, data wpływu przesyłki, data rejestracji, przedziały dat, osoba rejestrująca dokument, etc.,

5. Danych interesanta: dane adresowe, dane identyfikacyjne c) wyświetlanie danych wg co najmniej następujących widoków:

Wszystkich pozycji rejestru, dokumenty wewnętrzne, dokumenty zewnętrzne, dokumenty nietworzące akt sprawy, dokumenty do archiwum zakładowego,

d) użytkownik musi mieć możliwość indywidualnego parametryzowania widoku co najmniej w zakresie:

Określenia rodzaju listy (czy rejestr ma być wyświetlany w formie tabeli czy kafelków),

Parametryzacji widoczności kolumn co najmniej w zakresie widoczności poszczególnych kolumnę rejestru, definiowania kolejności kolumn (metodą przeciągnij upuść),definiowanie szerokości kolumn (definiowanie rozmiaru poprzez przesuwanie krawędzi kolumny za pomocą kursora myszy),

Parametryzacja powiadomień poprzez określenie czasu, w którym ma wyświetlać się powiadomienie, definiowania koloru podświetlenia pozycji w rejestrze.

e) system musi pozwalać na drukowanie całości rejestru lub wybranych pozycji. f) wykonywanie akcji grupowych na dokumentach:

możliwość zaznaczania wybranych lub wszystkich pozycji rejestru dołączenie dokumentów do istniejącej sprawy,

możliwość zaznaczania wybranych lub wszystkich pozycji rejestru zwrot dokumentów do osoby dekretującej,

możliwość zaznaczania wybranych lub wszystkich pozycji rejestru przekazanie dokumentów do innych pracowników lub grup pracowników,

Obsługa spraw i dokumentów - akceptacje dokumentów

79. System musi pozwalać użytkownikowi na akceptacje/odrzucenie dokumentu lub akceptację z podpisem po przekazaniu do niego dokumentu do zaakceptowania

80. System musi umożliwiać wieloetapową akceptację dokumentu.

81. System posiada możliwość parametryzacji wymagalności akceptacji dla dokumentu przed jego

wysłaniem do Interesanta lub założeniem sprawy

82.

Użytkownik powinien mieć możliwość swobodnego definiowania ścieżek akceptacji, co najmniej:a) akceptacja przez jednego użytkownika,b) przesłanie dokumentu do wielu użytkowników i akceptacja przez wybraną ilość

użytkowników - element jest wysyłany do kilku użytkowników, ale zostaje zaakceptowany w momencie uzyskania wybranej przez użytkownika dekretującego liczby akceptacji (np. 1/2, 2/5, 3/7, itd.),

c) przesłanie dokumentu do wielu użytkowników i akceptacja przez wszystkich - element jest zaakceptowany, gdy wszyscy użytkownicy zaakceptują dokument (np. 3/3)

83. System musi pozwalać na stworzenie ścieżki akceptacji - kolejna osoba może zaakceptować dokument dopiero wtedy, gdy poprzednia osoba w ścieżce go zaakceptowała

84. System musi posiadać możliwość podpisania akceptacji dokumentu przez akceptującego

85. System musi pozwalać na zaparafowanie dokumentu akceptowanego przy użyciu indywidualnego PINu za pomocą wewnętrznego centrum certyfikacji

86.

System musi umożliwiać grupową akceptacja dokumentów z użyciem podpisu elektronicznego:a) musi istnieć możliwość grupowej akceptacji pism wraz z ze złożeniem podpisu

elektronicznego na każdym załączniku pisma, z wykorzystaniem, mechanizmu zapamiętywania PIN na określoną ilość operacji,

b) musi istnieć możliwość grupowej akceptacji pism, bez złożenia podpisu,c) musi istnieć możliwość grupowego odrzucania dokumentów.

87. System powinien wyświetlać w widocznym miejscu liczbę pism do akceptacji oraz liczbę plików, które należy podpisać.

88. W przypadku usunięcia wszystkich plików pisma, musi zostać ono usunięte z listy pism do akceptacji, a informacja o liczbie plików do podpisania musi zostać zaktualizowana.

Obsługa spraw i dokumentów – sprawy

89. System musi umożliwiać wszczynanie, prowadzenie i załatwianie spraw, przechowywanie akt sprawy i prowadzenie spisów spraw zgodnie z obowiązującymi przepisami.

90. Sprawa może być otwierana z dokumentu lub z urzędu

91. System musi automatycznie nadawać znak spraw i zapewniać zgodność prowadzonej sprawy z wymogami instrukcji kancelaryjnej

92. System musi umożliwiać numerację i klasyfikację spraw w oparciu o JRWA zgodnie z instrukcją kancelaryjną

93. System musi umożliwiać opisywanie spraw i akt sprawy zgodnie z obowiązującymi przepisami

94.

System musi umożliwiać podgląd historii sprawy, musi przechowywać co najmniej dane w zakresie:

a) daty oraz godziny wprowadzonej modyfikacji, b) tytułu sprawy,c) oznaczenia osoby wykonującej czynność,d) określeniu wykonywanej czynności,e) wskazanie identyfikatora dokumentu.

95. System musi zapewnić prowadzenie, podgląd oraz wydruk metryki sprawy zgodnie z obowiązującymi przepisami.

96. System musi umożliwiać określenie liczby dni potrzebnych na rozpatrzenie sprawy.

97.Każdy z użytkowników musi mieć możliwość określenia liczby dni, przed wyznaczonym terminem zakończenia sprawy, w trakcie których sprawa będzie oznaczona przez System, jako zagrożona przekroczeniem terminu, a po jego przekroczeniu jako przeterminowana

98. SZPS musi umożliwiać użytkownikowi podgląd przypisanych do niego spraw i korespondencji z możliwością sortowania, filtrowania i przeszukiwania.

99. System musi umożliwiać udostępnianie sprawy innym pracownikom bezpośrednio z poziomu sprawy. Użytkownik prowadzący sprawę powinien posiadać możliwość różnicowania poziomu uprawnień do sprawy, co najmniej w zakresie:

a) udostępniania sprawy,b) zmiany statusu sprawy,c) widoku pracownika,d) pracownik widzi innych pracowników mających dostęp do sprawy,e) pracownik widzi dokumentacje roboczą nie tworzącą akt sprawy,f) pracownik widzi komentarze do sprawy,g) pracownik może dodawać,h) przesyłki wpływające,i) przesyłki wychodzące,j) akta sprawy, nie będące przesyłką,k) faktury,l) dokumentacje roboczą,m) komentarze,n) pracownik prowadzący musi mieć możliwość ograniczania uprawnień do poziomu: edycji,

otwierania, widoczności dokumentów dodawanych wcześniej w sprawie,

100. System musi umożliwiać wysyłkę dokumentu do wybranych osób, jeżeli w sprawie występuje więcej niż jeden interesant. Taki dokument można później wysłać do pozostałych interesantów.

101. System musi umożliwiać użytkownikowi wgląd do spraw z poziomu dokumentu oraz wgląd do dokumentów z poziomu spraw.

102. System musi posiadać część nadzorczą, która umożliwia przełożonym pełen wgląd do dokumentów, spraw i projektów pracowników podległych.

103.System musi generować powiadomienia o niezałatwionych sprawach i dokumentach. Użytkownik dodatkowo musi mieć możliwość odłożenia komunikatu na okres określony (np. 5 min, godzina, tydzień) lub na zawsze.

104. System musi pozwalać na określenie statusu sprawy oraz na jego modyfikację w trakcie postępowania.

105. System musi pozwalać na założenie sprawy w wybranej grupie spraw do której użytkownik posiada dostęp

106. System musi pozwalać na określenie dostępu do sprawy podlegającej publikacji w Biuletynie Informacji Publicznej oraz Portalu Mieszkańca.

107. System musi umożliwiać określenie rodzaju sprawy

108.

System musi pozwalać na dołączenie dokumentu do sprawy co najmniej jako: a) przesyłka wychodząca / wewnętrzna,b) akt sprawy (niebędący przesyłką)c) dokumentacja robocza

109. System musi pozwalać na zaimportowanie interesantów z pliku oraz pisma

110. System musi umożliwiać udostępnienie dokumentu innym pracownikom

111. System musi umożliwiać określenie rodzaju dokumentu

112. System musi pozwalać na określenie preferowanego sposobu wysyłki

113.

System musi zapewnić możliwość dodania załącznika do dokumentu z następujących źródeł:a) szablon dokumentu,b) plik z dyskuc) skan dokumentud) utworzenie dokumentu z poziomu zakładania sprawy (co najmniej z wykorzystaniem

edytora WYSWIG oraz jednego komercyjnego oraz darmowego edytora tekstu).

114. System musi umożliwiać na dodanie załącznika metodą „przeciągnij upuść”.

115.System musi umożliwiać wersjonowanie dokumentów wraz z zaznaczeniem różnic pomiędzy wersjami. Użytkownik może przywrócić poprzednią wersję pliku i korzystać z niej jako aktualnej, przy czym dokument jest rozumiany jako załącznik i zbór metadanych.

116. System musi klasyfikować sprawy które powinny zostać zarchiwizowane i przenieść je do widoku ,,Do archiwum’’

117.

System musi posiadać możliwość tworzenia raportu spraw z możliwością określenia co najmniej następujących parametrów:

a) wybór komórki organizacyjnej, b) wyboru symbolu klasyfikacyjnego sprawy,c) rok założenia sprawy:d) określenia przedziału czasowego (od dnia do dnia),e) wyboru użytkownika,f) wyboru statusu sprawy

Zestawienie powinno składać się minimum z następujących elementów:a) numer sprawy,b) tytuł sprawy,c) nazwa podmiotu, od którego dotyczy sprawa,d) znak przesyłki wszczynającej,e) data wszczęcia sprawy,f) data ostatecznego załatwienia sprawy,g) pracownik prowadzący sprawę,h) Uwagi dotyczące sposobu załatwienia sprawy.

118. System musi posiadać możliwość tworzenia spisu spraw zgodnego z instrukcją kancelaryjną.

119.

System musi umożliwiać umieszczanie komentarzy w sprawach, użytkownik musi posiadać możliwość zarządzania dostępem do umieszczanego wpisu co najmniej w zakresie:

a) dodawania wpisów publicznych – dostęp do komentarza mają wszyscy użytkownicy, którym został udostępniony dokument,

b) wybór pracowników – dostęp do komentarza mają wybrani użytkownicy,c) prywatny - dostęp do komentarza ma jedynie osoba dodająca wpis. d) Inicjujący rozmowę – wywołujący rozmowę na wewnętrznym komunikatorze

systemowym. Odbiorca komentarza powinien otrzymać jego treść w wyskakującym oknie, niezależnie od tego, w którym miejscu sytemu obecnie się znajduje. Powinna istnieć możliwość przejścia do komentowanej sprawy z poziomu otrzymanej wiadomości.

Użytkownik po dodaniu wpisu musi mieć możliwość jego edycji oraz zarządzania dostępnością. System powinien przechowywać historie komentarzy oraz prowadzonych rozmów dotyczących danej sprawy.

120. System musi zapewnić możliwość prowadzenia rozmowy z innym pracownikiem której treść zostanie zapisana do sprawy

Faktury

121.

System musi umożliwiać dodanie co najmniej następujących rodzajów faktury:a) Pro forma.b) Faktura VAT przychodzącac) Faktura VAT wychodzącad) Faktura odwrócony VATe) Korekta faktury.f) Duplikat faktury.g) Paragonh) Korekta paragonu

122. System musi posiadać możliwość wiązania ze sobą faktur (pro forma, faktura VAT, faktura

korygująca).

123.System musi umożliwiać rejestrację poszczególnych pozycji towaru / usługi zawartych na fakturze oraz rejestracje faktur bez rozbijania wartości faktury dla poszczególnych pozycji.

124.System musi umożliwiać przypisywania miejsc powstawania kosztów poszczególnym pozycjom towaru / usługi. na podstawie dedykowanego słownika

125.

System musi umożliwiać wiązania faktur z umowami ewidencjonowanymi w module Umowy:

powinna istnieć możliwość przypisania do umowy dowolnej ilości faktur. powinna istnieć możliwość przypisania do umowy całej faktury lub poszczególnych

pozycji, system powinien weryfikować stopień rozliczania umowy na podstawie przypisanych

faktur. system powinien dawać możliwość weryfikacji terminu płatności faktury z terminem

wynikającym z umowy. Na żądanie użytkownika system powinien weryfikować zgodność terminów w przypadku jej braku powinien mieć możliwość automatycznego poprawienia terminu płatności. W przypadku braku powiązanej umowy z fakturą, użytkownik powinien mieć możliwość wyboru umowy z listy umów zawartych w module umowy.

126. System musi umożliwiać na wprowadzenie numeru konta bankowego podczas rejestrowania faktury. Wprowadzanie kont bankowych musi się odbywać także w formacie IBAN i SWIFT.

127.System musi umożliwiać wybór płatności faktury. Sposób płatności musi być ustalany w czasie rejestracji faktury. Możliwość zmiany sposobu może być wykonywana podczas zatwierdzania/odrzucania faktury.

128. System musi umożliwiać użytkownikom definiowanie szablonów opisu faktury, które będą mogli wykorzystać w procesie zatwierdzania kolejnych faktur.

129. System musi umożliwiać wieloetapowe zatwierdzanie faktury przez użytkowników do tego uprawnionych oraz umożliwiać opisywanie faktury na danym etapie zatwierdzania.

130. System po zakończonej akceptacji faktury generuje dokument zawierający wszystkie akceptacje faktury wraz z informacją o złożonych parafkach powinien być możliwy do wydrukowania.

131. System musi posiadać możliwość określenia daty od której ma być liczony termin płatności faktury

132. System musi posiadać możliwość ustawienia etapów realizacji faktury

133. System musi umożliwiać po zarejestrowaniu faktury edycję etapów realizacji

134. System musi posiadać możliwość wybrania waluty w której została wystawiona faktura

135. System musi umożliwiać dodanie faktury do rejestru dokumentów

136. System musi umożliwiać dołączenie faktur do istniejącej sprawy.

137. System musi pozwalać na anulowanie zarejestrowanej faktury która nie została zatwierdzona na żadnym z etapów

138.

System musi posiadać historię faktury rejestrującą co najmniej: a) Datę oraz godzinę modyfikacji faktury, b) Informację o użytkowniku wprowadzającym zmiany,c) opis zmianyd) wersjonowanie faktur z możliwością przywrócenia wersji.

139. Rejestr faktur powinien umożliwiać co najmniej:g) filtrowanie oraz sortowanie zawartości rejestru,

h) filtrowanie powinno umożliwiać określenie parametrów niezbędnych do wyszukania dokumentu takich jak:

§ 2. filtrowanie:o łączne – wynik wyszukiwania musi spełniać łącznie wszystkie wybrane kryteria, o rozdzielne – wynik wyszukiwania musi spełniać przynajmniej jedno z wybranych

kryterium, § 3. Dane faktury: identyfikator, rodzaj faktury, numer faktury, opis faktury, kwota

netto, kwota brutto, data faktury, termin, data etap akceptacji, zatwierdzona, przypisana, etc.,

§ 4. Informacje o procedowaniu: do kogo przypisana, rejestrujący fakturę, przypisana komórka organizacyjna,

§ 5. Okresie wprowadzania faktur: data faktury, data wpływu data faktury, etc., § 6. Danych interesanta.

i) wyświetlanie danych wg co najmniej następujących widoków faktu: wszystkie faktury, w trakcie realizacji, etap realizacji – oddzielny widok dla każdego ze zdefiniowanych etapów, zakończone zatwierdzanie, faktury do archiwum zakładowego, faktury zwrócone z archiwum, anulowane, odrzucone.

j) system musi pozwalać na drukowanie całości rejestru lub wybranych pozycji. Musi umożliwiać możliwość drukowania rejestru z miejscem na podpis ułatwiając przy tym potwierdzanie otrzymania faktury papierowej – w przypadku pracy w niepełnym trybie SZPS,

k) wykonywanie akcji grupowych na dokumentach: możliwość zaznaczania wybranych lub wszystkich pozycji rejestru dołączenie do dodatkowo przygotowanych rejestrów.

140.System w momencie wprowadzania faktury musi posiadać możliwość weryfikacji kontrahenta na białej liście podatników VAT. Weryfikacja powinna odbyć się z poziomu formularza, bez konieczności przełączania się między oknami.

141.System musi umożliwiać grupową weryfikacje kontrahentów na białej liście podatników VAT. Weryfikacja powinna być możliwa z poziomu rejestru faktur, system powinien umożliwić mn. wybranie pojedynczych jak i wszystkich faktur jednocześnie.

142.

System musi być zgodny z wytycznymi ustawy z dnia 9 listopada 2018 r. o elektronicznym fakturowaniu w zamówieniach publicznych, koncesjach na roboty budowlane lub usługi oraz partnerstwie publiczno-prywatnym (Dz. U. z 2018 r. poz. 2191 )

Obsługa Pism Wewnętrznych

143.

System musi umożliwiać umieszczanie komentarzy w pismach nietworzących akt sprawy, użytkownik musi posiadać możliwość zarządzania dostępem do umieszczanego wpisu co najmniej w zakresie:

a) dodawania wpisów publicznych – dostęp do komentarza mają wszyscy użytkownicy, którym został udostępniony dokument,

b) wybór pracowników – dostęp do komentarza mają wybrani użytkownicy,c) prywatny - dostęp do komentarza ma jedynie osoba dodająca wpis.

Użytkownik po dodaniu wpisu musi mieć możliwość jego edycji oraz zarządzania dostępnością.

144. System musi umożliwiać przeprowadzenie wielopoziomowego procesu akceptacji pism wewnętrznych nie tworzących akt sprawy oraz ich późniejszą wysyłkę do interesanta.

145. System musi umożliwiać wieloetapową akceptację dokumentu (zgodnie z instrukcją kancelaryjną

podmiotu).

146. System musi umożliwiać przekazanie pisma do komórki merytorycznej

147. System musi umożliwiać stworzenie szablonu dokumentów

148. System musi pozwalać na określenie rodzaju dokumentu

149. System musi umożliwiać przekazanie pisma do uzupełnienia

150. System musi pozwalać na anulowanie pisma

151. System musi pozwalać na usunięcie pisma

152.

System musi umożliwiać prowadzenie pism nietworzących akt sprawy umożliwiający co najmniej:§ 1. filtrowanie oraz sortowanie zawartości rejestru, § 2. filtrowanie powinno umożliwiać określenie parametrów niezbędnych do wyszukania

dokumentu takich jak: § 3. dane dokumentu: identyfikator, zakres identyfikatorów, tytuł, rodzaj oraz opis

dokumentu, etc.,§ 4. danych interesanta: dane adresowe, dane identyfikacyjne § 5. wyświetlanie danych wg co najmniej następujących widoków:

wszystkie pozycje rejestru, nowe, oczekujące na uzupełnienie, uzupełnione, zaakceptowane, odrzucone, udostępnione, zwrócone, przekazane do wysyłki, wysłane, anulowane.

§ 6. użytkownik musi mieć możliwość indywidualnego parametryzowania widoku co najmniej w zakresie:

określenia rodzaju listy (czy rejestr ma być wyświetlany w formie tabeli czy kafelków),

parametryzacji widoczności kolumn co najmniej w zakresie widoczności poszczególnych kolumnę rejestru, definiowania kolejności kolumn (metodą „przeciągnij upuść”),definiowanie szerokości kolumn (definiowanie rozmiaru poprzez przesuwanie krawędzi kolumny za pomocą kursora myszy),

parametryzacja powiadomień poprzez określenie czasu, w którym ma wyświetlać się powiadomienie, definiowania koloru podświetlenia pozycji w rejestrze.

system musi pozwalać na drukowanie całości rejestru lub wybranych pozycji.

Podpis elektroniczny

153.System musi posiadać mechanizm parafowania dokumentów oraz podpisywania ich kwalifikowanym podpisem elektronicznym. W przypadku podpisanego dokumentu istnieje możliwość weryfikacji podpisu.

154. System musi posiadać możliwość podpisania akceptacji dokumentu przez akceptującego.

155. System musi pozwalać na podpisywanie dokumentów wychodzących profilem zaufanym

Wzory dokumentów i korespondencja seryjna

156. System musi umożliwiać dokumentowanie wypożyczenia dokumentacji ze składu chronologicznego lub ze składu informatycznych nośników danych

157. System musi umożliwiać tworzenie i zatwierdzanie szablonów dokumentów.

158.

System musi pozwalać na wprowadzenie w ramach szablonu dokumentów, co najmniej następujących znaczników umożliwiających zautomatyzowane uzupełnianie dokumentów danymi wprowadzonymi w procesie rejestracji dokumentu:

a) dla Interesantów - dane osobowe, dane adresowe, b) dla użytkowników - dane użytkownika,c) dla dokumentów – numeracji dokumentów, identyfikatorów, dat związanych z

dokumentami, elementów opisujących dokumenty takich jak tytuł opis dokumentu itp.,d) spraw – numeracji spraw, dat związanych ze sprawą (np. data wszczęcia, zakończenia,

zawieszenia, unieważniona) informacji o statusie, elementów opisujących sprawy (np. tytuł, opis), informacje o statusie,

e) inne dostępne w bazie danych systemu – takie jak kod kreskowy, numer strony, aktualna data itp.

159.System musi zapewniać obsługę korespondencji seryjnej m.in. podczas tworzenia dokumentu w sprawie z wykorzystaniem szablonów dokumentów system powinien w sposób zautomatyzowany generować korespondencję dla grupy wybranych interesantów, których dotyczy sprawa.

160.

System musi posiadać wbudowane repozytorium dokumentów, umożliwiające przechowywanie szablonów dokumentów, struktura repozytorium powinna być drzewiasta i oparta na uprawnieniach. Powinna istnieć możliwość dodania szablonów dokumentów:

a) osobistych – do których dostęp posiada jedynie użytkownik wprowadzający szablon,b) przypisanych poszczególnym komórkom organizacyjnym, c) wspólne – dla wszystkich użytkowników systemu.

Szablony dokumentów powinny być przypisywane do konkretnej kategorii JRWA.

161.System musi umożliwiać obsługę repozytorium dokumentów elektronicznych, w szczególności wytworzonych w pakietach MS Office i LibreOffice poprzez integrację z protokołem WebDAV (lub równoważnym).

162.

System musi umożliwiać integracje z pakietami MS Office i LibreOffice, co najmniej w zakresie:§ 1. edycji dokumentów wychodzących dołączanych przez użytkowników do spraw

bezpośrednio w pakiecie MS Office lub LibreOffice,§ 2. edycji szablonów z poziomu repozytorium szablonów bezpośrednio w MS Office lub

LibreOffice.§ 3. dodawania dokumentów do spraw za pośrednictwem pakietu MS Office lub LibreOffice§ 4. wykorzystania w szablonach dokumentów znaczników generowanych przez system SZPS,

w tym automatyczne zasilanie dokumentów danymi z systemu SZPS.

Umowy

163. System musi posiadać moduł, w którym będą rejestrowane umowy cywilnoprawne podpisane przez Jednostkę.

164. System musi informować o bliskim terminie zakończenia umowy.

165. System musi umożliwiać wpisanie terminu płatności przy wprowadzaniu umowy.

166. System musi umożliwiać przeliczanie kwot brutto z umowy na netto na podstawie podanej stawki VAT.

167. System musi mieć możliwość powiązania faktury z umową wprowadzoną do Systemu.

168. System musi mieć możliwość dodania aneksu do umowy

169. System musi mieć możliwość powiązania faktury z umową

170. System musi umożliwiać prowadzenie ewidencji przedmiotów umów.

171. System musi mieć możliwość dołączenia protokołu odbioru

172. System musi wyświetlać sumę netto oraz brutto wszystkich zawartych umów

173. System musi posiadać historię zmian umowy. Wpis musi posiadać datę zmiany, opis zmiany oraz informację o pracowniku dokonującym zmiany

174.

System musi umożliwiać eksport rejestru umów do BIP uwzględniając co najmniej następujący zakres danych:

a) identyfikator umowy nadany przez podmiot prowadzący rejestr,b) data zawarcia umowy,c) dane identyfikujące kontrahenta: nazwa (firma) wraz z numerem NIP, jeżeli go posiada

albo imię i nazwisko kontrahenta,d) przedmiot umowy,e) data początkowa i końcowa okresu realizacji umowy,f) całkowita wartość przedmiotu umowy (w kwotach nieobejmujących podatku od towarów

i usług), a w przypadku, gdy całkowita wartość przedmiotu umowy nie jest w umowie określona – kwotę zrealizowanych wydatków,

g) określenie, czy przedmiot umowy jest współfinansowany ze środków Unii Europejskiej,h) tryb zawarcia umowy.

Automatyzacja procesów biznesowych

175. System musi posiadać mechanizm definiowania procesów biznesowych w oparciu o rodzaj dokumentu lub/i kategorię JRWA.

176. Modelowanie musi się odbywać w graficznym narzędziu i nie wymagającym znajomości technik programistycznych.

177.Modeler musi umożliwiać określenie: zadań, warunków łącznych i rozłącznych, podprocesów oraz zakończeń. Dodatkowo przed publikacją musi zostać dokonana weryfikacja zamodelowanego rozwiązania.

178.

System musi posiadać wbudowany moduł wspomagania przepływu dokumentów umożliwiający, co najmniej:

a) wersjonowanie ścieżek przepływu pracy,b) definiowanie ścieżek przepływu pracy w oparciu o strukturę organizacyjną jednostki,c) procedowanie i dekretacje dokumentów oraz pism z wykorzystaniem mechanizmu

procedowania według definiowalnych ścieżek zgodnie z instrukcją kancelaryjną,d) możliwość dynamicznej modyfikacji osób/grup przydzielonych do zadania bez potrzeby

redefiniowania przepływu,e) możliwość wysyłania zdefiniowanych powiadomień mailowych w dowolnym momencie

czasu przepływu.

179. System musi umożliwiać zablokowanie oraz odblokowanie procesów

180. System musi umożliwiać dodanie zadania pozwalającego przekazać pismo z nadzoru nad dokumentami automatycznie do obsługi spraw

181. System musi umożliwiać dodanie zadania które zablokuje edycję dokumentu i uniemożliwi jego usunięcie

182. System musi umożliwiać dodanie zadania które dołączy dokument do rejestru i pozwoli edytować wpis rejestru

183. System musi umożliwiać dodanie zadania które dołączy dokument do sprawy wybranej w formularzu

184. System musi pozwalać na wpinanie w istniejące ścieżki przepływu pracy zewnętrznych interfejsów integracyjnych (usług sieciowych).

185. System musi pozwalać na definiowanie, tzn. mapperów umożliwiających modyfikowanie danych między kolejnymi zadaniami przepływu pracy.

186. System musi pozwalać na łatwą integrację istniejącego przepływu z wyglądem formularzy przypisanymi do konkretnego zadania.

Komunikator

187.System musi być wyposażony w funkcjonalność komunikatora tekstowego. Komunikator musi być wewnętrznym oprogramowaniem i nie może pozwalać na komunikację z zewnętrznymi ogólnodostępnymi komunikatorami.

188. System musi dostarczać narzędzia komunikacji asynchronicznej pomiędzy użytkownikami.

189. System musi dostarczać narzędzia tekstowej komunikacji synchronicznej pomiędzy użytkownikami.

190. System posiada mechanizm powiadomień dla użytkowników o nowo nadesłanych do nich komunikatach.

191. System musi umożliwiać przeglądanie wszystkich rozmów archiwalnych, prowadzonych przez danego użytkownika – zarówno w formie synchronicznej, jak i asynchronicznej.

192. System musi posiadać możliwość przypisywania rozmów tekstowych do konkretnych spraw.

193. System musi pozwalać na wysłanie wiadomości do wielu użytkowników jednocześnie

194. System musi umożliwiać pobranie i zapisanie rozmowy do pliku tekstowego

195.

Rozmowa musi być prowadzona w nowym oknie konwersacji, tak aby była widoczna/możliwa bezpośrednio po zalogowaniu się do systemu, bez konieczności przechodzenia do spraw lub innych części systemu. Powinna istnieć możliwość minimalizacji okna dialogowego, tak aby rozmowa nie ograniczała innych czynności wykonywanych przez Użytkownika.

196. System musi umożliwiać przejście do sprawy, której dotyczy rozmowa bezpośrednio z poziomu okna konwersacji.

Komunikaty i powiadomienia

197.

System generuje automatyczne komunikaty takie jak:a) powiadomienia o przekazaniu dokumentów,b) powiadomienia o przekazaniu dokumentów do akceptacji,c) powiadomienia o zaakceptowaniu dokumentu,d) powiadomienia o dekretacji dokumentu,e) powiadomienie o kończącym się terminie sprawy.

Kalendarz

198. System musi posiadać funkcjonalność obsługi kalendarzy.

199.

System musi umożliwiać dodawanie minimum 3 typów kalendarzy: a) kalendarz centralny – dostęp posiadają wszyscy użytkownicy systemu,b) kalendarze wydziałowe – dedykowane dla pracowników danych wydziałówc) kalendarz osobisty – dostęp posiada jedynie użytkownik będący właścicielem kalendarza.

200. Użytkownik powinien mieć możliwość wprowadzenia różnych typów zdarzań. Każdy typ zdarzeń powinien być uzupełniany z wykorzystaniem formularza dedykowanego dla danego typu zdarzenia. System powinien posiadać możliwość sprowadzania następujących typów zdarzeń:

a) zwykły wpis umożliwiający co najmniej: określenie przedziału czasowego lub oznaczenie zdarzenia jako całodobowe, wprowadzenie tytułu zdarzenia wraz z jego opisem, definiowanie cykliczności powiadomienia (jednorazowe, codziennie, co tydzień,

co miesiąc, co rok), definiowania czasu przed zdarzeniem, kiedy ma wyświetlić się powiadomienie, określenie koloru w jakim ma być oznaczany wpis. definiowanie cykliczności zdarzenia wraz z parametryzacją okresu, w którym

zdarzenia mają być wyświetlane, rezerwacje zasobów, wiązanie zdarzenia z toczącymi się sprawami, wiązanie zdarzeń z dokumentami wprowadzonymi do systemu, wiązanie zdarzenia z toczącymi się sprawami, wiązanie zdarzeń z interesantami (zdarzenia powinny być odznaczanie w raporcie

dla interesantów), dodanie pliku do zdarzenia, przypisywanie innym użytkownikom lub grupom użytkowników uprawnień do

wprowadzanego zdarzenia. Uprawnienia powinny być definiowane co najmniej w zakresie: odczyt oraz odczyt i zapis.

b) Zadanie wpis umożliwiający co najmniej:, określenie przedziału czasowego lub oznaczenie zdarzenia jako całodobowe, wprowadzenie tytułu zdarzenia wraz z jego opisem, określenie statusu zadania (zaplanowane, nierozpoczęte, w toku, zrealizowane), określenie priorytetu (niski, normalny, wysoki), definiowanie cykliczności powiadomienia (jednorazowe, codziennie, co tydzień,

co miesiąc, co rok), definiowania czasu przed zdarzeniem, kiedy ma wyświetlić się powiadomienie, rezerwacje zasobów, określenie koloru w jakim ma być oznaczany wpis. definiowanie cykliczności zdarzenia wraz z parametryzacją okresu, w którym

zdarzenia mają być wyświetlane, wiązanie zdarzenia z toczącymi się sprawami, wiązanie zdarzeń z dokumentami wprowadzonymi do systemu, wiązanie zdarzenia z toczącymi się sprawami, wiązanie zdarzeń z interesantami (zdarzenia powinny być odznaczanie w raporcie

dla interesantów), dodanie pliku do zdarzenia, przypisywanie innym użytkownikom lub grupom użytkowników uprawnień do

wprowadzanego zdarzenia. Uprawnienia powinny być definiowane co najmniej w zakresie: odczyt oraz odczyt i zapis.

c) Spotkanie wpis umożliwiający co najmniej:, określenie przedziału czasowego lub oznaczenie zdarzenia jako całodobowe, wprowadzenie tytułu zdarzenia wraz z jego opisem, określenie statusu zadania (zaplanowane, nierozpoczęte, zrealizowane), definiowanie cykliczności powiadomienia (jednorazowe, codziennie, co tydzień,

co miesiąc, co rok), definiowania czasu przed zdarzeniem, kiedy ma wyświetlić się powiadomienie, rezerwację zasobów, określenie koloru w jakim ma być oznaczany wpis. definiowanie cykliczności zdarzenia wraz z parametryzacją okresu, w którym

zdarzenia mają być wyświetlane, wiązanie zdarzenia z toczącymi się sprawami,

wiązanie zdarzeń z dokumentami wprowadzonymi do systemu, wiązanie zdarzenia z toczącymi się sprawami, wiązanie zdarzeń z interesantami (zdarzenia powinny być odznaczanie w raporcie

dla interesantów), dodanie pliku do zdarzenia, dodawanie agendy spotkania, określenie lokalizacji spotkania, przypisywanie innym użytkownikom lub grupom użytkowników uprawnień do

wprowadzanego zdarzenia. Uprawnienia powinny być definiowane co najmniej w zakresie: odczyt oraz odczyt i zapis.

d) rozmowa telefoniczna wpis umożliwiający co najmniej: określenie czasu zdarzenia, określenie czasu trwania rozmowy, wprowadzenie tematu rozmowy wraz z jej opisem, określenie statusu zadania (zaplanowane, zrealizowane), definiowanie cykliczności powiadomienia (jednorazowe, codziennie, co tydzień,

co miesiąc, co rok),e) notatka wpis umożliwiający co najmniej:.

określenie czasu zdarzenia, wprowadzenie tematu rozmowy wraz z jej opisem,

201. Użytkownik powinien mieć również możliwość definiowania zdarzeń całodniowych i dłuższych oraz cyklicznych.

202. Użytkownik powinien mieć możliwość wprowadzania zdarzeń z dokładnością do 15 minut.

203. Powinna istnieć możliwość dodania wpisu poprzez kliknięcie w wybraną datę lub zaznaczenia myszką oczekiwanego przedziału czasowego.

204.W Systemie musi istnieć funkcja grupowania zasobów (np. grupa „Pojazdy”, w której znajdują się wszystkie pojazdy należące do Zamawiającego). System musi informować o braku dostępności zasobu w przypadku gdy jest on zarezerwowany przez innego użytkownika.

205. System musi umożliwiać rezerwację czasu innych użytkowników, jako współuczestników zdarzenia.

206. W czasie rezerwacji zasobu musi być możliwość wybrania projektu, w ramach którego zasób będzie wykorzystany.

207. Każdy terminarz musi być możliwy do przeglądania co najmniej w trybie dziennym, tygodniowym i miesięcznym.

208.

System musi posiadać funkcjonalność planowania i raportowania spotkań, co najmniej w zakresie:a) opracowania agendy spotkania,b) zapraszania uczestników,c) wyszukiwania spotkań,d) generowania raportów ze spotkań na podstawie agendy (również w przypadku jej braku).

209.

System musi posiadać wbudowaną legendę wpisów w kalendarzu co najmniej uwzględniającą: a) Legendę wpisów wydziałowych i centralnych,b) Legendę wpisów własnych, c) Legendę pozostałych wpisów – musi istnieć możliwość dynamicznego podglądu wpisów

np. odznaczenie typów zdarzeń będzie wiązało się z brakiem wyświetlania ich w kalendarzu, dotyczy to typu wpisu jak i zasobów lub grup zasobów.

Zastępstwa

210. System musi umożliwiać wprowadzenie zastępstw.

211. Udzielone zastępstwo może być czasowe lub nieokreślone.

212. System musi pozwalać na określenie uprawnień do konta osoby nieobecnej dla osoby zastępującej

213. System musi pozwalać na stworzenie grupy przelogowań

214. W trakcie trwania zastępstwa System musi informować o zastępowaniu jednego użytkownika przez drugiego.

215. Operacje wykonane w zastępstwie muszą być zapisywane w Systemie w sposób pozwalający na jednoznaczne określenie, kto daną operację wykonał.

216. System powinien zapisywać w postaci rejestru elementy, na których zastępca wykonał jakiekolwiek operacje, by zastępowany mógł je zweryfikować po powrocie z nieobecności.

Tablica ogłoszeń

217.System musi posiadać możliwość dodawania ogłoszeń o różnym priorytecie. System musi posiadać możliwość definiowania priorytetów ogłoszeń oraz przypisywaniem do nich koloru wyświetlania ogłoszenia.

218. System musi posiadać możliwość ustawienia daty wygaśnięcia ogłoszenia

219. System musi posiadać możliwość dodania załącznika, załączniki powinny być możliwe do załączania metodą przeciągnij upuść.

220.

Użytkownik musi mieć możliwość ograniczania widoczności ogłoszenia dla: a) dla wszystkich użytkowników systemu,b) pojedynczego użytkownika, c) komórki organizacyjnejd) grupy użytkowników.

221. System musi pozwalać na dodanie odpowiedzi do ogłoszenia, odpowiedzi wszystkich użytkowników powinny być umieszczane w czytelnej formie bezpośrednio pod treścią ogłoszenia.

222. System powinien rejestrować co najmniej datę oraz godzinę dodania ogłoszenia oraz datę wygaśnięcia jeżeli takowa zostanie zdefiniowana.

223. Powinna istnieć możliwość eksportu wykazu ogłoszeń wraz z ich treścią do pliku CSV.

Centrum certyfikacji

224. System musi posiadać własne centrum certyfikacji.

225. Centrum musi pozwalać na generowanie certyfikatów niekwalifikowalnych dla użytkowników systemu.

226. Centrum certyfikacji musi działać w oparciu o certyfikaty nadrzędne oraz podrzędne.

227. System musi pozwalać na złożenie wniosku o wydanie certyfikatu przez każdego użytkownika

228. Wygenerowane certyfikaty mają służyć do parafowania dokumentów.

229. Parafowanie dokumentów w systemie musi odbywać się przy użyciu indywidualnego numeru PIN

230. W System musi pozwalać na unieważnienie certyfikatu w dowolnym momencie.

231.Wydawanie certyfikatów powinno obywać się co najmniej 2 etapowo. Jednym z etapów musi być weryfikacja tożsamości użytkownika ubiegającego się o certyfikat, bez której certyfikat nie może być wystawiony.

Archiwum zakładowe

232. System musi zapewniać automatyczną segregację dokumentów spełniających warunki

przekazywania do archiwum zakładowego.

233. System musi posiadać dedykowane funkcje do udostępniania i wycofywania dokumentacji z archiwum zakładowego.

234. System musi umożliwiać wypożyczanie sprawy z archiwum, podgląd informacji o sprawie.

235. System musi realizować brakowanie akt elektronicznych oraz przekazanie akt do archiwum państwowego oraz sporządzanie i przechowywanie odpowiedniej dokumentacji.

236.

System musi umożliwiać tworzenie co najmniej następujących spisów:a) spisy do archiwum państwowego, b) spisy do brakowania, c) spisy nie przeznaczone do brakowania,d) spisy ekspertyzy, e) spisy zdawczo-odbiorcze nośników.

237.

System musi wspomagać użytkownika w przygotowaniu paczki archiwalnej dla Archiwum Państwowego poprzez przygotowywanie automatycznych spisów zdawczo-odbiorczych, wykazu akt, oraz zapisanie spraw w strukturze wymaganej przez Archiwum Państwowe. Po skutecznym przekazaniu spraw do Archiwum Państwowego System powinien automatycznie usunąć dane spraw na podstawie potwierdzenia otrzymanego z Archiwum Państwowego.

raportowanie i monitorowania

238.

System musi posiadać dodatkowy moduł raportów umożliwiający, co najmniej:a) utworzenie raportu oraz zestawień na podstawie dowolnych danych przechowywanych w

bazie danych Systemu,b) prezentowanie danych w formie tabelarycznej, wykresów słupkowych oraz wykresów

kołowych,c) eksport danych do plików CSV,d) eksport raportów, do co najmniej następujących formatów: doc, docx, xls, xlsx, pdf, ppt,

pptx, odp, ods, odt.,e) definiowanie grup raportów.

239.

System domyślnie powinien mieć zaimplementowane co najmniej następujące raporty:a) wszystkie aktywne sprawy użytkownika,b) ilość dokumentów zakończonych, zakończonych po terminie oraz anulowanych,c) ilość dokumentów interesanta przychodzących oraz wychodzących,d) suma dokumentów zadekretowanych na pracownika,e) ilość dokumentów przychodzących z podziałem na sposób dostarczenia,f) ilość przesyłek przychodzących oraz wychodzących,g) suma faktur z podziałem na status,h) ilość spraw z podziałem na pracowników,i) ilość spraw z podziałem na działy,j) ilość wysłanych dokumentów do interesanta,k) procentowy podział spraw na działy,l) średni czas obiegu dokumentu – od momentu zarejestrowania do załatwienia sprawy,m) ilość opóźnionych faktur oraz etap na którym się znajdują.

administracja systemem

240. System musi posiadać wyodrębniony moduł administracyjny, do którego dostęp będą posiadać jedynie osoby o odpowiednich uprawnieniach.

241. Funkcjonowanie systemu powinno obywać się w oparciu wielopoziomową o strukturę organizacyjną. Administrator powinien mieć możliwość zarządzania struktura co najmniej w zakresie:

a) wprowadzenie danych instytucji,

b) dodawanie oraz usuwanie komórek organizacyjnych w tym określanie symbolu komórki niezbędnego do prawidłowego oznaczania spraw,

c) definiowania domyślnych ról systemowych przypisanych do danej komórki organizacyjnej,

d) wprowadzenie danych adresowych, danych kontaktowych oraz dodatkowych danych identyfikujących komórkę organizacyjna,

e) przypisywania do komórek schematów JRWA, f) przypisywanie użytkowników do poszczególnych komórek organizacyjnych z określeniem

stanowisk jakie zajmują. g) przypisywania skrytek ePUAP lub RESP do poszczególnych komórek organizacyjnych. h) możliwości reorganizacji struktury organizacyjnej Szpitala (bez konieczności ręcznego

przenoszenia pojedynczych pism i spraw oraz uprawnień bez konieczności angażowania samych użytkowników) np. w przypadku zmiany stanowiska pracownika lub w przypadku zmian kadrowych,

i) obsługi co najmniej dwóch rodzaj reorganizacji tj. zmiana stanowiska wraz ze zmianą komórki organizacyjnej oraz trwałe przejęcie dokumentacji pracownika przez innego użytkownika,

242.

System powinien umożliwiać wprowadzanie nowych użytkowników w tym:a) system musi umożliwiać wprowadzenie kont użytkowników o tymczasowej ważności, po

upływie, której konto zostaje automatycznie blokowane przez System,b) wprowadzenie danych indentyfikacyjnych użytkownika w tym login i hasło, skrót nazwy

użytkownika, etc.,c) powinna istnieć możliwość przypisywania ról oraz przypisywać do grup użytkowników,d) powinna istnieć możliwość przypisania kilku stanowisk do jednego użytkownika,e) powinna istnieć możliwość przypisania kalendarzy z możliwością ograniczenia zadań do

wybranego zakresu czasowego,f) przypisanie kont pocztowych w konfiguracji POP3 lub IMAP. Powinna istnieć możliwość

sprawdzenia poprawności połączenia bezpośrednio z okna dodawania konta. Użytkownik powinien mieć możliwość przypisania więcej niż jednego konta.

g) powinna istnieć możliwość eksportu bazy użytkowników do pliku CSV oraz importu użytkowników z odpowiednio przygotowanego dokumentu.

h) powinna istnieć możliwość blokowania użytkowników jak i ich odblokowywania. i) powinna istnieć możliwość śledzenia historii zmian dokonywanych na użytkownikach,j) administrator powinien mieć możliwość wylogowania użytkowników z systemu SZPS.

243.

Role i uprawnieniaa) System musi umożliwiać definiowanie uprawnień do poszczególnych elementów systemu

oraz grupowanie uprawnień w role w celu ułatwienia administracji systemem.b) System musi posiadać zdefiniowaną domyślną pule ról, użytkownik musi posiadać

możliwość dodawania kolejnych przez łączenie szczegółowych uprawnień do akcji w systemie,

c) System musi pozwalać na stworzenie grup użytkowników oraz przypisanie do nich wybranych uprawnień

d) System musi umożliwiać na stworzenie grup roboczych użytkowników a następnie przekazywanie dokumentów na stworzone grupy

e) System musi umożliwiać stworzenie grup użytkowników tablicy ogłoszeńf) System musi umożliwiać przeglądanie domyślnych ról i uprawnień oraz pozwalać na

stworzenie własnych ról z uprawnieniami do systemu244. System musi posiadać możliwość zarządzania słownikami pozwalający na ich swobodne

rozszerzanie o nowe wartości. System powinien posiadać co najmniej następujące słowniki:a) funkcje interesantów - używany podczas rejestracji dokumentu w celu określenia funkcji

interesanta w dokumencie,

b) rodzaje dokumentów, spraw, faktur, ogłoszeń, rejestrów.c) grupy zasobów oraz zasoby kalendarza,d) sposobów wysyłania, dostarczania korespondencji, etc.,

245.System musi posiadać możliwość personalizacji ustawień dotyczących:

a) widoku i kolejności wyświetlania kolumn na listach spraw oraz dokumentach,b) sortowania elementów w poszczególnych kolumnach.

246.

System musi umożliwiać przydzielanie użytkownikom dostępu do poszczególnych kategorii JRWA:a) musi istnieć możliwość wyznaczenia koordynatorów odpowiedzialnych za przydzielanie

kategorii,b) Koordynator musi mieć wgląd do aktualnie przydzielonej puli kategorii JRWA, jak również

możliwość wglądu i przywrócenia archiwalnej puli kategorii JRWA.c) Koordynator musi posiadać możliwość koordynacji teczek i spraw, w ramach, której

koordynator posiada wgląd do teczek i spraw przypisanych do danej kategorii JRWA.d) Koordynator nie może mieć wglądu do danych interesanta oraz do treści dokumentów

prowadzonych w teczkach i sprawach.e) Koordynator musi posiadać możliwość ograniczania dostępu do wybranych, wcześniej

zdefiniowanych rodzajów spraw.

247.

Zastępstwa:a) system musi umożliwiać definiowanie, zarządzanie zastępstwami, na czas nieobecności

pracownika, polegających na udzieleniu pełnomocnictwa innemu użytkownikowi do wykonywania czynności w imieniu użytkownika nieobecnego.

b) po upłynięciu czasu zastępstwa System odbiera uprawnienia do wykonywania czynności w imieniu użytkownika nieobecnego.

248.

System musi pozwalać na konfigurowanie automatycznych powiadomień w systemie w zakresie: a) włączania bądź wyłączania powiadomień,b) częstotliwości automatycznych powiadomień,c) wyboru kolorów dla zbliżającego się terminu,d) na ile dni przed terminem mają pojawiać się powiadomienia,e) po ilu dniach po terminie sprawa ma być oznaczona jako przeterminowana,f) wyboru koloru przeterminowanych spraw.

249.

Zarządzanie dekretacjami: a) system musi pozwalać na zdefiniowanie czy dekretacja dokumentów ma być

hierarchiczna czy niezależna od struktury organizacyjnej,b) system musi pozwalać zdefiniować użytkownika, który domyślnie będzie wybrany jako

dekretujący,c) system musi pozwalać zdefiniować wymagalność podpisu dekretacji,d) system musi pozwalać określić czy w czasie dekretacji wymagana jest parafka.e) system musi umożliwiać wskazanie odpowiedzialnych za określenie f) system musi pozwalać określić czy wypożyczenie nośnika ze składu chronologicznego przy

dekretacji dokumentu ma odbywać się automatycznie.

250.

System musi umożliwiać zdefiniowanie struktury numerów dokumentów oraz spraw co najmniej w zakresie:

a) unikatowego w systemie SZPS identyfikatora dokumentu,b) numeru dokumentu wychodzącego,c) symbolu dokumentu w rejestrze przesyłek wpływających,d) symbolu dokumentu w rejestrze przesyłek wychodzących,e) symbolu pisma wewnętrznego,f) symbolu faktury,g) symbolu faktury wychodzącej,h) znaku sprawy.

251. System musi pozwalać na edycję aktualnych sekwencji co najmniej w zakresie:

a) numeru rejestru korespondencji wpływającej,b) numeru rejestru korespondencji wychodzącej,c) numeru pism wewnętrznych,d) numeru faktur,e) numeru dokumentu,f) numeru rejestru korespondencji wpływającej w podziale rocznym,g) numeru rejestru korespondencji wychodzącej w podziale rocznym,h) numeru pism wewnętrznych w podziale rocznym,i) numeru faktur w podziale rocznym,j) numeru dokumentu w podziale rocznym,k) numeru rejestru korespondencji wpływającej w podziale miesięcznym,l) numeru rejestru korespondencji wychodzącej w podziale miesięcznym,m) numeru pism wewnętrznych w podziale miesięcznym,n) numeru faktur w podziale miesięcznym.

252.

System musi pozwalać na określenie nazewnictwa przekazywania dokumentu przez kancelarię co najmniej w zakresie:

a) dekretacja przesyłek,b) rozdzielenie przesyłek.

253.

Zarządzenie korespondencją:a) system musi pozwalać na rejestrację pism z datą przyszłą,b) system musi posiadać opcję konfiguracyjną która określi czy można rejestrować przesyłki

o takich samych znakachc) system musi pozwalać na wysyłkę kilku dokumentów w jednej kopercie,

254.

Zarządzanie sprawami:a) system musi pozwalać na określenie czy można tworzyć nowe sprawy

w miejsce anulowanych,b) system musi pozwalać określić czy możliwe jest edytowanie załącznika

w przekazanym dokumencie,c) system musi pozwalać określić czy możliwe jest zakładanie wielu spraw

z jednego dokumentu,d) system musi pozwalać zdefiniować kto określa termin załatwienia sprawy,e) system musi pozwalać określić domyślny termin załatwienia sprawy.f) system musi umożliwiać dodawanie i edycję poszczególnych kategorii JRWA z

uwzględnieniem kategorii archiwalnych,g) system musi posiadać opcję konfiguracyjną która pozwoli na tworzenie kategorii JRWA 5-

go rzędu.h) definiowanie uprawnień dotyczących eksportu sprawy do BIP - czy eksportować mogą

kierownicy czy również użytkownicy prowadzący sprawę.i) zarządzenie sortowaniem akt sprawy: wg daty dodania dokumentu do sprawy lub daty

wytworzeni dokumentu,j) definiowanie uprawnień dotyczących zmiany statusu sprawy - czy zmian dokonać mogą

kierownicy czy również użytkownicy prowadzący sprawę,

255.

Zarządzanie fakturami:a) system musi umożliwiać definicje etapów realizacji faktury,b) system musi pozwalać określić czy możliwe jest wycofywanie faktur,c) musi istnieć możliwość przypisywania kilku użytkowników do danego etapu zatwierdzenia

faktury,d) system musi pozwalać na dopuszczenie grupowej akceptacji danego etapu zatwierdzania

faktury, e) system musi pozwalać wymaganie pełnej akceptacji danego etapu zatwierdzania faktury

256. System musi pozwalać na określenie w jaki sposób mają być pobierane liczniki dokumentów:

a) pobieranie danych ze wszystkich lat,b) pobieranie danych z bieżącego roku.

257. Konfiguracji terminarza w zakresie wyświetlanych godzin, w których można dodawać terminy oraz skalę czasookresu, w jakim można dodawać terminy.

258. System musi posiadać mechanizm informujący o wprowadzonych zmianach w aplikacji.

259. System musi posiadać możliwość zdefiniowania zespołów roboczych złożonych z dowolnych użytkowników

260. System musi mieć możliwość ustawienia maksymalnego rozmiaru dla pliku, który ma być załączony.

261. System musi umożliwiać indywidualne dodawanie skrótów pozwalających na szybsze przejście do konkretnych zakładek.

Bezpieczeństwo

262.Hasła w Systemie muszą być przechowywane w formie zaszyfrowanej. Nie ma możliwości ich odtworzenia, lecz jedynie zresetowania. Po zresetowaniu hasła użytkownik przy pierwszym logowaniu jest proszony o wprowadzenie nowego hasła.

263. System musi zabezpieczać dane przed przypadkowym nadpisaniem w przypadku równoczesnego korzystania danych w Systemie.

264. System automatycznie zamyka sesje po określonym czasie bezczynności.

265. Użytkownik może indywidualnie zmienić hasło dostępowe do swojego konta.

266.

System musi umożliwiać swobodne definiowanie polityki uwierzytelniania i blokowania kont w oparciu o następujące parametry:

a) minimalna długość nazwy użytkownika i hasła.b) ilość dużych liter, cyfr i znaków specjalnych w haśle.c) długość cyklu wymuszania zmiany hasła (w miesiącach).d) Ilość nieudanych prób logowania, po których następuje blokada konta.e) czas blokady konta.f) wymuszanie cyklicznej zmiany hasła,

wymagana liczba cykli zmiany hasła, długość cyklu monitorowania o zmianę hasła użytkownika.

267. System musi umożliwiać blokowanie logowania się jednego użytkownika z wielu urządzeń.

268.

System musi posiadać rejestr zdarzeń rejestrujący akcje użytkowników w Systemie, co najmniej takie jak:

a) udane próby logowania,b) nieudane próby logowania,c) błędy aplikacji.

269.

System musi rejestrować czynności dostępu do usług i zasobów w Systemie, w tym co najmniej informacje o:

a) operacjach na dokumentach,b) operacjach na danych osobowych,c) zdarzeniach uwierzytelniania (udane logowanie, wylogowanie, nieudane logowanie),d) zdarzeniach autoryzacji (udane/nieudane operacje),e) zdarzeniach administracyjnych,f) zapisywanie danych identyfikujących musi obejmować, co najmniej:

adres IP i nazwę maszyny, z której wykonano daną czynność. identyfikator/nazwa użytkownika, który daną czynność wykonał. czas (data) występowania.

270. System powinien posiadać możliwość tworzenia harmonogramu automatycznego backupu bazy

danych. System powinien co najmniej na:a) określenie częstotliwości wykonywania backupu,b) określenie ilości przechowywanych kopii,c) wskazanie lokalizacji przechowywania kopii,d) z poziomu systemu powinna istnieć możliwość podejrzenia listy wykonanych backupów,e) z poziomu systemu powinna istnieć możliwość przeprowadzenia testu poprawności

wykonania kopii bazy.

271. System powinien umożliwiać wykonanie kopii bazy danych jak i plików.

272.System musi pozwalać na logowanie z wykorzystaniem co najmniej: nazwy użytkownika i hasła, usług katalogowych oraz z wykorzystaniem profilu zaufanego. System powinien umożliwić zarządzanie ustawieniami umożliwiającymi zastosowanie metod logowania.

Rejestry definiowalne

273. System musi posiadać mechanizm definiowania (bez wiedzy programistycznej) złożonych rejestrów, składających się z dowolnej ilości kolumn

274.

Użytkownik definiując rejestr musi mieć możliwość wyboru narzędzi ułatwiających ich późniejsze redagowanie co najmniej takich jak:

a) wyszukiwarka dokumentów wprowadzonych do systemu,b) wyszukiwarka spraw prowadzonych w systemie,c) wybór nazwy użytkownika systemu,d) krótkie pole tekstowe,e) długie pole tekstowe,f) dane interesanta – wyszukiwarka interesantów,g) adresu interesanta – wyszukiwarka interesantów,h) pole wyboru,i) data – pole wyboru z kalendarz,j) pole liczbowe,k) możliwość załączenia pliku.

275. System musi umożliwiać zdefiniowanie domyślnych wartości, którymi mają być zasilane poszczególne pozycje rejestru

276. Musi istnieć możliwość definiowania, które z pól będą wymagane do uzupełnienia podczas dodawania wpisu w rejestrze

277. Musi istnieć możliwość, które z elementów rejestru będą polami filtru w wyszukiwarce dedykowanej dla zdefiniowanego rejestru

278.System musi umożliwiać drukowanie rejestrów

279. System musi umożliwiać określenie, które z pozycji rejestru znajdować się na jego wydrukach

280.

Musi istnieć możliwość określania uprawnień dla definiowanych rejestrów oraz poszczególnych pozycji rejestru co najmniej w zakresie:

a) odczytu,b) odczytu i zapisu,c) braku dostępu.

Interesanci

281. System musi posiadać bazę Interesantów i możliwość ich grupowania w listy

282. Baza interesantów musi umożliwiać dodanie zarówno osób fizycznych jak i instytucji/firm. 283. Przy wprowadzaniu nowego Interesanta powinna być możliwość wprowadzenia minimum

następujących danych:a) imię i nazwisko osoby/nazwa instytucji,b) dane adresowe (możliwość dodania kilku lokalizacji),c) dane kontaktowe (e-mail, telefon, fax, itp. – z możliwością przypisania preferowanej

formy kontaktu),d) możliwość przypisania skrytki ePUAP.e) możliwość przypisania skrytki Regionalnej Elektronicznej Skrzynki Podawczej RESP,

284. System musi pozwalać na poszerzenie standardowego formularza wprowadzania interesanta

285.

System musi odnotowywać następujące informacje związane z interesantem:a) historia kontaktów będąca ewidencją takich czynności jak: spotkanie, wysyłka

korespondencji czy ewidencja rozmów telefonicznych.b) sprawy prowadzone dla Interesanta i wykaz dokumentów na nich zawarty z możliwością

przejścia do zawartości dokumentu lub sprawy (pod warunkiem, że osoba wyszukująca ma uprawnienia do wglądu),

c) dokumenty otrzymane od Interesanta, które nie rozpoczęły sprawy z możliwością przejścia do zawartości dokumentu (pod warunkiem, że osoba wyszukująca ma uprawnienia do wglądu),

d) informację, którzy użytkownicy mieli wgląd w dane osobowe interesanta z wskazaniem daty, od której interesant otrzymał dostęp do dokumentów.

e) informację na temat odbiorców, którym dane zostały udostępnione. f) Informacje o wpisach w kalendarzu dotyczących interesanta. g) historie weryfikacji interesanta na białej liście podatników VAT.

286. System musi umożliwiać nadawanie i odbieranie uprawnień do wglądu do pełnej informacji na temat Interesanta.

287. Moduł pozwala na filtrowanie oraz sortowanie Interesantów wprowadzonych do systemu

288. System musi umożliwiać określenie kraju pochodzenia interesanta

289. System umożliwia eksport Interesantów do pliku CSV

290.

System umożliwia sprawdzenie historii zmian danych Interesanta:a) datę wprowadzenia zmiany – co najmniej data i godzina operacji,b) opis zmiany – zawierający informację o użytkowniku, który wprowadził zmianę wraz ze

szczegółowym opisem dokonanej zmiany tzn. wskazanie elementów, które zostały zmienione oraz elementów na jakie zostały zmienione.

możliwość przywracania wpisów – powinna być możliwość powrotu do każdej pozycji historii.

291. System umożliwia dokonanie korekty lub aktualizacji danych Interesanta w zależności od rodzaju zmiany.

292.

System posiada możliwość wydruku raportu z informacjami dotyczącymi Interesanta, raport powinien zawierać co najmniej następujące informacje:

a) dane interesanta, którego dane zostały udostępnione (min. imię nazwisko, nazwa oraz adres),

b) informacje na temat źródła danych, sposobu gromadzenia danych, daty rejestracji, danych osoby wprowadzającej,

c) wykaz dokumentów wysłanych do interesanta (min. identyfikator, tytuł dokumentu, data rejestracji),

d) wykaz dokumentów wysłanych do interesanta (min. identyfikator, tytuł dokumentu, data rejestracji),

e) wykaz sprawy dotyczące interesanta (min. znak sprawy, opis sprawy, data założenia),f) wykaz odbiorców, którym dane zostały udostępnione.

Integracje z systemami zewnętrznymi

293.

System musi być interoperacyjny i powinien umożliwiać integrację z innymi systemami za pomocą:

a) API w formacie REST, SOAP,b) formatu XML. c) bazy danych.

294.

System SZPS musi umożliwiać integrację z systemem System ERP wykorzystując integrację na poziomie bazy danych, Integracja bazodanowa musi umożliwiać wymianę danych w czasie rzeczywistym.

295. System SZPS musi umożliwiać integracje z systemem System ERP minimum w następującym zakresie:

1. Finanse i Księgowość – system powinien umożliwiać obsługę finansowo Księgową w następującym zakresie:

Rejestracja faktur zakupowych - Faktura zakupowa będzie rejestrowana w SZPS a następnie po zakończeniu procesu akceptacji przekazywana do modułu Rejestr Zakupu, gdzie będzie odbywała się jej dalsza obsługa. SZPS rejestruje podstawowe dane faktury (rejestr dokumentów, numer, kontrahent, daty, czego dotyczy, załącznik w postaci „skanu”, opcjonalnie pozycje faktury). W Rejestrze Zakupu osoba merytoryczna uzupełnia brakujące dane niezbędne do przekazania faktury do systemu Finansowo-Księgowego (ośrodki powstawania kosztów, konta, wartości słownikowe niezbędne do wyznaczenia właściwych kont, jeśli nie są one podawane wprost), ustala ewentualnie schemat księgowania dokumentu, jeśli wymagany byłby inny niż schemat domyślny dla danego rejestru dokumentów. W SZPS faktura zostanie zarejestrowana w rejestrze faktur wspólnym dla całego Szpitala. Dostęp do rejestru może mieć więcej niż jedna kancelaria (faktury mogą być rejestrowane w wielu punktach, ale w jednym, wspólnym rejestrze). W systemie SZPS odbywa się będzie proces zatwierdzenia zgodnie z wcześniej zdefiniowaną ścieżkąIntegracja będzie dotyczyła minimum następujących typów dokumentów:

faktura VAT przychodząca, korekta faktury VAT przychodząca, faktura z odwróconym vat przychodząca, korekta faktury z odwróconym vat przychodząca.

Nie będzie dotyczyła Paragonów i korekt paragonów oraz dokumentów sprzedaży.

Wysyłanie dokumentów księgowych (potwierdzenia sald, wezwania do zapłaty) - System ERP generuje wiele dokumentów wysyłanych do kontrahenta. Obecnie dokumenty te muszą być drukowane i podpisane w związku, z czym nie da się ich wysyłać bezpośrednio z systemu. SZPS, w którym rejestrowana jest korespondencja wychodząca na podstawie typu dokumentu (potwierdzenie sald, wezwanie do zapłaty itp.) oraz kontrahenta będzie uzupełniać, w systemie ERP, referencję do dokumentu zarejestrowanego w systemie zarządzania procesami spółki. System SZPS pobierać będzie dokumenty wystawione w systemie ERP z poziomu dedykowanego miejsca w systemie, tworzy pismo i proceduje zgodnie z zamodelowanym procesem workflow

Rejestracja nowego interesanta Dodanie pisma Utworzenie wpisu w rejestrze Kontakty Windykacyjne Wysyłanie pisma (utworzenie wpisu w Rejestrze Korespondencji Wychodzącej)

2. Zamówienia wewnętrzne - Zamówienia wewnętrzne muszą być tworzone w systemie

System ERP, natomiast ze względu na fakt, iż istnieją różne procesy akceptacji dokumentów (zarówno ze względu na specyfikę organizacji, jak i typy dokumentów) konieczne jest umożliwienie definiowalnego procesu akceptacji w systemie SZPS. Zamówienie stworzone w systemie System ERP, po akceptacji przez osobę wprowadzającą, powinno trafić do Systemu Zarządzania Procesami Szpitala. W przypadku, gdy proces akceptacji zostanie zakończony, status zamówienia powinien zostać zaktualizowany w systemie System ERP.

Wykaz modułów Oprogramowania Aplikacyjnego:

Nazwa modułu ilość j.m. Opis odniesienie do zakresu funkcjonalnego

System wersja podstawowa 20 szt.

Dokumenty wpływające i wychodzące (Kancelaria),Obsługa spraw i dokumentów – przesyłki przychodzące,Obsługa spraw i dokumentów - akceptacje dokumentów,Obsługa spraw i dokumentów – sprawy,Podpis elektroniczny,Wzory dokumentów i korespondencja seryjna,Archiwum zakładowe,Interesanci.

Rejestry dedykowane 20 szt.

Faktury,Umowy,Rejestry definiowalne,Możliwość prowadzenia centralnego rejestru umów,wraz z możliwością kontrolowania stopnia,rozliczenia na podstawie rozliczanych faktur.

Integracja e-PUAP 20 szt.Integracja z platformą ePUAP,Możliwość podpięcia nieograniczonej ilości skrytek ePUAP.

Przepływ dokumentów 20 szt. Obsługa Pism Wewnętrznych,Automatyzacja procesów biznesowych.

Organizacja 20 szt.

Komunikator,Komunikaty i powiadomienia,Kalendarz,Zastępstwa,Tablica ogłoszeń,raportowanie i monitorowania,

Bezpieczeństwo 20 szt. Centrum certyfikacji,Bezpieczeństwo.

Integracja Infomedica 1 szt.Integracje z systemami zewnętrznymi,integracja z rejestrem zakupów oraz zamówień wewnętrznych w Infomedice.

Szkolenia 5 dzień

ze względu na sytuację dopuszcza się szkolenia zdalne, zapewniony trener na ilość wybranych dni, wybór narzędzia do prowadzenia szkolenia ustalany przed szkoleniami.

Gwarancja, asysta serwisowa, wsparcie techniczne - rozszerzona … mies. Na warunkach opisanych w SIWZ.

Zamawiający zastrzega sobie prawo do przeprowadzenia prezentacji oferowanego rozwiązania, przed wyborem najkorzystniejszej oferty, w celu potwierdzenia zgodności oferowanych funkcji Oprogramowania Aplikacyjnego z wymaganiami określonymi w dokumentacji przetargowej.

W celu potwierdzenia spełnienia minimalnych wymagań Zamawiający wezwie Wykonawcę do prezentacji funkcjonalności zaoferowanego systemu, zgodnie z zasadami określonymi poniżej:1. Wykonawca ma obowiązek stawienia się na prezentacji systemu w terminie wyznaczonym przez

Zamawiającego.2. Wezwanie Wykonawcy do przeprowadzenia prezentacji w siedzibie Zamawiającego nastąpi w

terminie wskazanym przez Zamawiającego w wezwaniu, tj. w terminie nie krótszym niż 10 dni.3. Wykonawca zobowiązany jest zapewnić niezbędny sprzęt i oprogramowanie niezbędne do

przeprowadzenia prezentacji. Zamawiający zapewni pomieszczenie wraz z dostępem do energii elektrycznej. Na prośbę Wykonawcy, istnieje możliwość udostępnienia przez Zamawiającego połączenia z siecią Internet o parametrach wskazanych przez Zamawiającego.

4. Jeżeli którakolwiek funkcjonalność nie zostanie zademonstrowana (nie zostanie zademonstrowany jeden lub więcej element do zrealizowania zgodnie z przedstawionymi scenariuszem lub też sposób jego realizacji będzie stał w sprzeczności z OPZ lub prezentacja elementu ujawni braki w funkcjonalności określonej w OPZ), Zamawiający uzna, że treść oferty nie odpowiedna treści SIWZ i odrzuci ofertę Wykonawcy na podstawie art. 89 ust. 1 pkt 2 ustawy Prawo zamówień publicznych.

5. Po wykonaniu prezentacji zostanie podpisany przez strony protokół przeprowadzenia prezentacji.

6. Prezentacja będzie się odbywać w dniach roboczych, w godzinach 08:00 — 14:00, jeżeli prezentacja nie zakończy się w ciągu jednego dnia, Zamawiający wyznaczy dodatkowy termin na dokończenie prezentacji.

7. Komisja przetargowa może w trakcie prezentacji zadawać Wykonawcy pytania celem weryfikacji. W trakcie testu Wykonawca może udzielać Zamawiającemu dodatkowych informacji związanych zweryfikowaną funkcjonalnością lub parametrami.

8. Wykonawca powinien w sposób jednoznaczny wykazać, że weryfikowana funkcjonalność jest dostępna w oprogramowaniu aplikacyjnym, oraz że wybrane przez Zamawiającego parametry oprogramowania aplikacyjnego są zgodne z wymaganiami opisanymi w SIWZ,

9. W przypadku gdy z winy Wykonawcy dojdzie do opóźnienia w terminie rozpoczęcia weryfikacji funkcjonalności przekraczającego 60 minut zegarowych, Komisja przetargowa uzna, że Wykonawca nie przystąpił do weryfikacji.

10. W uzasadnionych przypadkach, Zamawiający na wniosek Wykonawcy, może zmienić termin prezentacji, z zastrzeżeniem że przedmiotowy wniosek zostanie złożony najpóźniej do wyznaczonego pierwotnie terminu rozpoczęcia prezentacji,

11. wykonawca będzie zobowiązany przedstawić listę osób uczestniczących w prezentacji, ze wskazaniem jaką funkcję w prezentacji pełni każdy członek zespołu. W pomieszczeniu, gdzie będzie wykonywana prezentacja, może przebywać jednocześnie maksymalnie pięć osób po stronie Wykonawcy. Wykonawcę w czasie prezentacji reprezentuje osoba uprawniona do

działania w jego imieniu upoważniona na podstawie pełnomocnictwa załączonego do oferty lub złożonego przed rozpoczęciem prezentacji,

12. Weryfikacja funkcjonalności oprogramowania w formie prezentacji (testu) może być zarejestrowana przy użyciu kamery wideo wyłącznie przez Zamawiającego. Rejestracja wideo zostanie wykorzystana jako pomoc w sporządzeniu pisemnego protokołu 2 przeprowadzenia weryfikacji.

SCENARIUSZ PRZEZENTACJI SYSTEMU

Dla umożliwienia prawidłowego wykonania scenariusza Wykonawca przygotuje i dostarczy Zamawiającemu co najmniej cztery pisma w formie tradycyjnej adresowane bezpośrednio do Dyrektora, każde z załącznikiem (pisma nr 1 i 2 powinny być pismami interesantów niezarejestrowanych w bazie kontrahentów/interesantów, pisma nr 3 i 4 – interesantów już zarejestrowanych w bazie). Wygenerowany kod kreskowy identyfikujący użytkownika odbierającego korespondencje papierowa. Przygotowane środowisko testowe na Platforma Elektronicznego Fakturowania (PEF) z wprowadzoną i przekazaną przez wykonawcę na konto Urzędu minimum 1 fakturą. Skonfigurowane połączenie umożliwiające wymianę danych pomiędzy PEF a systemem PEF. Wprowadzone szablony opisu faktur. Wprowadzone do rejestru umów min. 2 umowy: umowa nr 1 i umowa nr 2, do których można przypisać faktury. Przygotowane w wewnętrznym centrum certyfikacji certyfikaty niekwalifikowane, wystawione dla użytkowników biorących udział w procesie akceptacji (zastrzega się możliwość weryfikacji poprawności działania centrum certyfikacji).

Należy wykonać następujące czynności:

Zalogowanie się w systemie jako pracownik kancelarii Szpitala.Przejście do funkcji rejestracji nowego pisma i dokonanie rejestracji pisma nr 1, w tym:• wprowadzenie nadawcy – dane osobowe przygotowane przez Wykonawcę – z wykorzystaniem podpowiedzi miejscowości i ulicy występującej w danej miejscowości ze słownika.• wprowadzenie opisu treści pisma: opis przygotowany przez Wykonawcę;• wykonanie skanowania pisma przygotowanego w formie papierowej i wprowadzenie do systemu zeskanowanego pisma (obie czynności wykonane bezpośrednio z systemu obiegu dokumentów);• wprowadzenie załącznika do pisma poprzez jego zeskanowanie z dokonaniem jego opisu.Powtórzenie ww. czynności dla pisma nr 2.Powtórzenie ww. czynności dla pism nr 3 i 4, z tą różnicą, że nadawców należy wprowadzić poprzez odszukanie ich danych w bazie interesantów.

Po dokonaniu rejestracji pism przejść do rejestru korespondencji przychodzącej i sprawdzić poprawność wpisów w odpowiednich komórkach dziennika.

Wydrukować dla jednego z pism potwierdzenie złożenia pisma wraz z załącznikami z nadrukowanym kodem kreskowym zawierającym ponadto:a. oznaczenie nadawcy (imię i nazwisko/nazwa, adres zamieszkania/siedziba),b. numer z dziennika korespondencji przychodzącej,c. data wpływu,d. ilość załączników.

Przejść do funkcji wyszukania pisma.Czytnikiem kodów kreskowych zeskanować kod kreskowy na potwierdzeniu złożenia pisma i odszukać pismo. Sprawdzić czy pismo zostało prawidłowo wyszukane w dzienniku korespondencji

przychodzącej.

Przekazać wcześniej wprowadzone pisma do dekretacji Dyrektorowi Wydziału. Potwierdzić odebranie wersji papierowej dla wszystkich pism za pomocą kodu kreskowego przypisanego dla dyrektora oraz zweryfikować poprawność wykonania operacji. Wylogować się.

Zalogować się w systemie obiegu dokumentów jako Dyrektor Wydziału.Przejść do funkcji dekretacji pisma.Zadekretować jedno pismo do trzech podległych komórek z zaznaczeniem jednej komórki wiodącej i dwóch komórek współpracujących.Zaznaczyć pozostałe pisma i zadekretować hurtowo do różnych komórek (do dwóch wydziałów po dwa pisma).

Zalogować się w systemie obiegu dokumentów jako kierownik komórki wskazany przy dekretacji jako pierwszy współpracujący, a następnie jako drugi współpracujący i sprawdzić poprawność wpisów.

Zalogować się w systemie obiegu dokumentów jako kierownik komórki wskazanego przy dekretacji jako wiodący.Dokonać zwrotu zadekretowanego pisma z komórki wiodącej z wpisaniem uwagi.

Zalogować się w systemie jako Dyrektor Wydziału.Ponownie zadekretować zwrócone pismo do tych samych trzech komórek z zaznaczeniem innej komórki jako wiodącej.

Zalogować się do systemie obiegu dokumentów kolejno jako kierownicy pozostałych komórek i dokonać odbioru pozostałych pism dekretowanych hurtowo.Sprawdzić poprawność wpisów.

Zalogować się w systemie obiegu dokumentów jako pracownik Kancelarii Szpitala.Bez wylogowania wejść na konto osoby zastępowanej i sprawdzić czy posiada ona pisma niezakończone.Powtórnie wejść na widok „swojego” konta.Sprawdzić poprawność wpisów oraz informacje „historyczne” zawarte w odpowiedniej kolumnie o dokonanych operacjach z poziomu dziennika korespondencji przychodzącej.Wylogować się.

Zalogować się w systemie jako użytkownik (pracownik referatu) z uprawnieniami do zakładania sprawy oraz zarządzania szablonami.

Przygotować szablon odpowiedzi:

dodać szablon odpowiedzi wykorzystując edytor tekstowy (MS word lub Libre writer), umieścić w nim znaczniki, dzięki którym dokument zostanie automatycznie wypełniony podczas generowania odpowiedzi dodanie znaczników określających min. aktualną datę, dane interesanta (nazwę oraz adres), dane sprawy (znak sprawy, tytuł sprawy, data założenia)

zapisać szablon jako osobisty (tylko dla pracownika, który go dodał), przypisać szablon do odpowiedniej kategorii JRWA (tak aby jego wybór wyświetlał się jedynie podczas tworzenia odpowiedzi jedynie dla tego konkretnego JRWA),

Odebrać pismo po dekretacji i założyć nową sprawę:• wybrać numer z JRWA uwzględniający symbol komórki i osoby,

• przygotować projekt odpowiedzi z wykorzystaniem zdefiniowanego szablonu, w którym automatycznie wypełnią się dane interesanta oraz wskazanie sprawy, której dotyczy pismo.

Użytkownik powinien dodać komentarz do sprawy będący inicjacja rozmowy z innymi użytkownikami z wykorzystaniem wewnętrznego komunikatora.

Powinna zostać przeprowadzona rozmowa z minimum 3 użytkownikami. Całość rozmowy powinna być przypisana do sprawy. I dostępna w każdym momencie pracy nad sprawą.

Dodatkowo użytkownik powinien opatrzyć pismo załączone do sprawy minimum 2 komentarzami. 1 Publiczny dostępny dla użytkowników mających dostęp do pisma, 2 prywatny dostępny dla użytkownika dodającego komentarz.

Przeprowadzić wielostanowiskową akceptację projektu odpowiedzi z uwzględnieniem hierarchii stanowisk w następującej kolejności działań:

przekazać projekt odpowiedzi do bezpośredniego przełożonego w celu akceptacji, zaakceptować odpowiedzi przez bezpośredniego przełożonego, poprzez parafowanie z

wykorzystaniem PINu certyfikatu niekwalifikowanego, wygenerowanego użytkownikowi za pomocą wewnątrz systemowego centrum certyfikacji.

przekazać zaakceptowany projekt odpowiedzi do Dyrektora Wydziału. odebrać pismo od Kierownika komórki z naniesionymi uwagami dotyczącymi konieczności

wprowadzenia zmian.Wprowadzić zmiany w projekcie pisma uwzględniając naniesione uwagi.Powtórzyć opisaną w pkt. powyżej wielostanowiskową akceptację z zatwierdzeniem przez Kierownika komórki z użyciem certyfikatu kwalifikowanego (w przypadku jeżeli prezentujący nie będzie dysponował certyfikatem kwalifikowanym dopuszczalne jest zademonstrowanie mechanizmu umożliwiającego podpisywanie dokumentów).Przygotować pismo do wysyłki (w formie elektronicznej, z podpisem elektronicznym i tradycyjnej - z podpisem odręcznym).Przekazać pisma do Kancelarii Urzędu.

Udostępnić utworzoną sprawę innym użytkownikom systemu

udostępnienie sprawy minimum 2 użytkownikom użytkownik nr 1 powinien otrzymać uprawnienia umożliwiające wgląd do akt sprawy w

zakresie: pismo nr 1 – jedynie wyświetlanie bez możliwości edycji oraz otwierania, pismo będące odpowiedzią – możliwość podglądu pisma, bez jego edycji. Dodatkowo użytkownik powinien mieć możliwość dodawania jedynie przesyłek wpływający.

Użytkownik nr 2 powinien otrzymać uprawnienia umożliwiające wgląd do akt sprawy w zakresie pismo nr 1 – ma być niewidoczne dla użytkownika, pismo będące odpowiedzią, powinno być jedynie wyświetlone, bez możliwości otwarcia. Użytkownik powinien mieć ograniczenie do dodawania jakichkolwiek dokumentów, powinien jednak mieć wgląd w listę pracowników zaangażowanych w sprawę oraz komentarzy, którymi sprawa została opatrzone.

Zakończyć sprawę w systemie obiegu dokumentów.Wyszukać sprawę w rejestrze spraw i sprawdzić poprawność wpisów oraz wyświetlić zapisy w historii sprawy.

Zalogować się w systemie jako pracownik kancelarii Urzędu.1. Przejść do funkcji pobierania faktur z Platformy Elektronicznego Fakturowania (PEF) – środowisko testowe:

zweryfikować czy na platformie znajduje się wcześniej wprowadzona faktura wykonawcy. pobrać fakturę z wykorzystaniem API, zarejestrować fakturę w rejestrze faktur.

2. Przejść do rejestru faktur:

zweryfikować poprawność rejestracji faktury otrzymanej z PEF, zarejestrować fakturę nr 1 oraz powiązać ją z umową nr 1 (faktura powinna mieć inny

termin płatności niżeli ten przypisany do umowy, jej wartość powinna być niższa niżeli całkowita wartość umowy nr 1). Zweryfikować mechanizm automatycznego sprawdzania poprawności terminu płatności. Dokonanie zmiany terminu na ten wynikający z zapisów umowy nr 1.

zarejestrować fakturę nr 2 z rozbiciem na pozycje kosztowe (4 szt,) oraz przypisanie miejsc powstawania kosztów dla poszczególnych pozycji kosztowych.

przekazać faktury PEF, nr 1 i nr 2 do akceptacji: merytorycznej, formalno-rachunkowej, do rozliczenia.

Zalogować się na użytkownika z uprawnieniami do „merytorycznej” akceptacji faktur.

sprawdzić poprawność przekazania faktury nr 1, zaakceptować przekazane faktury oraz opisać je z wykorzystaniem wcześniej

zdefiniowanych szablonów opisów (opis wstawiony z szablonu należy dostosować do danej faktury). Zaparafować akceptację z wykorzystaniem certyfikatu wystawionego przez wewnętrzne centrum certyfikacji.

zweryfikować poprawność przypisania faktur do umowy. Zweryfikować funkcjonalność śledzenia stopnia rozliczenia umowy.

Zalogować się na użytkownika z uprawnieniami do „formalno-rachunkowej” akceptacji faktur.

sprawdzić poprawność przekazania faktury nr 1, zaakceptować przekazane faktury oraz opisać je z wykorzystaniem wcześniej

zdefiniowanych szablonów opisów (opis wstawiony z szablonu należy dostosować do danej faktury). Zaparafować akceptację z wykorzystaniem certyfikatu wystawionego przez wewnętrzne centrum certyfikacji.

Zalogować się na użytkownika z uprawnieniami do „rozliczenie” faktur.

sprawdzić poprawność przekazania faktury nr 1, zaakceptować przekazane faktury oraz opisać je z wykorzystaniem wcześniej

zdefiniowanych szablonów opisów (opis wstawiony z szablonu należy dostosować do danej faktury). Zaparafować akceptację z wykorzystaniem certyfikaty wystawionego przez wewnętrzne centrum certyfikacji.

II. Wymagania w zakresie wdrożenia:

Zakres wdrożenia obejmuje:

Instalację i konfigurację dostarczanych modułów systemu. Parametryzację dostarczonych i wdrożonych modułów systemu. Uruchomienie środowiska testowego oferowanego rozwiązania. Integrację systemu SZPS z systemem ERP funkcjonującym u zamawiającego. Zamodelowanie procesów w tym m. In. Utworzeniu dedykowanych formularzy oraz

wprowadzenie szablonów dokumentów związanych z obsługiwanymi procesami (do 20 szt.), Uruchomienie komunikatora. Świadczenie asysty powdrożeniowej. Przeprowadzenie testów akceptacyjnych sparametryzowanego i skonfigurowanego

produkcyjnie oprogramowania. Przeprowadzenie szkoleń administratorów i użytkowników z dostarczanych modułów.

Wdrożenie i szkolenia:

1. Wykonawca zobowiązany jest do przeprowadzenia instruktażu z zakresu prawidłowej eksploatacji systemu. Instruktaż musi zostać przeprowadzony na dwóch poziomach: administratorów systemu i użytkownika systemu.

2. Instruktarz może mieć formę zdalną z wykorzystaniem narzędzi udostępnionych przez Wykonawcę.

3. Wykonawca oświadcza, że osoby prowadzące Instruktaż posiadają odpowiednią wiedzę i doświadczenia niezbędne do prowadzenia Instruktażu,

4. Wykonawca oświadcza, że osoby prowadzące Instruktaż brały udział we Wdrożeniu Systemu oraz szczegółowo znają jego właściwości oraz zastosowaną konfigurację.

5. Wykonawca uzgodni z Zamawiającym szczegółowy harmonogram Instruktażu.6. Sposób przeprowadzenia instruktarzu:

a. instruktaż prowadzony jest w środowisku testowym odpowiadającym rzeczywistemu środowisku pracy,

b. instruktaż odbywa się w dniach roboczych, tj. dniach od poniedziałku do piątku w godzinach 8-16,

c. o instruktażu Wykonawca powiadomi Zamawiającego na minimum 3 dni robocze przed planowanym terminem Instruktażu;

d. liczba osób korzystających z instruktażu ze strony Zamawiającego to maksymalnie 40 osób,

e. szkolenia dla użytkowników powinny zawierać zakres obsługi programu na danym stanowisku;

f. liczba osób szkolonych w grupie powinna mieścić się w przedziale 10-20 os.g. maksymalna ilość grup szkoleniowych to 4 grupy. h. maksymalny czas szkoleń przypadających na 1 grupę to 6 godz. (do wykorzystania w

ramach 1 dnia),i. łączna pula godzin do wykorzystania na szkolenia to 40 godz.

7. Zakres szkolenia dla użytkowników:a. zapoznanie z podstawowymi parametrami i własnościami dostarczonego systemu,b. szczegółowe omówienie zastosowanej konfiguracji systemu,c. szczegółowe omówienie wszystkich funkcjonalności systemu w zakresie niezbędnym

dla użytkownika, na określonym stanowisku.8. Zakres szkolenia dla administratorów:

a. zapoznanie się z zakresem szkolenia dla użytkowników,

b. szczegółowe omówienie narzędzi do administrowania systemem w tym zarządzanie polityką bezpieczeństwa oraz sposobów konfigurowania kopii bezpieczeństwa danych zawartych w systemie.

9. W trakcie Instruktażu musi zostać przekazana wiedza niezbędna do poprawnego korzystania z systemu, tworzenia i gromadzenia informacji związanych z wykonywaniem czynności służbowych, tworzeniem, gromadzeniem oraz przepływem dokumentów.

10. Szczegółowość i poziom Instruktażu dla administratorów Wykonawca musi dobrać tak, aby po odbyciu Instruktażu zespół osób był w stanie samodzielnie administrować dostarczonym systemem.

11. Wykonanie Instruktażu zostanie potwierdzone odpowiednim protokołem podpisanym przez obie Strony.

III. Wymagania w zakresie gwarancji.

1. Zakres i sposób świadczenia usług gwarancyjnego nadzoru autorskiego dla Oprogramowania Aplikacyjnego opisany jest w SIWZ Załączniku nr 2 do Umowy - warunki wsparcia gwarancyjnego

Załącznik nr 5 do SIWZ – wzór umowy Pakiet 4

UMOWA NR …………………

zawarta w dniu …………….. w ........................... w wyniku przeprowadzonego postępowania

o udzielenie zamówienia publicznego, w trybie przetargu nieograniczonego powyżej 214 000 euro pomiędzy:

..............................................................

Zwanym dalej ZAMAWIAJĄCYM reprezentowanym przez:

…………………………………………………………………………………………………………

wpisanym do Krajowego Rejestru Sądowego pod nr KRS: ……………………… lub wpisanym do ewidencji działalności gospodarczej prowadzonej przez …..…………….. pod nr.: …………..

zwanym dalej WYKONAWCĄ reprezentowanym przez:

1………………………………………………………………………………………………………

§ 1. Definicje1. Zgodnie z wynikiem postępowania o udzielenie zamówienia publicznego przeprowadzonego na

podstawie ustawy – Prawo zamówień publicznych, Wykonawca zobowiązuje się do wykonania w terminie do dnia ……… zadania pod nazwą ………………………. w pełnym zakresie określonym w SIWZ i w ofercie Wykonawcy z dnia ……….. oraz po cenach określonych w ofercie cenowej Wykonawcy.

2. Na potrzeby niniejszej umowy Strony nadają wymienionym niżej pojęciom następujące znaczenie:

Umowa Oznacza niniejszą umowę.

Oprogramowanie Aplikacyjne

- Oznacza programy komputerowe, wymienione w SIWZ, w tym Moduły dostarczone przez Wykonawcę na podstawie Umowy; Oprogramowanie Aplikacyjne jest utworem, w rozumieniu Ustawy o prawie autorskim i prawach pokrewnych, utrwalonym na nośnikach: magnetycznych lub optycznych i jest zapisem informatycznym procedur przetwarzania danych, uruchamianym w ramach poszczególnych Modułów.

Moduł (Aplikacja) - Oznacza wyodrębniona poprzez udzielenie licencji część Oprogramowania Aplikacyjnego - funkcjonalna część Oprogramowania Aplikacyjnego, charakteryzująca się spójnym zakresem merytorycznym realizowanych funkcji, wykonująca swoje procedury samodzielnie

(niezależnie) lub w interakcji z innymi Modułami wchodzącymi w skład Oprogramowania Aplikacyjnego;

Oprogramowanie Systemowe

- Oznacza programy komputerowe niezbędne do prawidłowego działania Oprogramowania Aplikacyjnego i komunikującego się z nim Oprogramowania bazodanowego, ale niewchodzące w skład Oprogramowania Aplikacyjnego, zainstalowane przez Zamawiającego na dedykowanych stacjach roboczych i serwerach;

Oprogramowanie bazodanowe

Oznacza motor bazy danych wykorzystywany przez oprogramowanie aplikacyjne w wersji aktualnej na dzień podpisania umowy

Projekt - Oznacza świadczenia Wykonawcy opisane w SIWZ (inaczej przedmiot umowy);

Serwer - Oznacza serwer (-y) sieciowy (-e) przekazany Wykonawcy przez Zamawiającego w celu realizacji umowy.

System Informatyczny

- Oznacza całość funkcjonujących u Zamawiającego urządzeń komputerowych i oprogramowania, w tym sieci komputerowe LAN i WAN, Serwery, dedykowane stacje robocze, inne stacje robocze, drukarki, Oprogramowanie Aplikacyjne, Oprogramowanie bazodanowe, Oprogramowanie Systemowe;

Usługi Wdrożeniowe/ Wdrożenie

- Oznacza usługi instalacyjne i konfiguracyjne świadczone przez Wykonawcę w odniesieniu do Oprogramowania Aplikacyjnego;

Kierowniku Projektu osoba ze strony Zamawiającego lub Wykonawcy, odpowiedzialna za realizację niniejszej Umowy;

Ilekroć w postanowieniach niniejszej umowy użyto pojęć wymienionych w ust. 2 niniejszego paragrafu, pojęciom tym nadaje się znaczenie określone powyżej, chyba, że określony termin został użyty w innym znaczeniu, co zostało wyraźnie zaznaczone w odpowiednim postanowieniu lub odmienne znaczenie danego pojęcia wynika z oczywistego kontekstu, w jakim zostało ono użyte w przedmiotowym postanowieniu, a Strony zgodne są, co do takiego znaczenia, odmiennego od określonego w ust. 2 niniejszego paragrafu.

§ 2. Przedmiot umowy1. Przedmiot niniejszej umowy obejmuje:

1) zakup licencji Oprogramowania Aplikacyjnego I. System Zarządzania Procesami Szpitala (SZPS),

2) instalację i konfigurację (wdrożenie) dostarczonego Oprogramowania Aplikacyjnego,

3) szkolenie personelu Zamawiającego,

4) objęcie dostarczonego Oprogramowania Aplikacyjnego min. ….. miesięcznym okresem gwarancyjnego nadzoru, na warunkach określonych w Załączniku nr 2 do Umowy,

5) przyjęcie przez wykonawcę zamówienia innych zobowiązań, o których mowa w SIWZ, i w niniejszej Umowie.

§ 3. Terminy realizacji umowy

1. Przedmiot umowy zostanie zrealizowany w ciągu …… dni licząc od daty podpisania umowy

2. Dla celów realizacji przedmiotu niniejszej umowy Kierownik Projektu po stronie Wykonawcy przygotuje szczegółowy harmonogram realizacji prac. Harmonogram zostanie sporządzony w porozumieniu z Zamawiającym w terminie 7 dni od daty podpisania Umowy.

3. Zamawiający zobowiązany jest, w terminie 7 dni od daty zawarcia niniejszej umowy:

1) udostępnić pomieszczenia niezbędne do realizacji umowy;

2) przekazać na piśmie Wykonawcy wszelkie dane dotyczące posiadanego sprzętu komputerowego i Systemu Informatycznego;

3) udostępnić Wykonawcy na czas realizacji Usług Wdrożeniowych Serwer (-y) i Dedykowane Stacje Robocze i inne urządzenia niezbędne do realizacji umowy.

4) przekazać na piśmie Wykonawcy wszelkie informacje i dane, konieczne dla prawidłowego zrealizowania usług.

4. W terminie 7 dni do daty spełnienia wszystkich wymagań określonych w ust. 3 niniejszego paragrafu Wykonawca przystąpi do wykonywania niniejszej umowy. W przypadku, gdy Wykonawca nie otrzyma wymaganych informacji określonych w ust. 3 niniejszego paragrafu terminy realizacji Projektu ulegają odpowiedniemu przesunięciu o liczbę dni pomiędzy wymaganym terminem wykonania przez Zamawiającego zobowiązań określonych w ust. 3, a rzeczywistym terminem ich wykonania.

5. Termin wykonania Projektu zostanie dotrzymany pod warunkiem realizacji przez Zamawiającego w wymaganych terminach wszystkich zadań określonych niniejszą umową, w szczególności w ustępach poprzedzających, jak również określonych przez Wykonawcę w harmonogramie szczegółowym. Jeżeli Zamawiający nie będzie wykonywać terminowo powołanych zadań, termin realizacji Projektu może ulec wydłużeniu z winy Zamawiającego.

6. Usługi gwarancyjnego nadzoru autorskiego Oprogramowania Aplikacyjnego, będą świadczone przez Wykonawcę w przez okres ….. miesięcy od daty podpisania protokołu odbioru licencji.

§ 4. Realizacja usług wdrożeniowych1. Licencje na korzystanie z Oprogramowania Aplikacyjnego udzielone zostaną na warunkach

określonych w załącznik nr 3 Umowy, z zastrzeżeniem, iż zobowiązania Wykonawcy dotyczące gwarancyjnego nadzoru autorskiego realizowane będą od daty podpisania protokołu odbioru końcowego.

2. Usługi Wdrożeniowe w tym wizyty instalacyjne, konfiguracyjne, odbywały się będą w pomieszczeniach Zamawiającego.

3. W przypadku braku gotowości Zamawiającego do wykonania zaplanowanych do realizacji w trakcie wizyty prac, Zamawiający zobowiązany jest do pisemnego i telefonicznego poinformowania o tym Kierownika Projektu po stronie Wykonawcy z co najmniej z 1 dniowym wyprzedzeniem. Strony uzgodnią w takim przypadku nowy termin wizyty.

4. Wykonanie Usług Wdrożeniowych dla wszystkich prac będzie potwierdzone odpowiednim protokołem.

5. Osobą odpowiedzialną za realizację niniejszej Umowy – Kierownikiem Projektu - po stronie Zamawiającego jest Jakub Kapuściński, tel. 052/325-59-00 e-mail: j.kapuscinski@wsoz.pl

6. Osobą odpowiedzialną za realizację niniejszej Umowy – Kierownikiem Projektu - po stronie Wykonawcy jest …………………., tel. …………………… e-mail: ……………………………….

7. Osoby wskazane w ust. 5 i 6 niniejszego paragrafu upoważnione są do dokonywania wiążących ustaleń w zakresie realizacji przedmiotu Umowy, podpisywania protokołów odbiorów oraz do zmiany harmonogramu realizacji przedmiotu Umowy. Zmiana osób, wskazanych w powyższych ustępach, nie stanowi zmiany niniejszej Umowy i jest skuteczna z dniem pisemnego powiadomienia drugiej strony.

§ 5. Procedura odbioru prac

1. Za datę wykonania przez Wykonawcę zobowiązań wynikających z realizacji Projektu przyjmuje się datę podpisania odbioru końcowego. Odbiór końcowy Przedmiotu Zamówienia ma na celu potwierdzenie odebrania wszystkich prac i dostaw oraz dostarczenia wymaganej zamówieniem Dokumentacji.

2. Strony przyjmują następującą procedurę odbioru:

1) Wykonawca zgłasza gotowość do odbioru przesyłając Zamawiającemu protokół odbioru.

2) Zamawiający jest zobowiązany, w terminie nie dłuższym niż 7 dni od daty zgłoszenia gotowości do odbioru, do przeprowadzenia odbioru, tj. sprawdzenia Oprogramowania Aplikacyjnego w oparciu o przeprowadzone testy.

3) Odbiór Usług wdrożeniowych przebiega w dwóch fazach. W pierwszej fazie odbioru weryfikowana jest zgodność konfiguracji z wytycznymi z audytu przedwdrożeniowego i organizacją pracy (weryfikacja techniczna konfiguracji oprogramowania). Odbiór ten powinien potwierdzić prawidłowość pracy Oprogramowania Aplikacyjnego od strony konfiguracyjnej. Druga faza odbioru Usług Wdrożeniowych polega na weryfikacji zgodności funkcjonowania danego Modułu Oprogramowania Aplikacyjnego z dokumentacją, tj. funkcjami określonymi w warunkach granicznych do SIWZ (weryfikacja istnienia danej funkcjonalności Oprogramowania Aplikacyjnego).

4) Przyczyną odmowy odbioru drugiej fazy odbioru Usług wdrożeniowych jest brak określonej w dokumentacji funkcji Oprogramowania Aplikacyjnego. Wadliwe działanie danej funkcjonalności usuwane będzie w uzgodnionych między stronami terminach lub w na zasadach usług nadzoru autorskiego.

5) Modyfikacje Oprogramowania Aplikacyjnego, polegające na zmianie sposobu działania Oprogramowania Aplikacyjnego względem wymaganych funkcji lub ustaleń wdrożeniowych, zgłaszane przez Zamawiającego przed lub podczas odbioru, nie będą miały wpływu na dokonanie odbioru. Zgłoszenia te mogą być realizowane przez Wykonawcę na podstawie odrębnych umów lub w trybie gwarancyjnego nadzoru autorskiego na zasadach określonych w Załączniku nr 4 do Umowy.

3. W wyniku przeprowadzonego odbioru Zamawiający zobowiązany będzie do:

1) podpisania protokołu odbioru, potwierdzającego realizację prac bez zastrzeżeń lub

2) podpisanie protokołu odbioru i zgłoszenia zastrzeżeń, w zakresie prac składających się na dany etap umowy. W takim przypadku Strony uzgodnią termin i zakres niezbędnych zmian. Wykonawca zobowiązany jest usunąć przyczynę zastrzeżeń w tak określonym terminie. Postanowienia ust. 5 niniejszego paragrafu stosuje się odpowiednio.

3) w przypadku zgłoszenia zastrzeżeń przez Zamawiającego co do danego zakresu prac, Strony postanawiają, że zrealizowane zobowiązania Wykonawcy, co do których nie zgłoszono zastrzeżeń, zostają uznane za odebrane. Ponowna procedura odbioru przeprowadzana będzie wyłącznie odnośnie zakresu prac, które zostały wykazane w protokole uwag. Ewentualne Błędy działania wcześniej odebranych funkcji realizowane będą zgodnie z warunkami obsługi błędów gwarancyjnego nadzoru autorskiego.

4. Niepodpisanie protokołu odbioru przewidzianych umową zadań, przez Zamawiającego lub nie podpisanie protokołu odbioru z zastrzeżeniami, w wyżej przewidzianym terminie 7 dni od daty zgłoszenia gotowości do odbioru, uznaje się za realizację etapu umowy. W takim przypadku jednostronnie podpisany przez Wykonawcę protokół odbioru jest skuteczny wobec Zamawiającego i wywołuje skutki przewidziane umową. Wykonawcy, w takim przypadku, przysługuje prawo do zgłoszenia Błędów Oprogramowania Aplikacyjnego w ramach gwarancyjnego nadzoru autorskiego, a wad sprzętu w trybie obsługi gwarancyjnej.

5. Ciężary i ryzyka związane ze stanowiącym przedmiot odbioru elementem Projektu przechodzą na Zamawiającego z chwilą przyjęcia od Wykonawcy danego elementu przedmiotu Umowy. Błędy Oprogramowania Aplikacyjnego ujawnione po tej dacie usuwane będą w trybie Nadzoru Autorskiego na zasadach określonych w załączniku nr 2 do Umowy.

§ 6. Płatności

1. Za realizację przedmiotu umowy, opisanego w niniejszej umowy, Zamawiający zapłaci Wykonawcy wynagrodzenie w wysokości:

2. ……………zł netto (słownie: ………………………) tj. …………. zł brutto (słownie: …………………….),

3. Rozliczenie za wykonane usługi i inne świadczenia nastąpi jedną fakturą wystawioną po zakończeniu wszelkich prac i dostaw będących przedmiotem umowy.

4. Wynagrodzenie będzie płatne w terminie ....... dni od daty wystawienia faktury VAT, na rachunek bankowy wskazany na fakturze.

5. Zmiana stawki podatku od towarów i usług (VAT) w trakcie obowiązywania niniejszej umowy, w odniesieniu do usług przewidzianych niniejszą umową, skutkuje, z dniem wejścia w życie nowej stawki VAT, zmianą wynagrodzenia brutto należnego wykonawcy oraz zmianą kalkulacji cenowej stanowiącej załącznik nr 1 do umowy w zakresie stawki VAT i nie wymaga aneksu do niniejszej umowy.

6. Za dzień zapłaty uznaje się datę obciążenia rachunku bankowego Zamawiającego.

§ 7. Zobowiązania Zamawiającego

1. Zamawiający zobowiązuje się dołożyć niezbędnych starań zmierzających do umożliwienia Wykonawcy sprawnego wykonywania postanowień niniejszej umowy, w szczególności poprzez udzielenie wszelkich niezbędnych informacji, jak również zapewni Wykonawcy dostęp do Systemu Informatycznego oraz Oprogramowania Systemowego, w tym niezbędnych urządzeń, na których będzie instalowane Oprogramowanie Aplikacyjne.

2. Zamawiający potwierdza, że dostarczane Oprogramowanie Aplikacyjne opisane w SIWZ, którego odbiór będzie potwierdzony protokołem odbioru zgodnie z warunkami niniejszej umowy spełnia wszystkie wymagania, w tym wymagania funkcjonalno-użytkowe określone przez Zamawiającego.

3. Zamawiający obowiązany jest zabezpieczyć posiadane przez siebie dane oraz oprogramowanie, znajdujące się bądź zainstalowane w Systemie Informatycznym, w szczególności poprzez:

1) Sporządzenie kopii zapasowych wszelkich danych oraz oprogramowania znajdujących się bądź zainstalowanych w Systemie Informatycznym, bezpośrednio przed udostępnieniem Systemu Informatycznego Wykonawcy (backup),

2) Regularne (co najmniej raz dziennie lub częściej w przypadku istotniejszych operacji) sporządzanie kopii zapasowych wszelkich danych oraz oprogramowania znajdujących się bądź zainstalowanych w Systemie Informatycznym w trakcie wykonywania niniejszej umowy.

§ 8. Siła Wyższa

1. Żadna ze Stron Umowy nie będzie odpowiedzialna za niewykonanie lub nienależyte wykonanie zobowiązań wynikających z Umowy spowodowane przez okoliczności traktowane jako Siła Wyższa. Przez Siłę Wyższą rozumie się zdarzenia pozostające poza kontrolą każdej ze Stron, których nie mogły one przewidzieć ani zapobiec, a które zakłócają lub uniemożliwiają realizację Umowy.

2. W przypadku zaistnienia Siły Wyższej, Strona, której taka okoliczność uniemożliwia lub utrudnia prawidłowe wywiązanie się z jej zobowiązań niezwłocznie nie później jednak niż w ciągu 14 dni, powiadomi drugą Stronę o takich okolicznościach i ich przyczynie.

3. Jeżeli Siła Wyższa, będzie trwała nieprzerwanie przez okres 90 dni lub dłużej, Strony mogą w drodze wzajemnego uzgodnienia rozwiązać Umowę, bez nakładania na żadną ze Stron dalszych zobowiązań, oprócz płatności należnych z tytułu wykonanych usług.

4. Okres występowania Siły Wyższej powoduje odpowiednie przesunięcie terminów realizacji usług określonych w Umowie, zastrzeżeniem, że termin zakończenia realizacji Projektu musi umożliwić Zamawiającemu rozliczenie dotacji.

§ 9. Ochrona Danych OsobowychWarunki i zasady dostępu, przetwarzania i ochrony Danych osobowych określone zostały w załączniku nr 5 niniejszej Umowy.

§ 10. Poufność

1. Umowa jest jawna i podlega udostępnianiu na zasadach określonych w przepisach prawa regulujących dostęp do informacji publicznej. Nie mniej jednak, z zastrzeżeniem wyjątków przewidzianych w Umowie, stronom nie wolno, bez uprzedniej pisemnej zgody drugiej strony, ujawnić jakiejkolwiek osobie trzeciej następujących informacji:

1) know–how, zastosowanych metodologii, procedur, algorytmów wykorzystanych przy realizacji Umowy oraz kodów źródłowych tego Oprogramowania Aplikacyjnego;

2) dokumentów sporządzonych w trakcie realizacji Umowy, takich jak scenariusze testowe, 3) innych informacji i danych, co do których Strona podjęła działania zmierzające do ochrony

przed ujawnieniem osobom trzecim;2. Zobowiązanie powyższe nie dotyczy sytuacji udostępnienia informacji poufnych upoważnionym

władzom lub organom administracyjnym, na ich prawnie uzasadnione żądanie.

3. Strony odpowiadają za zachowanie zasad poufności, określonych w niniejszym artykule, przez wszystkie osoby, którymi posługują się przy wykonywaniu Umowy.

4. Postanowienia niniejszego paragrafu obowiązują również po wygaśnięciu lub rozwiązaniu niniejszej umowy.

§ 11. Kary umowne1. Zamawiający zastrzega sobie stosowanie kar umownych w następujących przypadkach

i wysokościach:

1) w przypadku odstąpienia od umowy przez Zamawiającego z winy Wykonawcy, Zamawiającemu przysługuje kara umowna w wysokości 100% łącznej wartości umowy z podatkiem VAT,

2) w przypadku odstąpienia od umowy przez Wykonawcę z winy Wykonawcy, Zamawiającemu przysługuje kara umowna w wysokości 100% łącznej wartości umowy z podatkiem VAT,

3) za zwłokę z tytułu nieterminowego wykonania realizacji umowy, Zamawiającemu przysługuje kara umowna w wysokości 0,2% wartości netto umowy, za każdy dzień zwłoki,

4) za zwłokę w usunięciu przez Wykonawcę Awarii, Błędów krytycznych (w rozumieniu Załącznika nr 2 do Umowy) stwierdzonych w okresie świadczenia gwarancyjnego nadzoru autorskiego i serwisu gwarancyjnego, Zamawiającemu przysługuje kara umowna w wysokości 0,02% wartości netto Umowy, za każdy dzień zwłoki, licząc od dnia wyznaczonego na usunięcie błędu.

5) za zwłokę w usunięciu przez Wykonawcę Błędów zwykłych i Usterek (w rozumieniu Załącznika nr 2 do Umowy) stwierdzonych w okresie świadczenia gwarancyjnego nadzoru autorskiego i serwisu gwarancyjnego, Zamawiającemu przysługuje kara umowna w wysokości 0,01% wartości netto Umowy, za każdy dzień zwłoki, licząc od dnia wyznaczonego na usunięcie błędu/wady.

295.1. W razie wystąpienia zwłoki w płatności Zamawiający zapłaci Wykonawcy odsetki ustawowe.

295.2. Łączna wartość kar umownych, o których mowa w ust.1 nie może przekroczyć 100% wynagrodzenia brutto, należnego Wykonawcy z tytułu realizacji Projektu.

295.3. Naliczone przez Zamawiającego kary umowne płatne są w terminie 14 dni od dnia doręczenia wezwania do ich zapłaty.

295.4. Wykonawca wyraża zgodę na dokonanie potrącenia ewentualnych kar umownych z wynagrodzenia, o którym mowa w § 6.

§ 12. Odpowiedzialność

1. Strony nie ponoszą odpowiedzialności za niewykonanie lub nienależyte wykonanie Umowy, jeżeli zostało to spowodowane przyczynami o charakterze siły wyższej rozumianej jako zdarzenie zewnętrzne, którego skutków nie da się przewidzieć i nie można im zapobiec i które bezpośrednio uniemożliwia stronie umowy wykonanie obowiązków przewidzianych umową.

2. Żadna ze Stron nie ponosi odpowiedzialności za niewykonanie lub niewłaściwe wykonanie zobowiązań z Umowy, które spowodowane były nieterminowym wywiązaniem się ze zobowiązań drugiej Strony.

3. Strony nie ponoszą odpowiedzialności za szkody polegające na utracie przez drugą Stronę korzyści, które ta Strona uzyskałby, gdyby szkody nie wyrządzono.

4. Odpowiedzialność Wykonawcy za szkody powstałe w związku lub na skutek realizacji Umowy ograniczone są do 100% wartości przedmiotu Umowy brutto.

5. Zamawiający wymaga objęcia dostarczonego sprzętu 12 miesięcznym okresem rękojmi.

§ 13. Autorskie prawa majątkowe

1. W ramach wynagrodzenia, o którym mowa w § 6 Umowy, Wykonawca przenosi na Zamawiających autorskie prawa majątkowe do korzystania i rozporządzania utworami dedykowanymi, tj. wytworzonymi wyłącznie na potrzeby realizacji przedmiotu Umowy, powstałymi w wyniku wykonania niniejszej Umowy (dalej zwanymi „utworami dedykowanymi”).

2. Wykonawca udziela Zamawiającym prawa do korzystania i rozporządzania utworami dedykowanymi, na wszelkich polach eksploatacji niezbędnych dla korzystania z Przedmiotu Umowy zgodnie z jego przeznaczeniem opisanym w treści Umowy i OPZ, w tym w szczególności na następujących polach eksploatacji:

1) trwałe lub czasowe zwielokrotnianie programu komputerowego (utworu dedykowanego) w całości lub w części jakimikolwiek środkami i w jakiejkolwiek formie; Wykonawca wyraża zgodę na zwielokrotnianie programu komputerowego dla potrzeb jego wprowadzania, wyświetlania, stosowania, przekazywania i przechowywania,

2) tłumaczenia, przystosowywania, zmiany układu lub jakichkolwiek innych zmian w programie komputerowym (utworze dedykowanym),

3) rozpowszechniania, w tym użyczenia lub najmu, programu komputerowego (utworu dedykowanego) lub jego kopii,

4) wykonywanie kopii zapasowych utworów dedykowanych, 5) modyfikacji lub wprowadzania zmian do utworów dedykowanych po upływie okresu

gwarancyjnego nadzoru autorskiego, zgodnie z przekazanymi kodami źródłowymi do utworów.3. Wykonawca udziela Zamawiającemu prawa zależnego do opracowania programów

komputerowych (utworów dedykowanych).

4. Przeniesienie autorskich praw majątkowych do utworów dedykowanych, o których mowa w ust. 1 niniejszego paragrafu następuje z chwilą podpisania Protokołu Odbioru końcowego, o którym mowa w § 6 Umowy, bez ograniczeń co do terytorium, czasu lub liczby egzemplarzy, w zakresie wszystkich pól eksploatacji wymienionych w ust. 2.

5. W ramach wynagrodzenia, o którym mowa w § 6 Umowy, Wykonawca przenosi na Zamawiających prawo zezwalania na wykonywanie zależnego prawa autorskiego do utworów dedykowanych. Wykonawca udziela Zamawiającym nieodwołalnej zgody na dokonywanie przez Zamawiających dowolnych zmian w utworach, do których Zamawiający nabył autorskie prawa majątkowe na podstawie niniejszej Umowy.

6. Z chwilą podpisania Protokołu odbioru końcowego, Zamawiający nabywa własność wszystkich egzemplarzy dokumentacji, dedykowanej i wytworzonej w celu realizacji Umowy, na których rezultaty przedmiotu Umowy zostały utrwalone.

7. Wykonawca oświadcza, że posiada autorskie prawa majątkowe do Oprogramowania Aplikacyjnego, którego dotyczy niniejsza Umowa oraz posiada prawo do czerpania wynagrodzenia za korzystanie z niego przez osoby trzecie.

8. Oprogramowanie Aplikacyjne, którego dotyczy niniejsza Umowa jest chronione prawem autorskim wynikającym z przepisów Ustawy z dnia 4 lutego 1994 roku o prawie autorskim i prawach pokrewnych (Dz. U. 2017 r. poz. 880). Zamawiający i Wykonawca zobowiązują się do respektowania tych praw niezależnie od powstałych okoliczności.

9. Zasady korzystania z Oprogramowania Aplikacyjnego reguluje odrębna umowa licencyjna.

§ 14. Zmiany postanowień Umowy

1. Zamawiający dopuszczają zmianę treści Umowy w następujących przypadkach:

1) w przypadku zmiany wysokości podatku VAT, jeżeli w okresie obowiązywania umowy nastąpi zmiana przepisów prawa podatkowego, w zakresie determinowanym tymi zmianami,

2) w przypadku działania siły wyższej, przez którą należy rozumieć zdarzenia zewnętrzne charakterze niezależnym od stron, których strony nie mogły przewidzieć przed zawarciem Umowy, których nie można było uniknąć, ani którym strony nie mogły zapobiec przy zachowaniu należytej staranności, w zakresie determinowanym wystąpieniem siły wyższej,

3) w zakresie zmiany terminu realizacji przedmiotu Umowy w przypadku zaistnienia przestojów i opóźnień z przyczyn leżących po stronie danego Zamawiającego, mających bezpośredni wpływ na termin wykonania Przedmiotu Umowy; w takim przypadku strony dopuszczają wydłużenie okresu realizacji Umowy o okres zaistniałych opóźnień,

4) w przypadku zmian/wejścia w życie powszechnie obowiązujących przepisów prawa, w tym w szczególności przepisów wykonawczych zawierających regulacje z zakresu e-zdrowia; zmiany w takim przypadku zostaną wprowadzone w zakresie koniecznym do dostosowania przedmiotu Umowy do obowiązującego stanu prawnego,

5) uzyskania przez Zamawiającego zgody na zmianę terminu zakończenia rzeczowej realizacji Projektu lub terminu zakończenia realizacji Projektu,

6) w zakresie zmiany Umowy co do osób, które będą uczestniczyć w wykonywaniu zamówienia, wskazanych w wykazie osób załączonym do oferty Wykonawcy, zmiana osoby może nastąpić za zgodą Zamawiającego wyrażoną na piśmie; warunkiem akceptacji zmiany przez Zamawiającego, jest wskazanie przez Wykonawcę nowej osoby posiadającej odpowiednie kwalifikacje zawodowe i doświadczenie co najmniej takie same jak określone w opisie warunków udziału w postępowaniu,

7) zmiany Umowy w przypadku zmian podmiotowych stron Umowy w wyniku przekształcenia podmiotowego (następstwa prawnego),

8) korygowania oczywistych omyłek pisarskich i rachunkowych w treści Umowy.

§ 15. Rozwiązanie Umowy, Odstąpienie od Umowy

1. Zamawiający może rozwiązać Umowę ze skutkiem natychmiastowym w przypadku:

1) jeżeli Wykonawca przerwał realizację przedmiotu Umowy w stosunku do Zamawiającego na okres dłuższy niż 7 dni, z przyczyn leżących po stronie Wykonawcy,

2) jeżeli Wykonawca wykonuje przedmiot umowy w stosunku do Zamawiającego wadliwie lub w sposób sprzeczny z umową i pomimo wezwania do zmiany sposobu wykonania i wyznaczenia Wykonawcy w tym celu odpowiedniego terminu, Wykonawca nadal nie wywiązuje się należycie ze zobowiązań wynikających z umowy,

3) jeżeli na skutek postępowania egzekucyjnego nastąpiło zajęcie majątku Wykonawcy w takim stopniu, że zagraża to lub uniemożliwia dalszą realizację przedmiotu Umowy.

2. W razie zaistnienia istotnej zmiany okoliczności powodującej, że wykonanie Umowy nie leży w interesie publicznym, czego nie można było przewidzieć w chwili zawarcia Umowy, Zamawiający może odstąpić od Umowy w terminie 30 dni od powzięcia wiadomości o tych okolicznościach. Wówczas Wykonawca może żądać wyłącznie wynagrodzenia należnego z tytułu wykonania przez niego części Umowy.

3. W terminie 5 dni roboczych od daty doręczenia Wykonawcy oświadczenia o rozwiązaniu Umowy/odstąpieniu od Umowy, Wykonawca przy udziale Zamawiającego sporządzi szczegółowy protokół inwentaryzacji prac w toku, według stanu na dzień odstąpienia lub rozwiązania oraz zabezpieczy przerwane prace. Prace określone w tym protokole podlegają odbiorowi na zasadach określonych w § 5 Umowy.

4. W przypadku odstąpienia od umowy na podstawie ust. 2 powyżej, Wykonawca uprawniony będzie do otrzymania wynagrodzenia odpowiadającego proporcjonalnie wartości prac wykonanych do dnia odstąpienia.

§ 16. Postanowienia końcowe

1. Wszelkie zmiany niniejszej umowy wymagają formy pisemnej pod rygorem nieważności.

2. Strony będą dążyć do polubownego rozstrzygnięcia wszelkich sporów, jakie mogą wyniknąć w związku z interpretacją lub wykonywaniem niniejszej Umowy.

3. Ewentualne spory wynikające z niniejszej umowy rozstrzygać będzie Sąd właściwy dla siedziby Zamawiającego.

4. W sprawach nie uregulowanych niniejszą umową stosuje się przepisy Kodeksu Cywilnego i przepisy ustawy – Prawo zamówień publicznych.

5. Integralną część umowy stanowią załączniki:

c) Załącznik nr 1 do Umowy - kalkulacja cenowa,

d) Załącznik nr 2 do Umowy - warunki wsparcia gwarancyjnego,

e) Załącznik nr 3 do Umowy - warunki Licencyjne,

f) Załącznik nr 4 do Umowy - warunki zdalnego dostępu,

g) Załącznik nr 5 do Umowy - ochrona danych osobowych.

h) Załącznik nr 6 do Umowy – Szczegółowy Opis Przedmiotu Zamówienia.

6. Umowę sporządzono w dwóch jednobrzmiących egzemplarzach, po jednym dla każdej ze stron.

ZAMAWIAJĄCY WYKONAWCA

Załącznik nr 1 do Umowy - kalkulacja cenowa

L. p. Nazwa Ilość Jednostka

Cena jedn, netto

Cena jedn.

Brutto

Wartość netto

Wartość brutto

System wersja podstawowa 20 jednoczesnych użytkowników/

wsparcie techniczne min.

36 miesięcy

szt.

Rejestry dedykowane 20 jednoczesnych użytkowników/

wsparcie techniczne min.

36 miesięcy

Integracja e-PUAP 20 jednoczesnych użytkowników/

wsparcie techniczne min.

36 miesięcy

Przepływ dokumentów 20 jednoczesnych użytkowników/

wsparcie techniczne min.

36 miesięcy

szt.

Organizacja 20 jednoczesnych użytkowników/

wsparcie techniczne min.

36 miesięcy

szt.

Bezpieczeństwo 20 jednoczesnych użytkowników/

wsparcie techniczne min.

36 miesięcy

szt.

Integracja Infomedica 1 jednoczesnych użytkowników/

wsparcie techniczne min.

36 miesięcy

Szkolenia 5 dzień

Warto pakietu nr 4

Załącznik nr 2 do Umowy - warunki wsparcia gwarancyjnego

Warunki świadczenia usług gwarancyjnego nadzoru autorskiego

l) Strony ustalają następujące definicje pojęć: Oprogramowanie Aplikacyjne – programy komputerowe dostarczone przez Wykonawcę

w celu realizacji zamówienia, w wyłączeniem Systemów komputerowych Funkcja - wydzielona część Oprogramowania Aplikacyjnego

również: procedura, podprogram). Funkcjonalność – to zdolność Oprogramowania Aplikacyjnego do dostarczenia zbioru

operacji/działań/Funkcji zaspokajających wyznaczone i zakładane potrzeby, podczas używania go w określonych warunkach.

Nowa funkcjonalność – dodatkowa, nieistniejąca do tej pory w Oprogramowaniu Aplikacyjnym Funkcjonalność, wykonana lub dostarczona jako rozbudowa Oprogramowania Aplikacyjnego w ramach usług nadzoru autorskiego, lub odpłatnie

Modyfikacja – przebudowa istniejących w Oprogramowaniu Aplikacyjnym, wybranych Funkcji, polegająca na zmianie sposobu wprowadzania, przetwarzania lub prezentowania danych przez Oprogramowanie Aplikacyjne;

Błąd – niespowodowane przez użytkownika powtarzalne działanie Oprogramowania Aplikacyjnego, w tym samym miejscu programu, prowadzące w każdym przypadku do otrzymania błędnych wyników jego działania, udokumentowane, co najmniej poprzez opis ścieżki powtórzenia, zapisy logów systemowych lub zrzuty ekranów. Wszelkie uwagi związane z wyglądem, estetyką bądź przyzwyczajeniami użytkownika (Zamawiającego) oraz uwagi dotyczące rozbudowy lub ograniczenia Funkcjonalności nie są traktowane jako Błędy;

Błąd krytyczny – jest to Błąd, który uniemożliwia użytkowanie Oprogramowania Aplikacyjnego (w zakresie jego podstawowych Funkcji wskazanych w Dokumentacji użytkownika) i prowadzi do zatrzymania jego eksploatacji, utraty danych lub naruszenia ich spójności, w wyniku których niemożliwe jest prowadzenie działalności z użyciem Oprogramowania Aplikacyjnego;

Błąd zwykły – każdy Błąd inny niż Błąd krytyczny; Dokumentacja, Dokumentacja użytkownika – sporządzony w formie elektronicznej, w

języku polskim, opis Funkcjonalności, Funkcji, działań etc. Oprogramowania Aplikacyjnego, o jednolitym wyglądzie, spójny we wszystkich elementach;

Czas reakcji – czas pomiędzy otrzymaniem przez Wykonawcę zgłoszenia na witrynie internetowej Help-Desk lub na formularzu przesłanym faksem/pocztą elektroniczną, a podjęciem czynności zmierzających do usunięcia zgłoszonego Błędu / Awarii przez Wykonawcę.

Korekta – uaktualnienie Oprogramowania Aplikacyjnego eliminujące dotychczasowe nieprawidłowości (Błędy) w jego działaniu;

Rozwiązanie tymczasowe – sposób usunięcia Błędu krytycznego, pozwalający na realizację zadań Zamawiającego, z pominięciem lub ograniczeniem Funkcjonalności Oprogramowania Aplikacyjnego zawierającej Błąd krytyczny, obejmujący: procedury, programy komputerowe, urządzenia lub inne środki użyte w celu zapewnienia realizacji zadań wykonywanych przez Oprogramowanie Aplikacyjne;

Konsultacja – udzielenie informacji, w formie pisemnej, telefonicznej lub elektronicznej, w zakresie sposobów rozwiązania zgłoszonego problemu lub w zakresie uszczegółowienia informacji, które zostały umieszczone w zgłoszeniu Błędu;

Użytkownik – osoba upoważniona przez Zamawiającego do korzystania z programu.

Gotowość do świadczenia usług - dostępność pracowników Wykonawcy lub jego przedstawicieli, do zapewnienia ciągłości pracy Oprogramowania Aplikacyjnego u Zamawiającego, w godzinach pracy Wykonawcy;

Dzień roboczy – dzień tygodnia, od poniedziałku do piątku włącznie, z wyłączeniem dni ustawowo wolnych od pracy.

Godziny robocze – czas pracy Wykonawcy od 8:00 do 16:00 w Dni robocze. Oprogramowanie bazodanowe – oprogramowanie komputerowe zapewniające

techniczne możliwości bezpiecznego autoryzowanego dostępu, gromadzenia oraz przetwarzania danych opisowych oraz gromadzenia (indeksowania) i poprawnego topologicznie zapisu danych. Stanowi ono tzw. systemy zarządzania bazą danych;

System komputerowy – działające na tym samym komputerze fizycznym lub wirtualnym, na którym jest uruchamiane Oprogramowanie Aplikacyjne, oprogramowanie osób trzecich, np. systemy operacyjne (Oprogramowanie Systemowe), Oprogramowanie bazodanowe (motor bazy danych) oprogramowanie użytkowe (aplikacje). Wykonawca nie dostarcza Oprogramowania Systemowego i Oprogramowania bazodanowego w ramach wykonania Umowy.

m) W ramach gwarancyjnego nadzoru autorskiego, Wykonawca zapewnia: udostępnienie poprawek do Oprogramowania Aplikacyjnego, w przypadku stwierdzenia

przez Zamawiającego nieprawidłowego działania Oprogramowania Aplikacyjnego:i. w przypadku tzw. Błędu krytycznego:

1. czas reakcji Wykonawcy na zgłoszenie Zamawiającego wynosi 1 dzień roboczy;2. czas dokonania i udostępnienia Zamawiającemu odpowiednich korekt

Oprogramowania Aplikacyjnego wyniesie do 3 dni roboczych, od chwili rozpoczęcia czynności serwisowych;

3. w przypadku wystąpienia „Błędu krytycznego” Wykonawca może wprowadzić tzw. rozwiązanie tymczasowe, doraźnie rozwiązujące problem Błędu krytycznego; w takim przypadku dalsza obsługa usunięcia dotychczasowego Błędu krytycznego będzie traktowana jako błąd zwykły;

ii. w pozostałych przypadkach, określanych jako „Błędy zwykłe”:1. czas reakcji Wykonawcy na zgłoszenie Zamawiającego wynosi do 15 dni

roboczych;2. czas dokonania i udostępnienia Zamawiającemu odpowiednich korekt

Oprogramowania Aplikacyjnego wyniesie do 30 dni roboczych od chwili rozpoczęcia czynności serwisowych;

iii. Zamawiający udostępni Wykonawcy zdalny dostęp do baz danych i Oprogramowania Aplikacyjnego. W przypadku braku możliwości udostępnienia zdalnego dostępu czas reakcji oraz czas naprawy ulega wydłużeniu o czas oczekiwania na udostępnienie przez Zamawiającego kopii bazy danych i czas niezbędny na jej uruchomienie w siedzibie Wykonawcy

iv. w wyjątkowych wypadkach, za zgodą Zamawiającego, czas dokonania korekt będzie uzgodniony pomiędzy Wykonawcą i Zamawiającym;

v. czas reakcji i czas dokonania i udostępnienia Zamawiającemu odpowiednich korekt Oprogramowania Aplikacyjnego ulega zawieszeniu na okres oczekiwania na przedstawienie przez Zamawiającego uzupełniających informacji niezbędnych do usunięcia Błędu liczony od momentu wystąpienia z mailowym zapytaniem lub zapytaniem o dodatkowe informacje przez wykonawcę do momentu udzielenia odpowiedzi.

wprowadzanie zmian w Oprogramowaniu Aplikacyjnym objętym niniejszą Umową, w zakresie wymaganym zmianami powszechnie obowiązujących przepisów prawa lub przepisów prawa wewnętrznie obowiązujących u Zamawiającego, wydanych na podstawie delegacji ustawowej, o których Wykonawca zostanie poinformowany.

udostępniania uaktualnień Oprogramowania Aplikacyjnego (nowych wersji Oprogramowania Aplikacyjnego) poprzez serwer ………., przy czym na pisemne życzenie

Zamawiającego, Wykonawca zobowiązuje się przygotować i wysłać na adres Zamawiającego nośnik CD/DVD zawierający nową wersję Oprogramowanie Aplikacyjnego;

n) Zgłoszenia przez Zamawiającego ewentualnych Błędów, o których mowa w ust. 2, będą obsługiwane zgodnie z procedurą obsługi zgłoszeń zespołu serwisowego Wykonawcy, według następujących zasad:

a. Zamawiający zobowiązany jest do rejestrowania zgłoszeń poprzez witrynę internetową …….; b. w razie trudności z rejestracją zgłoszenia na w/w witrynie internetowej, Zamawiający może

dokonać zgłoszenia pisemnie na formularzu przesyłanym przy użyciu poczty elektronicznej na adres: …………., faksem na poniższe numery faksu lub telefonicznie pod poniższymi numerami telefonów (z zastrzeżeniem niezwłocznego potwierdzenia zgłoszenia przez e-mail lub faks): ……………………………………………………………………………………………………….;wypełnienie jednego formularza może dotyczyć tylko jednego rodzaju problemu występującego w konkretnym module.

c. w przypadku, gdy formularz zgłoszenia serwisowego zostanie przyjęty przez Wykonawcę:i. w godzinach pomiędzy 16.00 a 24.00 dnia roboczego – traktowany jest jak przyjęty o

godz. 8.00 następnego dnia roboczego;ii. w godzinach pomiędzy 0.00 a 8.00 dnia roboczego - traktowany jest jak przyjęty o godz.

8.00 danego dnia roboczego;iii. w dniu ustawowo lub dodatkowo wolnym od pracy - traktowany jest jak przyjęty o godz.

8.00 najbliższego dnia roboczego;

o) Zobowiązania Wykonawcy, o których mowa w ust. 2 i 3 będą wykonywane pod warunkiem realizacji przez Zamawiającego następujących zobowiązań:

o wykonywania czynności zaleconych przez Wykonawcę, w szczególności czynności związanych z bezpieczeństwem pracy systemu i bezpieczeństwem danych gromadzonych w systemie;

o powstrzymania się od samodzielnego lub przy udziale osób trzecich dokonywania jakichkolwiek zmian w konfiguracji oprogramowania lub sprzętu komputerowego, na którym wykorzystywane jest Oprogramowanie Aplikacyjne objęte niniejszą Umową, w tym Zamawiający zobowiązuje się nie dokonywać nieautoryzowanych przez Wykonawcę modyfikacji zawartości baz danych Oprogramowania Aplikacyjnego; w przypadku zaistnienia takiej potrzeby Wykonawca dopuszcza zmiany konfiguracji Oprogramowania Aplikacyjnego lub sprzętu komputerowego, ale muszą one zostać wcześniej zgłoszone Wykonawcy, a wszelkiego rodzaju zmiany muszą być wykonywane za uprzednią wyraźną zgodą Wykonawcy;

o prowadzenia rejestru kontaktów z Wykonawcą oraz z Zamawiającym, obejmującego w szczególności rozmowy telefoniczne, wysyłane faksy i pisma, zmiany konfiguracji Oprogramowania Aplikacyjnego oraz wykonane czynności;

o dostarczenia na wniosek Wykonawcy wskazanych fragmentów lub całości baz danych Oprogramowania Aplikacyjnego, w przypadku uzasadnionej potrzeby ich użycia do prawidłowej realizacji przedmiotu niniejszej Umowy poza siedzibą Zamawiającego, przy zachowaniu poniższej procedury:Uprawiony pracownik Zamawiającego przekaże bazę danych Wykonawcy poprzez jej skopiowanie na serwer SFTP o adresie ………………., w pliku archiwum (np. w formacie zip) zabezpieczonym hasłem (minimum 12 znakowym, uwzględniającym minimum 2 znaki specjalne i minimum 2 cyfry). Hasło do pliku archiwum zawierającego bazę danych będzie przekazywane SMS'em osobie ze Strony Wykonawcy, która wnioskowała o udostępnienie bazy danych. Zaszyfrowany plik archiwum z bazą danych będzie skopiowany przez pracownika Zamawiającego do katalogu domowego Zamawiającego na wskazanym wyżej serwerze SFTP, skąd będzie go mógł pobrać pracownik Wykonawcy, wnioskujący o udostępnienie bazy danych.

Dostęp do serwerów SFTP wymaga uwierzytelnienia identyfikatorem i hasłem. Każdy użytkownik zarówno ze strony Zamawiającego, Wykonawcy, chcący skorzystać z zasobów serwera i mając do tego uprawnienie wynikające ze wskazania go w Dodatku nr 1 i 2, będzie zobowiązany do posiadania własnego identyfikatora.;

o delegowania i upoważnienia pracowników do współpracy z Wykonawcą; o zapewnienia, aby Oprogramowanie Aplikacyjne, zainstalowane u Zamawiającego, było

używane wyłącznie przez użytkowników upoważnionych przez Zamawiającego do korzystania z ww. oprogramowania zgodnie z dokumentacją i instrukcjami Wykonawcy;

o dokonywania zgłoszeń ewentualnych Błędów zgodnie z niniejszą Umową oraz dostarczania Wykonawcy rzetelnych i wyczerpujących informacji o stanie Oprogramowania Aplikacyjnego i o zamiarach wprowadzenia zmian w działalności Zamawiającego (z odpowiednim wyprzedzeniem) oraz materiałów potrzebnych do wykonania usług w zakresie niniejszej umowy;

o przekazywania na bieżąco Wykonawcy wszystkich przepisów i regulaminów obowiązujących u Zamawiającego, które mogą mieć zastosowanie w realizacji niniejszej Umowy, w tym obowiązujących wykładni prawnych lub wskazówek jednostek nadrzędnych (np. Narodowy Fundusz Zdrowia, Ministerstwo Zdrowia, Samorządowy Wydział Zdrowia, Organ Założycielski, inne);

o zapewnienia Wykonawcy możliwości stałego dostępu do Oprogramowania Aplikacyjnego, w tym pracy w godzinach popołudniowych i wieczornych, a także zapewnienia obecności w tym czasie, upoważnionego przedstawiciela Zamawiającego;

o udostępnienia Wykonawcy sprzętu komputerowego i oprogramowania osób trzecich w zakresie potrzebnym do świadczenia usług określonych w ust. 1 i 2;

o zapewnienia pracownikom Wykonawcy warunków do świadczenia usług określonych w ust. 1 i 2, z uwzględnieniem obowiązujących u siebie przepisów BHP;

o zapewnienia zdalnego dostępu do Oprogramowania Aplikacyjnego.

Jeśli Zamawiający nie wywiąże się z obowiązków wymienionych powyżej, okoliczność ta traktowana będzie jako zwłoka Zamawiającego, a Wykonawca nie ponosi odpowiedzialności za dotrzymanie terminów przewidzianych Umową.

Załącznik nr 3 do Umowy - warunki Licencjonowania

A. Licencjodawca

................................................ z siedzibą w ..............................., przy ul. ...................., (kod i miejscowość) ................................, wpisana/y do rejestru przedsiębiorców przez Sąd Rejonowy w .................., Wydział ........... Gospodarczy Krajowego Rejestru Sądowego, pod numerem KRS ............................., NIP .........................., REGON ...........................,

B. Licencjobiorca

....................................... z siedzibą przy ul. ............................., wpisany do rejestru stowarzyszeń, innych organizacji społecznych i zawodowych, fundacji oraz publicznych zakładów opieki zdrowotnej przez Sąd Rejonowy w …………. , …… Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem KRS: …………….; NIP: ...................REGON: ………………

C. Przedmiot umowy

Licencjodawca udziela Licencjobiorcy niewyłącznej, nieograniczonej w czasie, odwołalnej, licencji na korzystanie z poszczególnych Modułów(1) Oprogramowania Aplikacyjnego określonych w pkt. D wyłącznie na terytorium Rzeczypospolitej Polskiej, na polach eksploatacji wymienionych w pkt. E.

(1) Moduł - oznacz wyodrębniona poprzez udzielenie licencji część Oprogramowania Aplikacyjnego.

D. Oprogramowanie Aplikacyjne

Lp. Nazwa Modułu / Funkcjonalności i oznaczenie Oprogramowania Aplikacyjnego

Ilość Jednoczesnych Użytkowników(1) /

Open(2) /

Ilość Lokalizacji (3)

/

Ilość Systemów Zewnętrznych(4)

Termin

udzielenia licencji

Po podpisaniu umowy

Po podpisaniu umowy

Po podpisaniu umowy

* Użytkownik - oznacza osoby, upoważnione przez Licencjobiorcę do korzystania z Oprogramowania Aplikacyjnego, z zastrzeżeniem, że są to osoby realizujące czynności w ramach działalności Licencjobiorcy (wyłączone jest upoważnienie dla przedstawicieli innych firm, niewskazanych przez producenta)

(1) Jednoczesny Użytkownik – oznacza Użytkowników w tym samym momencie zalogowanych do danego Modułu Oprogramowania Aplikacyjnego, na jednej instalacji bazy danych Oprogramowania Aplikacyjnego.

(2) Licencja Open - oznacza możliwość korzystania z Oprogramowania Aplikacyjnego przez nieograniczoną ilość Jednoczesnych Użytkowników, w wielu Lokalizacjach.

(3) Lokalizacja dla licencji Open (LO) - oznacza miejsce korzystania z Modułów Oprogramowania Aplikacyjnego przez upoważnione do tego przez Licencjobiorcę osoby. Lokalizacją nie jest lokalizacja serwera, na którym zainstalowana jest baza danych Oprogramowania Aplikacyjnego.

(4) System Zewnętrzny – system umożliwiający integrację z systemem produkcji Asseco Poland

S.A.  jednoznacznie identyfikowany przez udostępniany zasób dla:

Mechanizmy bazy danych (widoki oraz metody) pakietów.

E. Pola eksploatacji

Zwielokrotnienie Modułów Oprogramowania Aplikacyjnego w pamięci, serwerów, komputerów oraz urządzeń mobilnych. Tak

Korzystanie z Modułów Oprogramowania Aplikacyjnego przez liczbę Jednoczesnych Użytkowników określonych dla każdego Modułu w pkt. C. TAK

Instalacja na serwerze sieciowym Licencjobiorcy z udostępnieniem dla ilości Jednoczesnych Użytkowników określonych w pkt. C dla każdego Modułu Oprogramowania Aplikacyjnego.

Tak

Sporządzenie 1 kopii zapasowej (-ych) każdego nośnika Oprogramowania Aplikacyjnego. Tak

Korzystanie z Oprogramowania Aplikacyjnego wyłącznie przez Jednoczesnych Użytkowników, zalogowanych na jednej instalacji bazy danych Oprogramowania Aplikacyjnego.

Tak

F. Czas eksploatacji Nieoznaczony

G. Dodatkowe licencje

Licencjodawca zobowiązuje się do rozszerzenia, na pisemne zamówienie Licencjobiorcy licencji na korzystanie z poszczególnych Modułów Oprogramowania Aplikacyjnego dla dodatkowej liczby Jednoczesnych Użytkowników. Nowe licencje zostaną udzielone na warunkach wskazanych w niniejszej umowie.

Licencjobiorca wysyła do Licencjodawcy zapytanie ofertowe, wskazując Ilość Jednoczesnych Użytkowników oraz Moduły Oprogramowania Aplikacyjnego, na które ma zostać udzielona licencja.

Licencjodawca w odpowiedzi na zapytanie ofertowe przygotuje ofertę, wskazując wynagrodzenie należne za udzielenie dodatkowych licencji oraz zasady i termin płatności.

Licencjobiorca składa pisemne zamówienie na udzielenie licencji dodatkowych.

Celem potwierdzenie nabycia nowych licencji Licencjobiorca wystawi Licencjobiorcy Certyfikat licencyjny.

H.Zobowiązanie Licencjobiorcy

Licencjobiorca zobowiązuje się zorganizować i utrzymywać środki bezpieczeństwa zapobiegające jakiemukolwiek nieautoryzowanemu wykorzystaniu Oprogramowania Aplikacyjnego wskazanego w pkt. C niniejszej umowy.

Korzystanie z Oprogramowania Aplikacyjnego przez Jednoczesnych Użytkowników w więcej niż jednej instalacji bazy danych Oprogramowania Aplikacyjnego stanowi naruszenie warunków niniejszej umowy.

Korzystanie z Modułów Oprogramowania, na które została udzielona licencja, w więcej, aniżeli wskazane Lokalizacje, wymaga zapłaty wynagrodzenia za prawo korzystania z tych Modułów w kolejnych Lokalizacjach.

Licencjobiorca nie ma prawa do dokonywania modyfikacji, zmian układu czy jakichkolwiek zmian w Modułach Oprogramowania Aplikacyjnego, za wyjątkiem realizacji praw Licencjobiorcy przyznanych bezwzględnie obowiązującymi przepisami prawa. Zmodyfikowane przez Licencjobiorcę Moduły Oprogramowania Aplikacyjnego, w zakresie w jakim zostały zmodyfikowane, nie są objęte gwarancyjnym nadzorem autorskim Licencjodawcy.

I. Odpowiedzialność Licencjobiorca zobowiązuje się zorganizować i utrzymywać środki bezpieczeństwa zapobiegające jakiemukolwiek nieautoryzowanemu wykorzystaniu Oprogramowania

Licencjodawcy

Aplikacyjnego wskazanego w pkt. C niniejszej umowy.

Licencjodawca nie odpowiada za szkody, jakie Licencjobiorca poniósł w związku z korzystaniem z Oprogramowania Aplikacyjnego, z wyjątkiem przypadków, gdy taką odpowiedzialność przewidują bezwzględnie obowiązujące przepisy prawa.

Licencjodawca nie ponosi odpowiedzialności za:

skutki korzystania z Oprogramowania; treść i integralność (zawartość) danych, otrzymywanych i

przechowywanych przez Licencjobiorcę; jakiekolwiek szkody wynikłe z nieprawidłowego działania lub zaprzestania

funkcjonowania Oprogramowania Aplikacyjnego związane z nieprawidłowym korzystaniem z Oprogramowania Aplikacyjnego;

korzystanie z Oprogramowania Aplikacyjnego przez osoby nieupoważnione;

dokonywanie modyfikacji Oprogramowania Aplikacyjnego przez osoby inne niż upoważnione przez Licencjodawcę;

udostępnienie hasła lub jakichkolwiek innych informacji identyfikujących użytkowników;

wadliwe działanie sieci telekomunikacyjnej; nieprawidłowe działanie lub brak działania Oprogramowania Aplikacyjnego

osób trzecich; nieautoryzowaną ingerencję Licencjobiorcy lub osób trzecich, w struktury

baz danych Oprogramowania Aplikacyjnego; siłę wyższą

Odpowiedzialność odszkodowawcza Licencjodawcy ogranicza się do rzeczywistej straty, bez utraconych korzyści Licencjobiorcy. Odpowiedzialność odszkodowawcza Licencjodawcy ograniczona także jest do 100% wartości wynagrodzenia netto należnego Licencjodawcy z tytułu udzielenia licencji.

Strony oświadczają, że wszelka odpowiedzialność Licencjodawcy z tytułu rękojmi za wady fizyczne na podstawie art. 55 ustawy o prawie autorskim i prawach pokrewnych jak i na podstawie jakiegokolwiek tytułu prawnego, ulega wyłączeniu.

J.Rozwiązanie umowy licencyjnej

Licencjodawca może rozwiązać niniejszą umowę licencyjną bez zachowania terminów wypowiedzenia, gdy Licencjobiorca:

1. narusza warunki niniejszej umowy licencji w odniesieniu do miejsca, zakresu lub sposobu korzystania z każdego z Modułów Oprogramowania Aplikacyjnego lub jego części;

2. uniemożliwia przedstawicielom Licencjodawcy sprawdzenie sposobu wykorzystywania Oprogramowania Aplikacyjnego;

3. w inny sposób narusza warunki licencji, prawa autorskie do Oprogramowania Aplikacyjnego lub postanowienia niniejszej umowy.

W terminie 14 dni od rozwiązania umowy, Licencjobiorca ma obowiązek zaprzestania korzystania z Oprogramowania Aplikacyjnego - w tym celu Licencjobiorca ma obowiązek usunięcia Oprogramowania Aplikacyjnego z serwerów oraz stacji roboczych, na których zostało ono zainstalowane. Art. 59 ustawy o prawie autorskim i prawach pokrewnych nie stosuje się.

K.Postanowienia końcowe

W zakresie nieuregulowanym niniejszą umową zastosowanie mają przepisy prawa polskiego w szczególności przepisy Kodeksu cywilnego i Ustawy z 4 lutego 1994 o prawie autorskim i prawach pokrewnych (t. jedn. Dz.U.2016.666 z pózn. zm.).

Załącznik nr 4 do Umowy - warunki zdalnego dostępu

Niniejszy załącznik ustala zasady udzielenia Wykonawcy zdalnego dostępu do zasobów sieci teleinformatycznej Zamawiającego w celu umożliwienia Wykonawcy realizacji jego zobowiązań wynikających z Umowy.

Udostępnienie1. W celu realizacji usług, o których mowa w § 2 niniejszej Umowy, zdalny dostęp zostanie

udostępniony Wykonawcy przez Zamawiającego niezwłocznie, na wezwanie Wykonawcy, w terminie szczegółowo uzgodnionym przez Strony.

2. Bezpośredni dostęp do systemów Zamawiającego jest możliwy tylko i wyłącznie po udostępnieniu go przez administratora Zamawiającego i po przekazaniu wymaganych uprawnień i haseł.

3. Zamawiający zapewni sprawne działanie zdalnego dostępu.Zasady korzystania 1. Korzystając ze Zdalnego Dostępu Wykonawca:

a. będzie wykorzystywał Zdalny Dostęp wyłącznie w celu realizacji niniejszej Umowy;b. nie będzie pozyskiwał ani przetwarzał żadnych innych danych, za wyjątkiem danych

niezbędnych do realizacji niniejszej Umowy; 2. Wykonawca może wnioskować o dane logowania tylko i wyłącznie dla osób upoważnionych do

przetwarzania danych osobowych, powierzonych do przetwarzania na potrzeby należytej realizacji niniejszej Umowy

3. Zabrania się Wykonawcy przekazywania danych logowania (login lub hasło) innym osobom niż osoby wskazane do realizacji Umowy.

4. Zdalny dostęp udostępnia się do realizacji usług wynikających z niniejszej Umowy.

Warunki Techniczne do uzyskania Zdalnego Dostępu

1. Zamawiający zapewni jeden z czterech rodzajów połączeń:a. VPN - zapewni bezpieczny sposób komunikacji z siecią poprzez udostępnienie

bezpiecznego kanału VPN;b. Udostępnienie terminala - zapewni bezpieczny sposób komunikacji z siecią poprzez

udostępnienie bezpiecznego terminala;c. Udostępnienie portu do bazy danych – zapewni bezpieczny sposób komunikacji z

siecią poprzez udostępnienie IP i portu pozwalającego na komunikację z bazą danych.

d. Udostępnienie dostępu poprzez aplikację Team Viewer.2. Na wezwanie Wykonawcy, Zamawiający przekaże osobie realizującej wynikające z zapisów

Umowy prace identyfikator użytkownika (login) wraz z hasłem dostępu oraz innymi parametrami niezbędnymi do zestawienia zdalnego połączenia. Użytkownicy po stronie Wykonawcy zobowiązują się do nie udostępniania tych identyfikatorów i haseł innym osobom oraz wykorzystywania dostępu wyłącznie w celu realizacji niniejszej Umowy.

3. Wszystkie dane dotyczące parametrów logowania zostaną przekazane na indywidualne konta e-mail. Tą samą drogą dostarczone zostanie również oprogramowanie klienta VPN lub klienta terminalowego. Oprogramowanie zostanie zainstalowane na komputerach użytkowników staraniem Wykonawcy.

Załącznik nr 5 do Umowy - ochrona danych osobowych

UMOWA POWIERZENIA DANYCH OSOBOWYCH

Zawarta w [miasto] dnia [data] pomiędzy:

…………………………. wpisany do rejestru stowarzyszeń, innych organizacji społecznych i zawodowych, fundacji oraz publicznych zakładów opieki zdrowotnej przez Sąd Rejonowy w …………. , …… Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem KRS …………….; REGON: ………………

który reprezentuje:

zwany dalej Zamawiającym lub Administratorem

a

…………………………….. z siedzibą w ………………….., przy ul. ………………, ……………………, wpisana do rejestru przedsiębiorców przez Sąd Rejonowy w ……………., Wydział …… Gospodarczy Krajowego Rejestru Sądowego, pod numerem KRS ………………, o kapitale zakładowym, opłaconym w całości, w wysokości ……………………………… zł, NIP ………………., REGON ………………..,

reprezentowana przez:

………………………………………….………………………………

………………………………………….………………………………

Zwana dalej Wykonawcą

PREAMBUŁA

Mając na uwadze fakt, że:

1. Strony zawarły umowę ................................... („Umowa Główna”), w związku, z wykonywaniem której Zamawiający powierzy Wykonawcy przetwarzanie danych osobowych w zakresie określonym Umową;

2. Celem Umowy jest ustalenie warunków, na jakich Wykonawca wykonuje operacje przetwarzania Danych Osobowych w imieniu Zamawiającego;

3. Strony zawierając Umowę dążą do takiego uregulowania zasad przetwarzania Danych Osobowych, aby odpowiadały one w pełni postanowieniom rozporządzenia Parlamentu Europejskiego i Rady (UE) 2016/679 z 27.04.2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne rozporządzenie o ochronie danych) (Dz.Urz. UE L 119, s. 1) – dalej RODO.

Strony zawierają niniejszą Umowę powierzenia danych osobowych w celu realizacji Umowy Głównej:

§ 1. POSTANOWIENIA OGÓLNE1. Zamawiający oświadcza, że jest administratorem w rozumieniu art. 4 pkt 7 RODO, jest

uprawniony, na mocy art. 28 ust. 2 RODO, do dalszego powierzenia Wykonawcy przetwarzania danych osobowych.

2. Wykonawca oświadcza, że posiada zasoby infrastrukturalne, doświadczenie, wiedzę oraz wykwalifikowany personel, w zakresie umożliwiającym należyte wykonanie Umowy Głównej, w zgodzie z obowiązującymi przepisami prawa. W szczególności Wykonawca oświadcza, że znane mu są zasady przetwarzania i zabezpieczenia danych osobowych wynikające z RODO.

§ 2. PRZEDMIOT1. Na warunkach określonych niniejszą Umową Zamawiający powierza Wykonawcy przetwarzanie

(w rozumieniu, jakie nadaje przetwarzaniu art. 4 pkt 2 RODO) opisanych w Umowie Głównej Danych Osobowych.

2. Pod pojęciami „Dane Osobowe” lub „Dane” użytymi w niniejszej Umowie, Strony rozumieją dane osobowe zdefiniowane w art. 4 pkt 1 RODO, których rodzaj i zakres zostały wskazane w niniejszej Umowie.

3. Dostęp do danych osobowych przydzielany jest w oparciu o zasadę minimalnych koniecznych uprawnień tj. tylko uprawnień niezbędnych do wykonania czynności określonych w Umowie Głównej.

§ 3. CZASPrzetwarzanie będzie wykonywane w okresie realizacji przedmiotu Umowy Głównej, z uwzględnieniem pozostałych postanowień niniejszej Umowy dotyczących obowiązków i uprawnień Stron.

§ 4. CHARAKTER I CELCharakter i cel przetwarzania wynikają z przedmiotu Umowy Głównej w szczególności celem przetwarzania jest świadczenie na rzecz Zamawiającego usług nadzoru autorskiego i świadczenie usług serwisowych o których mowa w Umowie Głównej.

§ 5. RODZAJ DANYCH§ 5. Przetwarzanie obejmować będzie rodzaje danych osobowych (Dane Osobowe) wskazane

poniżej:1) Dane identyfikacyjne,2) Dane adresowe,3) Dane kontaktowe,4) Numery identyfikacyjne,5) Informacje związane z realizowanymi zadaniami Zamawiającego w szczególności

informacje opisujące relacje Zamawiającego z Pacjentami; Pracownikiem Zamawiającego.

§ 6. KATEGORIE OSÓB1. Przetwarzanie danych będzie dotyczyć następujących kategorii osób:

1) Pracownicy świadczący usługi dla Zamawiającego,2) Pacjenci Zamawiającego,3) Interesanci i Kontrahenci Zamawiającego.

§ 7. DALSZE PRZETWARZANIEWykonawca może powierzyć konkretne operacje przetwarzania Danych („podpowierzenie”) w drodze pisemnej umowy dalszego przetwarzania („Umowa podpowierzenia”) w imieniu Administratora innemu przetwarzającemu („Podwykonawca”), pod warunkiem uprzedniej akceptacji Podwykonawcy przez Administratora lub braku sprzeciwu Administratora. Strony przyjmują, iż wskazani w niniejszym punkcie Podwykonawcy są podmiotami, którym Wykonawca może powierzyć dalsze przetwarzanie Danych Osobowych i uzyskanie dodatkowej zgody Administratora, o której mowa powyżej, nie jest wymagane. Strony zgodnie postanawiają, że osoby fizyczne współpracujące z Wykonawcą na

podstawie umów cywilno-prawnych są traktowane jak personel Wykonawcy i nie stanowią Dalszych Przetwarzających w rozumieniu Umowy.

Lista Podwykonawców zaakceptowanych przez Zamawiającego:

1) ……………………..… realizując zadania wynikające z niniejszej Umowy uwzględniając stan wiedzy technicznej, koszty, charakter, zakres oraz cel przetwarzania w miarę możliwości udzieli pomocy Zamawiającemu w zakresie:

realizacji obowiązku odpowiadania na żądania osoby, której dane dotyczą, w zakresie wykonywania jej praw określonych w rozdziale III RODO,

zapewnienia realizacji obowiązków wynikających z art. 32–36 RODO.

§ 8. WSPÓŁPRACA PRZY REALIZACJI PRAW JEDNOSTKI 1. Wykonawca realizując zadania wynikające z niniejszej Umowy w miarę możliwości udzieli pomocy

Zamawiającemu w zakresie: 1) realizacji obowiązku odpowiadania na żądania osoby, której dane dotyczą, w zakresie

wykonywania jej praw określonych w rozdziale III RODO, 2) zapewnienia realizacji obowiązków wynikających z art. 32–36 RODO.

§ 9. POWIADOMIENIE O NARUSZENIEWykonawca bezzwłocznie - nie później jednak niż w ciągu 48 godzin od jego wystąpienia - zgłosi Zamawiającemu każde naruszenie danych osobowych powierzonych niniejszą Umową którego będzie uczestnikiem.

§ 10. USUNIĘCIE DANYCH Wykonawca po zakończeniu przetwarzania danych osobowych niezwłocznie zwróci powierzone mu dane lub dokona ich zniszczenia – adekwatnie do ustaleń z Zamawiającym. Czynności zwrotu lub zniszczenia każdorazowo winny zostać potwierdzane odpowiednio przez Strony.

Zamawiający Wykonawca