1. ROZBUDOWA POSIADANEGO PRZEZ ZAMAWIAJĄCEGO SYSTEMU INFOMEDICA

Strona1 Załącznik nr 1 do specyfikacji Ujednolicony opis przedmiotu zamówienia DZZ-382-60/12 Zamawiający za równoważny uzna system spełniający funkcjonalności wymienione w pkt. 3.8. W przypadku zaoferowania systemu równoważnego Wykonawca zobowiązany jest w ciągu 5 dni od dnia otwarcia ofert przedstawić w formie nieodpłatnej prezentacji w siedzibie Zamawiającego zaoferowany system potwierdzając, że spełnia on wszystkie określone przez Zamawiającego wymagane funkcjonalności. Uwaga: Ewentualne stwierdzenie przez komisję przetargową w trakcie weryfikacji oprogramowania aplikacyjnego braku choćby jednej funkcjonalności lub parametru technicznego, mimo wykazania go przez Oferenta w załączniku nr 1 SIWZ, skutkować będzie odrzuceniem oferty danego Oferenta. 1. ROZBUDOWA POSIADANEGO PRZEZ ZAMAWIAJĄCEGO SYSTEMU INFOMEDICA 1) Dostawę następujących modułów oprogramowania aplikacyjnego HIS (ang. Hospital Information System) zapisanych na nośniku danych (1 sztuka), udzielenie bezterminowej licencji na sieciowe użytkowanie tych programów aplikacyjnych wraz z nadzorem autorskim nad tym oprogramowaniem aplikacyjnym przez okres 2 lat od daty podpisania umowy realizacyjnej (opis wymagań funkcjonalnych dla oprogramowania aplikacyjnego znajduje się w załączniku nr 1 do SIWZ): Lp Moduł HIS Liczba licencji Licencja na nieograniczoną liczbę 1 epacjent użytkowników 2 ekontrahent Licencja na nieograniczoną liczbę użytkowników 3 Przychodnia Rejestracja Licencja na nieograniczoną liczbę użytkowników 4 Przychodnia Gabinet Lekarski Licencja na nieograniczoną liczbę użytkowników 5 Przychodnia Statystyka Licencja na 3 użytkowników 6 RIS: Pracowania Diagnostyczna Licencja na 6 użytkowników 7 Sprzedaż Usług Medycznych Umowy komercyjne Licencja na nieograniczoną liczbę użytkowników 8 Identyfikacja pacjentów za pomocą kodów kreskowych Licencja na funkcjonalność 9 Elektroniczna Inwentaryzacja Licencja na funkcjonalność 2) Integracja nowo zakupywanych modułów oprogramowania aplikacyjnego HIS z systemem InfoMedica funkcjonującym u Zamawiającego (opis wymagań funkcjonalnych w tym zakresie dla oprogramowania znajduje się w dalszej części SIWZ). Wymiana danych między systemami powinna odbywać się bezpośrednio na poziomie bazy danych lub z

Strona2 wykorzystaniem standardu HL7 w wersji 2.3. (opis dokumentacji technicznej z tym związanej znajduje się w załączniku zatytułowanym: Komunikaty HL7 w InfoMedica ) oraz uwzględniać wymagania w dalszej części SIWZ. Zestawienie posiadanego przez Zamawiającego oprogramowania aplikacyjnego InfoMedica: w części administracyjnej (szarej): Finanse i Księgowość Rachunek Kosztów Wycena Kosztów Normatywnych Rejestr Sprzedaży Grafiki Gospodarka Materiałowa Środki trwałe Wyposażenie Kasa Kalkulacja Kosztów Leczenia w części medycznej (białej) HIS: Ruch Chorych ( w tym: izba przyjęć, oddziały, statystyka) Zlecenia Apteka Apteczki owe Pracownia Diagnostyczna i Przychodnia Blok Operacyjny Zakażenia szpitalne Dokumentacja Medyczna Sprzedaż Usług Medycznych: Umowy NFZ Symulator JGP 3) Zakres integracji dla istniejącego rozwiązania InfoMedica oraz zakres integracji pomiędzy istniejącym rozwiązaniem InfoMedica a oprogramowaniem będącym przedmiotem zamówienia. Wymogi dotyczące przepływu danych miedzy modułami wymagania: Lp. 1. 2. 3. Nazwa wymagania Wspólna baza kontrahentów dla wszystkich modułów, Gospodarka materiałowa, Rejestr Sprzedaży, Środki Trwałe, Wyposażenie, Kasa, Apteka. Wspólna baza ośrodków powstawania kosztów dla modułów: Finanse- Księgowość, Rachunek Kosztów, Wycena Kosztów Normatywnych, Gospodarka materiałowa, Środki Trwałe, Wyposażenie,, Kalkulacja Kosztów Leczenia, Apteka, Ruch chorych oraz dla modułów Przychodnia Rejestracja, Przychodnia Gabinet Lekarski, Przychodnia Statystyka, Pracownia Diagnostyczna. Wspólna baza świadczeń medycznych (Procedur, Badania) modułów: Rachunek Kosztów, Wycena Kosztów Normatywnych Świadczeń, Kalkulacja Kosztów Leczenia, Ruch chorych oraz dla modułów Przychodnia Rejestracja, Przychodnia Gabinet Lekarski, Przychodnia Potwierdzenie spełnienia minimalnych wymagań [spełnia / nie spełnia]

Strona3 Statystyka, Pracownia Diagnostyczna. 4. Z modułu Kasa przekazywane są zadekretowane raporty kasowe do modułu Finanse-Księgowość. Zadekretowane listy płac z modułu przekazywane są automatycznie 5. na poziomie bazy danych do systemu Finanse-księgowość / Rachunek Kosztów. Zadekretowane odpisy amortyzacyjne z modułu Środki Trwałe 6. przekazywane są na poziomie bazy do modułu Finanse-księgowość / Rachunek Kosztów. 7. Zadekretowane faktury z modułu Rejestr Sprzedaży przekazywane są do modułu Finanse-Księgowość i VAT. 8. Koszty normatywne świadczeń z modułu Wycena Kosztów Normatywnych eksportowane są do modułu Rachunek Kosztów. Zadekretowane dokumenty przychodowe, rozchodowe oraz pozostałe 9. zawarte w module Gospodarka materiałowa wymieniane są z modułem Finanse-Księgowość. Z modułu Apteka / apteczka oddziałowa jakie obecnie posiada 10. zamawiający, przekazywane są automatycznie zadekretowane dokumenty przychodowe, rozchodowe oraz pozostałe do modułu Finanse-księgowość. Eksport danych statystycznych oraz ilościowych o wykonanych 11. świadczeniach do pliku tekstowego lub w formacie.xls z możliwością zaczytania do modułu Rachunek Kosztów, Wymiana danych z systemu Apteka z modułem Wycena Kosztów 12. 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). Moduł Apteczka oddziałowa udostępnia automatycznie dane o ewidencji 13. podania leków poszczególnym pacjentom do modułu Kalkulacja Kosztów Leczenia 14. Automatyczne przekazywanie rozchodów leków z Apteczki oddziałowej do modułu Finanse-Księgowość 15. Zadekretowane listy płac z modułu na poziomie bazy danych przekazywane są do modułu Koszty. Istnieje wymiana informacji pomiędzy Apteką a modułem Finansowoksięgowym 16. w zakresie przyjętych towarów, faktur zakupowych, a także rozchodów na ośrodki kosztów, z zachowaniem charakterystyki kont księgowych. 17. Automatyczna synchronizacja słowników kontrahentów, odbiorców, nr ośrodków kosztowych, pomiędzy systemem Finanse-Księgowość a Apteka. Możliwość zlecania z Ruchu chorych tj. z oddziału/izby przyjęć oraz gabinetu lekarskiego: 18. podania leku / kroplówki / chemioterapii, zabiegu, badania diagnostycznego, konsultacji, diety; wystawienie zlecenia powinno nieść kompletne informacje, niezbędne do jego wykonania; 19. 20. 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. Możliwość automatycznego wydruku skierowania na podstawie wystawionego zlecenia/zestawu zleceń.

Strona4 21. Możliwość zlecania/odbierania wyników badań laboratoryjnych, diagnostycznych poprzez protokół HL7. 22. Zakażenia Szpitalne - możliwość ewidencji karty zakażenia bezpośrednio z poziomu modułu Ruch Chorych,. 23. Z modułu Przychodnia Gabinet możliwość kierowania pacjenta bezpośrednio na izbę przyjęć w module Ruch Chorych Z modułu Przychodnia Gabinet możliwość walidacji, czy pacjent 24. zgłaszający się do gabinetu nie ma obecnie aktywnego pobytu na oddziale w module Ruch chorych W module Gabinet, odnotowanie podania leku/szczepionki z 25. automatycznym pomniejszeniem stanów magazynowych apteczki podręcznej W modułach Ruch chorych(izba przyjęć, oddział), Gabinet, Pracownia 26. Diagnostyczna czy Blok operacyjny powinien być wgląd we wcześniejsze pobyty pacjenta we wszystkich jednostkach szpitala. W modułach Ruch Chorych (Izba Przyjęć, ), Gabinet, Pracownia Diagnostyczna czy Blok Operacyjny powinien być możliwy wgląd do 27. wyników badań pacjenta, wykonanych zarówno podczas aktualnego pobytu, jak i wcześniejszych pobytów również w innych jednostkach organizacyjnych szpitala. Możliwość dowolnej rozbudowy modułów Blok Operacyjny, Zakażenia 28. Szpitalne, Ruch Chorych, o wybrane formularze, wykorzystując dane z modułu Dokumentacja Medyczna Z modułu Przychodnia możliwość planowania/realizacji wizyty 29. komercyjnej, automatycznego generowania dokumentu sprzedaży, walidacji sprzedaży, wystawiania zaświadczenia o płatności. I Automatyczne przesyłanie danych do modułu Finansowo Księgowego System ma mieć możliwość obsługi funkcjonalności Indywidualnego Konta 30. Pacjenta. Personel planujący/realizujący wizytę ma mieć wgląd w informacje o saldzie konta pacjenta w tym do informacji o niedozwolonym zadłużeniu. Z modułu Finansowo-Księgowego możliwość automatycznego 31. przydzielania numeracji faktur sprzedażowych realizowanych w ramach modułów Przychodnia, Sprzedaż Usług Medycznych: Umowy komercyjne i Ruch chorych w tym rozliczenia i statystyka medyczna Z modułu Pracownia Diagnostyczna możliwość ewidencji i wgląd w listę 32. bieżących hospitalizacji dla pacjentów hospitalizowanych na oddziałach tj. w module Ruch Chorych jaki obecnie posiada zamawiający Z modułu Sprzedaż Usług Medycznych: Umowy NFZ możliwość 33. automatycznego tworzenia zestawienia do NFZ faktur zakupowych za leki chemioterapii/programów lekowych na podstawie ewidencji faktur zakupowych w module Apteka jaki obecnie posiada zamawiający Możliwość przesłania danych o jednostkowych kosztach osobodni oraz 34. procedur medycznych z modułu Rachunku Kosztów do modułu Kalkulacji Kosztów Leczenia Pacjenta, 4) W przypadku braku możliwości spełnienia powyższych wymagań (np. z powodu braku odpowiedniej wiedzy nt. struktury bazy danych systemu InfoMedica) Zamawiający dopuszcza zastosowanie rozwiązania zastępczego, poprzez wymianę istniejącego systemu na inny, co najmniej w zakresie wymagań określonych w punkcie 3.7 załącznika nr.1 do Specyfikacji Warunków Zamówienia Publicznego. Pełne wdrożenie wymienianej

Strona5 części systemu InfoMedica musi zakończyć się nie później niż 3 miesiące od dnia podpisania umowy. Usługi związane z wymianą istniejącego systemu na inny obejmujące: instalację oprogramowania aplikacyjnego oraz wdrożenie oprogramowania aplikacyjnego (w tym szkolenie użytkowników i wizyty konsultacyjne przy i po uruchomieniu oprogramowania) nie mogą być mniejszej niż 500 roboczodni (1 roboczodzień ~ 7h pracy jednego pracownika Oferenta w szpitalu). Zestawienie posiadanego przez Zamawiającego oprogramowania aplikacyjnego InfoMedica: w części administracyjnej (szarej): Lp Moduł Wytwórca produktu Ilość licencji (nazwanych użytkowników) 1 Finanse i Księgowość Asseco Poland S.A. 7 2 Rachunek Kosztów Asseco Poland S.A. 2 3 Rejestr Sprzedaży Asseco Poland S.A. 4 4 Kasa Asseco Poland S.A. 3 5 Wycena Kosztów Normatywnych Asseco Poland S.A. 2 6 Kalkulacja Kosztów Leczenia Asseco Poland S.A. 2 7 Asseco Poland S.A. 6 8 Asseco Poland S.A. 4 9 Grafiki Asseco Poland S.A. 23 10 Gospodarka Materiałowa Asseco Poland S.A. 5 11 Środki Trwałe Asseco Poland S.A. 3 12 Wyposażenie Asseco Poland S.A. 2 w części medycznej (białej) HIS: Ilość licencji Lp Moduł Wytwórca produktu (nazwanych użytkowników) licencja otwarta na Ruch Chorych ( w tym: izby przyjęć, 1 Asseco Poland S.A. nieograniczoną ilość oddziały, statystyka) użytkowników 2 Apteka Asseco Poland S.A. 8 3 Apteczka owa Asseco Poland S.A. 35 4 Przychodnia (w tym: rejestracja, gabinety, statystyka) Asseco Poland S.A. 33 5 Pracownia Diagnostyczna Asseco Poland S.A. licencja otwarta na nieograniczoną ilość użytkowników 6 Blok Operacyjny Asseco Poland S.A. 15 7 Zlecenia Asseco Poland S.A. 44 8 Dokumentacja Medyczna Asseco Poland S.A. 50 (licencja na ilość formularzy) 9 Zakażenia szpitalne Asseco Poland S.A. 2 licencja otwarta na 10 Symulator JGP Asseco Poland S.A. nieograniczoną ilość użytkowników Sprzedaż Usług Medycznych: licencja otwarta na 11 Umowy NFZ (w tym: Gruper JGP, Kolejki Oczekujących) Asseco Poland S.A. nieograniczoną ilość użytkowników Zamawiający wymaga też przeniesienia wszystkich danych z systemu InfoMedica, w tym:

Strona6 Część biała: dane pacjentów wraz z całą historią pobytów, dane rozliczeniowe z ostatnich 5 lat (tak aby możliwe były korekty rozliczeń w nowym systemie), dane słownikowe (usługi, zlecenia), wszystkie szablony pism zdefiniowane w systemie InfoMedica muszą zostać odwzorowane w nowym systemie, wszystkie formularze dokumentacji medycznej zdefiniowane w systemie InfoMedica muszą zostać odwzorowane w nowym systemie. Część szara: Dane kadrowo płacowe wszystkie zapisy chronologiczne (umowy, dane pracowników, etatów, stawek. Dane FKK plan kont, baza kontrahentów, bilans otwarcia dla kont, rozrachunki, dekrety (muszą zostać migrowane zgodnie z chronologią powstawania w starym systemie). Zamawiający wymaga w nowym systemie aby z końcem 2013r. automatycznie przygotował on PIT-y za pełen rok 2013 dla wszystkich pracowników szpitala. Zamawiający zapewni dostęp do posiadanego przez niego systemu InfoMedica oraz wszelkie informacje będące w jego posiadaniu, niezbędne do migracji wyżej wymienionych danych. Zamawiający wymaga również integracji z posiadanym systemem Laboratorium firmy Roche według standardu HL7. Integracja z LIS Integracja z wykorzystaniem standardy HL7 Dane przesyłane z systemu HIS: - dane personalne pacjentów (nazwisko, imię, PESEL, miejsce zamieszkania) - dane zlecenia (numer zlecenia, techniczny identyfikator zlecenia, jednostka zlecająca, lekarz zlecający) - dane badania (kod i nazwa badania) Dane przesyłane z systemu LIS: - treść wyniku, dane osoby wykonującej, dane osoby autoryzującej, kod badania, nazwa badania 5) Usługi obejmujące instalację oprogramowania aplikacyjnego HIS oraz wdrożenie oprogramowania aplikacyjnego (w tym szkolenie użytkowników i wizyty konsultacyjne przy i po uruchomieniu oprogramowania) w ilości łącznej nie mniejszej niż 280 roboczodni (1 roboczodzień ~ 7h pracy jednego pracownika Oferenta w szpitalu). 6) Objęcie nadzorem autorskim oprogramowania aplikacyjnego HIS przez okres 2 lat od daty podpisania umowy realizacyjnej w ramach zakupionych licencjach. 7) W związku z posiadanymi przez w Olsztynie: ISO 9001:2008 System Zarządzania Jakością ISO 14001:2004 System Zarządzania Środowiskowego PN-N 18001:2004 System Zarządzania Bezpieczeństwem i Higieną Pracy ISO 27001:2005 System Zarządzania Bezpieczeństwem Informacji oraz Certyfikat Akredytacyjny Certyfikat Nr 2011/25, który potwierdza spełnienie przez w Olsztynie standardów akredytacyjnych dla lecznictwa szpitalnego, data przyznania 29.09.2011r. Szpital otrzymał status Szpitala Akredytowanego na okres trzech lat, przyznawany przez Ministra Zdrowia po uzyskaniu rekomendacji Centrum Monitorowania jakości w Ochronie Zdrowia - Kraków - wykonawców obowiązują z tego tytułu wszystkie uregulowania obowiązujące Zamawiającego w powyższym zakresie. 8) Wykonawca wybrany do realizacji niniejszego zamówienia zobowiązany jest do oznaczenia dostarczanych dokumentów i urządzeń logo Unii Europejskiej oraz logo Narodowych Strategicznych Ram Odniesienia 2007-2013.

Strona7 2. DOSTAWĘ, INSTALACJĘ I WDROŻENIE SPRZĘTU NIEZBĘDNEGO DO REALIZACJI POZOSTAŁYCH PUNKTÓW ZAMÓWIENIA wg parametrów podanych w załączniku nr 1 Pozycja Ilość Serwery Blade typ I 2 Serwery Blade typ II 2 Serwery Blade typ III 4 Kompletny system backupowy z deduplikacją na źródle, serwer do backup'u + medium backup'owe z replikacją do ośrodka zapasowego (Pojemność 3,9 TB z licencją na 2 TB po deduplikacji i replikacja na 1 drugi system o pojemności 1,3 TB) Macierz dyskowa 12 x 600GB 15K SAS DISK DRIVE, 16 GB cache 1 Półka do Macierzy dyskowej z 12 dyskami 1 TB SATA 1 Infrastruktura Blade 1 Infrastruktura Blade - przełączniki 4 Infrastruktura Blade - przełączniki FC 2 Rack UPS 2 Oprogramowanie systemowe Systemy operacyjne dla serwerów 5 Licencje dostępowe sieciowego systemu operacyjnego 100 Licencje dostępowe terminalowe sieciowego systemu operacyjnego 100 Oprogramowanie bazodanowe 4 licencje 1 Oprogramowanie do wirtualizacji 1 Terminal bezdyskowy z systemem operacyjnym z Internal Wireless 48 (802.11B/G/N) Terminal medyczny 2 Monitor 22" 20 Monitor 19 50 Monitor LCD 42" 1 Komputery PC 20 Wdrożenie Instalacja i konfiguracja dostarczonego sprzętu komputerowego i oprogramowania 1 3. DOSTAWĘ, INSTALACJĘ I WDROŻENIE URZĄDZEŃ PRZEZNACZONYCH DLA DIAGNOSTYCZNEJ PRACOWNI OBBRAZOWEJ wg parametrów podanych w załączniku nr 1 4. DOSTAWĘ, INSTALACJĘ I WDROŻENIE SYSTEMU PACS DLA DIAGNOSTYCZNEJ PRACOWNI OBBRAZOWEJ wg parametrów podanych w załączniku nr 1

Strona8 I. Termin realizacji przedmiotu zamówienia Przedmiot zamówienia musi być zrealizowany do 31.10.2013 roku.

Strona9 Załącznik nr 1 do Specyfikacji Istotnych Warunków Zamówienia Publicznego... pieczęć oferenta Wymagane funkcje systemu 1. Wymagania stawiane systemowi: W kolumnie Spełnia w poniższych tabelach należy odpowiedzieć: TAK lub NIE w zależności od spełnienia wymogu przez oferowany system. Brak odpowiedzi uznaje się za niespełnienie danego wymagania. Wszystkie wymagania zamieszczone poniżej są obligatoryjne. Nie spełnienie któregokolwiek wymagania, wpisanie NIE lub pozostawienie pola pustego, jest jednoznaczne z nie spełnieniem wymagań SIWZ i skutkuje odrzuceniem oferty. Wpisanie słowa TAK oznacza, że funkcjonalność wymagana istnieje i jest zaimplementowana na dzień składania oferty. Zamawiający po złożeniu ofert przez Oferentów zastrzega sobie możliwość weryfikacji spełnienia przez oferowane programy wymogów postawionych w SIWZ a zwłaszcza funkcjonalności wykazanych w załączniku nr 1 w SIWZ poprzez prezentację oprogramowania w siedzibie Zamawiającego. Uwaga: Ewentualne stwierdzenie przez komisję przetargową w trakcie weryfikacji oprogramowania aplikacyjnego braku choćby jednej funkcjonalności lub parametru technicznego, mimo wykazania go przez Oferenta w załączniku nr 1 SIWZ, skutkować będzie odrzuceniem oferty danego Oferenta. 2. Wymagania ogólne dotyczące oprogramowania aplikacyjnego HIS: Wymaganie 1. Producent oprogramowania aplikacyjnego HIS musi spełniać określone wymogi jakościowe co najmniej w zakresie projektowania i wytwarzania oprogramowania, np.: certyfikat ISO 9001:2008 lub równoważny. Należy załączyć odpowiednie zaświadczenie podmiotu uprawnionego do kontroli jakości, potwierdzające powyższe wymaganie. 2. Podmiot świadczący usługi wdrożenia i serwisu oprogramowania aplikacyjnego HIS musi spełniać określone wymogi jakościowe co najmniej w zakresie wdrażania oprogramowania oraz świadczenia do nich usług serwisowych, np.: certyfikat ISO 9001:2008 lub równoważny. Należy załączyć odpowiednie zaświadczenie podmiotu uprawnionego do kontroli jakości, potwierdzające powyższe wymaganie. 3. Oferent musi posiadać Audytora Wiodącego według ISO 9001:2008 (certyfikat rejestrowany w Międzynarodowym Rejestrze Certyfikowanych Auditorów IRCA lub równoważny) do prowadzenia i audytowania projektów informatycznych. Należy załączyć odpowiednie zaświadczenie podmiotu uprawnionego do kontroli jakości, potwierdzające powyższe wymaganie. 4. 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: Spełnia (należy wpisać TAK lub NIE)

Strona10 5. 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) 6. 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) 7. 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 8. 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). 9. 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) 10. 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 11. 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: o dacie wprowadzenia danych osobowych o identyfikator użytkownika wprowadzającego dane osobowe o źródło danych (o ile dane nie pochodzą od osoby, której te dane dotyczą) o informacje o odbiorcach danych którym dane osobowe zostały udostępnione, o dacie i zakresie tego udostępnienia o data modyfikacji danych osobowych o identyfikator operatora modyfikującego dane 12. 13. 14. 15. 16. Przewidywana ilość roboczodni (1 roboczodzień ~ 7 godzin pracy 1 pracownika Oferenta w szpitalu) przeznaczonych na usługi instalacyjno-szkoleniowo-wdrożeniowe oprogramowania aplikacyjnego HIS w szpitalu nie może być mniejsza niż 280 roboczodni. W ramach kupowanych licencji na system HIS Oferent gwarantuje objęcie nadzorem autorskim oprogramowania aplikacyjnego przez okres 2 lat od daty podpisania umowy realizacyjnej. System pracuje w środowisku graficznym MS Windows na stanowiskach użytkowników. (preferowane środowisko MS Windows XP/Vista/Windows 7) Wszystkie moduły systemu HIS działają w oparciu o jeden motor bazy danych. Oferowane moduły muszą współpracować z funkcjonującym u Zamawiającego

Strona11 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. systemem InfoMedica w taki sposób aby dane raz wprowadzone były natychmiast widoczne w każdym miejscu systemu. Wymiana informacji między modułami nie może wymagać ingerencji użytkownika lub administratora. Musi odbywać się automatycznie. Dostarczone oprogramowanie musi zagwarantować integrację z systemem InfoMedica działającym u Zamawiającego. Przekazywanie danych musi odbywać się automatycznie i na bieżąco bez konieczności wykonywania dodatkowych operacji przez użytkownika lub administratora 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 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). 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). System jest wykonany w technologii dwu lub wielowarstwowej, dane są przechowywane w modelu relacyjnym baz danych z wykorzystaniem aktywnego serwera baz danych. 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 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 najważniejsze czynności z możliwością analizy historii zmienianych wartości danych. 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 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. 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

Strona12 30. 31. 32. 33. 34. 35. umożliwiać definiowanie grup uprawnień, które to mogłyby być przydzielane poszczególnym użytkownikom. 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 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. Jednokrotne logowanie do systemu umożliwiające dostęp do wszystkich modułów, do których użytkownik posiada uprawnienia łącznie z aktualnie posiadanymi modułami InfoMedica. Możliwość uruchomienia kolejnej aplikacji bez konieczności wylogowywania się z dotychczas używanej aplikacji i ponownego logowania. 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. Dostęp do pulpitu użytkownika powinien być zabezpieczony hasłem. 36. Interfejs użytkownika jest dostępny z poziomu przeglądarki internetowej i nie wymaga instalowania żadnego 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). Na dzień złożenia ofert musi być dostęp do aplikacji przez WWW, co najmniej, w zakresie Przychodnia (Rejestracja, Gabinet, Statystyka) i RIS Pracowania Diagnostyczna. W związku z tym, te systemy powinny realizować także następujące funkcje: 37. System musi umożliwić pracę z poziomu najbardziej popularnych przeglądarek, co najmniej MS Internet Explorer i Mozilla Firefox. 38. System musi umożliwić uruchomienie aplikacji w wersji desktop 39. System w części medycznej musi umożliwić pracę na tabletach medycznych lub komputerach wyposażonych w monitory dotykowe. Pełna funkcjonalność modułów powinna być dostępna na komputerach tego typu. 40. Wyróżnienie pól: - których wypełnienie jest wymagane, - przeznaczonych do edycji, - wypełnionych niepoprawnie 41. System musi umożliwiać obsługę kodów 2D do rejestracji skierowań pochodzących z innych zakładów opieki 42. 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. 43. 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. 44. 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

Strona13 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. 45. Zmiana danych pacjenta powinna zostać zarejestrowana w historii zmian. Dokumentacja medyczna znajdująca się w systemie dotyczące okresu sprzed zmiany powinny zawierać wcześniejsze dane (np. nazwisko sprzed zmiany). 46. System powinien umożliwiać wyszukiwanie pacjentów po wcześniejszych nazwiskach, np. wcześniejsze nazwisko kobiety. 47. System musi umożliwić harmonogramowanie eksportów danych: o wyznaczonej godzinie, co określoną liczbę godzin, za określoną liczbę godzin 48. System musi umożliwić skanowanie danych z dokumentów np. dowodów osobistych i na tej podstawie dokonywanie automatycznej identyfikacji pacjenta 49. System umożliwia rejestrację i przechowywanie, w kartotece pacjenta, informacji dotyczących dokumentów potwierdzających uprawnienia do realizacji świadczeń 50. System działa w architekturze trójwarstwowej 3. Wymagania funkcjonalne systemu HIS 3.1 Szpitalny portal informacyjny: e-pacjent Wymaganie 1. Rejestracja nowego pacjenta użytkownika systemu. Spełnia (należy wpisać TAK lub NIE oraz nazwę produktu i jego producenta) 2. Potwierdzenie rejestracji pacjenta poprzez wprowadzenie kodu udostępnionego przez SMS. 3. Potwierdzenie rejestracji pacjenta poprzez wprowadzenie kodu udostępnionego przez e-mail. 4. Możliwość samodzielnej autoryzacji (określenie danych dostępowych login/hasło) użytkownika pacjenta po poprawnym potwierdzeniu rejestracji; możliwość wyłączenia trybu samodzielnej autoryzacji pacjentów. 5. Możliwość ograniczenia samodzielnej autoryzacji użytkowników pacjentów do osób zarejestrowanych w zintegrowanym systemie HIS oraz systemie InfoMedica (na podstawie zgodności numeru PESEL i nazwiska); możliwość wyłączenia trybu autoryzacji pacjentów w oparciu o rejestr zintegrowanego systemu HIS oraz systemu InfoMedica. 6. Logowanie pacjenta/użytkownika autentykacja użytkownika systemu. 7. Aktualizacja profilu pacjenta/użytkownika SPI; możliwość aktualizacji danych kontaktowych: adresu e-mail, nr-telefonu; adresu zamieszkania. 8. Możliwość określenia przez parametrów powiadomień o zbliżającym się terminie udzielenia usługi (interwał czasu przed planowanym terminie, tryb powiadamiania) zdefiniowanych w systemie jako możliwe do ustawienia przez użytkownika/pacjenta. 9. Możliwość zmiany hasła pacjenta użytkownika SPI.

Strona14 10. Możliwość ustawienia nowego hasła, po poprawnej weryfikacji adresu e-mail lub numeru telefonu poprzez wprowadzenie przesłanego kodu potwierdzenia. 11. Rezerwacja terminu udzielenia usługi wskazanie daty i czasu planowanej realizacji wizyty, miejsca realizacji (element struktury organizacyjnej) i personelu realizującego (opcjonalnie; w zależności od statusu wyboru personelu zdefiniowanego dla usługi). 12. Możliwość/konieczność rejestracji danych skierowania w czasie rezerwacji terminu udzielenia dla usług o odpowiednim statusie wymagalności danych skierowania. 13. Grupowanie usług do rezerwacji wg zdefiniowanych rodzajów usług. 14. Grupowanie usług wg zawodu personelu realizującego (np. lekarze, lekarze-dentyści, fizjoterapeuci). 15. Przegląd rejestru rezerwacji wizyt pacjenta z wyróżnieniem stanu usługi (planowana, zrealizowana, anulowana). 16. Możliwość anulowania przez pacjenta rezerwacji wizyty. 17. Możliwość zmiany terminu wizyty przez pacjenta. 18. Wydruk potwierdzenia rezerwacji wizyty zawierający informacje o usłudze, miejscu realizacji oraz planowaną datę udzielenia usługi. 19. Możliwość wysyłania przez SMS, e-mail lub wiadomości na portalu pacjenta przypomnień o zbliżających się terminach wizyt. 20. Możliwość wysyłania przez SMS, e-mail lub wiadomości na portalu pacjenta powiadomień o anulowaniu rezerwacji przez pracowników jednostki ochrony zdrowia. 21. Możliwość wysyłania przez SMS, e-mail lub wiadomości na portalu pacjenta powiadomień o zmianie terminu realizacji usługi dokonanej przez pracowników jednostki ochrony zdrowia. 22. Wysyłanie wiadomości do jednostki ochrony zdrowia; możliwość formatowania treści wiadomości (czcionka, kolor, justowanie, odnośniki do innych stron). 23. Przegląd wysłanych wiadomości; wyróżnienie wiadomości nieprzeczytanych; wyszukiwanie wiadomości wg tematu, daty wysłania i odbiorcy. 24. Edycja wysłanych i jeszcze nieprzeczytanych przez pracowników jednostki ochrony zdrowia wiadomości. 25. Przegląd wiadomości odebranych od pacjentów; wyszukiwanie wiadomości wg tematu, daty wysłania, nadawcy; wyróżnienie wiadomości nieprzeczytanych. 3.2 Szpitalny portal informacyjny: e-kontrahent Wymaganie 1. Rejestracja personelu kontrahenta użytkowników SPI. Spełnia (należy wpisać TAK lub NIE oraz nazwę produktu i jego producenta) 2. Aktualizacja danych personelu kontrahenta. 3. Rejestracja pacjentów związanych z kontrahentem. 4. Przegląd usług realizowanych w Jednostce Ochrony Zdrowia na rzecz kontrahenta wraz z harmonogramami realizacji usług. 5. Rezerwacja terminu udzielenia usługi dla wskazanego pacjenta kontrahenta.

Strona15 6. Anulowanie rezerwacji terminu udzielenia usługi medycznej. 7. Zmiana planowanego terminu realizacji usługi medycznej dla wskazanej rezerwacji. 8. Przegląd rezerwacji terminów udzielenia usług medycznych z wyróżnieniem stanu rezerwacji (planowane, zrealizowane, anulowane). 9. Wydruk potwierdzenia rezerwacji terminu udzielenia usług medycznych. 10. Możliwość rejestracji zlecenia wykonania badań; rejestracja danych skierowania na badania: instytucja kierująca, lekarz kierujący. 11. Możliwość rejestracji danych o pobraniu materiałów do zleconych badań. 12. Możliwość wydruku potwierdzenia zlecenia badań. 13. Przegląd zarejestrowanych zleceń wykonania badań z wyróżnieniem stanu realizacji badania (zarejestrowane/zlecone/w trakcie realizacji/zrealizowane/anulowane). 14. Wydruk raportu prezentującego liczby zrealizowanych usług w określonym czasie. 15. Wydruk raportu zestawienia usług zrealizowanych na rzecz danego kontrahenta w określonym czasie. Konfigurator i Administrator dla e-pacjent i e-kontrahent Wymaganie 1. Rejestracja struktury organizacyjnej Jednostki Ochrony Zdrowia w układzie hierarchicznym, w postaci interaktywnego diagramu. 2. Możliwość rejestracji i prezentacji formatowanych opisów jednostek organizacyjnych. Spełnia (należy wpisać TAK lub NIE) 3. Możliwość rejestracji godzin pracy jednostek organizacyjnych; możliwość przepisania godzin pracy z informacji zarejestrowanych dla jednostki nadrzędnej. 4. Integracja rejestru struktury organizacyjnej z odpowiadającym rejestrem HIS (ang. Hospital Information System) oraz systemem InfoMedica. 5. Publikacja informacji o elementach struktury organizacyjnej szpitala na Szpitalnym Portalu Informacyjnym. 6. Publikacja informacji o elementach struktury organizacyjnej szpitala na platformie internetowej. 7. Rejestracja informacji o personelu realizującym usługi medyczne; rejestracja informacji o grupach zawodowych i specjalnościach personelu. 8. Rejestracja informacji o godzinach pracy personelu (harmonogramach pracy personelu). 9. Integracja rejestru personelu z odpowiadającym rejestrem HIS oraz systemem InfoMedica. 10. Publikacja informacji o personelu na Szpitalnym Portalu Informacyjnym. 11. Rejestracja informacji o usługach realizowanych w Jednostce Ochrony Zdrowia; rejestracja opisów usługi w postaci formatowanych tekstów; rejestracja informacji o wymagalności skierowania. 12. Definiowanie rodzajów świadczonych usług, przypisywanie usług do zdefiniowanych rodzajów.

Strona16 13. Definiowanie statusu wyboru personelu dla definiowanych usług (wybór personelu dopuszczalny, niemożliwy, wymagany). 14. Definiowanie wymagalności skierowania do realizacji usługi; określenie możliwości lub konieczności rejestracji danych skierowania w czasie rezerwacji terminu udzielenia usługi. 15. Rejestracja informacji o szczególnych warunkach udzielania usług (zalecenia dla pacjentów odnośnie realizacji usługi) w postaci formatowanych tekstów. 16. Rejestracja informacji o dokumentach (załącznikach) związanych z definiowaną usługą. 17. Integracja rejestru usług medycznych z odpowiadającym rejestrem w HIS oraz systemem InfoMedica; powiązanie usług zdefiniowanych w portalu z usługami w HIS oraz systemem InfoMedica; przepisywanie wybranych usług z HIS oraz systemu InfoMedica do rejestru portalu. 18. Publikacja informacji o usługach na Szpitalnym Portalu Informacyjnym. 19. Wskazanie usług, dla których możliwa jest rezerwacja terminu udzielania usług w module e-pacjent. 20. Rejestracja usług zlecanych stanowiących grupy badań dostępnych dla kontrahenta; przypisanie badań do usług zlecanych. 21. Rejestracja informacji o dokumentach (załącznikach) wymaganych do udzielenia usług; możliwość dołączenia pliku załącznika. 22. Wskazanie usług, dla których wymagany jest dostarczenie wskazanych dokumentów (załączników). 23. Rejestracja informacji o dostępności elementów struktury organizacyjnej Jednostek Ochrony Zdrowia; podpowiadanie definicji harmonogramów pracy jednostki na podstawie godzin otwarcia jednostki. 24. Rejestracja przerw w dostępności elementów struktury organizacyjnej Jednostek Ochrony Zdrowia. 25. Rejestracja informacji o dostępności usług w jednostkach organizacyjnych szpitala na postawie zdefiniowanej wcześniej dostępności jednostek organizacyjnych. 26. Możliwość definiowania parametrów rezerwacji dla usług dostępnych w jednostkach organizacyjnych: maksymalna liczba jednoczasowych rezerwacji tego samego pacjenta; minimalny interwał czasu pomiędzy datą rejestracji a datą realizacji usługi; maksymalny okres czasu względem daty rezerwacji, w którym możliwe jest określenie planowanego terminu udzielenia usługi. 27. Rejestracja informacji o dostępności usług w jednostkach organizacyjnych szpitala na postawie harmonogramu; podpowiadanie definicji harmonogramu na podstawie godzin otwarcia jednostki; możliwość rejestracji ciągłej dostępności usług w jednostkach organizacyjnych. 28. Rejestracja informacji o dostępności personelu na podstawie harmonogramu; podpowiadanie harmonogramów dla personelu na podstawie godzin pracy zdefiniowanych w rejestrze personelu. 29. Rejestracja informacji o dostępności usług udzielanych przez określony personel na podstawie zdefiniowanej wcześniej dostępności personelu. 30. Rejestracja informacji o dostępności usług udzielanych przez określony personel na podstawie harmonogramów; podpowiadanie harmonogramów na podstawie godzin pracy personelu. 31. Możliwość dowolnej modyfikacji definiowanych dostępności: usuwanie dostępnych okresów; modyfikacja dat dostępnych okresów; dodawanie nowych okresów dostępności. 32. Definiowanie klas pacjentów użytkowników modułu e-pacjent.

Strona17 33. Definiowanie parametrów rezerwacji dla poszczególnych klas pacjentów: maksymalnej liczby rezerwacji terminów udzielenia usługi dostępnych dla pacjentów określonej klasy; maksymalny okres rezerwacji terminów udzielenia usług; tryb potwierdzenia rezerwacji (bez potwierdzenia/potwierdzenie e-mail/potwierdzenie SMS). 34. Możliwość określenia sposobu powiadamiania pacjentów określonej klasy o anulowaniu rezerwacji w jednostce ochrony zdrowia (brak powiadomień, powiadomienie SMS, powiadomienie e-mail). 35. Możliwość określenia sposobu powiadamiania pacjentów określonej klasy o zmianie planowanego terminu udzielenia usługi w jednostce ochrony zdrowia (brak powiadomień, powiadomienie SMS, powiadomienie e-mail). 36. Możliwość określenia sposobu powiadamiania pacjentów określonej klasy o potwierdzeniu planowanego terminu udzielenia usług w zintegrowanym systemie HIS (brak powiadomień, powiadomienie SMS, powiadomienie e-mail). 37. Możliwość określenia sposobu powiadamiania pacjentów określonej klasy o potwierdzeniu planowanego terminu udzielenia usług w zintegrowanym systemie HIS (brak powiadomień, powiadomienie SMS, powiadomienie e-mail). 38. Możliwość określenia sposobu powiadamiania pacjentów określonej klasy o zbliżającym się terminie udzielenia usługi (brak powiadomień, powiadomienie SMS, powiadomienie e-mail), możliwość określenia interwału czasu przed planowanym terminem udzielenia usługi, kiedy zostanie wysłane powiadomienie; możliwość definiowania wielu powiadomień o zbliżającym się terminie udzielenia usługi dla danej rezerwacji. 39. Możliwość definiowania uprawnień do modułu e-pacjent dla pacjentów określonej klasy; integracja uprawnień do modułu e-pacjent z uprawnieniami zarządzanymi w administratorze systemu. 40. Przegląd pacjentów zarejestrowanych w Szpitalnym Portalu Informacyjnym. 41. Zatwierdzenie zarejestrowanych pacjentów jako użytkowników Szpitalnego Portalu Informacyjnego przez pracowników szpitala (autoryzacja przez pracowników szpitala). 42. Rejestracja pacjentów jak użytkownika Szpitalnego Portalu Informacyjnego przez pracowników szpitala możliwość udostępnienia funkcjonalności e-pacjent bez konieczności rejestrowania się pacjenta na stronie internetowej. 43. Integracja rejestru pacjentów z odpowiadającym rejestrem w HIS oraz systemem InfoMedica; możliwość wyszukiwania pacjentów zarejestrowanych wg identyfikatora w systemie HIS oraz systemie InfoMedica. 44. Rejestracja kontrahenta obsługiwanego w Szpitalnym Portalu Informacyjnym 45. Rejestracja pracowników kontrahenta użytkowników Szpitalnego Portalu Informacyjnego; przydzielanie uprawnień pracownikom kontrahenta. 46. Rejestracja pacjentów powiązanych z danym kontrahentem. 47. Import danych pacjentów związanych z kontrahentem z pliku zewnętrznego (plik csv o określonym formacie). 48. Rejestracja umów zawartych z kontrahentem. 49. Rejestracja usług realizowanych na rzecz danego kontrahenta na podstawie określonej umowy; możliwość rejestracji ilościowych limitów usług. 50. Rejestracja dostępności usług w ramach określonych umów zawartych z kontrahentem. 51. Integracja rejestru kontrahentów z odpowiadającym rejestrem HIS oraz systemem InfoMedica. 52. Wysyłanie wiadomości do pacjentów zarejestrowanych w SPI (wiadomości powinny być prezentowane w module e-pacjent); wysyłanie wiadomości do wszystkich pacjentów; wysyłanie wiadomości do wybranych pacjentów; wysyłanie komunikatów wiadomości, na które nie można odpowiadać; możliwość formatowania treści wiadomości (czcionka,

Strona18 kolor, justowanie, odnośniki do innych stron). 53. Możliwość wysyłania wiadomości e-mail do pacjentów użytkowników portalu. 54. Możliwość wysyłania wiadomości SMS do pacjentów użytkowników portalu. 55. Przegląd wysłanych wiadomość; wyróżnienie wiadomości nieprzeczytanych; wyszukiwanie wiadomości wg tematu, daty wysłania i odbiorcy. 56. Edycja nieprzeczytanych, wysłanych wiadomości. 57. Logiczne usunięcie wiadomości oznaczenie wiadomości jako usuniętej niewidocznej dla adresatów. 58. Przegląd wiadomości odebranych od pacjentów; wyszukiwanie wiadomości wg tematu, daty wysłania, nadawcy; wyróżnienie wiadomości nieprzeczytanych. 59. Zgodność koncepcji mechanizmu kontroli dostępu do funkcji systemu z RBAC (ang. Role-based Access Control). 60. Definiowanie nowego użytkownika. 61. Przegląd i modyfikacja danych użytkowników. 62. Tworzenie grup użytkowników; przyporządkowanie użytkowników do grup. 63. Przydzielanie uprawnień i ról użytkownikom i grupom użytkowników. 64. Przegląd efektywnych uprawnień użytkownika wynikających z przynależności do grup użytkowników, przypisanych ról i praw. 65. Możliwość przydzielania uprawnień do zmieniających się w czasie zasobów. 66. Definiowanie polityk poziomu bezpieczeństwa hasła użytkownika, możliwość przypisania wskazanych polityk do użytkowników. 67. Kontrola złożoności hasła użytkownika zgodnie z przypisaną polityką poziomu bezpieczeństwa. 68. Dostępność interfejsu umożliwiającego integrację użytkowników z dotychczas użytkowanym systemem (interfejsy na poziomie bazy danych i języków wysokiego poziomu). 69. Dostępność interfejsu do kontroli praw przyznanych użytkownikom (interfejsy na poziomie bazy danych i języków wysokiego poziomu). 70. Dostępność interfejsu do zarządzania prawami przyznanych użytkownikom (interfejsy na poziomie bazy danych i języków wysokiego poziomu). 71. Użytkownicy systemu nie odpowiadają bezpośrednio użytkownikom systemu zarządzania bazą danych. 72. Możliwość delegowania uprawnień do administrowania uprawnieniami w poszczególnych podsystemach. 73. Szpitalny portal informacyjny: analizy dla e-pacjent i e-kontrahent oraz HIS dla 15 wybranych użytkowników (pracowników szpitala): 74. Porównywanie i analiza danych pochodzących z wszystkich systemów HIS oraz systemu InfoMedica, w oparciu o hurtownie danych 75. Możliwość definiowania własnych analiz opartych o gromadzone dane z systemów medycznych i administracyjnych 76. Tworzenie raportów on-line w oparciu o dane aktualne 77. Graficzna prezentacja wyników 78. Raporty medyczne:

Strona19 79. Grafik personelu, 80. Utylizacja zasobów oddziały, 81. Utylizacja zasobów przychodnia, 82. Utylizacja zasobów pracownie diagnostyczne, 83. Utylizacja zasobów laboratoria. 84. Raporty administracyjne: 85. Grupy personelu, 86. Wykaz stanu kont, 87. Plan i wykonanie kosztów OPK, 88. Wskaźniki płynności 89. Prognoza płynności finansowej 90. Absencje personelu, 91. Jednorodne grupy pacjentów 92. Stan realizacji umów NFZ poziom 1: stan realizacji rodzajów umów 93. Stan realizacji umów NFZ poziom 2: stan realizacji wybranej umowy 94. Stan realizacji umów NFZ poziom 3: szczegóły realizacji wybranej umowy 95. Stan realizacji umów NFZ poziom 4: zestawienie pozycji rozliczeniowych składających na realizację planu umowy 96. Zestawienie wyznaczonych JGP - Poziom 1: Zestawienie ogólnej liczby wystąpień danej JGP w zadanym okresie lub/i dla zadanej wersji grupera JGP 97. Zestawienie wyznaczonych JGP - Poziom 2: Szczegóły wybranej JGP 98. Zestawienie wyznaczonych JGP - Poziom 3: Dodatkowe informacje 99. Raporty przekrojowe 100. Wynik OPK 101. Wykonanie Kontraktu 102. Wartości kluczy statystycznych 103. Utylizacja zasobów Sprzęt 104. 105. System musi zapewniać dostęp do różnych typów źródeł danych: np. XML,Stron internetowych, procedur składowanych, plików Excel, baz relacyjnych, baz wielowymiarowych,. System powinien obsługiwać m.in. następujące źródła danych: Baza Oracle, Baza Microsoft SQL Server, Oracle OLAP option System musi potrafić integrować dane z różnych systemów hurtowni danych, hurtowni tematycznych, systemów transakcyjnych, gromadzonych danych operacyjnych. Wykorzystanie natywnych funkcji bazy danych : Access 97, Analysis Services (2000,2005),Oracle (8i,9i,10g,11g),MySQL,Terradata, XML

Strona20 System musi umożliwiać użytkownikowi lub administratorowi kompleksowe zamodelowanie różnych źródeł informacji biznesowej w prosty, zrozumiały 106. (logiczny), jeden model biznesowy wykorzystywany przez wszystkie komponenty platformy systemu analiz (tylko jedna warstwa metadanych wykorzystywana przez wszystkie narzędzia systemu analiz). System powinien umożliwiać użytkownikowi/administratorowi zmianę nazw 107. elementów warstwy fizycznej na pojęcia biznesowe, przyjazne użytkownikowi końcowemu. System musi natywnie wspierać wielojęzyczność przez mechanizmy 108. wbudowane w rozwiązanie. Wielojęzyczność musi być wspierana w obrębie jednej warstwy metadanych i nie może wymagać dla każdego języka instalacji odrębnej warstwy metadanych lub ich części. W celu osiągnięcia skalowania systemu powinien być wykorzystywany 109. mechanizm puli połączeń ( connection pooling ). Oznacza to, że pojedyncze połączenie do bazy danych jest wykorzystywane do wykonywania wielu zapytań. System powinien potrafić łączyć się I pozyskiwać dane z systemów źródłowych 110. w sposób bezpośredni (on-line) lub bezpośrednio po ich przeniesieniu do innej bazy danych. Użytkownik musi mieć dostęp do informacji biznesowej w sposób on-line (raporty) wyłącznie przez standardową przeglądarkę sieci Web za pomocą języka DHTML (technologia AJAX). Wykorzystanie przeglądarki internetowej 111. jako interfejsu użytkownika nie może wymuszać instalacji dodatkowych komponentów typu ActiveX lub Applet Java. Wymagana jest wsparcie przynajmniej dwóch następujących przeglądarek internetowych Internet Explorer oraz Mozilla Firefox. 112. System musi integrować się z rozwiązaniami portalowymi zgodnymi ze standardem JSR 168. 113. System nie może wymagać instalacji żadnego dodatkowego oprogramowania po stronie przeglądarki (np. Plug-in Active X, apletów Java,.) System musi zapewniać automatyczny sposób tworzenia agregatów w relacyjnym źródle danych na podstawie logiki biznesowej warstwy metadanych, a następnie automatyczną obsługę tych agreagatów (zarówno w postaci źródła 114. danych zagregowanych jak i automatycznych odświeżeń). Automatyczne tworzenie agregatów musi być niezależne od źródeł danych warstwy metadanych i może opierać się na wielu różnych technologicznie źródłach danych. 115. System powinien wspierać integracje z narzędziami do zarządzania procesami biznesowymi System musi pozwalać na dostęp do danych na poziomie warstwy biznesowej 116. za pomocą sterownika ODBC jako logiczne źródło danych dla innych niezależnych aplikacji. 117. System musi potrafić prezentować dane z wielu źródeł danych na jednym raporcie (nie na kokpicie menedżerskim) 118. System musi potrafić dynamicznie udostępniać użytkownikom listy wartości wykorzystywane do filtrowania danych na raporcie. 119. System musi wspierać tworzenie tzw. Sub-filtrów np. Użytkownik może wykorzystać rezultaty jednego raportu jako filtr drugiego raportu. System musi wspierać kaskadowe podpowiedzi (prompts) np. 2-ga podpowiedź 120. wyświetla tylko wyfiltrowane ważne wartości dla niej bazując na wartościach zwróconych w 1-ej podpowiedzi. 121. System powinien potrafić wyeksportować dane w formacie.rtf,.pdf,.xls.