Zakres rzeczowy projektu
Nr postępowania: DT/e-usługi/2017 Załącznik nr 1 do Ogłoszenia
Zakres rzeczowy projektu
pt. „Wdrożenie e-usług w Szpitalu im. św. Jadwigi Śląskiej w Trzebnicy”
I. KRÓTKI OPIS PROJEKTU
Przedmiotem projektu jest wdrożenie zintegrowanego oprogramowania informatycznego usprawniającego pracę wewnątrzadministracyjną oraz wdrożenie e-usług publicznych dla przedsiębiorców (A2B) i obywateli (A2C) w Szpitalu im. św. Jadwigi Śląskiej w Trzebnicy (ul. Xxxxxxxx 00-00, 00-000 Xxxxxxxxx). W projekcie nie przewiduje się wprowadzania rozwiązań związanych z udostępnianiem informacji sektora publicznego.
W ramach projektu przewidziano realizację następujących zadań:
1) Zadanie: Wdrożenie elektronicznego systemu w Szpitalu:
a) Rozbudowa infrastruktury sieciowej
b) Zakup, instalacja i konfiguracja infrastruktury informatycznej
c) Zakup, instalacja i konfiguracja wyposażenia do serwerowni
d) Prace adaptacyjno-montażowe dostosowujące serwerownie do zasad bezpieczeństwa
e) Zakup, instalacja i konfiguracja oprogramowania informatycznego wraz z migracją danych
f) Zakup rozwiązań PKI dla personelu Szpitala.
2) Zadanie: Szkolenia dla pracowników Szpitala
3) Zadanie: Promocja projektu:
a) Przygotowanie i wydruk ulotek
b) Przygotowanie i wydruk instrukcji dla użytkowników e-usług i Profilu Zaufanego.
Ze względu na przestarzałą i niewydajną infrastrukturę informatyczną Szpitala dla zapewnienia sprawnego, stabilnego i bezpiecznego działania systemu IT, przesyłania danych, udostępnienia e-usług i współpracy z innymi ogólnopolskimi systemami publicznymi niezbędne jest modernizacja i rozbudowa infrastruktury i sprzętu. Przewidziano przebudowę sieci, na co składa się montaż 60 gniazdek komputerowych, wykonanie okablowania szkieletowego, 14 switchy 48 port, montaż urządzenia typu UTM oraz switcha centralnego. Modernizacja serwerowni przewiduje jej dostosowanie do nowych serwerów (drobne prace adaptacyjno-montażowe) oraz montaż i uruchomienie wyposażenia tj. 2 szafy rack, UPSy, urządzenia klimatyzacyjne, monitoring wizyjny CCTV i instalacja kontroli dostępu. Zostaną zainstalowane 3 serwery wraz z zastosowaniem narzędzia wirtualizacji, macierz dyskowa, serwer backupu wraz z odpowiednimi systemami baz danych i systemami operacyjnymi (ERP, HIS z BI, RIS, LIS) oraz licencjami dostępowymi. W celu
umożliwienia funkcjonalnego działania wdrożonych systemów oraz udostępnienia bezprzewodowego internetu zostanie uruchomionych 40 access pointów oraz 2 kontrolery WI-FI. Zostanie wdrożone oprogramowanie do zarządzania siecią. Planuje się zakup 115 zestawów komputerowych wraz z programem antywirusowym, 25 drukarek monochromatycznych, 3 urządzeń wielofunkcyjnych, 4 skanerów do EDM, 6 drukarek i 20 czytników do kodów kreskowych. Ponadto zostanie zaimplementowanych 200 PKI do autoryzacji pracowników Szpitala (PKI służy do podpisania dokumentów zarówno medycznych jak i administracyjnych, to rodzaj podpisu niekwalifikowanego, certyfikowanego wewnętrznie w centrum certyfikacji Szpitala). Specyfikację infrastrukturalną przedstawiono w pkt III.
Na tak przygotowanej infrastrukturze zostanie wdrożony Zintegrowany System Usług Informatycznych Szpitala (ZSUIS) do części medycznej („białej”) i administracyjno-zarządczej („szarej”), oparty o jednolitą bazę danych – MICROSOFT SQL, który dzięki połączeniu systemów klasy ERP, RIS, HIS z BI, LIS, a także elektronicznego obiegu dokumentów obejmie swoją funkcjonalnością wszystkie procesy zachodzące w jednostce. Na ZSUIS składają się 4 moduły:
1. medyczny (odpowiada za sprawny przepływ wszystkich informacji medycznych, związanych z przebiegiem leczenia każdego pacjenta),
2. administracyjny (wspiera obsługę placówki z uwzględnieniem x.xx.: obsługi procesów
finansowych, kontroli kosztów, budżetów i czasu pracy pracowników),
3. e-Platforma (udostępnianie usług informatycznych pacjentom (A2C) oraz przedsiębiorcom
(A2B)),
4. analityczny (agregowanie danych z pozostałych modułów oraz udostępnianie ich do tworzenia zestawień, raportów i analiz).
Moduły ZSUIS będą ze sobą ściśle zintegrowane, a przepływ i wymiana danych między nimi niewymagająca ingerencji użytkownika. Informacja wprowadzona w części medycznej, a niezbędna do przekazania w e-Platformie będzie w niej dostępna od razu po jej wprowadzeniu. Wdrożony system znacząco wpłynie na efektywność realizowanych procesów wewnątrzadministracyjnych (części „szarej” i „białej”), a także usprawni i ułatwi kontakt z pacjentem – mapy procesów oraz opisy relacji pomiędzy poszczególnymi procesami składającymi się na e-usługę przedstawiono w pkt II i VII.
W ramach projektu w Szpitalu zostanie także utworzony Punkt Potwierdzania Profilu Zaufanego, co ma zachęcić pacjentów do korzystania z elektronicznych usług publicznych w obszarze e-zdrowia.
Wdrożone oprogramowanie pozwoli na uruchomienie 4 e-usług A2B, 7 e-usług A2C oraz 4 e-usług A2A: e-Portal Informacyjny, e-Rejestracja, e-Powiadomienia, e-Dokumentacja, e- Badania, e-Ankieta, e-Faktura, e-Konsultacja, e-Kontrahent, e-Podpis, e-Szkolenia.
System jest w pełni zgodny z obowiązującymi przepisami prawa i wymogami technicznymi. Opis systemu, w tym zgodność z elektroniczną platformą P1 oraz spełnienie zasad interoperacyjności, bezpieczeństwa danych oraz WCAG opisano w pkt II. Wymagane funkcjonalności systemu oraz wykaz wdrożonych e-usług wraz z określeniem e-dojrzałości i ich interesariuszy zawarto w pkt II i VI.
Powyższe zadania zostaną uzupełnione działaniami promującymi e-usługi, które obejmą swym zasięgiem cały region (40% pacjentów Szpitala pochodzi spoza powiatu trzebnickiego) i szkoleniowymi. 250 pracowników części „białej” i 24 pracowników części „szarej” Szpitala weźmie udział w testowaniu i wdrażaniu oprogramowania, a następnie w szkoleniach dotyczących nowoczesnych rozwiązań IT w procesie świadczenia e-usług publicznych (średnio po 40 h dla personelu „białego” i 32 h – dla „szarego”). Szczegółowy opis w/w działań zawarto w pkt IV i V.
Wdrożone oprogramowanie musi przyczynić się do zrealizowania wskaźników projektu:
Wskaźnik produktu | Jednostka miary | Docelowa wartość wskaźnika | Źródło informacji o wskaźniku |
Liczba usług publicznych udostępnionych on- line o stopniu dojrzałości co najmniej 4 – transakcja | Szt. | 9 | Dokumentacja powykonawcza lub/i statystyki systemowe wykorzystania usług |
Liczba udostępnionych usług wewnątrzadministracyjnych (A2A) | Szt. | 4 | Dokumentacja powykonawcza lub/i statystyki systemowe wykorzystania usług |
Liczba uruchomionych systemów teleinformatycznych w podmiotach wykonujących zadania publiczne | Szt. | 1 | Protokół odbioru wdrożenia systemu teleinformatycznego |
Liczba osób objętych szkoleniami / doradztwem w zakresie kompetencji cyfrowych O/K/M | Os. | 274 O | Protokoły odbioru zaświadczeń o ukończeniu szkoleń, listy obecności uczestników szkoleń |
220 K | |||
54 M |
Tabela 1: Wskaźniki produktu.
Wskaźnik rezultatu | Jednostka miary | Docelowa wartość wskaźnika | Źródło informacji o wskaźniku |
Liczba pobrań/uruchomień aplikacji opartych na ponownym wykorzystaniu informacji sektora publicznego i e-usług publicznych | Szt. | 200 | Statystyki systemowe wykonania usług |
Tabela 2: Wskaźniki rezultatu.
Dodatkowe wymagania odnośnie wskaźników projektu:
a) w przypadku wskaźnika produktu Liczba usług publicznych udostępnionych on-line o stopniu dojrzałości co najmniej 4 – transakcja: w ramach wskaźnika ujęto usługi nowe, skierowane do klientów spoza administracji publicznej: obywateli (usługi A2C, Administration to Citizen) i przedsiębiorców (A2B, Administration to Business), a są to:
1) dla obywateli (A2C):
• e-Rejestracja – stopień dojrzałości informatycznej (SDI) 4,
• e-Powiadomienia – SDI 5,
• e-Dokumentacja – SDI 4,
• e-Badania – SDI 4,
• e-Ankieta – SDI 4,
• e-Faktura – SDI 4,
2) dla przedsiębiorców (A2B):
• e-Konsultacja – SDI 4,
• e-Faktura – SDI 4,
• e-Kontrahent – SDI 4;
b) w przypadku wskaźnika produktu Liczba udostępnionych usług wewnątrzadministracyjnych (A2A): wskaźnik definiowany jako liczba usług elektronicznie udostępnionych przez organ administracji publicznej innemu organowi tej administracji, umożliwiających realizację części jego zadań drogą elektroniczną:
• e-Faktura – SDI 4,
• e-Podpis – SDI 4,
• e-Szkolenia – SDI 4.
• e-Portal Informacyjny – SDI 2.
II. OPIS SYSTEMU INFORMATYCZNEGO ORAZ E-USŁUG
Zintegrowany System Usług Informatycznych Szpitala (ZSUIS) będzie składał się z czterech modułów:
1) Modułu Medycznego (dla części „białej”), który będzie pokrywał potrzeby informatycznie personelu medycznego związane z dokumentowaniem historii chorób pacjenta oraz innymi czynnościami medycznymi;
2) Modułu Administracyjnego (dla części „szarej”), który pokrywał będzie potrzeby informatyczne personelu administracji pozwalający na sprawne funkcjonowanie szpitala pod względem organizacyjnym;
3) e-Platformy, której głównym zadaniem będzie udostępnianie usług informatycznych pacjentom oraz współpracownikom szpitala, którzy nie są bezpośrednimi pracownikami szpitala; zadaniem platformy będzie usprawnienie komunikacji między szpitalem i jego pacjentami oraz między szpitalem a podmiotami zewnętrznymi (innymi szpitalami, współpracownikami, konsultantami itp.);
4) Modułu Analitycznego, którego zadaniem będzie agregowanie danych z pozostałych modułów oraz udostępnianie ich do tworzenia zestawień, raportów i analiz; moduł przeznaczony będzie dla wybranej grupy osób, które będą miały prawo dostępu do tak
szerokiego zakresu danych analityczno-statystycznych zestawiających dane zarówno z części „białej” jak i „szarej”.
Wymienione moduły ZSUIS będą ze sobą ściśle zintegrowane, a przepływ i wymiana danych między nimi niewymagająca ingerencji użytkownika. System będzie tak zbudowany, aby informacja wprowadzona w części medycznej, a niezbędna do przekazania w e-Platformie, była w niej dostępna od razu po jej wprowadzeniu.
cmp Budowa systemu
e-Platforma
P1
Moduł Medyczny (część "biała")
Moduł Administracyjny (część "szara")
P2
Moduł analityczny
Rysunek 1: Obszary ZSUIS.
e-Platforma ma wzmacniać kanał komunikacji z pacjentami i podmiotami współpracującymi ze szpitalem. W ramach e-Platformy uruchomiony zostanie szereg usług, które będą zorientowane na potrzeby konkretnych interesariuszy projektu. Usługa e-Rejestracji przeznaczona dla pacjentów pozwoli pacjentom rejestrować się do wybranej przychodni i wybranego lekarza bez konieczności telefonicznego kontaktu czy osobistego przychodzenia do szpitala. Usługa będzie wykorzystywała harmonogramy pracy poradni i lekarzy wprowadzone w Module Medycznym, a informacja o zarezerwowanej wizycie będzie wracała do Modułu Medycznego, tak by nie było możliwe zarejestrowanie drugiego pacjenta na tą samą godzinę.
Rozszerzeniem usługi e-Rejestracja będzie usługa e-Badania, dzięki której pacjent będzie mógł przeglądać swoje wyniki badań zarejestrowane w Module Medycznym. Podobnie usługa e- Dokumentacja będzie stanowiła rozszerzenie usługi e-Rejestracja o dostęp pacjenta do jego dokumentacji medycznej zewnętrznej przetwarzanej w Module Medycznym.
Usługa e-Powiadomienia pozwoli na rozsyłanie powiadomień o zaplanowanych wizytach oraz ewentualnych zmianach dotyczących ich terminów. Wysyłanie powiadomień będzie automatyczne inicjowane przez ZSUIS i wysyłane przed terminem zaplanowanej wizyty lub w momencie zmiany terminu lub odwołania wizyty. e-Ankieta będzie pozwalała pacjentowi wyrazić
swoją opinię na temat usług realizowanych przez placówkę, dzięki czemu szpital będzie posiadał informację zwrotną od pacjentów o jakości udzielanych przez siebie świadczeń.
Moduł e-Konsultacje i e-Kontrahent to dwie usługi, które pozwolą na współpracę pracowników szpitala z zewnętrznymi współpracownikami. Usługa e-Konsultacje będzie udostępniała dokumentację medyczną wybranego pacjenta podmiotowi, z którym szpital ma podpisaną umowę o współpracy, w celu przeprowadzenia konsultacji ze specjalistą zewnętrznym. Moduł e-Kontrahent pozwoli na zlecanie przez współpracowników zewnętrznych wprowadzania zleceń na konsultacje realizowane przez lekarzy szpitala. W module e-Kontrahent możliwe będzie dodawanie dokumentacji medycznej, która będzie konsultowana przez specjalistę szpitala.
cmp Komponenty
e-Platforma
e-Portal
e-Kontrahent
e-Szkolenia
e-Konsultacje
e-Badania
e-Ankieta
Moduł Medyczny (część "biała")
e-Rejestracja
e-Powiadomienia
e-Dokumentacja
e-Podpis
Moduł Administracyjny (część "szara")
e-Faktura
Rysunek 2: Współpraca pomiędzy e-usługami.
Faktury wystawiane z wykorzystaniem usługi e-Faktura będą mogły być podpisywane podpisem elektronicznym wystawianym przez usługę e-Podpis. Dodatkowo usługa e-Podpis będzie wykorzystywana do podpisywana dokumentacji medycznej w Module Medycznym, a w szczególności wszystkie dokumenty przechowywane w Module Elektronicznej Dokumentacji
Medycznej, który komunikował będzie się z platformą elektroniczną P1. Również e-Podpis będzie mógł być wykorzystany w Module Administracyjnym do podpisywania dokumentów.
Usługa e-Szkolenia będzie usługą dostępną dla pracowników szpitala, która pozwoli na podnoszenie kwalifikacji zawodowych oraz udostępnianie ważnych przepisów oraz dokumentów.
Wdrożone oprogramowanie spowoduje uruchomienie:
a) e-usług dla: obywateli o stopniu dojrzałości 2 i powyżej tj.:
1) e-Portal Informacyjny – stopień dojrzałości informatycznej (SDI) 2
2) e-Rejestracja – SDI 4
3) e-Powiadomienia – SDI 5
4) e-Dokumentacja – SDI 4
5) e-Badania – SDI 4
6) e-Ankieta – SDI 4
7) e-Faktura – SDI 4
b) e-usług dla przedsiębiorców o stopniu dojrzałości 2 i powyżej tj.:
1) e-Konsultacja – SDI 4
2) e-Portal Informacyjny – SDI 2
3) e-Faktura – SDI 4
4) e-Kontrahent – SDI 4
c) e-usług A2A o stopniu dojrzałości 2 i powyżej tj.:
1) e-Portal Informacyjny – SDI 2
2) e-Faktura – SDI 4
3) e-Podpis – SDI 4
4) e-Szkolenia – SDI 4.
W sumie w projekcie zostanie wdrożonych: 4 e-usługi A2B, 7 e-usług A2C oraz 4 e-usługi A2A. Rodzaj i ilość interesariuszy danej usługi określono w poniższym zestawieniu tabelarycznym.
Lp. | e-usługa | Opis e-usługi | Poziom dojrzałości i rodzaj | Interesariusze |
e-Platforma to zbiór dedykowanych modułów udostępniających szereg e-usług wspomagających pracę placówki medycznej współpracujących z systemem szpitalnym HIS i ERP (system biały i szary). e-Platforma korzysta ze wspólnej instancji bazy danych dla systemu HIS i ERP, co ma duże znaczenie dla spójności danych oraz bezpieczeństwa ich przechowywania i przetwarzania. | ||||
1. | e-Portal Informacyjny | Portal informacyjny posiadający część publiczną (niewymagającą logowania) oraz cześć przeznaczoną tylko dla użytkowników, którym zostały nadane odpowiednie uprawnienia. Sposób logowania uzależniony od rodzaju usługi. Usługi modułu e-Portalu dedykowane są dla użytkowników posiadających dostęp do Internetu jak również Xxxxxxxxx. | X0X, X0X, X0X, 0 | Pacjenci – szacowana ilość: 40 tys. oszacowano na podstawie ilości pacjentów oddziałów szpitalnych (bez SOR), POZ, poradni specjalistycznych oraz korzystających z diagnostyki (dane za 2015 r.) Podmioty gospodarcze współpracujące z placówką lub zainteresowane |
W ramach usług informacyjnych użytkownicy będą mieli dostęp do ogólnych danych dotyczących świadczonych przez Szpital usług medycznych oraz informacji prawnych nt. placówki medycznej. Z poziomu e-Portalu po zalogowaniu (w ramach e-Platformy) użytkownicy będą mieć dostęp do szeregu dedykowanych e-Usług. e-Portal Informacyjny jako platforma dostępna nie tylko w Internecie, ale również Intranecie, stanowiący „mapę” dostępową dla poszczególnych e-Usług według przeznaczenia i przydzielonych uprawnień – dostęp realizowany przez stronę www, w tym na infokiosku. Aktualnie usługa nie jest realizowana przez placówkę medyczną. | rozpoczęciem współpracy: ok. 35 podmiotów; oszacowano na podstawie analizy danych za 2015 r. Podmioty publiczne, w tym organy administracji: ok. 10; oszacowano na podstawie analizy danych za 2015 r. Placówki medyczne współpracujące ze szpitalem: ok. 40; oszacowano na podstawie analizy danych za 2015 r. Pracownicy jednostki: ok. 450 osób, w tym ok. 270 osób aktywnie korzystających (personel medyczny, administracja) Działające w placówce organizacje związkowe: 3 | |||
2. | e-Rejestracja | Usługa przeznaczona dla pacjentów, dzięki której będą oni posiadali możliwość samodzielnego rejestrowania się na wizyty zgodnie z kalendarzem wolnych wizyt w wybranej przez siebie poradni. Założenie konta w module e- Rejestracja będzie wymagało uwierzytelnienia za pomocą e-PUAP lub podpisu elektronicznego. Usługi modułu e-Rejestracji dedykowane są dla pacjentów posiadających konta w e-Platformie. Po założeniu konta logowanie będzie odbywało się za pomocą indywidualnie nadanego bezpiecznego użytkownika i hasła. Dostęp z www z poziomu stacji roboczych oraz urządzeń mobilnych. Celem wdrożenia Modułu e- Rejestracji jest zapewnienie usługi rejestracji pacjentów przez placówkę medyczną w formie elektronicznej. e-Rejestracja umożliwi obsługę pełnego procesu rejestracji pacjenta na wizytę lekarską. W ramach usługi możliwe będzie wybranie na podstawie różnych kryteriów (sposób refundacji, nazwa poradni/specjalizacja, kod usługi, nazwa usługi) interesującej pacjenta usługi do realizacji w placówce medycznej i tym samym zarezerwowanie terminu jej wykonania. Rezerwacja terminu usługi wykonana z poziomu e-Rejestracja będzie natychmiast trafiać do Systemu HIS. Usługa e-Rejestracji będzie korzystała z definicji grafików i terminarzy | A2C, 4 | Pacjenci poradni: POZ i poradni specjalistycznych: chirurgiczna, neonatologiczna, urazowo-ortopedyczna: ok. 15 tys. osób; oszacowano na podstawie danych za 2015 r. |
zapisanych w systemie HIS w celu zaprezentowania pacjentowi właściwego zakresu możliwych do wybrania wizyty. Usługa e-Rejestracji będzie posiadać możliwość ograniczenia rejestracji tylko do wybranych poradni. Aktualnie usługa nie jest realizowana przez placówkę medyczną. | ||||
3. | e- Powiadomienia | Usługa rozszerzająca usługę e- Rejestracja. Dostęp do niej będzie możliwy po nadaniu pacjentowi odpowiednich uprawnień. Zasady bezpiecznego dostępu do e- Powiadomienia analogiczne do zasad w usłudze e-Rejestracja. e-Powiadomienia umożliwiają obsługę pełnego procesu powiadamiania pacjenta o zbliżającym się terminie wizyty, jej odwołaniu lub przesunięciu. Usługa e-Powiadomienia będzie umożliwiała elektroniczne przypomnienie o wizycie przy pomocy konfigurowalnych komunikatów e- mail lub sms, jeśli w danych personalnych pacjenci będą posiadali uzupełnione dane dot. numeru sms oraz/lub adresu email. Aktualnie usługa nie jest realizowana przez placówkę medyczną. | A2C, 5 | Pacjenci poradni: POZ i poradni specjalistycznych: chirurgiczna, neonatologiczna, urazowo-ortopedyczna: ok. 15 tys. osób; oszacowano na podstawie danych za 2015 r. |
4. | e-Dokumentacja | Usługa rozszerzająca usługę e- Rejestracja. Dostęp do niej będzie możliwy po nadaniu pacjentowi odpowiednich uprawnień. Zasady bezpiecznego dostępu do usługi e- Dokumentacja analogiczne do zasad w usłudze e-Rejestracja. Usługa modułu e-Dokumentacji dostępna będzie dla pacjentów posiadających konto w e-Platformie. W ramach usługi e-Dokumentacji możliwy będzie dostęp zalogowanego pacjenta do udostępnionej przez placówkę medyczną dokumentacji medycznej pacjenta. Elektroniczna dokumentacja medyczna udostępniana będzie drogą elektroniczną w module e- Dokumentacja z systemu HIS. Uprawniony pracownik placówki medycznej z poziomu systemu HIS będzie mógł wskazać, jaki zakres dokumentacji medycznej może być udostępniany dla pacjentów w module e-Dokumentacja. Usługa e-Dokumentacji umożliwi pacjentowi pełną realizację procesu | A2C, 4 | Pacjenci – szacowana ilość: 40 tys.; oszacowano na podstawie ilości pacjentów oddziałów szpitalnych (bez SOR), POZ, poradni specjalistycznych oraz korzystających z diagnostyki (dane za 2015 r.) |
dostępu do dokumentacji medycznej drogą elektroniczną. Aktualnie usługa nie jest realizowana przez placówkę medyczną. | ||||
5. | e-Kontrahent | Usługi modułu e-Kontrahenta dostępne będą dla uprawnionych pracowników zewnętrznych placówek medycznych, które posiadają umowę o współpracy z podmiotem medycznym (szpitalem). Dostęp do niej odbywa się za pomocą bezpiecznego użytkownika i hasła nadanego po zawarciu odpowiedniej umowy z podmiotem zewnętrznym. W ramach usługi e-Kontrahenta możliwa będzie obsługa pełnego procesu zlecania usług dla pacjentów z zewnętrznych placówek medycznych oraz dostęp do wyników wykonanych usług dla pracowników zewnętrznych placówek medycznych. Zalogowany uprawniony pracownik z zewnętrznej placówki medycznej będzie miał elektroniczny dostęp do rejestru usług, na które może kierować pacjentów z zewnętrznej placówki. Aktualnie usługa nie jest realizowana przez placówkę medyczną. | A2A, A2B, 4 | Placówki medyczne działające w publicznym i niepublicznym systemie ochrony zdrowia: 40, w tym: 14 publiczne, 26 – niepubliczne; oszacowano na podstawie analizy danych za 2015 r. Pracownicy jednostki: ok. 450 osób, w tym ok. 270 osób aktywnie korzystających (personel medyczny, administracja) |
6. | e-Badania | Usługa rozszerzająca usługę e- Rejestracja. Dostęp do niej będzie możliwy po nadaniu pacjentowi odpowiednich uprawnień. Zasady bezpiecznego dostępu do e-Badania analogiczne do zasad w usłudze e- Rejestracja. Usługi modułu e-Badania dostępne będą dla pacjentów posiadających konta e-Platformie. W ramach usługi e-Badania możliwe będzie pobranie wyników badań laboratoryjnych lub diagnostycznych bezpośrednio przez pacjenta. Moduł e-Badania będzie korzystał z tego samego źródła danych co system HIS gwarantując tym samym pełną integrację z Elektronicznym Rekordem Medycznym Pacjenta. Usługa e-Badania umożliwi pacjentowi pełną realizację procesu dostępu do wyników badań drogą elektroniczną. Aktualnie usługa nie jest realizowana przez placówkę medyczną. | A2C, 4 | Pacjenci – szacowana ilość: 40 tys.; oszacowano na podstawie ilości pacjentów oddziałów szpitalnych (bez SOR), POZ, poradni specjalistycznych oraz korzystających z diagnostyki (dane za 2015 r.) |
7. | e-Konsultacja | Usługi modułu e-Konsultacje będą dostępne dla uprawnionych użytkowników. W ramach usługi e- Konsultacji możliwe będzie | A2A, A2B, 4 | Placówki medyczne, w tym specjalistyczne, działające w publicznym i niepublicznym systemie ochrony zdrowia:40, |
elektroniczne zlecanie konsultacji badań do wskazanej jednostki konsultacyjnej. Zarządzanie jednostkami konsultacyjnymi będzie możliwe z poziomu administracji systemu HIS. W ramach usługi e- Konsultacji możliwe będzie przesyłanie drogą elektroniczną danych z miejsca, w którym są one generowane, do miejsca, gdzie będą analizowane w czasie rzeczywistym lub ich archiwizację do późniejszego wykorzystania na dowolnej stacji lekarskiej. Dzięki temu możliwe będzie monitorowanie wyników badań i prowadzenie konsultacji - z innymi placówkami specjalistycznymi, co umożliwia bieżące analizowanie i omawianie skomplikowanych przypadków z ekspertami bez konieczności ich fizycznej obecności. W zakresie usługi e-Konsultacji możliwe będzie wyświetlania obrazów znajdujących się w lokalnym archiwum PACS (dane obrazowe) w zakresie określonym przez zlecenie. Aktualnie usługa nie jest realizowana przez placówkę medyczną. | w tym: 14 publiczne, 26 – niepubliczne; oszacowano na podstawie analizy danych za 2015 r. Pracownicy jednostki: ok. 450 osób, w tym ok. 270 osób aktywnie korzystających (personel medyczny, administracja) | |||
8. | e-Ankieta | Usługa rozszerzająca usługę e- Rejestracja. Dostęp do niej będzie możliwy po nadaniu pacjentowi odpowiednich uprawnień. Zasady bezpiecznego dostępu do e- Dokumentacja analogiczne do zasad w usłudze e-Rejestracja. Usługi modułu e-Ankieta dostępne będą dla pacjentów posiadających konta e-Platformie. W ramach usługi e-Ankiety możliwe będzie udostępnienie elektronicznych ankiet które będą mogli wypełnić pacjenci np. ankiety oceny zadowolenia z poziomu obsługi medycznej w placówce medycznej. Upoważniony pracownik placówki medycznej będzie mógł definiować ankiety, określić ich czas publikacji oraz poprzez dedykowane raporty weryfikować zbiorcze dane z wypełnionych ankiet. Aktualnie usługa nie jest realizowana przez placówkę medyczną. | A2C, 4 | Pacjenci – szacowana ilość: 40 tys.; oszacowano na podstawie ilości pacjentów oddziałów szpitalnych (bez SOR), POZ, poradni specjalistycznych oraz korzystających z diagnostyki (dane za 2015 r.) |
9. | e-Podpis | Usługa rozszerzająca moduł medyczny, administracyjny oraz usługę e-Faktura pozwalający na podpisywanie podpisem elektronicznym dokumentów wytwarzanych w tych modułach. | A2A, 4 | Pracownicy jednostki: 200, w tym: 5 (administracja) 75 (lekarze) 95 (pielęgniarki/położne) 25 (pozostałe osoby medyczne: laboratorium, RTG) |
Usługi modułu e-Podpis dostępne będą dla użytkowników systemu HIS (część medyczna). W ramach usługi e-Podpisu możliwe będzie podpisanie niekwalifikowanym podpisem elektronicznym dokumentów, w szczególności: potwierdzanie przyjęcia i realizacji zleceń przez pielęgniarki i techników medycznych, dokumentacji medycznej. W systemie HIS w ramach usługi e- Podpisu, udostępniona będzie funkcjonalność składania podpisów elektronicznych niekwalifikowanych, pod dokumentami elektronicznymi w postaci PDF, zgodnie z szablonami autoryzacji. Aktualnie usługa nie jest realizowana przez placówkę medyczną. | ||||
10. | e-Faktura | Usługa rozszerzająca moduł medyczny i administracyjny pozwalająca na wystawianie faktur w wersji elektronicznej. Dostęp do usługi zgodny z zasadami dostępu do modułów, w których wystawiane są faktury. Usługi Modułu e-Faktura będą dostępne dla uprawnionych użytkowników placówki medycznej. W ramach usług e-Faktury możliwe będzie stosowanie faktur w wersji elektronicznej oraz będzie możliwe podpisywanie faktur wychodzących podpisem elektronicznym niekwalifikowanym lub kwalifikowanym. Moduł e-Faktura będzie posiadał możliwość weryfikacji autentyczności dokumentu poprzez weryfikację certyfikatu tego dokumentu. Aktualnie usługa nie jest realizowana przez placówkę medyczną. | X0X, X0X, X0X, 0 | Publiczne i biznesowe jednostki (przedsiębiorcy, kontrahenci) współpracujący z placówką: ok. 100 podmiotów, osoby prywatne: 229; oszacowano na podstawie danych za 2015 r. (dane podmiotów/osób, którym wystawiono fakturę) Pracownicy jednostki: ok. 450 osób, w tym ok. 270 osób aktywnie korzystających (personel medyczny, administracja) |
11. | e-Szkolenia | Usługi Modułu e-Faktura będą dostępne dla uprawnionych użytkowników placówki medycznej. Usługa dostępna wyłącznie w Intranecie dla pracowników Szpitala. W ramach usług e-Szkolenia zostanie uruchomiona platforma internetowa szkoleń wewnętrznych dla pracowników w szczególności z zakresu prawa pracy, przepisów BHP. W ramach usług e-Szkolenia będzie możliwość publikowania artykułów, zamieszczania dokumentów i udostępniania tej treści wskazanym grupom użytkowników na podstawie ich uprawnień. | A2A, 4 | Pracownicy jednostki: ok. 450 osób, w tym ok. 270 osób aktywnie |
Aktualnie usługa nie jest realizowana przez placówkę medyczną. |
Tabela 3: Wykaz wdrożonych e-usług w Szpitalu im. św. Jadwigi Śląskiej w Trzebnicy.
W ramach usług A2B i A2C nie będą przetwarzane dane będące informacją publiczną.
Interoperacyjność, zgodność z obowiązującymi przepisami oraz platformami P1 i P2
System ZSUIS musi spełniać warunki interoperacyjności w zakresie e-zdrowia, dlatego jego podstawą będzie przygotowanie do integracji z platformami elektronicznymi P1 i P2 tak, aby współpracować z centralnymi systemami w zakresie i na zasadach określonych w interfejsach integracyjnych tych systemów. W zakresie platformy P1 integracja będzie polegała na przekazywaniu informacji o wytworzonej dokumentacji medycznej, a w przypadku platformy P2, pobierania danych słownikowych z udostępnianych rejestrów.
Wymagania dotyczące interoperacyjnego współdziałania systemów informatycznych w
ochronie zdrowia zostały określone:
a) w ustawie z dnia 28.04.2011 r. o systemie informacji w ochronie zdrowia (Dz.U. z 2011 Nr
113 poz. 657, z późn. zm.),
b) w Rozporządzeniu Ministra Zdrowia z 28.03.2013 r. w sprawie wymagań dla Systemu
Informacji Medycznej,
c) w Rozporządzeniu Ministra Zdrowia z dnia 21.12.2010 r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania (Dz.U. z 2010 Nr 252 poz. 1697, z późn. zm.),
d) w Rozporządzeniu Rady Ministrów z dnia 12.04.2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. z 2012 poz. 526, z późn. zm.),
e) w dwóch dokumentach opublikowanych przez Centrum Systemów Informacyjnych Ochrony Zdrowia: Reguły biznesowe i walidacyjne określające strukturę dokumentów medycznych (eRecepta, eSkierowanie i eZlecenie) przetwarzanych na platformie P1 oraz Model transportowy danych o Zdarzeniach Medycznych oraz Indeksie Elektronicznej Dokumentacji Medycznej gromadzonych w systemie P1.
System będzie spełniał zasady interoperacyjnego współdziałania na trzech poziomach: semantycznym, organizacyjnym oraz technologicznym:
1) interoperacyjność na poziomie organizacyjnym osiągnięta będzie x.xx. poprzez możliwość zapoznania się za pośrednictwem Portalu Informacyjnego przez pacjentów o sposobie skorzystania z e-usług oraz procedur związanych z leczeniem czy udostępnianiem dokumentacji medycznej. Procedury związane z udostępnianiem dokumentacji medycznej
oraz informacji medycznej na poziomie organizacyjnym muszą być zgodne przede wszystkim z zasadami określonymi w ustawie z dnia 6.11.2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta (Dz.U. z 2009 Nr 52 poz. 417, z późn. zm.).
2) interoperacyjność na poziomie semantycznym będzie spełniona, gdyż system informatyczny, który zostanie wdrożony w wyniku realizacji projektu musi, zgodnie z wymogami ustawy z dnia 28.04.2011 r. o systemie informacji w ochronie zdrowia (Dz.U. z 2011 Nr 113 poz. 657, z późn. zm.), umożliwiać tworzenie elektronicznych dokumentów medycznych według struktur danych określonych przez CSIOZ (Reguły biznesowe i walidacyjne określające strukturę dokumentów medycznych), udostępniać informacje o zdarzeniach medycznych do Systemu Informacji Medycznej według zasad określonych w Rozporządzeniu Ministra Zdrowia z 28.03.2013 r. w sprawie wymagań dla Systemu Informacji Medycznej oraz dokumencie CSIOZ pt. Model transportowy danych o Zdarzeniach Medycznych oraz Indeksie Elektronicznej Dokumentacji Medycznej gromadzonych w systemie P1. Interoperacyjność semantyczna zostanie spełniona również poprzez zapewnienie, że dane medyczne gromadzone w rejestrze świadczeń opieki zdrowotnej będą gromadzone i opisywane według zasad określonych w Rozporządzeniu Ministra Zdrowia z dnia 20.06.2008 r. 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.
3) interoperacyjność na poziomie technologicznym będzie zapewniona, gdyż system informatyczny, zgodnie z wcześniej wymienionymi regulacjami prawnymi, umożliwiać będzie wymianę danych z usługodawcami innych systemów teleinformatycznych za pomocą zdefiniowanych przez CSIOZ protokołów komunikacyjnych i szyfrujących.
Zgodnie z wymogami określonymi we wspomnianych aktach prawnych oraz dokumentami opublikowanymi przez Centrum Systemów Informacyjnych Ochrony Zdrowia warunkiem integracji z platformami P1 i P2 jest wdrożenie systemu informatycznego implementującego mechanizmy komunikacji według standardu opracowanego przez IHE (Integrating the Healthcare Enterprise – xxx.xxx.xxx) w obszarze profilu XDS.b (Cross-Enterprise Document Sharing w wersji b) z uwzględnieniem niezbędnych polskich rozszerzeń opracowanymi przez CSIOZ. Zastosowanie tego standardu jest również ważne z punktu widzenia możliwej przyszłej międzynarodowej interoperacyjności. Zgodnie z zaleceniami CSIOZ wdrażany system informatyczny spełniać będzie trzy wymagania dotyczące komunikacji platformy P1 z systemami usługodawców:
1) komunikacja między systemami, dotycząca danych medycznych, wykorzystuje standardy opracowane przez IHE,
2) nieobrazowe dane medyczne: komunikacja z platformą P1 w zakresie transferu nieobrazowych danych medycznych realizuje w oparciu o standardy HL7 (w wersji 2.x oraz 3) oraz CEN 13606 1:5 (w aktualnej wersji),
3) dane obrazowe: system P1 umożliwia gromadzenie i przekazywanie informacji o miejscu przechowywania danych obrazowych (zgodnych ze standardem DICOM w jego aktualnej wersji).
Zgodnie z wymaganiami ustawy oraz wytycznymi CSIOZ system informatyczny wdrożony w Szpitalu im. św. Jadwigi w Trzebnicy umożliwiać będzie przesłanie do P1 informacji w trzech obszarach:
a) informacja o zdarzeniu medycznym, tzw. ExtPLHealthcareEvent,
b) indeksy dokumentów medycznych wytworzonych w ramach tego zdarzenia, tzw.
XDSDocumentEntry,
c) informacja o bieżącym komunikacie, tzw. XDSSubmissionSet.
Informacja o zdarzeniu medycznym przesyłana do P1 przez szpital zawierać będzie istotne informacje o zdarzeniu medycznym, poza wskazaniem usługobiorcy i usługodawcy, to typ zdarzenia według słownika kodów jednostek statystycznych, czas jego trwania, lista wykonanych procedur medycznych, uzyskane rozpoznania oraz typ płatnika. W szczególności będą to:
• identyfikator zdarzenia medycznego,
• data początku i końca zdarzenia,
• tryb przyjęcia i wypisu oraz numer księgi głównej,
• typ zdarzenia według słownika kodów jednostek statystycznych,
• dane usługodawcy realizującego zdarzenie,
• wskazanie osoby merytorycznie odpowiedzialnej za przeprowadzenie zdarzenia, tj.
pracownika medycznego usługodawcy,
• dane usługobiorcy,
• identyfikator skierowania powiązanego,
• lista procedur medycznych,
• lista rozpoznań,
• typ płatnika, a jeśli jest to płatnik publiczny, kod płatnika.
Indeks dokumentu medycznego ma za zadanie informowanie o istnieniu dokumentu i jego lokalizacji w szpitalu. Podstawowe dane, pochodzące wyłącznie bezpośrednio z dokumentu (przynajmniej dla dokumentów zgodnych z polskim HL7 CDA Implementation Guide), służyć będą wyszukiwaniu dokumentów. Dane te, poza wskazaniem usługobiorcy, usługodawcy i lokalizacji (kustosza) dokumentu, obejmują przede wszystkim typ LOINC i drugi typ P1 dokumentu, datę jego
wystawienia, a także procedury medyczne w wyniku, których dokument powstał. W szczególności dane dotyczące indeksu EDM zawierać będą następujące informacje:
• wskazanie na zdarzenie medyczne, w ramach którego dokument został utworzony,
• identyfikator dokumentu,
• data wystawienia dokumentu,
• typ dokumentu wg LOINC,
• typ dokumentu wg P1,
• język, poziom poufności i format dokumentu,
• dane usługobiorcy, którego dotyczy dokument,
• dane usługodawcy wystawiającego dokument,
• wskazanie osoby wystawcy dokumentu, tj. pracownika medycznego usługodawcy,
• wskazanie kustosza dokumentu,
• data rozpoczęcia i zakończenia procedur oraz lista procedur udokumentowanych
opisywanym dokumentem,
• rozmiar i status dostępności dokumentu (informacyjnie na potrzeby udostępniania) i skrót z dokumentu (na potrzeby wykrywania duplikatów i udostępniania),
• informacje o autorze modyfikacji, jeśli informacja dotyczy modyfikacji indeksu.
Szczególnymi dokumentami podlegającymi procesowi wymiany pomiędzy szpitalem a innymi usługodawcami oraz pacjentami za pośrednictwem P1 będą dokumenty takie jak recepta, skierowanie i zlecenie. Oznacza to, że system informatyczny musi archiwizować i przesyłać do P1 dokumenty w pełnej postaci (będą one gromadzone w module zleceń Systemu Informacji Medycznej, czyli centralnej bazie danych medycznych w ramach P1). Każdy dokument wysyłany do platformy P1 będzie podlegał regułom walidacyjnym przypisanym do konkretnego dokumentu. System wdrożony w trzebnickim szpitalu będzie posiadał możliwość wymiany EDM z systemami innych usługodawców za pośrednictwem P1 według następujących wariantów:
a) wariant I – dokumentacja zamawiana jest w SIM i przekazywana do wnioskującego przez
kustosza dokumentu,
b) wariant II – dokumentacja zamawiana jest w SIM i udostępniana przez kustosza wnioskującemu do pobrania,
przy czym kustoszem dokumentu jak i wnioskującym może być szpital lub inny usługodawca.
Integracja systemu z platformami P1 oraz P2 oznacza konieczność posiadania systemu informatycznego, zbudowanego według modelu logicznego zalecanego przez CSIOZ1. Model systemu do gromadzenia i udostępniania za pośrednictwem P1 informacji o zdarzeniach
1 Wytyczne, zasady i rekomendacje dla usługodawców w zakresie budowy i stosowania systemu bezpiecznego przetwarzania elektronicznej dokumentacji medycznej. Centrum Systemów Informacyjnych Ochrony Zdrowia. Warszawa, 2014.
medycznych oraz wytworzonej podczas zdarzenia medycznego elektronicznej dokumentacji
medycznej powinien być zbudowany z następujących modułów:
• dodawania i edycji danych medycznych,
• importu/migracji danych zewnętrznych,
• tworzenia dokumentacji medycznej,
• autoryzacji,
• wersjonowania,
• archiwizacji,
• uprawnień,
• dostępu,
• udostępniania.
Moduł „dodawania i edycji danych medycznych” i „importu/migracji danych zewnętrznych”, odpowiedzialny będzie są za dostarczenie Jednostkowych Danych Medycznych, na podstawie, których generowana będzie Elektroniczna Dokumentacja Medyczna. Jednostkowe Dane Medyczne będą wprowadzane bezpośrednio przez pracowników szpitala albo importowane z systemów innych usługodawców za pośrednictwem P1 przy pomocy modułu importu/migracji danych. Dlatego moduł importu/migracji będzie implementować otwartą architekturę umożliwiającą obsługę źródeł danych zgodnie ze specyfiką i wymaganiami dziedzinowych systemów medycznych (np. złożone relacyjne bazy danych w przypadku np. systemów HIS czy też zbiory obrazów w przypadku systemów PACS), a także powinien umożliwiać obsługę rożnych formatów komunikatów, w zależności od zakresu danych wymaganych przez poszczególne rodzaje dokumentacji medycznej. Następnie, na podstawie dostarczonych danych źródłowych, w module tworzenia dokumentacji medycznej generowana będzie Elektroniczna Dokumentacja Medyczna. Tworzona ona będzie zgodnie z obowiązującymi standardami wymiany danych, uwzględniając ewentualne dołączenie tzw. dokumentów „obcych” (np. skierowań, historycznych wyników badań). W przypadku recept, zleceń i skierowań będzie to standard HL7 CDA w zakresie przyjętego w Polsce zestawu reguł zwanego Implementation Guide, zaś dla dokumentacji obrazowej standard DICOM. Dla pozostałych rodzajów dokumentacji przewiduje się, że jako standard wymiany zostanie także przyjęty HL7 CDA.
W kolejnym kroku utworzona dokumentacja medyczna będzie autoryzowana (podpis elektroniczny), a następnie wersjonowana i przekazywana do przechowywania w repozytorium EDM. Dostęp do dokumentów zgromadzonych w repozytorium poprzedzony będzie weryfikacją uprawnień na podstawie zakresu praw zdefiniowanych dla poszczególnych ról funkcjonalnych i organizacyjnych. Następnie w module dostępu, na podstawie zgromadzonej dokumentacji, budowany będzie rekord pacjenta. Dzięki temu pracownik medyczny uzyska możliwość wglądu nie
tylko do pojedynczych dokumentów, ale także w ogólny stan zdrowia i choroby w formie zbiorczych zestawień. Moduł dostępu zapewni także możliwość wyszukiwania dokumentów, podgląd dokumentu źródłowego, przeglądu wersji dokumentów oraz wstawienie komentarza.
Dalej dokumentacja może zostać udostępniona odbiorcom zewnętrznym np. platformie P1, pacjentowi. Moduł udostępniania zapewni mechanizmy przetworzenia i odpowiedzi na zewnętrzne żądania wydania dokumentacji, a także eksportu danych, w przypadku przenoszenia dokumentacji do innego systemu. Dodatkowo zgodnie z § 84 Rozporządzenie Ministra Zdrowia z dnia 21.12.2010
r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania (Dz.U. z 2010 Nr 252 poz. 1697, z późn. zm.) w przypadku przeniesienia dokumentacji do innego systemu, do takiej dokumentacji musi zostać przypisana data przeniesienia oraz informacja, z jakiego systemu została przeniesiona.
W module archiwizacji dokumenty będą klasyfikowane ze względu na spełnienie warunków transferu do archiwum. Zarchiwizowane dokumenty będą przechowywane w tym samym repozytorium, w którym przechowywana jest dokumentacja bieżąca.
Zgodnie z założeniami architektury opartej o ogólnie przyjęte standardy oraz o model usługowy należy przyjąć, że rozwiązania zastosowane w projekcie będą cechować się neutralnością technologiczną i otwartym dostępem. System, który powstanie w wyniku realizacji projektu będzie posiadał interfejsy pozwalające na łatwe dołączanie do niego kolejnych podmiotów, projektów i platform teleinformatycznych niezależnie od ich producenta i użytej technologii i będzie spełniał założenia architektury SOA. Projekt nie będzie a priori faworyzował żadnej konkretnej technologii jak również ograniczał możliwości technologicznego wyboru. System będzie zgodny z następującymi standardami:
a) standardy branżowe:
1) IHE Cross-Enterprise Document Sharing (XDS), w szczególności profil integracyjny, który standaryzuje rozdzielność 4 bytów ze względu na różną odpowiedzialność: repozytorium dokumentów, rejestr dokumentów, systemy źródłowe dokumentów, konsumentów dokumentów. W ramach zgodności z XDS przewiduje się zgodność z następującymi wytycznymi standardu XDS.b:
• ITI-41 w zakresie dostarczania i rejestrowania dokumentów w repozytorium
• ITI-42 w zakresie rejestrowania dokumentów w rejestrze
• ITI-43 w zakresie pozyskiwania dokumentów z repozytorium
• ITI-18 w zakresie zapytań do rejestru
• ITI-8 oraz ITI-44 w zakresie identyfikacji pacjenta przez rejestr
• HL7 CDA, który standaryzuje strukturę dokumentów elektronicznych
2) IHE XDR, Cross-Enterprise Document Reliable Interchange,
3) IHE XDM, Cross-Enterprise Document Media Interchange,
4) ISO/IEEE 11073-10101 Base Terms (Nomenclature)
5) ISO/IEEE 11073-10201 Domain information model
6) Standardy pokrywające się z Continua Framework,
7) IHE PCD TF Vol1, Patient Care Device Technical Framework Volume 1,
8) IHE PCD TF Vol2, Patient Care Device Technical Framework Volume 1,
9) IHE PCD TF Vol3, Patient Care Device Technical Framework Volume 1,
10) DICOM, Digital Imaging and Communication in Medicine,
b) standardy funkcjonalne:
1) SOA, w tym zawieranie funkcjonalności związanych z integracją w postaci adapterów i
wystawianych w postaci usług oraz stosowanie standardów:
• WSDL w zakresie specyfikacji interfejsów
• XML w zakresie języka strukturalnego
• Szyn usługowych w zakresie warstwy integracji
• WS-Security w zakresie projektowania i realizacji usług bezpieczeństwa, w tym:
• SAML dla uwierzytelniania i autoryzacji użytkowników
2) oparte na modelu usługowym – platforma będzie oparta o model SOA, posiadający architekturę zorientowaną na usługi; wdrożone rozwiązanie będzie posiadało zestaw polis, praktyk i bibliotek, które pozwolą na wykorzystanie funkcjonalności aplikacji w taki sposób, aby można było z niej korzystać jako z zestawu usług, opublikowanych tak, aby poziom szczegółowości był dostosowany do potrzeb konsumenta usługi. Publikowane elementy będą niezależne od implementacji i stosować będą pojedynczy, standardowy interfejs. System będzie się opierał o interfejsy webAPI oraz o udostępnianie usług sieciowych (tzw. webservicers).
3) przystosowane do uruchomienia na platformie wirtualizacyjnej lub w chmurze – w celu zapewnienia bezpiecznego dostępu do usług udostępnianych przez system, zakłada się wykorzystanie odpowiednich technologii i urządzeń. Dzięki temu dostęp i wymieniane dane zostaną zabezpieczone w zakresie poufności, integralności i autentyczności. Jednocześnie zapewni to w połączeniu z powyższym opisem pełną interoperacyjność, w tym systemami P1 i P2 oraz zgodność z ustawą o systemie informacji w ochronie zdrowia.
Bezpieczeństwo systemu
Zgodnie z §20 Rozporządzenia Rady Ministrów z dnia 12.04.2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych oraz
normami dotyczącymi służby zdrowia, projektowany system informatyczny uwzględnia zasadę bezpieczeństwa i będzie on zgodny z normami dotyczącymi służby zdrowia:
1) ISO/IEC 27002 – poszczególne rozdziały normy są poświęcone następującym zagadnieniom:
• polityka bezpieczeństwa;
• organizacja bezpieczeństwa;
• klasyfikacja aktywów organizacji i bezpieczeństwa osobowego;
• sposoby kontroli dostępu, rozwoju i utrzymania systemu;
• warunki pracy.
2) PN-ISO/IEC 20000-1:2007 „Technika informatyczna – Zarządzanie usługami. Część 1: Specyfikacja”,
3) PN-ISO/IEC 20000-2:2007 „Technika informatyczna – Zarządzanie usługami. Część 2: Reguły postępowania”,
4) PN ISO/IEC 27001:2007 „Technika informatyczna – Techniki bezpieczeństwa – Systemy
zarządzania bezpieczeństwem informacji – Wymagania”,
5) PN-ISO/IEC 27005:2010 „Technika informatyczna – Techniki bezpieczeństwa – Zarządzanie
ryzykiem w bezpieczeństwie informacji”,
6) PN-ISO/IEC 27006:2009 „Technika informatyczna – Techniki bezpieczeństwa – Wymagania dla jednostek prowadzących audyt i certyfikację systemów zarządzania bezpieczeństwem informacji”.
Aby spełnić standardy bezpieczeństwa zostały określone poniższe wymagania:
a) dotyczące uwierzytelniania:
1) system informatyczny musi posiadać zaimplementowane mechanizmy kontroli dostępu do
danych
2) jeżeli dostęp do danych w systemie posiadają co najmniej dwie osoby, należy zapewnić,
aby:
• w systemie rejestrowany był dla każdego użytkownika odrębny identyfikator,
• dostęp do danych był możliwy wyłącznie po wprowadzeniu identyfikatora i dokonaniu uwierzytelnienia,
3) nie należy ponownie przydzielać identyfikatora użytkownika, który utracił uprawnienia do
przetwarzania danych,
4) w przypadku, gdy do uwierzytelniania użytkowników używa się hasła, system musi wymuszać jego zmianę nie rzadziej niż co 30 dni; hasło musi składać się co najmniej z 8 znaków, zawierać małe i wielkie litery oraz cyfry lub znaki specjalne,
b) dotyczące zabezpieczeń:
1) system musi posiadać ochronę przed zagrożeniami pochodzącymi z sieci publicznej opartą na fizycznych lub logicznych zabezpieczeniach chroniących przed nieuprawnionym dostępem,
2) stosuje się środki kryptograficznej ochrony wobec danych wykorzystywanych do uwierzytelnienia, które są przesyłane w sieci publicznej,
3) system musi być zabezpieczony przed:
• działaniem oprogramowania, którego celem jest uzyskanie nieuprawnionego
dostępu do systemu informatycznego,
• utratą danych spowodowaną awarią zasilania lub zakłóceniami w sieci zasilającej.
System informatyczny będzie również odpowiadać wymaganiom bezpieczeństwa na poziomie wysokim opisanym w Załączniku do Rozporządzenia Ministra Spraw Wewnętrznych i Administracji z dnia 29.04.2004 r. 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.
System zostanie wdrożony zgodnie z najlepszymi praktykami bezpieczeństwa, w zakresie technologii, jaka zostanie zastosowana do jego budowy. Szpital zwróci szczególną uwagę, aby oprogramowanie, dostarczone przez dostawcę oprogramowania zapewniało:
• wykorzystanie gotowych frameworków bezpieczeństwa np. JAAS w Javie,
• zastosowanie odpowiednich mechanizmów uwierzytelniania i autoryzacji podczas logowania się do systemu,
• w kontekście danych medycznych wykorzystanie silnych metod np. bezpieczny podpis elektroniczny,
• zastosowanie odpowiednich mechanizmów bezpiecznego przechowywania danych – dostęp do danych powinny mieć tylko uprawnione osoby, dane powinny być szyfrowane,
• w przypadku korzystania z aplikacji klient – serwer, szczególnie w modelu innym niż model klasyczny, zabezpieczenie komunikacji np.: poprzez wykorzystanie protokołu SSL (HTTPS),
• mechaniczne i automatyczne wylogowywanie się z systemu po określonym czasie nieaktywności użytkownika.
Szpital zapewni, aby podczas odbioru systemu przeprowadzono testy bezpieczeństwa systemu godnie z aktualnymi wytycznymi np. OWASP dla aplikacji webowych. Testy bezpieczeństwa będą również przeprowadzane okresowo już po wdrożeniu systemu. Środowisko, w którym będzie zainstalowany system będzie regularnie aktualizowane, w szczególności będzie posiadać najnowsze aktualizacje bezpieczeństwa. Dotyczy to systemów operacyjnych, serwerów WWW/aplikacyjnych, baz danych itd. System operacyjny zainstalowany na stacjach klienckich będzie regularnie aktualizowany, zgodnie z zaleceniami producenta. System zapewniać będzie mechanizm backupu
oraz archiwizacji danych. System będzie zabezpieczony przed działaniem oprogramowania, którego celem będzie uzyskanie nieuprawnionego dostępu do danych.
Metody uwierzytelniania danych
W ramach projektu przewidziano następujące metody uwierzytelniania danych:
1) profil zaufany e-PUAP (utworzenie Punktu Potwierdzenia Profilu Zaufanego w Szpitalu – umożliwienie pacjentom Szpitala założenie konta na e-PUAP, a następnie potwierdzenie Profilu Zaufanego, co daje możliwość załatwiania kolejnych spraw on-line),
2) metoda wykorzystująca infrastrukturę PKI, która będzie wspierała w zakresie bezpieczeństwa identyfikację i uwierzytelnianie użytkowników w systemie teleinformatycznym – wykorzystanie inteligentnych kart oraz certyfikatów cyfrowych, jako nośników tożsamości, dzięki czemu użytkownicy będą mogli uzyskać dostęp do wielu systemów i usług przy użyciu tylko jednego dokumentu elektronicznego.
Wykorzystanie infrastruktury PKI umożliwi korzystanie z takich usług jak podpis elektroniczny czy szyfrowanie danych niezbędne w przypadku danych wrażliwych pacjentów. Dzięki zastosowaniu kart z interfejsem dualnym (stykowym i bezstykowym) możliwe jest także wykorzystanie karty w systemach kontroli dostępu, kontroli wydruków i innych wymagających bezpiecznej autoryzacji. Poprzez zgodność z obowiązującymi na rynku standardami rozwiązanie będzie musiało integrować się z innymi systemami informatycznymi wzbogacając je o elementy zabezpieczeń takie jak SSL, IPSec czy VPN. Rozwiązanie to ma pomóc przygotować solidny fundament w postaci bezpiecznej infrastruktury sprzętowej i programowej – od stacji roboczej użytkownika, przez aktywne urządzenia sieciowe aż po serwery. Infrastruktura PKI będzie składała się z następujących elementów:
• Centrum Certyfikacji – element realizujący funkcjonalność modułu zarządzania kartami (CMS) oraz urzędu certyfikacyjnego (CA). Umożliwia personalizację i wydawanie kart użytkownikom oraz wydawanie certyfikatów X.509 na kartach lub w postaci plików. Moduł ten będzie zawierał narzędzia i usługi zapewniające kompleksową obsługę cyklu życia karty i certyfikatu cyfrowego od momentu rejestracji wniosku poprzez wydanie i eksploatację aż po unieważnienie i utylizację.
• Karta Inteligentna – multiaplikacyjna karta mikroprocesorowa wraz z zainstalowanymi na niej aplikacjami (liczba i typ aplikacji zależna od zastosowań). Będzie stanowić nośnik cyfrowej tożsamości użytkownika i token uwierzytelniający wykorzystywany w systemach kontroli dostępu do informacji. Karty muszą umożliwiać realizację poniższych funkcjonalności:
a) zgodność z rodziną standardów ISO:7816 – 1, 2, 3, 4, 8,
b) obsługa minimum 32 KB pamięci na dane (w tym klucze prywatne i certyfikaty),
c) generowanie par kluczy kryptograficznych RSA o długości do najmniej 2048 bitów,
d) dostęp do kart za pomocą interfejsów PKCS#11 oraz CSP (MS CryptoAPI 2.0).
• Oprogramowanie klienckie – zbiór sterowników, oprogramowania middleware i programów narzędziowych instalowanych na stacjach roboczych użytkowników. Umożliwi ono korzystanie z usług realizowanych przy pomocy karty inteligentnej tj.: uwierzytelnianie (w tym logowanie Windows), podpis elektroniczny, szyfrowanie.
• Nabiurkowe czytniki Kart Inteligentnych – czytniki umożliwiające odczyt wykorzystywanych w rozwiązaniu kart inteligentnych.
Ochrona antywirusowa
Dla zapewnienia bezpieczeństwa systemu będącego przedmiotem niniejszego studium oraz danych medycznych, które będzie on gromadził zastosowana zostanie obligatoryjnie ochrona przed kodem złośliwym, zarówno na poziomie stacji klienckich, urządzeń mobilnych oraz na poziomie serwerów. Za wybór narzędzi i oprogramowania antywirusowego odpowiadać będzie Administrator Bezpieczeństwa Systemu (ABI). Ochroną antywirusową objęta będzie również brama internetowa. Zastosowane będzie oprogramowanie antywirusowe umożliwiające skanowanie całego dopuszczalnego przez bramkę ruchu. Zostanie wdrożone oprogramowania antywirusowe, które umożliwi automatyczną aktualizację oraz posiadać będzie możliwość centralnego zarządzania i raportowania. Oprogramowanie umożliwiać będzie w szczególności:
• zmianę ustawień konfiguracyjnych,
• możliwość zdalnej instalacji przez administratora lub instalację automatyczną w momencie podłączania się komputera do sieci,
• automatyczną aktualizację,
• wymuszenie skanowania.
Oprogramowanie antywirusowe będzie regularnie aktualizowane (ręcznie lub automatyczne),
zgodnie z zaleceniami producenta:
• w zakresie definicji wirusów oraz sygnatur antywirusowych okresowo, przynajmniej raz w
tygodniu,
• w zakresie oprogramowania – niezwłocznie po opublikowaniu przez producenta aktualizacji
bezpieczeństwa.
Zakłada się, że po wdrożeniu systemu regularne będzie skanowanie komputerów oraz serwerów przy pomocy oprogramowania antywirusowego. Okres skanowania automatycznego określi dostawca oprogramowania po przeprowadzeniu analizy ryzyka. Zabronione będzie podłączanie jakichkolwiek stacji klienckich oraz serwerów bez zainstalowanego oprogramowania antywirusowego. Użytkownicy zobowiązani będą do natychmiastowego zgłaszania podejrzenia
zainfekowania swoich stacji klienckich przez xxxxxx. Prowadzone będą działania edukacyjne pracowników korzystających z systemu, celem zapoznania ich z polityką antywirusową placówki.
W przypadku, gdy usługi utrzymania, modyfikacji systemu zostaną powierzone firmie zewnętrznej będzie wprowadzony proces zarządzania usługami dostarczanymi przez strony trzecie. Proces ten nakłada na właściciela systemu obowiązek określenia odpowiedzialności w zakresie realizacji usług, określenia zakresu wymagań. Umowa podpisana ze stroną trzecią zawierać będzie co najmniej zapisy o:
• zachowaniu poufności danych,
• stosowaniu obowiązujących w organizacji określonych procedur (udostępniania powierzonych zasobów firmom i instytucjom zewnętrznym).
Szpital będzie regularnie przeglądał i monitorował usługi dostarczone przez strony trzecie, aby sprawdzać ich zgodność z zapisami umowy oraz odpowiednio reagować na problemy mogące wpłynąć na bezpieczeństwo systemu.
W celu minimalizacji ryzyka związanego z awarią systemu będą wprowadzone procedury monitorowania i planowania wydajności systemu. Dokonywane będą okresowe przeglądy zasobów (sprzętu, zasobów sieciowych, baz danych) w celu porównania wydajności urządzeń, pojemności łączy. Informacje te są konieczne w razie planowania rozbudowy systemu. Prowadzone będą regularne przeglądy umów serwisowych z dostawcami łączy, sprzętu.
W celu ograniczenia ryzyka wystąpienia awarii np.: w wyniku wprowadzonej zmiany systemu wprowadzone będą procedury zarządzania zmianami. Zarządzaniu zmianą powinny podlegać:
• sprzęt,
• oprogramowanie,
• dokumentacja,
• konfiguracja.
Proces zarządzania zmianą zawierać będzie co najmniej następujące kroki:
• planowanie zmiany,
• określenie wpływu zmiany na bezpieczeństwo systemu EDM; zaleca się sprawdzenie czy nie zostaną naruszone zasady integralności po wprowadzeniu zmiany,
• testowanie zmiany,
• zatwierdzenie zmiany przez osoby upoważnione,
• wprowadzenie zmiany,
• udokumentowanie wprowadzenia zmiany: aktualizacja dokumentacji, której dotyczy
zmiana oraz archiwizacja aktualnej dokumentacji oraz uaktualnienie dziennika zmian,
• przywrócenie poprzedniej wersji systemu w przypadku, gdy wprowadzenie zmiany
zakończyło się niepowodzeniem.
Dane osobowe
Szpital musi przestrzegać takich samych reguł dotyczących przetwarzania danych osobowych jak każdy inny administrator danych. Oznacza to, że zastosowanie będą miały przepisy ustawy o ochronie danych osobowych, które regulują kwestię x.xx. pozyskiwania danych osobowych, tj. art. 23 ust. 1 (który odnosi się do danych zwykłych, takich jak imię, nazwisko, numer PESEL, adres zamieszkania) oraz art. 27 ust. 2 (odnoszący się do danych wrażliwych, zwłaszcza informacji o stanie zdrowia, ale też o nałogach, które mogą mieć istotne znaczenie w leczeniu pacjenta).
Kwestie związane z ochroną danych osobowych i uwierzytelnianiem informacji w systemie reguluje Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29.04.2004 r. 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. Analiza założeń projektowych wskazuje, że system klasyfikuje się pod spełnienie wymagań na poziomie wysokim, który obowiązuje, „gdy przynajmniej jedno urządzenie systemu informatycznego, służącego do przetwarzania danych osobowych, połączone jest z siecią publiczną”. W przypadku systemów, w których są przetwarzane dane osobowe wymagane jest opracowanie dokumentacji, na którą składa się:
1) Polityka Bezpieczeństwa,
2) Instrukcja zarządzania systemem informatycznym służącym do przetwarzania danych
osobowych, która musi regulować następujące zagadnienia:
• procedury nadawania uprawnień do przetwarzania danych i rejestrowania tych uprawnień w systemie informatycznym oraz wskazanie osoby odpowiedzialnej za te czynności;
• stosowane metody i środki uwierzytelnienia oraz procedury związane z ich zarządzaniem i użytkowaniem;
• procedury rozpoczęcia, zawieszenia i zakończenia pracy przeznaczone dla użytkowników systemu;
• procedury tworzenia kopii zapasowych zbiorów danych oraz programów i narzędzi
programowych służących do ich przetwarzania;
• sposób, miejsce i okres przechowywania:
a) elektronicznych nośników informacji zawierających dane osobowe,
b) kopii zapasowych,
• sposób zabezpieczenia systemu informatycznego,
• procedury wykonywania i konserwacji systemów oraz nośników informacji służących do przetwarzania danych.
Jednocześnie należy podkreślić, że wdrażany przez trzebnicki szpital system będzie spełniał oprócz wymagań wnikających z ustawy o ochronie danych osobowych, ustawy o informacji w ochronie zdrowia oraz rozporządzeń wykonawczych również wymagania opisane w Normie XX-XX XXX 00000, a zatem rozwiązania wychodzące poza obowiązujące przepisy prawne. Norma dotyczy modelu funkcjonalnego systemu elektronicznej dokumentacji zdrowotnej (EHR-S – Electronic Health Record System) i zawiera listę referencyjną funkcji dla tych systemów. Zgodnie z Normą opis funkcji jest tworzony z perspektywy użytkownika i jest niezależny od technologii oraz strategii implementacji. W związku z tym, wybierając system informatyczny do gromadzenia dokumentacji medycznej, Szpital weźmie pod uwagę obligatoryjne funkcje infrastruktury informacyjnej z zakresu bezpieczeństwa dla systemu EHR opisane w tej Normie. Podstawą prawną dla opisanych w normie usług bezpieczeństwa jest dyrektywa UE [95/46/EC] dotycząca ochrony danych oraz Rekomendacja (97)5 Rady Europy dotycząca ochrony danych medycznych. Dokumenty te podkreślają, że podmiot opieki zdrowotnej, czyli pacjent, ma prawo odgrywać decydującą rolę w decyzjach o zawartości i dostępności jego elektronicznej dokumentacji zdrowotnej, jak również ma prawo być informowanym o jej zawartości. Przesyłanie danych z elektronicznej dokumentacji zdrowotnej do stron trzecich powinno następować tylko za zgodą pacjenta.
Obligatoryjne funkcje systemu z zakresu bezpieczeństwa według EN ISO 10781, które będą
wymagane przez Szpital to zapewnianie bezpieczeństwa poprzez:
a) IN.1.1 Uwierzytelnianie Podmiotu: system powinien uwierzytelniać podmioty przed ich dostępem do aplikacji lub danych systemu EHR, powinien zapobiegać dostępowi do aplikacji lub danych systemu EHR przez wszystkie podmioty nieuwierzytelnione, jeżeli brak jest odpowiednich mechanizmów uwierzytelniania, system powinien uwierzytelniać podmioty, wykorzystując co najmniej jeden z następujących mechanizmów uwierzytelniania: nazwa użytkownika/hasło, certyfikat cyfrowy, bezpieczny token lub biometria,
b) IN.1.2 Autoryzację Podmiotu: system powinien zapewniać możliwość tworzenia i aktualizacji zbiorów zezwoleń kontroli dostępu przyznanych podmiotowi, powinien zapewniać administratorom bezpieczeństwa możliwość przyznawania autoryzacji podmiotom zgodnie z zakresem zastosowania, polityką organizacyjną lub prawem, powinien zapewniać administratorom bezpieczeństwa możliwość przyznawania autoryzacji dla ról zgodnie z zakresem zastosowania, polityką organizacyjną lub prawem,
c) IN.1.3 Kontrolę Dostępu dla Podmiotu: system powinien egzekwować reguły dostępu do systemu i danych dla wszystkich zasobów systemu EHR (na poziomie komponentu, aplikacji
lub użytkownika, lokalnie albo zdalnie) w celu umożliwienia organizacji świadczącej ochronę zdrowia zarządzanie dostępem pacjenta do swoich informacji związanych z ochroną zdrowia,
d) IN.1.4 Zarządzanie Dostępem Pacjenta,
e) IN.1.5 Niezaprzeczalność: system powinien znakować początkowy wpis, modyfikację lub wymianę danych oraz identyfikować aktora/podmiot biorący w tym udział zgodnie z wymaganiami z zakresu zastosowania przez użytkowników, politykę organizacyjną i prawo, system powinien zapewniać dodatkową funkcjonalność niezaprzeczalności tam, gdzie jest to wymagane przez zakres zastosowania przez użytkowników, politykę organizacyjną i prawo,
f) IN.1.6 Bezpieczną Wymianę Danych: system powinien zabezpieczać wszystkie tryby wymiany danych EHR, system powinien szyfrować i deszyfrować dane EHR wymieniane niezabezpieczonym łączem, jeżeli do bezpiecznej wymiany danych wykorzystywane jest szyfrowanie, system powinien wspierać oparte na normach szyfrowanie zgodnie z polityką organizacyjną lub prawem, system powinien automatycznie przekazywać elektronicznie wymieniane dane EHR tylko od i do znanych źródeł i miejsc przeznaczenia i tylko bezpiecznymi sieciami,
g) IN.1.8 Poświadczanie Informacji: system powinien zapewniać możliwość powiązania każdej poświadczonej treści dodanej lub zmienionej w EHR z autorem tej treści, system powinien zapewniać możliwość poświadczania treści EHR podlegającej poświadczaniu przez autora tej treści, system powinien wskazywać status podlegających poświadczaniu danych, które nie zostały poświadczone,
h) IN.1.9 Prywatność i Poufność Pacjenta: system powinien zapewniać możliwość uzyskania pełnej zgodności z wymaganiami dotyczącymi prywatności i poufności pacjenta zgodnie z zakresem zastosowania przez użytkownika, politykę organizacyjną i prawo.
Szpital będzie wymagał także, aby oprogramowanie spełniało wymagania Norma 13606 – 4:2009. Norma 13606 – 4:2009 wychodzi z założenia, że w idealnym rozwiązaniu w zakresie bezpieczeństwa elektronicznej dokumentacji medycznej powinna istnieć możliwość skojarzenia każdej drobnej pozycji w dokumentacji pacjenta z listą kontrolną dostępu osób uprawnionych do przeglądania tych informacji.
WCAG 2.0
Jednym z istotnych obszarów, który reguluje Rozporządzenie Rady Ministrów z dnia 01.04.2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla
systemów teleinformatycznych jest kwestia zwiększenia dostępności do usług e-Administracji dla
osób niepełnosprawnych, ze szczególnym uwzględnieniem osób niewidomych i niedowidzących.
Zgodnie z zapisami rozporządzenia system teleinformatyczny podmiotu realizującego zadania publiczne służący prezentacji zasobów informacji powinien zapewniać spełnienie przez ten system wymagań Web Content Accessibility Guidelines (WCAG 2.0), z uwzględnieniem poziomu AA. Rozporządzenie wymienia 12 wytycznych dla serwisów internetowych administracji publicznej. Projektowane rozwiązanie będzie zgodne z wytycznymi dotyczącymi ułatwień w dostępie do treści publikowanych w internecie. Zastosowane rozwiązania będą zgodne ze szczegółowymi dokumentami opisującymi WCAG 2.0 w aktualnych wersjach:
• „Understanding WCAG 2.0” – xxxx://xxx.x0.xxx/XX/XXXXXXXXXXXXX-XXXX00/,
• „Techniques forWCAG 2.0” – xxxx://xxx.x0.xxx/XX/XXXX00-XXXXX/.
Zgodność projektowanego systemu z wytycznymi WCAG 2.0:
1) Tekst alternatywny
Każda treść niebędąca tekstem będzie uzupełniona tekstem alternatywnym. Dotyczy to elementów tj.: fotografie, grafiki, animacje, filmy, aplety i inne elementy. Tekst alternatywny przekazywać będzie informacje o tym, co zawiera dany element. Tworzyć się go będzie w ten sam sposób, jak podczas opisywania elementu graficznego przez telefon lub osobie niewidomej.
2) Alternatywa dla multimediów
Nagrane materiały zawierające tylko dźwięk lub tylko obraz będą zaopatrzone w transkrypcję tekstową lub audiodeskrypcję. Będą one obejmować pełne informacje na temat zawartości dźwiękowej lub wizualnej materiału, zsynchronizowane z materiałem za pomocą znaczników czasu. Nagrania dźwiękowe (audycje, wywiady, przemówienia itp.) będą uzupełnione o zsynchronizowane napisy. To rozwiązanie będzie skierowane do niesłyszących użytkowników, którzy nie są w stanie usłyszeć informacji dźwiękowej. Nagrania audiowizualne będą zaopatrzone w audiodeskrypcję, czyli w dodatkową ścieżką dźwiękową, na której lektor opisuje to, co widać na ekranie. W rozporządzeniu brak jest uregulowań dotyczących transmisji na żywo, dla których nie ma obowiązku dostarczania audiodeskrypcji i napisów. Jednak powinno to stać się powszechną praktyką, na czym zyskałyby zwłaszcza osoby niesłyszące, ponieważ dominuje tam przekaz ustny.
3) Informacja możliwa do adaptacji
Często spotykanym problemem jest projektowanie dokumentów w formie wyłącznie wizualnej, co sprawia, że są trudne do przetworzenia do innych form, np. wydrukowania, konwersji na alfabet Braille’a czy zmiany formatowania. Zgodnie z wymaganiami struktura i relacje pomiędzy elementami będą zaprogramowane lub opisane tekstem. W praktyce oznacza to, że elementy dokumentu będą tworzone za pomocą odpowiednich technik. Prawidłowa kolejność informacji będzie odpowiednio zaprogramowana. W ten sposób użytkownik w prawidłowo będzie mógł
wypełnić formularz na stronie internetowej lub odczytać dwukolumnowy tekst w pliku PDF. Instrukcje skierowane do użytkownika będą opierać się tylko na opisie wyglądu danego elementu (kształt, lokalizacja, dźwięk, wielkość). Ponieważ nie każdy użytkownik postrzega wszystkie elementy na stronie internetowej, to informacje w rodzaju „w prawym górnym rogu”, „czerwony przycisk”, „zębate kółko” itp. nie będą dostatecznie zrozumiałe.
4) Możliwość oddzielenia informacji od tła
Ważne informacje nie będą sygnalizowane wyłącznie poprzez inny kolor napisów. Wyróżnianie kolorem istotnych informacji (np. zaznaczenie błędów na czerwono) może pozostać niezauważone przez dużą grupę użytkowników, dlatego też tego rodzaju informacje będą wyróżnione także na inne sposoby, np. poprzez zmianę kroju pisma lub dodatkową informację tekstową. Dźwięk odtwarzany dłużej niż trzy sekundy będzie możliwy do wyłączenia lub ściszenia. Muzyka odtwarzana automatycznie po otworzeniu strony może uniemożliwić korzystanie z niej osobom posługującym się syntezatorami mowy, np. niewidomym. Optymalnym rozwiązaniem będzie więc rezygnacja z tego typu efektów.
Zgodnie z wymaganiami minimalny kontrast tekstu publikowanego na stronach internetowych w stosunku do tła będzie wynosić 1:4,5, a dla dużych czcionek – 1:3. Za duże czcionki uważa się czcionkę o rozmiarze przynajmniej 18 punktów lub 14 punktów pogrubioną. Tekst będzie możliwy do powiększenia dwukrotnie bez użycia specjalnego oprogramowania. Użytkownicy najczęściej robią to za pomocą mechanizmów wbudowanych w przeglądarkę internetową. Strona internetowa będzie zaprojektowana w taki sposób, aby nie wymuszała wyświetlania czcionek konkretnej wielkości.
5) Dostępność za pomocą klawiatury
Każda funkcjonalność będzie dostępna za pomocą klawiatury. Wyjątkiem będą sytuacje, w których ważne będzie to w jaki sposób przesuwany jest kursor (np. rysowanie). Niedopuszczalna będzie sytuacja, aby jakakolwiek funkcjonalność bezwzględnie wymagała użycia myszy lub panelu dotykowego. Serwis internetowy nie będzie zawierać tzw. pułapek na klawiaturę, czyli sytuacji, gdy do jakiegoś miejsca można dotrzeć za pomocą klawiatury, ale nie da się tego miejsca opuścić.
6) Wystarczający czas
Jeżeli korzystanie z serwisu będzie wymagać wykonania czynności w określonym czasie, to system zapewni możliwość zatrzymania odliczania pozostałego czasu oraz wydłużenia tego czasu. Serwis będzie informował użytkownika przed upływem określonego czasu i będzie dawał mu możliwość przedłużenia go. Ich wprowadzenie będzie szczególnie istotne w przypadku wygasających sesji oraz zmieniającej się treści. Informacja przewijana, migająca lub odświeżająca się automatycznie będzie możliwa do wstrzymania, zatrzymania lub ukrycia przez użytkownika. Dotyczy to elementów tj.: paski informacyjne, tabele kursów akcji lub bannerów informacyjnych
zmieniających się automatycznie. Taka zmieniająca się bez udziału użytkownika treść może być bowiem szczególnie dokuczliwa dla użytkowników niewidomych i słabowidzących.
7) Ataki epilepsji
Treść serwisu nie będzie zawierać elementów migających częściej niż trzy razy na sekundę lub niespełniających minimalnych wartości dla czerwonych rozbłysków. W praktyce dosyć trudno jest oszacować te progowe wartości, więc Szpital prawdopodobnie całkowicie zrezygnuje z tego rodzaju treści. Migające i rozbłyskające elementy są szczególnie częste w animacjach i filmach, chociaż zdarza się także umieszczanie migającego tekstu.
8) System nawigacji
Serwis będzie posiadać mechanizmy pozwalające pominąć stałe elementy interfejsu. Rozwiązaniem, które zastosuje Szpital będą tzw. skiplinki umieszczane na początku strony. Pozwolą one na pominięcie stałych elementów, jak menu nawigacji i przejście do części głównej. Każda strona będzie posiadać tytuł określający jej zawartość. Przez tytuł należy tu rozumieć tekst wyświetlany na pasku tytułu przeglądarki, a umieszczony w danych nagłówkowych. Pasek tytułu będzie stałym elementem interfejsu i łatwo będzie do niego dotrzeć. System nawigacji będzie jasno wskazywać, czego dotyczy treść danej strony oraz być unikalny dla całego serwisu. Fokus, czyli punkt zainteresowania przeglądarki internetowej, na którym wykonywane są różnego rodzaju akcje będzie przemieszczany w sposób zgodny z logiką dokumentu. Graficznie widoczny będzie, jako obrys danego elementu. Fokus będzie przesuwany za pomocą klawiszy, w tym przede wszystkim klawisza TAB w sposób sekwencyjny. Ta sekwencyjność będzie zgodna z logiką dokumentu lub kolejności wprowadzania danych. Fokus będzie możliwy do przemieszczenia także za pomocą myszki poprzez kliknięcie na odpowiedni element, ale tu nie jest istotna sekwencyjność. Funkcja ukryta pod tekstem linku będzie zrozumiała przy odczytaniu tekstu lub otoczenia bezpośrednio z nim powiązanego. Linki w rodzaju „kliknij”, „tutaj”, „PDF” same w sobie nie niosą żadnej konkretnej informacji i dlatego w serwisie będą zastąpione przez „kliknij, aby pobrać formularz”, „tutaj znajdziesz dane teleadresowe”, „sprawozdanie w formacie PDF”. Do każdej strony w serwisie będzie można dotrzeć przynajmniej na dwa sposoby. Systemu nawigacji i wyszukiwania informacji będzie skonstruowany w taki sposób, aby mógł pozwolić na łatwiejsze docieranie do konkretnych informacji. Służyć temu będą chmury tagów, logiczne menu, wyszukiwarka, dokumenty powiązane. Etykiety i nagłówki tj.: „menu główne”, „wyszukiwarka”, „dane teleadresowe”, które prawidłowo opisują treść dokumentów będą jasno identyfikować następującą po nich treść.
9) Informacja możliwa do odczytania i zrozumienia
Zgodnie z wymaganiami język dokumentu będzie prawidłowo zadeklarowany, a fragmenty dokumentów napisane w języku innym, niż określony dla całego dokumentu, również będą prawidłowo zadeklarowane. Oba warunki dotyczą wszelkiego rodzaju dokumentów
elektronicznych, w których istnieje techniczna możliwość takiej deklaracji. Dotyczy to dokumentów HTML, XHTML, PDF, DOC, DOCX, ODF. Nie dotyczy zaś plików w formatach typu plain-text, na przykład TXT, CSV czy LOG. Prawidłowa deklaracja języka będzie pozwalać na automatyczne przełączanie się syntezatorów mowy na odpowiedni język, a także będzie ułatwiać indeksowanie zasobów przez wyszukiwarki internetowe.
10) Przewidywalne zachowanie
Umieszczenie fokusu na obiekcie nie będzie zmieniać kontekstu strony. W praktyce oznacza to, że nie ma możliwości wywołania nieprzewidzianych reakcji serwisu, np. otwarcia nowej strony, otwarcia dokumentu w nowym oknie lub istotnej zmiany treści. Zmiana wartości w formularzu nie będzie wywoływać automatycznie zmiany kontekstu. Zaznaczenie opcji, wpisanie danej lub inna akcja przeprowadzona wewnątrz formularza nie będzie powodować zakłóceń w rodzaju istotnej zmiany treści, otwarcia nowego okna przeglądarki itp. W całym serwisie będzie zastosowana konsekwentna nawigacja, czyli menu nawigacyjne będzie w tych samych miejscach, a inne linki i przyciski będą znajdować się tam, gdzie użytkownik może się ich spodziewać. Serwisy będą zapewniać konsekwentną identyfikację elementów powtarzających się. Elementy interfejsu (ikony, przyciski, linki) będą pełniły tę samą funkcję.
11) Pomoc dla użytkownika
Wykryty przez system błąd we wprowadzanych danych będzie sygnalizowany użytkownikowi za pomocą tekstu. Użytkownik będzie otrzymywać jasny komunikat o tym, jaki błąd popełnił, np. „nie podałeś numeru PESEL”. Niedopuszczalne będzie ograniczenie informacji do zaznaczenia jej innym kolorem lub prostego komunikatu, że pojawił się błąd. Jeżeli użytkownik będzie musiał podać dane, prezentowane będą etykiety i instrukcje mówiące o tym, co należy podać (na przykład „nazwisko”, „numer PESEL”, „numer skierowania”) oraz jak to zrobić (np. „bez myślników”, „tylko duże litery”, „w formacie rrrr-mm-dd”). Jeżeli system wykryje błąd to będzie mógł zasugerować prawidłową wartość, chyba że wiązałoby się to z naruszeniem zasad bezpieczeństwa. Przykładowo: system będzie mógł zasugerować użytkownikowi nazwy miejscowości z danego powiatu do wyboru. System będzie pomagał zapobiegać błędom mającym skutki prawne lub finansowe, dając możliwość wycofania danych, ich sprawdzenia lub potwierdzenia. W sytuacjach, gdy operacje wykonane na stronie internetowej będą mogły rodzić skutki prawne (składanie wniosków, oświadczeń itp.), użytkownik serwisu będzie mógł sprawdzić podane dane przed ostatecznym zatwierdzeniem. Można to osiągnąć np. poprzez wyświetlenie kompletu informacji i przycisku zatwierdzającego, jako ostatniego etapu operacji.
12) Kompatybilność treści ze specyfikacjami
Ta część wymagań będzie skierowana do programistów, którzy tworzą serwisy internetowe, aplikacje webowe i komputerowe. Redaktorzy zazwyczaj nie mają już wpływu na te elementy.
Zgodnie z wymaganiami Dokumenty oparte na znacznikach (na przykład HTML, XML, ODT) powinny być zgodne z ich specyfikacjami. Jeżeli jest to obowiązkowe, znaczniki powinny być podomykane, zastosowane powinny zostać odpowiednie atrybuty oraz określony typ dokumentu. Każdy aktywny element interfejsu powinien mieć zdefiniowaną nazwę i rolę, a ich wartości powinny być dostępne dla technologii asystujących. Takimi elementami są przyciski, linki, pola formularzy i inne elementy, z którymi użytkownik może wchodzić w interakcje. Część z tych informacji zapewnia specyfikacja HTML, a pozostałe powinny być uzupełnione za pomocą atrybutów ARIA.
Ponadto zostanie zastosowane rozwiązanie przystosowania systemu do współpracy z urządzeniami typu speech to text (rozpoznawanie mowy przy wprowadzaniu podstawowych informacji do systemu). Funkcja umożliwi przetwarzanie mowy w tekst. Technologia Speech to text ułatwia osobom niedowidzącym korzystanie z komputerów stacjonarnych oraz laptopów.
Funkcjonalność rozwiązań oraz zorientowanie na użytkownika
Oprócz już wspomnianych funkcjonalności rozwiązań dotyczących bezpieczeństwa oraz dostępności dla osób niepełnosprawnych zostaną także zastosowane inne rozwiązania w zakresie zastosowania chmury obliczeniowej oraz kompatybilności z urządzeniami mobilnymi.
Proponowane dla projektu rozwiązanie konfiguracji i eksploatacji zasobów infrastruktury sprzętowej bazuje na rozwiązaniu tzw. chmury obliczeniowej prywatnej, której administrowanie (konfiguracja, przydział zasobów i uprawnień) realizowane będzie przez wykwalifikowanych pracowników. Wymagania dla infrastruktury sprzętowej przeznaczonej dla udostępniania usług systemu zostały ściśle ukierunkowane na technologię chmury obliczeniowej poprzez:
1. zapewnienie wirtualizacji środowiska serwerowego w celu maksymalnego wykorzystania
zasobów serwerów dedykowanych dla implementacji i eksploatacji usług systemu;
2. zapewnienie możliwości elastycznego skalowania zasobów (procesory, pamięć RAM, przestrzeń dyskowa, itp.) w zależności od potrzeb eksploatacji danej usługi systemu;
3. zapewnienie możliwości automatycznego tworzenia nowych wirtualnych maszyn jak i usuwania starych w zależności od potrzeb;
4. zapewnienie możliwości przydzielania dostępu do usług systemu użytkownikom w zależności od potrzeb i przeznaczenia;
5. zapewnienie ochrony danych dzięki zaprojektowaniu dedykowanego podsystemu backupu.
Dzięki nowoczesnej architekturze systemowej wykorzystującej technologię chmury obliczeniowej możliwe będzie optymalizowanie wykorzystania infrastruktury sprzętowej i jej wyskalowania dla potrzeb eksploatacji e-usług systemu.
Szybki wzrost możliwości technicznych i dostępności urządzeń mobilnych oraz szybkość, bezpieczeństwo i niezawodność bezprzewodowych połączeń, wychodzi naprzeciw dzisiejszym potrzebom służby zdrowia. Dzięki technologiom bezprzewodowym i urządzeniom mobilnym
personel medyczny może posiąść szybszy dostęp do kluczowych informacji, przez co ma możliwość poświęcania większej ilości czasu pacjentowi. Wykorzystanie technologii mobilnej pozwala zwracać większą uwagę na pacjentów i oferować im bardziej spersonalizowaną opiekę. Zakłada się, iż system posiadł będzie parametry i spełniał założenia niezbędne dla zapewnienia pełnej kompatybilności urządzeń mobilnych z usługami systemu. Dzięki e-usługom kompatybilnym z urządzeniami mobilnymi pracownicy Szpitala oraz pacjenci będą mieli możliwość korzystania z usług systemu w szpitalu oraz poza nim z zachowaniem aspektów bezpieczeństwa przetwarzania danych, co przyczyni się do zwiększenia dostępności i jakości świadczonych usług medycznych, a tym samym motywacji pacjentów do dbania o własne zdrowie. Dodatkowo ułatwi kontakt między lekarzami oraz lekarzami i pacjentami.
Poza tym dzięki zaplanowanym działaniom i zaawansowanym mechanizmom monitorującym dostępności sytemu Administrator oraz osoby upoważnione będą miały możliwość ciągłej weryfikacji poprawności działania oraz wykorzystania e-usług pod kątem dostępności i użyteczności graficznych interfejsów dla wszystkich interesariuszy, ciągłości działania i powszechności wykorzystania. Dostępność usług będzie realizowana z poziomu przeglądarek internetowych (Portal Informacyjny), co pozwala na dostarczenie e-usług do szerszego grona użytkowników końcowych (pacjenta, fizjoterapeuty, lekarza). Dostęp wielokanałowy poprzez portal WWW (uniezależniony od dostawcy przeglądarki) pozwala na uniezależnienie się od lokalizacji, z której będzie korzystał użytkownik końcowy. Dostępność do e-usług przy użyciu portalu WWW spełnia oczekiwania użytkowników, którzy chcą uniezależnić się od dedykowanych urządzeń dostępowych. Poza tym system, a co za tym idzie udostępniane usługi i funkcjonalności, zakłada czas pracy użytkowej i bezawaryjnego działania przez 24 godziny na dobę, 7 dni w tygodniu, 365 dni w roku. Jest to zgodne z oczekiwaniami i potrzebami pracowników szpitala ze względu na charakter ich pracy, w tym funkcjonowania szpitalnego oddziału ratunkowego. Również pacjenci cenią sobie elastyczność i możliwość dostępu do platformy i e-usług w dowolnie wybranej porze. Maksymalna dostępność jest też czynnikiem istotnym dla przedsiębiorców.
Minimalne wymagania funkcjonalności systemu informatycznego
Oprogramowanie użytkowe na potrzeby Zintegrowanego Systemu Usług Informatycznych Szpitala im. św. Jadwigi Śląskiej w Trzebnicy będzie posiadać moduły i funkcjonalności zgodne z opisem zawartym w pkt VI.
III. SPECYFIKACJA INFRASTRUKTURALNA
Proponowane dla projektu rozwiązanie konfiguracji i eksploatacji zasobów infrastruktury sprzętowej będzie bazować na wykonaniu środowiska wirtualnego na dostarczanym sprzęcie.
Dzięki wykorzystaniu 3 fizycznych serwerów połączonych z macierzą uzyskane będzie bezpieczne i bardzo wydajne środowisko wirtualne (chmura obliczeniowa).
Wirtualizacja oferuje ogromną elastyczność i wygodę zarządzania i utrzymania infrastruktury IT. Konsolidacja serwerów poprzez wirtualizację jest traktowana jako kamień milowy ekologicznych inicjatyw w zasobach IT. Nawet niewielki współczynnik konsolidacji, np. 7:1 (siedem wirtualnych maszyn na jednym serwerze fizycznym) skutkuje podobnym współczynnikiem redukcji zużycia prądu przez serwery. To bardzo dobry początek przystosowywania infrastruktury IT do pobierania znacznie mniejszych ilości prądu i ograniczenia kosztów utrzymania infrastruktury.
Zastosowanie środowiska wirtualnego daje możliwość stworzenia rozwiązania High Availability (wysokiej dostępności), które oferuje ekonomiczny, automatyczny mechanizm szybkiego ponownego uruchamiania wszystkich aplikacji w przypadku awarii sprzętu lub systemu operacyjnego, np. w przypadku awarii jednego z serwerów fizycznych pracującego w klastrze niezawodnościowym HA, pozostałe serwery przejmują jego obowiązki bez przestojów w pracy. Element ten jest bardzo ważną składową dla tworzenia bezpiecznych rozwiązań dedykowanych dla szpitali, gdzie kluczowe jest przechowywanie danych medycznych w formie elektronicznej.
Dzięki zastosowaniu rozwiązania wykorzystującego wirtualizację środowiska uzyskujemy dostęp do powstałej w ten sposób chmury obliczeniowej, która pozwala dodatkowo na optymalizowanie wykorzystania infrastruktury sprzętowej i jej optymalne wyskalowanie dla potrzeb eksploatacji e-usług systemu. Chmura obliczeniowa w sposób znaczący zwiększa dostępność do wdrażanego środowiska poprzez możliwość korzystania z niej z urządzeń mobilnych (smartphone, tablet) jak również z terminali, notebooków i desktopów.
Rysunek 3: Zastosowanie chmury obliczeniowej w projekcie.
Uzupełnieniem powyższego rozwiązania będzie zastosowanie zaawansowanego środowiska do backupu, które będzie gwarantować bezpieczeństwo gromadzonych i przechowywanych danych przez długie lata zgodnie z wymaganiami ustawowymi.
Na potrzeby wyżej wymienionego środowiska zostaną dostosowane dwa pomieszczenia, obecnie wykorzystywane jako serwerownie, które zostaną wyposażone w odpowiednie szafy RACK do montażu sprzętu, jak również klimatyzację, kontrolę dostępu i monitoring. Jedno z pomieszczeń będzie stanowiło serwerownię główną, a drugie – serwerownię zapasową z odpowiednim podziałem urządzeń, które zapewnią ciągłość pracy środowiska w przypadku awarii.
Obie serwerownie staną się głównymi punktami dystrybucyjnymi (GPD1, GPD2). Do serwerowni przy wykorzystaniu planowanych do wykonania połączeń światłowodowych zostaną podłączone pośrednie punkty dystrybucyjne (PPD), do których będą podłączone końcówki klienckie na terenie całego szpitala poprzez wykorzystanie sieci kablowej. Na terenie szpitala do punktów PPD zostaną również podłączone urządzenia dostępowe Wifi (AP), które umożliwią korzystanie ze środowiska pacjentom i pracownikom jednostki z wykorzystaniem urządzeń mobilnych. Poprzez wykorzystanie nowoczesnych metod zabezpieczeń wykonania powstała infrastruktura będzie spełniała wszystkie wymagania związane systemami przetwarzającymi dane osobowe, a w szczególności z:
• Rozporządzeniem Rady Ministrów z dnia 12.04.2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych, w obszarze zarządzania bezpieczeństwem informacji,
• Rozporządzeniem Ministra Spraw Wewnętrznych i Administracji z dnia 29.04.2004 r. 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.
Lp. | Opis/Wymagania | Szczegóły |
Serwer – 1 szt. | ||
Obudowa | -typu Rack, wysokość 2U | |
Płyta główna | - dwuprocesorowa, wyprodukowana i zaprojektowana przez producenta serwera, możliwość instalacji procesorów dwunastordzeniowych - minimum 6 złącz PCI Express generacji 3 low profile, w tym minimum 3 złącza o prędkości x 16 i 3 złącza o prędkości x 8 - możliwość integracji dedykowanej, wewnętrznej pamięci flash przeznaczonej dla wirtualizatora (niezależne od dysków twardych) - zintegrowany układ TPM 2.0 | |
Procesory | - zainstalowane dwa procesory 8-rdzeniowe w architekturze x 86 osiągające w oferowanym serwerze w testach wydajności SPECint_rate2006 min. 519 pkt | |
Pamięć RAM | - zainstalowane 68 GB pamięci RAM typu DDR4 Registered, 2133Mhz w kościach o pojemności 8 GB - wsparcie dla technologii zabezpieczania pamięci Advanced ECC, Memory Scrubbing, SDDC - wsparcie dla konfiguracji pamięci w trybie „Rank Sparing” -24 gniazda pamięci RAM na płycie głównej, obsługa minimum 768GB pamięci RAM DDR4 | |
Dyski twarde | - minimum 4 wnęki dla dysków twardych Hotplug 3,5 - 5 dysków min. 600 GB 10k SAS - możliwość rozbudowy do 12 wnęk Hotplug 3,5 w obrębie obudowy 2U | |
Kontrolery LAN | - trwale zintegrowana karta LAN, niezajmująca żadnego z dostępnych slotów PCI Express, wyposażona minimum w interfejsy: 2 x 1Gb/s LAN, ze wsparciem iSCSI i iSCSI boot i teamingu, RJ-45 - dodatkowa karta sieciowa 2x10Gbit/s SFP+ | |
Kontrolery I/O | - dwukanałowy kontroler FC 8Gbit/s | |
Porty | - zintegrowana karta graficzna ze złączem VGA; dodatkowe złącze VGA z przodu obudowy - 7 x USB, w tym minimum 5x USB w standardzie 3.0 w tym 2 na panelu przednim, minimum 1 wewnętrzne, 2 dostępne z tyłu serwera - 1 x RS-232-C (możliwość wykorzystania przez kartę zarządzającą serwera) | |
Zasilanie, chłodzenie | - redundantne zasilacze hotplug o sprawności 94% (tzw. klasa Platinum) o mocy maksymalnej 800W | |
Oprogramowanie | Do wirtualizacji Wymaga się dostarczenia oprogramowania do wirtualizacji zasobów serwerowych z licencją uprawniająca do bezterminowego, nieograniczonego czasowo korzystania z oprogramowania z możliwość instalacji oprogramowania na 3 dowolnych hostach posiadających do 2 procesorów każdy, wraz z centralnym systemem zarządzającym; możliwość przenoszenia instalacji oprogramowania pomiędzy serwerami; najnowsza, dostępna w momencie składania oferty wersja oprogramowania. Oprogramowanie musi wspierać systemy: Windows 2012, Linux, jak również współpracować z dostarczanym oprogramowaniem do Backupu. System operacyjny Musi umożliwiać odtwarzanie pojedynczych elementów Active Directory zainstalowanych w środowiskach wirtualnych (Hyper-V) poprzez backup całej maszyny wirtualnej. System powinien posiadać możliwość wykonania backupu Active Directory a następnie odzyskania pojedynczych obiektów AD bez restartu i resynchronizacji systemu. Backup ten powinien być wykonywany jednoprzebiegowo. Musi zapewniać wsparcie dla technologii wirtualizacyjnych firmy Microsoft (Hyper-V), z możliwością odtwarzania pojedynczych plików z maszyn wirtualnych Windows z jednoprzebiegowego backupu. Musi być kompatybilny z najnowszymi wersjami oprogramowania Windows Serwer 2012. Instalacja i konfiguracja systemów operacyjnych wraz z odpowiednią wirtualizacją na potrzeby prawidłowego działania systemu zintegrowanego. Wymagane jest dostarczenie 200 licencji dostępowych. | |
Serwer – 2 szt. | ||
Obudowa | - typu Rack, wysokość 2U | |
Płyta główna | - dwuprocesorowa, wyprodukowana i zaprojektowana przez producenta serwera, możliwość instalacji procesorów dwunastordzeniowych - minimum 6 złącz PCI Express generacji 3 low profile, w tym minimum 3 złącza o prędkości x16 i 3 złącza o prędkości x 8 | |
- możliwość integracji dedykowanej, wewnętrznej pamięci flash przeznaczonej dla wirtualizatora (niezależne od dysków twardych) - zintegrowany układ TPM 2.0 | ||
Procesory | - zainstalowane dwa procesory 8-rdzeniowe w architekturze x 86 osiągające w oferowanym serwerze w testach wydajności SPECint_rate2006 min. 519 pkt | |
Pamięć RAM | - zainstalowane 68 GB pamięci RAM typu DDR4 Registered, 2133Mhz w kościach o pojemności 8 GB - wsparcie dla technologii zabezpieczania pamięci Advanced ECC, Memory Scrubbing, SDDC - wsparcie dla konfiguracji pamięci w trybie „Rank Sparing” - 24 gniazda pamięci RAM na płycie głównej, obsługa minimum 768 GB pamięci RAM DDR4 | |
Dyski twarde | - minimum 4 wnęki dla dysków twardych Hotplug 3,5 - możliwość rozbudowy do 12 wnęk Hotplug 3,5 w obrębie obudowy 2U | |
Kontrolery LAN | - trwale zintegrowana karta LAN, niezajmująca żadnego z dostępnych slotów PCI Express, wyposażona minimum w interfejsy: 2x 1Gb/s LAN, ze wsparciem iSCSI i iSCSI boot i teamingu, RJ-45 - dodatkowa karta sieciowa 2x10Gbit/s SFP+ | |
Kontrolery I/O | - dwukanałowy kontroler FC 8Gbit/s | |
Porty | - zintegrowana karta graficzna ze złączem VGA; dodatkowe złącze VGA z przodu obudowy -7 x USB, w tym minimum 5 x USB w standardzie 3.0 w tym 2 na panelu przednim, minimum 1 wewnętrzne, 2 dostępne z tyłu serwera; Ilość dostępnych złącz USB nie może być osiągnięta poprzez stosowanie zewnętrznych przejściówek, rozgałęziaczy czy dodatkowych kart rozszerzeń zajmujących jakikolwiek slot PCI Express serwera - 1 x RS-232-C (możliwość wykorzystania przez kartę zarządzającą serwera) | |
Zasilanie, chłodzenie | - redundantne zasilacze hotplug o sprawności 94% (tzw. klasa Platinum) o mocy maksymalnej 800W | |
Oprogramowanie | System operacyjny Musi umożliwiać odtwarzanie pojedynczych elementów Active Directory zainstalowanych w środowiskach wirtualnych (Hyper-V) poprzez backup całej maszyny wirtualnej. System powinien posiadać możliwość wykonania backupu Active Directory a następnie odzyskania pojedynczych obiektów AD bez restartu i resynchronizacji systemu. Backup ten powinien być wykonywany jednoprzebiegowo. Musi zapewniać wsparcie dla technologii wirtualizacyjnych firmy Microsoft (Hyper-V), z możliwością odtwarzania pojedynczych plików z maszyn wirtualnych Windows z jednoprzebiegowego backupu. Musi być kompatybilny z najnowszymi wersjami oprogramowania Windows Serwer 2012. Instalacja i konfiguracja systemów operacyjnych wraz z odpowiednią wirtualizacją na potrzeby prawidłowego działania systemu zintegrowanego. | |
Macierz – 1 szt. | ||
Obudowa | - zestaw dysków twardych HDD i/lub dysków SSD kontrolowanych przez minimum pojedynczą parę kontrolerów macierzowych kontrolujących wszystkie zasoby dyskowe macierzy bez korzystania z zewnętrznych połączeń kablowych pomiędzy dowolnymi kontrolerami - macierz musi posiadać architekturę modułową w zakresie obudowy dla instalacji kontrolerów oraz obsługiwanych dysków, z dopuszczeniem współdzielenia jednego z modułów przez zainstalowane kontrolery i dyski | |
- system musi być dostarczony ze wszystkimi komponentami do instalacji w standardowej szafie rack 19 z zajętością maks. 2U w tej szafie - każdy skonfigurowany moduł/obudowa musi posiadać układ nadmiarowy zasilania i chłodzenia zapewniający bezprzerwową pracę macierzy bez ograniczeń czasowych w przypadku utraty redundancji w danym układzie (zasilania lub chłodzenia) - obudowa powinna posiadać widoczne elementy sygnalizacyjne do informowania o stanie poprawnej pracy lub awarii/macierzy - rozbudowa o dodatkowe moduły dla obsługiwanych dysków powinna odbywać się wyłącznie poprzez zakup takich modułów bez konieczności zakupu dodatkowych licencji lub specjalnego oprogramowania aktywującego proces rozbudowy - moduły dla dalszej rozbudowy o dodatkowe dyski i przestrzeń dyskową muszą mieć obudowy o zajętości w szafach przemysłowych standardu 19” nie większej niż 2U przy gęstości upakowania do 25 dysków 2,5” lub 12 dysków 3,5” oraz nie większej niż 4U w przypadku modułów tzw. wysokiej gęstości dedykowanych dla instalacji minimum 50 dysków 3,5” - w przypadku konfiguracji macierzy z dwoma kontrolerami wszystkie zewnętrzne połączenia kablowe pomiędzy modułami muszą pozwalać na połączenie kaskadowe jaki i w układzie tzw. pętli – należy zapewnić minimum 2-torową redundancję takich połączeń - połączenia kablowe pomiędzy modułami muszą zapewniać przepustowość minimum 48Gb/s w ramach pojedynczego połączenia | ||
Pojemność | - macierz musi obsługiwać min. 140 dyski wykonane w technologii hot- plug, także w konfiguracji z jednym kontrolerem macierzy - macierz musi obsługiwać przestrzeń dyskową w trybie surowym (tzw. RAW) minimum 860TB bez konieczności wymiany zainstalowanych kontrolerów – wymagana zgodność z zapisami w aktualnej na moment składania oferty specyfikacji technicznej macierzy udostępnionej publicznie na stronie internetowej producenta lub jego przedstawiciela w Polsce - macierz musi umożliwiać rozbudowę do wyższego modelu z tej samej rodziny urządzeń w trybie w „data-in-place” tj. z wykorzystaniem wszystkich modułów półek rozszerzeń dyskowych wykorzystywanych przed rozbudową i z dostępem do wcześniej zapisanych pojemność użyteczna wszystkich zainstalowanych w macierzy dysków hot-plug (pojemności wynikające z zastosowanego poziomu zabezpieczenia RAID dla grup dyskowych) musi być w 100% dostępna dla zapisu danych użytkownika | |
Kontrolery | - kontrolery macierzy muszą obsługiwać tryb pracy w układzie active- active lub mesh-active, macierz musi być dostarczona z zainstalowanymi minimum 2 kontrolerami - każdy z kontrolerów macierzy musi posiadać po minimum 4GB pamięci podręcznej Cache – zawartość pamięci Cache z danymi do zapisu na dyskach musi być identyczna (tzw. cache mirror) dla wszystkich kontrolerów macierzy - macierz musi obsługiwać rozbudowę pamięci podręcznej cache dla operacji odczytu do minimum 800GB poprzez instalację dodatkowych modułów pamięci w kontrolerach lub wykorzystanie pojemności zainstalowanych dysków SSD - w przypadku awarii zasilania dane niezapisane na dyski, przechowywane w pamięci podręcznej Cache dla zapisów muszą być zabezpieczone metodą trwałego zapisu na dysk lub równoważny nośnik niewymagający korzystania z podtrzymania jego zasilania – tj. bez zasilania zewnętrznego lub bateryjnego - kontrolery muszą posiadać możliwość ich wymiany (w przypadku awarii lub planowych zadań utrzymaniowych) bez konieczności wyłączania |
zasilania całego urządzenia – wymaganie w przypadku konfiguracji z min. 2 kontrolerami - macierz musi obsługiwać wymianę kontrolera RAID bez utraty danych zapisanych na dyskach w przypadku awarii macierzy z jednym zainstalowanym kontrolerem - każdy z kontrolerów RAID powinien posiadać dedykowane minimum 2 interfejsy RJ-45 Ethernet obsługujący połączenia z prędkością 100Mb/s i 1Gb/s ami – dla zdalnej komunikacji z oprogramowaniem zarządzającym i konfiguracyjnym macierzy - kontrolery macierzy muszą być oparte o procesor wykonany w technologii wielordzeniowej z minimum 4 rdzeniami - każdy kontroler macierzy musi pozwalać na konfigurację interfejsów niezbędnych dla współpracy w sieci IP/FC SAN oraz NAS, - dla obsługi operacji blokowych I/O w sieci IP/FC SAN kontrolery macierzy muszą wspierać protokoły transmisji: FC, iSCSI, FCoE, SAS | ||
Interfejsy | - minimum 2 porty FC 8Gb/s, do dołączenia serwerów bezpośrednio lub do dołączenia do sieci SAN, wyprowadzone na każdy kontroler RAID - macierz musi umożliwiać wymianę portów do transmisji danych na porty obsługujące protokoły: FC 8Gb/s, iSCSI 1 Gb/s, iSCSI 10Gb/s FCoE 10Gb/s, SAS 6Gb/s - wymiana portów jak w pkt.2 nie może powodować wymiany samych kontrolerów RAID w oferowanym rozwiązaniu, w przypadku konieczność licencjonowania tej funkcjonalności macierz ma być dostarczona z aktywną licencja na instalację i obsługę każdego z wymienionych protokołów transmisji danych - dla obsługi protokołów NFS i CIFS model oferowanej macierzy musi pozwalać na instalację minimum 4 interfejsów Ethernet 10Gb bądź minimum 8 portów Ethernet 1Gb/s – porty muszą być wyprowadzone na kontrolerach macierzy | |
Poziomy RAID | macierz musi zapewniać poziom zabezpieczenia danych na dyskach definiowany poziomami RAID: 0, 1 ,1+0, 5 , 50, 6 | |
Wspierane dyski | 1) wszystkie dyski wspierane przez oferowany model macierzy muszą być wykonane w technologii hot-plug i posiadać podwójne porty SAS obsługujące tryb pracy full-duplex 2) macierz musi wspierać dyski hot-plug: - dyski elektroniczne SSD SAS o pojemności min. 400 GB - dyski mechaniczne HDD SAS o pojemności min. 300 GB i prędkości obrotowej 15k rpm - dyski mechaniczne HDD SAS o pojemności min. 300GB i prędkości obrotowej 10k rpm - dyski mechaniczne HDD NLSAS o pojemności min. 1TB i prędkości obrotowej min. 7,2k krpm 3) Macierz musi obsługiwać dyski hot-plug SSD i HDD wyposażone w porty SAS 12Gb/s zainstalowane w dowolnym module rozwiązania 4) model macierzy musi pozwalać na instalację dysków hot-plug w formacie 2,5” i 3,5” 5) macierz musi obsługiwać min. 48 dysków SAS SSD w całym rozwiązaniu, 6) macierz musi wspierać mieszaną konfigurację dysków SAS, NearLine- SAS i SSD w obrębie każdego pojedynczego modułu obudowy pozwalającego na instalacje dysków hot-plug 7) macierz musi wspierać technologię energooszczędne typu Drive Spin Down lub wyłączanie dysków nieaktywnych w trybie ręcznym i automatycznym z wykorzystaniem mechanizmu typu „time scheduler” czyli w zadanym i/lub powtarzalnym oknie czasowym 8) macierz musi umożliwiać skonfigurowanie każdego zainstalowanego dysku hot-plug jako dysk hot-spare (dysk zapasowy) w trybach: |
- hot-spare dedykowany dla zabezpieczenia tylko wybranej grupy dyskowej RAID - hot-spare dla zabezpieczenia dowolnej grupy dyskowej RAID 9) w przypadku awarii dysku fizycznego i wykorzystania wcześniej skonfigurowanego dysku zapasowego wymiana uszkodzonego dysku na sprawny nie może powodować powrotnego kopiowania danych z dysku hot-spare na wymieniony dysk (tzw. CopyBackLess) 10) macierz dostarczona musi być wyposażoną w co najmniej: 5 dysków 2.5” o prędkości obr. 7200 obr/min o pojemności 2TB, 11 dysków o prędkości 10 000 obr/min o pojemności 460GB | ||
Switch centralny – 1 szt. | ||
Wymagania fizyczne dotyczące urządzenia | ▪ 24 x 10 Gb/s SFP+ ▪ 4 x 10Gb/s Ethernet mogą być współdzielone ▪ Port USB ▪ Port RS-232 ▪ Wymaga się aby przełącznik posiadał możliwość instalacji redundantnego zasilacza wymianę ▪ Przełącznik powinien mieć możliwość tworzenia stosu minimum 4 urządzeń. Minimalna wydajność stosu w trybie full duplex to 80Gb/s | |
Wymagania dotyczące obsługiwanych standardów oraz funkcji | 🟃 IEEE 802.1Q (do 4k VLAN ID) 🟃 IEEE 802.1p (CoS) 🟃 IEEE 802.1D Spanning Tree Protocol 🟃 IEEE 802.1v Protocol VLAN & Port VLAN 🟃 Voice VLAN 🟃 Guest VLAN 🟃 IP subnet VLAN 🟃 VLAN w oparciu o MAC 🟃 IEEE 802.1 Q-in-Q 🟃 IEEE 802.1w Rapid Spanning Tree 🟃 IEEE 802.1s Multiple Spanning Tree 🟃 IEEE 802.3ad (Static lub LACP) do 48 trunks 🟃 IEEE 802.1x 🟃 IGMP v1, v2, v3 snooping support 🟃 IGMP querier 🟃 Ochrona przed burzami broadcast, multicast oraz unicast 🟃 Filtering multicast 🟃 Port locking 🟃 Ograniczenie przepustowości na wejściu co 1 Kb/s 🟃 GARP/GVRP/GMRP 🟃 DHCP snooping 🟃 IP source guard 🟃 Dynamic ARP inspection 🟃 TACACS+ 🟃 LLDP 🟃 LLDP-MED 🟃 ISDP 🟃 sFlow 🟃 DoS 🟃 Private group 🟃 Protected port 🟃 DHCP L2 relay | |
Backup – 1 szt. | ||
Wymagania | Rozwiązanie musi reprezentować architekturę trójwarstwową (serwer zarządzający, serwer medialny oraz klient), taka architektura pozwoli na elastyczną skalowalność rozwiązania bez względu na dynamikę przyrostu danych. Rozwiązanie musi zapewnić interfejs graficzny do zarządzania i instalacji. | |
Oprogramowanie musi umożliwiać zdalne instalowanie i odinstalowywanie klienta backupowego z serwera backupowego dla systemów Windows, Linux i Unix – musi być to możliwe z jednego serwera pełniącego rolę cache dla wszystkich binarii klienckich. System musi zapewniać funkcjonalność odtwarzania po awarii konfiguracji serwera zarządzającego tworzeniem kopii bezpieczeństwa i archiwów. System musi umożliwić przechowywanie jedynie unikalnych bloków danych tzw. deduplikacja. Funkcjonalność ta musi działać na poziomie blokowym i być wykonywana online podczas procesu tworzenia kopii danych. Deduplikacja musi być realizowana poprzez oprogramowanie systemu na dowolnym sprzęcie czy to w warstwie serwera backupowego czy klienta backupu. Pojedynczy serwer systemu musi umożliwiać przechowywanie danych po deduplikacji minimum do 80 TB (rozbudowa do tej wielkości może nastąpić tylko poprzez dodanie dodatkowych dysków czy macierzy dyskowej). System musi umożliwiać wykonywanie kopii w post procesie do drugiej lokalizacji przesyłając jedynie unikalne bloki danych. A więc replikacja danych do innej lokalizacji musi być wykonywana na danych po deduplikacji i funkcjonalność ta musi być realizowana i zarządzana z poziomu systemu. System musi posiadać funkcję szyfrowania i kompresji danych transmitowanych przez LAN, możliwość wykorzystania szyfrowania i kompresji musi być dostępna w dowolnej kombinacji. Szyfrowanie danych musi być wykonywane minimum kluczem o długości 256 bitów, system musi pozwalać na wybór algorytmu (minimum dwa algorytmy: Blowfish, AES) także dla danych deduplikowanych na kliencie systemu. System musi posiadać możliwość wykonywania kopii oraz archiwów na urządzenia dyskowe. System musi umożliwiać współdzielenie napędów taśmowych w sieciach SAN pomiędzy serwerami medialnymi. System powinien umożliwiać obsługę urządzeń składowania danych w chmurze. System musi posiadać wbudowany mechanizm tworzenia kopii otwartych plików na platformie Windows. System musi wspierać wykonanie kopii na systemach klasy Linux i Unix. | ||
Napęd LTO – 1 szt. | ||
Typ napędu | LTO6 FC | |
Liczba napędów | 1 | |
Liczba slotów | 8 slotów wszystkie aktywne | |
Liczba magazynków | 2 | |
Liczba slotów Import/Export | 1 | |
Obudowa | Rack 19” | |
Dodatkowe parametry | Wbudowany skaner kodów paskowych na nośnikach LTO, Lokalne zarządzanie za pomocą panelu/pulpitu operatora, Obsługa szyfrowania danych na nośniku LTO, Obsługa nośników LTO WORM, | |
Interfejs zdalnego zarządzania | Ethernet 10/100Mb/s złącze RJ-45 | |
UTM/Firewall – 1 szt. | ||
Wymagania | Możliwość łączenia w klaster Active-Active lub Active-Passive każdego z elementów systemu. Monitoring i wykrywanie uszkodzenia elementów sprzętowych i programowych systemów zabezpieczeń oraz łączy sieciowych. Monitoring stanu realizowanych połączeń VPN. System realizujący funkcję Firewall powinien dawać możliwość pracy w jednym z dwóch trybów: Routera z funkcją NAT lub transparent. System realizujący funkcję Firewall powinien dysponować minimum 18 portami Ethernet 10/100/1000 Base-TX. Możliwość tworzenia min 254 interfejsów wirtualnych definiowanych jako VLANy w oparciu o standard 802.1Q. W zakresie Firewall’a obsługa nie mniej niż 2,5 miliona jednoczesnych połączeń oraz 20 tys. nowych połączeń na sekundę. Przepustowość Firewall’a: nie mniej niż 1 Gbps dla pakietów 512 B. | |
Switch dystrybucyjny – 14 szt. | ||
Wymagania | • Ilość portów 52; (48x1G, 2x10GBASE-T, 2xSFP+) • Chłodzenie od przodu do tyłu obudowy • Redundantny wewnętrzny zasilacz • Budżet mocy PoE przy zastosowaniu zasilacza 550W: 480W • Tablica MAC min. 16K • Tablica ARP/NDP min. 2K • Bufor 16Mb • MTBF min. 673207 godzin • Wydajność min. 130,9 Mp/s • Przepustowość min. 176 Gb/s • Port USB • Port miniUSB • Port zarządzania Out-of-band; • Web GUI • HTTPs • CLI • Telnet • SSH • SNMP • MIB RSPAN • Radius • TACACS+ • DiffServ • Możliwość limitowania przepustowości do 1 Kbps w oparciu o harmonogram • IPv4/IPv6 Multicast filtering • IGMPv3 MLDv2 Snooping • ASM & SSM • IGMPv1,v2 Querier • Auto-VoIP • Auto-iSCSI • Policy-based routing (PBR) • LLDP-MED • Spanning Tree • Green Ethernet • STP • MTP • RSTP • PV(R)STP • BPDU/STRG Root Guard • EEE (802.3az) | |
• GVRP/GMRP • Q in Q • Private VLAN • DOT1X • MAB • Captive Portal • DHCP Snooping • Dynamic ARP • Inspection • IP Source Guard • CPU min 800 Mhz • Min 1GB RAM • Min 256MB Flash • Min ilość obsługiwanych VLAN 4K • DHCP Server min 2K rezerwacji • sFlow • Minimalna ilość przełączników w stosie: 8 • Możliwość łączenia w stos przełączników z dominującymi portami 10Gb/s oraz 1Gb/s • Możliwość łączenia w stos za pomocą interfejsów 10Gb/s • Możliwość łączenia przełączników w stos w konfiguracji: pierścień, podwójny pierścień, mesh • Non-stop forwarding (NSF) • Distributed Link Aggregation (LAGs across the stack) • Ilość interfejsów IP 128 • Double VLAN Tagging (QoQ) • PIM-DM (Multicast Routing - dense mode) • PIM-DM (IPv6) • PIM-SM (Multicast Routing - sparse mode) • PIM-SM (IPv6) • RIPv1 • RIPv2 • OSPFv2 • RFC 2328 • RFC 1583 • OSPFv3 • OSPFv2 min. sąsiadów 400 • OSPFv3 min. sąsiadów 400 • OSPFv3 min. sąsiadów na interfejs 100 • UDLD • LLPF • DHCPv6 Snooping • Wysyłanie alertów na email • MMRP • Ilość ACL min. 100 • Ilość reguł na listę min. 1023 na wejściu i 511 na wyjściu | ||
Kontroler Wi-Fi – 1 szt. | ||
Wymagania | • 4 x Gigabit RJ45 10/100/1000 • Pamięć minimum RAM 1 GB DDR2 • Minimum 1 Port USB • Kontroler powinien mieć możliwość obsługi do 40 punktów dostępowych w standardzie oraz do 50 przez zakup dodatkowych licencji • Kontroler powinien być zabezpieczony przed awarią za pomocą drugiego takiego samego kontrolera • Połączenie w stos powinno być realizowane za pomocą | |
protokołu VRRP • Kontroler powinien umożliwić obsługę minimum 128 profili bezpieczeństwa SSID • Ilość profili bezpieczeństwa dla stosu powinna wynosić nie mniej niż 512 • Urządzenie powinno umożliwić wgranie minimum 7 planów pięter dla 3 budynków • Kontroler powinien obsługiwać Captive portal • W przypadku wykorzystania punktów dostępowych dwuzakresowych maksymalna ilość obsługiwanych użytkowników na kontroler bez dodatkowych licencji powinna wynieść minimum 1280 • Urządzenie powinno obsłużyć minimum 64 VLAN oraz jeden VLAN administracyjny | ||
Punkty dostępowe Wi-Fi Access Point – 40 szt. | ||
Wymagania | • 1 x 10/100/1000BASE-T z obsługą IEEE 802.3af • Obsługa SSH • Dwa złącza reverse SMA • Pobór mocy PoE nie większy niż 10,51W • Wewnętrzne anteny o mocy minimum 5dBi • IEEE 802.11n 2.4 oraz 5 GHz • IEEE 802.11g, IEEE 802.11b, 2.4 GHz oraz 5GHz • WMM • Obsługa WPA, WPA2 • Autentykacja IEEE 802.1x RADIUS z obsługą EAP TLS, TTLS, PEAP • Autentykacja na podstawie MAC • Wsparcie VPN pass-through • Obsługa Secure SSH, SSL • Praca w trybie Point-to-point bridge • Praca w trybie Point-to-multipoint bridge • Praca w trybie Repeater • Jednoczesny tryb bridge oraz access point • Wireless Distribution System (WDS) • Możliwość regulacji mocy nadawania od 100 mW do 0 mW • 16 x SSID • Wsparcie dla minimum 17 VLAN • Wykrywanie obcych AP | |
Zestaw komputerowy nr 1 – 100 szt. | ||
Wymagania | Typ: Komputer stacjonarny. Wydajność obliczeniowa: Procesor powinien osiągać w teście wydajności co najmniej wynik 5450 pkt Passmark CPU Mark. Pamięć operacyjna: 4GB 1600 MHz możliwość rozbudowy do min 32GB. Parametry pamięci masowej: Min. 500GB SATA, 7200 obr./min. dysk hybrydowy (SSHD) - wbudowana w dysk pamięci SSD o pojemności co najmniej 8 GB; zawierający partycję RECOVERY umożliwiającą odtworzenie systemu operacyjnego fabrycznie zainstalowanego na komputerze po awarii bez dodatkowych nośników. Wydajność grafiki: Grafika zintegrowana z procesorem powinna umożliwiać pracę na 3 monitorach ze wsparciem dla DirectX 12, Open CL 2.0, OpenGL 4.4 – z możliwością dynamicznego przydzielenia do 1,7 GB pamięci. Wyposażenie multimedialne: Karta dźwiękowa zintegrowana z płytą główną, zgodna z High Definition, porty słuchawek i mikrofonu na przednim oraz na tylnym panelu obudowy, obudowa wyposażona w głośnik. Obudowa: | |
- typu SFF z obsługą kart PCI Express wyłącznie o niskim profilu, wyposażona w min. 3 kieszenie: 1 szt. 5,25” zewnętrzne typu SLIM, 1 szt. 3,5” wewnętrzne, 1 szt. 3,5” zewnętrzne - zasilacz o mocy minimum 280W pracujący w sieci 230V 50/60Hz prądu zmiennego i efektywności min. 92%, przy 50% obciążeniu - w celu szybkiej weryfikacji usterki w obudowę komputera musi być wbudowany akustyczny system diagnostyczny, służący do sygnalizowania i diagnozowania problemów z komputerem i jego komponentami. Zgodność z systemami operacyjnymi i standardami: Oferowane modele komputerów muszą posiadać certyfikat Microsoft, potwierdzający poprawną współpracę oferowanych modeli komputerów z systemem operacyjnym Windows 7 32bit i 64bit (załączyć wydruk ze strony Microsoft WHCL) oraz Windows 8.1 64bit (załączyć wydruk ze strony Microsoft WHCL) oraz Windows 10 64bit (załączyć wydruk ze strony Microsoft WHCL). Klawiatura, w układzie polski programisty, trwałe oznaczenie klawiatury logo producenta. Mysz optyczna z technologią Blue LED, do 2000 dpi, 10 programowalnych klawiszy, rolka (scroll), funkcja scroll'a czterokierunkowego, trwałe oznaczenie myszy logo producenta, USB. | ||
Zestaw komputerowy nr 2 – 15 szt. | ||
Wymagania | Typ: Komputer stacjonarny. Procesor ze zintegrowanym układem graficznym, dedykowany do pracy w komputerach stacjonarnych, w architekturze x 64 o wydajności min. 7000 pkt w teście PassMark. Pamięć RAM: - min. 8GB 2133 MHz możliwość rozbudowy do min 64GB, możliwość pracy w trybie dual channel - możliwość zastosowania pamięci ECC min. 2 wolne złącza dla rozszerzeń pamięci. Dysk twardy: 1TB (min. 7200 rpm) SATA III (6Gbit) dysk hybrydowy (SSHD) - wbudowana w dysk pamięci SSD o pojemności co najmniej 8 GB, zawierający partycję RECOVERY umożliwiającą odtworzenie systemu operacyjnego fabrycznie zainstalowanego na komputerze po awarii bez dodatkowych nośników. Napęd optyczny: DVD-RW typu slim. Płyta główna: wbudowane złącza: - 1 złącze PCI-Express 3.0 x4 (mech. x16) - 1 złącze PCI-Express 3.0 x16 - 1 złącze M.2-2280 umożliwiający zamontowanie modułu PCIe lub dysku SSD Oferowany komputer musi umożliwiać instalację dysków SSD w postaci kart ze złączem PCI Express oraz kart graficznych do zastosowań profesjonalnych. minimum 4 złącza DIMM z obsługą do 64GB DDR4 pamięci RAM, min. 5 złączy SATA 3.0 NCQ z obsługą macierzy RAID 0/1/10/5, w tym min 2 złącza eSATA, płyta musi być trwale oznaczona logo producenta komputera. Karta dźwiękowa zintegrowana z płytą główną, zgodna z High Definition, porty słuchawek i mikrofonu na przednim oraz na tylnym panelu obudowy, obudowa wyposażona w głośnik. Karta sieciowa 10/100/1000 Ethernet RJ 45, zintegrowana z płytą główną, wspierająca obsługę WoL (funkcja włączana przez użytkownika). Grafika zintegrowana z procesorem powinna umożliwiać pracę na 3 monitorach ze wsparciem dla DirectX 12, Open CL 2.0, OpenGL 4.4 – z możliwością dynamicznego przydzielenia do 1,7 GB pamięci. Klawiatura, w układzie polski programisty, trwałe oznaczenie klawiatury logo producenta. | |
Mysz optyczna z technologią Blue LED, do 2000 dpi, 10 programowalnych klawiszy, rolka (scroll), funkcja scroll'a czterokierunkowego, trwałe oznaczenie myszy logo producenta, USB. | ||
Oprogramowanie antywirusowe – 135 szt. | ||
Wymagania | Pakiet oprogramowania antywirusowego wraz z lokalnym firewall’em umożliwiający użytkowanie rozwiązania na 200 stacjach roboczych i dostarczonych serwerach kompatybilny z systemami operacyjnymi dostarczonymi w ramach postępowania oraz zgodnego z systemami operacyjnymi które obecnie posiada Zamawiający, tj. 1x Windows Server 2003, 9x Windows Server 2012 R2 , Windows XP, Windows Vista, Windows 7, Windows 8.1 Aktualizacja oprogramowania i bazy wirusów przez okres 24 miesięcy. Ochrona przed wirusami, trojanami, robakami i innymi zagrożeniami. Wykrywanie i usuwanie niebezpiecznych aplikacji typu adware, spyware, dialer, phishing, narzędzi hakerskich, backdoor itp. Wbudowana technologia do ochrony przed rootkitami. Wykrywanie potencjalnie niepożądanych, niebezpiecznych oraz podejrzanych aplikacji. Skanowanie w czasie rzeczywistym otwieranych, zapisywanych i wykonywanych plików. Możliwość skanowania całego dysku, wybranych katalogów lub pojedynczych plików „na żądanie” lub według harmonogramu. | |
Drukarka sieciowa monochromatyczna – 25 szt. | ||
Technologia druku | Laserowa, druk monochromatyczny | |
Podstawowe funkcje urządzenia | Drukarka | |
Wspierane systemy operacyjne | Mac OS, Windows , Linux | |
Szybkość druku | Minimum 36 stron/min. | |
Drukowanie dwustronne | Automatyczne drukowanie dwustronne | |
Szybkość druku dwutronnego | Minimum 15 stron/min | |
Minimalna wydajność | 50 000 stron miesięcznie | |
Interfejsy / Komunikacja | 1 x USB 2.0, 1 x RJ45 (karta sieciowa) | |
Rozmiar papieru | A4 | |
Standardowa pojemność podajników papieru | Minimum 100 szt. | |
Zainstalowana pamięć | 64 MB | |
Rozdzielczość drukarki | 0000x0000 dpi | |
Obsługiwane nośniki | Papier zwykły, koperty | |
Urządzenie wielofunkcyjne – 3 szt. | ||
Technologia druku | Laserowa, druk monochromatyczny | |
Podstawowe funkcje urządzenia | Drukarka, Skaner, Kopiarka | |
Wspierane systemy operacyjne | Mac OS, Windows , Linux | |
Szybkość procesora | Co najmniej 300 MHz | |
Szybkość druku | Minimum 36 stron/min. | |
Drukowanie dwustronne | Automatyczne drukowanie dwustronne | |
Minimalna wydajność | 50 000 stron miesięcznie | |
Interfejsy / Komunikacja | 1 x USB 2.0, 1 x RJ45 (karta sieciowa), | |
Rozmiar papieru | A4 | |
Standardowa pojemność podajników papieru | 250 szt. | |
Zainstalowana pamięć | 256 MB | |
Rozdzielczość drukarki | 0000x0000 dpi | |
Skaner | Kolorowy płaski z automatycznym podajnikiem dokumentów (ADF) . Skanowanie dwustronne automatyczne. | |
Wydajność skanera | Minimum 36 str/min (w czerni), Minimum 18 str/min (w kolorze) | |
Obsługiwane nośniki | Papier zwykły, koperty | |
Skaner dokumentów dla EDM (EOD) – 4 szt. | ||
Typ skanera | Skaner z podajnikiem arkuszowym na format A4 | |
Rozdzielczość optyczna | Do 600 dpi | |
Automatyczny podajnik dokumentów | Skanowanie dwustronne jednoprzebiegowe | |
Obsługiwane formaty | A4, A5, A6, B5, A8 (tylko Windows), Legal, Letter, 10 × 15, Wizytówka, Karta plastikowa, B4 i A3 z funkcją łączenia skanów | |
Infokiosk – 3 szt. | ||
Obudowa | 1. stabilna obudowa oparta na konstrukcji stalowej, odpornej na akty wandalizmu, uniemożliwiająca niepowołany dostęp do wnętrza Kiosku (w tym do jednostki sterującej oraz do monitora) i zapewniająca odpowiednią | |
wentylację zamontowanych podzespołów, zabezpieczająca je przed przegrzaniem 2. obudowa Kiosku nie może posiadać elementów, które mogą zostać uszkodzone bez wykorzystania narzędzi 3. konstrukcja obudowy powinna uniemożliwiać dostęp osobom niepowołanym do śrub oraz innych elementów montażowych kiosku oraz jego wyposażenia 4. obudowa musi posiadać drzwiczki zamykane na zamek zapewniające dostęp serwisowy do wnętrza kiosku 5. obudowa musi być przystosowana do doprowadzenia sieci Ethernet zakończonej wtyczką RJ45 oraz zasilania elektrycznego od dołu podstawy 6. na zewnątrz obudowy nie może być widocznego innego okablowania niż opisane powyżej 7. obudowa musi umożliwiać zamontowanie (zakotwiczenie) do podłoża lub winny sposób uniemożliwiający przesuwanie kiosku 8. obudowa musi być wyposażona w monitor z nakładką dotykową umieszczoną na wysokości rąk użytkownika 9. obudowa musi być wyposażona w system zapewniający odpowiednią wentylację | ||
Gniazda zewnętrzne | RJ45 oraz zasilanie elektryczne | |
Komputer | − Procesor w architekturze x86, dwurdzeniowy − RAM 3 Gb DDR3 1600 − Dysk twardy 250 Gb 7200 rpm − System Windows 7, 8, Linux, MacOS − Monitor LCD 19 cali − Rozdzielczość 1280x1024 − Obsługa za pomocą ekranu dotykowego − Wyposażony w głośniki | |
Czytnik kodów kreskowych – 20 szt. | ||
Wymagania | Czytnik kodów paskowych stacjonarny: • Skaner kodów 1D, 2D • Interfejs USB • Zgodność ze szpitalnymi systemami informatycznymi | |
Drukarka kodów kreskowych – 6 szt. | ||
Wymagania | - zgodność z dostarczanym szpitalnym systemem informatycznym - elastyczne opcje interfejsów (USB 2.0, opcjonalnie Ethernet lub WI-FI) - wysokiej jakości druk tekstu i kodów kreskowych - temperatura pracy: 5° do 40°C - wilgotność pracy: 20% do 85% bez kondensacji | |
Tabela 4: Zestawienie infrastruktury informatycznej.
Prace adaptacyjno-montażowe w serwerowniach GPD1 i GPD2 obejmują:
a) montaż drzwi PPOŻ wyposażonych w następujące elementy:
• zamek z wkładka antywłamaniową klasy C,
• samozamykacz,
• dodatkowy zamek z elektrozaczepem rewersyjnym stanowiący drugi punkt podparcia zgodnie z przepisami PPOŻ,
• od zewnątrz klamka,
• od wewnątrz klamka,
b) zabezpieczenie podłogi wykładziną antyelektrostatyczną o parametrach pozwalających na zastosowanie jej w pomieszczeniu serwerowni,
c) montaż systemu klimatyzacji wraz z instalacją i konfiguracją o mocy chłodniczej dostosowanej do kubatury pomieszczenia,
d) montaż szafy serwerowej o parametrach:
• wysokość 42U,
• szerokość – 800 mm,
• głębokość – 1000-1200 mm (dostosowana do wielkości dostarczanych serwerów),
• szafa przeznaczona do zastosowań wewnątrz pomieszczeń serwerowych,
e) montaż systemu bezpieczeństwa technicznego i monitoringu środowiskowego o
funkcjonalności:
• pomiar temperatury i wilgotności w pomieszczeniu serwerowni,
• pomiar temperatury i wilgotności w szafach teleinformatycznych (każda szafa monitorowana w jednym punkcie),
• detekcja dymu i temperatury w pomieszczeniu serwerowni oraz w każdej szafie,
• detekcja zalania w pomieszczeniu serwerowni – dwa punkty weryfikacji,
• powiadamianie o zaistniałych anomaliach za pomocą wiadomości tekstowych SMS oraz e-mail,
• prezentacja aktualnych parametrów środowiskowych z poziomu przeglądarki WWW,
• możliwość zmiany wartości progowych,
f) montaż systemu Kontroli Dostępu do pomieszczenia serwerowni – czytnik kart zbliżeniowych. System ma na celu ograniczenie dostępu do wskazanych pomieszczeń dla osób nieuprawnionych. Pracownikom wejście do pomieszczeń umożliwią karty zbliżeniowe systemu kontroli dostępu przykładane do odpowiednich czytników kart, a umieszczonych przy drzwiach wejściowych dla danego obszaru. Po przyłożeniu karty kontroli dostępu do czytnika i poprawnej weryfikacji użytkownika przez system, mechanizm blokujący otwarcie drzwi zostanie zwolniony na okres kilku sekund, w którym to okresie będzie możliwe otwarcie drzwi.
g) wykonanie w pomieszczeniu serwerowni systemu sygnalizacji włamania i napadu w oparciu o centralę sterującą systemem; do centrali podłączone będą następujące elementy systemu:
1) czujka ruchu,
2) manipulator z wyświetlaczem,
3) sygnalizator optyczno-akustyczny.
Sieć okablowania poziomego (szkieletowego) dla sieci logicznej LAN będzie zgodna z wymogami klasy EA i obejmie wykonanie we wskazanych lokalizacjach co najmniej 60 punktów
logicznych, gniazd końcowych. Gniazda zamontowane będą w puszkach natynkowych w miejscu instalacji punktu logicznego. Sieć okablowania światłowodowego musi objąć połączenie wszystkich punktów dystrybucyjnych z serwerownią. W ramach wykonanego połączenia należy podłączyć co najmniej 3 pary włókien światłowodowych do przełącznic. Dla bezpośredniego połączenia pomiędzy serwerowniami należy podłączyć co najmniej 6 par włókien światłowodowych. Kable należy ułożyć w kanałach PCV, z zachowaniem wymogów wynikających z normy dotyczącej układania okablowania strukturalnego przestrzegając zachowania minimalnych promieni gięcia kabla. Rezerwa wypełnienia listew nie powinna być mniejsza niż 40%. Kable sieci logicznej należy oddzielić od przewodów elektrycznych przy użyciu separatora. Głównymi elementami okablowania strukturalnego będą:
1) uniwersalny kabel optyczny (światłowodowy) 24 włóknowy G50/125 OM3, LSHF,
2) KABEL S/FTP FRNC KAT6A DRUT (skrętka) lub równoważny,
3) moduł Keystone RJ45, kat. 6A, bez narzędziowy GHMT,
4) 19" panel modularny na 24xRJ45, ekranowany, 1U.
Pośrednie punkty dystrybucyjne (PPD – 12 szt.) poza urządzeniami sieciowymi będą wyposażone
w:
• szafy wiszące 12-15U (w zależności od możliwości zabudowy),
• 19’’ poziomy organizator kabli , 1U, uszy plastik, czarny, musi być trwale oznakowany logo
systemu,
• kabel krosujący Kat.6A S/FTP; 0,5; 1,0; 2,0 i 3,0,
• przełącznica światłowodowa do zakończenia kabla FO na końcówkach LC – kompletna,
• kable krosujące MM zakończone po obu stronach stykami LC dupleks.
IV. SZKOLENIA DLA PRACOWNIKÓW SZPITALA
Personel Szpitala weźmie udział w testowaniu i wdrażaniu oprogramowania informatycznego, a następnie w szkoleniach z zakresu stosowania nowoczesnych rozwiązań IT w procesie świadczenia elektronicznych usług publicznych. Szkolenia te przyczynią się do podniesienia wiedzy i umiejętności pracowników Szpitala (zarówno pracowników części „szarej” jak i „białej”) we wskazanym zakresie. Uczestnikami szkoleń będzie 250 pracowników części „białej” (medycznej) i
24 pracowników części „szarej” (niemedycznej). Łącznie wsparciem zostanie objętych 274
pracowników Szpitala.
Pracownicy części „białej” (250 osób) wezmą udział w następujących szkoleniach:
1) Stosowanie narzędzi elektronicznych w pracy Szpitala (16 h) – celem szkolenia jest nabycie praktycznych umiejętności i niezbędnej wiedzy w obsłudze wdrożonego oprogramowania informatycznego oraz uruchomionych e-usług (16 grup po 12-16 osób każda),
2) Bezpieczeństwo przetwarzania informacji (8 h) – celem szkolenia jest nabycie umiejętności w zakresie zasad bezpieczeństwa przetwarzania informacji w systemach teleinformatycznych (16 grup po 12-16 osób każda),
3) Zarządzanie dokumentami elektronicznymi (8 h) – celem szkolenia jest poznanie zasad obiegu dokumentacji w systemie EZD oraz zdobycie podstawowej wiedzy i umiejętności w zakresie zarządzania dokumentacją od chwili jej wytworzenia do przekazania do archiwum (16 grup po 12-16 osób każda),
4) Kontroling i planowanie w systemach informatycznych (8 h) – celem szkolenia jest nabycie umiejętności obsługi nowoczesnych metod i narzędzi zarządzania w systemie informatycznym z zakresu planowania, budżetowania, monitorowania oraz kontroli procesów Szpitala (szkolenie dla kierowników oddziałów szpitalnych – 11 osób).
Pracownicy części „szarej” (24 osoby) wezmą udział w następujących szkoleniach:
1) Stosowanie narzędzi elektronicznych w pracy Szpitala (16 h) – celem szkolenia jest nabycie praktycznych umiejętności i niezbędnej wiedzy w obsłudze wdrożonego oprogramowania informatycznego oraz uruchomionych e-usług (2 grupy po 11 osób każda),
2) Bezpieczeństwo przetwarzania informacji (8 h) – celem szkolenia jest nabycie umiejętności w zakresie zasad bezpieczeństwa przetwarzania informacji w systemach teleinformatycznych (2 grupy po 11 osób każda),
3) Zarządzanie dokumentami elektronicznymi (8 h) – celem szkolenia jest poznanie zasad obiegu dokumentacji w systemie EZD oraz zdobycie podstawowej wiedzy i umiejętności w zakresie zarządzania dokumentacją od chwili jej wytworzenia do przekazania do archiwum (2 grupy po 11 osób),
4) e-Szpital (8 h) – celem szkolenia jest nabycie umiejętności w zakresie informowania pacjentów i przedsiębiorców o dostępnych e-usługach Szpitala (szkolenie dla 5 osób),
5) Budowanie analiz na podstawie systemu informatycznego i planowanie długofalowe (8 h)
– celem szkolenia jest nabycie umiejętności w zakresie wykorzystania systemu informatycznego do długofalowego planowania (szkolenie dla kadry zarządzającej – 3 osoby),
6) Zarządzanie środowiskiem serwerowym, bazą danych (32 h) – celem szkolenia jest nabycie umiejętności posługiwania się najważniejszymi narzędziami pracy administratora w zaimplementowanym systemie informatycznym (szkolenie dla pracowników ds. IT – 2 osoby).
Uczestnicy szkoleń otrzymają materiały szkoleniowe, na zakończenie projektu – zaświadczenia o ukończeniu szkoleń.
V. PROMOCJA PROJEKTU
Dla pacjentów:
1) przygotowanie i wydruk materiałów promocyjnych – 3500 szt. ulotek,
2) przygotowanie i wydruk instrukcji dla użytkowników e-usług i Profilu Zaufanego; instrukcje (1750 szt.).
Dla przedsiębiorców:
1) przygotowanie i wydruk instrukcji dla użytkowników e-usług i Profilu Zaufanego; instrukcje
(250 szt.).
VI. FUNKCJONALNOŚCI OPROGRAMOWANIA IT
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
1. | Wymagana ogólne | 1. System spełnia wymagania: a. Ustawy z dnia 15 kwietnia 2011 o działalności leczniczej (Dz. U. Nr 112 poz. 654), b. Ustawy z dnia 28 kwietnia 2011 o systemie informacji w ochronie zdrowia (Dz. U. Nr 113 poz. 657), c. Ustawy z dnia 5 grudnia 1996 r. o zawodach lekarza i lekarza dentysty (Dz. U. z 2008 r. Nr 136, poz. 857, z późn. zm.), d. Ustawy o świadczeniach opieki zdrowotnej finansowanych ze środków publicznych z dnia 27 sierpnia 2004 r. (Dz.U. Nr 210, poz. 2135) tekst jednolity z dnia 25 sierpnia 2008 r. (Dz.U. Nr 164, poz. 1027 z późn. zm.), e. Ustawy z dnia 6 listopada 2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta (Dz. U. z 2009 r. Nr 52, poz. 417 i Nr 76, poz. 641, z 2010 r. Nr 96, poz. 620 oraz z 2011 r. Nr 112, poz. 654), f. Ustawy o statystyce publicznej z dnia 29 czerwca 1995 r. (Dz.U. Nr 88, poz. 439 z późn. zm.), g. Ustawy o ochronie danych osobowych z dnia 29 sierpnia 1997 r. (Dz.U. Nr 133, poz. 883) tekst jednolity z dnia 17 czerwca 2002 r. (Dz.U. Nr 101, poz. 926 z późn. zm.), h. Rozporządzenia Ministra Zdrowia z dnia 21 grudnia 2010 r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania (Dz. U. Nr 252 poz. 1697), i. Rozporządzenia Ministra Zdrowia 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 20 czerwca 2008 r. (Dz.U. Nr 123, poz. 801 z późn. zm.), j. Rozporządzenia Ministra Zdrowia z dnia 6 maja 2008 r. w sprawie ogólnych warunków umów o udzielanie świadczeń opieki zdrowotnej (Dz. U. Nr 81 poz. 484), k. Rozporządzenia Ministra Zdrowia z dnia 8 marca 2012 r. w sprawie recept lekarskich (Dz.U. 2012 poz. 260), l. Rozporządzenia Ministra Zdrowia z dnia 29 września 2011 r. w sprawie szczegółowego zakresu danych objętych wpisem do rejestru podmiotów wykonujących działalność leczniczą oraz szczegółowego trybu postępowania w sprawach dokonywania wpisów, zmian |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
w rejestrze oraz wykreśleń z tego rejestru (Dz. U. Nr 221, poz. 1319), m. Rozporządzenia Ministra Zdrowia z dnia 17 maja 2012 r. w sprawie systemu resortowych kodów identyfikacyjnych dla zakładów opieki zdrowotnej oraz szczegółowych zasad ich nadawania, Rozporządzenia Rady Ministrów w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz. U. z 16 maja 2012 poz. 526) , n. Rozporządzenia Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. 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 r. Nr 100, poz. 1024), o. Zarządzeń Prezesa Narodowego Funduszu Zdrowia w sprawie warunków postępowania dotyczących zawierania umów o udzielanie świadczeń opieki zdrowotnej. 2. System musi spełniać wymogi do prowadzenia dokumentacji w wersji elektronicznej oraz normy PN EN 13606. 3. System musi mieć możliwość pracy użytkowej przez 24 godziny na dobę, 7 dni w tygodniu, 365 dni w roku. 4. W Systemie muszą być zaimplementowane mechanizmy walidacji haseł zgodnie z wymaganiami ustawowymi przewidzianymi dla rodzaju danych przetwarzanych przez System. 5. System musi umożliwiać odwzorowanie struktury organizacyjnej Zamawiającego. 6. Językiem obowiązującym w Systemie, w chwili jego odbioru, musi być język polski. Dotyczy to wszystkich menu, ekranów, raportów, wszelkich komunikatów, wprowadzania, wyświetlania, sortowania i drukowania. Polskie znaki diakrytyczne będą, w chwili instalacji, dostępne w każdym miejscu i dla każdej funkcji w Systemie łącznie z wyszukiwaniem, sortowaniem (zgodnie z kolejnością liter w polskim alfabecie), drukowaniem i wyświetlaniem na ekranie. 7. System musi tworzyć i utrzymywać log systemowy (datę i godzinę z dokładnością do sekundy; adres IP stacji lub jej nazwa, unikalny identyfikator użytkownika; jeżeli dane w Systemie uległy zmianie to również informacje o tym, z jakiej wartości i na jaką wartość została dokonana zmiana), rejestrujący w szczególności zapisy o zalogowaniu do Systemu i wylogowaniu z Systemu każdego z użytkowników. 8. System musi mieć możliwość utrzymania następujących przedmiotowych zbiorów słownikowych przez administratora: ▪ płatników (w tym oddziałów NFZ) i umów z nimi zawartych, ▪ jednostek i lekarzy kierujących. ▪ katalogów badań, ▪ katalogu leków, w tym receptariusza szpitalnego, ▪ cenników. 9. System musi mieć możliwość definiowania listy personelu białego (w szczególności lekarzy, pielęgniarek, położnych, techników) i ich specjalności zgodnie ze słownikiem i wymaganiami NFZ. 10. System musi być zintegrowany, przez co rozumie się zintegrowaną pracę wszystkich systemów/modułów w oparciu o swobodną, automatyczną wymienialność danych pomiędzy elementami (modułami) systemu także pomiędzy modułami części „Białej” i „Szarej”. |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
11. Wykonawca zapewni, że do utrzymania baz danych zastosowane zostaną powszechnie znane na rynku, komercyjne silniki bazodanowe z bezterminową licencją, gwarantującą dostęp dla wszystkich użytkowników (np. licencja na lokalizację), a utrzymanie ww. silników u Zamawiającego musi być możliwe, przez co najmniej dwa inne podmioty niezależne od Wykonawcy. 12. Dostarczone oprogramowanie bazodanowe musi być ogólnodostępnym rozwiązaniem komercyjnym innego producenta niż oferowany system, umożliwiającym obsługę baz innych systemów i aplikacji dostępnych na rynku 13. System posiada możliwość uruchamiania wielu instancji serwera bazy danych na jednym serwerze (jednostce sprzętowej lub maszynie wirtualnej) 14. System posiada możliwość podłączenia wielu baz danych do jednej instancji serwera bazy danych 15. Oprogramowanie bazy danych udostępnia narzędzia pozwalające administratorowi na „tuning” bazy danych 16. System musi być oparty o jeden rekord pacjenta, raz wprowadzone dane są dostępne w każdym module. 17. System musi posiadać interfejs graficzny dla wszystkich modułów systemu. 18. System Informatyczny musi pracować w środowisku graficznym MS Windows na stanowiskach użytkowników lub przeglądarkę internetową (WWW) 19. System Informatyczny 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ż łatwość wykonania ich kopii bieżących w trakcie jego pracy. 20. System Informatyczny musi być wyposażony w zabezpieczenia przed nieautoryzowanym dostępem. 21. System powinien oferować mechanizmy kontrolne zapewniające poprawność numeru PESEL, REGON, Numer prawa wykonywania zawodu, NIP. 22. System Informatyczny musi umożliwiać definiowanie szablonów dokumentów wykorzystywanych w jednostce. 23. Relacyjna baza danych musi pozwalać na kompresję kopii zapasowej danych (backup) od razu w czasie jej tworzenia. Cecha niezależna od funkcji systemu operacyjnego ani od sprzętowego rozwiązania archiwizacji danych. 24. System musi wspierać technologię XML - relacyjna baza danych musi udostępniać mechanizmy składowania i obróbki danych w postaci struktur XML. 25. System musi posiadać spójne okno opisu historii choroby z takim samym rozmieszczeniem głównych funkcjonalności (recepta, zlecenia, badania, opis pozycji historii choroby) dla gabinetu lekarskiego, historii choroby izby przyjęć oraz oddziału szpitalnego. 26. System musi mieć możliwość integracji z zewnętrznymi systemami laboratoryjnymi(LIS) oraz diagnostyki obrazowej (PASC) 27. System musi mieć możliwość drukowania paragonów fiskalnych. 28. System musi mieć możliwość drukowania faktur VAT. | ||
Wykaz modułów i funkcjonalności dla zakres medycznego (część „biała”) | ||
2. | Moduł eWUŚ | Moduł musi posiadać funkcjonalności zapewniające: 1. Możliwość weryfikacji prawa pacjenta do świadczeń opieki zdrowotnej finansowanych ze środków publicznych w : ▪ Rejestracja ▪ Terminarz ▪ Ewidencja ▪ Ruch chorych 2. Dostęp do historii weryfikacji uprawnień pacjenta |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
3. Możliwość wprowadzenia informacji o przedstawieniu przez pacjenta dokumentu uprawniającego do skorzystania z usług w ramach NFZ lub złożeniu przez pacjenta oświadczenia, 4. Możliwość cyklicznego automatycznego sprawdzania uprawnień pacjentów, 5. Możliwość zmiany hasła dostępu użytkownika do systemu eWUŚ. 6. Możliwość automatycznego powiadomienia o konieczności zmiany wygasłego hasła wraz z jego blokadą. | ||
3. | Moduł Poradnia | Moduł musi wspierać proces rejestracji pacjenta, badań i konsultacji w zakresie świadczeń zdrowotnych realizowanych w ramach kontraktów NFZ, poprzez ewidencjonowanie wszystkich zdarzeń związanych z obsługą pacjenta przybywającego na badania. Wymagany sposób działania modułu / usługi: 1. Pacjent rejestruje się: a. osobiście do lekarza • w Rejestracji • i / lub poprzez Infokiosk w Jednostce b. telefonicznie c. elektronicznie poprzez Internet 2. Fakt przybycia pacjenta jest odnotowywany w systemie, system wspomaga kontrolę złożenia niezbędnych dokumentów 3. Rejestracja kieruje pacjenta do odpowiedniego gabinetu w oparciu o elektroniczny terminarz pracy. 4. Lekarz bada pacjenta i opisuje jego stan w systemie. 5. W razie potrzeby lekarz wystawia elektroniczne skierowania na badania i konsultacje odpowiednio do stanu zdrowia pacjenta (zlecenia wewnętrzne i zewnętrzne), pacjent poddaje się badaniom zgodnie z otrzymanymi skierowaniami. Wyniki badań są rejestrowane w systemie. 6. Lekarz wystawia w systemie receptę (druk lub e-receptę) 7. Dokumentacja pacjenta wprowadzona zostaje do systemu EDM. |
4. | Moduł Poradnia – Rejestracja | Moduł musi posiadać funkcjonalności zapewniające: 1. Możliwość tworzenia kalendarza przyjęć. 2. Możliwość definiowania średniego czasu trwania wizyty. 3. Możliwość blokady terminów dla wybranego lekarza oraz blokady całego dnia. 4. Możliwość modyfikacji przynajmniej następujących parametrów pracy poradni: • planowanie lub zapisywanie wizyty wg planu pracy poradni, • przyjmowanie pacjentów niezależnie od planu pracy, • przyjmowanie pacjentów poza limitem. 5. Możliwość rejestracji pacjenta z możliwością nanoszenia przynajmniej następującego zestawu jego danych: • dane personalne, • dane adresowe, • przynależność do oddziału wojewódzkiego NFZ, • dane i uprawnienia opiekunów lub innych osób uprawnionych do otrzymywania informacji na temat stanu pacjenta, • rodzaj i nr dokumentu uprawniającego do leczenia, w tym udostępnianych przez NFZ dokumentów elektronicznych potwierdzających ubezpieczenie lub oświadczeń pacjenta/opiekuna o ubezpieczeniu z możliwością ich wydruku, • upoważnienia do otrzymywania informacji o stanie zdrowia i upoważnienia do dostępu do dokumentacji medycznej, • specyficzne dane dotyczące pacjentów z krajów Unii Europejskiej przyjmowanych w ramach przepisów o koordynacji, • specyficzne dane dotyczące pacjentów przyjmowanych na zasadach indywidualnych np. wojskowi, za zgodą burmistrza. |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
6. Możliwość weryfikacji poprawności kodu terytorialnego (tylko dla pacjentów z Polski) oraz kodu kraju (dla obcokrajowców) 7. Możliwość gromadzenia informacji o podmiocie kierującym (lekarz - nr prawa wykonywania zawodu, poradnia - nr regon i kody resortowe), jednostka kierująca, data wydania skierowania, rozpoznanie ze skierowania zgodne z obowiązującym w danym czasie słownikiem ICD-10. 8. Możliwość wyszukiwania pacjentów przy zadanych kryteriach: • PESEL, • nazwisko oraz imię, • data urodzenia, • nr identyfikacyjny, • lub po wpisaniu fragmentu powyższych danych. 9. Możliwość utworzenia historii zdrowia i choroby pacjenta przez uprawnionych użytkowników w oparciu o modyfikowalne formularze. 10. Możliwość zmiany terminu jednej lub wielu wizyt z poziomu widoku terminarza graficznego np. z wykorzystaniem mechanizmu drag&drop. 11. Możliwość przyjęcia pacjenta z rozróżnieniem płatnika wg otwartego słownika np.: • NFZ, • Prywatne, • Kontrahent Komercyjny, • Abonament. 12. Możliwość automatycznego dodania kodu dodatkowych uprawnień „32aDILO” w przypadku wyboru trybu przyjęcia na podstawie karty diagnostyki i leczenia onkologicznego dla AOS. 13. Możliwość wydrukowania potwierdzenia rejestracji z datą, godziną oraz planowanym miejscem wykonywania świadczenia. 14. Możliwość automatycznego wykreślania pacjentów, którym udzielono już świadczenia, z listy oczekujących na to świadczenie na podstawie zakończonych wizyt. 15. Możliwość dopisania komentarza w trakcie rejestracji pacjenta, który będzie widoczny zarówno z widoku rejestratora, jak również pracownika wykonującego świadczenie. 16. Możliwość obsługi deklaracji POZ. 17. Możliwość filtrowania deklaracji po: a. dacie wycofania (zakres od – do) b. dacie złożenia (zakres od – do) 18. Możliwość integracji systemu z aplikacją AP-KOLCE w zakresie obsługi listy oczekujących. 19. Możliwość przeglądu i wydruku terminarza wizyt dla poszczególnych poradni/gabinetów lekarskich. 20. Możliwość graficznej prezentacji zaplanowanych i wolnych terminów wizyt w przychodni (poradni/gabinecie). 21. Możliwość automatycznego wskazania najbliższego wolnego terminu do wybranego lekarza. 22. Możliwość automatycznego wskazania najbliższego wolnego terminu dla pacjentów z grupy NFZ, pacjentów prywatnych oraz abonamentowych. 23. Możliwość zapisania uwag pacjenta do rejestracji telefonicznej. 24. Możliwość zmiany terminu wizyty bez konieczności ponownego rejestrowania pacjenta. 25. Możliwość anulowania wizyty zaplanowanej pacjentowi. 26. Możliwość nadania numeru rezerwacji w ramach jednostki wykonującej. 27. Możliwość dodania do systemu dodatkowych dokumentów ubezpieczeniowych. 28. Możliwość dopisania ścieżki leczenia DILO. 29. Możliwość wpisania powodu zmiany terminu planowanego przyjęcia. |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
30. Możliwość wprowadzania uwag w zakresie: • uwag do wizyty widzianych w gabinecie lekarskim, • uwag do pacjenta widzianych przy każdej rejestracji pacjenta, • uwag do wizyt widzianych tylko przez rejestrację. 31. Możliwość informowania o posiadanych aktywnych oraz nieaktywnych deklaracjach POZ podczas rejestracji w poradni POZ. 32. Możliwość ostrzegania o otwartej historii choroby pacjenta rejestrowanego wraz ze wskazaniem miejsca, w którym otwarta jest historia choroby - np. oddział/izba przyjęć. 33. Możliwość identyfikowania wizyty pierwszorazowej w danej jednostce. 34. Możliwość nadania własnej klasyfikacji wizyty. 35. Możliwość wskazania wizyt wymagających doniesienia skierowania do poradni specjalistycznych. 36. Możliwość drukowania paragonów fiskalnych. 37. Możliwość drukowania faktur VAT. | ||
5. | Moduł Poradnia – Gabinet | Moduł musi posiadać funkcjonalności zapewniające: 1. Przegląd listy zarejestrowanych do lekarza pacjentów w zależności od wybranego dnia. 2. Możliwość przyjęcia pacjentów w innej kolejności niż wynika to z porządku rejestracji. 3. Opcjonalnie pozwolić na przywoływanie i odwoływanie pacjentów przy użyciu wyświetlaczy gabinetowych. 4. Dostęp do archiwalnych przyjęć pacjentów. 5. Funkcjonalność umożliwiająca odczytanie przez lekarza uwag od rejestracji na temat pacjenta. 6. Możliwość podglądu przez lekarza indywidualnych statystyk z poziomu okna gabinetu lekarskiego. 7. Możliwość wydruku historii choroby pojedynczo (jednej wizyty) lub zbiorczo dla pacjenta (wszystkie wizyty). 8. Program umożliwia zdefiniowanie wydruków własnych. 9. Dostęp do wyników badań pacjenta z poziomu okna gabinetu lekarskiego. 10. Możliwość podglądu historii wizyt pacjenta w placówce. 11. Możliwość wykonania badania podmiotowego (wywiadu) na podstawie zdefiniowanych wcześniej ankiet lub szablonów. 12. Możliwość wykonania badania przedmiotowego na podstawie zdefiniowanych wcześniej ankiet lub szablonów. 13. Możliwość prowadzenia formularzowej Historii Choroby 14. Modyfikacja schematów historii choroby. 15. Dodawanie elementów schematu historii choroby. 16. Możliwość wykonania opisu zabiegu na podstawie zdefiniowanych wcześniej ankiet lub szablonów. 17. Możliwość kopiowania opisów z poprzednich wizyt. 18. Możliwość edytowania skopiowanego opisu. 19. Wykorzystywanie własnych schematów historii choroby. 20. Możliwość dodawania plików graficznych (w formatach obsługiwanych przez system Windows) do historii choroby. 21. Oznaczanie przyjęcia jako „ratującego życie”. 22. Możliwość wpisania kodu chorobowego ICD10 jako: ▪ kodu chorobowego wstępnego ▪ kodu chorobowego zasadniczego ▪ kodu chorobowego dodatkowego ▪ kodu chorobowego współistniejącego ▪ kodu chorobowego V-Y 23. Możliwość wybrania kodu chorobowego ICD10 ze słownika według: ▪ kodu, ▪ opisu. 24. Możliwość ręcznego wpisania kodu chorobowego ICD10. 25. Możliwość przypisania pacjentowi diety wybranej ze słownika. 26. Dodawanie uwag do wizyty. 27. Dodawanie procedur ze słownika ICD9 lub poprzez wpisanie kodu. |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
28. Możliwość utworzenia własnych grup procedur. 29. Gruper JGP. 30. Możliwość ręcznego dopisania procedury. 31. Możliwość zamykania procesu leczniczego z poziomu gabinetu lekarskiego. 32. Możliwość wystawienia skierowania dla pacjenta: ▪ do szpitala, ▪ do specjalisty, ▪ na badania, ▪ na transport, ▪ na badania laboratoryjne, ▪ na badania radiologiczne. 33. Możliwość wystawiania zaświadczeń opisowych z możliwością edycji. 34. Możliwość podglądu zdjęć wyników RTG przy połączeniu systemu poprzez HL7 z placówką obsługującą RTG. 35. Możliwość podglądu wyników laboratoryjnych przy połączeniu systemu poprzez HL7 z laboratorium. 36. Możliwość obejrzenia dołączonych plików multimedialnych z jednego okna. 37. Podgląd na wcześniejsze wpisane szczepienia pacjenta. 38. Podgląd na wpisane do systemu leki uczulające pacjenta. 39. Dostęp do pełnej historii choroby pacjenta wygenerowanej podczas poprzednich wizyt w poradniach, w pracowniach. 40. System umożliwia wystawianie recept na pacjenta. 41. Kopiowanie wcześniej wystawionych recept. 42. Blokada przed ponownym wydrukowaniem tej samej recepty. 43. Anulowanie błędnie wystawionej recepty. 44. Sprawdzanie puli dostępnych recept dla danego lekarza z podziałem na: ▪ NFZ, ▪ prywatne, ▪ psychotropowe. 45. Możliwość wydrukowania recept przed wizytą domową dla konkretnego pacjenta. 46. Dostęp do informacji o ubezpieczeniu przy wystawianiu recepty. 47. Przy wystawianiu recept z lekiem refundowanym program dokonuje walidacji ubezpieczenia pacjenta i jeżeli pacjent nie posiada uprawnień do refundacji świadczeń, system podaje komunikat o braku ubezpieczenia pacjenta. 48. Wprowadzenie leków na receptę za pomocą: • Szablonu • Wyszukania z bazy leków • Wybrania z listy podpowiedzi podczas wpisywania nazwy 49. Wydruk recepty lub nadruk na receptę. 50. Możliwość wstawienia jednocześnie do pięciu leków na receptę. 51. Możliwość tworzenia schematów recept. 52. Podgląd charakterystyki produktu leczniczego. 53. Filtrowanie leków pod kątem refundacji oraz innych grup. 54. Wyróżnienie kolorystyczne leków refundowanych. 55. Dostęp do informacji o refundacji leków. 56. Dostęp do cen leków refundowanych. 57. Wczytanie puli recept. 58. Wystawianie recept z lekami do przygotowania w aptece (leki recepturowe). Korzystanie ze zdefiniowanych wcześniej szablonów. 59. Dostęp do skanowanej uprzednio dokumentacji pacjenta. 60. Wydruk karty informacyjnej dla pacjenta lub dla lekarza kierującego oraz dowolnych definiowalnych raportów związanych z pacjentem lub historią choroby pacjenta. 61. Możliwość obsługi elektronicznych kart pacjenta ŚOW NFZ | ||
6. | Moduł poradnia – Ewidencja | Moduł musi posiadać funkcjonalności zapewniające: 1. Wspólną Ewidencje Główną Pacjentów dla wszystkich poradni. |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
2. Gromadzenie w Karcie Pacjenta: ▪ danych osobowych, ▪ danych adresowych, ▪ adresu e-mail, ▪ kartoteki papierowej, ▪ zatrudnienia, ▪ ubezpieczenia, ▪ płatnika, oddziału NFZ, 3. Gromadzenie w Karcie Pacjenta dodatkowych danych, takie jak: ▪ wywiad rodzinny, ▪ wywiad środowiskowy, ▪ grupa krwi ▪ dane opiekuna, ▪ upoważnienie o zgodzie do uzyskania informacji o stanie zdrowia ▪ upoważnienie o zgodzie do uzyskania dokumentacji medycznej ▪ rodzaj i nr dokumentu uprawniającego do leczenia, ▪ dane i uprawnienia opiekunów oraz innych osób uprawnionych do otrzymywania informacji na temat stanu pacjenta, ▪ dane osób uprawnionych do odbierania dokumentacji medycznej pacjenta, ▪ dane i uprawnienia opiekunów oraz innych osób uprawnionych do otrzymania dokumentacji pacjenta w przypadku jego śmierci 4. Zapisanie w Karcie Pacjenta dodatkowych danych jak: ▪ informacja na temat szczepień ▪ informacji na temat przebytych chorób ▪ informacji na temat uczulenia na leki i materiały medyczne ▪ informacji na temat wypożyczanego sprzętu ▪ dowolnej informacji na temat pacjenta w postaci ogólnych uwag ▪ informacji na temat umów, polis związanych z komercyjną / prywatną wizytą ▪ informacji o koncie do rejestracji internetowej. 5. Podgląd na wcześniejsze wpisane szczepienia pacjenta. 6. Podglądu wcześniejszych wizyt pacjenta w jednostce. 7. Dostęp do informacji w zakresie: ▪ data/godzina rejestracji, ▪ data przyjęcia, ▪ data wypisu, ▪ rodzaj poradni, w której był przyjęty pacjent, ▪ dane lekarza przyjmującego, ▪ data skierowania, ▪ status wizyty, ▪ przyczyna skreślenia. 8. Filtrowanie informacji z odbytych wizyt przy użyciu parametrów: ▪ data/godzina rejestracji, ▪ data przyjęcia, ▪ data wypisu, ▪ rodzaj poradni, w której był przyjęty pacjent, ▪ dane lekarza przyjmującego, ▪ data skierowania, ▪ status wizyty. 9. Możliwość dodania pacjenta niezidentyfikowanego. 10. Możliwość wyszukiwania danych pacjenta z uwzględnieniem danych takich jak: ▪ imię i nazwisko, ▪ nr PESEL, ▪ nr identyfikacyjny 11. Filtrowanie danych pacjentów w ewidencji pod kątem: |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
▪ miejscowości, ▪ roku urodzenia. 12. Możliwość skanowania i podglądu zeskanowanych dokumentów. 13. Możliwość sprawdzenie statusu ubezpieczenia pacjenta (eWUŚ). 14. Możliwość wyeksportowania historii wizyt pacjenta w danej jednostce do pliku XML. 15. Możliwość sprawdzania kolejek oczekujących na wizyty. 16. Możliwość obsługi elektronicznych kart pacjenta ŚOW NFZ 17. System daje możliwość numerowania kartotek za pomocą oznaczenia alfanumerycznego (zarówno litery, jak i cyfry) | ||
7. | Moduł Poradnia – POZ | Moduł musi posiadać funkcjonalności zapewniające: 1. Możliwość podglądu i weryfikacji deklaracji podczas rejestracji pacjenta. 2. Możliwość wydruku deklaracji z poziomu rejestracji przy jej braku lub zmianie lekarza. 3. Możliwość dodania do systemu dodatkowych dokumentów ubezpieczeniowych. 4. Możliwość eksportu i importu deklaracji do pliku. 5. Możliwość rozliczenia deklaracji z NFZ wraz pełną informacją o wymianie danych. 6. Możliwość podglądu szczegółowych danych poszczególnych deklaracji takich jak: punkt kontraktowy i świadczenie z umowy POZ oraz wartość w złotówkach danej deklaracji 7. Możliwość podglądu numeru szablonu, którym wczytano informacje. 8. Możliwość podglądu komunikatów z NFZ. 9. Możliwość zbiorczego działania na deklaracjach (Wycofania, aktywowania, itp.) 10. Możliwość wydruku listy deklaracji zgodnie z filtrem. 11. Możliwość wykonywania indywidualnej sprawozdawczości badań w POZ. 12. Możliwość zliczania badań dla sprawozdania zbiorczego badań w POZ. 13. Możliwość dodawania zestawów badań POZ 14. Możliwość walidacji na podwójne wpisy tego samego pacjenta w tym samym okresie sprawozdawczym oraz walidacji na sprawozdawczość indywidualną. |
8. | Moduł zleceń | Moduł musi posiadać funkcjonalności zapewniające: 1. Możliwość obsługi elektronicznych zleceń medycznych w tym: ▪ wysłanie zlecenia, ▪ śledzenie stanu wykonania zlecenia, ▪ zwrotne odebranie wyniku zlecenia. 2. Możliwość wprowadzenia, modyfikacji, przedłużenia oraz anulowania zleceń dla pacjentów. 3. Kontrolę wprowadzania podwójnych zleceń oraz kontroli zlecenia pod kątem poprawności i kompletności. 4. Możliwość wykorzystania kodów kreskowych i czytników do identyfikacji zleceń. 5. Możliwość wykorzystania danych z modułu do rozliczania kosztów. 6. Rejestrację etapów wykonania/realizacji zlecenia. 7. Możliwość anulowanie zlecenia. 8. Automatyczny zapis daty i czasu, osobę wprowadzającą, zmieniającą i odwołującą zlecenie. 9. Automatyczny zapis daty i czasu, osobę wprowadzająca oraz zmieniająca wyniki. 10. Automatyczne aktualizowanie etapu realizacji zlecenia. 11. Automatyczne przekazanie zlecenia do jednostki realizującej zlecenie. 12. Automatyczne zwrotne przekazanie wyniku. 13. Możliwość przedłużania zleceń, zleceń cyklicznych. |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
14. Możliwość na zlecania badań i konsultacji poza poradniami oraz możliwość prowadzania wyników tych badań w formie papierowej, lub elektronicznej. 15. Możliwość zapisania w ramach komentarza do zlecenia istotnych danych diagnostycznych (rozpoznanie, kierunek badania, grupa krwi itp.). 16. Możliwość integracji w trybie online za pomocą standardu HL 7. | ||
9. | Moduł nadzorczy | Moduł musi umożliwiać tworzenie zestawień analitycznych i syntetycznych wg wskazań Zamawiającego. Dostępne będą zarówno zestawienia predefiniowane wg wskazań i wzorców Zamawiającego, jak również mechanizm tworzenia własnych zestawień. Moduł musi również posiadać funkcjonalności pozwalające na kontrolowanie ewidencji spraw z uwzględnieniem ich statusów oraz obieg dokumentów z nimi związanych (kompletność dokumentów, terminowość wystawienia dokumentu, terminowość otrzymania odpowiedzi) |
10. | Archiwum dokumentacji medycznej | Moduł musi posiadać funkcjonalności wspomagające zarządzanie zbiorem dokumentacji elektronicznej poprzez: 1. Możliwość ewidencjonowania archiwum papierowego 2. Możliwość nadania statusu dokumentacji medycznej (wypożyczenie, zwrot, zniszczenie/odnalezienie, stworzenie kopii, planowe zniszczenie, archiwizacja) 3. Ewidencję adnotacji o osobie wypożyczającej wydającej dokumentacje medyczne. 4. Automatyczny druk dokumentu PDF lub XML podczas wydruków z przypisaniem go do historii choroby, 5. Przechowywanie dokumentów elektronicznych wraz z wersjonowaniem, 6. Możliwość podpisu elektronicznego dokumentu 7. Obsługę obiegu dokumentów zgodnie ze zdefiniowanymi w konfiguracji systemu regułami. |
11. | Moduł statystyki medycznej | Moduł statystyki medycznej musi posiadać następujące funkcjonalności: 1. Obsługę bazy pacjentów poradni, zakładu, pracowni. 2. Wyszukiwanie pacjentów w skorowidzu wg różnych parametrów (min. nazwisko, XXXXX, ID Wewnętrzny). 3. Przegląd danych archiwalnych pacjenta w zakresie danych z poszczególnych wizyt w zakładach diagnostycznych, wyników badań i wizyt w poradniach. 4. Potwierdzenia wypisu pacjenta pod kątem kompletności i poprawności danych. 5. Obsługa Księgi Oczekujących (kolejki oczekujących). 6. Obsługa Karty Zakażenia Szpitalnego 7. Obsługa Księgi Głównej 8. Obsługa Księgi Odmów 9. Obsługa Księgi Poradni. 10. Obsługa Księgi Pracowni Diagnostycznej. 11. Obsługa Księgi Zabiegowej. 12. Elektroniczna komunikacja z NFZ. 13. Możliwość potwierdzenia przez lekarza zakończenia wizyty lekarskiej wraz ze sprawdzeniem kompletności danych dotyczących pacjenta i wykonanych świadczeń. 14. Czas oczekiwania (planowany i rzeczywisty) na poszczególne świadczenia (dane z list oczekujących). 15. Możliwość sporządzania raportów: liczba porad płatnych. 16. Możliwość sporządzania raportów: liczba porad ambulatoryjnych. |
12. | Moduł statystyczno-raportowy | Moduł musi posiadać następujące funkcjonalności: 1. Możliwość stworzenia dowolnej statystyki z danych zgromadzonych w systemie. 2. System musi mieć możliwość gromadzenia odpowiednich danych do prowadzenia statystyk ruchu chorych na oddziałach szpitalnych, w szczególności dotyczących liczby: |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
▪ pacjentów przyjętych z rozbiciem na: a. podstawę przyjęcia (zgodnie ze słownikiem NFZ), b. dane osobowe, c. liczba i rodzaje rozpoznania ICD-10, d. liczba i rodzaje procedury ICD-09. ▪ pacjentów w ruchu międzyoddziałowym, ▪ wypisów: podstawa wypisu (zgodnie ze słownikiem NFZ), ▪ zgonów z rozbiciem na ich przyczyny wg: ICD-10, z powodu zatruć, urazów i udanych prób samobójczych. 3. System musi mieć możliwość gromadzenia odpowiednich danych do prowadzenia następujących statystyk ruchu chorych w poradniach specjalistycznych: ▪ liczba udzielonych porad: a. podstawa przyjęcia (zgodnie ze słownikiem NFZ), b. dane osobowe (wybrane: płeć, wiek w tym wiek od- do), c. liczba i rodzaje z rozpoznaniem ICD-10, d. liczba i rodzaje z procedurami ICD-09, e. rodzaj udzielonych porad (zgodnie ze słownikiem NFZ), ▪ sposób zakończenia porady (zakończony proces, kontynuacja leczenia w danej poradni, skierowanie do szpitala, skierowanie na rehabilitację, skierowanie do innego specjalisty), ▪ liczba i rodzaj zleconych badań przez poradnie lub konkretnego lekarza. 4. Możliwość wygenerowania i wydruku miesięcznych, kwartalnych, półrocznych i rocznych statystyk dotyczących: ▪ liczby przyjętych do danego oddziału na podany dzień, ▪ liczby leczonych w szpitalu ogółem na podany dzień, ▪ liczby zgonów w szpitalu ogółem na podany dzień, ▪ liczby wypisanych ze szpitala ogółem na podany dzień, ▪ średniego czasu hospitalizacji za dany okres od-do, ▪ średniego obłożenia poszczególnych oddziałów w szpitalu ogółem wyrażonego w dniach i procentach za dany okres lub na dany dzień, ▪ wskaźnika przelotowości, ▪ planowanych i wykonanych osobodni dla poszczególnych oddziałów rozliczanych w trybie osobodni i w podsumowaniu dla całego szpitala. 5. Możliwość wygenerowania zestawień wykonanych świadczeń dla wszystkich lub wskazanej pozycji umowy NFZ, w całym lub dowolnie wybranym okresie jej obowiązywania, z rozbiciem na miesiące. Zestawienia muszą zawierać przynajmniej: ▪ miesiąc wraz z rokiem, ▪ limit miesięczny, ▪ wartość wykonania w danym miesiącu, ▪ realizację limitu (wykonanie - limit), ▪ wartość wykonania, która figuruje w raporcie statystycznym, ▪ wartość wykonania, która figuruje w raporcie rozliczeniowym, ▪ wartość przesłanych szablonów przez NFZ, ▪ świadczenia z błędami w raporcie statystycznym, ▪ świadczenia posiadające potwierdzenie w raporcie statystycznym. 6. Możliwość wygenerowania zestawień wykonania świadczeń w rozbiciu na poszczególne pozycje umowy NFZ, wraz z podsumowaniami całego zestawienia w punktach i złotówkach. Zestawienia muszą zawierać przynajmniej: ▪ kod identyfikujący umowę, ▪ numer pozycji umowy, ▪ nazwę pozycji umowy, |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
▪ miesiąc i rok obowiązywania, ▪ limit miesięczny, ▪ wartość wykonania w danym miesiącu, ▪ wykorzystanie limitu (w procentach), ▪ wartość wykonania, która figuruje w raporcie statystycznym, ▪ wartość wykonania, która figuruje w raporcie rozliczeniowym. 7. Możliwość eksportu danych statystycznych do arkuszy kalkulacyjnych, plików tekstowych. | ||
13. | Moduł sprawozdawczo- rozliczeniowy | Moduł sprawozdawczo-rozliczeniowy musi posiadać następujące funkcjonalności: 1. Możliwość ewidencjonowania umów zawartych z oddziałami NFZ. 2. Ewidencjonowania i monitorowania kolejki oczekujących na wykonanie procedur medycznych zgodnie z wymaganiami prawa. 3. Generowanie sprawozdania ze stanu tych kolejek zgodnie z wymaganiami NFZ. 4. Spełniać wymogi prawne dotyczące rozliczeń świadczeń i umów w służbie zdrowia. 5. Generowania sprawozdań do systemów rozliczeniowych płatników świadczeń w formatach wymaganych przez NFZ. 6. Generowania wydruków do sprawozdań (sprawozdawczość wymagana przez NFZ). 7. Przechowywania informacji o strukturze organizacyjnej zakładu. 8. Możliwość powiązania struktury organizacyjnej zakładu z kontraktem NFZ (możliwość wskazania, która jednostka organizacyjna w Zakładzie odpowiada jednostkom z kontraktu NFZ). 9. Możliwość automatycznego tworzenia raportu dla NFZ na podstawie wprowadzonych danych w gabinetach i na oddziałach. 10. Możliwość automatycznej zmiany koloru czcionki umowy po zaczytaniu paczki z odpowiedziami dla umów, dla których można wystawić rachunek. 11. Podglądu limitów oraz sumy punktów zaplanowanych zabiegów w poszczególnych miesiącach dla umów NFZ w trakcie planowania zabiegów rehabilitacyjnych. 12. Możliwość stworzenia wykresów słupkowych odzwierciedlających stan wykorzystania świadczeń w stosunku do limitów NFZ na oferowane świadczenia. 13. Możliwość automatycznego wyznaczania cykli zabiegowych dla NFZ (rehabilitacja). 14. Możliwość rozliczenia usług/badań z NFZ według obowiązujących zarządzeń Prezesa NFZ, Rozporządzeń i Ustaw Ministra Zdrowia. 15. Grupera, który na podstawie danych wprowadzonych podczas wizyty potrafi wskazać pozycję rozliczeniową z katalogu NFZ. Dostęp do Grupera jest lokalny, tzn. nie wymaga zewnętrznego łącza internetowego 16. Raporty pozwalające na bieżąco śledzić stan realizacji umowy. 17. Możliwość zmiany wersji wysyłki. 18. Możliwość zmiany statusu produktu z wyszczególnieniem zakresu dat, umowy, produktu oraz wyróżnika. 19. Możliwość wybór danych do eksportu – z podziałem na: ▪ deklaracje POZ, ▪ zbiorczy POZ, ▪ kolejki oczekujących, ▪ faktury zakupowe, ▪ rozliczenia, ▪ świadczenia. 20. Możliwość eksportu danych z zastosowaniem filtra dla błędnych rekordów. 21. Możliwość generowania danych do eksportu według: ▪ umowy, ▪ produktu, |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
▪ wyróżnika, ▪ zakresu dat. 22. Możliwość importu umów z Narodowym Funduszem Zdrowia oraz aneksów. 23. Możliwość przypisania umowy do kolejnej jednostki świadczącej usługi. 24. Możliwość generowania sprawozdań takich jak: ▪ ZD3, ▪ MZ-11, ▪ CZP. 25. Możliwość filtrowania sprawozdań według umowy, roku i miesiąca. 26. Możliwość przeliczania wszystkich kolejek. 27. Możliwość przeliczania wybranej kolejki i wysłania jej do NFZ. 28. Możliwość walidacji kolejek. 29. Informowania o błędach w kolejce. 30. Możliwość podglądu listy pacjentów oczekujących w kolejce. 31. Możliwość wyszukiwania pacjenta po numerze PESEL. 32. Możliwość filtrowania rekordów pacjentów z błędem w kolejce. 33. Możliwość nadania kodu skreślenia dla wybranego pacjenta lub dla wszystkich rekordów. 34. Możliwość filtrowania rekordów z uwzględnieniem 6-cio miesięcznego okresu oczekiwania w kolejce. 35. Przygotowywania faktur zakupowych. 36. Możliwość podglądu informacji o błędzie przesłanej z NFZ 37. Możliwość eksportowania do pliku CSV lub HTML danych o świadczeniach. 38. Możliwość wysyłki do Centralnej Kolejki Oczekujących (AP-KOLCE). | ||
14. | Moduł administratora | Moduł dedykowany dla administratora, który musi posiadać następujące funkcjonalności: 1. Możliwość automatycznej, centralnej aktualizacji aplikacji na stacjach roboczych. 2. Zabezpieczenie dostępu do programu dla użytkowników hasło lub logowanie biometryczne lub przez kartę. 3. Wymuszoną okresowa zmiana hasła. 4. Wymuszoną „wrażliwość” na duże i małe litery. 5. Możliwość określenia minimalnej długości hasła. 6. Wbudowane mechanizmy do administrowania prawami użytkowników; zarządzanie uprawnieniami, tworzenie i modyfikacja grup, określanie uprawnień użytkowników na poziomie poszczególnych funkcji. 7. Możliwość zarządzania użytkownikami, ich prawami, dostępem do komórek organizacyjnych. 8. Możliwość przydzielania użytkownikom prawa dostępu do wybranych komórek organizacyjnych (np. oddziału). 9. Możliwość administrowania bazami słownikowymi. 10. Możliwość definiowania struktury placówki Zamawiającego w zakresie danych administracyjnych w tym kodów resortowych MZ, REGON. 11. Możliwość zaewidencjonowania w programie i modyfikacji poszczególnych jednostek organizacyjnych zakładu (gabinety, rejestracje, izby przyjęć, oddziały, laboratoria, pracownie diagnostyczne, itd.). 12. Możliwość definiowania kontraktów i usług. 13. Możliwość obsługi słowników personelu z możliwością połączenia z zarządzaniem listą użytkowników. 14. Możliwość wykorzystania słowników zarówno standardowych (ICD-10, ICD-9 CM, Słownik Kodów Terytorialnych GUS, słownik trybów przyjęcia, słownik płatników i instytucji zewnętrznych itp.), jak i wewnątrzzakładowych. 15. Możliwość definiowania i obsługi ksiąg wykorzystywanych w jednostce. |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
16. Możliwość obsługi systemu e-WUŚ - konfiguracja umożliwiająca co najmniej dwukrotną weryfikację uprawnień pacjentów "hurtowo" o ustalonej, zapisanych w harmonogramie godzinach. 17. Możliwość konfiguracji rozliczeń z wieloma oddziałami NFZ 18. Możliwość konfiguracji obsługi wielu podmiotów gospodarczych w ramach grupy zakładów | ||
15. | Moduł elektronicznej dokumentacji medycznej (EDM) | 1. Przechowywanie drukowanych dokumentów w formie elektronicznej wraz z informacjami pozwalającymi na zidentyfikowanie osoby generującej dany wydruk. 2. W przypadku dokonania ponownego wydruku dokumentu, tworzony jest nowy dokument elektroniczny odkładany jako kolejna wersja dokumentu przechowywana w module EDM. 3. Możliwość podpisania certyfikatem elektronicznym (kwalifikowanym lub niekwalifikowanym) wygenerowanego dokumentu elektronicznego. 4. Możliwość wyszukiwania dokumentów elektronicznych. 5. Brak możliwości modyfikowania zarejestrowanych dokumentów w module EDM. |
16. | Moduł Szpital – Izba przyjęć i oddziały | Moduł Szpital – Izba przyjęć i oddziały musi posiadać następujące funkcjonalności: 1. Możliwość obsługi oddziałów i izby przyjęć. 2. Możliwość filtrowania pacjentów oddziału wg lekarza prowadzącego. 3. Możliwość ewidencjonowania przyjęć depozytów na stan jednostki. 4. Możliwość przenosin międzyoddziałowych pacjenta. 5. Możliwość wprowadzenia pacjenta NN. 6. Możliwość uszczegółowienia informacji podczas rejestracji o dane: Psychiatryczne, Rehabilitacyjne. 7. Możliwość wyświetlenia aktualnej historii choroby pacjenta po zeskanowanym identyfikatorze pacjenta, dostosowanym do obowiązujących aktów prawnych. 8. Możliwość uruchamiania na urządzeniach przenośnych typu tablet, umożliwiających pracę personelu medycznego z dokumentacją medyczną pacjenta przy łóżku pacjenta. 9. Funkcjonalność drukowania identyfikatora pacjenta, dostosowanego do obowiązujących aktów prawnych. 10. Możliwość wydruku takich wydruków jak: karty statystyczne, karty wypisu i pełnej historii choroby pacjenta. 11. Możliwość obsługi bloku operacyjnego poprzez: ▪ Tworzenie protokołu operacyjnego (prowadzenie wykonanych czynności i procedur, protokołów pielęgniarskich, anestezjologicznych, generowanie opisów medycznych w oparciu o indywidualne słowniki, utworzone w systemie formularze lub dopiski, ewidencja podanych leków, zużytych materiałów, wykonującego personelu). ▪ Prowadzenie księgi bloku operacyjnego 12. Możliwość zapisywania statusów dziennych dla hospitalizowanego pacjenta. 13. Możliwość zablokowania edycji dokumentacji archiwalnej. 14. Posiadanie mechanizmu przeliczania ruchu pacjentów, przepustowości i obłożenia łóżek. 15. Możliwość prowadzenia i automatycznej numeracji Księgi Głównej, Ksiąg Oddziałowych. 16. Możliwość druku wybranego zakresu numerów Księgi Głównej. 17. Możliwość obsługi elektronicznych zleceń oddziałowych z wysłaniem do poszczególnych pracowni, laboratorium, rehabilitacji, poradni, oddziału, innej jednostki medycznej: ▪ badania diagnostyczne ▪ badania laboratoryjne ▪ zabiegi ▪ konsultacje |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
▪ apteczki oddziałowe. 18. Możliwość definiowania formularzy zlecenia ( charakterystycznych dla jednostki odbierającej zlecenie) 19. Możliwość automatycznego odbioru wyniku (wynik jest widoczny w dokumentacji med. pacjenta) i wydruku wyniku. 20. Możliwość modyfikacji, anulowania zaplanowanego zlecenia, przeglądu zleceń, wydruku zleceń. 21. Możliwość przeglądu danych archiwalnych o pacjentach przebywających w przeszłości na danym oddziale. 22. Możliwość wystawiania i ewidencjonowania przepustek. 23. Możliwość automatycznego rozdzielenia krotności produktu i procedur na poszczególne dni. 24. Możliwość wprowadzenia rozpoznań: wstępne, główne, współistniejące, dodatkowe wypisowe, przyczyny zgonu i rozpoznania sekcyjnego wg klasyfikacji ICD-10 oraz opisowych (z wykorzystaniem zdefiniowanych wcześniej szablonów). 25. Posiadanie aktualnej wersji grupera JGP dla szpitalnictwa. 26. Możliwość aktualizacji oprogramowania do najnowszej wersji grupera oraz wczytywania aneksów umów NFZ. 27. Możliwość zapamiętywania okresu obowiązywania danej wersji grupera oraz danych niezbędnych do grupowania z umów NFZ. 28. Możliwość podglądu w jednym miejscu wszystkich danych, niezbędnych do wyznaczenia grupy JGP. 29. Możliwość wskazywania wszystkich grup spełniających warunki poprawnego grupowania oraz nich wartości punktowej. 30. Możliwość generowania informacji o najbliższych grupach nie spełniających warunków (system podaje ich wartości punktową oraz przyczyny niespełnienia warunków oraz uwagi związane z tym faktem). 31. Możliwość wprowadzania skierowań na transport medyczny, oraz wydawania zaświadczeń o pobycie w szpitalu. 32. Możliwość stworzenia słownika powodów wprowadzenia zmian w pozycjach historii choroby pacjenta. 33. Możliwość wprowadzania i przechowywania informacji o zmianie pozycji historii choroby z zapisaniem powodu tej zmiany oraz informacji o tym, kto jej dokonał. 34. Możliwość prowadzenia gospodarki lekami apteki głównej i apteczek oddziałowych. 35. Możliwość planowania i zlecania leków, prowadzenia karty zleceń leku, wydruku dziennego zestawienia leków na pacjenta. 36. Możliwość tworzenia szablonów zleceń na podanie leków. 37. Możliwość ewidencjonowania osoby wydającej i wydania leków oraz materiałów z dokładnością do pacjenta. 38. Aktualizowanie stanu apteczki oddziałowej w wyniku podania leku oraz możliwość wprowadzenia strat. 39. Możliwość definiowania struktury apteczek oddziałowych w powiązaniu z apteką główną. 40. Możliwość zaczytywania kodów kreskowych z leków i materiałów. 41. Możliwość generowania stanów magazynowych apteczki oddziałowej. 42. Możliwość ewidencjonowania serii leków i dat ich ważności. 43. Możliwość drukowania zestawień dla apteczki oddziałowej między innymi: dat ważności, zużycia za okres; obrotów, inwentaryzacji (generowanie arkusz spisu z natury), stanów minimalnych. 44. Możliwość prowadzenia karty magazynowej apteczki oddziałowej. 45. Możliwość tworzenia raportu rozchodu leków 46. Wsparcie tworzenia planów i zapotrzebowania na leki 47. Możliwość automatycznego tworzenia zamówienia na brakujący lek ze zlecenia lekarskiego 48. Możliwość wyliczenia kosztów medycznych hospitalizacji. 49. Możliwość rejestracji pacjenta (zapisywane są min. dane osobowe, adresowe, ubezpieczeniowe, o opiekunie, płatniku, osobach |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
upoważnionych do uzyskania informacji o stanie zdrowia, odbiorze dokumentacji medycznej). 50. Możliwość wyszukiwania pacjentów w liście pacjentów wg różnych parametrów. 51. Możliwość prowadzenia list oczekujących na przyjęcie do oddziałów z możliwością zmiany zaplanowanego terminu. 52. Możliwość prowadzenia historii choroby (zapisywane są min: dane przyjęcia, wywiad, przebieg choroby, epikryza, procedury, zabiegi, badania diagnostyczne, leki, konsultacje, wypis). 53. Możliwość ewidencji czynności pielęgniarskich oraz wydruku wymaganych dokumentów. 54. Możliwość definiowania i użycia tekstów standardowych w opisie historii choroby. 55. Możliwość stworzenia dodatkowych dokumentów zapisywanych w rekordzie pobytu w oddziale umożliwiające zbieranie nietypowych danych. 56. Możliwość obsługi kart TISS. 57. Możliwość generowania standardowych zestawień wg rozpoznań, procedur (sumaryczne, jednostkowe), zleconych badań na pacjenta w danym dniu lub okresie. 58. Możliwość samodzielnej modyfikacji istniejących szablonów wydruków, formularzy dokumentacji medycznej, tworzenia raportów zgodnie z potrzebami Zamawiającego. 59. Możliwość przygotowywania elektronicznych raportów do instytucji zewnętrznych, np. NFZ, PZH, Centrum Zdrowia Publicznego. 60. Możliwość wystawiania recept. 61. Możliwość wprowadzenia receptury oraz oznaczenia braku zamiennika. 62. Możliwość prowadzenia elektronicznego obiegu recept tj. od wczytania numerów recept z NFZ poprzez wystawianie recept do raportów zużycia numeracji. 63. Możliwość oznaczenia historii choroby pacjenta jako świadczenia ratującego życie. 64. Możliwość dołączania do historii choroby dowolnego pliku, np. skanu skierowania, zgód pacjenta, konsultacji zewnętrznej, prześwietlenia, itp. 65. Możliwość odnotowywania udostępniania dokumentacji medycznej (dotyczy zarówno wersji papierowej dokumentacji jak i elektronicznej). 66. Możliwość przyjęcia pacjenta ze szpitalnej kolejki oczekujących do izby przyjęć, z automatycznym przeniesieniem danych pacjenta. 67. Możliwość wydruku pasków na rękę z definiowanym kodem i nadrukiem. | ||
17. | Moduł Szpital – Rejestry | Moduł Szpital – Rejestry musi posiadać następujące funkcjonalności: 1. Możliwość dodania dowolnych rejestrów (słowników) w celu ewidencji przebiegu zdarzeń, np. Rejestr odleżyn; 2. Możliwość nadania odpowiedniego statusu dla wybranego zdarzenia, 3. Możliwość powiązania badania z rejestrem. 4. Automatyczne utworzenie rejestru przy zleceniu badania. |
18. | Moduł Szpital – Moduł Blok Operacyjny | Moduł Szpital – Moduł Blok Operacyjny musi posiadać następujące funkcjonalności: 1. Możliwość zlecania zabiegów na blok operacyjny; 2. Możliwość planowania zabiegów w terminarzu; 3. Ewidencja zleceń lekarskich na blok operacyjny; 4. Możliwość filtrowania zabiegów wg. x.xx.: dat, nazwy zabiegu, jednostki kierującej i lekarza, wykonawcy, nazwisko pacjenta, PESEL. 5. Możliwość przypisania zespołów lekarskich do wykonania danych operacji; 6. Możliwość podglądu zaplanowanych zabiegów; 7. Możliwość wprowadzania opisów dokonanych operacji i zabiegów; |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
8. Możliwość rejestracji ewentualnych zakażeń; 9. Możliwość drukowania wyników badań, skierowań, kart pacjentów; 10. Możliwość określenia kosztu operacji; 11. Możliwość wydania na pacjenta leków i środków operacyjnych związanych z zabiegiem; 12. Możliwość zamawiania leków i materiałów operacyjnych z apteki poprzez skojarzony moduł apteki; 13. Możliwość obsługi materiałów z magazynu depozytowego. 14. Możliwość automatycznego przyjmowania zleceń z oddziałów; 15. Możliwość prowadzenia wykazu pracowników bloku operacyjnego; 16. Możliwość prowadzenia Księgi Bloku Operacyjnego, Sal Operacyjnych i Porodowych; 17. Możliwość prowadzenia Księgi Zabiegów. 18. Możliwość podglądu statystyk dedykowanych do bloku operacyjnego. | ||
19. | Moduł Szpital – Moduł Zakażeń Szpitalnych | Moduł Szpital – Moduł Zakażeń Szpitalnych musi posiadać następujące funkcjonalności: 1. Możliwość rejestrowania informacji o zakażeniach szpitalnych: ▪ podstawowe dane wykrytego zakażenia ▪ okoliczność zakażenia ▪ forma zakażenia ▪ sposób leczenia 2. Możliwość wydruku Karty zakażenia szpitalnego; 3. Powiazanie zakażeń z pobytem lub zabiegiem. |
20. | Moduł Szpital – Rejestr Zdarzeń Niepożądanych | Moduł Szpital – Rejestr Zdarzeń Niepożądanych musi posiadać następujące funkcjonalności: 1. Możliwość wprowadzania do Rejestru : ▪ Kart niezgodności ▪ Kart zdarzeń niepożądanych ▪ Kart działań korygujących 2. Możliwość powiadamiania uprawnionych użytkowników o wprowadzonych Kartach i ich statusach 3. Możliwość nadawania poziomów uprawnień w dostępie do Rejestru |
21. | Moduł Szpital – Diety | Moduł Szpital – Diety musi posiadać następujące funkcjonalności: 1. Możliwość zlecania diety dla poszczególnych pacjentów; 2. Możliwość wydruku zlecenia diety 3. Możliwość ewidencji planowanego zaprowiantowania pacjentów, 4. Możliwość obsługi planu żywienia z adnotacją o podaniu posiłku, 5. Możliwość utworzenia własnych słowników żywienia; 6. Możliwość czasowego wstrzymania diety z podanie daty, godziny oraz powodu 7. Możliwość eksportu zestawień do pliku x.xx. CSV. |
22. | Moduł Szpital – Tablet Oddziałowy | Moduł Szpital – Tablet Oddziałowy musi posiadać następujące funkcjonalności: 1. Możliwość pracy na urządzeniach mobilnych (np. Android 3.0+). 2. Możliwość współpracy z urządzeniami mobilnymi za pomocą sieci LAN (WiFi) oraz sieci Internet (3G). 3. Możliwość zmiany sposobu wykorzystania sieci LAN i Internet. 4. Możliwość komunikacji aplikacji na urządzeniach mobilnych z systemem np. za pomocą webserwisu. 5. Funkcjonalność logowania zabezpieczonego indywidualnym loginem i hasłem użytkownika. 6. Możliwość pracy na urządzeniach mobilnych wyposażonych w ekran dotykowy. 7. Możliwość podglądu listy pacjentów znajdujących się na oddziale, na którym pracuje zalogowany lekarz, 8. Możliwość podglądu terminarza wizyt ambulatoryjnych lub zaplanowanych zabiegów na sali operacyjnej – zależnie od uprawnień i miejsca pracy użytkownika; 9. Możliwość oznaczenia podania leków przez pielęgniarkę, zleconych przez lekarza; |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
10. Możliwość zlecenia badań, diety, konsultacji przez lekarza poprzez historię choroby 11. Możliwość zlecenia podania leków przez lekarza; 12. Możliwość podania leku przez pielęgniarkę na podstawie zlecenia lekarza. 13. Możliwość sprawdzania wyników zrealizowanych badań. 14. Możliwość opisania w historii choroby poszczególnych pozycji (x.xx: wywiad , ICD10/ICD9, obserwacja dzienna, karta gorączkowa, TISS). 15. Możliwość automatycznego otwarcia rekordu medycznego, dotyczącego danego pacjenta, po odczytaniu kodu kreskowego na jego opasce identyfikacyjnej. 16. Możliwość dodania formularza do historii choroby do wywiadu przyłóżkowego; 17. Możliwość zatwierdzenia zabiegu rehabilitacyjnego przez rehabilitanta. 18. Możliwość przeprowadzenia automatycznej aktualizacji oprogramowania po zatwierdzeniu jej przebiegu. | ||
23. | Moduł Rehabilitacja | Moduł Rehabilitacja musi posiadać następujące funkcjonalności: 1. Obsługa zleceń dla: ▪ rehabilitacji ambulatoryjnej, ▪ rehabilitacji oddziału dziennego, ▪ rehabilitacji oddziału, ▪ rehabilitacji sanatorium, ▪ rehabilitacji domowej. 2. Możliwość rejestracji/przyjęcia pacjenta z zewnątrz. 3. Możliwość obsługi zleceń z jednostek wewnętrznych i zewnętrznych. 4. Możliwość używania filtrów zleceń dla jednostek zlecających. 5. Możliwość używania filtrów aparatów/osób dla jednostek zlecających. 6. Możliwość zarządzania słownikami: ▪ stanowisk i urządzeń rehabilitacyjnych, ▪ sal, ▪ zabiegów 7. Możliwość zarządzania grafikami i terminarzami: ▪ personelu, ▪ stanowisk i urządzeń rehabilitacyjnych. 8. Możliwość określenia standardowych czasów trwania zabiegu, 9. Możliwość automatycznego planowania na bazie dostępności osób i urządzeń, preferencji pacjenta, filtrów. 10. Możliwość korzystania z kalendarza planowania z wizualizacją zajętych slotów na zabiegi prze innych pacjentów, blokady terminów. 11. Możliwość drukowania planu zabiegów z możliwością edycji formularza wydruku. 12. Możliwość podglądu limitów oraz sumy punktów zaplanowanych zabiegów w poszczególnych miesiącach dla umów NFZ w trakcie planowania zabiegów rehabilitacyjnych. 13. Możliwość wyszukania pierwszego terminu wolnego z podpowiedzią kolejnych 90 dni. 14. Możliwość automatyzacji realizacji wizyty poprzez: ▪ realizację pozycji zlecenia za pomocą kodu kreskowego, dotyku bez potrzeby wybierania ręcznego pacjenta, zlecenia, ▪ automatyczne dopisywanie procedur (w tym procedur zależnych od parametrów zlecenia),produktów podczas realizacji zabiegów, ▪ obsługę realizacji zdalnej rehabilitacji domowej. |
24. | Moduł RIS | Moduł RIS musi posiadać następujące funkcjonalności: 1. Możliwość tworzenia grafików pracy urządzeń 2. Możliwość planowanie lub zapisywanie badań |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
3. Możliwość rejestracji pacjentów niezależnie od planu pracy urządzenia 4. Możliwość rejestracji pacjenta na podstawie wewnętrznego zlecenia 5. Możliwość rejestracji pacjentów poza limitem z dnia 6. Możliwość zarejestrowania pacjenta z rozróżnieniem płatnika za konkretną usługą (NFZ, wizyta prywatna, wizyta abonamentowa) 7. Możliwość wprowadzenia przyczyny skreślenia dla zleceń na terminarzu RIS 8. Możliwość wyróżnienia na terminarzu pracy urządzeń, w których zamieszczony został wewnętrzny komunikat o założeniu blokady. 9. Możliwość sprawdzenia w systemie e-WUŚ statusu ubezpieczenia nowo zarejestrowanego pacjenta. 10. Możliwość prowadzenia Księgi pracowni z możliwością wydruku Księgi zleceń oraz Księgi badań. 11. Możliwość badań filtrowania po: ▪ Dacie badania ▪ Wykonawcy ▪ Opisującym ▪ Nazwisku, PESEL-u pacjenta 12. Możliwość ewidencji zleceń z uwzględnieniem statusu wykonania. 13. Możliwość opisu badania poprzez nagranie mówionego tekstu. 14. Możliwość przypisania materiałów wykorzystanych przy badaniu. 15. Możliwość dodania multimediów do opisu badania (zdjęcia, film) 16. Możliwość wydruku wyniku 17. Możliwość podglądu zdjęć z zewnętrznego systemu PACS 18. Możliwość ewidencji zużycia materiałów izotopowych 19. Możliwość rozliczenia badania diagnostycznego w NFZ | ||
25. | Moduł Apteka i magazyn materiałów medycznych | Moduł Apteka musi posiadać następujące funkcjonalności: 1. Funkcjonalność zapewnienia spójności indeksu materiałowego magazynu źródłowego (tj. magazyn apteki centralnej i magazynów branżowych) i magazynu docelowego (do którego są pobierane materiały). 2. Możliwość ewidencji dostawy środków farmaceutycznych i materiałów medycznych do apteki (możliwość rejestrowania również dostaw niefakturowanych). 3. Możliwość przypisania do kontrahenta opóźnienia płatności za fakturę. 4. Możliwość przypisania do kontrahenta domyślnej faktury elektronicznej. 5. Możliwość ewidencji dostaw od dostawców z możliwością wprowadzana ich drogą elektroniczną. 6. Możliwość przypisania wielu dokumentów PZ do jednej faktury zakupu. 7. Możliwość przypisania wielu faktur zakupu do jednego dokumentu PZ. 8. Możliwość powiązania wprowadzonej faktury zakupu z wprowadzonym wcześniej dokumentem przyjęcia zewnętrznego (PZ), w powiązaniu z umowami przetargowymi. 9. Możliwość dokonania korekty dokumentów ewidencjonujących dostawy środków farmaceutycznych i materiałów medycznych. 10. Możliwość automatycznej aktualizacji stanu apteczki głównej i oddziałowej, zgodnie z ewidencją dystrybucji środków farmaceutycznych. 11. Możliwość prowadzenia ewidencji wszystkich operacji w magazynie z przypisaniem czasu i personelu. 12. Możliwość obciążenia kosztami innego oddziału niż realizujący wydanie leku. 13. Możliwość wykorzystania słowników: leków, grup ATC, nazw międzynarodowych, słownik jednostek miar. 14. Możliwość definiowania własnych grup leków (lokalnych). |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
15. Możliwość definiowania własnych dokumentów (np. Rozchód Darów, Przyjęcie bezpłatnych próbek itp.) 16. Możliwość automatycznego numerowania dokumentów wg definiowanego przez użytkownika wzorca. 17. Możliwość sporządzania zamówień doraźnych do dostawców środków farmaceutycznych i materiałów medycznych. 18. Możliwość sporządzania zamówień planowych do dostawców środków farmaceutycznych i materiałów medycznych. 19. Możliwość przygotowywania zamówień automatycznie (do umowy), na podstawie aktualnych stanów magazynowych, stanów minimalnych i maksymalnych oraz z automatycznym wyliczeniem wielkości zamówienia na podstawie średniego zużycia w zadanym okresie, z możliwością późniejszego wglądu i weryfikacji i zatwierdzenia wysłania przez personel zlecający. 20. Możliwość automatycznego wysłania zamówień do dostawców drogą elektroniczną za pomocą e-maila z załącznikiem PDF 21. Możliwość sporządzania preparatów laboratoryjnych, preparatów galenowych, leków recepturowych, maści oraz płynów infuzyjnych. 22. Możliwość sporządzania roztworów spirytusowych. 23. Możliwość realizacji zamówień zbiorczych na oddział. 24. Możliwość wprowadzania produktów końcowych z poszczególnych składników (nowy końcowy produkt zostaje wprowadzany na stan magazynowy, a poszczególne składniki schodzą ze stanu magazynowego). 25. Możliwość wydania towaru nierównego zapotrzebowaniu pod względem ilościowym i jakościowym. 26. Funkcjonalność informowania przez program o różnicy ceny na fakturze w porównaniu z ceną w umowie. 27. Możliwość importu docelowego zakładowego i indywidualnego. 28. Możliwość ewidencji zwrotów z oddziałów do apteki głównej. 29. Możliwość ewidencji darów. 30. Możliwość ewidencji i obsługi leków klinicznych. 31. Możliwość ewidencji leków prywatnych pacjenta z wydrukiem potwierdzenia przyjęcia i wydania po zakończeniu hospitalizacji. 32. Możliwość ewidencji szczepionek. 33. Możliwość wydawania środków farmaceutycznych z apteki na oddziały na podstawie zamówień elektronicznych lub papierowych (współpraca z apteczką oddziałową). 34. Możliwość elektronicznego potwierdzenia zamówienia z oddziału. 35. Możliwość kopiowania dokumentów wydania. 36. Możliwość szybkiego tworzenia dokumentu przekazania leków na inny oddział na podstawie dokumentu PZ. 37. Możliwość wydawania wyrobów medycznych na zewnątrz jednostki, w ramach magazynu. 38. Możliwość zwrotu środków farmaceutycznych z apteki głównej do dostawców. 39. Możliwość ewidencji ubytków i strat nadzwyczajnych z podaniem przyczyn niezgodności. 40. Możliwość ewidencji utylizacji środków farmaceutycznych. 41. Możliwość korekty wydań środków farmaceutycznych. 42. Możliwość wykonywania remanentu, inwentaryzacji magazynu. 43. Możliwość generowania pustego arkusza do spisu z natury. 44. Możliwość korekty stanów magazynowych (ilościowej i jakościowej) na podstawie arkusza spisu z natury z dokładnością do dostawy lub asortymentu. 45. Możliwość kontroli dat ważności oraz możliwość zdejmowania ze stanów magazynowych leków przeterminowanych. 46. Możliwość przeglądu stanów magazynowych i wartości magazynu na bieżący oraz na wybrany dzień. 47. Możliwość obsługi przetargów: tworzenia pakietów, wyboru najtańszej i najlepszej oferty, utworzenia umowy przetargowej. |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
48. Możliwość kontroli realizacji dostaw i poziomu cen w ramach obowiązującej umowy przetargowej z informacją o stopniu realizacji. 49. Możliwość podglądu i wydruku stanu magazynowego uwzględniający różne parametry (na dany dzień, wg grup leków). 50. Możliwość generowania przez użytkownika raportów i zestawień na podstawie wszystkich dostępnych danych, w tym: ▪ na podstawie rozchodów, ▪ na podstawie przychodów, ▪ na podstawie obrotów. 51. Możliwość wykonania zestawień księgowych wymaganych w pracy apteki np. wydruk danej grupy leków z uwzględnieniem przychodu, rozchodu i stanu obecnego (np. leki psychotropowe). 52. Możliwość wykonania zestawień zużycia danej grupy leków (np.: psychotropy) z uwzględnieniem zakresu dat, magazynu i apteki, umowy dostawcy, czy też z dokładnością do danego leku. 53. Możliwość tworzenia zestawień rozchodów i przychodów leków w różnych konfiguracjach np. ze wskazaniem odbiorcy/dostawcy, bez wskazania odbiorcy/dostawcy, ze wskazaniem leku lub grupy leków. 54. Możliwość eksportu danych do arkusza kalkulacyjnego. 55. Możliwość przechowywania informacji o leku. 56. Funkcjonalność mechanizmu „stop-order” - wstrzymanie danej serii lub dostawy z podaniem przyczyny oraz możliwością odblokowania. 57. Możliwość wydruku raportu o podjętych czynnościach w związku ze wstrzymaniem leku. 58. Możliwość definiowania przez użytkownika receptariusza szpitalnego oraz oddziałowego. 59. Możliwość definiowania limitów wartościowych na poszczególne grupy materiałowe. 60. Możliwość definiowania struktury apteczek oddziałowych poszczególnych jednostek organizacyjnych w powiązaniu z apteką główną. 61. Możliwość prowadzenia wielu magazynów równorzędnie. 62. Możliwość automatycznej aktualizacji oprogramowania oraz słowników z wykorzystaniem połączenia internetowego. 63. Możliwość obsługi zamienników podczas wydawania leków. 64. Możliwość wydawania leków: wg nazw handlowych, kodów apteki, nazw międzynarodowych, synonimów, grup leków. 65. Możliwość pracy w oparciu o wbudowane dostępne na rynku polskim bazy leków. 66. Możliwość zamykania okresów obrotowych (rozliczeniowych) zarówno przez aptekę główną jak i apteki oddziałowe. 67. Możliwość obsługi sterylizatorni w powiązaniu z blokiem operacyjnym. 68. Możliwość obsługi depozytów (np.: implanty należące do firmy zewnętrznej). 69. Możliwość obsługi środków z grupy: I-N, II-P oraz środków z grupy: II-N, III-P, IV-P. 70. Funkcjonalność blokady możliwości dokonywania zmian i usuwania w inny sposób niż poprzez dokumenty korekt. 71. Możliwość prowadzenia ewidencji obrotu środków odurzających i substancji psychotropowych w formie elektronicznej. 72. Możliwość oznaczenia Karty Magazynowej jako archiwalnej. | ||
26. | Moduł Sterylizatornia | Moduł Sterylizatornia musi posiadać następujące funkcjonalności: 1. Możliwość tworzenia pakietów do sterylizacji; 2. Możliwość identyfikacji materiałów sterylnych; 3. Możliwość obsługi sterylizatorni w powiązaniu z oddziałami. |
Wykaz modułów i funkcjonalności dla zakres administracyjnego (część „szara”) | ||
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
27. | Moduł Finanse i Księgowość | Moduł musi posiadać następujące funkcjonalności: 1. Prowadzenia ksiąg ma się odbywać zgodnie z art. 9 ustawy o rachunkowości, to jest w języku polskim i w walucie polskiej. 2. Pozwalać na prowadzenie ksiąg w układzie kont księgi głównej, kont ksiąg pomocniczych oraz ewidencji pozabilansowej (konta pozabilansowe). 3. Umożliwić dokonywanie zapisów księgowych zgodnie z art. 23 ustawy o rachunkowości, w tym ma pozwalać na dokonywanie zapisów księgowych zawierających: określenie rodzaju i numeru identyfikacyjnego dowodu księgowego stanowiącego podstawę zapisu oraz jego datę, kwotę dokumentu, treść operacji, termin płatności, datę dokonania operacji gospodarczej (datę księgowania), datę zapisu (datę wprowadzenia do ksiąg), oznaczenie stron kont oraz kont których operacja dotyczy. 4. Możliwość wprowadzenia zapisów o następującej długości znaków: ▪ identyfikator dokumentu (tj. np. numer faktury/rachunku/umowy) – 20 znaków i mniej, ▪ treść operacji – 500 znaków i mniej, ▪ daty – w układzie dzień/miesiąc/rok (00/00/0000) 5. W zakresie prowadzenia ksiąg rachunkowych ma być zgodny z ustawą o rachunkowości w tym art. 13 ust. i ust. 5, zgodnie z którymi: ▪ ust. 4 ”księgi rachunkowe mają być trwale oznaczone nazwą (pełną lub skróconą) jednostki, której dotyczą (każda księga wiązana, każda luźna karta kontowa, także jeżeli mają one postać wydruku komputerowego lub zestawienia wyświetlanego na ekranie monitora komputera), nazwą danego rodzaju księgi rachunkowej oraz nazwą programu przetwarzania; wyraźnie oznaczone co do roku obrotowego, okresu sprawozdawczego i daty sporządzenia.” ▪ ust. 5 ”Przy prowadzeniu ksiąg rachunkowych przy użyciu komputera należy zapewnić automatyczną kontrolę ciągłości zapisów, przenoszenia obrotów lub sald. Wydruki komputerowe ksiąg rachunkowych powinny składać się z automatycznie numerowanych stron, z oznaczeniem pierwszej i ostatniej, oraz być sumowane na kolejnych stronach w sposób ciągły w roku obrotowym”. 6. Możliwość prowadzenia dzienników zgodnie z art. 14 ustawy o rachunkowości, to jest: ▪ Dziennik powinien umożliwić uzgodnienie jego obrotów z obrotami zestawienia obrotów i sald kont księgi głównej, ▪ Zapisy w dzienniku muszą być kolejno numerowane, a sumy zapisów (obroty) liczone w sposób ciągły. Sposób dokonywania zapisów w dzienniku powinien umożliwić ich jednoznaczne powiązanie ze sprawdzonymi i zatwierdzonymi dowodami księgowymi. ▪ Zapis księgowy powinien posiadać automatycznie nadany numer pozycji, pod którą został wprowadzony do dziennika, a także dane pozwalające na ustalenie osoby odpowiedzialnej za treść zapisu. 7. Możliwość wygenerowania wydruku przyjętego planu kont 8. Możliwość tworzenia automatów wzorców księgujących x.xx. zamykanie kont wynikowych (automatyczne przeniesienie na wynik finansowy) , zamykanie kręgów kosztów. 9. Możliwość automatycznego wygenerowania bilansu otwarcia zapisów na kontach bilansowych poprzedniego roku. 10. Możliwość księgowania BO oraz korekty BO w trybie odrębnego dokumentu. 11. Możliwość pracy jednocześnie w dwóch otwartych latach bilansowych. |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
12. Możliwość generowania raportów w układzie dzienników księgowań . 13. Możliwość generowania raportów w układzie co najmniej wydruku dokumentów księgowych w trybie jednoczesnego wyboru zakresu „od – do” wg dat, kwot , kont wg: ▪ dokumentów ▪ sumy obrotów kont ▪ wykazu dokumentów ▪ kartoteki kont. 14. Możliwość generowania raportów w układzie co najmniej: kartotek kont – w trybie jednoczesnego wyboru zakresu „od – do” wg konta, daty, kwoty, symbolu dowodu, identyfikatora. 15. Możliwość generowania raportów w układzie co najmniej: wydruk zestawienia obrotów i sald w trybie jednoczesnego wyboru: konta z zakresu „od – do”, rodzaju kont , okresu 16. Możliwość ręcznego i automatycznego tworzenia segmentów kont analitycznych, w tym możliwość tworzenia segmentów kont analitycznych w układzie podpinanych katalogów np. jednostki, ośrodków powstawania kosztów, pracowników. 17. Możliwość określenie rodzaju konta czy rozrachunkowe, powiązanie go z walutą 18. Umożliwić wygenerowanie i wydruk raportu z wybranego dekretu konta oraz zestawienie obrotów i sald dla danego konta. 19. Możliwość przechowywania danych kontrahenta w odpowiadającej mu kartotece. Dane te muszą zawierać: nazwę pełną kontrahenta, nazwę skróconą, adres siedziby, adres do korespondencji, NIP, REGON, PESEL, KRS, wiele numerów rachunków bankowych. 20. Identyfikacji Kontrahenta będącego jednocześnie dostawcą i odbiorcą poprzez jedną i tę samą kartotekę. 21. Możliwość wyboru kartoteki (znalezienie kontrahenta) przynajmniej po następujących kryteriach: nazwa kontrahenta, NIP, nazwa miejscowości, nazwa ulicy, numer NIP oraz po dowolnej frazie występującej w wymienionych kryteriach, wyróżnikach. 22. Możliwość podania na karcie kontrahenta informacji w zakresie: cen, terminów płatności , form płatności – możliwość wykorzystywania niniejszych danych przy wystawianiu faktur. 23. Możliwość definiowania dowolnej ilości rodzajów dokumentów. 24. Możliwość przygotowania, edytowania i wydrukowania dokumentu PK „polecenie księgowania” na podstawie wyboru (odznaczenia). 25. Możliwość wprowadzenia kilku dat płatności do jednego księgowanego dokumentu (np. faktury zakupu) z podziałem na rachunki bankowe kontrahenta z uwzględnieniem planowych terminów spłat w wiekowaniu należności i zobowiązań (harmonogram). 26. Możliwość powiązania dokumentu z rachunkiem bankowym dostawcy o ile posiada więcej niż jeden (możliwość wykorzystania tej informacji przy generowaniu poleceń przelewów). 27. Możliwość wyszukiwania dokumentów w Systemie wg danych księgowych zawartych w Systemie pozwalając określić zakres od- do dla np. daty faktury, daty zapłaty, kwoty netto, kwoty brutto. 28. Możliwość generowania zestawień/raportów w układzie zapisów na danym koncie (wydruku kartotek) ze wskazaniem podziału na stanowiące i niestanowiące kosztów uzyskania przychodów. 29. Posiadać mechanizm bufora księgowań. Dwustopniowe zatwierdzanie i księgowanie dokumentów, to jest: ▪ I etap – wprowadzanie dokumentów do ksiąg i ich zatwierdzenie. Na tym etapie ma być możliwa poprawa i usunięcie poszczególnych dokumentów jak również zapisów. Na podstawie dokumentów zatwierdzonych |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
przy I etapie ma być również możliwe wstępne wygenerowanie zapisów i obrotów na kontach na podstawie których możliwe będzie wykonanie dowolnych zestawień księgowych bazujących na obrotach i zapisach na kontach (zestawienie obrotów i sald, zapisy na koncie, bilans, rachunek wyników, inne) ▪ II etap – zaksięgowanie dokumentów zatwierdzonych. Po tych czynnościach brak możliwości modyfikacji i zmian w dokumentach. System ma mieć mechanizm kontroli poprawności dokumentów. 30. Możliwość kontroli kompletności i poprawności dekretu wprowadzonych dokumentów zgodnie z zasadą podwójnego zapisu. Brak możliwości zatwierdzenia księgowań dokumentu w sytuacji braku zgodności stron dt/ct. 31. Możliwość dla kont rozrachunkowych ustalania sald dwustronnych to jest salda strony debet i credit , możliwość automatycznego przeksięgowania nadpłat na dokumenty niezbilansowane. 32. Możliwość wycofywania rozrachunków niezależnie czy wycofanie dotyczyć będzie dokumentów zarejestrowanych czy zatwierdzonych . 33. Możliwość kopiowania (duplikowania) , stornowania całych zapisów księgowych ze wskazaniem okresu do jakiego ma zostać skopiowany / wystornowany . 34. Możliwość kopii/storna dekretu dwustronnego w ramach dokumentu. 35. Możliwość automatycznego przeksięgowania obrotów (zapisów) wybranych kont na inne konto z wygenerowaniem dokumentu PK - np. poprzez mechanizm (automat) księgowy. 36. Możliwość generowania zestawienia obrotów i sald w trybie wyboru wieloparametrowego obejmującym co najmniej parametry z zakresów danych: zakres kont (od nr do nr), okres. 37. Możliwość generowania zestawień w układzie zobowiązań i należności dla kont zespołu „2” w układzie kont analitycznych i syntetycznych w układzie: przeterminowanych, nieprzeterminowanych, ogółem z uwzględnieniem struktury wiekowej, to jest przyjętego przedziału czasowego w podziale na minimum 6 zakresów (np. 0-7 dni, 8-30, 31-60, 61-90, 91-180, 181-360). 38. Możliwość generowania wiekowej struktury należności i zobowiązań w układzie wyboru wieloparametrowego z jednoczesnym określeniem zakresu dla: ▪ numerów kont (zakresu kont), ▪ określenia czy dotyczy należności czy zobowiązań, ▪ daty płatności od – do, ▪ należności / zobowiązań liczonych na dzień, ▪ przedziały (minimum 6), ▪ trybu uporządkowania (np. wg dokumentów, dat), ▪ określenia daty dowodu od – do, ▪ określenia daty dokumentu od – do. 39. Możliwość generowania zestawień z kont dla poszczególnych kont rozrachunkowych w układzie zobowiązań / należności generowanych wg stanu „na dzień” w układzie: wymagalnych, niewymagalnych, razem. 40. Możliwość wygenerowania zestawienia z kont, w tym kartoteki konta mają zawierać co najmniej następujące dane: ▪ konto od-do, ▪ data od-do, ▪ kwota od-do, ▪ symbol dowodu od-do, ▪ identyfikator od-do. |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
41. Możliwość automatycznego generowania potwierdzenia salda dla kont rozrachunkowych w trybie pojedynczego konta, kontrahenta , grupy kontrahentów. 42. Możliwość potwierdzenia sald, które ma zawierać typowy (np.: numery faktur, daty wystawienia, wpływu) dla potwierdzeń zakres danych, w tym co najmniej: informacje adresowe o wierzycielu i dłużniku, wykaz dokumentów będących przedmiotem potwierdzenia z wymaganym zakresem danych. 43. Możliwość edytowania treści potwierdzenia sald i umieszczania własnej treści potwierdzenia. 44. Możliwość wyboru z konta rozrachunkowego (dotyczącego dostawcy i odbiorcy) dokumentów, tj. zaksięgowanych faktur do ugody. 45. Możliwość automatycznego przeksięgowania dokumentów, tj. zaksięgowanych faktur, na inne konto rozrachunkowe. 46. Możliwość automatycznego przygotowania dokumentu PK na podstawie wybranych dokumentów tj. zaksięgowanych faktur. 47. Możliwość rejestracji not księgowych dotyczących spłaty należności. 48. Możliwość wybrania różnego typu wezwań do zapłaty o różnej treści. 49. Możliwość modyfikowania treści szablonów lub poszczególnych dokumentów z punktu powyżej przed ich ostatecznym zapisaniem w Systemie. 50. Możliwość umieszczenia znaku graficznego na szablonie wezwań. 51. Możliwość wygenerowanie automatycznie wezwania dla wybranego dłużnika/wybranych dłużników. Ma zawierać czytelne informacje o wierzycielu i dłużniku (nazwa, adres do korespondencji, nr ewidencyjny, nr konta), informacje odnośnie dokumentów będących podstawą do wezwania (w tym: numer, data dokumentu, termin płatności, liczba dni spóźnienia, odsetki naliczone do dnia wezwania (jeżeli wymagane dla danego kontrahenta). 52. Możliwość wystawiania not odsetkowych dla odsetek kalkulowanych wg „zasad ogólnych”, zgodnie z ustawą o terminach zapłaty w transakcjach handlowych oraz odsetek umownych, wg oprocentowania umownego. 53. Możliwość wyliczania na bieżąco w sposób automatyczny wartości odsetek symulowanych z podziałem na odsetki od transakcji rozliczonych (zapłaconych) i nierozliczonych (przeterminowanych niezapłaconych) z możliwością prezentacji w zestawieniach należności. 54. Możliwość wygenerowania noty odsetkowej sprawdzającej dokument otrzymany od wierzyciela na podstawie ręcznie wybranych (odznaczonych w Systemie) dokumentów. Możliwość wygenerowania tej noty w trybie odsetek kalkulowanych wg „zasad ogólnych” i zgodnie z ustawą o terminach zapłaty w transakcjach handlowych. 55. Umożliwić wygenerowanie kompensaty z możliwością wyboru dokumentów po stronie należności i zobowiązań 56. Możliwość prowadzenia kilku kas (okienek kasowych) np. głównej, ZFŚS, walutowej (dla każdej waluty odrębnej kasy), z pełną obsługą tworzenia dokumentów KP i KW (tworzenie, wydruk) oraz wykonywanie osobnych raportów kasowych dla każdego rodzaju kasy. 57. Możliwość automatycznego tworzenia raportu kasowego. 58. Możliwość tworzenia dokumentów KP i KW, automatycznego rozliczania z dokumentami zobowiązań i należności (przeprowadzanie rozrachunku), automatycznego tworzenia zapisów księgowych na zadanych kontach. 59. Możliwość wygenerowania dokumentu KW na potrzeby dokonania wypłaty z listy płac. |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
60. Możliwość wprowadzenia dokładnego opisu (treści) dokumentu KP i KW oraz treści w poszczególnych pozycjach raportu kasowego. 61. Mieć zaimplementowany automat generujący polecenia przelewów na potrzeby bankowości elektronicznej na podstawie zestawienia zobowiązań płatnych do danego dnia. 62. Możliwość grupowania przelewów w paczki a następnie utworzenia pliku do systemu bankowości elektronicznej. 63. Możliwość automatycznego generowania przelewów do kontrahentów na podstawie wprowadzonych dokumentów zakupu. 64. Możliwość wyboru z listy wygenerowanych przelewów, przelewów, które zostaną wyemitowane do programów bankowości elektronicznej obsługujących Zamawiającego. 65. Możliwość wskazania, z którego rachunku bankowego będzie realizowany dany przelew. 66. Możliwość ewidencji dokumentów z wyciągów bankowych w walucie zgodnej z umieszczoną na wyciągu. 67. Możliwość obsługi wielu rachunków bankowych z możliwością przypisana kontrahentów do rachunku, z którego dokonywana jest płatność i uwzględnienie ich podczas generacji paczek przelewów. 68. Możliwość pełnej prezentacji rozliczeń dokonanych na danej pozycji wyciągu bankowego w trakcie jego edycji i przeglądania. 69. Możliwość dopisania do każdej pozycji wyciągu bankowego konta księgowego wraz ze specyfikacją . 70. możliwość wydruku pojedynczych przelewów w formie papierowej – papier z nadrukiem lub czysty papier . 71. Możliwość symulowanego rozliczenia kosztów bez księgowań. 72. Możliwość tworzenia różnych typów kluczy podziałowych : ▪ na podstawie kluczy prostych ▪ na podstawie procentowego podziału ▪ na podstawie obrotów ▪ na podstawie katalogu powiązań 73. Możliwość tworzenia wieloetapowych rozliczeń / procesów z użyciem różnych typów kluczy. 74. Możliwość określenia stanowisk / ośrodków powstawania kosztów. 75. Możliwość określenia dowolnych obiektów / grup kosztów (poradnie, pracownie, zakłady, oddziały, pododdziały) . 76. Możliwość określenia dowolnych grup rodzajów kosztów. 77. Możliwość przenoszenia kosztów i tworzenia wieloetapowych rozliczeń z użyciem różnych typów kluczy. 78. Możliwość tworzenia kalkulacji kosztowych opartych na etapach rozdziału kosztu – tworzenie zestawienie obrotów i sald. 79. Możliwość zatwierdzenia zmian i dokonania księgowań 80. Możliwość wygenerowania raportu z kosztów bezpośrednich w rozbiciu na koszty rodzajowe. 81. Możliwość bieżącej i okresowej informacji o poziomie kosztów bezpośrednich, pośrednich, zarządu, kosztów własnych sprzedaży dla danego OPK, kilku wskazanych OPK, dla danej grupy OPK. 82. Możliwość wygenerowania zestawienia klasyfikacji kosztów w dowolnym układzie z rozbiciem na konta , ośrodki kosztów , rodzaje , obiekty w układzie miesięcznym i narastająco w roku. | ||
24. | Moduł Kasa | Moduł Kasa musi posiadać następujące funkcjonalności: 1. Możliwość automatycznego tworzenia raportu kasowego – praca w kontekście raportu kasowego 2. Funkcjonalność obsługi raportu kasowego (praca kasjera zawsze w kontekście otwartego raportu kasowego) 3. Możliwość wydruku raportu kasowego 4. Możliwość wymiany danych w ramach systemu: • zapisu wartościowego operacji kasowych na kontach księgi głównej i ksiąg pomocniczych modułu FK zgodnie z |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
określonym sposobem dekretacji (eksport dokumentów do modułu FK), • prowadzenia katalogu kontrahentów zintegrowanego z modułem FK. | ||
25. | Moduł Obrót Towarowy/Zarządzanie Magazynami | Moduł Towarowy/Magazynowy musi posiadać następujące funkcjonalności: 1. Funkcjonalność zapewnienia spójności indeksu materiałowego magazynu źródłowego i magazynu docelowego (do którego są pobierane materiały). 2. Możliwość ewidencji dostawy (również dostaw niefakturowanych). 3. Możliwość przypisania do kontrahenta opóźnienia płatności za fakturę. 4. Możliwość przypisania do kontrahenta domyślnej faktury elektronicznej. 5. Możliwość ewidencji dostaw od dostawców z możliwością wprowadzana ich drogą elektroniczną np. z pliku EXCEL lub XML. 6. Możliwość przypisania wielu dokumentów PZ do jednej faktury zakupu. 7. Możliwość przypisania wielu faktur zakupu do jednego dokumentu PZ. 8. Możliwość powiązania wprowadzonej faktury zakupu z wprowadzonym wcześniej dokumentem przyjęcia zewnętrznego (PZ), w powiązaniu z umowami przetargowymi. 9. Możliwość dokonania korekty dokumentów ewidencjonujących dostawy materiałów. 10. Możliwość automatycznej aktualizacji stanu magazynu głównego i mu podległych, zgodnie z ewidencją dystrybucji środków. 11. Możliwość prowadzenia ewidencji wszystkich operacji w magazynie z przypisaniem czasu i personelu. 12. Możliwość definiowania własnych grup materiałowych. 13. Możliwość definiowania własnych nazw dokumentów. 14. Możliwość automatycznego numerowania dokumentów wg definiowanego przez użytkownika wzorca. 15. Możliwość automatycznego wysłania zamówień do dostawców drogą elektroniczną za pomocą e-maila z załącznikiem PDF 16. Możliwość wydania towaru nierównego zapotrzebowaniu pod względem ilościowym i jakościowym. 17. Funkcjonalność informowania przez program o różnicy ceny na fakturze w porównaniu z ceną w umowie. 18. Możliwość ewidencji zwrotów do magazynu głównego. 19. Możliwość wydawania towaru na zewnątrz jednostki, w ramach magazynu. 20. Możliwość zwrotu z magazynu głównego do dostawców. 21. Możliwość ewidencji ubytków i strat nadzwyczajnych z podaniem przyczyn niezgodności. 22. Możliwość wykonywania remanentu, inwentaryzacji magazynu. 23. Możliwość generowania pustego arkusza do spisu z natury. 24. Możliwość korekty stanów magazynowych (ilościowej i jakościowej) na podstawie arkusza spisu z natury z dokładnością do dostawy lub asortymentu. 25. Możliwość kontroli dat ważności oraz możliwość zdejmowania ze stanów magazynowych towarów przeterminowanych. 26. Możliwość przeglądu stanów magazynowych i wartości magazynu na bieżący oraz na wybrany dzień. 27. Możliwość kontroli realizacji dostaw i poziomu cen w ramach obowiązującej umowy przetargowej z informacją o stopniu realizacji. 28. Możliwość podglądu i wydruku stanu magazynowego uwzględniający różne parametry (na dany dzień, wg grup leków). 29. Możliwość generowania przez użytkownika raportów i zestawień na podstawie wszystkich dostępnych danych, w tym: • na podstawie rozchodów, |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
• na podstawie przychodów, • na podstawie obrotów. 30. Możliwość wykonania zestawień księgowych np. wydruk danej grupy towaru z uwzględnieniem przychodu, rozchodu i stanu obecnego. 31. Możliwość wykonania zestawień zużycia danej grupy leków (np.: psychotropy) z uwzględnieniem zakresu dat, magazynu i apteki, umowy dostawcy, czy też z dokładnością do danego leku. 32. Możliwość tworzenia zestawień rozchodów i przychodów leków w różnych konfiguracjach np. ze wskazaniem odbiorcy/dostawcy, bez wskazania odbiorcy/dostawcy, ze wskazaniem leku lub grupy leków. 33. Możliwość eksportu danych do arkusza kalkulacyjnego. 34. Możliwość przechowywania informacji o leku. 35. Możliwość definiowania limitów wartościowych na poszczególne grupy materiałowe. 36. Możliwość prowadzenia wielu magazynów równorzędnie. 37. Możliwość automatycznej aktualizacji oprogramowania oraz słowników z wykorzystaniem połączenia internetowego. 38. Możliwość obsługi zamienników podczas wydawania towaru. 39. Możliwość zamykania okresów obrotowych (rozliczeniowych). 40. Funkcjonalność blokady możliwości dokonywania zmian i usuwania w inny sposób niż poprzez dokumenty korekt. 41. Możliwość oznaczenia Karty Magazynowej jako archiwalnej. | ||
26. | Moduł Płace | Moduł musi posiadać następujące funkcjonalności: 1. Musi być bezpieczny z punktu widzenia naliczania wynagrodzeń, w tym naliczania podatków, składek i innych świadczeń ZUS, wszelkich potrąceń i innych składników wynagrodzeń, a jego bezpieczeństwo przejawia się przede wszystkim w tym, że stosowane algorytmy przetwarzania danych w sposób prawidłowy naliczają: podatki, składki i świadczenia ZUS, prawidłowo dokonują wszelkich sumowań i naliczeń w obszarach wynagrodzeń poszczególnych pracowników/zleceniobiorców, w obszarach sumowań poszczególnych list płac i zbiorówek list płac. 2. Musi być zgodny z obowiązującymi aktami prawnymi w zakresie naliczania oraz rozliczania podatku od osób fizycznych oraz składek ZUS, oraz otrzyma bieżącą aktualizację programu w razie zmian w przepisach go dotyczących. 3. Możliwość gromadzenia danych dotyczących pracownika takich jak: ▪ przynależność do urzędu skarbowego ▪ adresy z możliwością wprowadzenia różnych rodzajów adresów tzn. zamieszkania, do korespondencji, zameldowania, do celów podatkowych ▪ stopy podatku z możliwością zablokowania wyższego podatku w przypadku wspólnego rozliczania się z małżonkiem (po złożeniu deklaracji) lub samotnej matki ▪ przysługujących pracownikowi kosztach uzyskania przychodu i ulgach podatkowych ▪ określenia czy na rozliczeniu rocznym PIT 11 ma być NIP pracownika czy PESEL ▪ określenia rodzaju rozliczenia rocznego (PIT 11 czy PIT 40) ▪ nr konta bankowego pracownika – kontrola prawidłowości numeru wprowadzonego konta (informacyjnie). 4. Możliwość gromadzenia zbiorczych informacji o naliczonych podstawach składek na ubezpieczenie społeczne i zdrowotne pracownika na podstawie jego stosunków pracy w układzie rocznym. 5. Możliwość ręcznego wprowadzenia kwot podstaw emerytalno – rentowych z innych zakładów pracy. |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
6. Możliwość zablokowania naliczania składek na ubezpieczenia emerytalne i rentowe w przypadku informacji o przekroczeniu podstawy od ZUS lub pracownika. 7. Możliwość automatycznej kontroli rocznego ograniczenia podstaw składek na ubezpieczenie emerytalno – rentowe (np. w przypadku zatrudnienia pracownika na kilku umowach). 8. Możliwość automatycznej kontroli progów podatkowych nawet przy kilku umowach dla jednego pracownika. 9. Możliwość ręcznego wprowadzenia podstawy do podatku w przypadku przejścia z innego zakładu pracy. 10. Możliwość wydruku podstawowych zestawień na podstawie szablonów dostępnych w Systemie: ▪ list płac, ▪ karty wynagrodzeń pracownika (za cały rok i za wybrane miesiące), ▪ karty zasiłkowej pracownika (pełnej i za wybrany okres), ▪ zestawień list płac z podziałem na komórki organizacyjne i ośrodki kosztów, ▪ zaświadczeń o zatrudnieniu oraz wynagrodzeniu (z podziałem na brutto i/lub netto) za dowolny okres (np. z 3,5,7,12 miesięcy) z możliwością wykazania potrąceń pracownika typu pożyczka, zajęcie komornicze (zarówno kwota potrącenia jak i stan zadłużenia lub termin zakończenia spłaty); możliwość podziału wynagrodzenia na podstawowe (zasadnicza, wysługa, funkcyjny) i zmienne (np. zmianowość, godziny nadliczbowe, premie). 11. Możliwość prowadzenia rejestru dochodów pracownika. 12. Możliwość prowadzenia rejestru umów cywilno-prawnych. 13. Możliwość rozliczania umów ryczałtowych ( zaliczka na podatek wynikająca z przepisów prawa podatkowego). 14. Możliwość prowadzenia rejestrów potrąceń typu pożyczki ZFM, PKZP, zajęć komorniczych, pożyczek obcych, oraz możliwość podglądu i wydruku historii spłat 15. Możliwość wydruku miesięcznego pożyczek zawierającego: kwotę potrącenia, oraz salda pożyczek i salda wkładów. 16. Możliwość wydruku miesięcznych potrąceń składek ubezpieczenia np. PZU (każda grupa oddzielnie). 17. Możliwość wpisania okresu choroby dłuższego niż 30 dni i rozpisanie wypłaty na poszczególne miesiące z jednoczesną kontrolą ilości dni wypłaty w miesiącu. 18. Możliwość skorygowania (na liście płac i w kartotece zasiłkowej) nieprawidłowo wprowadzonego zwolnienia chorobowego. 19. Możliwość podglądu i wydruku podstawy zasiłków z podziałem na miesiące dla danego pracownika. 20. Możliwość wygenerowania zaświadczenia dla pracujących emerytów o wysokości osiągniętych w danym roku dochodów (łącznie za dany rok lub za poszczególne miesiące). 21. Możliwość zmiany parametrów programu w przypadku zmiany progów lub wskaźników ogólnie obowiązujących tj.: progów podatkowych, postawy ograniczenia składek emerytalno- rentowych, ulg podatkowych, procentu składki wypadkowej itp. 22. Możliwość kontroli naliczania składki na fundusz pracy zgodnie z wymaganiami ZUS. 23. Możliwość podziału wypłat dla jednego pracownika na wiele ośrodków kosztów np. na Oddział i na Izbę Przyjęć. 24. Możliwość podziału poszczególnych składników wynagrodzenia na różne ośrodki kosztów (np. pracownik dostał wynagrodzenie za dodatkową pracę w wskazanym oddziale i tym wynagrodzeniem trzeba obciążyć koszty właśnie oddziału, nie robiąc dla tej osoby oddzielnej listy płac). 25. Możliwość procentowego podziału kosztów wynagrodzenia na wiele ośrodków kosztów. |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
26. Możliwość wydrukowania zestawienia kosztów dla dowolnego OPK. 27. Możliwość wyliczenie średnich urlopowych wg wybranych kryteriów. 28. Możliwość tworzenia list płac na poszczególne składniki np. lista nagród jubileuszowych. 29. Możliwość określenia dla danej listy płac daty wypłaty oraz okresu księgowania. 30. Możliwość korygowania składników wynagrodzenia i potrąceń. 31. Możliwość korygowania potrąconych składek na ubezpieczenie społeczne za bieżący rok. 32. Możliwość wydruku list dotyczących umów cywilno-prawnych. 33. Możliwość stosowania mechanizmu zamykania list płac (blokada zmian) przez uprawnionych użytkowników. 34. Możliwość wydruku zestawień zbiorczych list płac z podziałem na komórki i OPK zarówno ze wszystkich list, jak i z dowolnie wybranych list wg określonego kryterium (np. kosztowo, podatkowo). 35. Możliwość wydruku zestawień dla wybranego składnika listy (np. dodatków specjalnych, kwoty do przelewu, składki emerytalnej). 36. Możliwość tworzenia raportów do ZUS dla programu Płatnik zgodnie z obowiązującymi przepisami. 37. Możliwość eksportu danych dotyczących wynagrodzeń do programu Płatnik na potrzeby przygotowania raportów ZUS zgodnie z obowiązującymi przepisami. 38. Możliwość tworzenia raportu dotyczącego kwoty podatku dochodowego przekazywanego do Urzędu Skarbowego w danym miesiącu. 39. Możliwość generowania i wydruku deklaracji XXX-0X, XXX-00, PIT- 40 zgodnie z obowiązującymi przepisami. 40. Możliwość wygenerowania raportów dla XXX zgodnie z obowiązującymi przepisami. 41. Możliwość automatycznego tworzenia plików do programów umożliwiających wykonywanie przelewów elektronicznych. 42. Możliwość generowania przelewów na podstawie obliczonych wynagrodzeń. 43. Możliwość drukowania pasków wynagrodzeń dla wszystkich, dla wybranej grupy lub dla jednej osoby. 44. Możliwość tworzenia zbiorówek z list oraz trwałego zapisania zbiorówek w niezmiennej np. w formie pliku PDF). | ||
27. | Moduł Kadry | Moduł musi posiadać następujące funkcjonalności: 1. Możliwość wyboru zakresu danych w ramach raportów ekranowych oraz wydruku tych raportów. 2. Możliwość ustawiania uprawnień na poziomie funkcji jak również na poziomie obiektów (rejestry, typy dokumentów, zestawienia, grupy kartotek) poprzez mechanizm użytkowników, haseł oraz uprawnień w systemie. 3. Możliwość przypisania do pracownika terminów obowiązywania: ▪ umowy, ▪ badań lekarskich, ▪ ważności szkolenia BHP, ▪ ważności innych szkoleń i uprawnień zawodowych 4. Możliwość rozróżniania (tryb nieaktywny) pracowników, którzy zakończyli pracę w Szpitalu na wszystkich swoich umowach. 5. Możliwość zapewnienia identyfikacji pracowników, którzy są zatrudnieni jednocześnie na umowę o pracę i umowę cywilnoprawną, jako jednej kartoteki. 6. Możliwość wyboru kartoteki po podstawowych kryteriach np. kategoria pracownika, numer identyfikacyjny, nazwisko oraz po dowolnej frazie występującej we wskazanych kryteriach i wyróżnikach. |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
7. Możliwość wygenerowania wskazanego dokumentu (np. świadectwa pracy) dla wielu pracowników jednocześnie (wybór z listy). 8. Możliwość nadawania numeru kartoteki - numeru identyfikacyjnego pracownika. 9. Możliwość rejestrowania danych osobowych pracownika (nazwisko, imiona, nazwisko xxxxxx, imiona rodziców, data i miejsce urodzenia, obywatelstwo, dane dokumentu tożsamości, PESEL, NIP, XXXXX, płeć, nr akt osobowych, informacja o niekaralności pracownika. 10. Możliwość rejestrowania kilku adresów pracownika ze wskazaniem typu adresu (adres zameldowania, zamieszkania, do korespondencji). 11. Możliwość wpisania kilku sposobów kontaktu z pracownikiem ze wskazaniem ich typu np. adres e-mail, telefon kontaktowy. 12. Możliwość rozróżnienia w programie struktury kosztowej (OPK) od struktury organizacyjnej. 13. Możliwość wygenerowania hierarchicznej (drzewiastej) struktury firmy (zależności między jednostkami organizacyjnymi). 14. Możliwość stworzenia otwartego słownika szkół ukończonych przez pracowników lub odbytych kursów i szkoleń tj. z możliwością dodawania i edycji pozycji. Pozycja słownikowa powinna zawierać: nazwa szkoły/uczelni, pole tekstowe dla dowolnego opisu 15. Możliwość prowadzenia ewidencji historii wykształcenia pracownika. Dane o ukończonej szkole (nazwa szkoły, data ukończenia, tryb ukończenia, wykształcenie, zakres, kierunek/specjalność, zawód wyuczony, pełny i skrótowy tytuł naukowy. Określenie ilości lat nauki pokrywających się ze stażem. 16. Możliwość prowadzenia ewidencji członków rodzin pracownika (imię, nazwisko, data urodzenia, XXXXX, stopień pokrewieństwa, adres zamieszkania). Uprawnienia członków rodzin do ubezpieczenia zdrowotnego, stopień niepełnosprawności, czy na wyłącznym utrzymaniu ubezpieczonego, czy wspólne gospodarstwo domowe z ubezpieczonym. Dane o członkach rodzin wykorzystywane są między innymi do generacji ZCNA. 17. możliwość przygotowania i wydruku różnych typów dokumentów w szczególności: ▪ umów określonych w przepisach prawa pracy i kodeksu cywilnego (wartości słownikowe np. umowa na okres próbny, czas określony, nie określony, umowa na zastępstwo, umowa zlecenie, umowa o dzieło). ▪ zmian w umowach (porozumienia, aneksy, wypowiedzenia zmieniające), ▪ rozwiązań umów, ▪ zaświadczeń o zatrudnieniu w tym druków wymaganych przez ZUS, ▪ świadectw pracy. 18. Możliwość wydruku świadectwa pracy wg wzoru określonego przepisami prawa z wykorzystaniem danych zawartych w systemie: okres zatrudnienia, wymiar, dane osobowe, kolejno zajmowane stanowiska wraz z okresem ich zajmowania, sposób rozwiązania umowy, wykorzystanie urlopów wypoczynkowych, zwolnienia lekarskie z okresu zatrudnienia (okresy trwania i liczba dni), informacje dodatkowe np. zajęcia komornicze. 19. Możliwość zawierania wielu umów z jednym pracownikiem w tym samym czasie (np. 2 różne umowy o pracę, umowa o pracę + umowa cywilnoprawna) z określeniem typu umowy (umowa podstawowa, dodatkowa, umowna cywilno-prawna) i statusu umowy (aktywna, zrealizowana). 20. Możliwość wprowadzania aneksu, angażu, zmiany warunków zatrudnienia (porozumienia stron) - śledzenie historii zmian |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
parametrów umowy (data zmiany, nowe miejsce wykonywanej pracy, stanowisko, kategoria zaszeregowania, wymiar czasu pracy, wynagrodzenie, dodatki do umowy w szczególności: za specjalizację, za posiadany tytuł naukowy). 21. Możliwość zawierania nowej umowy (przedłużenie) z wykorzystaniem danych już zarejestrowanych w Systemie (kopia umowy). 22. Możliwość określenia czy dla danej umowy uwzględniać wybrane typy staży tj. rodzajów zatrudnienia na potrzeby liczenia dodatków za wysługę lat pracy i nagród jubileuszowych. 23. Możliwość automatycznego przeliczania stażu pracy na podstawie wprowadzonej historii zatrudnienia. 24. Możliwość liczenia stażu zgodnie z odrębnymi regulacjami prawnymi i wewnętrznymi na potrzeby wysługi lat pracy i nagród jubileuszowych. 25. Możliwość przeliczania okresów zatrudnienia pracownika do ustalenia prawa do świadczeń emerytalnych. 26. Możliwość ewidencji historii zatrudnienia w poprzednich zakładach pracy, czas trwania poprzedniej umowy, sposób rozwiązania, stanowisko, nazwa firmy, wykorzystane absencje wykazane w ostatnim świadectwie pracy, wybór rodzajów stażu uwzględnianych przy obliczaniu składników, określenie daty początku naliczania stażu dla każdej z umów. 27. Możliwość określenia miejsca wykonywanej pracy (wg słownika struktury organizacyjnej). 28. Możliwość powiązania danego elementu struktury organizacyjnej z danym OPK. 29. Możliwość ewidencji badań lekarskich pracownika. Określenie typu badań (wstępne, okresowe, kontrolne), daty badania i ważności badań 30. Możliwość wydrukowania skierowania na badania lekarskie z wykorzystaniem danych zawartych w Systemie. 31. Możliwość ewidencji szkoleń BHP pracownika. Określenia typu szkoleń (w szczególności wstępne, stanowiskowe), daty szkolenia 32. Możliwość prowadzenia ewidencji praw wykonywania zawodu pracowników (numer prawa, data nadania i ważności). 33. Możliwość nadawania uprawnień urlopowych pracownikom (w przypadku umów zawieranych na okres próbny, czas określony - proporcjonalnie do okresu zatrudnienia) wraz z jednoczesną kontrolą ilości wykorzystanego przez pracownika urlopu w danym roku. 34. Możliwość kontroli liczby wykorzystanych dni urlopu na żądanie oraz kontroli zaległych urlopów. 35. Możliwość przydziału dodatkowych dni urlopowych dla pracownika: urlop wypoczynkowy wyrównawczy, urlopy szkoleniowe, urlopy związane ze stopniem niepełnosprawności. 36. Możliwość udzielania urlopów i ich rozliczanie w dniach lub w systemie godzinowym (w zależności od pracownika bądź grupy pracowników, systemu ich pracy oraz wymiaru zatrudnienia). 37. Możliwość ewidencji wszystkich rodzajów urlopów i zwolnień pracownika. 38. Możliwość automatycznej kontroli limitów urlopowych oraz chorobowych (wraz z kontrolą wieku pracowników). 39. Możliwość nadawania uprawnień związanych z rodzicielstwem, z jednoczesną kontrolą ich wykorzystania. 40. Możliwość pełnej ewidencji absencji pracownika. 41. Możliwość podglądu pełnych absencji również tych na przełomie roku. 42. Możliwość określenia szczególnych warunków pracy na wybranym stanowisku (kod ZUS i składka). 43. Możliwość tworzenia wykazu stanowisk oraz wykazu pracowników objętych składkami na FEP. |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
44. Możliwość określenia przynależności pracownika do US (dane wykorzystywane podczas generowania deklaracji podatkowych) oraz NFZ. Dane do US i NFZ wybierane ze słownika. 45. Możliwość ewidencji kar, nagród i odznaczeń przyznanych pracownikom (nazwa, data otrzymania, data odwołania terminu). 46. Możliwość ewidencjonowania informacji dotyczących przebiegu zatrudnienia np. specjalizacje lekarskie: stopień, rodzaj, data uzyskania, nazwa, kod specjalizacji (wybierane ze słownika), zakres obowiązków na danym stanowisku z datą obowiązywania, uprawnienia biegłego sądowego. 47. Możliwość wygenerowania informacji o rodzaju zatrudnienia (dla zestawień GUS) 48. Możliwość określenia prawa do emerytury lub renty oraz stopnia niepełnosprawności (własności słownikowe) oraz przypisywany indywidualnie nr świadczenia wraz z datami obowiązywania). 49. Możliwość określenia dokładnie nominalnego czasu pracy oraz obowiązujących okresów rozliczeniowych. 50. Możliwość planowania i ewidencjonowania czasu pracy dla wszystkich pracowników (niezależnie od obowiązującej pracownika normy dobowej, systemu czasu pracy, czy rozkładu pracy). 51. Możliwość wygenerowania wymaganego grafiku (planowany, wykonany, ewidencja czasu pracy, rozliczenie godzin (w szczególności nadliczbowe, nocne, świąteczne, dyżury medyczne, gotowość): czas przepracowany w danym miesiącu, okresie rozliczeniowym (ilość godzin), absencje (urlopy, zwolnienia lekarskie - wynagrodzenie, zasiłek chorobowy), urlopy bezpłatne, wychowawcze, zasiłki opiekuńcze, macierzyńskie, rodzicielskie, ojcowski, świadczenia rehabilitacyjne, delegacje, inne nieobecności usprawiedliwione, nieobecności nieusprawiedliwione (czas trwania, ilość godzin), dyżury medyczne (ilość godzin, struktura), godziny nadliczbowe wg rodzaju (z tyt. przekroczenia normy dobowej, normy średniotygodniowej, normy okresu rozliczeniowego) (ilość godzin, struktura - do wybrania, do opłacenia dodatkami 50%, 100%, 20%, 45%, 65%), praca personelu medycznego zatrudnionego w systemie zmianowym w niedziele, święta oraz dni wolne wynikające z przeciętnie pięciodniowego tygodnia pracy) ( ilość godzin, struktura), praca w porze nocnej (ilość godzin). 52. Możliwość definiowania kalendarza firmowego. Dowolne ustawienie dni roboczych, wolnych, świątecznych. 53. Możliwość zliczania wprowadzonego czasu pracy. Ewidencja i rozliczanie godzin do wybrania i wybieranych, godzin opłacanych odpowiednimi dodatkami zgodnie z obowiązującymi przepisami prawa. 54. Możliwość wprowadzania grafików przez poszczególnych użytkowników. 55. Możliwość określenia wymiaru czasu pracy w systemie godzinowym i minutowym np. 7 godzin 35 minut 56. Możliwość proporcjonalnego pomniejszania czasu pracy danego pracownika w przypadku zatrudnienia danego pracownika w niepełnym wymiarze czasu pracy. 57. Możliwość dowolnej definicji typów nieobecności. Wybór kodów wg ZUS, określenie limitów dni w roku lub limitów indywidualnych dla pracownika w zadanym okresie roku. 58. Możliwość drukowania miesięcznej, okresowej i rocznej ewidencji czasu pracy. Ewidencja godzin do wybrania i wybieranych. Bilansowanie godzin „nadpracowanych” pomiędzy kolejnymi miesiącami rozliczeniowymi. 59. Możliwość generowania miesięcznych, i rocznych zestawień obecności dla wybranego pracownika, grupy pracowników lub całej komórki na dany miesiąc lub okres rozliczeniowy. Powinno |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
zawierać faktyczny czas pracy, godziny przepracowane w godzinach nadliczbowych, niedziele i święta, nocne, dyżury, nieobecności w pracy (raport). 60. Możliwość sporządzania zaświadczeń o zatrudnieniu za wskazany okres z uwzględnieniem różnych umów / tylko wybranej umowy oraz absencji pracownika. 61. Możliwość generowania zestawienia sprawdzającego ważność badań lekarskich pracowników. Możliwość generacji zestawienia ważności badań lekarskich wg. komórek organizacyjnych i formy zatrudnienia (raport). 62. Możliwość wygenerowania zestawienia o szkoleniach pracowników (rodzaje, terminy). 63. Możliwość sporządzania planów urlopów na dany rok. 64. Możliwość wygenerowania zestawień o stażach pracowników. 65. Możliwość sprawdzenia, którzy pracownicy w ciągu roku przekroczą progi dla staży ze zdefiniowanymi progami ( np. maks. 7 dni w roku/ 5 dni w roku / 3 dni w roku). 66. Możliwość generowania wydruku karty zasiłkowej (zestawienie nieobecności chorobowych pracownika (płatne przez ZUS i pracodawcę). 67. Możliwość wygenerowania zestawienia zawierającego informacje o okresach zaliczanych do stażu pracowników. 68. Możliwość generowania informacji o przeciętnym zatrudnieniu na każdy dzień wybranego miesiąca i za dany miesiąc lub za dany okres 69. Możliwość zmiany parametrów programu w przypadku zmiany progów lub wskaźników ogólnie obowiązujących np. limity urlopowe. 70. Możliwość tworzenia wymaganych raportów do ZUS dla programu Płatnik (ZUA, ZZA, ZCNA, ZWUA, ZIUA, ZSWA, prawidłowe kody ubezpieczeniowe, po ustaniu stosunku pracy, pracowników przebywających w okresie urlopu macierzyńskiego, wychowawczego, bezpłatnego, nieobecność usprawiedliwiona niepłatna). 71. Możliwość tworzenia raportów wymaganych przez GUS w szczególności: Z-03, Z-05, Z-06, Z-12. 72. Możliwość tworzenia zaświadczeń o przebiegu zatrudnienia z uwzględnieniem każdego okresu pracy w komórkach organizacyjnych pracodawcy. | ||
28. | Moduł Środki Trwałe | Moduł musi posiadać następujące funkcjonalności: 1. Możliwość prowadzenia pełnej ewidencji obiektów inwentarzowych (pełnej ewidencji majątku trwałego) w układzie danych ewidencjonowanych na indywidualnych kartotekach. Kartoteka ma mieć możliwość rejestracji informacji o obiekcie w co najmniej zakresie: ▪ numeru inwentarzowego ▪ kodu kreskowego ▪ nazwy obiektu inwentarzowego ▪ symbol klasyfikacji GUS ▪ typ środka trwałego ▪ sposób naliczania amortyzacji ▪ współczynnik amortyzacji ▪ forma własności ▪ status środka (w użytkowaniu, wyłączony) ▪ data przyjęcia, data wykreślenia z ewidencji, data przeszacowania ▪ wartość początkowa, wartość po przeszacowaniu ▪ umorzenie bilansowe/roczne/miesięczne, aktualna wartość bilansowa ▪ użytkownik/data przyjęcia przez użytkownika/konto powstawania kosztów ▪ dostawca / sprzedawca / właściciel |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
▪ numer fabryczny obiektu/rok produkcji ▪ pole tekstowe 1000-1500 znaków do umieszczenia wyczerpujących informacji dodatkowych (opis zdarzeń związanych z obiektem). 2. Możliwość rejestracji poszczególnych składników obiektu inwentarzowego (obiektów składowych), np. dla zespołu komputerowego rejestracja jednostki centralnej, monitora, klawiatury. 3. Możliwość zdefiniowania dowolnych typów dokumentów określonego rodzaju: ▪ OT, OW – przyjęcia do użytkowania, ▪ LT – likwidacji, ▪ LC – likwidacji częściowej, ▪ PT – nieodpłatnego przekazania / przejęcia, ▪ MT – zmiany miejsc użytkowania, ▪ zmiany osób odpowiedzialnych, ▪ zmiany wartości i umorzenia. 4. Możliwość automatycznego naliczania amortyzacji dla celów bilansowych i podatkowych (stanowiącej koszty uzyskania i niestanowiącej kosztów uzyskania). 5. Możliwość automatycznego wygenerowania druków arkuszy spisu z wraz z wydrukiem listy obiektów inwentarzowych znajdujących się w danym OPK. 6. Możliwość w zakresie generowania pustych druków arkuszy spisowych. 7. Możliwość generowania druku arkusza spisowego w układzie wyboru wieloparametrowego, to jest wybór co najmniej w zakresie: ▪ pola spisowego – miejsc użytkowania, ▪ pozycji inwentarzowych wg KŚT (od-do) lub numeru inwentarzowego (od-do). 8. Możliwość zmiany stawki amortyzacji bilansowej i podatkowej z zachowaniem historii zmian. 9. Możliwość naliczania odpisów amortyzacyjnych wyznaczonych dowolnymi metodami: ▪ odpis jednorazowy, ▪ amortyzacja liniowa, ▪ amortyzacja degresywna, ▪ amortyzacja sezonowa, ▪ odpis wg stawki indywidualnej. 10. Możliwość wykonania inwentaryzacji wg ilości obiektów inwentarzowych (bez podawania wartości) oraz wg: ▪ miejsc użytkowania , ▪ numerów inwentarzowych, ▪ grupy KŚT , ▪ typu . 11. Możliwość korzystać z następujących funkcji przy wykonaniu inwentaryzacji: ▪ automatyczne wygenerowanie druków arkuszy spisowych, ▪ możliwość ręcznego naniesienia do systemu (na arkusze spisowe) pozycji spisanych, ▪ możliwość ręcznego wpisania pozycji niebędących w ewidencji a wynikających ze spisu, ▪ możliwość automatycznego wygenerowania rozliczenia spisu oraz zestawienia różnic inwentaryzacyjnych. 12. Możliwość, przy rozliczaniu inwentaryzacji, automatycznego wygenerowania: ▪ „rozliczenia spisu z natury” dla poszczególnych miejsc użytkowania– rozliczenie ma wskazywać wszystkie obiekty inwentarzowe podlegające spisowi i obiekty spisane, z określeniem co najmniej: nr inwentarzowego, nazwy, nadwyżki, niedoboru, |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
▪ zestawienia różnic inwentaryzacyjnych (wydruk braków i nadwyżek) ze wskazaniem czytelnego komunikatu o statusie pozycji, np. dla niedoboru – „środek jest w kartotece, brak go na arkuszu”, dla nadwyżki – „brak środka w kartotece, jest na arkuszu”, dla niedoborów i nadwyżek pozycji stanowych podanie wartości wg wartości początkowych przy nadwyżkach informacji o miejscu użytkowania wg danych z ewidencji. 13. Możliwość wykonania inwentaryzacji zdawczo - odbiorczej wg osób odpowiedzialnych z jednoczesnym automatycznym przepisaniem pozycji z osoby na osobę (bez konieczności „przebijania” każdego pojedynczego obiektu). 14. Możliwość określenia automatycznej numeracji numerów inwentarzowych oraz kodów kreskowych np. literowo(L)- cyfrowego(C): CCC-C-CCCLLCCCC np. 013-1-808KS2271. 15. Możliwość automatycznego wygenerowania zestawień-planów odpisów amortyzacyjnych ▪ w układzie trybu wielo wyborowego, to jest co najmniej: ▪ wg zakresu grup KRST (od-do), ▪ wg numerów inwentarzowych (od-do), ▪ wg miejsc użytkowania (od-do). 16. Możliwość automatycznego generowania zestawień-planów odpisów amortyzacyjnych w układzie planu amortyzacji dla celów bilansowych oraz dla celów podatkowych. Plan odpisów amortyzacyjnych ma zawierać co najmniej dane w zakresie: ▪ określenia okresu (roku), na który jest generowany plan, ▪ numeru inwentarzowego ▪ nazwy pozycji inwentarzowej ▪ daty przyjęcia do użytkowania, wartość początkową, stawkę amortyzacyjną, umorzenie początkowe, amortyzacji miesięcznej ze wskazaniem miesiąca oraz kwoty amortyzacji oraz amortyzacji razem dla danego roku. 17. Możliwość wygenerowania tabel amortyzacyjnych dla określonej klasyfikacji rodzajowej. Tabele zawierają informację o wartości BO, zwiększeniach, zmniejszeniach, kolejnych odpisach. Dane od początku roku do danego miesiąca danego roku. 18. Uniemożliwić powtórne naliczenie amortyzacji za dany okres w sytuacji wcześniejszego wygenerowania amortyzacji i jego zatwierdzenia. 19. Możliwość automatycznego wygenerowania standardowego dokumentu PK z automatycznym podaniem kont księgowych dla operacji : ▪ przyjęcia ▪ likwidacji ▪ przeszacowania. 20. Możliwość wielokrotnego naliczania amortyzacji, np. w przypadku ruchów na środkach zwiększenie, zmniejszanie, ponowne przeliczenie amortyzacji dla wybranego środka trwałego. 21. Możliwość zapewnienia informacji o wartościach występujących osobno dla amortyzacji bilansowej: ▪ wartość księgowa netto, ▪ wartość księgowa brutto, ▪ wartość początkowa, ▪ dotychczasowe umorzenie, ▪ procent umorzenia (bieżący stopień zużycia). 22. Możliwość likwidacji środka trwałego nie w pełni umorzonego w taki sposób, aby w miesiącu likwidacji amortyzacja za środek była naliczona. 23. Możliwość przesunięć obiektów pomiędzy zestawami, środkami trwałymi – dokumenty kompletowania / rozkompletowania . 24. Możliwość przypisania zdefiniowanego typu dokumentu do określonego typu majątku trwałego: środki trwałe, wyposażenia |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
(środki trwałe niskocenne), wartości niematerialne i prawne, pozabilansowe. 25. Możliwość tworzenia dokumentu zmiany miejsca użytkowania obiektu inwentarzowego w układzie pojedynczych obiektów na dokumencie oraz więcej niż jednego obiektu inwentarzowego na jednym dokumencie (kilku, kilkunastu, kilkudziesięciu). 26. Możliwość zmiany miejsc użytkowania, oraz osób odpowiedzialnych, osób nadzorujących obiekty inwentarzowe. Przy inwentaryzacji zdawczo-odbiorczej potwierdzenie zmiany osób odpowiedzialnych na inne osoby odpowiedzialne lub nadzorujące. 27. Możliwość zmiany osoby odpowiedzialnej bez zmiany miejsca użytkowania obiektu inwentarzowego. 28. Możliwość prowadzenia i wydruku ewidencji osób nadzorujących obiekty inwentarzowe. 29. Możliwość edytowania i poprawiania kartoteki środka trwałego już amortyzowanego zgodnie z nadanymi uprawnieniami. 30. Możliwość generowania raportów wg nadanych cech – grup oraz zakresów w grupie. 31. Możliwość ewidencjonowania typu środków trwałych wartości pozabilansowe (użyczony sprzęt medyczny, informatyczny). Sprzęt na który nie nalicza się amortyzacji miesięcznej, nalicza się natomiast raz na rok na potrzeby sprawozdawczości (CIT8). W przypadku konieczności możliwość zmiany naliczania amortyzacji w okresach miesięcznych. 32. Możliwość likwidacji jednego lub kilku obiektów inwentarzowych jednocześnie, możliwość dokładania nowych obiektów inwentarzowych, możliwość zmian miejsca użytkowania obiektów inwentarzowych. 33. Możliwość seryjnego zakładania kartotek tego samego typu środka inwentarzowego każde na osobnej kartotece z innym numerem inwentarzowym. Dla nisko cennych (to samo miejsce użytkowania, osoby odpowiedzialne, inne cechy środka, to jest na dokumencie przyjęcia) np. wprowadzenie 10 krzeseł wymaga podania cech obiektu tylko raz i podania liczby dodawanych identycznych obiektów inwentarzowych. Wszystkie 10 krzeseł zostanie wówczas zaewidencjonowanych z kolejnymi numerami inwentarzowymi. 34. Możliwość zapewnienia pełnej ewidencji dokumentów wpływających na wartość środków trwałych: numer faktury, dostawca, nazwa pozycji na dokumencie, kwota, data wystawienia dokumentu zakupu. 35. Możliwość przeglądania obiektów inwentarzowych i tworzenia zestawień wg typu majątku, nazwy (fragmentu nazwy), wg numeru inwentarzowego, wg miejsca użytkowania, wg OPK, osób odpowiedzialnych, grupy GUS, źródeł finansowania i innych, które zostaną zdefiniowane. 36. Możliwość tworzenia zestawień dokumentów w zadanym okresie wg typów, grupy GUS, OPK, miejsca użytkowania, osoby odpowiedzialnej, źródeł finansowania. 37. Umożliwia ewidencję wypożyczonych środków trwałych. | ||
29. | Moduł Sprawozdawczość i Analizy Finansowe | Moduł Sprawozdawczość i Analizy Finansowe musi posiadać następujące funkcjonalności: 1. Możliwość przygotowywania zestawień kosztów w różnych układach, np. według zużycia poszczególnych rodzajów materiałów. 2. Możliwość wygenerowania zestawiania przychodów według grup, miejsc ich powstania itp. 3. Możliwość zdefiniowania wzorców wspomagających rozliczanie. 4. Możliwość wyliczania danych do deklaracji VAT-7 oraz VAT-7K, z procentowym rozliczeniem VAT. 5. Możliwość naliczania i drukowania deklaracji CIT-2. |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
6. Możliwość bezpośredniego wyboru kont z planu kont oraz pozycji bilansu i rachunku zysków i strat. 7. Możliwość wygenerowania gotowych zestawień i raportów: • Dane do sprawozdania F01. • Gotowe wzory deklaracji podatkowych VAT-7, VAT-UE, CIT-2, w układzie zgodnym z wymaganiami Urzędów Skarbowych. • Wzorcowe arkusze obrotów kont i sald. • Xxxxxxx bilansu, rachunku zysków i strat w dowolnych przedziałach czasu. • Arkusz do przygotowania sprawozdania przepływów środków pieniężnych metodą pośrednią • Arkusz do przygotowania sprawozdania ze zmian w kapitale własnym. 8. Możliwość modyfikowania wzorcowych szablonów i dostosowywania ich do własnych potrzeb. 9. Funkcjonalność automatycznego wczytywania danych do zdefiniowanych raportów i zestawień. | ||
32. | Moduł Rejestracja Czasu Pracy | Moduł Rejestracja Czasu Pracy musi posiadać następujące funkcjonalności: 1. Zapewnienie autoryzowanego dostępu użytkowników z możliwością definiowania odpowiednich ról pracowników (nieograniczona liczba) i przypisywania im odpowiednich uprawnień . 2. Możliwość prowadzenia harmonogramu pracy dla dowolnej ilości osób, zgodny z przepisami prawa pracy. 3. Możliwość podziału pracowników na dowolną ilość oddziałów i komórek organizacyjnych. 4. Możliwość definiowania kalendarza, dni świątecznych oraz rozkładu standardowego pięciodniowego tygodnia pracy, godzinowych systemów pracy, dyżurów personelu medycznego. 5. Możliwość planowania i rozliczania czasu pracy w dowolnym okresie rozliczeniowym, z możliwością definiowania różnych okresów rozliczeniowych dla różnych grup pracowników nawet w ramach jednej jednostki organizacyjnej. 6. Możliwość podzielenia dziennego czasu na czas pracy, przepracowany w dwóch lub więcej komórkach organizacyjnych jak i również uwzględniający wykonywane czynności, np. dyżur, gotowość, itp. Możliwość podziału czasu pracy w obrębie dnia na czynności z możliwością podziału na stanowiska kosztów. 7. Możliwość kontroli przestrzegania wymagań kodeksowych planowania czasu pracy . 8. Możliwość obsługi wszystkich występujących w służbie zdrowia systemów pracy, min. dla: pielęgniarek, lekarzy, administracji, pracowników RTG oraz różne okresy rozliczeniowe. 9. Możliwość podglądu sum godzin przepracowanych i nieobecnych z podziałem na typy, wg ustalonych kodów (rodzaje godzin i odpowiadające im kody zostaną określone na etapie Wdrożenia). 10. Możliwość dopisania w grafiku WYKONANY nadgodzin w danym dniu pracy, z podziałem na godziny nocne i świąteczne (możliwość zarejestrowania wszelkich zmian, typu nieplanowany urlop na żądanie, opieka, choroba, urlop okolicznościowy, zamiana dyżuru, itp.) Możliwość dopisania faktycznego czasu pracy pracowników, rejestracja godzin nieobecności, dodatkowych godzin pracy. 11. Możliwość wglądu do określonych danych pracownika 12. Możliwość ewidencjonowania szkoleń pracowniczych. 13. Funkcjonalność automatycznego tworzenia grafików dla pracowników zmianowych. 14. Możliwość tworzenia dowolnej ilości harmonogramów czasu pracy, podpinania ich pracownikom oraz na jego podstawie automatycznego wypełniania grafików planowanych. |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
15. Możliwość wystawiania, przeglądania, zapisywania wniosków urlopowych z automatyczną aktualizacją zaplanowanego czasu pracy w przygotowanych grafikach. 16. Możliwość przechowywania informacji o szkoleniach oraz uprawnieniach pracowników. Możliwość definiowania wymaganych uprawnień, które pracownik powinien posiadać. 17. Możliwość kontrolowania, czy lekarze mają podpisaną klauzulę OPT-OUT. Pracownicy tacy są uwidaczniani na grafiku np. innym kolorem. 18. Funkcjonalność automatycznej kontroli w przypadku braku podpisanej klauzuli OPT-OUT przez pracownika, czy nie został przekroczony czas pracy lekarza. 19. Możliwość automatycznego rozliczania czasu pracy na podstawie zatwierdzonych grafików np.: nadgodziny. Aplikacja w sposób automatyczny wylicza nadgodziny, jako ilość godzin przepracowanych ponad zaplanowany limit. 20. Możliwość rozliczania nadgodzin poprzez ich odbiór w okresie rozliczeniowym. 21. Funkcjonalność zapewnienia obsługi dyżurów lekarskich, rozliczania czasu pracy lekarzy funkcją wprowadzającą automatyczny podział czasu pracy na czas wynikający z etatu oraz dyżur lekarski. 22. Funkcjonalność rozliczenia dyżurów lekarskich odliczanych od nominalnego czasu pracy z podziałem na dyżur 50% i dyżur 100% (i ew. innych). 23. Możliwość generowania, zapisywania, elektronicznej archiwizacji (w formacie pdf) i drukowania ewidencji czasu pracy w postaci wydruków (Indywidualna Karta Ewidencji Czasu Pracy): a. dla pracowników ujętych w grafikach b. dla pracowników nieujętych w grafikach 24. Możliwość stworzenia Indywidualnej Karty Ewidencji Czasu Pracy (wzór opracowany na etapie opracowania Projektu Technicznego). 25. Możliwość drukowania planowanej ewidencji czasu pracy 26. Możliwość pełnego wglądu w ewidencję czasu pracy pracowników (pielęgniarki, lekarze, administracja) prowadzoną w poszczególnych działach. 27. możliwość rozliczenia godzin pracy dla potrzeb naliczenia wynagrodzeń: automatyczne obliczanie w oparciu o faktyczny czas pracy pracownika liczby przepracowanych godzin świątecznych, nocnych, (rozliczenie powinno być przygotowywane w rozbiciu na miejsca zatrudnienia pracownika). 28. Zapewnienie autoryzowanego dostępu użytkowników z możliwością definiowania odpowiednich ról pracowników (nieograniczona liczba) i przypisywania im odpowiednich uprawnień | ||
31. | Moduł analityczny | 1. Dostęp do danych przetwarzanych w pozostałych modułach systemu 2. Możliwość wybrania do tworzonego raportu dowolnego zakresu danych w trybie graficznym 3. Możliwość definiowania filtrów dla raportu 4. Możliwość tworzenia zapytań SLQ 5. Możliwość definiowania nazwy raportu 6. Możliwość zapisania utworzonego raportu 7. Możliwość nadania uprawnień dostępu do raportu 8. Możliwość modyfikacji stworzonych wcześniej raportów 9. Możliwość generowania wcześniej stworzonego raportu 10. Możliwość usunięcia stworzonego wcześniej raportu 11. Możliwość grupowania po kolumnach 12. Możliwość włączania lub wyłączania kolumn prezentowanych w wybranym raporcie 13. Możliwość eksportowania danych raportu do CSV, XLS, PDF |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
Elektroniczny System Obiegu Dokumentów | ||
Założenia przyjęte w zakresie architektury rozwiązania: | 1) System musi być zbudowany w architekturze trójwarstwowej, złożonej z: a) kodu generowanego do interpretacji przez przeglądarkę internetową, b) serwera aplikacji (pośredniczącego między żądaniami programu klienckiego, a motorem bazy danych), c) motoru bazy danych, zarządzającego SQL-ową bazą danych. 2) System ma umożliwiać pracę na minimum jednej bazie komercyjnej oraz jednej bazie typu Open Source. 3) Zastosowany motor bazy danych ma umożliwiać/obsługiwać: a) podzapytania (ang. subqueries), b) kontrolę spójności referencyjnej danych (ang. referential integrality), c) wbudowane języki proceduralne (ang. stored procedural languages), d) rozbudowane indeksy, e) klucze obce, f) sekwencje, g) kursory, h) widoki, i) definiowane typy. 4) System ma mieć możliwość instalacji na platformie Linux lub MS Windows Serwer - system w warstwie serwera aplikacji i bazy danych można uruchomić w środowiskach opartych na technologii Microsoft Windows Server oraz w środowiskach opartych na systemie Linux. 5) System w warstwie klienckiej musi poprawnie działać z minimum następującymi przeglądarkami WWW: a) Microsoft Internet Explorer 10, 11 b) Mozilla Firefox – wersja aktualna 6) System ma umożliwiać realizację wszystkich czynności przez przeglądarkę internetową z obsługą wirtualnej maszyny Java i do poprawnej pracy nie wymaga zainstalowania żadnych dodatkowych komponentów (oprócz Java JRE, oprócz sterowników do skanerów, oprócz oprogramowania do podpisu cyfrowego). 7) Dopuszcza się odstępstwo od wymagania powyższego dla celów integracji dodawania dokumentów do repozytorium EZD bezpośrednio z zewnętrznych edytorów tekstowych. Dopuszcza się odstępstwo od wymagania powyższego dla celów integracji dodawania dokumentów do repozytorium EZD bezpośrednio z oprogramowania Microsoft Outlook. Dopuszcza się odstępstwo od wymagania powyższego dla celów integracji dodawania dokumentów do repozytorium EZD bezpośrednio ze skanerów. 8) Interfejs użytkownika, w celu zminimalizowania liczby załadowań całych stron przy każdorazowym kliknięciu, musi wykorzystywać technologię AJAX, co najmniej w zakresie: a) Przeglądania i uzupełniania metadanych dokumentów, b) Przeglądania i uzupełniania metadanych spraw, c) Przeglądania i uzupełniania metadanych delegacji, d) Przeglądania i uzupełniania metadanych urlopów, e) Przeglądania i uzupełniania metadanych rezerwacji, f) Przeglądania i uzupełniania Pocztowych Książek Nadawczych, g) Przeglądania i odszukiwania odpowiedniej kategorii JRWA podczas nadawania znaku sprawy. 9) System nie może ograniczać w żaden sposób przetwarzanych plików ze względu na format. Musi umożliwić także określenie maksymalnego dopuszczalnego rozmiaru pliku przechowywanego w systemie | |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
10) System musi posiadać budowę modułową, umożliwiając stopniowe ich uruchamianie. 11) System, w warstwie prezentacji musi być zoptymalizowany do pracy w rozdzielczości 1280x800 lub wyższej, w oparciu o tzw. interfejs responsywny. 12) System musi być skalowalny, poprzez możliwość dołączenia dodatkowych stanowisk komputerowych, zwiększenie zasobów obsługujących warstwę aplikacyjną, zwiększenie zasobów obsługujących warstwę bazy danych. 13) System musi pracować poprawnie na stacjach roboczych użytkowników systemu spełniających wymagania: i. Monitor z rozdzielczością 1280x800. ii. Procesor: Intel Core 2000 MHz lub innych o podobnej wydajności, iii. Pamięć RAM: 2GB (4GB na systemach 64bit) lub więcej, iv. Pamięć dyskowa: zapewniająca poprawną i wydajną pracę systemu operacyjnego, v. System operacyjny: Windows 7, 8, 8.1 14) System musi mieć możliwość pracy w oparciu o bazy danych komercyjne i bazy danych open source oraz umożliwiać integrację z innymi dziedzinowymi systemami informatycznymi 15) Uwierzytelnianie użytkowników może odbywać się za pomocą uprawnień zapisanych w MS Active Directory (własność ta powinna stanowić element konfiguracji systemu). 16) System musi posiadać interfejs programistyczny wykorzystujący, jako standard komunikacyjny WebServices, pozwalający na bezpieczną wymianę danych z innymi systemami co najmniej w zakresie: a) Dokumentów b) Spraw c) Słowników d) Powiadomień e) Użytkowników 17) Komunikacja użytkownika z Systemem EZD może odbywać się za pomocą połączenia szyfrowanego SSL (własność ta powinna stanowić element konfiguracji systemu). 18) Poszczególne elementy systemu muszą się dwukierunkowo kontaktować w oparciu o protokół SOAP (Simple Object Application Protocol). 19) System powinien posiadać możliwość rozszerzenia funkcjonalności bazowych elektronicznego obiegu dokumentów poprzez doinstalowanie dedykowanego modułu WorkFlow. Moduł ten powinien pozwalać na pełną obsługę zadań procesowych z poziomu interfejsu systemu obiegu dokumentów i wykorzystywać jego API tak, aby produkty powstałe w wyniku wykonywania procesów WorkFlow miały odzwierciedlenie i reprezentację w systemie (dokumenty oraz sprawy i ich metadane, zadania, podpisy, akceptacje itd.). | ||
ASPEKTY BEZPIECZEŃSTWA SYSTEMU - aksjomaty niezbędne do uznania systemu za gotowy do wdrożenia | ||
20) System zapewnia spójność przechowywanych danych w bazie danych, poprzez stosowanie transakcji. System zapewnia wycofanie czynności objętej transakcją w przypadku niepowodzenia jej wykonania. 21) System umożliwia okresowe wykonywanie, w sposób automatyczny, pełnej kopii aplikacji i/lub danych systemu. 22) System pozwala na jednoczesny dostęp do danych wielu użytkownikom oraz zapewnia ochronę tych danych przed utratą spójności lub zniszczeniem. 23) Pliki binarne przetwarzane w systemie są przechowywane w repozytorium odrębnym w stosunku do bazy przechowującej rdzenne (nie plikowe) dane. |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
24) System dla każdego pliku automatycznie generuje i przechowuje w bazie sumę kontrolną z zawartości pliku. System każdorazowo informuje użytkownika, w trakcie przeglądania dokumentów o naruszeniu integralności plików sprawdzając sumę kontrolną. 25) System umożliwia rozdzielenie warstwy aplikacji od warstwy bazodanowej na różne maszyny fizyczne. 26) System pozwala na uwierzytelnianie się użytkowników w ramach aplikacji na różne sposoby, w tym co najmniej: za pomocą loginu i hasła i/lub poprzez Active Directory. Administrator w stosunku do każdego użytkownika decyduje o dostępnej dla niego metodzie uwierzytelnienia. 27) Konfiguracja systemu w zakresie haseł użytkowników umożliwia określenie co najmniej: a) Liczby niepowtarzalnych ostatnich haseł (w przypadku gdy system wymusza jego okresową zmianę) b) Maksymalnej liczby nieudanych prób logowania, po przekroczeniu której użytkownik zostaje zablokowany i bez interwencji administratora nie może się zalogować. c) Liczbę dni co którą system wymusza nadania hasła, w tym wyłączenie tego warunku. d) Minimalnej liczby znaków w haśle. e) Znaków wymaganych w haśle. 28) System musi się komunikować z systemami zewnętrznymi w sposób zapewniający poufność danych. Dopuszcza się jako rozwiązanie wykorzystanie protokołu SSL i połączenia VPN. 29) System musi być odporny na znane techniki ataku i włamań, typowe dla technologii w której został wykonany. System umożliwia określenie czasu nieaktywności, po którym użytkownik zostaje wylogowany (w przypadku braku wykonania jakiejkolwiek czynności w systemie). | ||
FUNKCJONALNOŚCI OGÓLNE | ||
System jest w pełni zgodny z obowiązującymi przepisami prawa a w szczególności: a) Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych, b) Rozporządzenia Prezesa Rady Ministrów z dnia 18 stycznia 2011 r. w sprawie instrukcji kancelaryjnej, jednolitych rzeczowych wykazów akt oraz instrukcji w sprawie organizacji i zakresu działania archiwów zakładowych, USTAWA z dnia 18 września 2001 r. o podpisie elektronicznym | ||
Praca podstawowa przez przeglądarkę internetową. | ||
Uwierzytelnianie użytkowników zintegrowane z uwierzytelnianiem na bazie usług katalogowych. | ||
System umożliwia przeglądanie list spraw i dokumentów oraz innych elementów systemu w postaci listy kafelek lub listy tabelarycznej. | ||
FUNKCJONALNOŚCI MODUŁU OBSŁUGI DOKUMENTÓW | ||
System realizuje wykonanie odwzorowania cyfrowego dokumentu wpływającego do Jednostki. | ||
Dokument opisywany jest następującymi metadanymi: ▪ Numer/ identyfikator – nadawany automatycznie, ▪ Oznaczenie komórki – pole słownikowe, do której kwalifikowany jest dokument, ▪ Rodzaj / kategoria dokumentu – pole słownikowe np.: faktura, decyzja. ▪ Dane teleadresowe zawierające minimum następujące pola (wspomagane TERYT): • Osoba prawna lub fizyczna, • Skrót, • Nazwa albo nazwisko i imię |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
• NIP, • REGON albo PESEL, • Skrytka pocztowa, • Miasto, • Kod pocztowy, • Ulica, • Numer budynku, • Numer lokalu, • Kraj, • Województwo, • Powiat, • Gmina, • Osoba kontaktowa w przypadku osoby prawnej ▪ Adresat (system umożliwia wpisanie ręczne bądź dokonanie wyboru z bazy kontaktowej), ▪ Data ważności, ▪ Data wpływu ▪ Data na piśmie ▪ Oznaczenie dokumentu, jako pilny, ▪ Numer nadawczy ▪ Zewnętrzny znak dokumentu(numer zawarty na piśmie – znak pisma, nr faktury itp.) ▪ Sposób dostarczenia – wybór pola ze słownika np.: list zwykły, email itd. ▪ Opis dokumentu, ▪ Słowa kluczowe, ▪ Lokalizacja fizyczna, ▪ Dowolnie zdefiniowane pola – dostosowywane do wybranej kategorii rejestrowanego dokumentu Numer dokumentu jest generowany zgodnie z kolejnością wpływu | ||
System umożliwia obsługę pism składanych w postaci elektronicznej: pocztą elektroniczną, na nośnikach cyfrowych. | ||
System wspomaga rejestrację wielu dokumentów z jednej przesyłki wpływającej (koperta zawierająca wiele dokumentów od tego samego nadawcy) poprzez możliwość wykorzystania całego zestawu danych z rejestracji poprzedniego pisma poprzez użycie schowka. | ||
System pobiera dane adresowe z bazy adresowej, a w razie braku danych o osobie fizycznej bądź prawnej następuje wprowadzenie jej do ewidencji. | ||
System posiada funkcjonalność przekazywania odwzorowania cyfrowego do więcej niż jednego użytkownika bez konieczności jego powielania. | ||
Możliwa jest modyfikacja – uzupełnianie bądź zmiana metadanych w systemie. | ||
Informacja o odebraniu pisma przez użytkownika wraz z możliwością wydruku przedmiotowego potwierdzenia. Informacja zawiera oznaczenie pisma, datę oraz godzinę odbioru pisma przez użytkownika z możliwością wydruku na stronie A4 bądź A5. | ||
Możliwość dołączenia dokumentów, połączeń/powiązań z dokumentami, elementów w formie elektronicznej. | ||
Możliwość nadania numeru archiwalnego na dokumencie bez konieczności tworzenia sprawy oraz zarchiwizowanie dokumentu. | ||
Zeskanowany obraz lub automatycznie przygotowany podgląd dokumentu prezentowany jest zawsze w centralnej części widoku dokumentu. | ||
System umożliwia oznaczenie każdego pisma unikalnym kodem kreskowym wygenerowanym przez system podczas rejestracji oraz naniesienie tego kodu kreskowego na podgląd wcześniej zeskanowanego dokumentu. | ||
System posiada możliwość dołączania do dokumentów: • Obrazu dokumentu (odwzorowania cyfrowego) |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
• Elementów w formie elektronicznej (w tym plików multimedialnych) • Notatek • Terminów z terminarza • Powiązań z innymi dokumentami | ||
System jest wyposażony w mechanizm akceptacji, który umożliwia co najmniej: ▪ Akceptację przez jednego użytkownika – element jest zaakceptowany tylko przez jednego użytkownika (np.: jeden z jeden) ▪ Przesłanie dokumentu do wielu i akceptację przez jednego z nich – element jest zaakceptowany gdy tę operację wykona jeden z grupy użytkowników (np.: jeden z trzech) ▪ Przesłanie i akceptację przez wielu użytkowników – element jest zaakceptowany gdy tę operację wykona większość użytkowników (np.: dwóch z trzech) ▪ Przesłanie i akceptację przez wszystkich – element jest zaakceptowany gdy tę operację wykonają wszyscy użytkownicy (np.: trzech z trzech) | ||
System posiada funkcję predefiniowania ścieżek akceptacji. Poprzez ścieżkę akceptacji należy rozumieć automatyczne wytypowanie kolejnych akceptujących wg schematu i automatyczne przekazywanie dokumentów pomiędzy akceptującymi użytkownikami. | ||
Użytkownik ma dokonujący zmiany w dokumencie ma możliwość zdecydowania czy zmiana powinna powodować utworzenie nowej wersji dokumentu. | ||
Dokumenty w systemie są wersjonowane w taki sposób, że modyfikacja metadanych, obrazu dokumentu, załączonych plików i formularzy może powodować powstanie nowej wersji dokumentu. | ||
FUNKCJONALNOŚCI MODUŁU OBSŁUGI SPRAW | ||
Sprawa – możliwość utworzenia dowolnej liczby spraw z jednego dokumentu. | ||
Każdy uprawniony użytkownik powinien posiadać możliwość tworzenia spraw z dokumentów. | ||
Możliwość utworzenia dodatkowej sprawy w ramach sprawy już istniejącej | ||
System posiada możliwość dołączania do spraw: • Dokumentów (odwzorowań cyfrowych) • Elementów w formie elektronicznej (w tym plików multimedialnych) • Notatek • Terminów z terminarza | ||
Sprawa posiada następujące możliwości: ▪ Połączenie z istniejącą sprawą ▪ Tworzenie spraw podrzędnych bądź nadrzędnych ▪ Dodanie bądź uzupełnienie metadanych ▪ Nadanie znaku sprawy zgodnie z JRWA ▪ Datę rozpoczęcia ▪ Datę planowanego zakończenia ▪ Datę zakończenia ▪ Uwagi | ||
Posiadanie możliwości wglądu do sprawy z poziomu dokumentu oraz wglądu do dokumentu z poziomu spraw | ||
System umożliwia prowadzącemu sprawę udzielenie dostępu do akt sprawy innym użytkownikom | ||
Nie ma konieczności przydzielania użytkownikom wszystkich akt sprawy, akta sprawy mogą być przydzielane innym użytkownikom wybiórczo. | ||
System umożliwia dostęp do tych samych informacji dowolnej/wyznaczonej grupie użytkowników bez pojawienia się konfliktów w jednym czasie. |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
Zapewnienie blokowania dostępu do sprawy/dokumentu użytkownikowi, któremu wcześniej przydzielono sprawę/dokument. | ||
Użytkownik prowadzący sprawę posiada uprawnienia nadawania znaku sprawy na każdym etapie prowadzonej sprawy, przy założeniu, w trakcie bądź przy zakończeniu sprawy. | ||
Użytkownik ma możliwość nadania/zmiany znaku sprawy zakończonej oraz możliwość zmiany numeru archiwalnego. | ||
System posiada możliwość blokowania znaku sprawy, który został już użyty. | ||
Użytkownik prowadzący sprawę powinien posiadać możliwość na każdym etapie prowadzonej sprawy modyfikacji metadanych. | ||
Możliwość przekazywania sprawy do prowadzenia jednemu użytkownikowi bądź wielu, z wyznaczeniem Prowadzącego sprawę bez utraty dostępu do sprawy. | ||
System powinien umożliwiać określenie cykliczności przypomnień realizacji sprawy poprzez definiowanie czasu przez użytkownika, gdzie system powiadamia o kończącym się terminie. | ||
System posiada funkcję umożliwiającą prowadzenie korespondencji seryjnej, względem podmiotów połączonych z dokumentem. | ||
System umożliwia automatycznie grupowanie elementów należących do sprawy rozdzielając takie elementy jak: dokumenty, pliki, notatki, formularze. Dodatkowo w widoku pogrupowanych elementów sprawy powinna istnieć możliwość zawężenia liczby widocznych elementów za pomocą filtrowania m. in. wg nazwy, kategorii, dat. | ||
System umożliwia przeglądanie historii zmian dotyczącej elementów z określeniem czasu i opisu zmian, informacja o osobach, które tych zmian dokonały, elementu, którego dotyczy zmiana oraz czynności, której dotyczy zmiana. Konieczne jest umożliwienie filtrowania historii zmian według następujących parametrów: • użytkownika, który wykonał operacje, • elementu, którego zmiana dotyczy (minimalnie 4 parametry dokument, sprawa, notatka, plik), • czynności (minimalnie trzy parametry modyfikacja, dodanie, usuniecie). System wyróżnia zmianę, która nastąpiła poprzez opisanie elementu, w którym ta zmiana nastąpiła np.: dodano użytkownika, zmieniono nazwę sprawy, itd. System posiada możliwość sortowania historii zmian względem daty wykonania operacji. System posiada możliwość eksportu historii zmian do sformatowanego pliku tekstowego, w którym dane oddzielone są separatorami. Historia zmian obejmuje co najmniej zdarzenia w: ▪ JRWA, ▪ sprawie, ▪ dokumencie, ▪ strukturze organizacyjnej, ▪ koncie użytkownika, ▪ bazie teleadresowej, ▪ zastępstwie, ▪ pliku dołączonym do systemu, ▪ notatce tekstowej dołączonej do systemu, ▪ rezerwacjach zasobów. | ||
System posiada przypisywanie formularzy do dokumentów wybranych kategorii, spraw wybranych kategorii, wybranych rejestrów dokumentów, wybranych rejestrów spraw. | ||
Użytkownik posiada dostęp do rejestrów zgodnie z nadanymi uprawnieniami. | ||
Użytkownik systemu powinien posiadać możliwość tworzenia spisów archiwalnych prowadzonych przez siebie spraw. | ||
Spis archiwalny jest generowany na podstawie znaku sprawy z oznaczeniem numeru JRWA z możliwością podziału na: ▪ Sprawy zakończone |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
▪ Sprawy w trakcie ▪ Sprawy archiwalne ▪ Sprawy zawieszone ▪ Sprawy usunięte | ||
Archiwizowanie spraw zakończonych | ||
Użytkownik posiadający podwładnych powinien mieć wgląd w sprawy oraz dokumenty przypisane do nich. Funkcja wyświetlana jest w widoku tabelarycznym (matrycy) poszczególnych użytkowników wraz z informacją ilościową o posiadanych sprawach: sumarycznie, przeterminowanych, załatwionych w terminie, załatwionych po terminie, oczekujących na załatwienie, anulowanych, zamkniętych; dokumentach odebranych, nieodebranych oraz o aktywnych procesach workflow, w których uczestniczy każdy użytkownik. Opisana informacja jest dostępna bez konieczności wchodzenia w profil poszczególnego użytkownika, ale poprzez widok tabelaryczny. | ||
Sortowanie spraw wg wprowadzonych danych np.: po liczbie dziennika, dacie wprowadzenia, opisie sprawy itp. | ||
FUNKCJONALNOŚCI MODUŁU FORMULARZY | ||
System posiada funkcje definiowania formularzy dynamicznych, które mogą być powiązane z wybranymi przez administratora kategoriami dokumentów, spraw, rejestrami. Formularze pojawiają się w momencie rejestracji lub edycji dokumentu, sprawy wybranej kategorii. Każdy formularz może się składać z dowolnej liczby atrybutów. System umożliwia w szczególności zdefiniowane następujących typów atrybutów: ▪ pole tekstowe; ▪ pole liczbowe; ▪ pole opisu (bez ograniczenia rozmiaru); ▪ pole wyboru (radio button); ▪ przycisk opcji (checkbox); ▪ pole kombi; ▪ pole listy; ▪ pole daty; ▪ pole pracownicy (użytkownicy systemu); ▪ pole adresaci (zarejestrowani w bazie kontakty). | ||
Formularze dynamiczne powinny stanowić integralną część metadanych dokumentu i dlatego metadane zapisane w formularzach powinny być wersjonowane wraz z pozostałymi metadanymi dokumentu. | ||
System powinien być wyposażony w mechanizm budowania definicji formularzy. | ||
Przygotowanie typowych formularzy musi być możliwe bez dodatkowej wiedzy z dziedziny programowania. | ||
Edytor formularzy musi umożliwiać zdefiniowanie i wykorzystanie walidacji poszczególnych pól formularza w szczególności zgodność ze wzorcem określonym wyrażeniem regularnym. | ||
System na etapie definiowania formularza musi zapewniać prezentowanie widoku formularza zgodnego z jego ostatecznym wyglądem tzw. WYSIWYG. | ||
Budowanie formularzy powinno odbywać się z wykorzystaniem mechanizmu przeciągnij i upuść dla umieszczania na nich poszczególnych elementów. | ||
Użytkownik może zdecydować o rozmieszczeniu elementów składowych formularza zarówno w pionie jak i w poziomie. | ||
Formularze muszą umożliwiać tworzenie zakładek tj. możliwość wyświetlenia na wielu kartach. | ||
Musi istnieć możliwość ponownego wykorzystania tego samego formularza w szczególności utworzenia nowego formularza na podstawie już istniejącego. | ||
Musi istnieć możliwość utworzenia, zapisania i późniejszego wykorzystania danej wersji formularza. |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
System posiada formularze do spraw jak również do dokumentów i rejestrów. | ||
System posiada funkcjonalność wiązania formularzy z szablonami dokumentów | ||
Możliwość edycji listy wartości pól formularzy typu lista rozwijana polegająca na możliwości dodawania kolejnych wartości lub blokowania użycia wartości wcześniej wprowadzonych. | ||
System posiada możliwość eksportu danych z formularzy do co najmniej jednego z formatów: pdf, xls, doc, rtf. | ||
FUNKCJONALNOŚCI MODUŁU OPERATORA | ||
Moduł aplikacji operatorskiej pozwala na zeskanowanie dokumentu a następnie wprowadzenie do systemu. | ||
Skanowane dokumenty pojawiają się na liście, która umożliwi grupowe wprowadzenie dokumentów do systemu, poprzez zaznaczenie na liście skanów dokumentów, pola typu np.: checkbox. Aplikacja umożliwia grupowe zaznaczenie wszystkich dokumentów np. klikając w nagłówek tabeli w kolumnie odpowiedzialnej za zaznaczanie dokumentów. | ||
Aplikacja operatorska lub integracja z aplikacją, która umożliwia dokonanie transformacji zeskanowanego obrazu co najmniej o następujące opcje: ▪ Obrót skanu (obrazu dokumentu) o / co 90 stopni w dowolną stronę ▪ Wybranie opcji pokazywania miniatur stron w przypadku skanu wielostronicowego ▪ Możliwość wyboru określonych stron ▪ Możliwość zamiany kolejności stron ▪ Możliwość usuwania stron | ||
Aplikacja operatorska lub integracja z aplikacją, która umożliwia zdefiniowanie następujących trybów skanowania: ▪ Wszystkich skanowanych dokumentów / stron jako jeden plik – jeden dokument, ▪ Wszystkich skanowanych dokumentów / stron jako oddzielne pliki – oddzielne dokumenty, ▪ Możliwość dodawania nowych stron do dokumentu ▪ Możliwość powiązań zeskanowanych już dokumentów ▪ Możliwość skanowania dokumentu jako jeden dokument, nawet w przypadku gdy podajnik skanera nie pozwala na wprowadzanie wszystkich kartek dokument za jednym razem (skanowanie ciągłe do jednego pliku). | ||
Możliwy automatyczny import zeskanowanych dokumentów. | ||
Okno rejestracji dokumentu wywołane z poziomu modułu skanowania masowego prezentuje zarówno widok zeskanowanego dokumentu jak i formularza metadanych. | ||
Istnieje skanowanie dwustronne. | ||
Inteligentne usuwanie pustych stron. | ||
Plik z edytowalną treścią rozpoznanego tekstu zostaje automatycznie dołączony do dokumentu. | ||
Skanowanie realizowane jest bezpośrednio z poziomu wbudowanego narzędzia zintegrowanego z systemem. | ||
Użytkownik pracujący w module operatora posiada możliwość opisania dokumentu metadanymi. | ||
System umożliwia zabezpieczanie rejestrowanych dokumentów wykorzystując mechanizm sum kontrolnych. | ||
System posiada możliwość rejestracji dokumentu w postaci samych metadanych, bez konieczności dołączania obrazu cyfrowego. | ||
Dokumenty rejestrowane w Systemie dzielą się na: ▪ dokumenty przychodzące, ▪ dokumenty wychodzące, ▪ dokumenty wewnętrzne, ▪ dokumenty wewnętrzne – robocze (Oznaczenie dokumentu jako roboczego oznacza, że nie zostanie on automatycznie przekazany odbiorcy, a po zmianie statusu dokumentu z roboczego na |
Lp. | Moduł oprogramowania | Wymagane funkcjonalności |
wewnętrzny odbiorca otrzyma wyłącznie zaakceptowaną wersję dokumentu) | ||
Możliwość przekazania dokumentów przychodzących oraz dokumentów wewnętrznych do dowolnej liczby użytkowników bez konieczności powielania. | ||
Generowanie z dokumentów wychodzących wykazów: ▪ Przesyłek poleconych ▪ Przesyłek poleconych za zwrotnym potwierdzeniem odbioru ▪ Przesyłek nadanych | ||
Eksportowanie do co najmniej jednego z formatów: PDF, XLS, DOC, RTF z możliwością wydruku względem wyboru wg Metadanych. | ||
Możliwość wyszukiwania po metadanych. | ||
Uzyskanie pełnej informacji o dokumencie np.: odbiorcy, powiązane sprawy, przypisanie do dziennika/spisu, znak sprawy. | ||
Możliwość sortowania wprowadzonych dokumentów do systemu wg składowych metadanych. | ||
Możliwość przesyłania dokumentów pomiędzy osobami pełniącymi rolę kancelarzystów bez utraty nadanego numeru dokumentu w systemie. | ||
System umożliwia śledzenie lokalizacji fizycznej oryginalnego dokumentu gdy jest on przekazywany wewnątrz jednostki. Mechanizm uwzględnia funkcję potwierdzenia odebrania oryginału przez osobę, której dokument przekazano. | ||
FUNKCJONALNOŚCI MODUŁU REJESTRY | ||
System definiuje wzorce rejestrów wraz z numeracją takie jak: a. Centralny rejestr dokumentów przychodzących b. Centralny rejestr dokumentów wychodzących. c. Centralny rejestr dokumentów wewnętrznych Budowane automatycznie spisy spraw dla każdej grupy spraw (JRWA) w każdej komórce organizacyjnej. | ||
System posiada funkcjonalność nadawania uprawnień do rejestrów z podziałem: ▪ Uprawnienie dodawania/edycji ▪ Uprawnienie podglądu | ||
Uprawnienie edycji i podglądu rejestru skutkuje też udzieleniem tych samych uprawnień do dokumentów znajdujących się w tych rejestrach. | ||
System posiada mechanizm definiowania formularzy do rejestrów. | ||
System zawiera funkcjonalność eksportu danych do plików w co najmniej jednym z formatów: xls, doc, pdf oraz wydruku. System zawiera możliwość ograniczenia zakresu eksportowanych danych na podstawie daty wszczęcia/zakończenia sprawy. | ||
Wyszukiwanie zaawansowane za pomocą gromadzonych danych w rejestrach. Po wyświetleniu wyniku wyszukiwania system posiada funkcję eksportu danych do plików w co najmniej jednym z formatów: xls, doc, pdf w celu opracowania oraz wydruku. | ||
Wyświetlanie spisów w oddzielnych folderach z podziałem na poszczególne lata. | ||
FUNKCJONALNOŚCI MODUŁU ASYSTENTA DNIA | ||
System posiada moduł asystenta dnia prezentujący użytkownikom listę elementów, które zostały im przydzielone do realizacji. | ||
Elementy są wyróżnione w sposób umożliwiający natychmiastową identyfikację i natychmiastowe wykonanie operacji, celem której element został do użytkownika przydzielony oraz natychmiastowe zapoznanie się z treścią dokumentu. | ||
Elementy posiadają możliwość filtrowania wg kryteriów co najmniej nazwy, terminu realizacji, oraz sortowania wg priorytetu realizacji. | ||
Użytkownik posiada możliwość samodzielnego definiowania szczegółowej listy wcześniej przydzielonych mu elementów do realizacji poprzez dokonanie wyboru elementów i zdefiniowanie ich kolejności. | ||
System umożliwia automatyczne usunięcie elementu z listy do realizacji po tym jak użytkownik daną operację wykonał. |