Opis przedmiotu zamówienia.

Załącznik nr 8 do SIWZ

Opis przedmiotu zamówienia.

Wymagania zamawiającego dotyczące Rozbudowy Zintegrowanego Systemu Informatycznego:

A. Wykonawca dostarczy Zamawiającemu Moduły Oprogramowania ZSI z odpowiednimi licencjami dla części medycznej (HIS) rozbudowujących konfigurację aktualnie posiadanego i eksploatowanego przez Zamawiającego systemu HIS o zakres określony poniżej:

tabela 1 - Wykaz nowych modułów i licencji dla części medycznej:

Moduł systemu	Liczba licencji
• Przychodnia:	-
o Rejestracja	10
o Gabinet Xxxxxxxx	otwarta
o Statystyka	4
• Rozliczenia z NFZ	otwarta
• Symulator JGP	otwarta
• Zlecenia	otwarta
• Blok operacyjny wraz z prawem do bezpłatnej migracji na wersję AMMS	otwarta
• Dokumentacja formularzowa	otwarta
• Pracownia Diagnostyczna	4
• Moduł integracyjny (RIS/HIS)	1

B. Wykonawca dostarczy Zamawiającemu Moduły Oprogramowania ZSI z odpowiednimi licencjami dla części administracyjnej (ERP) rozbudowujących konfigurację aktualnie posiadanego i eksploatowanego przez Zamawiającego systemu ERP o zakres określony poniżej:

tabela 2- Wykaz nowych modułów i licencji dla części administracyjnej:

Moduł systemu	Liczba licencji
• Kalkulacja Kosztów	2
• Wycena Kosztów Normatywnych	1

Wykonawca rozbuduje systemu ZSI o funkcjonalności określone w powyższych tabelach poprzez integrację :

- HIS i ERP w zakresie niezbędnym dla przetwarzania danych z posiadanymi systemami;

- diagnostyka medyczna (RIS/PACS);

C. Wykonawca przeprowadzi instalację, konfigurację, parametryzację i wdrożenie ZSI w ww. zakresie w następujących przypadkach:

- przeniesienia danych w pełnym zakresie ze źródeł aktualnie eksploatowanych obecnie przez Zamawiającego w zakresie niezbędnym do utrzymania jego ciągłości funkcjonowania,

- wdrożenia administratorów w zakresie administrowania bazą danych wdrożonego systemu ZSI,

- wdrożenia administratorów w zakresie administrowania i eksploatacji całego zakresu funkcjonalnego wdrożonego ZSI,

- wdrożenia personelu Szpitala w pełnym zakresie funkcjonalnym eksploatacji ZSI,

- świadczenia usługi serwisowej wraz z nadzorem autorskim dla ZSI dla licencji nabywanych w ramach niniejszego zamówienia przez okres minimum 12 miesięcy liczony od daty podpisania Protokołu Odbioru Końcowego (bezusterkowego).

D. Stan obecny

Wykaz eksploatowanych systemów przez Zamawiającego :

L.p.	Nazwa systemu, producent, liczba licencji, baza danych	Systemy do integracji	Systemy do wymiany
1	System dla części medycznej AMMS/Infomedica Asseco Poland S.A. – baza danych ORACLE 11g
	• Ruch Chorych (IP, Oddział, Statystyka, Rozliczenia z NFZ) – licencja otwarta	TAK	NIE
	• Apteka- 5 licencji • Apteczka oddziałowa – licencji 17	TAK	NIE
	• MiniInfomedica (Rejestracja, Statystyka/ Rozliczenia z NFZ) – 20 licencji	NIE	TAK (migracja danych)
2.03.2 015	System dla części administracyjnej (ERP) InfoMedica Asseco Poland S.A. – baza danych ORACLE 11g
	• Finanse-Księgowość -7 licencji • Koszty – 3 licencje • Gospodarka Materiałowa – 2 licencje • Kasa – 1 licencja • Rejestr Sprzedaży – 1 licencja • Środki Trwałe – 1 licencja • System Kadrowo-Płacowy - 7 licencji • System Grafiki Czasu Pracy – licencja otwarta	TAK	NIE
3	System RIS i PACS firmy Pixel Technology	TAK	NIE
4	System laboratorium firmy Diagnostyka	NIE	NIE

E. Stan docelowy Zintegrowanego Systemu Informatycznego

Zamawiający wymaga, aby w wyniku realizacji niniejszego zamówienia uzyskał produkt w postaci wyposażonego, w co najmniej poniżej zdefiniowane moduły ZSI.

Część administracyjnej składająca się z następujących modułów:

• Finanse-Księgowość

• Koszty

• Gospodarka Materiałowa

• Kasa

• Rejestr Sprzedaży

• Środki Trwałe

• Kadry

• Płace

• Ewidencja Czasu Pracy (Grafiki)

• Kalkulacja Kosztów Leczenia

• Wycena Kosztów Normatywnych

Część medyczna składająca się z następujących modułów:

Lecznictwo Otwarte:

• Przychodnia

o Rejestracja

o Gabinet Xxxxxxxx

o Statystyka

• Rozliczenia z NFZ

• Symulator JGP Lecznictwo Zamknięte:

• Ruch Chorych (Izba Przyjęć, Oddział, Statystyka) Gospodarka lekiem:

• Apteka Szpitalna

• Apteczki Oddziałowe Inne:

• Zlecenia

• Blok operacyjny

• Dokumentacja formularzowa

• Moduł integracyjny

• Pracownia Diagnostyczna

W przypadku konieczności zaoferowania większej ilości modułów należy wypełnić tabele we wzorze oferty w pkt II.7 formularza ofertowego.

Zamawiający nie dopuszcza zakupu systemu, który nie posiada PEŁNEJ funkcjonalności wymaganej na etapie składania oferty.

Oferowane aplikacje muszą spełniać wszelkie obecne wymogi prawne, dotyczące rachunkowości, rozliczeń kosztów w podmiotach leczniczych, ochrony danych osobowych, informatyzacji podmiotów realizujących zadania publiczne, rachunkowości i sposobu liczenia kosztów w podmiotach leczniczych, zgodnie z wymogami przepisów prawa. Wraz z aplikacjami dostarczana będzie polskojęzyczna dokumentacja użytkowa, pozwalająca na samodzielną naukę obsługi każdego modułu. Należy także dostarczyć dokumentację techniczną ZIS w wersji elektronicznej.

• Każdy z dostarczonych modułów medycznych musi posiadać dostęp do księgi głównej Zamawiającego.

• Każdy z dostarczonych modułów medycznych musi posiadać własną funkcjonalność statystyczną, która pozwoli analizować aspekty pracy jednostki, której moduł dotyczy.

• Każdy z dostarczonych modułów medycznych musi posiadać własną funkcjonalność analityczną , która pozwoli generować dowolne, zdefiniowane przez administratora zestawienia:

- elastyczne dopasowanie systemu do potrzeb sprawozdawczych Zamawiającego

- definiowanie niestandardowych wykazów pozwalających na tabelaryczne przedstawianie danych dostępnych w poszczególnych modułach, zapis stworzonych wzorców wykazów w celu wielokrotnego wykonywania raz zdefiniowanego wykazu

- wykonanie zdefiniowanych wykazów i ich przedstawienie poprzez arkusz kalkulacyjny Excel oraz Open Office .

Z uwagi na wymaganą pełną integrację modułów oraz jednolity sposób serwisowania i gwarancji, wszystkie moduły oferowanego systemu informatycznego muszą:

• umożliwić pracę z wykorzystaniem jednego rozwiązania platformy bazodanowej,

• pochodzić od jednego producenta

F. Założenia związane z wolumetrią

- Ilość jednoczenie korzystających z aplikacji użytkowników do 350.

- Ilość zarejestrowanych użytkowników minimum 500 – dotyczy aktywnych kont użytkowników.

- System zbudowany w oparciu o założenia skalowalności do 500 jednocześnie pracujących użytkowników – możliwość zwiększenia maksymalnego obciążenia serwerów aplikacji do 500 sesji aktywnych na serwerach aplikacji poprzez rozbudowę infrastruktury sprzętowej związanej z serwerami aplikacji.

G. Wymagania i funkcjonalności zamawianego systemu (część medyczna - HIS) Zamawiający dopuszcza inny podział oferowanego systemu na moduły, niż przedstawiony poniżej. Jednocześnie Wykonawca zobowiązany jest wskazać, że jego system pokrywa całą opisaną w niniejszym punkcie funkcjonalność oraz przedstawić podział na moduły oferowanego systemu, a także przedstawić funkcjonalność tych modułów w ofercie.

Lp.	Akty prawne i normy
	Oferowane oprogramowanie jest zgodne z aktualnymi aktami prawnymi regulującymi organizację i działalność sektora usług medycznych i opieki zdrowotnej w kraju w szczególności:
1	Rozporządzenie Ministra Zdrowia i Opieki Społecznej z dnia 22 grudnia 1998 r. w sprawie szczególnych zasad rachunku kosztów w publicznych zakładach opieki zdrowotnej (Dz.U. 1998 nr 164 poz. 1194)
2	Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz.U. z 2004 nr 100, poz.1024)
3	Ustawa z dnia 17 lutego 2005 o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U z 2005 nr 64) z późniejszymi zmianami
4	Rozporządzenie Rady Ministrów z dnia 11 października 2005 w sprawie minimalnych wymagań dla systemów teleinformatycznych (Dz.U. 2005 Nr 212, poz. 1766).
5	Rozporządzenie Ministra Zdrowia z dnia 14 grudnia 2006 r. zmieniające rozporządzenie w sprawie zakresu niezbędnych informacji gromadzonych przez świadczeniodawców, szczegółowego sposobu rejestrowania tych informacji oraz ich przekazywania podmiotom zobowiązanym do finansowania świadczeń ze środków publicznych (z dnia 29 lipca 2005)
6	Rozporządzenie Ministra Zdrowia w sprawie rodzajów i zakresu dokumentacji medycznej w zakładach opieki zdrowotnej oraz sposobu jej przetwarzania z dnia 21 grudnia 2010
7	System musi spełniać wymogi wynikające z ustawy „o Ochronie Danych Osobowych” z 29 czerwca 1997 roku oraz z Rozporządzenia MSWiA z 29 kwietnia 2004 roku, w szczególności system musi przechowywać informacje o:
8	- dacie wprowadzenia danych osobowych
9	- identyfikator użytkownika wprowadzającego dane osobowe
10	- źródło danych (o ile dane nie pochodzą od osoby, której te dane dotyczą)
11	- informacje o odbiorcach danych, którym dane osobowe zostały udostępnione,
12	- dacie i zakresie tego udostępnienia
13	- data modyfikacji danych osobowych
14	- identyfikator operatora modyfikującego dane
15	Zarządzenie Nr 4/2009/DŚOZ Prezesa NFZ z dnia 9 stycznia 2009 r. w sprawie określenia szczegółowych komunikatów sprawozdawczych XML dotyczących świadczeń ambulatoryjnych i szpitalnych (I fazy) oraz rozliczenia świadczeń ambulatoryjnych i szpitalnych (II fazy)
16	Zarządzenie Nr 3/2009/DŚOZ Prezesa NFZ z dnia 9 stycznia 2009 r. w sprawie określenia szczegółowych komunikatów sprawozdawczych XML dotyczących deklaracji POZ / KAOS, zwrotnych wyników weryfikacji deklaracji POZ / KAOS, zwrotnego rozliczenia deklaracji POZ / KAOS
17	Zarządzenie Nr 10/2008/DI Prezesa NFZ z dnia 31 stycznia 2008 r. zmieniające zarządzenie w sprawie określenia szczegółowych komunikatów sprawozdawczych XML dotyczących danych zbiorczych o świadczeniach udzielonych w ramach POZ
18	Zarządzenie nr 12/2009/DSOZ Prezesa NFZ z dnia 11 lutego 2009 r.

19	Zarządzenie Nr 102/2008/DGL Prezesa NFZ z dnia 29 października 2008 r. w sprawie określenia warunków zawierania i realizacji umów w rodzaju leczenie szpitalne w zakresie chemioterapia
20	Zarządzenie Nr 98/2008/DGL Prezesa NFZ z dnia 27 października 2008 r. w sprawie określenia warunków zawierania i realizacji umów w rodzaju leczenie szpitalne w zakresie terapeutyczne programy zdrowotne
Lp.	Wymagania ogólne
	Architektura i interfejs użytkownika
1.	System ma interfejs graficzny dla wszystkich modułów
2.	System pracuje w środowisku graficznym MS Windows na stanowiskach użytkowników (preferowane środowisko MS Windows 7/8)
3.	System komunikuje się z użytkownikiem w języku polskim. Jest wyposażony w system podpowiedzi (help). W przypadku oprogramowania narzędziowego i administracyjnego serwera bazy danych dopuszczalna jest częściowa komunikacja w języku angielskim
4.	System umożliwia pracę w innych wersjach językowych. Powinna istnieć, co najmniej wersja anglojęzyczna systemu obejmująca nazwy okien i etykiety pól
5.	Podczas uruchamiania systemu, użytkownik musi mieć możliwość wybrania wersji językowej
6.	Powinna istnieć możliwość przypisania użytkownikowi lub grupie użytkowników domyślnej wersji językowej, tak aby dla tego użytkownika system uruchamiał się we właściwym dla niego języku
	Baza danych
7.	Wszystkie moduły systemu działają w oparciu o jeden motor bazy danych posiadany przez Zamawiającego
8.	System w zakresie części medycznej powinien pracować w oparciu o tę samą bazę danych, przez co należy rozumieć tę samą instancję bazy danych, te same tabele. Niedopuszczalne jest przekazywanie i dublowanie danych w zakresie w/w systemów.
9.	System zapewnia odporność struktur danych (baz danych) na uszkodzenia oraz pozwala na szybkie odtworzenie ich zawartości i właściwego stanu, jak również posiada łatwość wykonania ich kopii bieżących oraz łatwość odtwarzania z kopii. System jest wyposażony w zabezpieczenia przed nieautoryzowanym dostępem. Zabezpieczenia funkcjonują na poziomie klienta (aplikacja) i serwera (serwer baz danych).
10.	System jest wykonany w technologii klient-serwer, dane są przechowywane w modelu relacyjnym baz danych z wykorzystaniem aktywnego serwera baz danych.
	Udogodnienia interfejsu użytkownika
11.	W funkcjach związanych z wprowadzaniem danych system udostępnia podpowiedzi, automatyczne wypełnianie pól, słowniki grup danych (katalogi leków, procedur medycznych, danych osobowych, terytorialnych).
12.	System musi umożliwić zmianę jednostki organizacyjnej, na której pracuje użytkownik bez konieczności wylogowania się z systemu
13.	System musi umożliwić skanowanie danych z dokumentów tożsamości - dowodów osobistych lub prawo jazdy i na tej podstawie dokonywanie identyfikacji pacjenta
14.	System powinien umożliwić obsługę procesów biznesowych realizowanych w szpitalu tzn. powinien: - pokazywać tylko to, co w danym momencie jest najważniejsze, - udostępniać tylko te zadania, które na danym etapie powinny zostać wykonane, - umożliwić wprowadzenie tylko tych danych, które są niezbędne, - podpowiadać kolejne kroki procesu.
	Bezpieczeństwo
15.	System musi być wyposażony w zabezpieczenia przed nieautoryzowanym dostępem. Zabezpieczenia muszą funkcjonować na poziomie klienta (aplikacja) i serwera (serwer baz danych),
16.	System musi tworzyć i utrzymywać log systemu, rejestrujący wszystkich użytkowników systemu i wykonane przez nich najważniejsze czynności z możliwością analizy historii zmienianych wartości danych.
17.	W przypadku przechowywania haseł w bazie danych, hasła muszą być zapamiętane w postaci

	niejawnej (zaszyfrowanej).
18.	Dane powinny być chronione przed niepowołanym dostępem przy pomocy mechanizmu uprawnień użytkowników. Każdy użytkownik systemu powinien mieć odrębny login i hasło. Jakakolwiek funkcjonalność systemu (niezależnie od ilości modułów) będzie dostępna dla użytkownika dopiero po jego zalogowaniu.
19.	System powinien wylogować lub blokować sesję użytkownika po zadanym czasie braku aktywności
20.	Użytkownik po zalogowaniu powinien widzieć pulpit zawierający wszystkie funkcje i moduły dostępne dla tego użytkownika
21.	W systemie musi zostać zachowana zasada jednokrotnego wprowadzania danych. Wymiana danych pomiędzy modułami musi odbywać się na poziomie bazy danych
	Komunikator w zakresie lecznictwa otwartego
22.	System powinien zawierać komunikator umożliwiający wymianę wiadomości pomiędzy użytkownikami.
23.	Komunikator musi umożliwić wysłanie wiadomości do:
24.	- pracowników jednostki organizacyjnej
25.	- wskazanego użytkownika
26.	- użytkowników pełniących określoną funkcję (lekarze, pielęgniarki)
27.	- użytkowników wskazanego modułu
28.	- możliwość łączenia w/w grup adresatów np. wszystkie pielęgniarki z oddziału chorób wewnętrznych pracujące w module Apteczka
29.	Musi istnieć możliwość nadania wiadomości statusu: zwykła, ważna, wymagająca potwierdzenia
30.	System powinien umożliwić definiowanie wiadomości, których wysłanie jest inicjowane zdarzeniem np. zlecenie leku, badania, wynik badania, zamówienie na lek do apteki.
31.	Wiadomości mogą być wysyłane przez użytkowników systemu
32.	Wiadomości powinny mieć określony termin obowiązywania podawany z dokładnością do godziny
33.	System powinien zapewniać mechanizm powiadomień generowanych automatycznie w związku ze śledzeniem stanu realizacji zleceń, wyników badań, zamówień do apteki.
	Administrator
34.	Konfigurowanie systemu
35.	Dynamiczne definiowanie widoków słowników (zakresu danych wyświetlanych) dla jednostki organizacyjnej, dla użytkownika,
36.	Definiowanie terminarzy zasobów: pomieszczeń, łóżek, urządzeń
37.	Zarządzanie parametrami na poziomie systemu, jednostki organizacyjnej, stacji roboczej, użytkownika,
38.	Definiowanie struktury dokumentów:
39.	- ksiąg wykorzystywanych w przychodni, szpitalu, pracowniach,
40.	- szablonów wydruków (pism),
41.	Definiowanie elementów leczenia i złożonych szablonów zleceń wykorzystywanych przez jednostki zlecające,
42.	Zarządzanie słownikiem jednostek struktury organizacyjnej Zamawiającego na poziomie całego systemu:
43.	- tworzenie i modyfikacja listy jednostek organizacyjnych (recepcje, gabinety, pracownie, oddziały, izby przyjęć, bloki operacyjne itp.),
44.	- powiązanie struktury jednostek organizacyjnych ze strukturą kosztów.
45.	Zarządzanie słownikami standardowymi (ogólnopolskimi):
46.	- Międzynarodowa Klasyfikacja Procedur Medycznych ICD9 CM – druga polska edycja,
47.	- Klasyfikacja chorób wg ICD – rewizja 10,
48.	- Słownik Kodów Terytorialnych GUS,
49.	- Słownik Zawodów.
50.	Tworzenie, przegląd, edycja słowników własnych Zamawiającego:
51.	- personelu,

52.	- leków.
53.	Zarządzanie strukturą użytkowników i ich uprawnieniami:
54.	System zarządzania użytkownikami musi być wspólny dla wszystkich systemów, w szczególności dla modułu Ruch Chorych, Przychodnia, Apteka, Apteczki oddziałowe, Rozliczenia z NFZ, Pracownie Diagnostyczne.
55.	System zarządzania użytkownikami musi umożliwiać definiowanie listy użytkowników systemu
56.	System zarządzania użytkownikami musi umożliwiać określenie uprawnień użytkowników,
57.	System zarządzania użytkownikami musi umożliwiać połączenie listy użytkowników ze słownikiem personelu,
58.	Musi istnieć możliwość nadania użytkownik uprawnień do pracy wyłącznie w kontekście wybranej/ wybranych jednostek organizacyjnych. Np. tylko oddział wewnętrzny lub gabinet POZ i izba przyjęć.
59.	System musi posiadać mechanizmy umożliwiające zapis i przeglądanie danych o logowaniu użytkowników do systemu
60.	Administrator musi posiadać możliwość z poziomu aplikacji z modułu administratora nadawania danemu użytkownikowi unikalnego loginu oraz hasła. Administrator musi posiadać możliwość ustawienia parametrów hasła: długość, czas żywotności, czas przed wygaśnięciem, minimalna liczba dużych i małych liter oraz cyfr, liczb, minimalna i maksymalna liczba znaków specjalnych w haśle
61.	System uprawnień powinien być tak skonstruowany, aby można było użytkownikowi nadać uprawnienia z dokładnością do rodzaju wykonywanej operacji tj. osobne uprawnienie na odczyt danych i osobne na wprowadzanie/modyfikację danych. System uprawnień powinien umożliwiać definiowanie grup uprawnień, które to mogłyby być przydzielane poszczególnym użytkownikom.
62.	Równolegle musi istnieć możliwość nadawania użytkownikowi pojedynczych uprawnień z listy dostępnych. System musi umożliwiać definiowanie grup użytkowników i przydzielanie użytkowników do tych grup.
63.	System powinien umożliwiać nadawanie uprawnień użytkownikom do jednostek organizacyjnych, w których pracują, np. lekarz pracujący na izbie przyjęć i oddziale wewnętrznym powinien w swoich aplikacjach widzieć tylko pacjentów izby przyjęć i tego jednego oddziału.
64.	System musi umożliwiać podgląd aktualnie zalogowanych do systemu użytkowników.
65.	Administrator musi posiadać z poziomu aplikacji możliwość wylogowania wszystkich użytkowników aplikacji
66.	System umożliwia administratorowi z poziomu aplikacji definiowanie i zmianę praw dostępu dla poszczególnych użytkowników i grup użytkowników z dokładnością do poszczególnych modułów oraz funkcji systemu
67.	System powinien umożliwić przypisanie do komórki organizacyjnej jednostki, kodu technicznego NFZ. Powinna istnieć możliwość zmiany tego kodu w dowolnym momencie pracy systemu.
68.	System musi umożliwić określenie jednostkom organizacyjnym oddzielnego numeru REGON, innego niż REGON zakładu opieki zdrowotnej
69.	System musi umożliwiać zarządzanie międzymodułowym systemem komunikacyjnym umożliwiający pobranie lub wysłanie komunikatów do: - użytkowników wybranych modułów, - wskazanych użytkowników (nazwanych oraz ról jakie pełnią w systemie) - wskazanych stacji roboczych
70.	System musi umożliwiać przegląd dziennika operacji (logi),
71.	System musi umożliwiać wykonanie funkcji optymalizacji bazy danych
72.	System musi umożliwiać wyszukiwanie i łączenie podwójnie wprowadzonych danych pacjentów, lekarzy, instytucji.
73.	System przekazuje wyniki sprawozdań i analiz w postaci elektronicznej do modułów pakietu MS Office / OpenOffice. Przygotowuje wyniki sprawozdań i analiz w postaci plików MS Office (np. MS Excel) / OpenOffice (np. Calc) oraz automatycznie (mechanizm OLE) uruchamia wybrany moduł pakietu MS Office / OpenOffice i prezentuje w nim przygotowane wyniki w dowolnie opracowanej przez użytkownika formie (tabela, wykres, pismo itp.).

	Wykazy
74.	Elastyczne dopasowanie systemu do potrzeb sprawozdawczych Zamawiającego:
75.	- definiowanie niestandardowych wykazów pozwalających na tabelaryczne przedstawianie danych dostępnych w poszczególnych modułach, zapis stworzonych wzorców wykazów w celu wielokrotnego wykonywania raz zdefiniowanego wykazu
76.	- wykonanie zdefiniowanych wykazów i ich przedstawienie poprzez arkusz kalkulacyjny Excel
	Zlecenia
1.	Moduł musi oferować web’owy interfejs użytkownika, z możliwością pracy co najmniej w przeglądarkach Internet Explorer i Mozilla Firefox (bez konieczności instalowania dodatkowych aplikacji). Wskazana funkcjonalność powinna być dostępna zarówno na komputerach stacjonarnych jak i tabletach PC.
2.	System musi umożliwiać planowanie i zlecanie leków w powiązaniu z modułem Apteczki Oddziałowej
3.	System musi umożliwiać kopiowanie zleceń leków z poprzednich pobytów lub hospitalizacji
4.	System musi pozwalać na zlecanie leków wg nazwy handlowej i międzynarodowej
5.	System musi umożliwiać zlecanie podań leków o określonych porach oraz co określony czas, od pierwszego podania co X godzin i Y minut
6.	System musi pozwalać na wyróżnianie kolorem zleceń leków zlecanych z innych magazynów
7.	Podczas zlecenia leków system powinien umożliwiać:
8.	- podgląd karty leków
9.	- kontrolę interakcji pomiędzy zleconymi lekami
10.	Podczas zlecania antybiotyku system powinien wymagać określenie rodzaju antybiotykoterapii: celowana, empiryczna, profilaktyka, WRZ
11.	System powinien umożliwiać prezentację i wydruk indywidualnej karty zleceń podań leków
12.	Musi istnieć możliwość zlecania leków:
13.	- recepturowych
14.	- chemioterapii
15.	- zlecenie chemioterapii z wykorzystaniem schematów leczenia
16.	- pomp infuzyjnych
17.	- możliwość określenia drogi podania leków
18.	Musi istnieć możliwość wydruku tacy leków z podaniem nazwiska osoby drukującej i czasu wydruku
19.	Podczas realizacji zlecenia leku system powinien umożliwiać zastosowanie zamienników do zleconego leku
20.	Dla pobytów oznaczonych „zagrożenie życia lub zdrowia” wszystkie zlecenia powinny być opatrzone statusem PILNE
21.	System musi umożliwić planowanie i zlecanie badań diagnostycznych i laboratoryjnych, zabiegów, konsultacji przekazywanych z jednostek Zamawiającego, w tym:
22.	- z Oddziału do: Pracowni Diagnostycznej, Przychodni, Bloku operacyjnego, innego Oddziału, Gabinetu lekarskiego, Laboratorium
23.	System powinien umożliwiać zlecanie wielu różnych badań w jednym miejscu, opatrzony wspólnym nagłówkiem i komentarzem
24.	System powinien podpowiadać, na zleceniu, rozpoznania zasadniczego a w przypadku jego braku rozpoznania wstępnego
25.	Możliwość utworzenia zlecenia laboratoryjnego z wykorzystaniem predefiniowanej karty kodów kreskowych
26.	Dla zleceń laboratoryjnych musi istnieć możliwość odnotowania informacji o pobranym materiale dla pojedynczego badania lub zestawu badań
27.	Dla zleceń laboratoryjnych musi istnieć możliwość określenia planowanej godziny wykonania badania. System powinien podpowiadać domyślne godziny pobrań materiałów
28.	W przypadku anulowania zlecenia, powód anulowania powinien być widoczny przy zleceniu
29.	System musi umożliwiać planowanie i zlecanie badań i konsultacji w ramach zleceń zewnętrznych (z innych podmiotów)

30.	System musi zapewnić możliwość definiowania zleceń złożonych:
31.	- kompleksowych,
32.	- panelowych,
33.	- cyklicznych.
34.	System powinien umożliwiać zapisanie zleconych badań, jako panelu zleceń do wykorzystania w późniejszym terminie
35.	Powinna istnieć możliwość przepisania opisu zlecenia z poprzedniego zlecenia
36.	Powinna istnieć możliwość dwuetapowego wprowadzania zlecenia (wpisanie oraz potwierdzenia),
37.	System musi umożliwiać powtarzanie zleceń, co określony interwał czasu
38.	System musi umożliwiać przegląd zleceń według ustalonych przez użytkownika kryteriów:
39.	- dla pacjenta,
40.	- typu zlecenia (laboratoryjne, diagnostyczne, podanie leku),
41.	- okresu.
42.	Po wystawieniu zlecenia powinna istnieć możliwość zmiany jednostki, która zostanie obciążona kosztami realizacji zleconego badania.
43.	System musi umożliwiać wydruki zleceń, w tym:
44.	- dzienne zestawienie leków dla pacjenta,
45.	- dzienne zestawienie badań do wykonania.
46.	Musi istnieć możliwość wydruku wszystkich wyników pacjenta z bieżącej hospitalizacji lub ze wszystkich pobytów w szpitalu,
47.	System musi umożliwiać przegląd wszystkich zleceń z jednostki zlecającej z możliwością wydruku wyniku wykonanego badania,
48.	Musi istnieć możliwość definiowania szablonów dokumentów skojarzonych z wprowadzanym zleceniem.
49.	System musi zapewnić możliwość wyświetlania wyników w układzie tabelarycznym z możliwością śledzenia zmian wyników i zmiany kolejności porównywanych parametrów (np. w wyniku morfologii)
50.	System musi zapewnić możliwość przeglądania wyników liczbowych w postaci graficznej (badanie trendu)
51.	System musi umożliwić graficzną prezentację wyników badań z uwzględnieniem, na osi czasu, podanych leków i wykonanych procedur
Lp.	Blok operacyjny
1.	System musi umożliwiać dokonanie klasyfikacji anestezjologicznej, co najmniej w zakresie odnotowania:
2.	- rodzaju planowanego znieczulenia z wykorzystaniem słownika rodzajów znieczulenia z możliwością definiowania własnych rodzajów znieczulenia,
3.	- klasyfikacji pacjenta wg skali ASA,
4.	System musi umożliwić planowanie zabiegu operacyjnego w tym wpisanie:
5.	- daty zabiegu, bloku operacyjnego i sali operacyjnej,
6.	- materiałów,
7.	- składu zespołu zabiegowego i anestezjologicznego z wykorzystaniem słownika personelu z możliwością określenia definiowania roli członków personelu,
8.	Musi istnieć możliwość obsługi listy zabiegów bloku operacyjnego, obejmującej:
9.	- dostęp do aktualnych i archiwalnych danych pacjentów.
10.	- modyfikacja danych pacjentów,
11.	System musi umożliwiać wyszukiwanie zabiegów na liście zabiegów wg różnych kryteriów, w tym:
12.	- statusu zabiegu (planowany, w trakcie realizacji, opieka pooperacyjna, przekazany na oddział, anulowany),
13.	- danych pacjenta (nazwisko, imię, XXXXX),
14.	- tryb zabiegu,
15.	- rodzaj zabiegu,
16.	- składu zespołu operacyjnego (operatora, pielęgniarski operacyjnej, anestezjologa, pielęgniarki

	anestezjologiczna).
17.	- przeglądu zabiegów zaplanowanych na dzisiaj i/lub jutro
18.	System musi umożliwiać przyjęcie pacjenta na blok operacyjny i odnotowanie związanych z tym danych tj:
19.	- czas przyjęcia i osoby przyjmującej,
20.	- wpis do Księgi Bloku operacyjnego
21.	System musi umożliwić odnotowanie danych medycznych przeprowadzonego zabiegu w tym:
22.	- rodzaju wykonanego zabiegu,
23.	- czasu trwania zabiegu,
24.	- rozpoznania pooperacyjnego ICD9 i opisowego,
25.	- procedur medycznych z możliwością automatycznego dodania procedur powiązanych z przeprowadzonym zabiegiem,
26.	- opisu wykonanego zabiegu wraz z lekarzem opisującym,
27.	- składu zespołu zabiegowego domyślnie uzupełnianego na podstawie planu,
28.	- możliwość załączenia formularza definiowanego przez użytkownika,
29.	- możliwość dołączania załączników w postaci dowolnych plików (np. skany dokumentów, pliki dźwiękowe i wideo),
30.	- odnotowanie przetoczeń krwi i preparatów krwiopochodnych z wpisem do księgi transfuzyjnej, odnotowanie powikłań po przetoczeniu,
31.	- zużytych materiałów:
32.	-- z wykorzystaniem kodów kreskowych lub poprzez manualny wybór pozycji ze słownika,
33.	-- z możliwością automatycznego dodania materiałów z planu,
34.	-- z możliwością automatycznego dodania materiałów powiązanych z wykonanym zabiegiem,
35.	- możliwość rejestracji danych z poziomu oddziału i z poziomu bloku operacyjnego
36.	System musi umożliwić rejestrację danych znieczulenia, w tym:
37.	- czasu znieczulenia,
38.	- czasu anestezjologicznego,
39.	- rodzaju przeprowadzonego znieczulenia domyślnie wypełnianego na podstawie kwalifikacji z możliwością edycji,
40.	- opisu znieczulenia ze wskazaniem osoby opisującej,
41.	- zespołu anestezjologicznego domyślnie uzupełnionego na podstawie planu,
42.	- podanych leków:
43.	-- z wykorzystaniem kodów kreskowych lub poprzez manualny wybór pozycji ze słownika,
44.	-- z możliwością automatycznego dodania leków powiązanych z wykonanym zabiegiem
45.	System musi wspomagać opiekę pooperacyjną w zakresie:
46.	- ewidencji czasu trwania opieki pooperacyjnej oraz lekarza przyjmującego,
47.	- ewidencji wykonanych procedur,
48.	- ewidencji podanych leków i zużytych materiałów,
49.	- oceny stanu pacjenta z wykorzystaniem zmodyfikowanej skali Xxxxxxx'a
50.	- opisu powikłań znieczulenia,
51.	- opisu zaleceń pooperacyjnych,
52.	- ewidencji daty przekazania pacjenta na oddział wraz ze wskazaniem lekarza przekazującego.
53.	System musi umożliwiać prowadzenie Księgi Bloku Operacyjnego w zakresie:
54.	- możliwość definiowania księgi dla bloku operacyjnego, dla sali operacyjnej oraz dla grupy zabiegów,
55.	- przegląd ksiąg bloku operacyjnego wg różnych kryteriów, w tym:
56.	-- danych pacjenta (nazwisko, imię, XXXXX),
57.	-- xxxxx xxxxxxx,
58.	-- rodzaju zabiegu,
59.	-- dat wykonania zabiegu,
60.	-- bloku i sali operacyjnej,
61.	-- jednostki zlecającej,

62.	-- księgi zabiegów,
63.	-- roku księgi,
64.	-- zakresu numerów księgi,
65.	-- składu zespołu operacyjnego (operatora, pielęgniarski operacyjnej, anestezjologa, pielęgniarki anestezjologiczna),
66.	- wydruk księgi bloku operacyjnego
67.	System musi wspomagać prowadzenie dokumentacji zabiegu operacyjnego, w tym:
68.	- protokół z zabiegu operacyjnego,
69.	- protokół przekazania pacjenta na oddział
70.	- możliwość uzupełniania dokumentacji o materiały elektroniczne - skany dokumentów, zdjęcia, pliki dźwiękowe oraz wideo
71.	- opcjonalne przechowywanie wszystkich wersji utworzonych dokumentów
72.	Musi istnieć możliwość definiowania własnych szablonów wydruków
73.	Musi istnieć możliwość obsługi raportów wbudowanych, w tym:
74.	- raport z wykonań zabiegów operacyjnych z uwzględnieniem kryteriów: czas wykonania zabiegu, księga bloku, sala operacyjna z podziałem na rodzaj zabiegu, księgę bloku, salę i jednostkę zlecającą
75.	Musi istnieć możliwość definiowania własnych wykazów
76.	Musi istnieć możliwość projektowania formularzy dokumentacji medycznej
77.	System musi zapewnić integrację z innymi modułami systemu medycznego w zakresie:
78.	- dostępu do historii choroby i dokumentacji medycznej bieżącego pobytu szpitalnego,
79.	- rejestracji kart zakażeń,
80.	- automatycznej aktualizacji stanów magazynowych przy ewidencji leków i materiaółów,
81.	- wzajemnego udostępniania informacji o zleconych badaniach i konsultacjach,
82.	- przeglądu wyników zleconych badań i konsultacji,
83.	- przeglądu wszystkich poprzednich hospitalizacji pacjenta i wizyt w przychodni,
84.	- eksportu danych statystycznych oraz ilościowych o wykonanych świadczeniach, podanych lekach i zużytych materiałach z możliwością wykorzystania przez moduły Rachunku Kosztów Leczenia.
Lp.	Przychodnia
1	Moduł musi oferować web’owy interfejs użytkownika, z możliwością pracy, co najmniej w przeglądarkach Internet Explorer i Mozilla Firefox (bez konieczności instalowania dodatkowych aplikacji). Wskazana funkcjonalność powinna być dostępna zarówno na komputerach stacjonarnych jak i tabletach PC.
2	Ręczne i automatyczne, na podstawie częstotliwości użycia, wyróżnienie w słownika pozycji najczęściej używanych
3	Kontrola/parametryzacja Wielkich/małych liter. Możliwość ustawienia w wybranych polach jak ma być sformatowany wpis
4	Wyróżnienie pól: - których wypełnienie jest wymagane, - przeznaczonych do edycji, - wypełnionych niepoprawnie
5	System musi umożliwiać obsługę kodów 2D do rejestracji skierowań pochodzących z innych zakładów opieki
6	System umożliwia wykonanie nowej operacji w systemie bez konieczności przerywania czynności dotychczas wykonywanej (np. obsługa zdarzenie w trybie nagłym) i powrót do zawieszonej czynności bez utraty danych, kontekstu itp. Bez konieczności ponownego uruchamiania aplikacji i wykorzystania licencji z puli dostępnych.
7	Wszystkie błędy niewypełnienie pól obligatoryjnych oraz błędnego wypełnienia powinny być prezentowane w jednym komunikacie z możliwością szybkiego przejścia do miejsca aplikacji, gdzie te błędy wystąpiły.
8	W każdym polu edycyjnym(opisowym) tj. np. treść wywiadu powinna istnieć możliwość wybrania i skorzystania z dowolnego formularza, tekstu standardowego lub wczytania tekstu zapisanego w

	pliku zewnętrznym. Powinna również w tych miejscach istnieć możliwość zapisu do zewnętrznego pliku przygotowanego tekstu oraz powinny być udostępnione podstawowe narzędzia ułatwiające edycję np. kopiuj/wklej, możliwość wstawiania znaków specjalnych
9	System powinien umożliwiać sprawdzanie poprawności pisowni w polach opisowych tj. opis badania, wynik, epikryza
10	System musi umożliwić nadanie użytkownikowi lub grupie użytkowników uprawnień do wydruku dokumentu
11	System musi zachowywać dane pacjenta "scalonego" mechanizmem scalania pacjentów. Pacjent, którego dane zostały scalone z danymi innego pacjenta nie może być usunięty z systemu. Dane pacjenta powinny być dostępne do wyszukiwania w szczególności wyszukiwania wg identyfikatora pacjenta.
	Rejestracja/Recepcja
1	System musi umożliwiać określanie definiowanie dostępności usług placówki medycznej
2	Definiowanie grafików pracy
3	System musi umożliwiać określanie dostępności zasobów w placówce (grafiki) dla gabinetów:
4	- określenie szablonu dla każdego z dni tygodnia,
5	- określenie czasu pracy,
6	- określenie zakresu realizowanych usług
7	System musi umożliwiać definiowanie szablonu pracy lekarza:
8	- określenie szablonu dla każdego z dni tygodnia,
9	- określenie czasu pracy,
10	- określenie gabinetu, w którym wykonywane są usługi (miejsce wykonania).
11	System musi umożliwiać definiowanie przedziału wieku pacjentów obsługiwanych przez zasób
12	System musi umożliwiać generowanie grafików dla lekarzy w powiązaniu z gabinetami w zadanym okresie czasu,
13	System musi umożliwiać ustawienie blokady w grafiku z podaniem przyczyny tj. urlop, remont
14	Obsługa skorowidza pacjentów
15	System musi umożliwiać przypisanie pacjentowi uprawnień do obsługi poza kolejnością
16	Informacja o posiadanych uprawnieniach do obsługi poza kolejnością musi być prezentowana na listach pacjentów
17	System musi umożliwiać wyszukiwanie pacjentów, co najmniej, wg kryterium:
18	- imię, nazwisko i XXXXX pacjenta
19	- jednostka wykonująca
20	- osoba wykonująca
21	- osoba rejestrująca
22	- jednostka kierująca
23	- instytucja kierująca
24	- lekarz kierujący
25	- kartoteka
26	- identyfikator pacjenta
27	- świadczenie
28	- status na liście pacjentów (np. do obsłużenia, zaplanowany, zarejestrowany, anulowane, przyjęty/w realizacji)
29	- wizyty CITO
30	- status osoby: cudzoziemiec, VIP, uprawniony do obsługi poza kolejnością
31	Planowanie i rezerwacja wizyty pacjenta
32	System musi umożliwiać wyszukiwanie wolnych terminów jednoczesnej dostępności wymaganych zasobów:
33	- rezerwacja wybranego terminu lub „pierwszy wolny”.
34	- wyszukiwanie zasobów spełniających kryterium wieku pacjenta
35	- w przypadku braku wolnych terminów w preferowanych godzinach możliwość rezerwacji pierwszy wolny lub ręczny wybór terminu
36	- rezerwacja terminów dla pacjentów przebywających na oddziale

37	- wstawianie terminu pomiędzy już istniejące wpisy w grafiku w przypadkach nagłych (dopuszczenie planowania wielu wizyt w tym samym terminie) z możliwością wpisania komentarza do tak zaplanowanej wizyty
38	- przegląd liczby zaplanowanych wizyt z podziałem na pierwszorazowe i kontynuacje leczenia
39	- przegląd terminarza zaplanowanych wizy
40	- nadanie numeru rezerwacji w ramach rejestracji i jednostki wykonującej (gabinetu)
41	System musi umożliwiać obsługa kolejek oczekujących zgodnie z obowiązującymi przepisami
42	Podczas planowania wizyty, system powinien sugerować dokonanie wpisu do kolejki oczekujących, jeśli istnieje kolejka dla planowanej usługi lub gabinetu
43	Rejestracja na wizytę (usługę)
44	System musi umożliwić rejestrację pacjenta na wizytę (zaplanowaną w terminarzu i niezaplanowaną)
45	System musi pozwalać na określenie miejsca wykonania usługi (wybór gabinetu) dla usług niepodlegających planowaniu i rezerwacji.
46	System musi umożliwiać zlecenie wykonania usługi pacjentowi we wskazanym (lub wynikającym z rezerwacji) miejscu wykonania,
47	Obsługa wyników:
48	- odnotowanie wydania wyniku,
49	- wpisywanie wyników zewnętrznych.
50	Wydruk recept i kuponów
51	Raporty i wykazy Rejestracji.
	Gabinet lekarski
52	Obsługa wizyty
53	Podczas przyjęcia pacjenta skierowanego z innej jednostki np. oddział, jeśli nie został wskazany inny płatnik lub cennik, system powinien podpowiadać płatnika NFZ
54	System musi umożliwiać dostęp do listy pacjentów zarejestrowanych do gabinetu
55	System musi informować o uprawnieniach pacjenta do obsługi poza kolejnością
56	System powinien umożliwiać rejestrację faktu rozpoczęcia obsługi wizyty pacjenta w gabinecie (przyjęcie)
57	System musi umożliwić przegląd danych pacjenta, co najmniej, w następujących kategoriach:
58	- dane osobowe,
59	- dane medyczne pacjenta tj. grupa krwi, uczulenia, choroby przewlekłe, szczepienia, nazwisko lekarza rodzinnego
60	- uprawnienia z tytułu umów,
61	- informacja o stopniu ubezpieczenia - weryfikacja z eWUŚ
62	- historia leczenia (dane ze wszystkich wizyt i pobytów szpitalnych pacjenta),
63	- wyniki badań,
64	- przegląd rezerwacji historycznych i planowanych w przyszłości
65	Obsługa wizyty powinna obejmować przegląd, modyfikację i rejestrację danych w następujących kategoriach:
66	- wywiad (na formularzu zdefiniowanym dla wizyty),
67	- opis badania (na formularzu zdefiniowanym dla wizyty),
68	- informacje ze skierowania,
69	- kontrola daty ważności skierowania
70	- możliwość przepisania skierowania już zarejestrowanego
71	- skierowania, z możliwością skopiowania danych z innego pobytu w tej lub innej jednostce
72	- zlecanie badań diagnostycznych i laboratoryjnych, konsultacji, zabiegów,
73	- możliwość wykorzystania szablonów zleceń złożonych, paneli badań do zlecania
74	- usługi, świadczenia w ramach wizyty,
75	- rozpoznanie (główne, dodatkowe),
76	- kopiowanie wyników badania i danych wypisowych z zleconych podczas poprzednich wizyt
77	- zalecenia z wizyty (w tym zwolnienia lekarskie),
78	- wystawienie recept, skierowań, zapotrzebowań na zaopatrzenie ortopedyczne i okulary

79	System powinien informować o zleceniach wykonanych po zakończeniu poprzedniej wizyty i umożliwić rozliczenie ich w wizycie aktualnej
80	System musi umożliwić obsługę pobytów wielodniowych
81	System musi umożliwić obsługę domowego leczenia żywieniowego
82	System musi umożliwić obsługę tlenoterapii w warunkach domowych
	Wystawianie recept
1	System powinien wspierać wystawianie recept, co najmniej w zakresie:
2	- możliwości wybrania leków ze słownika leków,
3	- możliwości sprawdzenia interakcji poszczególnych leków oraz podpowiadanie stopnia refundacji na podstawie weryfikacji z eWUŚ
4	- możliwości wydruku recepty (z rozmieszczaniem i nadrukiem na formularzach recept),
5	- na wydruku leki powinny być prezentowane w kolejności zgodnej z kolejnością wpisywania
6	- system powinien podpowiadać dane osoby zalogowanej, jako wystawiającej receptę o ile osoba ta jest lekarze. Jeśli zalogowany użytkownik nie jest lekarzem, system powinien podpowiadać lekarz realizujący wizytę
7	- podpowiadanie ilości i jednostki, w jakich powinien zostać wydany lek
8	- kopiowanie recept z poprzednich wizyt z weryfikacją poziomu refundacji wg aktualnych danych ze słownika BAZYL lub słownika leków własnych
9	- kopiowanie recept musi umożliwiać wybór recepty do skopiowania spośród:
10	- recept z poprzedniego pobytu w tym gabinecie
11	- recept z wizyty takiej jak aktualna (ta sama usługa), niezależnie od gabinetu, w jakim się odbywała
12	- z innych pobytów w tej samej jednostce
13	- możliwości pomijania leków oznaczonych, jako "wycofane" w słowniku BAZYL
14	- możliwości wydruku recept tylko z puli lekarza zalogowanego
15	- ponowny wydruk recepty już wydrukowanej powinien spowodować utworzenie kopii recepty, dotyczy to również recept drukowanych w trybie nadruku na gotowych drukach
16	- oznaczenie wydrukowanej recepty, jako anulowanej
17	- system kontroluje przekroczenie minimalnej puli recept uwzględniając typ recepty RP/RPW
18	Musi istnieć możliwość wystawiania recept trans granicznych
	Dokumentacja wizyty
1	System musi umożliwiać wystawienie skierowania,
2	Skierowanie do jednostki zewnętrznej, dla pacjenta niepełnoletniego, powinno zawierać imię i nazwisko oraz adres opiekuna
3	- leki podane podczas wizyty (współpraca z apteczką oddziałową),
4	- ewidencja szczepień:
5	- możliwość oznaczenia podania leku jako szczepienia,
6	- możliwość wpisania przy podaniu leku danych charakteryzujących szczepienie,
7	- automatyczny wpis do karty szczepień po oznaczeniu podania leku, jako szczepienia.
8	- wykonane podczas wizyty dodatkowych usług i badania
9	- inne dokumenty (zaświadczenia, druki, na formularzach zdefiniowanych dla wizyty).
10	Możliwość stosowania słownika tekstów standardowych do opis danych wizyt
11	Możliwość wykorzystania definiowalnych formularzy do opisu danych wizyty
12	Możliwość stosowania „pozycji preferowanych” dla użytkowników, jednostek organizacyjnych (wyróżnienie najczęściej wykorzystywanych pozycji słowników).
13	Obsługa zakończenia wizyty:
14	- autoryzacja medyczna wizyty,
15	- automatyczne tworzenie karty wizyty.
16	- możliwość bezpośredniego skierowania na IP
17	Kwalifikacja rozliczeniowa usług i świadczeń.
18	- wiązanie rozliczanych badań do kolejnej zaplanowanej wizyty
19	Wgląd w rozliczenia NFZ z tytułu zrealizowanych w trakcie wizyty usług
20	Automatyczna aktualizacja i przegląd Księgi Głównej Przychodni

	Obsługa pakietu onkologicznego
1	System musi umożliwiać rejestrację kart diagnostyki i leczenia onkologicznego (KDILO) w zakresie:
2	- numer karty
3	- etap obsługi
4	- informacja, czy karta znajduje się w jednostce, czy poza nią
5	System musi rejestrować historię zmian karty DILO
6	System musi umożliwić powiązanie pozycji rozliczeniowych z numerem KDILO
	Konfiguracja pracy gabinetu
1	System musi pozwalać na dostosowanie modułu do specyfiki gabinetu lekarskiego, co najmniej w zakresie:
2	- możliwości zdefiniowania wzorców dokumentacji dedykowanej dla gabinetu
3	- możliwości zdefiniowania elementów menu (zakładek) w zależności od potrzeb i rodzaju usługi
4	- możliwość wykorzystania, zdefiniowanych wcześniej, wzorów dokumentów
5	System musi umożliwiać tworzenie raportów i wykazów pracy gabinetu
	Statystyka LO
1	Obsługa statystyki rozliczeniowej i medycznej
2	Automatyczna generacja Księgi Przychodni,
3	Dostęp do wszystkich ksiąg placówki Zamawiającego
4	Raporty i wykazy statystyczne, w tym:
5	- raport rozpoznań - zestawienie syntetyczne i analityczne ilości rozpoznań każdego rodzaju w rozbiciu na pacjentów i jednostki wykonujące
6	- wykonane badania wg płatnika i jednostki kierującej - zestawienie ilości wykonanych badań poszczególnych rodzajów, z podziałem na jednostki wykonujące, dla wybranych instytucji i jednostek kierujących
7	- lista pacjentów przyjętych przez lekarza - zestawienie pacjentów przyjętych w zadanym okresie, w wybranych gabinetach, przez wybranych lekarzy
8	- zestawienie statystyczne pacjentów - zestawienie syntetyczne lub analityczne (dla poszczególnych dni zadanego okresu) liczby pacjentów przyjętych w wybranych/wszystkich gabinetach w rozbiciu na dorosłych i dzieci z podziałem na płeć oraz pacjentów pierwszorazowych i kontynuację leczenia
9	- raport obciążenia gabinetów - zestawienie liczby wykonanych badań w poszczególnych dniach zadanego okresu dla wybranych/wszystkich gabinetów, dla poszczególnych lekarzy
10	- wykonane procedury - syntetyczne i analityczne (dla poszczególnych dni zadanego zakresu) zestawienie liczby procedur danego rodzaju wykonanych w zadanym okresie, w wybranych/wszystkich gabinetach, dla wybranego/wszystkich ubezpieczycieli i płatników
11	- zestawienie zrealizowanych badań - zestawienie liczby badań wykonanych pacjentom (podstawowe dane pacjenta) wraz z rozpoznaniami i procedurami w wybranej, wszystkich jednostkach, dla wybranych instytucji i jednostek kierujących wykonanych przez wybranego/wszystkich lekarzy
12	- lista zarejestrowanych/przyjętych pacjentów - zestawienie ilości zarejestrowanych pacjentów do wybranego gabinetu
13	- liczba usług wykonanych przez lekarza - zestawienie ilości usług wykonanych w jednostce przez danego lekarza
14	- zestawienie liczby przyjętych pacjentów - zestawienie liczby pacjentów przyjętych przez daną jednostkę i lekarza w ramach określonego pakietu świadczeń z podziałem na grupy wiekowe
15	- lista wykonanych usług - lista usług wraz z danymi takimi jak: jednostka i lekarz kierujący, miejsce i data wykonania, dane o wartości usługi, opłacie kontrahenta, opłacie pacjenta dla wybranych lub wszystkich: umów, pacjentów, świadczeń, instytucji i lekarzy kierujących oraz jednostek i lekarzy wykonujących
16	- zestawienie wystawionych skierowań - syntetyczne i analityczne (wg daty wystawienia) zestawienie ilości wystawionych skierowań na określone badania/usługi z podziałem na lekarzy wystawiających i/lub jednostki, w których wystawiono skierowanie dla wybranych lub wszystkich;

			jednostek, lekarzy kierujących, usług, statusów realizacji
17			- deklaracje - raport personalny - zestawienie liczby osób zadeklarowanych w wybranym miesiącu danego roku dla wybranej lub wszystkich umów oraz dla wybranego lub wszystkich rodzajów deklaracji
18			- kolejki oczekujących - zestawienie kolejek oczekujących w ujęciu syntetycznym (dane całej kolejki) i analitycznym (z danymi oczekujących pacjentów
19			- zestawienie wykonanych usług - lista pacjentów z wykonanymi usługami i procedurami oraz z danymi o instytucji, jednostce i lekarzu kierującym dla wybranej jednostki wykonującej w zadanym okresie
20			- zestawienie wykonanych usług pacjenta - lista usług wykonanych w określonym czasie dla wybranego pacjenta z wyszczególnieniem danych o wartości i opłatach
21			- zestawienie udzielonych porad i przyjętych pacjentów - syntetyczne i analityczne (pacjenci) zestawienie liczby udzielonych porad danego rodzaju z podziałem na : miejscowości zamieszkania, pacjenta lub typ porady w zadanym okresie, dla wybranych lub wszystkich gabinetów i wybranego rodzaju wizyty (pierwszorazowa, kolejna)
Lp.			Pracownia Diagnostyczna
1.			Moduł musi oferować web’owy interfejs użytkownika, z możliwością pracy co najmniej w przeglądarkach Internet Explorer i Mozilla Firefox (bez konieczności instalowania dodatkowych aplikacji). Wskazana funkcjonalność powinna być dostępna zarówno na komputerach stacjonarnych jak i tabletach PC.
2.			Ręczne i automatyczne, na podstawie częstotliwości użycia, wyróżnienie w słownika pozycji najczęściej używanych
3.			Kontrola/parametryzacja Wielkich/małych liter. Możliwość ustawienia w wybranych polach jak ma być sformatowany wpis
4.			Wyróżnienie pól: - których wypełnienie jest wymagane, - przeznaczonych do edycji, - wypełnionych niepoprawnie
5.			System umożliwia wykonanie nowej operacji w systemie bez konieczności przerywania czynności dotychczas wykonywanej (np. obsługa zdarzenie w trybie nagłym) i powrót do zawieszonej czynności bez utraty danych, kontekstu itp. Bez konieczności ponownego uruchamiania aplikacji i wykorzystania licencji z puli dostępnych.
6.			Wszystkie błędy niewypełnienie pól obligatoryjnych oraz błędnego wypełnienia powinny być prezentowane w jednym komunikacie z możliwością szybkiego przejścia do miejsca aplikacji, gdzie te błędy wystąpiły.
7.			W każdym polu edycyjnym(opisowym) tj. np. treść wywiadu powinna istnieć możliwość wybrania i skorzystania z dowolnego formularza, tekstu standardowego lub wczytania tekstu zapisanego w pliku zewnętrznym. Powinna również w tych miejscach istnieć możliwość zapisu do zewnętrznego pliku przygotowanego tekstu oraz powinny być udostępnione podstawowe narzędzia ułatwiające edycję np. kopiuj/wklej, możliwość wstawiania znaków specjalnych
8.			System powinien umożliwiać sprawdzanie poprawności pisowni w polach opisowych tj. opis badania, wynik, epikryza
9.			System musi umożliwić nadanie użytkownikowi lub grupie użytkowników uprawnień do wydruku dokumentu
10.			System musi zachowywać dane pacjenta "scalonego" mechanizmem scalania pacjentów. Pacjent, którego dane zostały scalone z danymi innego pacjenta nie może być usunięty z systemu. Dane pacjenta powinny być dostępne do wyszukiwania w szczególności wyszukiwania wg identyfikatora pacjenta.
11.			Dostęp do listy pacjentów zarejestrowanych do pracowni
12.			Na liście zleceń do wykonania powinna być wyświetlana informacja, czy badanie powinno być wykonane przy łóżku pacjenta
	13.		Rejestracja rozpoczęcia obsługi wizyty pacjenta w pracowni (przyjęcie)
	14.		Wspomaganie obsługi pacjenta w pracowni:

	15.		Przegląd danych pacjenta w następujących kategoriach:
	16.		- dane osobowe,
17.			- podstawowe dane medyczne (grupa krwi, uczulenia, stale podawane leki, przebyte choroby, karta szczepień),
	18.		- Historia Choroby (dane ze wszystkich wizyt pacjenta),
	19.		- wyniki badań,
	20.		- przegląd rezerwacji.
	21.		Możliwość zdefiniowania elementów menu (zakładek) w zależności od potrzeb i rodzaju usługi
	22.		Możliwość zdefiniowania wzorów dokumentów dedykowanych dla pracowni
	23.		Możliwość użytkowania zdefiniowanych wcześniej wzorców dokumentacji dedykowanej do wizyty,
	24.		Przegląd, wprowadzanie i modyfikacja danych wizyty w następujących kategoriach:
	25.		- informacje ze skierowania,
	26.		- skierowania, zlecenia,
	27.		- usługi, świadczenia w ramach wizyty,
	28.		- wystawione skierowania,
	29.		- wykonane podczas wizyty procedury dodatkowe
	30.		- inne dokumenty (zaświadczenia, druki, na formularzach zdefiniowanych dla wizyty).
	31.		- wynik badania
32.			- możliwość przechwytywania pojedynczych klatek obrazu z kamery lub innego źródła np. aparatu USG i dołączanie go do wyniku badania
33.			Możliwość stosowania słownika tekstów standardowych do opis danych wizyt
34.			Możliwość stosowania „pozycji preferowanych” dla użytkowników, jednostek organizacyjnych (wyróżnienie najczęściej wykorzystywanych pozycji słowników).
	35.		- obsługa stanowiska kasowego (jak w Rejestracji/Recepcji).
	36.		Obsługa zakończenia badania/wizyty:
	37.		- autoryzacja medyczna badania,
	38.		- automatyczne tworzenie karty wizyty/wyniku badania
	39.		Wgląd w rozliczenia NFZ z tytułu zrealizowanych w trakcie wizyty usług
	40.		Automatyczna generacja i przegląd Księgi Pracowni
	41.		Obsługa wyników badań:
	42.		- wprowadzanie opisów wyników badań diagnostycznych
43.			- wprowadzanie opisów wyników badań na definiowalnych formularzach wyników dostosowanych do rodzaju wykonywanego badania
	44.		- autoryzacja wyników badań diagnostycznych
	45.		- wydruk wyniku wg wzoru, jakim posługuje się pracownia
	46.		System powinien umożliwiać powtórny wydruk dokumentu już wydrukowanego.
Lp.			Rozliczenia z NFZ
1.			Moduł musi oferować web’owy interfejs użytkownika, z możliwością pracy, co najmniej w przeglądarkach Internet Explorer i Mozilla Firefox (bez konieczności instalowania dodatkowych aplikacji). Wskazana funkcjonalność powinna być dostępna zarówno na komputerach stacjonarnych jak i tabletach PC.
2.			Ręczne i automatyczne, na podstawie częstotliwości użycia, wyróżnienie w słownika pozycji najczęściej używanych
3.			Kontrola/parametryzacja Wielkich/małych liter. Możliwość ustawienia w wybranych polach jak ma być sformatowany wpis
4.			Wyróżnienie pól: - których wypełnienie jest wymagane, - przeznaczonych do edycji, - wypełnionych niepoprawnie
5.			System umożliwia wykonanie nowej operacji w systemie bez konieczności przerywania czynności dotychczas wykonywanej (np. obsługa zdarzenie w trybie nagłym) i powrót do zawieszonej czynności bez utraty danych, kontekstu itp. Bez konieczności ponownego uruchamiania aplikacji i

	wykorzystania licencji z puli dostępnych.
6.	Wszystkie błędy niewypełnienie pól obligatoryjnych oraz błędnego wypełnienia powinny być prezentowane w jednym komunikacie z możliwością szybkiego przejścia do miejsca aplikacji, gdzie te błędy wystąpiły.
7.	W każdym polu edycyjnym(opisowym) tj. np. treść wywiadu powinna istnieć możliwość wybrania i skorzystania z dowolnego formularza, tekstu standardowego lub wczytania tekstu zapisanego w pliku zewnętrznym. Powinna również w tych miejscach istnieć możliwość zapisu do zewnętrznego pliku przygotowanego tekstu oraz powinny być udostępnione podstawowe narzędzia ułatwiające edycję np. kopiuj/wklej, możliwość wstawiania znaków specjalnych
8.	System powinien umożliwiać sprawdzanie poprawności pisowni w polach opisowych tj. opis badania, wynik, epikryza
9.	System musi umożliwić nadanie użytkownikowi lub grupie użytkowników uprawnień do wydruku dokumentu
10.	System musi zachowywać dane pacjenta "scalonego" mechanizmem scalania pacjentów. Pacjent, którego dane zostały scalone z danymi innego pacjenta nie może być usunięty z systemu. Dane pacjenta powinny być dostępne do wyszukiwania w szczególności wyszukiwania wg identyfikatora pacjenta.
11.	Zarządzanie umowami NFZ
12.	Import pliku umowy w postaci komunikatu UMX,
13.	Przegląd i modyfikacja szczegółów umowy:
14.	- Okres obowiązywania umowy,
15.	- Pozycje planu umowy,
16.	- Miejsca realizacji świadczeń
17.	- Limity na realizację świadczeń i ceny jednostkowe,
18.	- Słowniki związane z umowami (słownik zakresów świadczeń, świadczeń jednostkowych, pakietów świadczeń, schematów leczenia itd.)
19.	- Parametry pozycji pakietów świadczeń
20.	Moduł korzysta bezpośrednio z danych zaewidencjonowanych w poradniach bez konieczności importu i kopiowania danych
21.	Weryfikacja wprowadzonych pozycji rozliczeniowych pod kątem zgodności ze stanem, po wczytaniu aneksu umowy (ze wstecznym okresem obowiązywania). Możliwość zbiorczej modyfikacji pozycji rozliczeniowych, w których znaleziono różnice
22.	- Różnica w cenie świadczenia,
23.	- Różnica w wadze efektywnej świadczenia,
24.	- Różnica w sposobie obliczania krotności i okresu sprawozdawczego,
25.	Definiowanie dodatkowych walidacji
26.	- Liczba realizacji świadczeń w okresie,
27.	- Liczba realizacji świadczeń w ramach zakresu w okresie,
28.	Możliwość ewidencji i rozliczenia realizowanych świadczeń
29.	- Ubezpieczonym,
30.	- Nieubezpieczonym a uprawnionym do świadczeń,
31.	- Uprawnionym na podstawie decyzji wójta/burmistrza
32.	- Uprawnionym na podstawie przepisów o koordynacji,
33.	- Uprawnionym na podstawie Karty Polaka
34.	- Kobietom w ciąży, w okresie połogu oraz młodzieży do 18 roku życia
35.	Możliwość zbiorczej modyfikacji pozycji rozliczeniowych w zakresie zmian dotyczących
36.	- Numeru umowy,
37.	- Zakresu świadczeń,
38.	- Wyróżnika
39.	- Świadczenia jednostkowego,
40.	Możliwość wprowadzenia dodatkowego poziomu kontroli wprowadzonych świadczeń poprzez funkcjonalność autoryzacji świadczeń przez osobę uprawnioną
41.	Przegląd informacji o posiadanych przez pacjenta uprawnieniach do świadczeń w każdym dniu

	wizyty
42.	Po otrzymaniu informacji z NFZ, uprawniony użytkownik działu rozliczeń musi mieć możliwość modyfikacji danych
43.	Sprawozdawczość z oddziałów NFZ w zakresie komunikacji przez pocztę elektroniczną musi odbywać się automatycznie, z poziomu systemu HIS
44.	W przypadku komunikatów, w których NFZ wymaga kompresowania lub szyfrowania danych, operacje te muszą odbywać się automatycznie w systemie HIS
45.	System musi umożliwić harmonogramowanie eksportów danych: o wyznaczonej godzinie, co określoną liczbę godzin, za określoną liczbę godzin
46.	Weryfikacja zestawów świadczeń pod kątem poprawności i kompletności wprowadzonych danych
47.	Wyszukiwanie pozycji błędnie potwierdzonych w komunikatach zwrotnych NFZ
48.	Wyszukiwanie po numerach w księgach
49.	Wyszukiwanie zestawów bez zaewidencjonowanych procedur ICD9
50.	Wyszukiwanie zestawów po numerze paczki, w której wyeksportowano dane do NFZ
51.	Wyszukiwanie po instytucji kierującej
52.	Wyszukiwanie po personelu kierującym/ realizującym
53.	Wyszukiwanie zestawów bez pozycji rozliczeniowych
54.	Wyszukiwanie zestawów z niekompletnymi danymi rozliczeniowymi
55.	Wyszukiwanie pozycji rozliczeniowych, które nie zostały jeszcze rozliczone
56.	Wyszukiwanie po statusie rozliczenia
57.	Wyszukiwanie zestawów zawierających rozliczenia ze wskazanej umowy
58.	Wyszukiwanie zestawów zawierających wskazane świadczenie jednostkowe
59.	Wyszukiwanie zestawów świadczeń z JGP wyznaczoną w zadanej wersji
60.	Wyszukiwanie zestawów świadczeń ratujących życie i zdrowie
61.	Wyszukiwanie zestawów świadczeń zrealizowanych dla wybranych uprawnień pacjenta
62.	Wyszukiwanie świadczeń, które zostały skorygowane, a informacja o skorygowaniu nie została sprawozdana do systemu NFZ
63.	Generowanie i eksport komunikatu fazy I (komunikat SWIAD) w aktualnie obowiązującej wersji publikowanej przez płatnika
64.	Import potwierdzeń do danych przekazanych w komunikacie I fazy (komunikat P_SWI)
65.	Import danych z pliku z szablonami rachunków (komunikat R_UMX)
66.	Eksport komunikatów związanych ze sprawozdawczością POZ
67.	- Eksport komunikatu DEKL – informacje o deklaracjach
68.	- Eksport komunikatu ZBPOZ – informacje o świadczeniach zrealizowanych w ramach POZ
69.	Import potwierdzeń związanych ze sprawozdawczością POZ
70.	- Import komunikatu P_DEK – potwierdzenia danych dla przesłanych deklaracji
71.	- Import komunikatu Z_WDP – wyniki weryfikacji deklaracji
72.	- Import komunikatu Z_RDP – rozliczenia deklaracji
73.	Eksport komunikatów związanych ze sprawozdawczością kolejek oczekujących
74.	- Eksport komunikatu LIOCZ – informacje o statystykach kolejek oczekujących
75.	- Eksport komunikatu KOL – informacje o oczekujących na świadczenia wysokospecjalistyczne
76.	Import potwierdzeń związanych ze sprawozdawczością kolejek oczekujących
77.	Import komunikatu P_LIO – potwierdzenie statystyk przekazanych w komunikacie LIOCZ
78.	Przegląd szablonów rachunków wygenerowanych i przekazanych przez płatnika
79.	Generowanie i wydruk rachunków na podstawie szablonów
80.	Generowanie i wydruk faktur na podstawie rachunków
81.	Generowanie i wydruk zestawień i raportów związanych ze sprawozdawczością wewnętrzną (możliwość śledzenia postępów wykonania zakontraktowanych świadczeń w ciągu trwania okresu rozliczeniowego)
82.	Raport z wykonanych świadczeń z możliwością ograniczenia danych do x.xx.:
83.	- Numeru umowy,
84.	- Zakresu miesięcy sprawozdawczych,
85.	- Miesiąca rozliczeniowego,

86.	- Jednostki realizującej,
87.	- Zakresu świadczeń i wyróżnika,
88.	- Świadczenia,
89.	- Numeru szablonu
90.	- Uprawnienia pacjenta do świadczeń
91.	Zestawienie z realizacja planu umowy,
92.	Zestawienie wykonań przyrostowo,
93.	Zestawienie wykonań według miejsc realizacji
94.	Sprawozdanie rzeczowe
95.	Eksport danych do formatu XLS
96.	Generowanie i wydruk dokumentów związanych ze sprawozdawczością wymaganą przez OW NFZ
97.	Sprawozdanie finansowe,
98.	Zestawienie świadczeń udzielonych świadczeniobiorcom innym niż ubezpieczeni,
99.	Zestawienie świadczeń wykonanych pacjentom na podstawie przepisów o koordynacji (UE),
100.	Zestawienie świadczeń wykonanych pacjentom na podstawie art. 2 ust. 1 ustawy (decyzja wójta/burmistrza),
101.	Zestawienie świadczeń wykonanych pacjentom nieubezpieczonym, rozliczanym na podstawie art. 12 lub art. 13 ustawy
102.	Wyliczanie kosztów porady u pacjenta nieubezpieczonego
103.	Załącznik nr 4 do umowy - chemioterapia
104.	Załącznik nr 4 do umowy – programy terapeutyczne
105.	Załączniki do umów POZ
106.	Ewidencja faktur zakupowych
107.	Import słownika produktów handlowych (komunikat PRH)
108.	Możliwość przekodowania produktów handlowych na leki
109.	Ewidencja faktur zakupowych
110.	Generowanie i eksport faktur zakupowych do NFZ w aktualnym formacie komunikatu FZX
111.	Import potwierdzeń do faktur zakupowych (komunikat FZZ)
112.	Generowanie i wydruk załącznika nr 4 do umowy – ewidencja faktur zakupowych
113.	Obsługa sprawozdawczości w zakresie POZ
114.	System powinien umożliwiać definiowanie minimalnej i maksymalnej liczby pacjentów uczestniczących w sesjach
115.	Integracja z innymi modułami systemu
116.	- ewidencja pozycji rozliczeniowych w Ruchu Chorych, Przychodni
117.	- ewidencja faktur zakupowych za leki w chemioterapii w module Apteka
118.	- ewidencja faktur zakupowych na leki stosowane w programach lekowych
119.	Eksport faktur rozliczeniowych do modułu Finansowo-Księgowego
120.	Przekazywanie danych o hospitalizacji do Symulatora JGP
	JGP
121.	Import aktualnego słownika procedur medycznych ICD9 (komunikat ICD9),
122.	Zapewnienie sprawnego zasilania systemu w aktualne charakterystyki JGP wynikające z publikowanych Zarządzeń Prezesa NFZ
123.	Wyznaczanie JGP za pomocą wbudowanego (lokalnego) grupera JGP w zakresie umów: leczenie ambulatoryjne opieka specjalistyczna
124.	Wsteczna weryfikacja poprawności wyznaczonych wcześniej JGP z możliwością aktualizacji JGP na poprawną
125.	Różnice wynikające z wczytania nowych wersji grupera, które opublikowano z wsteczną datą obowiązywania, które mogą obejmować
126.	- Różnice w zaewidencjonowanych taryfach,
127.	- Różnice w zaewidencjonowanych JGP,
128.	Różnice wynikające z modyfikacji danych statystycznych a mające wpływ na wyznaczoną JGP:
129.	- Konieczność zmiany JGP,
130.	- Konieczność zmiany taryfy,

131.	Wyszukiwanie wizyt wg poniższych kryteriów
132.	- Data zakończenia wizyty,
133.	- Wersja grupera za pomocą, którego wyznaczono JGP
134.	- Kod JGP,
135.	- Rozpoznanie główne
136.	- Kod procedury medycznej,
137.	- Status rozliczenia
138.	Wsteczna weryfikacja z możliwością aktualizacji JGP pod kątem znalezienia bardziej optymalnej JGP
139.	Możliwość wydrukowania charakterystyki wybranej JGP w formie podręcznej karty
140.	Możliwość wykonywania symulacji wyznaczania JGP (funkcjonalność Symulatora JGP)
Lp.	Deklaracje POZ
141.	Moduł musi oferować web’owy interfejs użytkownika, z możliwością pracy co najmniej w przeglądarkach Internet Explorer i Mozilla Firefox (bez konieczności instalowania dodatkowych aplikacji). Wskazana funkcjonalność powinna być dostępna zarówno na komputerach stacjonarnych jak i tabletach PC.
142.	Import umów w rodzaju POZ
143.	Ewidencja deklaracji POZ/KAOS
144.	- Deklaracje do lekarza rodzinnego,
145.	- Deklaracje do pielęgniarki,
146.	- Deklaracje do położnej,
147.	- Deklaracje z zakresu medycyny szkolnej,
148.	- Kompleksowa ambulatoryjna opieka nad pacjentem z cukrzycą,
149.	- Kompleksowa ambulatoryjna opieka nad pacjentem zarażonym HIV
150.	Ewidencja porad POZ
151.	Generowanie i eksport komunikatów XML w aktualnie obowiązujących wersjach z zakresu sprawozdawczości związanej z deklaracjami POZ/KAOS
152.	Komunikat DEKL – komunikat szczegółowy deklaracji POZ/KAOS
153.	Komunikat ZBPOZ – komunikat szczegółowy danych zbiorczych o świadczeniach udzielonych w ramach POZ
154.	Import komunikatów zwrotnych XML w obowiązujących wersjach
155.	Import komunikatu „potwierdzeń odbioru” danych przesłanych komunikatami DEKL i ZBPOZ
156.	Import komunikatu potwierdzeń do deklaracji POZ/KAOS (komunikat P_DEK)
157.	Import komunikatu zwrotnego z weryfikacji deklaracji POZ/KAOS (komunikat P_WDP)
158.	Import komunikatu zwrotnego rozliczenia deklaracji POZ/KAOS (komunikat Z_RDP)
159.	Przegląd potwierdzeń deklaracji POZ/KAOS
160.	Przegląd weryfikacji deklaracji POZ/KAOS z możliwością zbiorczego wycofania deklaracji, które nie zostały zaliczone przez NFZ
161.	Generowanie rachunków deklaracji POZ
162.	Generowanie i wydruk załączników i sprawozdań POZ zgodnie z wytycznymi płatnika
163.	Załącznik nr 4 do umowy POZ
164.	Załącznik nr 5 do umowy POZ w zakresie: nocna i świąteczna opieka lekarska i pielęgniarska w POZ
165.	Załącznik nr 6 do umowy POZ w zakresie: transport sanitarny w POZ
166.	Półroczne sprawozdanie z wykonanych badań diagnostycznych
Lp.	Kolejki Oczekujących
167.	Moduł musi oferować web’owy interfejs użytkownika, z możliwością pracy co najmniej w przeglądarkach Internet Explorer i Mozilla Firefox (bez konieczności instalowania dodatkowych aplikacji). Wskazana funkcjonalność powinna być dostępna zarówno na komputerach stacjonarnych jak i tabletach PC.
168.	Definicja kolejek oczekujących zgodnie z wymaganiami płatnika
169.	Kolejki oczekujących do komórek organizacyjnych
170.	Kolejki oczekujących do procedur medycznych lub świadczeń wysokospecjalistycznych

	zdefiniowanych przez płatnika
171.	Prowadzenie kolejek oczekujących
172.	Wykaz osób oczekujących w kolejce
173.	Możliwość planowania daty z dokładnością do dnia lub tygodnia (w przypadku odległego terminu realizacji świadczenia)
174.	Przyporządkowanie oczekujących do jednej z kategorii medycznych (przypadki pilne/przypadki stabilne)
175.	Rejestrowanie przypadków zmian terminu udzielenia świadczenia wraz z przyczyną zmiany
176.	Zablokowanie możliwości zmiany danych w kolejce oczekujących dla pacjentów zrealizowanych, po zakończeniu okresu rozliczeniowego tj. po 10 dniu każdego miesiąca za miesiąc rozliczeniowy (poprzedni)
177.	Możliwość zbiorczego przenoszenia oczekujących pomiędzy kolejkami
178.	- Wszystkich aktywnych pozycji
179.	- Wybranych oczekujących
180.	Wskazanie tych definicji kolejek oczekujących, które po wczytaniu aneksu do umowy posiadają nieaktualne informacje o kodzie komórki wg NFZ wraz z możliwością aktualizacji kodu komórki wg NFZ na podstawie aktualnych zapisów w umowie z NFZ
181.	Generowanie statystyk kolejek z podziałem na przypadki pilne i stabilne
182.	- Liczba oczekujących
183.	- Szacunkowy czas oczekiwania w kolejce
184.	- Średni rzeczywisty czas oczekiwania w kolejce (zgodnie z algorytmem opublikowanym w rozporządzeniu)
185.	Generowanie i eksport komunikatów XML w aktualnie obowiązujących wersjach z zakresu sprawozdawczości związanej z kolejkami oczekujących
186.	Komunikat LIOCZ – komunikat szczegółowy o kolejkach oczekujących
187.	Komunikat KOL – komunikat o kolejkach oczekujących do świadczeń wysokospecjalistycznych
188.	Import komunikatu „potwierdzeń odbioru” danych o kolejkach oczekujących
189.	Wydruk listy oczekujących z uwzględnieniem poniższych kryteriów
190.	- Rodzaj kolejki (do komórki organizacyjnej, do procedury medycznej/świadczenia wysokospecjalistycznego)
191.	- Kod kolejki
192.	- Stan wpisu w kolejce (aktywne, wykreślone, zakończone realizacją)
193.	- Kategoria medyczna (pilny, stabilny)
194.	- Data wpisu (od .. do ..)
195.	- Data planowanej realizacji (od .. do ..)
196.	- Data skreślenia z kolejki (od .. do ..)
Lp.	Weryfikacja uprawnień świadczeniobiorców
197.	Moduł musi oferować web’owy interfejs użytkownika, z możliwością pracy co najmniej w przeglądarkach Internet Explorer i Mozilla Firefox (bez konieczności instalowania dodatkowych aplikacji). Wskazana funkcjonalność powinna być dostępna zarówno na komputerach stacjonarnych jak i tabletach PC.
198.	Weryfikacja uprawnień pacjenta do świadczeń refundowanych przez NFZ podczas
199.	- rejestracji/planowania wizyty w przychodni lub pracowni, weryfikowany jest stan na dzień rejestracji
200.	Tworzenie harmonogramów weryfikacji grupowej
201.	Weryfikacja uprawnień w oparciu o harmonogramy obejmująca pacjentów
202.	- w trakcie wizyt
203.	Oznaczanie ikoną i kolorem statusu weryfikacji pacjenta
204.	- na liście pacjentów
205.	- w widocznym miejscu przy danych pacjenta
Lp.	Symulator JGP
1.	Symulator dostępny w systemie, działający w oparciu o dane medyczne zgromadzone w systemie medycznym

2.	Symulator dostępny poprzez przeglądarkę WWW bez konieczności dostępu do zewnętrznej sieci Internet
3.	Wstępne zasilenie symulatora danymi z wybranej hospitalizacji
4.	Możliwość sprawnej modyfikacji danych w symulatorze i obserwacja wpływu zmian na wyznaczane JGP
5.	Modyfikacja danych pacjenta (wiek, płeć),
6.	Modyfikacja danych hospitalizacji (data przyjęcia, data wypisu, tryb przyjęcia, tryb wypisu, tryb i charakter hospitalizacji,
7.	Dodanie lub usuniecie pobytu
8.	Modyfikacja danych pobytu (data przyjęcia, data wypisu, cz. VIII kodu resortowego komórki, kod świadczenia, rozpoznanie zasadnicze, rozpoznania współistniejące, procedury medyczne (daty wykonania))
9.	Wyróżnianie kolorami danych hospitalizacji nieistotnych z punktu widzenia wyznaczenia JGP
10.	Możliwość określenia wersji grupera za pomocą, którego wyznaczone zostaną JGP
11.	Wersja grupera wynikająca z daty zakończenia hospitalizacji,
12.	Dowolna wersja grupera istniejąca w systemie,
13.	Wskazywanie JGP z podziałem na:
14.	- JGP, dla której hospitalizacja spełnia warunki wyboru,
15.	- JGP, dla których hospitalizacja nie spełnia warunków,
16.	- JGP, które istnieją w planie umowy świadczeniodawcy,
17.	Wyróżnienie kolorem pozycji w celu odzwierciedlenia ważności wyznaczonych JGP z punktu widzenia świadczeniodawcy (np. istniejących w planie umowy a tym samym możliwych do rozliczenia)
18.	W przypadku wskazania JGP, do których pacjent mógłby zostać zakwalifikowany jednak nie zostały spełnione wszystkie warunki - wskazanie tych warunków
19.	Możliwość przeglądu podstawowych informacji o wybranej JGP
20.	Wartości taryf dla poszczególnych trybów hospitalizacji,
21.	Parametry związane z mechanizmem osobodni (liczba dni finansowana grupą, taryfa dla hospitalizacji trwających < 2 dni, wartość punktowa osobodnia ponad ryczałt finansowany grupą),
22.	Parametry JGP (warunki, które musi spełniać hospitalizacja),
23.	Wykorzystanie planu umowy dla JGP w przypadku, gdy JGP istnieje w umowie ,
24.	Prezentacja wykresów ilustrujących zależność naliczonych taryf od czasu hospitalizacji pacjenta
Lp.	Dokumentacja Formularzowa
1	Generowanie Historii Choroby z danych zgromadzonych w systemie
2	Generowanie Karty Informacyjnej z danych gromadzonych w systemie
3	Generowanie wyników badań dla zadanych kryteriów: pacjent, nazwa badania, jednostka organizacyjna, zadany czasu,
4	Generowanie wydruków kart obserwacji pacjenta
5	Generowanie wydruków kart zakażenia, kart drobnoustroju
6	Generowanie raportów z dyżuru lekarskiego na podstawie zarejestrowanych obserwacji pacjenta
7	Generowanie raportów z diagnoz pielęgniarskich
8	Wydruk diagnoz pielęgniarskich
9	System musi umożliwiać dopasowanie systemu do potrzeb Zamawiającego w zakresie dokumentowania procesu leczenia:
10	- definiowania własnych formularzy przeznaczonych do wpisywania danych w systemie.
11	- wyświetlanie, wprowadzanie i drukowanie informacji w ustalonej przez użytkownika postaci (definiowalne formularze oraz edytor wydruków dla badań, konsultacji, itp.).
12	- histogramy
13	- możliwość kojarzenia formularzy ze zleceniami i elementami leczenia
14	- rejestrowanie danych multimedialnych (rysunki, obrazy, dźwięki, itp.).
15	- dostęp do danych dla potrzeb analityczno-sprawozdawczych.
16	System powinien przechowywać wszystkie wersje utworzonej i wydrukowanej (lub

	zarchiwizowanej w archiwum elektronicznym) dokumentacji medycznej.
17	Wszystkie dokumenty dokumentacji medycznej pacjenta powinny być dostępne z jednego miejsca
18	Musi istnieć możliwość zdefiniowania drukarki dla każdego rodzaju dokumentu tak, aby dokument mógł być drukowany na odpowiedniej dla niego drukarce
19	Powinna istnieć możliwość podpisania elektronicznego i zarchiwizowania wszystkich dokumentów dokumentacji medycznej tworzonych przez system zgodnie z obowiązującymi przepisami.
20	Możliwość zablokowania modyfikacji wpisów w historii choroby dokonanych przez innego lekarza niż lekarz aktualnie zalogowany/ autoryzujący wpis
21	Możliwość autoryzacji przez lekarza dokonującego wpis, fragmentu historii choroby, epikryzy lub rozpoznania
22	Podczas wydruku dokumentu system sprawdza i informuje czy dane źródłowe wykorzystane do utworzenia dokumentu uległy zmianie.
23	System musi być wyposażony w mechanizmy umożliwiające weryfikację, czy na określonym etapie procesu obsługi pacjenta zostały utworzone wszystkie wymagane dokumenty
24	Musi istnieć możliwość utworzenia dokumentu roboczego, umożliwiającego podgląd danych źródłowych w postaci dokumentu
25	System umożliwia obsługę dokumentów o zmiennej treści, o ile nie stoi to w sprzeczności z wymaganiami zewnętrznymi dotyczącymi tych dokumentów (np. ściśle określony format lub zawartość informacyjna dla dokumentów skierowań, zleceń, recept)

H. Wymagania i funkcjonalności zamawianego systemu (część administracyjna -ERP)

Zamawiający dopuszcza inny podział oferowanego systemu na moduły, niż przedstawiony poniżej. Jednocześnie Wykonawca zobowiązany jest wskazać, że jego system pokrywa całą opisaną w niniejszej tabeli funkcjonalność oraz przedstawić podział na moduły oferowanego systemu, a także przedstawić funkcjonalność tych modułów w ofercie.

Lp.	Akty prawne i normy
1.	Oferowane oprogramowanie jest zgodne z aktualnymi aktami prawnymi regulującymi organizację i działalność sektora usług medycznych i opieki zdrowotnej w kraju. w tym:
2.	Ustawa z dnia 29 września 1994 r. o rachunkowości (Dz.U. 1994 nr 121 poz. 591) z późniejszymi zmianami (w szczególności nowelizacją obowiązującą od 1 stycznia 2002 r.)
3.	Ustawa z dnia 11.03.2004 o podatku od towarów i usług z późniejszymi zmianami
4.	Rozporządzenie Ministra Zdrowia i Opieki Społecznej z dnia 22 grudnia 1998 r. w sprawie szczególnych zasad rachunku kosztów w publicznych zakładach opieki zdrowotnej (Dz.U. 1998 nr 164 poz. 1194)
5.	Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz.U. z 2004 nr 100, poz.1024)
6.	Ustawa z dnia 17 lutego 2005 o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U z 2005 nr 64) z późniejszymi zmianami
7.	Rozporządzenie Rady Ministrów z dnia 11 października 2005 w sprawie minimalnych wymagań dla systemów teleinformatycznych (Dz.U. 2005 Nr 212, poz. 1766).
8.	System musi spełniać wymogi wynikające z ustawy „o Ochronie Danych Osobowych” z 29 czerwca 1997 roku oraz z Rozporządzenia MSWiA z 29 kwietnia 2004 roku, w szczególności system musi przechowywać informacje o:
9.	dacie wprowadzenia danych osobowych
10.	identyfikator użytkownika wprowadzającego dane osobowe
11.	źródło danych (o ile dane nie pochodzą od osoby, której te dane dotyczą)
12.	informacje o odbiorcach danych którym dane osobowe zostały udostępnione,
13.	dacie i zakresie tego udostępnienia
14.	data modyfikacji danych osobowych
15.	identyfikator operatora modyfikującego dane
Lp.	Wymagania ogólne
1.	System ma interfejs graficzny dla wszystkich modułów
2.	System pracuje w środowisku graficznym MS Windows na stanowiskach użytkowników
3.	(preferowane środowisko MS Windows XP/Vista)
4.	Wszystkie moduły systemu działają w oparciu o jeden motor bazy danych
5.	Wszystkie moduły/ systemy pochodzą od jednego producenta
6.	System komunikuje się z użytkownikiem w języku polskim. Jest wyposażony w system podpowiedzi (help). W przypadku oprogramowania narzędziowego i administracyjnego serwera bazy danych - częściowa komunikacja w języku angielskim
7.	W funkcjach związanych z wprowadzaniem danych system udostępnia podpowiedzi, automatyczne wypełnianie pól, słowniki grup danych (katalogi leków, procedur medycznych, danych osobowych, terytorialnych).
8.	System zapewnia odporność struktur danych (baz danych) na uszkodzenia oraz pozwala na szybkie odtworzenie ich zawartości i właściwego stanu, jak również posiada łatwość wykonania ich kopii bieżących oraz łatwość odtwarzania z kopii. System jest wyposażony w zabezpieczenia przed nieautoryzowanym dostępem. Zabezpieczenia funkcjonują na poziomie klienta (aplikacja) i serwera (serwer baz danych).
9.	System jest wykonany w technologii klient-serwer, dane są przechowywane w modelu relacyjnym baz danych z wykorzystaniem aktywnego serwera baz danych.

10.	System musi być wyposażony w zabezpieczenia przed nieautoryzowanym dostępem. Zabezpieczenia muszą funkcjonować na poziomie klienta (aplikacja) i serwera (serwer baz danych),
11.	System musi posiadać mechanizmy umożliwiające zapis i przeglądanie danych o logowaniu użytkowników do systemu
12.	System musi umożliwiać podgląd aktualnie zalogowanych do systemu użytkowników.
13.	System musi tworzyć i utrzymywać log systemu, rejestrujący wszystkich użytkowników systemu i wykonane przez nich najważniejsze czynności z możliwością analizy historii zmienianych wartości danych.
14.	Administrator musi posiadać możliwość z poziomu aplikacji z modułu administratora nadawania danemu użytkownikowi unikalnego loginu oraz hasła. Administrator musi posiadać możliwość ustawienia parametrów hasła: długość, czas żywotności, czas przed wygaśnięciem
15.	Administrator musi posiadać z poziomu aplikacji możliwość wylogowania wszystkich użytkowników aplikacji oraz zablokowania im dostępu do niej przez określony czas
16.	W przypadku przechowywania haseł w bazie danych, hasła muszą być zapamiętane w postaci niejawnej (zaszyfrowanej).
17.	Dane powinny być chronione przed niepowołanym dostępem przy pomocy mechanizmu uprawnień użytkowników. Każdy użytkownik systemu powinien mieć odrębny login i hasło. Jakakolwiek funkcjonalność systemu (niezależnie od ilości modułów) będzie dostępna dla użytkownika dopiero po jego zalogowaniu. Systemu uprawnień powinien być tak skonstruowany, aby można było użytkownikowi nadać uprawnienia z dokładnością do rodzaju wykonywanej operacji tj. osobne uprawnienie na odczyt danych i osobne na wprowadzanie/modyfikację danych. System uprawnień powinien umożliwiać definiowanie grup uprawnień, które to mogłyby być przydzielane poszczególnym użytkownikom.
18.	Równolegle musi istnieć możliwość nadawania użytkownikowi pojedynczych uprawnień z listy dostępnych. System musi umożliwiać definiowanie grup użytkowników i przydzielanie użytkowników do tych grup.
19.	System umożliwia administratorowi z poziomu aplikacji definiowanie i zmianę praw dostępu dla poszczególnych użytkowników i grup użytkowników z dokładnością do poszczególnych modułów oraz funkcji systemu
20.	Jednokrotne logowanie do systemu umożliwiające dostęp do wszystkich modułów, do których użytkownik posiada uprawnienia
21.	Możliwość uruchomienia kolejnej aplikacji bez konieczności wylosowywania się z dotychczas używanej aplikacji i ponownego logowania.
22.	Definiowanie pulpitu użytkownika umożliwiającego uruchomienie wszystkich modułów, aplikacji czy funkcjonalności Systemu, do jakich posiada uprawnienia, również aplikacji nie będących przedmiotem zamówienia np. aplikacje biurowe.
23.	Dostęp do pulpitu użytkownika powinien być zabezpieczony hasłem.
LP.	Wycena kosztów normatywnych świadczeń
1.	Możliwość opisania normatywnych nakładów osobowych i materiałowych niezbędnych do wykonania świadczenia lub grupy JGP :
2.	-określenie nakładów materiałowych potrzebnych do wykonania świadczenia lub grupy JGP na podstawie zdefiniowanego słownika materiałów i słownika leków z możliwością systemowej integracji w tym zakresie ze słownikami użytkowanymi przez moduły realizujące funkcjonalność w zakresie obsługi magazynu materiałów i obsługi magazynu leków,
3.	- określenie nakładów osobowych personelu uczestniczącego w wykonaniu świadczenia,
4.	- określenie ilości lub czasu pracy urządzenia użytego do wykonania świadczenia oraz jednostkowego kosztu pracy (dane pobierane z modułu środki trwałe i wyliczane na podstawie amortyzacji) lub wpisanie wartości kosztów w podziale na koszty rodzajowe ręcznie
5.	- możliwość wykorzystania do opisu świadczenia – świadczeń prostych wcześniej opisanych
6.	- możliwość wykorzystania do opisu JGP – świadczeń wcześniej opisanych, z określeniem miejsca wykonania
7.	- określenie średniej ilości osobodni w ramach JGP dla oddziału rozliczającego dane JGP lub

	innego oddziału
8.	- możliwość wydruku przygotowanych opisów świadczeń,
9.	- możliwość automatycznego stworzenia opisu świadczenia dla ośrodka na podstawie wzorca przygotowanego dla całego zakładu.
10.	Możliwość opisywania tych samych świadczeń w sposób różny dla każdego ośrodka wykonującego,
11.	Możliwość aktualizacji kosztów nakładów materiałowych w trybie miesięcznym poprzez:
12.	- aktualizację „ręczną”,
13.	- automatyczne przepisanie kosztów materiałów i leków z poprzedniego miesiąca,
14.	- integrację w zakresie średnich cen dostaw materiałów i leków z modułami realizującymi funkcjonalność w zakresie obsługi magazynu materiałów i obsługi magazynu leków,
15.	Uaktualnienie kosztów nakładów osobowych personelu,
16.	Wyliczenie aktualnych sumarycznych kosztów normatywnych,
17.	Wydruk wyliczonych kosztów normatywnych.
18.	Raporty kontroli celowości wydania materiałów z magazynu materiałów do miejsc udzielania świadczeń (w ramach systemowej integracji z modułem realizującym funkcjonalność obsługi magazynu i ewidencją udzielonych świadczeń w miejscach udzielania,
19.	Analizy porównawcze kosztów zaksięgowanych w kartotece ośrodka powstawania kosztów FK z kosztami wynikającymi z normatywu i zaewidencjonowanej ilości wykonań.
20.	Możliwość określenia kosztu osobodnia do wyliczenia kosztu JGP poprzez
21.	- aktualizację „ręczną”,
22.	- automatyczne przepisanie kosztów osobodnia z poprzedniego miesiąca,
23.	- obliczenie kosztu osobodnia z na podstawie kosztów rzeczywistych (do wyboru koszty bezpośrednie, całkowite, wytworzenia, sprzedaży) z wybranych miesięcy, z wyłączeniem wybranych kosztów szczegółowych, wg określonego klucza podziału
Lp.	Kalkulacja kosztów leczenia
1.	Kalkulacja indywidualnych kosztów leczenia pacjenta:
2.	Możliwość automatycznego pobierania danych o pacjencie w zakresie zrealizowanych mu świadczeń z aplikacji medycznych (Przychodnia, Ruch Chorych i Apteczka oddziałowa):
3.	- osobodni,
4.	- procedury,
5.	- badania,
6.	- leki.
7.	możliwość wydruku kosztowej karty pacjenta dającej możliwość wyceny pobytu pacjenta (wydruk jako załącznik może być podstawą wystawienia faktury za pobyt pacjenta nieubezpieczonego) z wyszczególnieniem kosztów świadczeń i leków istotnych kosztowo oraz włączeniem kosztów pozostałych świadczeń do kosztów ogólnych pobytu:
8.	- w zakresie kosztów leków – na poziomie cen leków z konkretnej dostawy, w ramach której zrealizowano podania dla pacjenta (inetgracja z modułami Apteka, Apteczka oddziałowa),
9.	- w zakresie rzeczywistych kosztów świadczeń (z ostatniego miesiąca, dla którego taka wycena istnieje – integracja z modułem Koszty)
10.	Możliwość grupowania kosztowych kart pacjentów wg zdefiniowanych kryteriów i prowadzenia analiz ekonomicznych (np. wg jednostek chorobowych, produktów rozliczeniowych).
11.	Możliwość definiowania wskaźników kosztowo-przychodowych w oparciu o predefiniowane funkcje dla:
12.	- pacjentów,
13.	- ośrodków powstawania kosztów,
14.	- jednostek chorobowych,
15.	- produktów kontraktowych.
16.	Możliwość zestawienia przychodów i kosztów hospitalizacji na poziomie:
17.	- pojedynczego pacjenta,
18.	- kodu JGP,
19.	- produktu jednostkowego,

20.	- produktu kontraktowego,
21.	- rozpoznania głównego.
22.	Możliwość zestawienia statystyk kosztów pobytów z podziałem na lekarzy prowadzących.
23.	Możliwość szacunkowej kalkulacji dotychczasowych kosztów pacjenta w trakcie trwania hospitalizacji w oparciu o dane historyczne lub zdefiniowane cenniki (w przypadku braku danych historycznych).
24.	Możliwość prezentacji kosztów zleceń do jednostek zewnętrznych wg przyjętych cen umownych z daną jednostką
25.	Możliwość porównania liczby osobodni wynikającej z danych zaewidencjonowanych w systemie medycznym z liczbą osobni przesłaną do modułu KKL z modułu Rachunek Kosztów.

I. Pozostałe wymagania

Lp .	System obsługi zgłoszeń
1.	Obsługa zgłoszeń błędów oraz zmian funkcjonalności w formie elektronicznej poprzez Witrynę Internetową Wykonawcy (WIW).
2.	Autoryzowany dostęp do witryny dla uprawnionych pracowników Zamawiającego
3.	Dostęp do różnych konsoli zarządzania zgłoszeniami
4.	Konsola zgłaszającego dostępna dla wszystkich uprawnionych pracowników Zamawiającego - umożliwia użytkownikowi witryny WIW dostęp tylko do własnych zgłoszeń
5.	Konsola KZS (Kierownika Zespołu Serwisowego) dostępna dla Lidera (Liderów) zespołu po stronie Zamawiającego – umożliwia dostęp do zgłoszeń wszystkich użytkowników witryny WIW ze strony Zamawiającego
6.	Rejestracja zgłoszenia w formie elektronicznej na witrynie WIW
7.	Rejestracja treści zgłoszenia wraz z opcjonalnymi załącznikami
8.	Kategoryzacja zgłoszenia przez zgłaszającego, zgodnie z zasadami zawartymi w umowie
9.	Wybór przedmiotu zgłoszenia - wersji systemu/modułu oraz umowy (umowa serwisowa, nadzoru autorskiego itp.) w ramach której zostały określone warunki realizacji zgłoszeń i czasy SLA wykorzystywane podczas realizacji zgłoszenia
10 .	Prezentacja statusu zgłoszenia, umożliwiającego szybką weryfikację stanu zaawansowania prac oraz konieczność wykonania określonych czynności przez zgłaszającego (uszczegółowienie zgłoszenia, akceptacja realizacji itp.)
11 .	Dwustronna komunikacja w trakcie realizacji zgłoszenia pomiędzy zgłaszającym a osobą realizującą zgłoszenie (poprzez witrynę WIW)
12 .	Przesyłanie informacji (również z załącznikami) mających na celu doprecyzowanie opisu zgłoszenia, starczenia dodatkowych wyjaśnień itp.
13 .	Prezentacja istotnych informacji w trakcie realizacji zgłoszenia (dla zgłaszającego)
14 .	Informacje o wynikach analizy zgłoszenia, planowanym sposobie realizacji i terminie realizacji
15 .	Informacje o tymczasowym rozwiązaniu zgłoszenia (o ile takowe istnieje), które umożliwi dalszą pracę w istniejącym systemie do momentu pojawienia się rozwiązania właściwego.
16 .	Informacje o zrealizowaniu zgłoszenia wraz z ewentualnymi dodatkowymi wyjaśnieniami
17.	Prezentacja rozwiązania zgłoszenia z możliwością akceptacji/odrzucenia przez klienta
18 .	Automatyczne zamknięcie zgłoszenia po akceptacji rozwiązania
19 .	Automatyczne wznowienie realizacji zgłoszenia po odrzuceniu rozwiązania
20 .	Podgląd historii realizacji zgłoszenia

21 .	Podgląd historii realizacji w porządku chronologicznym od momentu jego zarejestrowania wraz z całą korespondencją oraz informacjami, kto, kiedy i jaką czynność wykonał
22 .	Wydruk na żądanie danych zgłoszenia wraz z pełną historią jego obsługi
23 .	Dostęp do tablicy ogłoszeń na witrynie (dla wszystkich jej użytkowników), która zawiera:
24 .	Informacje ogólne o zmianach w systemie, informacje o nowych wersjach systemu, miejscach skąd można ją pobrać itp.
25 .	Załączniki mogące być częścią każdego ogłoszenia takie jak pliki parametryzujące, słowniki itp.
26 .	Powiadamianie uprawnionych użytkowników o nowych informacjach i komunikatach pojawiających się a witrynie.

Lp.	e-Learning
	Przez okres co najmniej 180 dni od rozpoczęcia wdrożenia, Wykonawca udostępni Zamawiającemu portal e-Learningu, zgodnie z poniższymi wymaganiami:
1	Szkolenia e-Learning muszą zostać dostarczone, dla co najmniej następujących obszarów:
2	- Rejestracja w Przychodni
3	- Gabinet Xxxxxxxx
4	- Pracownia Diagnostyczna
5	Lekcje muszą zawierać slajd wprowadzający („w tej lekcji nauczymy się …”) oraz podsumowujący slajd kończący („w tej lekcji nauczyliśmy się…”).
6	Lekcje składać się muszą z ekranów (nie będzie to film, aby nie obciążać sieci).
7	Lekcje powinny być czytane przez lektora (preferowany głos męski).
8	Lekcja będzie trwała 20 – 25 minut i będzie podzielona na etapy.
9	Każdy Etap będzie się składał z:
10	- części lekcyjnej ( animacji trwającej ok. 6-8 minut) podzielonej na kroki,
11	- w trakcie trwania animacji po kilku krokach będzie występowało ćwiczenie (około 2 ćwiczeń, gdzie ćwiczenie będzie miało około 5 poleceń).
12	Po przeprowadzonej lekcji nastąpi egzamin praktyczny – (będzie składał się on z zadań praktycznych do wykonania lub pytań testowych).
13	Lekcja powinna zatrzymywać się, wyróżniać i wyraźnie podkreślać ważne elementy.
14	W czasie trwania lekcji musi być możliwość cofania i zatrzymania lekcji, a w przypadku potrzeby przewinięcia do przodu, platforma powinna wymusić konieczność przynajmniej jednokrotnego przejścia przez całą lekcję – test z danej lekcji będzie udostępniany po zaliczeniu lekcji.
15	Po zdanym egzaminie użytkownik będzie miał możliwość dowolnego poruszania się po lekcji do czasu wygaśnięcia uprawnień na platformie.
16	Lekcje będą składane w pakiety dedykowane konkretnym rolom użytkowników np. pakiet dla personelu lekarskiego szpitala modułu x, pakiet dla personelu pielęgniarskiego szpitala modułu x (w przypadku modułu Izba przyjęć będzie to jeden pakiet).
17	Lekcje ogólne nt interfejsu i standardów aplikacji będą dołączane do różnych pakietów.
18	Ćwiczenia powinny mieć charakter dobrze zdefiniowanego zadania, przykładowo: „przyjmij pacjenta o danych NN na Izbę przyjęć …”. Niektóre kroki mogą być prawidłowo wykonane na kilka sposobów. Jeśli student wykona nieprawidłowy ruch, program podpowie prawidłowy po jednokrotnej nieudanej próbie. Student dostanie kompletne opisane zadanie do wykonania.
19	Tekst wypowiadany przez lektora powinien być również wyświetlony na ekranie na żądanie studenta.
20	Egzamin będzie posiadać wprowadzenie, w którym będą wyjaśnione zasady jego przeprowadzenia i oceny. Na końcu będzie podsumowanie wyników testu.
21	Student będzie mógł wykonać egzamin kilkukrotnie w celu uzyskania lepszego wyniku.

22	Egzamin po zakończeniu będzie pokazać błędne odpowiedzi i pozwalać na przeskok do danego fragmentu lekcji, w którym to zagadnienie było omawiane.
23	Lekcje, ćwiczenia, egzaminy, będą pokazywać, w którym momencie przerabianego materiału jest student i ile kroków zostało do końca (liczbowo np. krok 7 z 30).
24	W szkoleniu znajdzie się miejsce, slajd, screen - jeden poświęcony informacji gdzie jest środowisko testowe w szpitalu i jak się do niego zalogować.
25	Szkolenie umożliwi wywołanie konkretnej sekcji podręcznika elektronicznego dotyczącej omawianego materiału (podręcznik w formacie HTML).

J. Integracja ZSI z modułami pracującymi w szpitalu

Zamawiający wymaga integracji ZSI zamawianego w ramach przedmiotowego zamówienia z posiadanym oprogramowaniem opisanym w pkt. Stan obecny. Poniższe wymagania stanowią wymagania funkcjonalne nieopisane wyżej, dla systemu dostarczanego przez Wykonawcę w ramach przedmiotu zamówienia, w zakresie przepływu danych, wewnętrznej spójności systemu oraz wymagań integracyjnych pomiędzy poszczególnymi funkcjonalnościami systemu lub grupami tych funkcjonalności. Wymagania Zamawiającego w zakresie integracji (opis funkcjonalny integracji):

• W ramach niniejszego zamówienia wymagane jest zintegrowanie oprogramowania aplikacyjnego części administracyjnej i aplikacjami części medycznej w zakresie opisanym poniżej, bez konieczności ponoszenia dodatkowych kosztów integracji

Wymagany parametr graniczny

System będzie zintegrowany, przez co rozumie się zintegrowaną pracę wszystkich elementów (modułów) Systemu w oparciu o swobodną, automatyczną wymienialność wspólnych danych pomiędzy elementami (modułami) Systemu.

Z modułu Przychodnia ma być wgląd do informacji o pacjencie w module Ruch Chorych (integracja na poziomie bazy)

Wspólna baza ośrodków powstawania kosztów dla systemów administracyjnych, jakie obecnie posiada Zamawiający oraz systemów medycznych dostarczonych w ramach postępowania.

Z modułu Finansowo-Księgowego możliwość automatycznego przydzielania numeracji faktur sprzedażowych realizowanych w ramach modułów Przychodnia i Ruch chorych w tym rozliczenia NFZ.

Automatyczne przekazywanie informacji o fakturach sprzedażowych rozliczanych w ramach umów NFZ do systemu Finansowo-Księgowego posiadanego przez Zamawiającego

Z modułu Apteka/Apteczka oddziałowa, eksportowane są zadekretowane dokumenty przychodowe, rozchodowe oraz pozostałe do systemu Finanse-księgowość i Wyceny Kosztów Normatywnych (w celu analizy kosztów poprzez uzyskanie średnich cen dostaw dla materiałów).

Import danych z systemu Apteka jaki posiada Zamawiający do systemu Wycena kosztów normatywnych - w zakresie udostępnienia indeksu leków i danych o aktualnych cenach leków do określenia normatywów materiałowych świadczeń (w zakresie leków).

Możliwość zlecania z oddziału, izby przyjęć oraz gabinetu:

- podania leku/kroplówki/pompy infuzyjnej, zabiegu, badania diagnostycznego, konsultacji, diety. Wystawienie zlecenia powinno nieść kompletne informacje, niezbędne do jego wykonania i powinno automatycznie trafiać w miejsce wykonania danej procedury.

Wgląd w wyniki badań wykonanych na skutek realizacji zleceń. Treść i format wyniku powinien być zgodny z formatem w jakim wynik został opisany w jednostce realizującej badanie, np. w oparciu o specjalizowany formularz.

Pobieranie danych do list użytkowników/personelu medycznego z systemu Kadrowego wraz z informacją nt. danych osobowych, prawa wykonywania zawodu, stopnia naukowego, specjalizacji.

Import do systemu wyceny procedur indeksów materiałowych z cenami z systemu Apteka,

Eksport do systemu wyceny procedur indeksów materiałowych z cenami z systemu Gospodarki Materiałowej,

Eksport faktur rozliczeniowych do modułu FK.

• W ramach wdrożenia Wykonawca zintegruje posiadany przez Zamawiającego system RIS/PACS (System RIS: Chazon, system PACS: ExPACS, producenta Pixel Technology) z wdrażanym ZSI bez konieczności ponoszenia dodatkowych kosztów integracji.

Lp	Wymagany parametr graniczny
1.	Interfejs wymiany danych – w oparciu o protokół HL7 (w uzgodnionym z Zamawiającym zakresie dopuszczalny jest inny rodzaj transferu danych)
2.	Przekazywanie zleceń drogą elektroniczną wraz z danymi skierowania oraz danymi osobowymi pacjenta
3.	Wykonawca skonfiguruje automatyczne przesyłanie z systemu RIS do systemu HIS informacji o terminie umówienia badania.
4.	Wykonawca skonfiguruje automatyczne odsyłanie z systemu RIS do systemu HIS opisu badania zleconego elektronicznie.
5.	Możliwość anulowania/odrzucenia zlecenia wysłanego z systemu HIS po stronie RIS.
6.	Śledzenie statusu realizacji zlecenia po stronie HIS.
7.	Możliwość przesyłania linków do wyników badań w systemie RIS (dostęp on-line do wyników wykonanych w systemie RIS)
8.	Automatyczne uzupełnianie danych rozliczeniowych NFZ w systemie HIS po odesłaniu wyników badania z systemu RIS.
9.	Automatyczne rozsyłanie komunikatów o zmianie danych osobowych pacjenta w systemie HIS.
10.	Wykonawca skonfiguruje dostęp z systemu RIS do wszystkich badań gromadzonych w systemie HIS
11.	Wykonawca skonfiguruje dostęp z systemu RIS do pełnej historii leczenia pacjenta w systemie HIS
12.	Wykonawca skonfiguruje dostęp z systemu RIS do rejestru pacjentów w systemie HIS z celu umówienia na badanie.
13.	Możliwość dopisania pacjenta po stronie HIS podczas rejestracji pacjenta w systemie RIS
14.	Wykonawca skonfiguruje wgląd z systemu RIS do słowników systemów HIS jednostek zlecających, lekarzy kierujących systemu możliwością wprowadzenia, modyfikacji pozycji słownika.
15.	Możliwość zapisu informacji w systemie HIS o umówionym/wykonanym badaniu w systemie RIS
16.	Wykonawca skonfiguruje automatyczny zapis zleceń zewnętrznych wprowadzonych w systemie RIS do systemu HIS z możliwością ich późniejszego rozliczenia z NFZ.
17.	Wykonawca umożliwi przeglądanie dodatkowych danych personalnych i pobytu ewidencjonowanych w systemie HIS (w zakresie regulowanym uprawnieniami dostępu do danych) z poziomu systemu RIS.

K. Migracja danych do ZSI

W ramach wdrożenia przedmiotu zamówienia wymagane jest przejęcie (migracja) do ZSI wszelkich niezbędnych danych z obecnego systemu informatycznego.

Przeniesienie danych do ZSI z użytkowanych przez Zamawiającego baz i rejestrów prowadzonych w formie elektronicznej (stanowiące element prac wdrożeniowych):

• Dane muszą być spójne z nowo wprowadzanymi, edytowalne, podlegające analizie i spełniające warunki walidacji dla określonych typów pól.

• Migracja danych do nowego systemu informatycznego powinna obejmować wszystkie dane i kompletne bazy z obecnie istniejącego i działającego systemu niezbędne do podjęcia i kontynuowania pracy w dostarczonym systemie.

Zamawiający nie dysponuje dokumentacją techniczną posiadanego systemu, a w szczególności informacjami określającymi stosowane w tym oprogramowaniu sposoby przechowywania i dostępu do informacji. Zamawiający nie dysponuje również kodami źródłowymi oprogramowania.

Uwzględniając powyższe, Wykonawca w ramach przedmiotu zamówienia zobowiązany będzie dokonać czynności zmierzających do analizy opisywanego wyżej oprogramowania w celu ustalenia i zidentyfikowania stosowanych w tym oprogramowaniu zasad składowania danych, relacji i powiązań danych. Wykonawca dokona analizy funkcjonowania miejsca ich składowania w bazie danych (tabele, widoki, poszczególne pola w tablicach etc.).

Czynności te mogą również obejmować badanie zawartych w oprogramowaniu algorytmów, jeżeli będzie to niezbędne dla właściwej interpretacji tych danych.

Do dokonania każdej z powyższych czynności z osobna lub wszystkich lub części czynności wyżej określonych Wykonawca uprawniony jest wyłącznie w zakresie, w jakim będą one niezbędne do osiągnięcia współdziałania oprogramowania dostarczanego w ramach niniejszego zamówienia z oprogramowaniem.

Dla przeprowadzenia przedmiotowej analizy, Zamawiający przewiduje konieczność dokonania przez Wykonawcę czynności zwielokrotnienia kodu lub tłumaczenia jego formy w rozumieniu art. 74 ust.

4 pkt. 1 i 2 ustawy Prawo autorskie i prawa pokrewne w zakresie, jaki niezbędny będzie do uzyskania informacji koniecznych do osiągnięcia współdziałania dostarczanego w ramach zamówienia oprogramowania z oprogramowaniem. Dobór środków w zakresie tłumaczenia formy oprogramowania (np. dekompilacja oprogramowania) zapewniających osiągnięcie celu przedmiotowej analizy leży po stronie Wykonawcy. Czynności tłumaczenia formy oprogramowania Wykonawca zobowiązany jest wykonać na własny koszt i ryzyko, w pełnym koniecznym zakresie z zastrzeżeniem, że:

1. czynności te będą odnosiły się tylko do tych części oprogramowania, które będą niezbędne do dokonania migracji danych do systemu dostarczanego przez Wykonawcę w ramach przedmiotowego zamówienia,

2. informacje uzyskane w ramach tych czynności nie będą:

• wykorzystane do innych celów niż do dokonania migracji danych z oprogramowania do oprogramowania dostarczanego przez Wykonawcę,

• przekazane innym osobom, chyba że jest to niezbędne do dokonania migracji danych,

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

Informacje uzyskane przez Wykonawcę w toku wykonywania powyższych czynności stanowią tajemnicę przedsiębiorstwa rozumieniu przepisów ustawy o zwalczaniu nieuczciwej konkurencji.

Zamawiający będzie współpracował z Wykonawcą w zakresie przygotowania powyższej analizy poprzez:

🗁📬 Udostępnienie Wykonawcy ostatniej posiadanej przez Zamawiającego wersji kodu wynikowego oprogramowania oraz udostępnienie współpracujących z tym oprogramowaniem baz danych, z zachowaniem przepisów ustawy o ochronie baz danych oraz ustawy o ochronie danych osobowych.

🗎📬 Zapewni stosowne upoważnienie, pełnomocnictwo etc. umożliwiające Wykonawcy działanie na rzecz licencjobiorcy oprogramowania w rozumieniu art. 75 ust. 2 (Dz.U. Nr 24, poz. 83; tj. z dnia 17 maja 2006 r. (Dz.U. Nr 90, poz. 631).

Wyniki przedmiotowej analizy stanowią podstawę do dokonania migracji danych do dostarczanego przez Wykonawcę w ramach zamówienia systemu z systemu funkcjonującego obecnie u

Zamawiającego.

Charakterystyka danych podlegających migracji do ZSI:

1. Nazwa i wersja oprogramowania będącego przedmiotem migracji danych w ramach realizacji przedmiotu zamówienia: (tabela pkt D. )

2. Baza danych systemu (tabela pkt D. )

a) Wielkość bazy: ok. 40 GB

b) Rodzaj bazy: Oracle Standard Edition One 11g

L. Wymagania dotyczące wdrożenia

W ramach usług wdrożeniowych wchodzić będzie w szczególności:

• Przeprowadzenie próbnej migracji danych w ZSI w zakresie danych medycznych i rozliczeniowych,

• Wykonanie instalacji wszystkich wdrażanych systemów,

• Konfiguracja oraz parametryzacja oprogramowania,

• Ewentualna instalacja baz danych i przeniesienie danych z baz danych aktualnie eksploatowanych systemów przeznaczonych do zastąpienia po pomyślnym przeprowadzeniu próbnej migracji danych według określonego dla niej zakresu,

• Harmonizacja (ujednolicenie formatów) i normalizacja (ujednolicenie zakresów

i uzupełnienie wartości) danych przeniesionych z aktualnie eksploatowanych systemów do wymagań integralnościowych baz danych wdrożonych systemów,

• Zamawiający oczekuje dostarczenia oprogramowania kompletnego, tj. zawierającego wszystkie składniki wymagane do jego zainstalowania, wdrożenia i eksploatacji

– w tym systemy operacyjne serwerów.

• Zamawiający zapewnia współpracę przy uzyskaniu przez Wykonawcę opisów interfejsów do integracji z wymienionymi w SIWZ systemami, natomiast wykonanie integracji jest obowiązkiem Wykonawcy. Ustalenie kosztów integracji z systemami posiadanymi przez Zamawiającego jest obowiązkiem Wykonawcy.

• 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ę na dostawę i wdrożenie ZSI.

• Oferowane oprogramowanie HIS musi posiadać zaimplementowany protokół HL7 i XML.

• Wykonawca przed zawarciem umowy dostarczy wykaz dokumentów, których oczekuje od Zamawiającego do przeprowadzenia wdrożenia.

• Wykonawca przeniesie dane z posiadanych przez Zamawiającego baz danych na własny koszt.

• Zamawiający wymaga, by Wykonawca zharmonizował (ujednolicenie formatów) i znormalizował (ujednolicenie zakresów i uzupełnienie wartości) znajdujące się w systemie słowniki, np.: jednostek kierujących, personelu zlecającego, miejscowości

z kodami pocztowymi. Przez harmonizację i normalizację słowników rozumie odpowiednio: scalenie słowników przechowujących te same dane

z usunięciem danych powielonych i ujednoliceniem gromadzonych wartości/znaczenia danych już znajdujących się w tych słownikach, - ujednolicenie struktur tych słowników. Uzupełnienie danych w słownikach nie jest obowiązkiem Wykonawcy.

• Zamawiający zapewnienia dostęp do danych przeznaczonych do migracji. Zamawiający zapewnia współpracę przy uzyskaniu opisu struktur i formatów,

w jakich te dane są przechowywane.

• Zamawiający wymaga, aby moduły oprogramowania, wdrożone przez Wykonawcę w ramach realizacji przedmiotu zamówienia, były wdrożone w pełnej ich funkcjonalności.

• Wdrażanie dostarczanego oprogramowania musi uwzględniać ciągłość pracy w szpitalu. Wszelkie przerwy w działaniu systemu wynikające z prowadzonych prac wdrożeniowych muszą zostać uzgodnione z producentem systemu HIS

i zatwierdzone przez Xxxxxxxxxxxxx.

• Instalacja i wdrożenie winny odbywać się w godzinach pracy pracowników Zamawiającego

tj. w dni robocze (od poniedziałku do piątku), w godz. 730 – 1430.Zamawiający dopuszcza wykonywanie prac w innym czasie niż wskazany, po odpowiednim uzgodnieniu i jego akceptacji.

• Po dokonaniu instalacji i wdrożenia docelowo system powinien:

o spełniać wymagania określone niniejszą SIWZ,

o uwzględniać charakter prowadzonej przez Zamawiającego działalności oraz spełniać wymagania obowiązujących przepisów prawa, w szczególności ustaw i rozporządzeń dotyczących:

▪ Podmiotów objętych ustawą o działalności leczniczej,

▪ Rozliczeń i sprawozdawczości do NFZ,

▪ Rodzaju i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania,

▪ Ochrony danych osobowych,

▪ Informatyzacji podmiotów realizujących zadania publiczne,

▪ Systemu informacji w ochronie zdrowia.

• Zamawiający wymaga, by docelowo wdrożone moduły spełniały następujące warunki:

o zachowanie ciągłości obecnie stosowanych przez Zamawiającego oznaczeń dokumentacji medycznej,

o umożliwienie kontynuacji sprawozdawania i rozliczania świadczeń udzielonych pacjentom przebywającym w Szpitalu od kilkunastu lat (możliwość przesłania do NFZ pełnej historii hospitalizacji/wizyt oraz historii rozliczeń), przy wykorzystaniu jednego modułu/oprogramowania,

o umożliwienie dokonywania korekt zakwestionowanych przez NFZ świadczeń sprawozdanych i rozliczonych co najmniej od roku 2008,

o zachowanie przekazanej do NFZ historycznej numeracji zestawów świadczeń, świadczeń i procedur rozliczeniowych oraz zachowanie historycznej numeracji wszystkich innych danych przekazanych do NFZ i potwierdzonych przez niego takich jak id uprawnień, numeracja sesji, numer przepustki, itp.,

o zapewnienie możliwości wykonywania archiwalnych statystyk i raportów,

o zapewnienie możliwości wykonywania kopii zapasowych struktur danych w trakcie ich pracy,

o posiadanie sprawnego mechanizmu archiwizacji danych i mechanizmów gwarantujących spójność danych. Wymagane jest wzajemne współdziałanie modułów systemu medycznego i administracyjnego poprzez powiązania logiczne i korzystanie ze wspólnych danych przechowywanych na serwerach,

o zapewnienie współpracy w zakresie eksportu danych z innym oprogramowaniem - pakietem oprogramowania biurowego (arkusz kalkulacyjny, edytor tekstów),

o komunikaty systemowe i komunikacja z użytkownikiem w języku polskim,

o możliwość korzystania z rozbudowanych podpowiedzi.

Wymagania w zakresie instruktaży:

1. Instruktaż obejmować będzie:

• administrowanie bazami danych wdrożonych systemów informatycznych,

• administrowanie oprogramowaniem,

• eksploatację oprogramowania.

2. W ramach instruktażu (podczas wdrożenia) Wykonawca przekaże użytkownikom pełną wiedzę niezbędną do poprawnego użytkowania modułów, potrzebną do wykonywania obowiązków służbowych na zajmowanym stanowisku pracy.

3. Zamawiający, w ramach instruktażu, przewiduje szkolenia grupowe oraz indywidualne. Liczbę osób przewidzianych do instruktażu Zamawiający określa na 100 osób. Instruktaż stanowiskowy (indywidualny) obejmie swoim zakresem personel rejestracji, poradni specjalistycznych, bloku operacyjnego, rozliczeń oraz POZ w ilości 100 osób.

4. Instruktaż Administratorów systemów (2 osoby) należy wykonać w pełnym zakresie administrowania oprogramowaniem.

5. Wykonawca dokona instruktażu wszystkich administratorów Zamawiającego przed rozpoczęciem instruktażu użytkowników.

6. Instruktaże nie mogą odbywać się w grupach większych niż 10 osób.

7. Przed przystąpieniem do instruktażu Wykonawca uruchomi testowe bazy danych, tak by umożliwić użytkownikom testowanie funkcjonalności dostarczanego Oprogramowania.

8. Instruktaże grupowe winny się odbywać w podziale na grupy zawodowe, a tym samym w podziale na poszczególną funkcjonalność modułów.

9. Czas instruktażu z danego modułu systemu dla danej grupy zawodowej powinien uwzględniać stopień skomplikowania modułu lecz nie krócej niż 60 minut.

10. Dla przeprowadzenia instruktaży grupowych Zamawiający nieodpłatnie zapewni Wykonawcy

10 stanowisk roboczych (pochodzących z zamówienia w ramach niniejszego projektu) i odpowiednie pomieszczenie. Odpowiedzialność za przygotowanie stanowisk do przeprowadzenia instruktaży leży po stronie Wykonawcy.

11. Wykonawca dostarczy harmonogram instruktaży do akceptacji Zamawiającego.

Ł. Obsługa serwisowa wraz Nadzorem autorskim oraz Asystą techniczną

W ramach realizacji przedmiotu umowy Wykonawca zobowiązany jest do świadczenia usług obsługi serwisowej wraz z nadzorem autorskim oraz asystą techniczną przez okres 12 miesięcy od daty odbioru końcowego. W ramach usług obsługi serwisowej wraz z nadzorem autorskim oraz asystą techniczną Wykonawca jest zobowiązany zapewnić:

1. udostępnienie poprawek do Zintegrowanego Systemu Informatycznego, w przypadku stwierdzenia przez Zamawiającego błędu Zintegrowanego Systemu Informatycznego (tzn. nie spowodowanego przez Zamawiającego powtarzalnego działania Zintegrowanego Systemu Informatycznego, w tym samym miejscu programu, prowadzącego w każdym przypadku do otrzymania błędnych wyników jego działania):

a. w przypadku tzw. błędu krytycznego, tj. takiego, który uniemożliwia użytkowanie Zintegrowanego Systemu Informatycznego (w zakresie jego podstawowej funkcjonalności wskazanej 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 Zintegrowanego Systemu Informatycznego:

- czas reakcji Wykonawcy na zgłoszenie Zamawiającego (tj. czas od otrzymania zgłoszenia do chwili podjęcia przez Wykonawcę czynności zmierzających do naprawy zgłoszonego

„błędu krytycznego”) wynosi [zgodnie z ofertą Wykonawcy] dni roboczych;

- czas dokonania i udostępnienia Zamawiającemu odpowiednich korekt Zintegrowanego Systemu Informatycznego wyniesie do [zgodnie z ofertą Wykonawcy] dni roboczych od chwili rozpoczęcia czynności serwisowych;

- 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;

b. w pozostałych przypadkach:

- czas reakcji Wykonawcy na zgłoszenie Zamawiającego (tj. czas od otrzymania zgłoszenia do chwili podjęcia przez Wykonawcę czynności zmierzających do naprawy zgłoszonego błędu zwykłego) wynosi do [zgodnie z ofertą Wykonawcy] dni roboczych;

- czas dokonania i udostępnienia Zamawiającemu odpowiednich korekt Zintegrowanego Systemu Informatycznego wyniesie do [zgodnie z ofertą Wykonawcy] dni roboczych od chwili rozpoczęcia czynności serwisowych;

c. ewentualne przekwalifikowanie błędu zgłoszonego przez Zamawiającego jako zwykły, na "błąd krytyczny", wymagać będzie osobnego zgłoszenia i oznaczać będzie uruchomienie procedury opisanej w lit. a) powyżej.

d. zgłoszenie błędu przez Zamawiającego odbywać się będzie poprzez serwisową witrynę internetową (w skrócie SWI) Wykonawcy w razie trudności z rejestracją zgłoszenia na w/w witrynie internetowej, Zamawiający może dokonać zgłoszenia

telefonicznie pod wskazany przez Wykonawcę numer telefonu lub za pomocą poczty elektronicznej na wskazany adres e-mail.

2. wprowadzanie zmian w Zintegrowanym Systemie Informatycznym objętym Umową, w zakresie wymaganym zmianami powszechnie obowiązujących przepisów prawa lub przepisów prawa wewnętrznie obowiązujących, wydanych na podstawie delegacji ustawowej, z zastrzeżeniem, że Wykonawca zobowiązany jest do:

a. przekazania Zamawiającemu informacji o nowych wersjach Zintegrowanego Systemu Informatycznego,

b. udostępniania uaktualnień Zintegrowanego Systemu Informatycznego (nowych wersji Zintegrowanego Systemu Informatycznego).

c. możliwość zgłoszenia uwag i propozycji modyfikacji Zintegrowanego Systemu Informatycznego, zgłoszenia takie wynikają z zobowiązania Wykonawcy do dokonywania rozwoju Oprogramowania Aplikacyjnego, o którym mowa w punkcie poprzedzającym;

3. zapewnienie w ramach serwisu oprogramowania oraz Asysty technicznej:

a. zainstalowania i wdrożenia wersji Zintegrowanego Systemu Informatycznego otrzymanych w ramach świadczeń z tytułu nadzoru autorskiego;

b. podjęcia starań w celu usunięcia awarii Zintegrowanego Systemu Informatycznego powstałej z winy Zamawiającego lub wskutek wypadków losowych;

c. bieżącego optymalizowania konfiguracji Zintegrowanego Systemu Informatycznego, uwzględniającego potrzeby Zamawiającego;

d. pomocy w awaryjnym odtwarzaniu, na wniosek Zamawiającego, stanu Zintegrowanego Systemu Informatycznego i zgromadzonych danych archiwalnych, poprawnie zabezpieczonych przez Zamawiającego na odpowiednich nośnikach danych;

e. pomocy w przygotowaniu danych przekazywanych przez Zamawiającego do jednostek nadrzędnych i współpracujących (np. do Narodowego Funduszu Zdrowia, Wydziału Zdrowia odpowiedniego Urzędu, banków itp.) w formie elektronicznej (np. dyskietki, łącza telekomunikacyjne itp.);

f. doradztwa w zakresie rozbudowy środków informatycznych, dokonywanie ponownych instalacji Zintegrowanego Systemu Informatycznego objętego Umową w przypadkach rozbudowy infrastruktury informatycznej Zamawiającego;

g. korzystania z konsultacji telefonicznych;

h. prowadzenia rejestru kontaktów z Zamawiającym, obejmującego wizyty serwisowe i wykonane czynności, w tym zmiany konfiguracji oprogramowania.

4. Usługi serwisu oraz Asysty technicznej, określone w pkt. 3), świadczone będą przez Wykonawcę w dni robocze tj. dni od poniedziałku do piątku z wyłączeniem dni ustawowo wolnych od pracy, w godzinach od 8.00 do 16.00 bez jakiegokolwiek limitu godzinowego.

W zakresie świadczenia usług, o których mowa powyżej, Zamawiający zapewnia:

1. Osobę odpowiedzialną za realizację całości Umowy serwisowej, oraz powiadomienia Wykonawcy o każdej zmianie tej osoby (w formie pisemnej lub elektronicznej);

2. wykonywania niezwłocznie 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;

3. powstrzymania się od samodzielnego lub przy udziale osób trzecich dokonywania jakichkolwiek zmian w konfiguracji oprogramowania (zgodnie z art. 74 ust. 4 pkt 2 ustawy o prawie autorskim i prawach pokrewnych) lub sprzętu komputerowego, na którym wykorzystywany jest Zintegrowany System Informatyczny objęty Serwisem, w tym Zamawiający zobowiązuje się nie dokonywać nieautoryzowanych przez Wykonawcę modyfikacji zawartości baz danych Zintegrowanego Systemu Informatycznego – w przypadku zaistnienia takiej potrzeby, prace te zostaną uzgodnione z Wykonawcą, a wszelkiego rodzaju zmiany będą wykonywane za uprzednią wyraźną zgodą Wykonawcy.

4. prowadzenia rejestru kontaktów z Wykonawcą, obejmującego w szczególności rozmowy

telefoniczne, wysyłane faksy i pisma, zmiany konfiguracji Oprogramowania Aplikacyjnego oraz wykonane czynności;

5. dostarczenia na wniosek Wykonawcy, wskazanych fragmentów lub całości baz danych Zintegrowanego Systemu Informatycznego, w przypadku uzasadnionej potrzeby ich użycia do prawidłowej realizacji Serwisu poza siedzibą Zamawiającego przy zachowaniu procedury uzgodnionej z Wykonawcą.

6. delegowania i upoważnienia pracowników do współpracy z Wykonawcą w zakresie potrzebnym do świadczenia usług Serwisowych;

7. dokonywania zgłoszeń ewentualnych błędów oraz dostarczania Wykonawcy rzetelnych i wyczerpujących informacji o stanie Zintegrowanego Systemu Informatycznego i o zamiarach wprowadzenia zmian w działalności Zamawiającego (z odpowiednim wyprzedzeniem) oraz materiałów potrzebnych do wykonania usług Serwisowych;

8. przekazywania na bieżąco Wykonawcy wszystkich przepisów i regulaminów obowiązujących u Zamawiającego, które mogą mieć zastosowanie w realizacji Serwisu, 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);

9. zapewnienia Wykonawcy możliwości stałego dostępu do Zintegrowanego Systemu Informatycznego objętego zakresem Serwisu, w tym pracy w godzinach popołudniowych i wieczornych, a także zapewnienia obecności w tym czasie, upoważnionego przedstawiciela Zamawiającego;

10. udostępnienia Wykonawcy sprzętu komputerowego i Zintegrowanego Systemu Informatycznego Zamawiającego lub oprogramowania osób trzecich w zakresie potrzebnym do świadczenia opisanych usług;

11. zapewnienia zdalnego dostępu do Zintegrowanego Systemu Informatycznego objętego opisanymi usługami, o ile to będzie konieczne.

Wykonawca ma obowiązek zapoznawania się z obowiązującymi przepisami prawa oraz wskazówkami NFZ i innymi dostępnymi powszechnie np. na odpowiednich stronach www.