Podpis osoby uprawnionej do złożenia oferty

Transkrypt

1 AE/ZP-27-93/14 Załącznik nr Z1 W Pakiecie numer 1 przedmiot zamówienia obejmuje aktualizację Szpitalnego Systemu Informatycznego HIS InfoMedica posiadanego przez Specjalistyczny Szpital im. Edwarda Szczeklika w Tarnowie. Przez aktualizację Zamawiający rozumie dostarczenie oraz wdrożenie najnowszej wersji Szpitalnego Systemu Informatycznego HIS InfoMedica działającego w Szpitalu im. E. Szczeklika w zakresie obejmującym funkcjonalności: izb przyjęć, oddziałów szpitalnych, statystyki medycznej, rozliczeń z Narodowym Funduszem Zdrowia, gospodarki lekami na oddziałach i izbach, zleceń medycznych. Pozostała część Szpitalnego Systemu Informatycznego w Specjalistycznym Szpitalu im. Edwarda Szczeklika w Tarnowie musi funkcjonować bez zakłóceń w dotychczasowej wersji, tzn. w pełni współpracować i na bieżąco wymieniać dwustronnie dane ze zaktualizowaną częścią Szpitalnego Systemu HIS InfoMedica. W ramach niniejszego zamówienia Wykonawca skonfiguruje nowe wersje oprogramowania do poprawnej pracy w warunkach pracy użytkowników aktualnej wersji oprogramowania wraz z udostępnieniem poprawnie działających elektronicznych wersji dokumentów medycznych użytkowanych w Specjalistycznym Szpitalu im. Edwarda Szczeklika w Tarnowie. Nowa wersja oprogramowania nie może być gorsza funkcjonalnie niż obecnie używane oprogramowanie. Zamawiający wymaga również przeszkolenia personelu medycznego, a także administratorów Systemu w zakresie korzystania z najnowszej wersji oprogramowania. Wszystkie dane zgromadzone w aktualnej wersji Szpitalnego Systemu Informatycznego HIS InfoMedica, od początku funkcjonowania oprogramowania (tj od 2001r), w zakresie podlegającym aktualizacji, muszą być w pełni dostępne w zaktualizowanej wersji Systemu. W ramach niniejszego zadania Wykonawca: a. dostarczy odpowiednie licencje oprogramowania aplikacyjnego, spełniającego wymagania funkcjonalne wskazane poniżej, w wersji bez jakiegokolwiek limitu (ilości pracujących użytkowników, ilości połączeń, ilości zajmowanego miejsca, itp.), stanowiące aktualizację wykorzystywanego przez Zamawiającego Szpitalnego Systemu Informatycznego HIS do tzw. wersji przeglądarkowej, umożliwiającej również pracę na urządzeniach mobilnych typu tablet, w zakresie posiadanych już przez Specjalistyczny Szpital im. E. Szczeklika w Tarnowie licencji otwartych, tj. bez limitu nazwanych użytkowników, liczby stacji roboczych czy użytkowników jednocześnie pracujących, b. zainstaluje oraz skonfiguruje do poprawnej pracy oprogramowanie aplikacyjne, c. przeszkoli personel medyczny Zamawiającego w ilości 39 osób, d. przeszkoli administratorów IT Zamawiającego w zakresie zarządzania oraz administrowania dostarczonym rozwiązaniem (np bieżące atualizacje, instalacja systemu itp) - 4 osoby. W ramach szkolenia użytkowników przekazana musi zostać wiedza niezbędna do poprawnego użytkowania dostarczonego rozwiązania, zgodnie z jego zakresem funkcjonalnym, tworzeniem i gromadzeniem danych związanych z wykonywaniem czynności służbowych, tworzeniem i gromadzeniem dokumentów, wykonywaniem analiz i sprawozdań, współpracy pomiędzy poszczególnymi jednostkami organizacyjnymi Zamawiającego.

2 Łączny czas szkoleń użytkowników w zakresie aktualizacji nie może być krótszy niż 30 godzin. Oprogramowanie objęte niniejszym zamówieniem musi posiadać gwarancyjny nadzór autorski jego producenta przez 12 miesięcy od daty zakończenia prac aktualizacyjnych oraz wdrożeniowych. Zamawiający przez gwarancyjny nadzór autorski rozumie zobowiązanie Wykonawcy do: I. udostępnienia poprawek do Oprogramowania Aplikacyjnego, w przypadku stwierdzenia przez Zamawiającego błędu Oprogramowania Aplikacyjnego (tzn. nie spowodowanego przez Zamawiającego powtarzalnego działania Oprogramowania Aplikacyjnego, 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 Oprogramowania Aplikacyjnego (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 Oprogramowania Aplikacyjnego: 1. 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 1 dzień roboczy; 2. czas dokonania i udostępnienia Zamawiającemu odpowiednich korekt Oprogramowania Aplikacyjnego wyniesie do 3 dni roboczych od chwili rozpoczęcia czynności serwisowych; 3. w przypadku wystąpienia błędu krytycznego Wykonawca może wprowadzić tzw. rozwiązanie tymczasowe, doraźnie rozwiązujące problem błędu krytycznego. W takim przypadku dalsza obsługa usunięcia dotychczasowego błędu krytycznego może być traktowana jako błąd zwykły; b) w pozostałych przypadkach: 1. 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 15 dni roboczych; 2. czas dokonania i udostępnienia Zamawiającemu odpowiednich korekt Oprogramowania Aplikacyjnego wyniesie do 60 dni roboczych od chwili rozpoczęcia czynności serwisowych; c) w wyjątkowych wypadkach, za zgodą Zamawiającego, czas dokonania korekt będzie uzgodniony pomiędzy Wykonawcą i Zamawiającym; d) zgłoszenie błędu przez Zamawiającego odbywać się będzie poprzez witrynę internetową Help-Desku Wykonawcy; w razie trudności z rejestracją zgłoszenia na w/w witrynie internetowej, Zamawiający może dokonać zgłoszenia telefonicznie - wymagane minimum dwa numery telefonu lub pisemnie na formularzu przesyłanym za pomocą poczty elektronicznej na podany adres , wymagany wzór formularza dostarczy Wykonawca. 1. w przypadku, gdy formularz zgłoszenia błędu zostanie przyjęty przez Wykonawcę:

3 1.1. w godzinach pomiędzy a dnia roboczego traktowany jest jak przyjęty o godz następnego dnia roboczego; 1.2. w godzinach pomiędzy 0.00 a 8.00 dnia roboczego - traktowany jest jak przyjęty o godz danego dnia roboczego; 1.3. w dniu ustawowo lub dodatkowo wolnym od pracy - traktowany jest jak przyjęty o godz najbliższego dnia roboczego; II. rozwój Oprogramowania Aplikacyjnego objętego Umową zgodnie ze zmieniającymi się powszechnie obowiązującymi przepisami prawa lub przepisami prawa wewnętrznie obowiązującymi wydanymi na podstawie delegacji ustawowej, z zastrzeżeniem, że Wykonawca zobowiązany jest do: a) przekazania Zamawiającemu informacji o nowych wersjach Oprogramowania Aplikacyjnego, poprzez wysłanie wiadomości pocztą elektroniczną na adres Zamawiającego b) udostępniania uaktualnień Oprogramowania Aplikacyjnego (nowych wersji Oprogramowania Aplikacyjnego) poprzez serwer ftp, przy czym na pisemne życzenie Zamawiającego, Wykonawca zobowiązuje się przygotować i wysłać na adres Zamawiającego nośnik CD-ROM zawierający nową wersję Oprogramowania Aplikacyjnego. III. możliwość pisemnego zgłoszenia uwag i propozycji modyfikacji Oprogramowania Aplikacyjnego. Zgłoszenia takie wynikają z zobowiązania Wykonawcy do dokonywania rozwoju Oprogramowania Aplikacyjnego, o którym mowa w punkcie poprzedzającym, które będą rozpatrywane w czasie prac analitycznych przy rozwoju Oprogramowania Aplikacyjnego. 1. Aktualizacja Szpitalnego Systemu Informatycznego 1.1. Wymagania ogólne dla aktualizowanych modułów oprogramowania aplikacyjnego Ilekroć w dokumencie wykorzystano skrót SzSI oznacza to Szpitalny System Informatyczny. Lp. Wymagania ogólne Parametry Wymagane 1. Wykonawca dostawca/producent Szpitalnego Systemu Informatycznego HIS, zobowiązany jest do przekazania Zamawiającemu wszystkich loginów i haseł Administratora bazy danych, związanych z zarządzaniem bazą danych i danymi SzSI HIS, umożliwiających Zamawiającemu, pełną kontrolę i możliwość pełnego zarządzania bazą danych oraz wszystkimi danymi gromadzonymi w SzSI HIS Specjalistycznego Szpitala im. E. Szczeklika w Tarnowie. 2. System musi posiadać interfejs graficzny dla wszystkich modułów System musi pracować w środowisku graficznym MS Windows na stanowiskach użytkowników (preferowane środowisko MS Windows XP/Vista/7). Wszystkie moduły Zintegrowanego Szpitalnego Systemu Informacyjnego Specjalistycznego Szpitala im. E. Szczeklika w Tarnowie muszą działać w oparciu o jeden motor bazy danych. Szpital posiada silnik bazy danych Oracle w wersji 12c.

4 System, co najmniej w zakresie aplikacji Ruch Chorych, Apteka Szpitalna, Apteczki Oddziałowe, Rozliczenia z NFZ, Przychodnia, Pracownie Diagnostyczne, Blok Operacyjny musi 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. System musi komunikować się z użytkownikiem w języku polskim. Musi być wyposażony w system podpowiedzi (help). W przypadku oprogramowania narzędziowego i administracyjnego serwera bazy danych - częściowa komunikacja może odbywać się w języku angielskim. W funkcjach związanych z wprowadzaniem danych system musi udostępniać podpowiedzi, automatyczne wypełnianie pól, słowniki grup danych (katalogi leków, procedur medycznych, danych osobowych, terytorialnych itp). System musi 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 musi być wyposażony w zabezpieczenia przed nieautoryzowanym dostępem. Zabezpieczenia muszą funkcjonować na poziomie klienta (aplikacja) i serwera (serwer baz danych). System musi być wykonany w technologii klient-serwer, dane przechowywane w modelu relacyjnym baz danych z wykorzystaniem aktywnego serwera baz danych. Musi istnieć możliwość nadania użytkownikowi uprawnień do pracy wyłącznie w kontekście wybranych jednostek organizacyjnych np. tylko oddział wewnętrzny i /lub izba przyjęć. System musi umożliwić zmianę jednostki organizacyjnej, na której pracuje użytkownik bez konieczności wylogowywania się z systemu. 12. System zarządzania użytkownikami musi być wspólny dla wszystkich modułów System musi być wyposażony w zabezpieczenia przed nieautoryzowanym dostępem. Zabezpieczenia muszą funkcjonować na poziomie klienta (aplikacja) i serwera (serwer baz danych), System musi posiadać mechanizmy umożliwiające zapis i przeglądanie danych o logowaniu użytkowników do systemu. System musi umożliwiać podgląd listy aktualnie zalogowanych do systemu użytkowników. System musi tworzyć i utrzymywać log systemu, rejestrujący wszystkich użytkowników systemu i wykonane przez nich czynności (takie jak dopisywanie, zmiany, usuwanie) z możliwością analizy historii zmienianych wartości danych. Administrator musi posiadać możliwość, z poziomu aplikacji z modułu Administrator, 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. 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. W przypadku przechowywania haseł w bazie danych, hasła muszą być zapamiętane w postaci niejawnej (zaszyfrowanej). 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. 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.

5 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. 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. System musi 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. System musi umożliwić skanowanie danych z dokumentów np. dowodów osobistych i na tej podstawie dokonywanie automatycznej identyfikacji pacjenta. System powinien umożliwić obsługę procesów biznesowych realizowanych w szpitalu oraz podpowiadać kolejne kroki procesu. System powinien automatycznie wylogowywać lub blokować sesję użytkownika po zadanym czasie braku aktywności. Użytkownik po zalogowaniu powinien widzieć pulpit zawierający wszystkie funkcje i moduły dostępne dla tego użytkownika. W systemie musi zostać zachowana zasada jednokrotnego wprowadzania danych. Wymiana danych pomiędzy modułami musi odbywać się na poziomie bazy danych. Dostarczone oprogramowanie musi zagwarantować pełną integrację z funkcjonującym w Specjalistycznym Szpitalu im. E. Szczeklika w Tarnowie, systemem części administracyjnej (tzw. szarej) oraz oprogramowniem pracowni diagnostycznych CRID EsaProjekt wraz z systemem ArPacs Synektik. (w części administracyjnej Szpital posiada moduły: Kadry, Płace, Kadry/Płace - Wykazy/Pisma, Kadry - Eksport ZUS, Kadry - Eksport FKK, Kadry Grafik, Kadry/Płace Słowniki, Pożyczki, Finanse i Księgowość, Koszty, Finanse i Księgowość - Import-Eksport, Rejestr Sprzedaży, Rejestr VAT, Rejestr Bankowy, Kasa, Wycena Kosztów Normatywnych, Gospodarka Materiałowa, Środki Trwałe z Elektroniczną Inwentaryzacją, Wyposażenie z Elektroniczną Inwentaryzacją,Zintegrowane Słowniki). Przekazywanie danych musi odbywać się automatycznie i na bieżąco, bez konieczności wykonywania dodatkowych operacji przez użytkownika lub administratora. System musi umożliwić przypisanie do komórki organizacyjnej jednostki, kodu technicznego NFZ. Musi istnieć możliwość zmiany tego kodu w czasie pracy Systemu. Wykonawca oświadcza, że spełnia wszystkie wymagania wymienione w Tabeli 1.1 w pkt.1-30

6 1.2. Szczegółowe wymagania funkcjonalne Systemu HIS w zakresie aktualizacji Szpitalnego Systemu Informatycznego HIS do tzw. wersji przeglądarkowej: Izba Przyjęć Lp. Wymaganie (Izba Przyjęć) Parametry Wymagane 1. Moduł musi działać w architekturze trójwarstwowej Interfejs użytkownika modułu musi być dostępny z poziomu przeglądarki internetowej i nie może wymagać instalowania żadnego dodatkowego oprogramowania na stacjach klienckich (system nie może wymagać korzystania ze specjalnych programów klienckich technologii typu Citrix, VNC, innych, w celu realizacji wymagań funkcjonalnych). Moduł musi umożliwiać pracę z poziomu najbardziej popularnych przeglądarek, co najmniej Microsoft Internet Explorer, Google Chrome, Mozilla Firefox. Moduł musi umożliwiać pracę na tabletach medycznych lub komputerach wyposażonych w monitory dotykowe oraz zwykłych stacjonarnych komputerach. Pełna funkcjonalność modułu musi być dostępna na wszystkich w/w urządzeniach. Moduł musi umożliwić skanowanie danych z dokumentów tożsamości - dowodów osobistych lub prawo jazdy i na tej podstawie dokonywanie automatycznej identyfikacji pacjenta. Moduł musi umożliwiać obsługę kodów 2D do rejestracji skierowań pochodzących z innych zakładów opieki. Moduł musi 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. Wszystkie błędy niewypełnienia pól obligatoryjnych oraz błędnego wypełnienia muszą być prezentowane w jednym komunikacie, z możliwością szybkiego przejścia do tego miejsca aplikacji (np. poprzez odpowiedni link), gdzie te błędy wystąpiły. 9. Wyróżnienie pól: których wypełnienie jest wymagane, - przeznaczonych do edycji, - wypełnionych niepoprawnie. Obsługa głównego skorowidza pacjentów, wspólnego dla wszystkich pozostałych modułów medycznych Szpitalnego Systemu Informatycznego HIS Specjalistycznego Szpitala im. E. Szczeklika w Tarnowie, zarówno w zakresie już funkcjonującym, jak i rozbudowy modułów objętych niniejszym zamówieniem: - wyszukiwanie pacjentów w skorowidzu wg różnych parametrów, - rejestracja i modyfikacja danych pacjentów, - rejestracja danych pacjenta z Unii Europejskiej,

7 11. - rejestracja danych pacjenta przyjmowanego decyzją wójta/burmistrza. System musi przechowywać historię zmian danych osobowych pacjenta. Wgląd w dane medyczne sprzed zmiany danych osobowych powinno umożliwić przeglądanie i wydruk dokumentacji z danymi pacjenta aktualnymi na dzień tworzenia tej dokumentacji. 12. Przegląd danych archiwalnych pacjenta: - w zakresie danych osobowych, - w zakresie danych z poszczególnych pobytów szpitalnych. 13. Rejestracja przyjęcia pacjenta w Izbie Przyjęć: - wprowadzenie danych o rozpoznaniu z wykorzystaniem słownika ICD10 - wprowadzenie danych ze skierowania, - wprowadzenie danych płatnika. 14. Wprowadzenie informacji o dokumentach uprawniających do uzyskania świadczeń. 15. Ewidencja elementów pobytu w Izbie Przyjęć: - wywiad wstępny z możliwością użycia słownika tekstów standardowych, - wykonane pacjentowi elementy leczenia: - procedury, - leki, - konsultacje. 16. Rejestracja informacji o wymaganym transporcie medycznym pacjenta. 17. Rejestracja opuszczenia Izby Przyjęć przez pacjenta w jednym z trybów: - skierowanie/cofnięcie skierowania na oddział (ustalenie trybu przyjęcia, form płatności, wydruk pierwszej strony historii choroby, itp.), - przeniesienie pacjenta na inną Izbę Przyjęć, - odmowa przyjęcia pacjenta do szpitala wpis do Księgi Odmów i Porad Ambulatoryjnych, - zaplanowanie późniejszego terminu przyjęcia wpis do Księgi Oczekujących, - zgon pacjenta na Izbie Przyjęć. 18. Autoryzacja danych Izby Przyjęć, 19. Ewidencja danych do rozliczenia produktów kontraktowanych z NFZ,

8 20. Wypełnianie i wydruk dokumentów Izby Przyjęć: - Karta Wypisowa, - Historia choroby pierwsza strona - Karta Odmowy. 21. Przechowywanie wszystkich wersji utworzonych dokumentów medycznych. 22. Obsługa Ksiąg: Księga Główna, - Księgi Izby Przyjęć, - Księga Oczekujących, - Odmów i Porad Ambulatoryjnych, - Zgonów. Integracja z innymi modułami medycznymi Szpitalnego Systemu Informatycznego HIS Specjalistycznego Szpitala im. E. Szczeklika w Tarnowie, realizującymi co najmniej funkcjonalność w zakresie: - ewidencji zużytych leków i materiałów oraz automatycznej aktualizacji stanów magazynowych - wymagana jest integracja z pracującym w Specjalistycznym Szpitalu im. E. Szczeklika w Tarnowie modułem Apteka Szpitalna oraz modułem Gospodarka Magazynowo-Materiałowa. - wzajemnego udostępniania danych zleceń i danych o ich wykonaniu - wymagana jest integracja z pracującym w Specjalistycznym Szpitalu im. E. Szczeklika w Tarnowie modułami: Zlecenia medyczne, Laboratorium Szpitalne, Blok Operacyjny, Pracownia Diagnostyczna. Projektowanie własnych formularzy dokumentacji medycznej w miarę pojawiających się indywidualnych potrzeb użytkowników, na podstawie danych gromadzonych w module. 25. Wbudowane raporty standardowe: - Ruch chorych Izby Przyjęć osobowy, - Ruch chorych Izby Przyjęć sumaryczny. 26. Definiowanie własnych wykazów w zakresie danych gromadzonych w module Wydruk opasek identyfikujących pacjenta: z kodem paskowym, numerem MIP (numerem identyfikacyjnym pacjenta w użytkowanym Zintegrowanym Szpitalnym Systemie Informacyjnym HIS, unikalnym identyfikatorem nadawanym przez Szpital i nie do skojarzenia z pacjentem poza nim) oraz nazwą oddziału/szpitala. Musi działać z zainstalowanymi u Zamawiającego drukarkami kodów Godex RT230 Wykonawca oświadcza, że spełnia wszystkie wymagania wymienione w Tabeli w pkt.1-27

9 Oddziały szpitalne Lp. Wymaganie (Oddziały szpitalne) Parametry Wymagane 1. Moduł musi działać w architekturze trójwarstwowej. 2. Interfejs użytkownika modułu musi być dostępny z poziomu przeglądarki internetowej i nie może wymagać instalowania żadnego dodatkowego oprogramowania na stacjach klienckich (system nie może wymagać korzystania ze specjalnych programów klienckich technologii typu Citrix, VNC, innych, w celu realizacji wymagań funkcjonalnych). 3. Moduł musi umożliwiać pracę z poziomu najbardziej popularnych przeglądarek, co najmniej Microsoft Internet Explorer, Google Chrome, Mozilla Firefox. 4. Moduł musi umożliwiać pracę na tabletach medycznych lub komputerach wyposażonych w monitory dotykowe oraz zwykłych stacjonarnych komputerach. Pełna funkcjonalność modułu musi być dostępna na wszystkich w/w urządzeniach. 5. Moduł musi 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. 6. Wszystkie błędy niewypełnienia pól obligatoryjnych oraz błędnego wypełnienia muszą być prezentowane w jednym komunikacie, z możliwością szybkiego przejścia do tego miejsca aplikacji (np. poprzez odpowiedni link), gdzie te błędy wystąpiły. 7. Wyróżnienie pól: - których wypełnienie jest wymagane, - przeznaczonych do edycji, - wypełnionych niepoprawnie. 8. Obsługa listy pacjentów Oddziału: - wyszukiwanie pacjentów na liście wg różnych parametrów, - wyszukanie pacjenta z wykorzystaniem kodu paskowego z opaski, - modyfikacja danych pacjentów z listy oddziałowej. 9. Przegląd danych archiwalnych pacjenta: - w zakresie danych osobowych, - w zakresie danych z poszczególnych pobytów szpitalnych. Odmowa lub anulowanie przyjęcia na Oddział wycofanie danych pacjenta na Izbę 10. Przyjęć. 11. Zaplanowanie późniejszego terminu przyjęcia wpis do Księgi Oczekujących Oddziału. 12. Rejestracja przyjęcia pacjenta na Oddziale: - nadanie numeru Księgi Oddziałowej automatycznego lub przez użytkownika, - wprowadzenie danych lekarza prowadzącego, - możliwość modyfikacji danych płatnika, - wprowadzenie danych o miejscu hospitalizacji w ramach oddziału: odcinka oddziałowego, łóżka, - wprowadzenie danych o rodzaju hospitalizacji do celów statystycznych, np. całodobowa z zabiegiem operacyjnym, dzienna z- i bez zabiegów i badań laboratoryjnych, itp. 13. Ewidencja elementów pobytu pacjenta na Oddziale: - wywiad wstępny z możliwością użycia słownika tekstów standardowych,

10 - rozpoznania: wstępne, końcowe, przyczyna zgonu. 14. Wykonane pacjentowi elementy leczenia (zlecenia): - procedury, w tym zabiegi, - badania diagnostyczne, - leki, - konsultacje, - diety. 15. Ewidencja diagnoz pielęgniarskich: - wprowadzanie diagnozy, - realizacja procedur, - plan realizacji, - wydruk indywidualnej karty procesu pielęgnacji. Możliwość wydruku raportu z dyżuru lekarskiego na podstawie wprowadzonych 16. obserwacji. 17. Ewidencja przepustek. 18. Ewidencja danych porodu dla Oddziału Ginekologiczno-Położniczego: - wpis do Księgi Porodów, - odnotowanie personelu uczestniczącego, - odnotowanie danych noworodka (medyczne, skala Apgar). 19. Rejestracja opuszczenia Oddziału przez pacjenta w jednym z trybów: - przeniesienie/wycofanie przeniesienia pacjenta na inny Oddział. - przeniesienie w trybie nagłym na inny Oddział (bez uzupełnienia danych wypisowych z poprzedniego oddziału), - wypis pacjenta ze Szpitala, - zgon pacjenta na Oddziale, 20. Odnotowanie faktu wydania pacjentowi druków, zaświadczeń, skierowań itp. 21. Autoryzacja danych oddziałowych. Ewidencja danych do rozliczenia kontraktowanych produktów z płatnikiem, w tym 22. rozliczanie kart TISS Prowadzenie i wydruk Historii Choroby w podziale na: - dane przyjęciowe, - wywiad wstępny (przedmiotowo, podmiotowo), - przebieg choroby, - epikryza (możliwością wykorzystania słownika tekstów standardowych). 24. Wydruki dokumentów wewnętrznych Oddziału, w tym: - Karta wypisowa, - Karta informacyjna. 25. Wydruki dokumentów zewnętrznych Oddziału, w tym: - Karta statystyczna, - Karta leczenia psychiatrycznego, - Karta zakażenia szpitalnego, - Karta nowotworowa,

11 - Karta zgłoszenia choroby zakaźnej, - Karta zgonu, - Karta tiss Przechowywanie w systemie wszystkich wersji utworzonych dokumentów. 27. Obsługa ksiąg: - Księga główna, - Oddziałowa, - Oczekujących, - Zgonów, - Noworodków, - Zabiegów. 28. Możliwość definiowania własnych szablonów wydruków. 29. Wbudowane raporty standardowe: - zestawienie pacjentów, nowoprzyjętych, wypisanych, przebywających na oddziale (dzienne, tygodniowe, za dowolny okres), - ilość osobodni z uwzględnieniem przepustek, w zadanym okresie, - obłożenie łóżek na dany moment, - diety podane pacjentom oddziału. Możliwość definiowania własnych wykazów w zakresie danych gromadzonych w 30. module. Możliwość projektowania formularzy dokumentacji medycznej w miarę pojawiających 31. się indywidualnych potrzeb użytkowników, na podstawie danych gromadzonych w module. Integracja z innymi modułami systemu medycznego realizującymi funkcjonalność w 32. zakresie: - ewidencji zużytych leków i materiałów oraz automatycznej aktualizacji stanów magazynowych - wymagana jest integracja z pracującym w Specjalistycznym Szpitalu im. E. Szczeklika w Tarnowie modułem Apteka Szpitalna oraz modułem Gospodarka Magazynowo-Materiałowa - wzajemnego udostępniania danych zleceń i danych o ich wykonaniu - wymagana jest integracja z pracującymi w Specjalistycznym Szpitalu im. E. Szczeklika w Tarnowie modułami Zlecenia medyczne, Laboratorium Szpitalne, Blok Operacyjny, Pracownia Diagnostyczna, System powinien zawierać pulpity użytkowników umożliwiające bezpośredni dostęp 33. do wszystkich niezbędnych funkcji, do jakich użytkownik posiada uprawnienia. 34. Powinny istnieć zdefiniowane pulpity, co najmniej w zakresie: - pulpit lekarza, - pulpit pielęgniarki. 35. Pulpit użytkownika musi zawierać co najmniej bezpośredni dostęp do: - pacjentów: oddziału, moich pacjentów, czyli tych dla których zalogowany lekarz jest lekarzem prowadzącym, zaplanowanych na wizytę i konsultacje, umówionych na dzisiaj, - wyników badań z podziałem na laboratoryjne, diagnostyczne i inne z możliwością wyświetlenia tylko najnowszych wyników (np. z ostatnich 24 godzin), - zaplanowane na dzisiaj: wizyty, konsultacje, - dokumentacji medycznej pacjentów oddziału, moich, umówionych na wizytę, z odbytych wizyt i konsultacji,

12 36. - terminarza użytkownika uwzględniający jego: dyżury, nieobecności, zadania, zaplanowane dla niego lub zrealizowane przez niego: zabiegi, konsultacje, wizyty. Musi istnieć możliwość samodzielnego, przez użytkowników i/lub administratorów, definiowania pulpitu i/lub jego modyfikacji w zakresie jego treści i wyglądu, np. możliwość wstawienia zdjęcia właściciela pulpitu, kolejności treści wymienionych w 5 powyższych punktach, bądź niewyświetlania niektórych z nich, itp. 37. Generowanie Historii Choroby z danych zgromadzonych w systemie. 38. Generowanie Karty Informacyjnej z danych gromadzonych w systemie. Generowanie wyników badań dla zadanych kryteriów: pacjent, nazwa badania, 39. jednostka organizacyjna, zadany okres czasu. 40. Generowanie wydruków kart obserwacji pacjenta. 41. Generowanie wydruków kart zakażenia, kart drobnoustroju. Generowanie raportów z dyżuru lekarskiego na podstawie zarejestrowanych 42. obserwacji pacjenta. 43. Generowanie raportów z diagnoz pielęgniarskich. Elastyczne dopasowanie systemu do potrzeb Zamawiającego w zakresie 44. dokumentowania procesu leczenia : - definiowania własnych formularzy przeznaczonych do wpisywania danych w systemie, w zakresie danych gromadzonych w module - wyświetlanie, wprowadzanie i drukowanie informacji w ustalonej przez użytkownika postaci (definiowalne formularze oraz edytor wydruków dla badań, konsultacji, itp.), w zakresie danych gromadzonych w module - histogramy, - możliwość kojarzenia formularzy ze zleceniami. 45. Rejestrowanie danych multimedialnych (rysunki, obrazy, dźwięki, itp.). 46. Dostęp do danych dla potrzeb analityczno-sprawozdawczych. System powinien przechowywać wszystkie wersje utworzonej i wydrukowanej (lub 47. zarchiwizowanej w archiwum elektronicznym) dokumentacji medycznej. Wszystkie dokumenty dokumentacji medycznej pacjenta powinny być dostępne z 48. jednego miejsca. Podczas drukowania dokumentu wygenerowanego wcześniej system powinien 49. informować, że nastąpiły zmiany w danych i zaleca się utworzenie nowej wersji dokumentu. Powinna istnieć możliwość podpisania elektronicznego i zarchiwizowania wszystkich 50. dokumentów dokumentacji medycznej tworzonych przez system zgodnie z obowiązującymi przepisami. 51. Możliwość archiwizacji dokumentacji medycznej w postaci elektronicznej. Możliwość automatycznej rejestracji dokumentów elektronicznych generowanych 52. przez zewnętrzne systemy współpracujące z repozytorium dokumentacji elektronicznej (za pomocą usługi sieciowej). Możliwość manualnego tworzenia nowych dokumentów w postaci elektronicznej (np. 53. cyfryzacja dokumentu papierowego, import pliku RTF, PDF itd.). 54. Możliwość exportu/importu dokumentu elektronicznego do/z pliku w formacie XML. 55. Możliwość złożenia podpisu elektronicznego na dokumencie. 56. Możliwość znakowania czasem dokumentu. 57. Możliwość wykonania kontrasygnaty. 58. Możliwość weryfikacji podpisu elektronicznego. 59. Możliwość wydruku dokumentu.

13 Możliwość wyszukiwania dokumentów za pomocą zaawansowanych kryteriów oraz 60. meta danych. Możliwość wersjonowania przechowywanych dokumentów z dostępem do pełnej 61. historii poprzednich wersji. System uprawnień pozwalający na precyzyjne definiowanie obszarów dostępnych dla 62. danego użytkownika pełniącego określoną rolę. Możliwość zarządzania uprawnieniami dostępu do określonych operacji w repozytorium. Przykłady uprawnień systemowych: uruchomienie systemu, 63. zarządzanie uprawnieniami użytkowników, zarządzanie parametrami konfiguracyjnymi, zarządzanie typami dokumentów. Możliwość zarządzania uprawnieniami do wykonywania operacji na poszczególnych typach dokumentów w ramach całej placówki lub poszczególnych jednostek organizacyjnych. Przykłady uprawnień do dokumentów: dodawanie dokumentów do 64. repozytorium, odczyt dokumentu, podpisywanie dokumentu, znakowanie czasem dokumentu, import i eksport dokumentu, anulowanie dokumentu, wydruk dokumentu itd. Możliwość definiowania nowych typów dokumentów obsługiwanych przez repozytorium dokumentów elektronicznych, czyli możliwość przechowywania w 65. repozytorium nowych typów dokumentów, poza tymi, które zostaną zdefiniowane na etapie wdrażania systemu. 66. Możliwość definiowania meta-danych opisujących dokumenty danego typu. Możliwość definiowania pojęć opisujących dokumenty danego typu. Przykład pojęcia 67. na dokumencie: Rozpoznanie. Możliwość definiowania atrybutów opisujących pojęcia występujące na dokumencie 68. danego typu. Przykład: pojęcie na dokumencie np. Rozpoznanie ma następujące atrybuty: Kod ICD10, Nazwa rozpoznania, Uwagi, Opis. Wyznaczanie Jednorodnych Grup Pacjentów na podstawie danych hospitalizacji za 69. pomocą wbudowanego grupera JGP. 70. Import aktualnego słownika procedur medycznych ICD9 (komunikat ICD9). 71. Wyznaczanie JGP dla hospitalizacji. Zapewnienie sprawnego zasilania systemu w aktualne charakterystyki JGP wynikające 72. z publikowanych Zarządzeń Prezesa NFZ. Wyznaczanie JGP za pomocą wbudowanego (lokalnego) grupera JGP w zakresie 73. umów: leczenie szpitalne, rehabilitacja stacjonarna, ambulatoryjna opieka specjalistyczna. Możliwość ręcznego wyznaczenia JGP dla hospitalizacji z pominięciem grupera 74. lokalnego i grupera NFZ. Możliwość automatycznego przypisania JGP do pobytu na oddziale, z którego 75. pochodzi element kierunkowy wyznaczonej JGP. Wsteczna weryfikacja poprawności wyznaczonych wcześniej JGP z możliwością 76. automatycznej aktualizacji JGP na poprawną. Różnice wynikające z wczytania nowych wersji grupera, które opublikowano z 77. wsteczną datą obowiązywania, które mogą obejmować: - różnice w zaewidencjonowanych taryfach, różnice w zaewidencjonowanych JGP. Różnice wynikające z modyfikacji danych statystycznych hospitalizacji, a mające wpływ na wyznaczoną JGP: - konieczność zmiany JGP, - konieczność zmiany taryfy, - konieczność przepięcia JGP do pobytu na innym oddziale. 79. Wyszukiwanie hospitalizacji wg poniższych kryteriów:

14 - data zakończenia hospitalizacji, - wersja grupera za pomocą którego wyznaczono JGP - kod JGP, - rozpoznanie główne, - kod procedury medycznej, - status rozliczenia. Wskazanie możliwości uzyskania JGP o większej taryfie w przypadku zmiany 80. kombinacji rozpoznań wypisowych. Wsteczna weryfikacja z możliwością automatycznej aktualizacji JGP pod kątem 81. znalezienia bardziej optymalnej JGP. 82. Możliwość wykonywania symulacji wyznaczania JGP: -wstępne zasilenie symulatora danymi z wybranej hospitalizacji, - możliwość sprawnej modyfikacji danych w symulatorze i obserwacja wpływu zmian na wyznaczane JGP. 83. Modyfikacja danych pacjenta (wiek, płeć). Modyfikacja danych hospitalizacji (data przyjęcia, data wypisu, tryb przyjęcia, tryb 84. wypisu, tryb i charakter hospitalizacji). 85. Dodanie lub usuniecie pobytu. Modyfikacja danych pobytu (data przyjęcia, data wypisu, cz. VIII kodu resortowego 86. komórki, kod świadczenia, rozpoznanie zasadnicze, rozpoznania współistniejące, procedury medyczne (daty wykonania)). Wyróżnianie kolorami danych hospitalizacji nieistotnych z punktu widzenia 87. wyznaczenia JGP. 88. Możliwość określenia wersji grupera za pomocą którego wyznaczone zostaną JGP. 89. Wersja grupera wynikająca z daty zakończenia hospitalizacji. 90. Dowolna wersja grupera istniejąca w systemie. 91. Wskazywanie JGP z podziałem na: - JGP, dla której hospitalizacja spełnia warunki wyboru, - JGP, dla których hospitalizacja nie spełnia warunków, - JGP, które istnieją w planie umowy świadczeniodawcy. Wyróżnienie kolorem pozycji w celu odzwierciedlenia ważności wyznaczonych JGP z 92. punktu widzenia świadczeniodawcy (np. istniejących w planie umowy a tym samym możliwych do rozliczenia). W przypadku wskazania JGP do których pacjent mógłby zostać zakwalifikowany 93. jednak nie zostały spełnione wszystkie warunki - wskazanie tych warunków. 94. Możliwość przeglądu podstawowych informacji o wybranej JGP. 95. Wartości taryf dla poszczególnych trybów hospitalizacji. Parametry związane z mechanizmem osobodni (liczba dni finansowana grupą, taryfa 96. dla hospitalizacji trwających < 2 dni, wartość punktowa osobodnia ponad ryczałt finansowany grupą). 97. Parametry JGP (warunki, które musi spełniać hospitalizacja). 98. Wykorzystanie planu umowy dla JGP w przypadku, gdy JGP istnieje w umowie. Prezentacja wykresów ilustrujących zależność naliczonych taryf od czasu hospitalizacji 99. pacjenta. Wykonawca oświadcza, że spełnia wszystkie wymagania wymienione 100. w Tabeli w pkt.1-99

15 Statystyka medyczna Lp. Wymaganie (Statystyka medyczna) Parametry Wymagane 1. Moduł musi działać w architekturze trójwarstwowej. Interfejs użytkownika modułu musi być dostępny z poziomu przeglądarki internetowej i nie może wymagać instalowania żadnego dodatkowego oprogramowaniach na stacjach 2. klienckich (system nie może wymagać korzystania ze specjalnych programów klienckich technologii typu Citrix, VNC, innych, w celu realizacji wymagań funkcjonalnych). Moduł musi umożliwiać pracę z poziomu najbardziej popularnych przeglądarek, co 3. najmniej Microsoft Internet Explorer, Google Chrome, Mozilla Firefox. Moduł musi umożliwiać pracę na tabletach medycznych lub komputerach 4. wyposażonych w monitory dotykowe oraz zwykłych stacjonarnych komputerach. Pełna funkcjonalność modułu musi być dostępna na wszystkich w/w urządzeniach. Moduł musi umożliwiać wykonanie nowej operacji w systemie bez konieczności 5. 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. Wszystkie błędy niewypełnienia pól obligatoryjnych oraz błędnego wypełnienia muszą 6. być prezentowane w jednym komunikacie, z możliwością szybkiego przejścia do tego miejsca aplikacji (np. poprzez odpowiedni link), gdzie te błędy wystąpiły. 7. Wyróżnienie pól: 8. - których wypełnienie jest wymagane, - przeznaczonych do edycji, - wypełnionych niepoprawnie. Obsługa głównego i jedynego skorowidza pacjentów Zintegrowanego Szpitalnego Systemu Informacyjnego HIS Specjalistycznego Szpitala im. E. Szczeklika w Tarnowie: - wyszukiwanie pacjentów w skorowidzu wg różnych parametrów, - rejestracja i modyfikacja danych pacjentów. 9. Przegląd danych archiwalnych pacjenta: - w zakresie danych osobowych, - w zakresie danych z poszczególnych pobytów szpitalnych. 10. Potwierdzenia wypisu pacjenta pod kątem kompletności i poprawności dokumentacji. 11. Wbudowane wydruki zewnętrzne: - Karta statystyczna, - Karta leczenia psychiatrycznego, - Karta zgonu, 12. Obsługa Ksiąg: - Księga główna, - Księga odmów, - Księga zgonów, - Księga noworodków, 13. Możliwość definiowania własnych szablonów wydruków. 14. Wbudowane raporty standardowe:

16 - zestawienie pacjentów, nowoprzyjętych, wypisanych, przebywających na oddziale (dzienne, tygodniowe, za dowolny okres), - liczba osobodni z uwzględnieniem przepustek, w zadanym okresie, - obłożenie łóżek na dany moment, - diety podane pacjentom oddziału. Możliwość definiowania własnych wykazów w zakresie danych gromadzonych w 15. module. Możliwość projektowania formularzy dokumentacji medycznej w miarę pojawiających 16. się indywidualnych potrzeb użytkowników, na podstawie danych gromadzonych w module. 17. Wbudowane raporty standardowe: - statystyczne z oddziałów: np. Dziennik ruchu chorych, wskaźniki szpitalne w okresie (liczba. przyjętych, liczba wypisanych, liczba osobodni), - z obłożenia łóżek, - zestawienia wg jednostek chorobowych, czasu leczenia jednostki chorobowej (sumaryczne i osobowe). 18. Elektroniczna komunikacja z instytucjami nadrzędnymi, w tym: Oddziały NFZ, - Centrum Zdrowia Publicznego. Eksport danych statystycznych oraz ilościowych o wykonanych świadczeniach do pliku tekstowego lub w formacie.xls. Wykonawca oświadcza, że spełnia wszystkie wymagania wymienione w Tabeli w pkt.1-19

17 Rozliczenia z NFZ Lp. Wymaganie (Rozliczenia z Narodowym Funduszem Zdrowia) Parametry Wymagane 1. Moduł musi działać w architekturze trójwarstwowej. 2. Interfejs użytkownika modułu musi być dostępny z poziomu przeglądarki internetowej i nie może wymagać instalowania żadnego dodatkowego oprogramowaniach na stacjach klienckich (system nie może wymagać korzystania ze specjalnych programów klienckich technologii typu Citrix, VNC, innych, w celu realizacji wymagań funkcjonalnych). 3. Moduł musi umożliwiać pracę z poziomu najbardziej popularnych przeglądarek, co najmniej Microsoft Internet Explorer, Google Chrome, Mozilla Firefox. 4. Moduł musi umożliwiać pracę na tabletach medycznych lub komputerach wyposażonych w monitory dotykowe oraz zwykłych stacjonarnych komputerach. Pełna funkcjonalność modułu musi być dostępna na wszystkich w/w urządzeniach. 5. Moduł musi 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. 6. Wszystkie błędy niewypełnienia pól obligatoryjnych oraz błędnego wypełnienia muszą być prezentowane w jednym komunikacie, z możliwością szybkiego przejścia do tego miejsca aplikacji (np. poprzez odpowiedni link), gdzie te błędy wystąpiły. 6. Zarządzanie umowami NFZ 7. Import pliku umowy w postaci komunikatu UMX, 8. Przegląd i modyfikacja szczegółów umowy: Okres obowiązywania umowy, - Pozycje planu umowy, - Miejsca realizacji świadczeń - Limity na realizację świadczeń i ceny jednostkowe, - Słowniki związane z umowami (słownik zakresów świadczeń, świadczeń jednostkowych, pakietów świadczeń, schematów leczenia itd.) - Parametry pozycji pakietów świadczeń Moduł korzysta bezpośrednio z danych zaewidencjonowanych na oddziałach i w poradniach bez konieczności importu i kopiowania danych 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 - Różnica w cenie świadczenia, - Różnica w wadze efektywnej świadczenia, - Różnica w sposobie obliczania krotności i okresu sprawozdawczego, 11. Definiowanie dodatkowych walidacji - Liczba realizacji świadczeń w okresie, - Liczba realizacji świadczeń w ramach zakresu w okresie, 12. Możliwość ewidencji i rozliczenia realizowanych świadczeń - Ubezpieczonym, - Nieubezpieczonym a uprawnionym do świadczeń,

18 - Uprawnionym na podstawie decyzji wójta/burmistrza - Uprawnionym na podstawie przepisów o koordynacji, - Uprawnionym na podstawie Karty Polaka - Kobietom w ciąży, w okresie połogu oraz młodzieży do 18 roku życia 13. Możliwość zbiorczej modyfikacji pozycji rozliczeniowych w zakresie zmian dotyczących Numeru umowy, - Zakresu świadczeń, - Wyróżnika - Świadczenia jednostkowego, Możliwość wprowadzenia dodatkowego poziomu kontroli wprowadzonych świadczeń poprzez funkcjonalność autoryzacji świadczeń przez osobę uprawnioną Przegląd informacji o posiadanych przez pacjenta uprawnieniach do świadczeń w każdym dniu pobytu Po otrzymaniu informacji z NFZ, uprawniony użytkownik działu rozliczeń musi mieć możliwość modyfikacji danych Sprawozdawczość z oddziałów NFZ w zakresie komunikacji przez pocztę elektroniczną musi odbywać się automatycznie, z poziomu systemu HIS W przypadku komunikatów, w których NFZ wymaga kompresowania lub szyfrowania danych, operacje te muszą odbywać się automatycznie w systemie HIS System musi umożliwić harmonogramowanie eksportów danych: o wyznaczonej godzinie, co określoną liczbę godzin, za określoną liczbę godzin Weryfikacja zestawów świadczeń pod kątem poprawności i kompletności wprowadzonych danych 21. Wyszukiwanie pozycji błędnie potwierdzonych w komunikatach zwrotnych NFZ 22. Wyszukiwanie po numerach w księgach 23. Wyszukiwanie zestawów bez zaewidencjonowanych procedur ICD9 24. Wyszukiwanie zestawów po numerze paczki, w której wyeksportowano dane do NFZ 25. Wyszukiwanie po instytucji kierującej 26. Wyszukiwanie po personelu kierującym/ realizującym 27. Wyszukiwanie zestawów bez pozycji rozliczeniowych 28. Wyszukiwanie zestawów z niekompletnymi danymi rozliczeniowymi 29. Wyszukiwanie pozycji rozliczeniowych, które nie zostały jeszcze rozliczone 30. Wyszukiwanie po statusie rozliczenia 31. Wyszukiwanie zestawów zawierających rozliczenia ze wskazanej umowy 32. Wyszukiwanie zestawów zawierających wskazane świadczenie jednostkowe 33. Wyszukiwanie zestawów świadczeń z JGP wyznaczoną w zadanej wersji 34. Wyszukiwanie zestawów świadczeń ratujących życie i zdrowie Wyszukiwanie zestawów świadczeń zrealizowanych dla wybranych uprawnień 35. pacjenta Wyszukiwanie świadczeń, które zostały skorygowane, a informacja o skorygowaniu nie 36. została sprawozdana do systemu NFZ Generowanie i eksport komunikatu fazy I (komunikat SWIAD) w aktualnie 37. obowiązującej wersji publikowanej przez płatnika 38. Import potwierdzeń do danych przekazanych w komunikacie I fazy (komunikat P_SWI)

19 39. Import danych z pliku z szablonami rachunków (komunikat R_UMX) 40. Eksport komunikatów związanych ze sprawozdawczością kolejek oczekujących - Eksport komunikatu LIOCZ informacje o statystykach kolejek oczekujących - Eksport komunikatu KOL informacje o oczekujących na świadczenia wysokospecjalistyczne 41. Import potwierdzeń związanych ze sprawozdawczością kolejek oczekujących Import komunikatu P_LIO potwierdzenie statystyk przekazanych w komunikacie 42. LIOCZ 43. Przegląd szablonów rachunków wygenerowanych i przekazanych przez płatnika 44. Generowanie i wydruk rachunków na podstawie szablonów 45. Generowanie i wydruk faktur na podstawie rachunków Generowanie i wydruk zestawień i raportów związanych ze sprawozdawczością 46. wewnętrzną (możliwość śledzenia postępów wykonania zakontraktowanych świadczeń w ciągu trwania okresu rozliczeniowego) 47. Raport z wykonanych świadczeń z możliwością ograniczenia danych do m.in.: - Numeru umowy, - Zakresu miesięcy sprawozdawczych, - Miesiąca rozliczeniowego, - Jednostki realizującej, - Zakresu świadczeń i wyróżnika, - Świadczenia, - Numeru szablonu - Uprawnienia pacjenta do świadczeń 48. Zestawienie z realizacja planu umowy, 49. Zestawienie wykonań przyrostowo, 50. Zestawienie wykonań według miejsc realizacji 51. Sprawozdanie rzeczowe 52. Eksport danych do popularnych formatów (XLS, TXT, CSV, HTML) Generowanie i wydruk dokumentów związanych ze sprawozdawczością wymaganą 53. przez OW NFZ 54. Sprawozdanie finansowe, 55. Zestawienie świadczeń udzielonych świadczeniobiorcom innym niż ubezpieczeni, Zestawienie świadczeń wykonanych pacjentom na podstawie przepisów o koordynacji 56. (UE), Zestawienie świadczeń wykonanych pacjentom na podstawie art. 2 ust. 1 ustawy 57. (decyzja wójta/burmistrza), Zestawienie świadczeń wykonanych pacjentom nieubezpieczonym, rozliczanym na 58. podstawie art. 12 lub art. 13 ustawy 59. Wyliczanie kosztów porady u pacjenta nieubezpieczonego 60. Załącznik nr 4 do umowy - chemioterapia 61. Załącznik nr 4 do umowy programy terapeutyczne 62. Załączniki do umów 63. Ewidencja faktur zakupowych

20 64. Import słownika produktów handlowych (komunikat PRH) 65. Możliwość przekodowania produktów handlowych na leki 66. Ewidencja faktur zakupowych Generowanie i eksport faktur zakupowych do NFZ w aktualnym formacie komunikatu 67. FZX 68. Import potwierdzeń do faktur zakupowych (komunikat FZZ) 69. Generowanie i wydruk załącznika nr 4 do umowy ewidencja faktur zakupowych System powinien umożliwiać definiowanie minimalnej i maksymalnej liczby pacjentów 70. uczestniczących w sesjach Integracja z innymi modułami Szpitalnego Systemu Informatycznego HIS 71. Specjalistycznego Szpitala im. E. Szczeklika w Tarnowie: ewidencja pozycji rozliczeniowych w Ruchu Chorych i Przychodni, - ewidencja faktur zakupowych za leki w chemioterapii w module Apteka Szpitalna, - ewidencja faktur zakupowych na leki stosowane w programach lekowych, Eksport faktur rozliczeniowych do modułu Finansowo-Księgowego Szpitalnego Systemu Informatycznego HIS Specjalistycznego Szpitala im. E. Szczeklika w Tarnowie. Przekazywanie danych o hospitalizacji do Symulatora JGP Szpitalnego Systemu Informatycznego HIS Specjalistycznego Szpitala im. E. Szczeklika w Tarnowie. Wykonawca oświadcza, że spełnia wszystkie wymagania wymienione w Tabeli w pkt.1-73

21 Apteczka Oddziałowa Lp. Wymaganie (Apteczka oddziałowa) Parametry Wymagane 1. Moduł musi działać w architekturze trójwarstwowej. Interfejs użytkownika modułu musi być dostępny z poziomu przeglądarki internetowej i nie może wymagać instalowania żadnego dodatkowego oprogramowaniach na stacjach 2. klienckich (system nie może wymagać korzystania ze specjalnych programów klienckich technologii typu Citrix, VNC, innych, w celu realizacji wymagań funkcjonalnych). Moduł musi umożliwiać pracę z poziomu najbardziej popularnych przeglądarek, co 3. najmniej Microsoft Internet Explorer, Google Chrome, Mozilla Firefox. Moduł musi umożliwiać pracę na tabletach medycznych lub komputerach wyposażonych 4. w monitory dotykowe oraz zwykłych stacjonarnych komputerach. Pełna funkcjonalność modułu musi być dostępna na wszystkich w/w urządzeniach. Moduł musi umożliwiać wykonanie nowej operacji w systemie bez konieczności 5. 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. Wszystkie błędy niewypełnienia pól obligatoryjnych oraz błędnego wypełnienia muszą 6. być prezentowane w jednym komunikacie, z możliwością szybkiego przejścia do tego miejsca aplikacji (np. poprzez odpowiedni link), gdzie te błędy wystąpiły. 7. Wyróżnienie pól: - których wypełnienie jest wymagane, - przeznaczonych do edycji, - wypełnionych niepoprawnie. 8. Generowanie elektronicznych zamówień do apteki głównej (szpitalnej). 9. Obsługa magazynu apteczki oddziałowej: a) wydawanie środków farmaceutycznych z apteczki oddziałowej: - wydawanie na oddział/pacjenta - współpraca z funkcjonującymi w Specjalistycznym Szpitalu im. E. Szczeklika w Tarnowie modułami Ruch Chorych oraz Przychodnia Specjalistyczna, - zwrot do apteki, - ubytki i straty nadzwyczajne, - korekta wydań środków farmaceutycznych; b) korekta stanów magazynowych: - korekta stanów magazynowych (ilościowa i jakościowa) na podstawie arkusza spisu z natury, - generowanie arkusza do spisu z natury, - bieżąca korekta jakościowa stanu magazynowego. 10. Możliwość definiowania receptariusza oddziałowego. 11. Możliwość obsługi apteczek własnych pacjentów. Wykonawca oświadcza, że spełnia wszystkie wymagania wymienione w 12. Tabeli w pkt.1-11

22 Zlecenia medyczne Lp. Wymaganie (Zlecenia medyczne) Parametry Wymagane 1. Moduł musi działać w architekturze trójwarstwowej. 2. Interfejs użytkownika modułu musi być dostępny z poziomu przeglądarki internetowej i nie może wymagać instalowania żadnego dodatkowego oprogramowania na stacjach klienckich (system nie może wymagać korzystania ze specjalnych programów klienckich technologii typu Citrix, VNC, innych, w celu realizacji wymagań funkcjonalnych). 3. Moduł musi umożliwiać pracę z poziomu najbardziej popularnych przeglądarek, co najmniej Microsoft Internet Explorer, Google Chrome, Mozilla Firefox. 4. Moduł musi umożliwiać pracę na tabletach medycznych lub komputerach wyposażonych w monitory dotykowe oraz zwykłych stacjonarnych komputerach. Pełna funkcjonalność modułu musi być dostępna na wszystkich w/w urządzeniach. 5. Moduł musi 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. 6. Wszystkie błędy niewypełnienia pól obligatoryjnych oraz błędnego wypełnienia muszą być prezentowane w jednym komunikacie, z możliwością szybkiego przejścia do tego miejsca aplikacji (np. poprzez odpowiedni link), gdzie te błędy wystąpiły. 7. Wyróżnienie pól: których wypełnienie jest wymagane, - przeznaczonych do edycji, - wypełnionych niepoprawnie. Planowanie i zlecanie leków w powiązaniu z funkcjonującym w Specjalistycznym Szpitalu im. E. Szczeklika w Tarnowie modułem Apteczka Oddziałowa. Planowanie i zlecanie badań diagnostycznych i laboratoryjnych, zabiegów, konsultacji przekazywanych z jednostek Zamawiającego, w ramach funkcjonującego Szpitalnego Systemu Informatycznego HIS Specjalistycznego Szpitala im. E. Szczeklika w Tarnowie, a w tym: - z Izby Przyjęć (IP) oraz Oddziału do modułu InfoMedica Laboratorium Szpitalne (do wszystkich pracowni laboratorium Specjalistycznego Szpitala im. E. Szczeklika w Tarnowie), - z Izby Przyjęć (IP) oraz Oddziału do Pracowni Diagnostycznej, - z Izby Przyjęć (IP) oraz Oddziału do Przychodni Specjalistycznej, - z Izby Przyjęć (IP) oraz Oddziału do Bloku Operacyjnego, - z Izby Przyjęć (IP) oraz Oddziału do innego Oddziału w ramach funkcjonującego Szpitalnego Systemu Informatycznego HIS Specjalistycznego Szpitala im. E. Szczeklika w Tarnowie, - z Izby Przyjęć (IP) oraz Oddziału do Gabinetu Lekarskiego, z Izby Przyjęć (IP) oraz Oddziału do systemu RIS, Zlecanie wielu różnych badań w jednym miejscu, opatrzonych wspólnym nagłówkiem i komentarzem.