uczkin.pluczkin.pl/storage/files/zamówienia/Informatyka UE/SIWZ-Załącznik nr... · Web viewLp....

Załącznik nr 6 do SIWZ

Uniwersyteckie Centrum Zdrowia Kobiety i Noworodka Warszawskiego Uniwersytetu Medycznego Sp. z o.o.

Pl. S. Starynkiewicza 1/302-015 Warszawa

Opis Przedmiotu ZamówieniaPoprawa jakości i dostępności do świadczeń z zakresu położnictwa

i neonatologii w Uniwersyteckim Centrum Zdrowia Kobiety i Noworodka Warszawskiego Uniwersytetu Medycznego

Modernizacja systemu informatycznego z rozbudową o nowe funkcjonalności

SPIS TREŚCII. Stan obecny............................................................................................................................2

II. Przedmiot zamówienia...........................................................................................................3

III. Aktualizacja i rozbudowa systemu HIS................................................................................4

IV. Wymagania funkcjonalne nowej wersji systemu................................................................5

V. Rozbudowa systemu HIS.......................................................................................................61

VI. Integracja oprogramowania z systemem administracyjnym ERP......................................69

VII. Dostawa systemu diagnostyki obrazowej PACS................................................................71

VIII. Oprogramowanie bazodanowe........................................................................................88

IX. Integracja z PACS..............................................................................................................92

X. Integracja z systemem laboratoryjnym.................................................................................94

XI. System długopisu elektronicznego wraz z integracją........................................................96

XII. Szkolenia e-Learning.......................................................................................................102

XIII. Migracja danych.............................................................................................................104

XIV. Infrastruktura sprzętowa................................................................................................105

XV. Sieć teleinformatyczna – zabezpieczenia sieciowe.........................................................121

XVI. Prezentacja systemu.......................................................................................................137

XVII. Wdrożenie i szkolenia.....................................................................................................140

1UCZKIN/ZP -02/01/2019/PNO/EU –SIWZ na dostawę wraz z instalacją, wdrożeniem i uruchomieniem kompletnej aplikacji HIS (RIS, PACS, EDM HL7) oraz dostawą niezbędnego wyposażenia i rozbudowaniem istniejącej sieci teleinformatycznej w ramach realizowanego Projektu pn. „Poprawa jakości i dostępności do świadczeń z zakresu położnictwa i neonatologii w Uniwersyteckim Centrum Zdrowia Kobiety i Noworodka Warszawskiego Uniwersytetu Medycznego” nr POIS.09.02.00-00-0060/17


I. Stan obecnySystem HISW chwili obecnej Szpital użytkuje system InfoMedica wersja 4.50 produkcji firmy Asseco Poland SA. Zakres systemu jest opisany w Tabeli nr 1. Jednakże w celu implementacji Elektronicznej Dokumentacji Medycznej konieczna jest aktualizacja systemu do najnowszej dostępnej wersji. Docelowy (wymagany) funkcjonalny zakres systemu HIS został opisany w Tabeli nr 3.

Tabela nr 1 – Posiadane licencje systemu HIS

1. Moduł LIczba Licencji

Ruch chorych (Izba przyjęć, Oddział, Rozliczenia z NFZ, Statystyka) 25Apteka 4Apteczka oddziałowa 10Gabinet lekarski 7Recepcja/Rejestracja 3Sprzedaż usług medycznych OpenZlecenia 25Blok operacyjny 2Punkt Pobrań 10Symulator JGP Open

System ERPJako system ERP Zamawiający wykorzystuje system InfoMedica w wersji 4.50.0.0 produkcji firmy Asseco Poland SA . Zakres systemu jest opisany w Tabeli nr 2. Zamawiający wymaga integracji systemu HIS z systemem ERP.

Tabela nr 2 – Posiadane licencje systemu ERP

Moduł Liczba Licencji

Finanse – Księgowość 3Koszty 1Rejestr Sprzedaży 2Środki trwałe 1Gospodarka materiałowa 1Kadry 3Płace 3Kasa 1Wyposażenie 1Rejestr Zakupów 1Grafiki 11



II. Przedmiot zamówienia

Przedmiot zamówienia obejmuje:

1. Dostawę i uruchomienie najnowszych modułów oprogramowania aplikacyjnego w części w podziale na moduły opisane w Tabeli nr 3.

2. Zakres funkcjonalny poszczególnych modułów został opisany w pkt III niniejszego załącznika.3. Rozbudowę systemu HIS o moduły opisane w pkt III niniejszego załącznika4. Zakres funkcjonalny poszczególnych modułów został opisany w pkt IV niniejszego załącznika5. Udzielenie bezterminowej licencji na sieciowe użytkowanie zaoferowanego oprogramowania

aplikacyjnego wraz z gwarancją i nadzorem autorskim 6. Integrację oferowanego oprogramowania z systemem administracyjnym ERP posiadanym

przez Zamawiającego. Zakres integracji opisano w pkt VI7. Dostawa systemu diagnostyki obrazowej (PACS) wraz z jego integracją z rozbudowywanym

systemem HIS. Zakres integracji opisano w pkt. VII8. Integrację oferowanego oprogramowania HIS z systemem laboratoryjnym firmy ALAB. Zakres

integracji opisano w pkt. VIII9. Zakup i dostawę oprogramowania bazodanowego

10. Zakres funkcjonalny został opisany w pkt V niniejszego załącznika11. Przeprowadzenie szkoleń e-learningowych dla użytkowników. Zakres i zasady szkoleń

opisano w pkt X.12. Zakupi i dostawę infrastruktury sprzętowej w zakresie opisanym w pkt. XIV13. Objęcie gwarancyjnym nadzorem autorskim całego systemu w części medycznej przez okres

minimum 24 miesięcy.



III. Aktualizacja i rozbudowa systemu HIS

W ramach aktualizacji do najnowszej wersji systemu, Wykonawca będzie zobowiązany do implementacji systemu w nie niższym zakresie niż:

TAB. III.A. Moduły do aktualizacji posiadanego systemu HISŁączna liczba

licencji po aktualizacji

Ruch Chorych (Izba przyjęć, Oddział, Rozliczenia z NFZ, Statystyka) 45Apteka 4Apteczka oddziałowa 10Gabinet lekarski 13Recepcja/Rejestracja 4Sprzedaż Usług Medycznych OpenZlecenia 50Blok operacyjny 5Punkt Pobrań 10Symulator JGP OpenAdministrator 3Elektroniczna Dokumentacja Medyczna Open

TAB.III.B. Moduły do rozbudowy systemu HIS Liczba licencji

Dokumentacja Formularzowa OpenZakażenia Szpitalne 1Pracownia Diagnostyczna 6Recepcja/Rejestracja 1Gabinet zabiegowy 2Integracja z systemem diagnostyki obrazowej 1Badania Kliniczne 1Transport sanitarny 1Badanie krwi 1Kalkulacja Kosztów Leczenia 2e-Portal Pacjenta OpenOprogramowanie bazodanowe 2

a) Zamawiający wymaga dostarczenia licencji bezterminowych na każdy z elementów

oferowanego systemu informatycznego, tzn. wszystkie funkcjonalności systemu informatycznego muszą być dostępne przez cały okres użytkowania systemu przez Zamawiającego, także w przypadku wygaśnięcia umów gwarancyjnych i serwisowych.

b) Przez pojęcie „Open” Zamawiający rozumie licencję bezterminową na nieograniczoną liczbę użytkowników i stanowisk komputerowych.



c) Wskazana wartość jako liczba licencji określa liczbę jednocześnie korzystających użytkowników z danego modułu funkcjonalnego. Zamawiający wymaga, aby dostarczony system informatyczny objęty był licencją na użytkownika „licencja pływająca” w liczbie licencji na poszczególne moduły, określonej w tabeli powyżej.



IV. Wymagania funkcjonalne nowej wersji systemu A.

Lp. TAB. IV.A. Wymagania prawne Spełnianie (TAK/NIE)

1. Oferowane oprogramowanie jest zgodne z aktualnymi aktami prawnymi regulującymi organizację i działalność sektora usług medycznych i opieki zdrowotnej, w tym:

2.ROZPORZĄDZENIE PARLAMENTU EUROPEJSKIEGO I RADY (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne rozporządzenie o ochronie danych)

3. Ustawa z dnia 17 lutego 2005 o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U z 2017 poz 570 tj.)

4.

Rozporządzenie Ministra Zdrowia z dnia 20 czerwca 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 (Dz.U.2016. 192 t.j.)

5. Rozporządzenie Ministra Zdrowia z dnia 9 listopada 2015 r. w sprawie rodzajów, zakresu i wzorów dokumentacji medycznej oraz sposobu jej przetwarzania (Dz.U. 2015 poz. 2069)

6. Ustawa z dnia 10 maja 2018 r. o ochronie danych osobowych

7. Zarządzenie Prezesa NFZ w sprawie określania warunków zawierania i realizacji umów w rodzaju rehabilitacja lecznicza

8. Zarządzenie Prezesa NFZ w sprawie określenia szczegółowych komunikatów sprawozdawczych XML dotyczących świadczeń ambulatoryjnych i szpitalnych. (ze zmianami publikowanymi w komunikatach Centrali NFZ)

9. Zarządzenie Prezesa NFZ zmieniające zarządzenie w sprawie określenia szczegółowych komunikatów sprawozdawczych XML dotyczących danych zbiorczych o świadczeniach udzielonych w ramach POZ

10. Zarządzenie Prezesa NFZ w sprawie warunków zawarcia i realizacji umów o udzielanie świadczeń opieki zdrowotnej w zakresie podstawowej opieki zdrowotnej

11. Zarządzenie Prezesa NFZ w sprawie określenia warunków zawierania i realizacji umów w rodzaju leczenie szpitalne w zakresie chemioterapia

12. Zarządzenie Prezesa NFZ w sprawie określenia warunków zawierania i realizacji umów w rodzaju leczenie szpitalne w zakresie terapeutyczne programy zdrowotne

B.

Lp. TAB. IV.B. Wymagania ogólne – techniczne Spełnianie (TAK/NIE)

1. Architektura i interfejs użytkownika




2. System działa w architekturze trójwarstwowej

3. System ma interfejs graficzny dla wszystkich modułów

4. System pracuje w środowisku graficznym MS Windows na stanowiskach użytkowników (preferowane środowisko MS Windows 7/8/10)

5.System komunikuje się z użytkownikiem w języku polskim. Jest wyposażony w system podpowiedzi (help). W przypadku oprogramowania narzędziowego i administracyjnego serwera bazy danych dopuszczalna jest częściowa komunikacja w języku angielskim

6. System umożliwia pracę w innych wersjach językowych. Powinna istnieć co najmniej wersja anglojęzyczna systemu obejmująca nazwy okien i etykiety pól

7. Podczas uruchamiania systemu, użytkownik musi mieć możliwość wybrania wersji językowej

8. Powinna istnieć możliwość przypisania użytkownikowi lub grupie użytkowników domyślnej wersji językowej, tak aby dla tego użytkownika system uruchamiał się we właściwym dla niego języku

9. System posiada mechanizm informujący użytkowników o zmianach i nowościach w aplikacjach.

10. System powinien umożliwiać zapamiętanie zdefiniowanych kryteriów wyszukiwania z dokładnością dla jednostki i użytkownika

11.

Interfejs użytkownika jest dostępny z poziomu przeglądarki internetowej i nie wymaga instalowania żadnego oprogramowania na stacjach klienckich. Na dzień złożenia musi być dostęp do aplikacji przez WWW, co najmniej, w zakresie obsługi izby przyjęć, oddziału i zleceń, rejestracji gabinetu lekarskiego pracowni diagnostycznej, apteki i apteczek oddziałowych, rozliczeń z NFZ wraz z gruperem JGP.

12. System musi umożliwić pracę z poziomu najbardziej popularnych przeglądarek, co najmniej MS Internet Explorer, Mozilla Firefox, Google Chrome.

13. System w części medycznej musi umożliwić pracę na tabletach medycznych w zakresie aplikacji mobilnej.

14. System umożliwia zdefiniowanie skrótu umożliwiając bezpośrednie uruchomienie danego modułu z domyślną jednostką.

15. Baza danych

16. Wszystkie moduły systemu HIS działają w oparciu o jeden motor bazy danych

17.

System, co najmniej, w zakresie aplikacji RCH, apteki centralnej, apteczki oddziałowej, lecznictwa otwartego i rozliczeń NFZ powinien pracować w oparciu o tę samą bazę danych, przez co należy rozumieć tę samą instancję bazy danych, te same tabele. Niedopuszczalne jest przekazywanie i dublowanie danych w zakresie w/w systemów.

18. System zapewnia odporność struktur danych (baz danych) na uszkodzenia oraz pozwala na szybkie odtworzenie ich zawartości i właściwego stanu, jak również posiada łatwość wykonania ich kopii bieżących oraz łatwość odtwarzania z kopii.




System jest wyposażony w zabezpieczenia przed nieautoryzowanym dostępem. Zabezpieczenia funkcjonują na poziomie klienta (aplikacja) i serwera (serwer baz danych).

19. System jest wykonany w technologii klient-serwer, dane są przechowywane w modelu relacyjnym baz danych z wykorzystaniem aktywnego serwera baz danych.

20. Udogodnienia interfejsu użytkownika

21. W funkcjach związanych z wprowadzaniem danych system udostępnia podpowiedzi, automatyczne wypełnianie pól, słowniki grup danych (katalogi leków, procedur medycznych, danych osobowych, terytorialnych).

22. Ręczne i automatyczne, na podstawie częstotliwości użycia, wyróżnienie w słownika pozycji najczęściej używanych

23. System umożliwia włączenie szybkiego wyszukiwania w polach słownikowych bez konieczności otwarcia okna dla poszczególnych słowników

24. Kontrola/parametryzacja Wielkich/małych liter. Możliwość ustawienia w wybranych polach jak ma być sformatowany wpis

25. System musi umożliwić zmianę jednostki organizacyjnej na której pracuje użytkownik bez konieczności wylogowywania się z systemu

26. Wyróżnienie pól:

27. - których wypełnienie jest wymagane,

28. - przeznaczonych do edycji,

29. - wypełnionych niepoprawnie

30. System powinien umożliwiać wyłączanie niewykorzystanych elementów menu czy zakładek

31. System powinien umożliwiać zmianę kolejności prezentacji elementów menu czy zakładek

32. System umożliwia zmianę wielkości okien słownikowych i ich zapamiętanie w kontekście użytkownika.

33. System musi umożliwić skanowanie danych z dokumentów tożsamości - dowodów osobistych lub prawo jazdy i na tej podstawie dokonywanie identyfikacji pacjenta

34. System musi umożliwiać obsługę kodów 2D do rejestracji skierowań pochodzących z innych zakładów opieki

35.

System umożliwia wykonanie nowej operacji w systemie bez konieczności przerywania czynności dotychczas wykonywanej (np. obsługa zdarzenie w trybie nagłym) i powrót do zawieszonej czynności bez utraty danych, kontekstu itp. Bez konieczności ponownego uruchamiania aplikacji i wykorzystania licencji z puli dostępnych.

36. Wszystkie błędy niewypełnienie pól obligatoryjnych oraz błędnego wypełnienia powinny być prezentowane w jednym komunikacie z możliwością szybkiego przejścia do miejsca aplikacji, gdzie te błędy wystąpiły.




37. System powinien umożliwić obsługę procesów biznesowych realizowanych w szpitalu tzn. powinien:

38. - pokazywać tylko to, co w danym momencie jest najważniejsze,

39. - udostępniać tylko te zadania, które na danym etapie powinny zostać wykonane,

40. - umożliwić wprowadzenie tylko tych danych, które są niezbędne,

41. - podpowiadać kolejne kroki procesu.

42.

W każdym polu edycyjnym(opisowym) tj. np. treść wywiadu powinna istnieć możliwość wybrania i skorzystania z dowolnego formularza, tekstu standardowego lub wczytania tekstu zapisanego w pliku zewnętrznym. Powinna również w tych miejscach istnieć możliwość zapisu do zewnętrznego pliku przygotowanego tekstu oraz powinny być udostępnione podstawowe narzędzia ułatwiające edycję np. kopiuj/wklej, możliwość wstawiania znaków specjalnych

43. System musi umożliwiać autoryzację danych za pomocą podpisu cyfrowego tj.:-cerytfikatu kwalifikowanego/niekwalifikowanego w chmurze -certyfikatu na zewnętrznym nośniku danych

44.

Podczas autoryzacji danych podpisem tworzony jest dokument zawierający szczegółowe dane tj:-datę złożenia podpisu-dane użytkownika systemu uruchamiającego opcję podpisu-informację o zakresie autoryzowanych danych - przyczynę modyfikacji danych- skrót autoryzowanych danych

45. System powinien umożliwiać sprawdzanie poprawności pisowni w polach opisowych tj. opis badania, wynik, epikryza

46. System musi umożliwiać drukowanie kodów jedno i dwuwymiarowych na opaskach dla pacjentów

47. System musi umożliwiać przeglądanie historii choroby, wyników badań, dokumentacji, zleceń na jednym ekranie z jednego i wielu pobytów. System musi umożliwiać porównywanie tych danych.

48. System musi umożliwić wyświetlenie miniatury zdjęcia pacjenta w nagłówku z podstawowymi danymi pacjenta na ekranach prezentujących dane wizyty/ pobytu.

49. System musi umożliwiać definiowanie tagów globalnych i prywatnych.

50. System umożliwia użycie tagów w specyficznych miejscach systemu.

51. System musi umożliwić definiowanie skrótów akcji użytkownika.

52. Definicja skrótów akcji użytkownika musi umożliwiać określenie:- kategorii skrótu- czy jest publiczny




- czy jest aktywny- dla jakich jednostek/ról jest dostępny- skrótu klawiszowego dla danego skrótu akcji

53. System musi umożliwiać wykorzystanie zdefiniowanych skrótów akcji użytkownika w specyficznych miejscach systemu.

54. System umożliwia zdefiniowanie nazwy przycisku pod którym będzie wykonywana akcja użytkownika.

55. Bezpieczeństwo

56. System musi być wyposażony w zabezpieczenia przed nieautoryzowanym dostępem. Zabezpieczenia muszą funkcjonować na poziomie klienta (aplikacja) i serwera (serwer baz danych),

57. System musi umożliwić logowanie z wykorzystaniem usług domenowych np. Active Directory (AD), w ramach, których możliwe jest logowanie z wykorzystaniem czytnika biometrycznego oraz kart kryptograficznych.

58. System umożliwia automatyczne tworzenie użytkowników systemu, na podstawie użytkowników w Active Directory (AD).

59.Użytkownik nie może zmienić hasła AD z poziomu SSI

60. Konfiguracja musi uwzględniać model bez SSO, co oznacza możliwość logowania się do SSI na koncie dowolnego użytkownika, niezależnie od zalogowanego do Systemu Operacyjnego użytkownika.

61. System musi tworzyć i utrzymywać log systemu, rejestrujący wszystkich użytkowników systemu i wykonane przez nich najważniejsze czynności z możliwością analizy historii zmienianych wartości danych.

62. W przypadku przechowywania haseł w bazie danych, hasła muszą być zapamiętane w postaci niejawnej (zaszyfrowanej).

63.Dane powinny być chronione przed niepowołanym dostępem przy pomocy mechanizmu uprawnień użytkowników. Każdy użytkownik systemu powinien mieć odrębny login i hasło. Jakakolwiek funkcjonalność systemu (niezależnie od ilości modułów) będzie dostępna dla użytkownika dopiero po jego zalogowaniu.

64. System powinien wylogowywać lub blokować sesję użytkownika po zadanym czasie braku aktywności

65. System powinien wyświetlać czas pozostały do wylogowania (zablokowania) użytkownika

66. Użytkownik po zalogowaniu powinien widzieć pulpit zawierający wszystkie funkcje i moduły dostępne dla tego użytkownika

67. W systemie musi zostać zachowana zasada jednokrotnego wprowadzania danych. Wymiana danych pomiędzy modułami musi odbywać się na poziomie bazy danych

68. System musi umożliwić samodzielne odzyskiwanie hasła przez użytkownika realizowane za pomocą wysłania wiadomości e-mail/sms.

69. Komunikacja z pacjentem

70. System powinien umożliwiać wysyłanie indywidualnych i grupowych SMS do




pacjentów71. System musi umożliwić wysłanie do pacjenta wiadomości potwierdzającej

zakończenie pobytu na oddziale.72. System powinien umożliwiać wysyłanie e-mail do pacjentów

73. System musi umożliwić wysyłanie do użytkownika wiadomości e-mail/sms dla zdefiniowanych zdarzeń np. zlecenia wysłanego, zleceniu badania, przyjęcia na oddział.

74. System musi umożliwiać zdefiniowanie wysyłania zdarzeń do opiekunów dla pobytów pacjenta, w ramach którego wyrażono zgodę na powiadomienia.

75. System umożliwia definiowanie preferowanego kanału komunikacji (sms,e-mail) dla opiekuna.

76. W przypadku zmiany terminu system musi umożliwić zatwierdzenie nowego terminu za pomocą odpowiedniego linku wysyłanego w wiadomości e-mail.

77. System musi umożliwiać ręczne wysyłanie wiadomości sms lub e-mail do grupy pacjentów. Wysyłanie może nastąpić poprzez sms, e-mail lub według preferowanego kanału dla pacjenta.

78. Komunikator

79. System powinien zawierać komunikator umożliwiający wymianę wiadomości pomiędzy użytkownikami.

80. Komunikator musi umożliwić wysłanie wiadomości do:

81. - pracowników jednostki organizacyjnej

82. - użytkowników pełniących określoną funkcję (lekarze, pielęgniarki)

83. - użytkowników wskazanego modułu

84. - możliwość łączenia w/w grup adresatów np. wszystkie pielęgniarki z oddziału chorób wewnętrznych pracujące w module Apteczka

85. Musi istnieć możliwość nadania wiadomości statusu: zwykła, ważna, wymagająca potwierdzenia

86. System powinien umożliwić definiowanie wiadomości, których wysłanie jest inicjowane zdarzeniem np. zlecenie leku, badania, wynik badania, zamówienie na lek do apteki, przeterminowane podania.

87. Wiadomości mogą być wysyłane przez użytkowników systemu

88. System musi umożliwiać grupowe wysyłanie wiadomości sms lub e-mail do presonelu. Musi istnieć możliwość przeglądu wiadomości wysłanych do personelu.

89. Wiadomości powinny mieć określony termin obowiązywania podawany z dokładnością do godziny

90. System powinien zapewniać mechanizm powiadomień generowanych automatycznie w związku ze śledzeniem stanu realizacji zleceń, wyników badań,




zamówień do apteki.91. System powinien informować o przewidywanym niedoborze leków w apteczce

jednostki organizacyjnej92. System musi umożliwić uruchomienie dla zalogowanego użytkownika,

bezpośrednio z poziomu aplikacji, komunikatora (np. Skype for Business).93. System musi zapewnić możliwość przypisania identyfikatora komunikatora

(np.Skype for Business) do użytkownika.

94.System musi umożliwić rozpoczęcie konwersacji (tekstowej, audio/wideo) z wykorzystaniem komunikatora (np. Skype for Business) z innym użytkownikiem bezpośrednio z różnych miejsc systemu, bez konieczności przerywania czynności dotychczas wykonywanych.

95. System musi umożliwić prowadzenie wielu niezależnych konwersacji tekstowych za pomocą komunikatora (np. Skype for Business).

96. System musi umożliwić wyszukiwanie użytkowników w katalogu organizacji, w przypadku gdy użytkownik z którym ma być nawiązana konwersacja za pomocą komunikatora (np. Skype for Business) nie znajduje się na liście kontaktowej.

C. Licencje i funkcjonalności część biała

Lp. TAB. IV.C. Izba PrzyjęćSpełnianie (TAK/NIE)

1. System musi umożliwić obsługę skorowidza pacjentów, wspólnego dla innych modułów medycznych tj.: Przychodnia, Pracownia Diagnostyczna, Oddział

2. System musi umożliwiać wyszukiwanie pacjentów w skorowidzu wg różnych parametrów:

3. - status eWUŚ

4. - nazwisko, imię i nr PESEL

5. - identyfikator pacjenta w systemie informatycznym

6. - rok pobytu

7. - nr w księdze

8. - rozpoznanie

9. - lekarz badający

10. - pacjenci leczeni we wskazanym roku

11. System umożliwia rejestrację i modyfikację danych pacjentów

12. System umożliwia rejestrację pacjenta z Unii Europejskiej,

13. System umożliwia rejestrację pacjenta przyjmowanego decyzją wójta/burmistrza12

UCZKIN/ZP -02/01/2019/PNO/EU –SIWZ na dostawę wraz z instalacją, wdrożeniem i uruchomieniem kompletnej aplikacji HIS (RIS, PACS, EDM HL7) oraz dostawą niezbędnego wyposażenia i rozbudowaniem istniejącej sieci teleinformatycznej w ramach realizowanego Projektu pn. „Poprawa jakości i dostępności do świadczeń z zakresu położnictwa i neonatologii w Uniwersyteckim Centrum Zdrowia Kobiety i Noworodka Warszawskiego Uniwersytetu Medycznego” nr POIS.09.02.00-00-0060/17



14.System musi przechowywać historię zmian danych osobowych pacjenta. Wgląd w dane medyczne sprzed zmiany danych osobowych powinno umożliwić przeglądanie I wydruk dokumentacji z danymi pacjenta aktualnymi na dzień tworzenia tej dokumentacji

15. Podczas wprowadzania danych pacjenta system musi kontrolować ich poprawność, co najmniej w zakresie:

16. - poprawności wprowadzonego nr PESEL oraz zależności PESEL z płcią i data urodzenia pacjenta

17. - poprawności numeru dokumentu tożsamości (co najmniej dla dowodu osobistego i prawa jazdy)

18. System musi umożliwić wprowadzenie daty uzyskania pełnoletniości dla pacjentów, którzy nie ukończyli 18 roku życia

19. Z poziomu danych pacjenta NN musi istnieć możliwość powiązania rekordu pacjenta NN z rekordem pacjenta zarejestrowanego w systemie

20. System musi umożliwiać ewidencję pacjentów ze szczególnymi uprawnieniami, których dane są objęte ograniczonym dostępem.

21. System musi umożliwić ograniczenie widoczności danych wrażliwych za pomocą uprawnień.

22. System musi umożliwiać przegląd danych archiwalnych pacjenta:

23. - w zakresie danych osobowych,

24. - w zakresie danych z poszczególnych pobytów szpitalnych

25. System musi umożliwić dodanie zdjęcia pacjenta w danych podstawowych.

26. System musi umożliwić ustawienie w zdjęcie pacjenta:

27. -z pliku graficznego

28. - zeskanowanego

29. - wykonanego podczas przyjęcia pacjenta

30. Rejestracja pacjenta w Izbie Przyjęć

31. System musi umożliwić pacjenta przyjęcie w trybie nagłym oraz planowym

32. Dla przyjęć w trybie nagłym, system musi oznaczać pobyt jako "zagrożenie życia lub zdrowia"

33. Podczas przyjmowania pacjenta skierowanego z gabinetu lekarskiego, działającego w strukturach jednostki, system powinien informować, że pacjent taki oczekuje na przyjęcie

34. System musi umożliwiać rejestrację rozpoznań: wstępnego, towarzyszących i 13




rozpoznania końcowego35. Wprowadzenie danych o rozpoznaniu musi odbywać się z wykorzystaniem

słownika ICD1036. System powinien umożliwiać kopiowanie rozpoznań z: poprzedniej jednostki,

poprzedniej hospitalizacji, poprzedniego pobytu w Izbie Przyjęć.37. System musi umożliwiać:

38. - wprowadzenie danych ze skierowania,

39. - wprowadzenie danych płatnika

40. - wpisanie wywiadu wstępnego z możliwością użycia słownika tekstów standardowych lub dedykowanego formularza

41. - wpisanie wywiadu przedporodowego

42. System musi umożliwić odnotowanie wykonanych elementów leczenia tj.:

43. - procedury,

44. - podane leki,

45. - konsultacje.

46.Podczas uzupełniania danych wywiadu lub badania wstępnego, system musi umożliwić wykorzystanie informacji uzupełnionych wcześniej tj.: wywiad wstępny, rozpoznanie wstępne lub rozpoznanie ze skierowania, badanie fizykalne wstępne

47. System powinien umożliwiać wprowadzenie informacji o dokumentach uprawniających do uzyskania świadczeń

48. System powinien umożliwiać śledzenie historii dokumentów uprawniających do uzyskania świadczeń.

49. System powinien umożliwić rejestrację informacji o wymaganym transporcie medycznym pacjenta

50. System powinien umożliwić rejestrację informacji o planowanym czasie hospitalizacji

51. System musi posiadać możliwość ewidencji usług rozliczanych komercyjnie

52. Zakończenie pobytu w Izbie Przyjęć

53. Rejestracja opuszczenia Izby Przyjęć przez pacjenta powinna umożliwiać wybór jednego z trybów:

54. - skierowanie na oddział,

55. - przeniesienie pacjenta na inną izbę przyjęć,




56. - odmowa przyjęcia pacjenta do szpitala, skutkująca wpisem do Księgi Odmów i Porad Ambulatoryjnych,

57. - zaplanowanie późniejszego terminu przyjęcia, skutkująca wpisem do Księgi Oczekujących,

58. - zgon pacjenta na Izbie Przyjęć, skutkujący wpisem do Księgi Zgonów.

59. System musi umożliwiać cofnięcie skierowania na oddział lub inną izbę przyjęć

60. Po zatwierdzeniu skierowania pacjenta do oddziału system drukuje opaskę z kodem kreskowym identyfikującym pacjenta

61. System umożliwia drukowanie wielu etykiet opatrzonym identyfikatorem pacjenta np. w postaci kodu paskowego

62. Podczas kierowania pacjenta na oddział, system podpowiada planowaną liczbą dni pobytu

63. System musi umożliwić autoryzację danych Izby Przyjęć,

64. System musi umożliwić ewidencję danych do rozliczenia produktów kontraktowanych z NFZ

65. Tworzenie dokumentacji Izby Przyjęć

66. System musi umożliwiać tworzenie i wydruk dokumentacji indywidualnej pacjentów izby przyjęć: tj.

67. - Karta Wypisowa,

68. - Historia choroby

69. - Karta Odmowy.

70. System musi umożliwiać obsługę dokumentacji zbiorczej tj.:

71. - Księga Główna,

72. - Księgi Izby Przyjęć,

73. - Księga Oczekujących,

74. - Księga odmów i Porad Ambulatoryjnych,

75. - Księga Zabiegów,

76. - Księga Badań,

77. - Księga Depozytów,

78. - Księga Zgonów,15




79. - Księga Ratownictwa

80. - karta gorączkowa

81. - karta zleceń lekarskich

82. - informacje i formularze świadomej zgody na zabiegi położnicze i ginekologiczne

83. - karta obserwacji wkłuć

84. - karta zapobiegania zakażeniom miejsca operowanego

85. - karta oceny ryzyka wystąpienia zakażenia/kolonizacji

86. - oświadczenie Pacjentki o szczepieniu przeciwko wzw B

87. - komplet dokumentów dotyczących ekspozycji zawodowej na zakażenie

88. - karta depozytowa

89. - ankieta badania anestezjologicznego

90. - formularz zgody na znieczulenie

91. - druk zaświadczenia lekarskiego

92. - druk skierowania na konsultację

93. - zgoda pacjentki na podanie leku w trybie ambulatoryjnym (misoprostol)

94. - ankieta psychologiczna dla pacjentki

95. Oświadczenie pacjentki w sprawie wykonania badań genetycznych poronionego płodu

96. Zlecenie na transport sanitarny

97. System musi umożliwić podpowiadanie dat w danych pozycji Księgi Ratownictwa.

98. System musi posiadać wbudowane raporty standardowe:

99. - Ruch chorych Izby Przyjęć – osobowy,

100. - Ruch chorych Izby Przyjęć – sumaryczny.




101. - liczba pacjentów powracających do szpitala w podanym okresie.

102. Musi istnieć możliwość definiowania własnych wykazów w oparciu o zgromadzone w systemie dane

103. System musi umożliwiać projektowanie własnych formularzy dokumentacji medycznej,

104. System musi zapewniać integrację z innymi modułami systemu medycznego realizującymi funkcjonalność w zakresie:

105. Integracja z innymi elementami systemu

106. - ewidencji zużytych leków i materiałów oraz aktualizacji stanów magazynowych (Apteczka oddziałowa)

107. - wzajemnego udostępniania danych zleceń i danych o ich wykonaniu,

D.

Lp. TAB. IV.D. Oddział Spełnianie (TAK/NIE)

1. Pulpit główny modułu powinien zawierać podstawowe informacje liczbowe informujące o liczbie aktualnie przebywających w oddziale pacjentach, o liczbie pacjentów wypisywanych, do przyjęcia, liczbie zleceń do obsłużenia

2. System musi umożliwić prezentację na głównym pulpicie modułu informacji o liczbie pacjentów przebywających na przepustkach.

3. Obsługa rejestru pacjentów

4. System musi umożliwiać wyszukiwanie pacjentów na liście wg różnych parametrów, w tym:

5. - stan pacjenta

6. - status pacjenta ( przysłany z IP, przebywający na oddziale, skierowany do innej jednostki, na przepustce, uciekinier)

7. - status eWUŚ

8. - identyfikator pacjenta

9. - lekarz prowadzący

10. - nazwisko i imię

11. - nr księgi głównej

12. - rozpoznanie

13. - płatnik

14. - nr kartoteki i karty pacjenta17




15. - zlecenia modyfikowane w ciągu ostatnich X godzin

16. - z aktualnymi zleceniami leków

17. - obsługiwani w innych jednostkach

18. - z przepustkami do zatwierdzenia

19. - zlecenia leków do potwierdzenia

20. - obsługiwani w trybie IOM

21. - bez opisu historii choroby

22. - daty urodzenia

23. - wyszukanie pacjenta z wykorzystaniem kodu paskowego z opaski

24. - osoby poniżej określonego wieku (roku życia)

25. - wymagające zafakturowania

26. System musi umożliwić modyfikację danych osobowych pacjentów przebywających na oddziale.

27. System musi umożliwić przeglądanie danych archiwalnych pacjenta w zakresie:

28. - danych osobowych,

29. - danych z poszczególnych pobytów szpitalnych,

30. System musi umożliwiać rejestrację i śledzenie historii dokumentów uprawniających do uzyskania świadczeń.

31. System musi sprawdzać zgodność daty urodzenia pacjenta podanej w dokumencie UE, z datą urodzenia podaną w danych osobowych pacjenta.

32. System musi umożliwiać określenie stopnia niepełnosprawności w danych pacjenta.

33. System musi umożliwiać obsługę innych dokumentów tożsamości niż dowód osobisty/paszport dla opiekuna/osoby upoważnionej.


35. System musi umożliwić ograniczenie widoczności danych wrażliwych za pomocą uprawnień. Pomimo braku uprawnień istnieje możliwość prezentacji danych niejawnych przeglądanych w ramach danej opieki.

36. System musi umożliwić dodanie zdjęcia pacjenta w danych podstawowych.18




37. System musi umożliwić wstawienie zdjęcia pacjenta:

38. -z pliku graficznego

39. - zeskanowanego

40. - zdjęcia wykonanego podczas przyjęcia pacjenta

41. System musi umożliwiać gromadzenie danych o lekach stale przyjmowanych przez pacjenta m.in. w zakresie- nazwa leku -okres przyjmowania leku-dawkowanie-rozpoznanie-źródło informacji

42. Przyjęcie pacjenta na oddział

43. Przyjęcie pacjenta do oddziału powinno odbywać się w jednym z trybów:

44. - w trybie nagłym w wyniku przekazania przez zespół ratunkowy

45. - w trybie nagłym

46. - planowane na podstawie skierowania

47. - planowane, poza kolejnością, na podstawie posiadanych uprawnień

48. - przymusowe

49. - przeniesienie z innego szpitala

50. - przyjęcie osoby podlegającej obowiązkowemu leczeniu

51. - noworodka, w wyniku porodu w tym szpitalu (dla oddziału neonatologicznego)

52. System musi umożliwić rejestrację odmowy lub anulowania przyjęcia do Oddziału, skutkujące wycofaniem danych pacjenta na Izbę Przyjęć lub innej jednostki kierującej (inny oddział)

53. System musi umożliwiać zaplanowanie późniejszego terminu przyjęcia – wpis do Księgi Oczekujących Oddziału,

54. System musi umożliwić dodanie zdefiniowanej (dla jednostki lub odcinka) listy procedur medycznych podczas przyjmowania pacjenta na oddział.

55. System powinien prezentować czas, jaki upłynął od ostatniej hospitalizacji, w tym hospitalizacji o tym samym rozpoznaniu, co aktualna




56. System musi umożliwić określenie wymagalności przypisania łóżka pacjentowi podczas przyjęcia na Oddział.

57. Podczas rejestracji przyjęcia pacjenta na oddział system powinien umożliwiać:

58. - nadanie numeru Księgi Oddziałowej – automatycznego lub wpisanie przez użytkownika,

59. - wprowadzenie danych lekarza prowadzącego,

60. -ewidencję pielęgniarki prowadzącej oraz zapis historii zmian pielęgniarki,

61. - możliwość modyfikacji danych płatnika,

62. - wprowadzenie danych o miejscu hospitalizacji w ramach oddziału: odcinka oddziałowego, łóżka,

63. - wprowadzenie danych o rodzaju hospitalizacji do celów statystycznych, np. całodobowa z zabiegiem operacyjnym, dzienna z bez zabiegów i badań laboratoryjnych, itp.

64. - podpowiadanie czasu trwania pobytu na oddziale. System powinien umożliwiać określanie domyślnej liczby dni pobytu dla oddziałów

65. Pobyt pacjenta na oddziale

66. System musi umożliwić rejestrację wywiadu wstępnego z możliwością użycia słownika tekstów standardowych lub zdefiniowanych formularzy,

67. System musi umożliwiać rejestrację rozpoznań: wstępnego, końcowego, przyczyny zgonu,

68. System umożliwia wyszukiwanie rozpoznań po kodzie, nazwie i słowach kluczowych zdefiniowanych przez administratora systemu.

69. System musi podpowiadać rozpoznanie wstępne – oddziałowego, takie samo, jak rozpoznanie z poprzedniego pobytu

70. Podczas rejestracji danych dot. pobytu system, w zależności od statusu pobytu, podpowiada do wypełnienia odpowiedni typ rozpoznania. Jeśli pobyt nie posiada statusu "zamknięty" to domyślnie podpowiadanym rozpoznaniem, jest rozpoznanie wstępne

71. System powinien sygnalizować brak rozpoznania dodatkowego z zakresu V-Y przy podanym rozpoznaniu zasadniczym z grup S-T

72. System musi umożliwiać określenie klasyfikacji TNM oraz stopni zaawansowania dla poszczególnych rozpoznań nowotworowych. Ponadto system umożliwia konfigurację klasyfikacji TNM dla rozpoznań nowotworowych, w zakresie stopnia rozwoju i występowania przerzutów dla poszczególnych cech klasyfikacji.

73. System musi umożliwiać zdefiniowanie listy rozpoznań określających zatrucie, dla których wymagane jest wypełnienie formularza PSS.

74. System umożliwia kopiowanie rozpoznania zaewidencjonowanego w ramach choroby przewlekłej pacjenta.

75. System powinien umożliwiać tworzenie tymczasowych wpisów w historii choroby




76. System musi umożliwiać autoryzację, przez lekarza, rejestrowanych elementów historii choroby

77. Dla wpisów autoryzowanych, system musi prezentować informacje o dacie i godzinie autoryzacji oraz osobie autoryzującej

78. System musi umożliwiać przeglądanie historii choroby, wyników badań, zleceń z wielu pobytów na jednym ekranie; z możliwością konfiguracji kategorii danych.

79. System powinien umożliwiać wydruk historii choroby zawierający kod kreskowy

80. System musi umożliwiać rejestrację informacji o zdeponowanych przez pacjenta rzeczach, z wpisem do wybranej księgi depozytów

81. System musi umożliwić wpisanie planowanego czasu trwania hospitalizacji

82. System powinien umożliwiać zdefiniowanie standardowego czasu pobytu pacjenta dla każdego z oddziałów. Czas ten powinien być podpowiadany podczas przyjęcie pacjenta na oddział.

83. System musi informować o przeterminowanych pobytach w zależności od rozpoznania

84. System musi umożliwiać przegląd historii zmian danych pobytu w oddziale

85. System musi umożliwiać rejestrację wykonanych oraz zlecanych pacjentowi elementów leczenia, w szczególności:

86. - procedur, w tym zabiegów, z możliwością ich wprowadzania wg zdefiniowanych grup

87. - umiejscowieniu realizacji procedury medycznej,

88. - badań diagnostyczne,

89. - leków,

90. - konsultacji,

91. - diet,

92. Powinna istnieć możliwość jednoczesnego dodawania i usuwania wielu procedur

93. System musi umożliwić ewidencję przepustek

94. System musi umożliwić oznaczenie na przepustce pacjenta możliwości rozliczenia rezerwacji łóżka w oddziale.

95. W danych medycznych pacjenta musi istnieć możliwość rejestracji informacji o szczepieniach, alergii, chorobach przewlekłych, grupie krwi. Dane te powinny być na stałe przypisane do pacjenta i widoczne w kontekście każdego pobytu.

96. Dla grupy krwi powinna być możliwość potwierdzenia przez lekarza oraz możliwość załączenia skanu dokumentu potwierdzającego grupę

97. System umożliwia zdefiniowanie wymagalności zaplanowania terminu pacjenta 21




podczas wysyłania zleceń.98. Ewidencja danych do rozliczenia kontraktowanych produktów z płatnikiem, w tym

rozliczanie kart TISS28,99. System powinien umożliwiać powielanie, już zarejestrowanych kart TISS28

100. System umożliwia ewidencję w ramach pobytu konsultacji anestezjologicznych wykonanych przed rozpoczęciem hospitalizacji, umożliwiając ich rozliczenie w ramach NFZ.

101. System musi umożliwić tworzenie kart kwalifikacji do żywienia dojelitowego i pozajelitowego

102. System musi umożliwiać dodanie pakietu materiałów podczas grupowego dodawania leków w jednostkach.

103. System musi umożliwić podczas przenoszenia pacjenta na inny oddział, przepięcie kart pomocniczych pacjenta do dokumentacji nowego oddziału.

104. Opieka pielęgniarska

105. System musi umożliwiać ewidencję diagnoz pielęgniarskich, co najmniej, w zakresie:

106. - wprowadzania diagnoz (przy użyciu słownika diagnoz funkcjonującego w szpitalu)

107. - wprowadzania procedur wynikających z diagnozy przy użyciu słownika INCP

108. - ustalenie listy diagnoz preferowanych dla jednostki

109. - przegląd diagnoz z poprzednich pobytów pacjenta

110. - realizacji procedur wynikających z diagnoz,

111. - dodania lub usuwania wielu procedur jednocześnie

112. - odnotowania realizacji wielu procedur jednocześnie

113. - edycji opisu wykonanej procedury

114. - planu realizacji

115. - wydruku indywidualnej karty procesu pielęgnacji

116. - zbiorczej realizacji procedur wynikających z jednej lub wielu diagnoz

117. - zbiorczej realizacji procedur dla wielu pacjentów

118. System musi zapewnić możliwość wystawienia, podglądu i edycji:

119. - zleceń wykonania diagnoz pielęgniarskich22




120. - zleceń wykonania pomiarów

121. - innych zleceń pielęgniarskich

122. System musi umożliwić jednoczesne zakończenie wielu diagnoz pielęgniarskich.

123. System musi umożliwić jednoczesne przywrócenie do realizacji wielu diagnoz pielęgniarskich.

124. System musi umożliwić powielenie obserwacji/przebiegu pielęgniarskiego.

125. System musi umożliwiać przeprowadzenie wywiadu ginekologicznego

126. System musi umożliwiać określenie maksymalnego opóźnienia we wprowadzeniu opisu obserwacji/przebiegu pielęgniarskiego.

127. System musi umożliwić określenie maksymalnego opóźnienia w wystawieniu zlecenia pielęgniarskiego.

128. System musi umożliwiać odnotowanie realizacji wielu zleceń pielęgniarskich jednocześnie.

129. System musi umożliwić wycofanie operacji realizacji lub odrzucenia zlecenia pielęgniarskiego.

130. System powinien umożliwiać wskazanie przebiegów pielęgniarskich, które powinny zostać wydrukowane na raporcie z dyżuru pielęgniarskiego

131. Powinna istnieć możliwość zdefiniowania, dla jednostki organizacyjnej, domyślnych diagnoz, które będą przypisywane pacjentowi w momencie jego przyjęcia na oddział

132. System musi umożliwiać wydruk karty gorączkowej z możliwością wyboru pomiarów , jakie powinny pojawić się na karcie

133. System musi umożliwiać drukowanie wielu zleceń pielęgniarskich z danego dnia na wydruku karty gorączkowej

134. Ewidencja pomiarów dokonywanych pacjentowi wg ustalonej przez użytkownika kolejności

135. System umożliwia określenie częstotliwości wykonań pomiarów i innych zleceń pielęgniarskich.

136. System musi umożliwiać definiowanie słowników wartości mierzonych i korzystanie ze słownika podczas odnotowywania pomiaru

137. Musi istnieć możliwość wydruku siatek centylowych dla pomiaru wzrostu, wagi, obwodu głowy i BMI dla pacjentów w różnych grupach wiekowych.

138. System musi umożliwić powiązanie wyniku pomiaru ze zleceniem pomiaru.

139. System musi umożliwiać wprowadzanie wyników pomiarów złożonych, na które składa sie kilka pomiarów prostych.

140. System musi umożliwić ewidencję przebiegów pielęgniarskich

141. System musi umożliwiać wprowadzanie opisów zaleceń pielęgniarskich23




142. System musi umożliwiać wprowadzanie opisów wywiadu pielęgniarskiego

143. System musi umożliwiać wprowadzani informacji o stopniu sprawności pacjenta

144. System musi umożliwiać wprowadzanie opisów historii pielęgnowania

145. System musi umożliwić podgląd opisów zleceń i wywiadów pielęgniarskich dla całej hospitalizacji pacjenta, a nie tylko dla bieżącego pobytu.

146. System musi umożliwiać rozszerzenie definicji diagnoz i procedur pielęgniarskich o diagnozy i interwencje wg klasyfikacji INCP

147. System musi umożliwiać wybór diagnoz i procedur pielęgniarskich dla pacjenta wg kodów i nazw klasyfikacji INCP

148. System musi umożliwiać rejestrację przebiegu pielęgniarskiego bezpośrednio z listy pacjentów

149. System musi umożliwiać określanie kategorii opieki pielęgniarskiej dla pacjenta

150. System musi umożliwiać automatyczne ustalanie kategorii opieki pielęgniarskiej dla pacjenta, na podstawie kategorii określanych dla kryterium: aktywność fizyczna, odżywianie, wydalanie

151. System umożliwia określanie poziomu intensywności opieki pielęgniarskiej nad pacjentem na oddziałach intensywnej terapii.

152. System musi umożliwiać wydruk przebiegów pielęgniarskich

153. Musi istnieć możliwość wykorzystania definiowanych formularzy do opisu przebiegu pielęgniarskiego

154. Tworzenie zapotrzebowania żywnościowego dla pacjentów oddziału z możliwością przeliczenia ilości zamawianych posiłków wg przypisanych pacjentom diet

155. Możliwość uzupełnienie zapotrzebowania żywnościowego o zamówienia dodatkowych posiłków i materiałów

156. Musi istnieć możliwość odnotowania podania leku należącego do pacjenta

157. System musi umożliwić tworzenie dokumentacji związanej z oceną stanu odżywiania pacjenta

158. Podczas tworzenia dokumentu oceny stanu odżywiania, system powinien uzupełniać dokument danymi ostatnich pomiarów

159. System musi umożliwić ewidencję kart pomocniczych z poziomu opieki pielęgniarskiej

160. System musi umożliwiać podgląd karty bilansu płynów w ramach opieki pielęgniarskiej

161. System musi umożliwiać dodanie zlecenia pielęgniarskiego grupie pacjentów.

162. Oddział ginekologiczno - położniczy

163. System musi umożliwić ewidencję danych porodu, co najmniej w zakresie : 24




164. - wywiadu przedporodowego (badania położniczego)

165. - wpis do Księgi Porodów,

166. - odnotowanie personelu uczestniczącego,

167. - odnotowanie danych noworodka (medyczne, Apgar)

168. - odnotowanie badania przedmiotowego noworodka

169. - odnotowanie czasu pracy personelu uczestniczącego w porodzie

170. - odnotowanie informacji o zabiegach i powikłaniach

171. System musi umożliwić kopiowanie do nowego wywiadu przedporodowego, danych z poprzedniego wywiadu pacjentki.

172. Dla porodów zabiegowych musi istnieć możliwość odnotowania rodzaju porodu:

173. - cesarskie cięcie

174. - kleszcze

175. - próżnociąg

176. - zlecenie porodu zabiegowego kierowane na blok porodowy

177. Musi istnieć możliwość drukowania karty obserwacji porodu

178. System musi umożliwić zdefiniowanie zdarzenia związanego z porodem (takiego jak: początek porodu, koniec porodu, urodzenie pierwszego noworodka), na podstawie którego prezentowana jest data porodu w Księdze porodów.

179. System powinien umożliwiać określanie reguł nadawania imion noworodkom

180. Na oddziale Neonatologicznym, w danych medycznych noworodka wgląd w dane porodu i dane matki

181. System musi umożliwiać niezależną ewidencję danych charakterystyki porodu dla noworodków w przypadku porodów mnogich

182. System musi umożliwiać zlecenie sekcji zwłok lub innego badania histopatologicznego dla martwo urodzonego noworodka

183. Zakończenie pobytu

184. System musi umożliwić rejestrację opuszczenia oddziału przez pacjenta w jednym z trybów:

185. - przeniesienie/wycofanie przeniesienia pacjenta na inny Oddział.25




186. - przeniesienie w trybie nagłym na inny Oddział (bez uzupełnienia danych wypisowych z poprzedniego oddziału),

187. - wypis pacjenta ze Szpitala,

188. - zgon pacjenta na Oddziale, z możliwością odnotowania:

189. -- innej osoby wypisującej a innej stwierdzającej zgon

190. -- danych medycznych po zarejestrowaniu zgonu pacjenta

191. -- rodzaju zgonu: nagły, śródoperacyjny, śródzabiegowy, inny

192. -- oznaczenia pacjenta jako dawcy organów

193. -- wycofanie aktywnych deklaracji POZ

194. System umożliwia obsługę opieki nad dawcą organów w zakresie:

195. - ewidencji danych medycznych

196. - ewidencji obserwacji lekarskich

197. - ewidencji opieki pielęgniarskiej

198. Podczas kończenia pobytu, jeśli stwierdzono wystąpienie patogenu alarmowego a karta zakażenia szpitalnego nie została wystawiona, system wymaga wypełnienie tej karty

199. Odnotowanie faktu wydania pacjentowi druków, zaświadczeń, skierowań itp.,

200. Podczas rejestracji zgonu pacjenta, system powinien anulować wszystkie zlecenia, zaplanowane wizyty oraz wpisy w kolejce oczekujących

201. Podczas rejestracji wypisu pacjenta system powinien zakończyć zlecenia leków oraz diet.

202. System musi umożliwić zakończenie realizacji otwartych diagnoz pielęgniarskich podczas potwierdzania wypisu lub zgonu pacjenta.

203. Podczas rejestracji wypisu system powinien odnotowywać datę archiwizacji o nr kartoteki pacjenta

204. Przygotowanie dokumentacji medycznej

205. System musi umożliwić autoryzację danych oddziałowych, co najmniej w zakresie:

206. - rozpoznań,

207. - epikryz,26




208. - obserwacji lekarskich.

209. Danych autoryzowanych nie można usunąć ani modyfikować, jedynie oznaczyć jako nieaktualne

210. Podczas wpisywania treści rozpoznania opisowego, system musi umożliwiać wykorzystanie wszystkich tekstów zapisanych wcześniej w historii choroby pacjenta.

211. System musi umożliwiać wydruk obserwacji zarejestrowanych w ramach wszystkich pobytów pacjenta.

212. Możliwość projektowania formularzy dokumentacji medycznej

213. Możliwość definiowania własnych szablonów wydruków,

214. Możliwość definiowania własnych wykazów

215. System musi informować o konieczności utworzenia właściwego dokumentu w oparciu o informacje o wyniku badania (patogen alarmowy)

216. Przechowywanie wszystkich wersji utworzonych dokumentów

217. Przegląd i modyfikacja pełnej historii choroby, wszystkie jej elementy powinny być dostępne w jednym miejscu, na jednym ekranie

218. Prowadzenie i wydruk Historii Choroby w podziale na:

219. - dane przyjęciowe,

220. - wywiad wstępny (przedmiotowo, podmiotowo),

221. - przebieg choroby,

222. - epikryza (możliwością wykorzystania słownika tekstów standardowych).

223. - kopiowanie wyników badania i danych wypisowych z poprzednich pobytów w ramach jednej hospitalizacji

224. System musi umożliwić wydruk dokumentów wewnętrznych oddziału, w tym:

225. - Karty Wypisowa,

226. - Karty Informacyjna.

227. System musi umożliwić wydruk dokumentów zewnętrznych oddziału, w tym:

228. - Karty Statystyczna,

229. - Karta Zakażenia Szpitalnego,27




230. - Karta Nowotworowa,

231. - Karta Zgłoszenia Choroby Zakaźnej,

232. - Karta Zgonu,

233. - Karta TISS28,

234. - recept,

235. - zwolnień

236. - skierowań

237. - skale Ballarda

238. - karta CRIB II

239. - karta oceny ryzyka NEC

240. - skale Fineganna

241. - siatki ciążowe w zależności od wieku ciążowego i masy ciała

242. - formularz zgody na szczepienie

243. - formularz sprzeciwu wyrażenia zgody na szczepienie

244. - karta szczepień

245. Karta zgłoszenia wady wrodzonej

246. System powinien umożliwiać wystawienie recepty na lek wymieniony we wskazaniach

247. System powinien umożliwić, podczas wystawiania recepty, kopiowanie leku z listy leków podanych i zlecanych podczas hospitalizacji

248. System musi umożliwić obsługę ksiąg:

249. - Księga Główna,

250. - Księga oddziałowa,

251. - Księga Oczekujących,




252. - Księga Zgonów,

253. - Księga Porodów,

254. - Księga Noworodków,

255. - Księga Zabiegów.

256. - Księga Raportów Lekarskich

257. - Księga Raportów Pielęgniarskich

258. - Księga Badań

259. - Księga Zdarzeń Niepożądanych

260. - Księga Oddziału Sztucznej Nerki

261. Podczas wydruku zbiorczej dokumentacji medycznej musi istnieć możliwość definiowania zakresów ksiąg do wydruku obejmująca:

262. - wybrane strony,

263. - wybrane jednostki organizacyjne

264. System musi posiadać możliwość utworzenia i wydrukowania standardowych raportów:

265. - zestawienie pacjentów, nowoprzyjętych, wypisanych, przebywających na oddziale (dzienne, tygodniowe, za dowolny okres)

266. - liczba osobodni z uwzględnieniem przepustek, w zadanym okresie

267. - obłożenie łóżek na dany moment

268. - liczba pacjentów powracających do szpitala w podanym okresie

269. - diety podane pacjentom oddziału.

270. - zaświadczenie o pobycie pacjenta zawierające: nazwisko i imię pacjenta, nazwę oddziału(kliniki), okres pobytu, rozpoznanie zasadnicze

271. - raport przewidywanego zużycia leków we wskazanym zakresie dat.

272. - raport z dyżuru lekarskiego

273. - raport z przebiegów pielęgniarskich powinien uwzględniać sortowanie w porządku malejącym lub rosnącym wg daty wykonania i osoby wykonującej

274. - raport kategorii opieki pielęgniarskiej powinien uwzględniać liczbę pacjentów z 29




podziałem a kategorie dla każdego oddziału lub odcinka na dzień275. - raport prezentujący liczbę diet z zapotrzebowania żywnościowego

276. Integracja z innymi modułami systemu medycznego realizującymi funkcjonalność w zakresie:

277. - ewidencji zużytych leków i materiałów oraz aktualizacji stanów magazynowych (Apteczka oddziałowa),

278. - wzajemnego udostępniania danych zlecenia i danych o jego wykonaniu (Przychodnia, Pracownia Diagnostyczna).

279. Dane dotyczące opisu porodu, noworodka (Blok Operacyjny)

E.

Lp. TAB. IV.E. Rozliczenia z NFZ Spełnianie (TAK/NIE)

1. Zarządzanie umowami NFZ

2. Możliwość obsługi i rozliczeń z wieloma oddziałami NFZ

3. Import pliku umowy w postaci komunikatu UMX,

4. Przegląd i modyfikacja szczegółów umowy:

5. - Okres obowiązywania umowy,

6. - Pozycje planu umowy,

7. - Miejsca realizacji świadczeń

8. - Limity na realizację świadczeń i ceny jednostkowe,

9. - Słowniki związane z umowami (słownik zakresów świadczeń, świadczeń jednostkowych, pakietów świadczeń, schematów leczenia itd.)

10. - Parametry pozycji pakietów świadczeń

11. System musi umożliwiać przegląd informacji o miejscach realizacji umów wraz z informacją o punktach umowy realizowanych w danym miejscu (komórce organizacyjnej).

12. Moduł korzysta bezpośrednio z danych zaewidencjonowanych na oddziałach i w poradniach bez konieczności importu i kopiowania danych

13. Musi istnieć możliwość rozliczenia pobytu, jeśli dane osobowe uległy zmianie w trakcie pobytu (hospitalizacji)

14. Weryfikacja wprowadzonych pozycji rozliczeniowych pod kątem zgodności ze stanem, po wczytaniu aneksu umowy (ze wstecznym okresem obowiązywania). Możliwość zbiorczej modyfikacji pozycji rozliczeniowych, w których znaleziono




różnice:15. - Różnica w cenie świadczenia,

16. - Różnica w wadze efektywnej świadczenia,

17. - Różnica w sposobie obliczania krotności i okresu sprawozdawczego,

18. Definiowanie dodatkowych walidacji

19. - Liczba realizacji świadczeń w okresie,

20. - Liczba realizacji świadczeń w ramach zakresu w okresie,

21. Możliwość ewidencji i rozliczenia realizowanych świadczeń

22. - Ubezpieczonym,

23. - Nieubezpieczonym a uprawnionym do świadczeń,

24. - Uprawnionym na podstawie decyzji wójta/burmistrza

25. - Uprawnionym na podstawie przepisów o koordynacji,

26. - Uprawnionym na podstawie Karty Polaka

27. - Kobietom w ciąży, w okresie połogu oraz młodzieży do 18 roku życia

28. System musi umożliwiać automatyczne przekodowanie procedur medycznych na świadczenia jednostkowe, zaewidencjonowane podczas odmowy na Izbie Przyjęć oraz zakończenia pobytu w SOR bez przekazania na inny oddziała.System powinien umożliwiać wyłączenie automatycznej generacji powyższych rozliczeń (świadczeń jednostkowych) we wskazanych komórkach organizacyjnych.

29. System weryfikuje pobyty dłuższe niż 1 doba, dla SOR i IP

30. Możliwość zbiorczej modyfikacji pozycji rozliczeniowych w zakresie zmian dotyczących

31. - Numeru umowy,

32. - Zakresu świadczeń,

33. - Wyróżnika

34. - Świadczenia jednostkowego,

35. Możliwość zbiorczego wykonania operacji uzupełnienia i poprawienia danych dla 31




Izby Przyjęć i SOR36. Możliwość wprowadzenia dodatkowego poziomu kontroli wprowadzonych

świadczeń poprzez funkcjonalność autoryzacji świadczeń przez osobę uprawnioną 37. Przegląd informacji o posiadanych przez pacjenta uprawnieniach do świadczeń w

każdym dniu pobytu38. Po otrzymaniu informacji z NFZ, uprawniony użytkownik działu rozliczeń musi mieć

możliwość modyfikacji danych39. Sprawozdawczość z oddziałów NFZ w zakresie komunikacji przez pocztę

elektroniczną musi odbywać się automatycznie, z poziomu systemu HIS40. W przypadku komunikatów, w których NFZ wymaga kompresowania lub

szyfrowania danych, operacje te muszą odbywać się automatycznie w systemie HIS

41. System musi umożliwić harmonogramowanie eksportów danych: o wyznaczonej godzinie, co określoną liczbę godzin, za określoną liczbę godzin

42. System musi umożliwić weryfikacje zestawów świadczeń pod kątem:

43. - poprawności i kompletności wprowadzonych danych

44. - danych zakwestionowanych przez system NFZ

45. System musi umożliwiać weryfikację poprawności i kompletności danych w sposób zautomatyzowany, zgodnie ze zdefiniowanym harmonogramem (np. w godzinach nocnych).

46. System musi umożliwiać przeglądanie danych archiwalnych dotyczących błędów weryfikacji, powstałych podczas grupowej weryfikacji świadczeń lub eksportu świadczeń.

47. Wyszukiwanie pozycji błędnie potwierdzonych w komunikatach zwrotnych NFZ

48. Wyszukiwanie po numerach w księgach

49. Wyszukiwanie zestawów bez zaewidencjonowanych procedur ICD9

50. Wyszukiwanie zestawów po numerze paczki, w której wyeksportowano dane do NFZ

51. Wyszukiwanie po instytucji kierującej

52. Wyszukiwanie po personelu kierującym/ realizującym

53. Wyszukiwanie zestawów bez pozycji rozliczeniowych

54. Wyszukiwanie zestawów z niekompletnymi danymi rozliczeniowymi

55. Wyszukiwanie pozycji rozliczeniowych, które nie zostały jeszcze rozliczone

56. Wyszukiwanie po statusie rozliczenia 32




57. Wyszukiwanie zestawów zawierających rozliczenia ze wskazanej umowy

58. Wyszukiwanie zestawów zawierających wskazane świadczenie jednostkowe

59. Wyszukiwanie zestawów świadczeń z JGP wyznaczoną w zadanej wersji

60. Wyszukiwanie zestawów świadczeń ratujących życie i zdrowie

61. Wyszukiwanie zestawów świadczeń zrealizowanych dla wybranych uprawnień pacjenta

62. System musi umożliwiać ewidencję i sprawozdawczość świadczeń z uwzględnieniem współczynników korygujących.

63. Wyszukiwanie świadczeń, które zostały skorygowane, a informacja o skorygowaniu nie została sprawozdana do systemu NFZ

64. Generowanie i eksport komunikatu fazy I (komunikat SWIAD) w aktualnie obowiązującej wersji publikowanej przez płatnika

65. Import potwierdzeń do danych przekazanych w komunikacie I fazy (komunikat P_SWI)

66. Import danych z pliku z szablonami rachunków (komunikat R_UMX)

67. Eksport komunikatów związanych ze sprawozdawczością POZ

68. - Eksport komunikatu DEKL – informacje o deklaracjach

69. - Eksport komunikatów do NFZ z użyciem poczty elektronicznej

70. Import potwierdzeń związanych ze sprawozdawczością POZ

71. Import odpowiedzi nadesłanych poczta elektroniczną

72. - Import komunikatu P_DEK – potwierdzenia danych dla przesłanych deklaracji

73. - Import komunikatu Z_WDP – wyniki weryfikacji deklaracji

74. - Import komunikatu Z_RDP – rozliczenia deklaracji

75. Eksport komunikatów związanych ze sprawozdawczością kolejek oczekujących

76. - Eksport komunikatu LIOCZ – informacje o statystykach kolejek oczekujących

77. - Eksport komunikatu KOL – informacje o oczekujących na świadczenia wysokospecjalistyczne

78. Import potwierdzeń związanych ze sprawozdawczością kolejek oczekujących




79. Import komunikatu P_LIO – potwierdzenie statystyk przekazanych w komunikacie LIOCZ

80. Przegląd szablonów rachunków wygenerowanych i przekazanych przez płatnika

81. Generowanie i wydruk rachunków na podstawie szablonów

82. Generowanie i wydruk faktur na podstawie rachunków

83. Generowanie i wydruk zestawień i raportów związanych ze sprawozdawczością wewnętrzną (możliwość śledzenia postępów wykonania zakontraktowanych świadczeń w ciągu trwania okresu rozliczeniowego)

84. Raport z wykonanych świadczeń z możliwością ograniczenia danych do m.in.:

85. - Numeru umowy,

86. - Zakresu miesięcy sprawozdawczych,

87. - Miesiąca rozliczeniowego,

88. - Jednostki realizującej,

89. - Zakresu świadczeń i wyróżnika,

90. - Świadczenia,

91. - Numeru szablonu

92. - Uprawnienia pacjenta do świadczeń

93. Zestawienie z realizacja planu umowy,

94. Zestawienie wykonań przyrostowo,

95. Zestawienie wykonań według miejsc realizacji

96. Sprawozdanie rzeczowe

97. Eksport danych do formatu XLS

98. Generowanie i wydruk dokumentów związanych ze sprawozdawczością wymaganą przez OW NFZ

99. Sprawozdanie finansowe,

100. Zestawienie świadczeń udzielonych świadczeniobiorcom innym niż ubezpieczeni,




101. Zestawienie świadczeń wykonanych pacjentom na podstawie przepisów o koordynacji (UE),

102. Zestawienie świadczeń wykonanych pacjentom na podstawie art. 2 ust. 1 ustawy (decyzja wójta/burmistrza),

103. Zestawienie świadczeń wykonanych pacjentom nieubezpieczonym, rozliczanym na podstawie art. 12 lub art. 13 ustawy

104. Wyliczanie kosztów porady u pacjenta nieubezpieczonego

105. Załącznik nr 4 do umowy - chemioterapia

106. Załącznik nr 4 do umowy – programy terapeutyczne

107. Załączniki do umów POZ

108. Import słownika produktów handlowych (komunikat PRH)

109. Możliwość przekodowania produktów handlowych na leki

110. Ewidencja faktur zakupowych

111. Generowanie i eksport faktur zakupowych do NFZ w aktualnym formacie komunikatu FZX

112. Import potwierdzeń do faktur zakupowych (komunikat FZZ)

113. Generowanie i wydruk załącznika nr 4 do umowy – ewidencja faktur zakupowych

114. Obsługa sprawozdawczości w zakresie POZ

115. System powinien umożliwiać definiowanie minimalnej i maksymalnej liczby pacjentów uczestniczących w sesjach

116. System musi umożliwiać przypisanie pacjentów do programów leczenia. W przypadku realizacji świadczenia dla różnych umiejscowień (np. lewe, prawe oko), system musi umożliwiać kilkukrotne przypisanie pacjenta do tego samego programu leczenia.

117. System musi umożliwić zbiorcze usuwanie pozycji rozliczeniowych na liście rozliczeń dotyczącej danego zestawu świadczeń.

118. System powinien umożliwiać wykorzystanie słownika jednostek rozliczeniowych

119. Integracja z innymi modułami systemu

120. - ewidencja pozycji rozliczeniowych w Ruchu Chorych, Przychodni

121. - ewidencja faktur zakupowych za leki w chemioterapii w module Apteka

122. - ewidencja faktur zakupowych na leki stosowane w programach lekowych35




123. Dla świadczeń oznaczonych kodem CBE (Centralna baza Endoprotezoplastyk) system powinien wymagać rejestracji właściwego dokumentu

124. Eksport faktur rozliczeniowych do modułu Finansowo-Księgowego

125. System musi umożliwiać określenie domyślnego rodzaju faktury eksportowanej do systemu Finansowo-Księgowego

126. Przekazywanie danych o hospitalizacji do Symulatora JGP

127. JGP

128. Wyznaczanie Jednorodnych Grup Pacjentów na podstawie danych hospitalizacji za pomocą wbudowanego grupera JGP

129. Import aktualnego słownika procedur medycznych ICD9 (komunikat ICD9),

130. Wyznaczanie JGP dla hospitalizacji

131. Możliwość wyznaczania JGP dla każdego z pobytów oddzielnie

132. Zapewnienie sprawnego zasilania systemu w aktualne charakterystyki JGP wynikające z publikowanych Zarządzeń Prezesa NFZ

133. Wyznaczanie JGP za pomocą wbudowanego (lokalnego) grupera JGP w zakresie umów: leczenie szpitalne, rehabilitacja stacjonarna, ambulatoryjna opieka specjalistyczna

134. Możliwość ręcznego wyznaczenia JGP dla hospitalizacji z pominięciem grupera lokalnego i grupera NFZ

135. Możliwość automatycznego przypisania JGP do pobytu na oddziale, z którego pochodzi element kierunkowy wyznaczonej JGP

136. Wsteczna weryfikacja poprawności wyznaczonych wcześniej JGP z możliwością aktualizacji JGP na poprawną

137. Różnice wynikające z wczytania nowych wersji grupera, które opublikowano z wsteczną datą obowiązywania, które mogą obejmować

138. - Różnice w zaewidencjonowanych taryfach,

139. - Różnice w zaewidencjonowanych JGP,

140. Różnice wynikające z modyfikacji danych statystycznych hospitalizacji, a mające wpływ na wyznaczoną JGP:

141. - Konieczność zmiany JGP,

142. - Konieczność zmiany taryfy,

143. - Konieczność przepięcia JGP do pobytu na innym oddziale

144. Wyszukiwanie hospitalizacji wg poniższych kryteriów36




145. - Data zakończenia hospitalizacji,

146. - Wersja grupera za pomocą którego wyznaczono JGP

147. - Kod JGP,

148. - Rozpoznanie główne

149. - Kod procedury medycznej,

150. - Status rozliczenia

151. Wskazanie możliwości uzyskania JGP o większej taryfie w przypadku zmiany kombinacji rozpoznań wypisowych

152. Możliwość porównania wersji grupera. Wynik porównania powinien być możliwy do zapisu w formacie XLS.

153. Wsteczna weryfikacja z możliwością aktualizacji JGP pod kątem znalezienia bardziej optymalnej JGP

154. Jeśli dla hospitalizacji istnieje aktywne świadczenie JGP ze wskazanym sposobem rozliczenia związanym z urazami wielonarządowymi (UJ1, UJ2, UJ3), system powinien sprawdzić, czy wśród rozpoznań wypisowych hospitalizacji występuje rozpoznanie z listy T07 dla wersji grupera zgodnej ze wskazanej w świadczeniu JGP

155. Możliwość wydrukowania charakterystyki wybranej JGP w formie podręcznej karty

156. Możliwość wykonywania symulacji wyznaczania JGP (funkcjonalność Symulatora JGP)

157. Symulator Ryczałtu PSZ

158. System musi umożliwiać symulację ryczałtu PSZ.

159. Funkcjonalność Symulatora Ryczałtu PSZ zintegrowana powinna być z system dziedzinowym służącym do ewidencji i rozliczania umów z NFZ.

160. Symulator ryczałtu pozwala na:

161. - wybór okresu planowania oraz okresu rozliczeniowego z możliwością wskazania przedziału miesięcy lub dni

162. - ręczne wprowadzenie wartości niezbędnych do wyliczenia ryczałtu zgodnie z rozporządzeniem Ministra Zdrowia w sprawie sposobu ustalania ryczałtu systemu podstawowego szpitalnego zabezpieczenia świadczeń opieki zdrowotnej

163. - pobranie wartości wykonania świadczeń z systemu dziedzinowego

164. - pobranie wartości dynamiki (wzrost/spadek) liczby świadczeń ambulatoryjnych z systemu dziedzinowego

165. - pobranie wartości dynamiki (wzrost/spadek) średniej wartości hospitalizacji z 37




systemu dziedzinowego166. - określanie stopnia spełnienia parametrów jakościowych wpływających na

wielkość ryczałtu zgodnie ww. rozporządzeniem.167. - wyliczanie prognozowanego ryczałtu w wzorów określonych w ww.

rozporządzeniu.168. Symulator JGP

169. Symulator dostępny w systemie, działający w oparciu o dane medyczne zgromadzone w systemie medycznym

170. Symulator dostępny poprzez przeglądarkę WWW bez konieczności dostępu do zewnętrznej sieci Internet

171. System musi umożliwiać wstępne zasilania symulatora danymi wybranego zestawu świadczeń (hospitalizacji, wizyty), a w przypadku niezakończonych hospitalizacji system musi umożliwiać uzupełnienie wymaganych pozycji symulatora domyślnymi danymi.

172. Możliwość sprawnej modyfikacji danych w symulatorze i obserwacja wpływu zmian na wyznaczane JGP

173. Modyfikacja danych pacjenta (wiek, płeć),

174. Modyfikacja danych hospitalizacji (data przyjęcia, data wypisu, tryb przyjęcia, tryb wypisu, tryb i charakter hospitalizacji,

175. Dodanie lub usuniecie pobytu

176. Modyfikacja danych pobytu (data przyjęcia, data wypisu, cz. VIII kodu resortowego komórki, kod świadczenia, rozpoznanie zasadnicze, rozpoznania współistniejące, procedury medyczne (daty wykonania))

177. Wyróżnianie kolorami danych hospitalizacji nieistotnych z punktu widzenia wyznaczenia JGP

178. Możliwość określenia wersji grupera za pomocą którego wyznaczone zostaną JGP

179. Wersja grupera wynikająca z daty zakończenia hospitalizacji,

180. Dowolna wersja grupera istniejąca w systemie,

181. Wskazywanie JGP z podziałem na:

182. - JGP, dla której hospitalizacja spełnia warunki wyboru,

183. - JGP, dla których hospitalizacja nie spełnia warunków,

184. - JGP, które istnieją w planie umowy świadczeniodawcy,

185. Wyróżnienie kolorem pozycji w celu odzwierciedlenia ważności wyznaczonych JGP z punktu widzenia świadczeniodawcy (np. istniejących w planie umowy a tym samym możliwych do rozliczenia)




186. W przypadku wskazania JGP do których pacjent mógłby zostać zakwalifikowany jednak nie zostały spełnione wszystkie warunki - wskazanie tych warunków

187. Możliwość przeglądu podstawowych informacji o wybranej JGP

188. Wartości taryf dla poszczególnych trybów hospitalizacji,

189. Parametry związane z mechanizmem osobodni (liczba dni finansowana grupą, taryfa dla hospitalizacji trwających < 2 dni, wartość punktowa osobodnia ponad ryczałt finansowany grupą),

190. Parametry JGP (warunki, które musi spełniać hospitalizacja),

191. Wykorzystanie planu umowy dla JGP w przypadku, gdy JGP istnieje w umowie ,

192. Prezentacja wykresów ilustrujących zależność naliczonych taryf od czasu hospitalizacji pacjenta

193. Kolejki oczekujących

194. Definicja kolejek oczekujących zgodnie z wymaganiami płatnika

195. Kolejki oczekujących do komórek organizacyjnych

196. Kolejki oczekujących do procedur medycznych lub świadczeń wysokospecjalistycznych zdefiniowanych przez płatnika

197. Prowadzenie kolejek oczekujących

198. Wykaz osób oczekujących w kolejce

199. Możliwość planowania daty z dokładnością do dnia lub tygodnia (w przypadku odległego terminu realizacji świadczenia)

200. Przyporządkowanie oczekujących do jednej z kategorii medycznych (przypadki pilne/przypadki stabilne)

201. Rejestrowanie przypadków zmian terminu udzielenia świadczenia wraz z przyczyną zmiany

202. Możliwość przywrócenia do kolejki oczekujących pacjenta wykreślonego

203. Zablokowanie możliwości zmiany danych w kolejce oczekujących dla pacjentów zrealizowanych, po zakończeniu okresu rozliczeniowego tj. po 10 dniu każdego miesiąca za miesiąc rozliczeniowy (poprzedni)

204. Możliwość zbiorczego przenoszenia oczekujących pomiędzy kolejkami

205. Możliwość zbiorczego przeliczania pierwszych wolnych terminów dla wszystkich kolejek oczekujących

206. - Wszystkich aktywnych pozycji

207. - Wybranych oczekujących39




208. Wskazanie tych definicji kolejek oczekujących, które po wczytaniu aneksu do umowy posiadają nieaktualne informacje o kodzie komórki wg NFZ wraz z możliwością aktualizacji kodu komórki wg NFZ na podstawie aktualnych zapisów w umowie z NFZ

209. Generowanie statystyk kolejek z podziałem na przypadki pilne i stabilne

210. - Liczba oczekujących

211. - Szacunkowy czas oczekiwania w kolejce

212. - Średni rzeczywisty czas oczekiwania w kolejce (zgodnie z algorytmem opublikowanym w rozporządzeniu)

213. Komunikacja z NFZ

214. Generowanie i eksport komunikatów XML w aktualnie obowiązujących wersjach z zakresu sprawozdawczości związanej z kolejkami oczekujących

215. Komunikat LIOCZ – komunikat szczegółowy o kolejkach oczekujących

216. Komunikat KOL – komunikat o kolejkach oczekujących do świadczeń wysokospecjalistycznych

217. Import komunikatu „potwierdzeń odbioru” danych o kolejkach oczekujących

218. Wydruki i raporty dotyczące kolejek oczekujących

219. Wydruk listy oczekujących z uwzględnieniem poniższych kryteriów

220. - Rodzaj kolejki (do komórki organizacyjnej, do procedury medycznej/świadczenia wysokospecjalistycznego)

221. - Kod kolejki

222. - Stan wpisu w kolejce (aktywne, wykreślone, zakończone realizacją)

223. - Kategoria medyczna (pilny, stabilny)

224. - Data wpisu (od .. do ..)

225. - Data planowanej realizacji (od .. do ..)

226. - Data skreślenia z kolejki (od .. do ..)

227. Potwierdzanie odbioru komunikatu, dla komunikatów tego wymagających, bezpośrednio w aplikacji

228. prowadzenie kolejek onkologicznych i kolejek na procedurę




229. rejestracja dla kolejki onkologicznej powinna odbywać się bez podziału na przypadki pilne i stabilne

230. Weryfikacja w eWUŚ

231. Weryfikacja uprawnień pacjenta do świadczeń refundowanych przez NFZ podczas

232. rejestracji na Izbie Przyjęć

233. rejestracji/planowania wizyty w przychodni lub pracowni, weryfikowany jest stan na dzień rejestracji

234. System musi umożliwić sprawdzenie statusu eWUŚ dla pacjentów wpisanych do Księgi Oczekujących.

235. Tworzenie harmonogramów weryfikacji grupowej

236. System musi umożliwić powiadamianie użytkownika o przebiegu zbiorczej weryfikacji uprawnień eWUŚ z użyciem kanałów SMS i e-mail.

237. System musi umożliwiać taką konfigurację procesu weryfikacji uprawnień eWUŚ, aby w przypadku pracy w konfiguracji sieci jednostek, system sprawdzał uprawnienia eWUŚ pacjenta w jednym z poniższych trybów:

238. -uprawnienia pacjenta sprawdzane w kontekście wszystkich Oddziałów Wojewódzkich NFZ odpowiadającym Świadczeniodawcom objętych funkcjonalnością sieci jednostek

239. -uprawnienia pacjenta sprawdzane były wyłącznie w kontekście właściwego płatnika wskazanego w danych zestawu świadczeń (wizyty, hospitalizacji), a nie wszystkich płatników NFZ zdefiniowanych w systemie

240. Weryfikacja uprawnień w oparciu o harmonogramy obejmująca pacjentów

241. - przebywających na oddziale,

242. - przebywających na obserwacji na izbie przyjęć

243. - w trakcie wizyt

244. - wypisywanych ze szpitala ale o niezautoryzowanym wypisie i nie rozliczonych

245. - dla których zarejestrowano zgon, ale zapis nie został autoryzowany a pobyt rozliczony

246. - którzy złożyli deklaracje

247. Oznaczanie ikoną i kolorem statusu weryfikacji pacjenta

248. - na liście pacjentów

249. - w widocznym miejscu przy danych pacjenta



F.

Lp. TAB. IV.F Statystyka Spełnianie (TAK/NIE)

1. Obsługa rejestru pacjentów2. System musi umożliwić obsługę skorowidza pacjentów z możliwością integracji

z innymi systemami medycznymi (Przychodnia, Pracownia Diagnostyczna)3. System musi umożliwić wyszukiwanie pacjentów w skorowidzu wg różnych

parametrów, w szczególności:4. - identyfikator pacjenta5. - data urodzenia i miejsce6. - imię ojca i matki7. - miejsce urodzenia8. - płeć9. - PESEL opiekuna10. - nazwisko rodowe matki11. - miasto (pobyt stały, adres korespondencyjny)12. - pobyt w jednostce13. - pobyt w okresie14. - nr telefonu15. - adres e-mail16. - nazwisko rodowe i poprzednie nazwisko pacjenta17. - rodzaj i nr dokumentu tożsamości18. - status: VIP, cudzoziemiec, uprawniony do przyjęcia poza kolejnością19. - przyjęty: dzisiaj w godzinach od.. do.., wczoraj w godzinach od.. do.., w ciągu

ostatnich 24,48, X godzin20. System musi umożliwić wyszukiwanie pacjenta o nieznanej tożsamości (NN) co

najmniej w oparciu o:21. - płeć (męska, żeńska, nieznana)22. - fragment (fraza) opisu pacjenta23. - przyjęty: dzisiaj w godzinach od.. do.., wczoraj w godzinach od.. do.., w ciągu

ostatnich 24,48, X godzin24. Musi istnieć możliwość modyfikacji i rejestracji danych pacjentów,25. Musi istnieć możliwość przeglądu danych archiwalnych pacjenta: 26. - w zakresie danych osobowych,27. - w zakresie danych z poszczególnych pobytów szpitalnych28. System musi umożliwać zatwierdzenie wniosku użytkownika o zmianę danych.29. System musi umożliwiać podgląd złożonych wniosków oraz ich statusów w

kontekście osoby składającej oraz wszystkich użytkowników.30. System musi umożliwiać obsługę wniosków użytkownika o zmianę:31. -danych personalnych32. -danych kontaktowych33. -danych wymaganych w dokumentacji medycznej (tytuł naukowy, tytuł

zawodowy, specjalizacje)34. System musi umożliwiać potwierdzenie wypisu pacjenta pod kątem

kompletności i poprawności dokumentacji,35. System musi umożliwić obsługę ksiąg:




36. - Księga Główna,37. - Księga Odmów,38. - Księga Zgonów,39. - Księga Noworodków,40. - Księga Oczekujących,41. - Księga Transfuzji42. - Księga Badań43. - Księga Oddziałowa44. - Księga Zabiegów45. - Księga Noworodków,46. - Księga Zdarzeń Niepożądanych47. System musi umożliwiać wyszukiwanie pacjentów NN w Księdze Ratownictwa

Medycznego.48. Raporty i wydruki statystyki49. System musi umożliwiać definiowanie własnych szablonów wydruków,50. System musi umożliwiać definiowanie własnych wykazów 51. System musi umożliwiać definiowanie wykazów z wykorzystaniem generatora

Jasper Reports52. System powinien umożliwiać generowanie raportów statystycznych dla

nieaktywnych Jednostek Organizacyjnych Szpitala53. System musi umożliwiać projektowanie formularzy dokumentacji medycznej54. System musi umożliwiać wydruk, co najmniej:55. - Karty Statystycznej,56. - Karty Leczenia ,57. - Karty Zgonu,58. System musi umożliwiać tworzenie raportów: 59. - zestawienie pacjentów, nowoprzyjętych, wypisanych, przebywających na

oddziale (dzienne, tygodniowe, za dowolny okres)60. - liczba osobodni z uwzględnieniem przepustek, w zadanym okresie61. - diety podane pacjentom oddziału.62. wbudowane raporty standardowe: 63. - statystyczne z oddziałów: np. Dziennik ruchu chorych, wskaźniki szpitalne w

okresie (liczba. przyjętych, liczba wypisanych, liczba osobodni),64. - z obłożenia łóżek,65. - dekursusów,66. wysyłanie raportu z obłożenia łóżek na zdefiniowany adres e-mail67. - zestawienia wg jednostek chorobowych, czasu leczenia jednostki chorobowej

(sumaryczne i osobowe)68. - pacjenci powracający do szpitala, z uwzględnieniem pacjentów powracających

na ten sam oddział69. System powinien umożliwić wydruk raportów w formacie XLS70. System musi umożliwiać przygotowanie elektronicznych dokumentów

wymaganych do zapewnienia komunikacji z instytucjami nadrzędnymi, w tym:71. System musi umożliwić wykonanie raportu pacjentów powracających do




szpitala (dla wszystkich jednostek organizacyjnych szpitala)72. - Oddziały NFZ, 73. - PZH.74. System musi umożliwiać eksport danych statystycznych oraz ilościowych o

wykonanych świadczeniach do pliku tekstowego lub w formacie .xls z możliwością wykorzystania przez moduły Rachunku Kosztów Leczenia.

75. Prowadzenie rejestru Kart Diagnostyki Leczenia Onkologicznego76. System musi umożliwiać tworzenie i modyfikację kart DILO77. Podczas rejestracji karty musi istnieć możliwość zarejestrowania, co najmniej:78. - numer karty79. - etap80. - lokalizacja (przyjęta, wydana, odesłana do lekarza POZ)81. - status (aktualna, zamknięta, archiwalna, anulowana)82. - data wersji od83. Podczas zmiany danych karty tj. etap, lokalizacja, status system powinien

zmieniać datę wersji na datę bieżącą84. Podczas tworzenia karty system powinien umożliwiać edycję daty ważności85. Raporty i wykazy statystyki86. System powinien umożliwiać tworzenie reportów i wykazów statystyki, w

szczególności:87. - raport rozpoznań - zestawienie syntetyczne i analityczne liczbie rozpoznań

każdego rodzaju w rozbiciu na pacjentów i jednostki wykonujące88. - wykonane badania wg płatnika i jednostki kierującej - zestawienie ilości

wykonanych badań poszczególnych rodzajów, z podziałem na jednostki wykonujące, dla wybranych instytucji i jednostek kierujących

89. - lista pacjentów przyjętych przez lekarza - zestawienie pacjentów przyjętych w zadanym okresie, w wybranych gabinetach, przez wybranych lekarzy

90. - zestawienie statystyczne pacjentów - zestawienie syntetyczne lub analityczne (dla poszczególnych dni zadanego okresu) liczby pacjentów przyjętych w wybranych/wszystkich gabinetach w rozbiciu na dorosłych i dzieci z podziałem na płeć oraz pacjentów pierwszorazowych i kontynuację leczenia

91. - raport obciążenia gabinetów - zestawienie liczby wykonanych badań w poszczególnych dniach zadanego okresu dla wybranych/wszystkich gabinetów, dla poszczególnych lekarzy

92. - wykonane procedury - syntetyczne i analityczne (dla poszczególnych dni zadanego zakresu) zestawienie liczby procedur danego rodzaju wykonanych w zadanym okresie, w wybranych/wszystkich gabinetach, dla wybranego/wszystkich ubezpieczycieli i płatników

93. - zestawienie zrealizowanych badań - zestawienie liczby badań wykonanych pacjentom (podstawowe dane pacjenta) wraz z rozpoznaniami i procedurami w wybranej/wszystkich jednostkach, dla wybranych instytucji i jednostek kierujących wykonanych przez wybranego/wszystkich lekarzy

94. - lista zarejestrowanych/przyjętych pacjentów - zestawienie ilości zarejestrowanych pacjentów do wybranego gabinetu

95. - liczba usług wykonanych przez lekarza - zestawienie ilości usług wykonanych 44




w jednostce przez danego lekarza96. - zestawienie liczby przyjętych pacjentów - zestawienie liczby pacjentów

przyjętych przez daną jednostkę i lekarza w ramach określonego pakietu świadczeń z podziałem na grupy wiekowe

97. - lista wykonanych usług - lista usług wraz z danymi takimi jak: jednostka i lekarz kierujący, miejsce i data wykonania, dane o wartości usługi, opłacie kontrahenta, opłacie pacjenta dla wybranych lub wszystkich: umów, pacjentów, świadczeń, instytucji i lekarzy kierujących oraz jednostek i lekarzy wykonujących

98. - zestawienie wystawionych skierowań - syntetyczne i analityczne (wg daty wystawienia) zestawienie ilości wystawionych skierowań na określone badania/usługi z podziałem na lekarzy wystawiających i/lub jednostki, w których wystawiono skierowanie dla wybranych lub wszystkich; jednostek, lekarzy kierujących, usług, statusów realizacji

99. - deklaracje - raport personalny - zestawienie liczby osób zadeklarowanych w wybranym miesiącu danego roku dla wybranej lub wszystkich umów oraz dla wybranego lub wszystkich rodzajów deklaracji

100. - kolejki oczekujących - zestawienie kolejek oczekujących w ujęciu syntetycznym (dane całej kolejki) i analitycznym (z danymi oczekujących pacjentów)

101. - zestawienie wykonanych usług - lista pacjentów z wykonanymi usługami i procedurami oraz z danymi o instytucji, jednostce i lekarzu kierującym dla wybranej jednostki wykonującej w zadanym okresie

102. - zestawienie wykonanych usług pacjenta - lista usług wykonanych w określonym czasie dla wybranego pacjenta z wyszczególnieniem danych o wartości i opłatach

103. - zestawienie udzielonych porad i przyjętych pacjentów - syntetyczne i analityczne (pacjenci) zestawienie liczby udzielonych porad danego rodzaju z podziałem na : miejscowości zamieszkania, pacjenta lub typ porady w zadanym okresie, dla wybranych lub wszystkich gabinetów i wybranego rodzaju wizyty (pierwszorazowa, kolejna)

104. System musi umożliwiać definiowanie wykazów z wykorzystaniem generatora Jasper Reports

G.

Lp. TAB. IV.G. Apteka Spełnianie (TAK/NIE)

1. Obsługa magazynu leków apteki :2. konfiguracja magazynu apteki:

3. - możliwość wykorzystania słowników: leków, grup ATC, nazw międzynarodowych,

4. - możliwość tworzenia nadrzędnych grup leków/materiałów,

5. - możliwość definiowania własnych grup leków (globalnych i lokalnych),




6. - możliwość tworzenia lokalnych słowników leków dla magazynów,

7. - możliwość wyszukiwania leku na podstawie kodu EAN13 lub EAN 128

8. - możliwość definiowania własnych dokumentów (np. rozchód darów, przyjęcie bezpłatnych próbek itp.),

9. - możliwość numerowania dokumentów wg definiowanego wzorca.

10. - możliwość drukowania etykiet na szuflady w magazynie apteki

11. Sporządzanie zamówień doraźnych do dostawców środków farmaceutycznych i materiałów medycznych. Zamówienia mogą być przygotowywane na podstawie aktualnych stanów magazynowych, stanów minimalnych i maksymalnych,

12. Podczas składania zamówienia do dostawcy powinna istnieć możliwość oznaczenia zamawianego leku jako zamiennika do leku będącego przedmiotem zawartej umowy

13. Ewidencja dostaw(przychód):

14. - dostawa od dostawców, z możliwością wprowadzana ich drogą elektroniczną (możliwość rejestrowania również dostaw nie fakturowanych),

15. - możliwość manualnej rejestracji faktur przychodowych

16. - sporządzanie preparatów laboratoryjnych, preparatów galenowych, leków recepturowych oraz płynów infuzyjnych,

17. W dokumencie produkcji leku recepturowego musi być możliwość podglądu składników leku

18. - sporządzanie roztworów spirytusowych,

19. - import docelowy zakładowy i indywidualny,

20. - zwrot z oddziałów z aktualizacją stanów apteczki,

21. - dary.

22. W dokumencie przychodu próbek powinna istnieć możliwość rejestracji danych osoby dostarczającej próbkę oraz nazwę podmiotu odpowiedzialnego.

23. W dokumencie przychodu leku wykorzystywanego w programie badań klinicznych powinna istnieć możliwość uzupełnienia numeru protokołu.

24. Ewidencja dostaw na podstawie kodu EAN13 lub EAN 128. W przypadku braku pozycji o podanym kodzie system powinien uzupełnić dane leku

25. Korekta dokumentów ewidencjonujących dostawy środków farmaceutycznych i materiałów medycznych.

26. Modyfikacja dokumentów dostawy min w zakresie korekty części dostawy

27. System powinien umożliwiać obsługę zleceń z oddziału, w szczególności zleceń 46




na pacjenta leków cytostatycznych28. System musi umożliwić obsługę wydania leku pacjentowi do domu, w ramach

schematu leczenia.29. Ewidencja wydań (rozchodów):

30. - wydawanie na oddziały za pomocą dokumentów RW lub MM na podstawie zamówień elektronicznych lub papierowych (współpraca z apteczką oddziałową),

31. Ewidencja wydań na podstawie kodów EAN13 i EAN 128

32. - możliwość elektronicznego potwierdzenia realizacji zamówienia z oddziału

33. - wydawanie na zewnątrz,

34. - zwrot do dostawców,

35. - korekta zwrotu do dostawców,

36. - ubytki i straty nadzwyczajne,

37. - korekta wydań środków farmaceutycznych,

38. - definiowanie i kontrola limitów wartościowych leków wydawanych do komórek organizacyjnych

39. - prezentacja wartości w postaci ułamkowej

40. Rezerwacja stanów magazynowych

41. Korekta stanów magazynowych:

42. - korekta stanów magazynowych (ilościowa i jakościowa) na podstawie arkusza spisu z natury z dokładnością do dostawy lub asortymentu,

43. - generowanie arkusza do spisu z natury,

44. - bieżąca korekta jakościowa stanu magazynowego,

45. - system sprawdza, czy występują różnice inwentaryzacyjne. W przypadku braku różnic informuje o tym użytkownika.

46. - odnotowanie wstrzymania lub wycofania leku z obrotu,

47. - kontrola dat ważności oraz możliwość zdejmowania ze stanów magazynowych leków przeterminowanych.

48. System musi oznaczać na liście kolorem/symbolem umowy, dla których zbliża się koniec terminu ważność.

49. System w generatorze zamówień do kontrahentów musi umożliwiać tworzenie jednego zamówienia dla wielu umów.




50. System musi umożliwić dopisanie do spisu z natury pozycji, dla których nie odnotowano obrotów w danym magazynie.

51. Przegląd stanów magazynowych bieżących oraz na wybrany dzień.

52. System musi umożliwić weryfikację przekroczenia wartości procentowej limitu ustawionego dla magazynu.

53. Wspieranie obsługi i kontroli zamówień (w tym publicznych):

54. - przekazywanie listy asortymentowo - wartościowej leków do modułu realizującego funkcjonalność Obsługi zamówień i przetargów,

55. - pobieranie zwycięskiej oferty (umowy),

56. - kontrola realizacji dostaw i poziomu cen w ramach zwycięskiej oferty (umowy).

57. System w generatorze zamówień do kontrahentów musi umożliwiać tworzenie jednego zamówienia dla wielu umów.

58. Możliwość współpracy z blistrownicą przepakowującą leki w dawki jednostkowe (unit dose)

59. Prezentowanie informacji o stanie realizacji zlecenia unit dose

60. Obsługa cytostatyków

61. - realizacja zamówienia na produkcję leku cytostatycznego

62. Obsługa żywienia pozajelitowego

63. czynności analityczno-sprawozdawcze:

64. raporty i zestawienia:

65. - na podstawie rozchodów,

66. - na podstawie przychodów,

67. - na podstawie stanów magazynowych,

68. - możliwość wydruku do XLS

69. - raport realizacji zamówień wewnętrznych

70. System musi umożliwiać planowanie realizacji zamówień wewnętrznych.

71. Możliwość przekazywania wszystkich wydruków do plików w formacie PDF

72. Wspomaganie decyzji farmakoterapeutycznych:48




73. - przechowywanie informacji o leku,

74. - wstrzymanie, wycofanie decyzją GIF

75. - odnotowywanie działań niepożądanych.

76. - możliwość definiowania receptariusza szpitalnego

77. Integracja z innymi modułami realizującymi funkcjonalność w zakresie:

78. Finanse – Księgowość:

79. - dostępność funkcji wartościowego, syntetycznego zapisu obrotu materiałowego na kontach księgi głównej FK,

80. - możliwość zapisu dokumentów rozchodowych (koszty) na poziomie wydania z magazynu apteki,

81. - możliwość zapisu dokumentów rozchodowych (koszty) na poziomie wydania z magazynu apteczki oddziałowej,

82. - możliwość eksportu dokumentów rozchodu wewnętrznego w formacie OSOZ-EDI

83. - możliwość elastycznego tworzenia wzorców eksportu do FK,

84. - możliwość wykorzystania słowników FK: kontrahentów, rodzajów kosztów, ośrodków powstawania kosztów.

85. System musi umożliwić rozliczenie dostaw z całego miesiąca jedną fakturą.

86. - w zakresie udostępnienia indeksu leków i danych o aktualnych cenach leków do określenia normatywów materiałowych świadczeń (w zakresie leków).

87. System musi umożliwić domyślne otwarcie nowego okresu rozliczeniowego z pierwszym dniem nowego miesiąca.

88. Ruch Chorych, Przychodnia:

89. - w zakresie skorowidza pacjentów.

90. System musi umożliwiać definiowanie zamienników dla wybranych leków

91. W systemie musi być możliwość przypisania leku do grupy odpowiedników/zamienników

92. System umożliwia obsługę magazynu depozytów w szczególności:

93. - konfigurację magazynu depozytów obejmującą możliwość definiowania dokumentu oraz możliwość oraz karty materiału depozytowego

94. - obsługę dokumentów:




95. -- przyjęcie materiałów w depozyt

96. -- faktura depozytowa

97. -- korekta faktury depozytowej

98. -- rozchód depozytowy na pacjenta

99. -- rozchód depozytowy bez pacjenta

100. -- korekta rozchodu depozytowego

101. - zamówienia do dostawcy:

102. -- generowanie zamówienia na podstawie rozchodu depozytowego

103. -- tworzenie zamówienia depozytowego bez wskazania pacjenta

104. - Kontrola realizacji zamówień do dostawców oraz umów przetargowych.

105. - wprowadzanie i edycja numeru pozycji na fakturze depozytowej

106. - Raporty:

107. -- na podstawie przychodów

108. -- na podstawie rozchodów

109. -- raport z produkcji cytostatyków

110. -- możliwość zapisu w formacie xls

111. - eksport do Systemu Finansowo Księgowego

112. - możliwość przeglądu historii eksportów do FK

113. - możliwość przeglądu historii eksportów VAT do FK

114. - zapewnienie komunikacji w zakresie JPK, w szczególności:

115. -- przygotowanie i wysłanie komunikatu JPK_MAG

116. -- odbiór potwierdzenia odbioru (UPO)

117. System musi umożliwiać integrację z szafami lekowymi.50




118. System musi umożliwiać powiązanie magazynu z szafami lekowymi.

119. System musi umożliwiać przeglądanie decyzji i komunikatów Głównego Inspektoratu Farmaceutycznego

120. Powiadomienie o nowym zamówieniu z Apteczek Oddziałowych

H.

Lp. TAB. IV.H. Apteczka oddziałowa Spełnianie (TAK/NIE)

1. Moduł apteczki musi umożliwić generowanie zamówień do apteki głównej, z uwzględnieniem:

2. - wglądu w stany magazynowe Apteki

3. - kontroli interakcji pomiędzy składnikami leków z zamówienia

4. System musi umożliwiać obsługę magazynu apteczki oddziałowej w zakresie:

5. - wydawania środków farmaceutycznych z apteczki oddziałowej, w szczególności:

6. -- wydawanie na oddział/pacjenta (współpraca z aplikacjami medycznymi np. Ruch Chorych, Przychodnia),

7. -- zwrotu do apteki,

8. -- rejestracji ubytków i strat nadzwyczajnych,

9. -- korekty wydań środków farmaceutycznych.

10. - korekty stanów magazynowych, w szczególności:

11. -- korekty stanów magazynowych (ilościowej i jakościowej) na podstawie arkusza spisu z natury,

12. -- generowanie arkusza do spisu z natury,

13. -- bieżąca korekta jakościowa stanu magazynowego.

14. Musi istnieć możliwość definiowania receptariusza oddziałowego

15. System musi umożliwić podpowiadanie ilości leków podczas dodawania ich do zamówienia wewnętrznego

16. System musi umożliwiać oznaczenie zamówienia wewnętrznego jako pilne.

17. System musi umożliwiać obsługę apteczek pacjentów (leki własne pacjenta)



I.

Lp. TAB. IV.I Gabinet Spełnianie (TAK/NIE)

1. Obsługa wizyty2. Podczas przyjęcia pacjenta skierowanego z innej jednostki np. oddział, jeśli nie

został wskazany inny płatnik lub cennik, system powinien podpowiadać płatnika NFZ

3. System musi umożliwiać dostęp do listy pacjentów zarejestrowanych do gabinetu

4. System musi informować o uprawnieniach pacjenta do obsługi poza kolejnością5. System musi informować o przyjęciu pacjenta na wizytę przed zaplanowanym

terminem, z możliwością rejestracji pilnych konsultacji, także w dniu zgłoszenia pacjentki

6. System powinien prezentować liczbę punktów zrealizowanych, w bieżącym dniu i miesiącu, przez zalogowanego lekarza z podziałem na umowy

7. System musi umożliwiać prezentację wizyt wymagających zafakturowania.8. System powinien umożliwiać rejestrację faktu rozpoczęcia obsługi wizyty

pacjenta w gabinecie (przyjęcie)9. System musi umożliwić przegląd danych pacjenta, co najmniej, w następujących

kategoriach:10. - dane osobowe,11. - dane medyczne pacjenta tj. grupa krwi, uczulenia, choroby przewlekłe,

szczepienia, nazwisko lekarza rodzinnego12. - uprawnienia z tytułu umów,13. - informacja o stopniu ubezpieczenia - weryfikacja z eWUŚ14. - historia leczenia (dane ze wszystkich wizyt i pobytów szpitalnych i

ambulatoryjnych pacjenta), widoczna na jednym ekranie (bez konieczności szukania w systemie)

15. - wyniki badań,16. - przegląd rezerwacji historycznych i planowanych w przyszłości 17. System musi umożliwiać ewidencję uczuleń pacjenta z podziałem na: leki,

pokarmowe i inne. Podczas wprowadzania recepty, zlecenia lub podania leku, system na podstawie ewidencji uczuleń pacjenta musi infomować o uczuleniach pacjenta na substancje czynne.

18. System musi umożliwiać gromadzenie danych o lekach stale przyjmowanych przez pacjenta m.in. w zakresie- nazwa leku -okres przyjmowania leku-dawkowanie-rozpoznanie-źródło informacji

19. Obsługa wizyty powinna obejmować przegląd, modyfikację i rejestrację danych w następujących kategoriach:

20. - obsługa wizyt receptowych. Dla wizyt receptowych system powinien sprawdzać ile czasu upłynęło od ostatniej wizyty tego typu

21. - wywiad (na formularzu zdefiniowanym dla wizyty), 22. - opis badania (na formularzu zdefiniowanym dla wizyty),




23. - informacje ze skierowania,24. - kontrola daty ważności skierowania25. - możliwość przepisania skierowania już zarejestrowanego26. - skierowania, z możliwością skopiowania danych z innego pobytu w tej lub

innej jednostce27. - zlecanie badań diagnostycznych i laboratoryjnych , konsultacji, zabiegów,28. - możliwość wykorzystania szablonów zleceń złożonych, paneli badań do

zlecania29. - usługi, świadczenia w ramach wizyty,30. - rozpoznanie (główne, dodatkowe),31. - kopiowanie wyników badania i danych wypisowych z zleconych podczas

poprzednich wizyt32. - zalecenia z wizyty (w tym zwolnienia lekarskie),33. System musi umożliwiać wystawianie druków i formularzy:34. - zaświadczenie lekarski potwierdzające pozostawanie kobiety pod opieką

medyczną nie później niż od 10 tygodnia ciąży do porodu35. - uniwersalny druk zaświadczenia lekarskiego36. - formularze zgody na zabiegi ambulatoryjne (5)37. - karta zabiegu ambulatoryjnego (5)38. - skierowanie do pracowni usg – druk wewnętrzny39. - skierowanie na badanie zewnętrzne40. - skierowanie na planowy zapis KTG41. - skierowanie do poradni specjalistycznej42. - skierowanie do pracowni diagnostycznej43. - skierowanie do szpitala44. - opis kolposkopii45. Karta śródciążowego podania immunoglobuliny anty-D46. Zaświadczenie o przeprowadzonym lekarskim badaniu kwalifikacyjnym –

ankieta do szczepienia p-HPV (komercja)47. Wizyta ciężarnej w Poradni Cukrzycowej48. Wizyta ciężarnej w Poradni Ciąży Mnogiej49. Wizyta w Poradni Leczenia Niepłodności50. Karta podstawowych danych z wywiadu pacjentki ginekologicznej UCZKiN51. System musi umożliwiać import danych o podmiotach leczniczych i praktykach

lekarskich z Rejestru Podmiotów Wykonujących Działalność Leczniczą. Zaimportowane dane powinny być możliwe do wykorzystania podczas ewidencji danych skierowania.

52. System umożliwia ewidencje opieki położnych w ramach wizyty w gabinecie lekarskim.

53. System powinien umożliwiać zmianę usługi głównej wizyty54. System musi umożliwiać zarejestrowanie wizyty w innym gabinecie z poziomu

obecnie realizowanej wizyty.




55. System musi umożliwiać przejście do kolejnej wizyty z wyszukanej listy wizyt pacjentów, bez konieczności powrotu na listę pacjentów gabinetu.

56. System powinien informować o zleceniach wykonanych po zakończeniu poprzedniej wizyty i umożliwić rozliczenie ich w wizycie aktualnej

57. System umożliwia zdefiniowanie wymagalności zaplanowania terminu pacjenta podczas wysyłania zleceń.

58. System musi umożliwiać ewidencję danych ciąży pacjentki, szczególnie istotnych w przypadku wykonywania świadczeń medycznych inaczej wycenianych przez NFZ dla pacjentek ciężarnych i będących w połogu.

59. Wystawianie recept60. System powinien wspierać wystawianie recept, co najmniej w zakresie:61. - możliwości wybrania leków ze słownika leków,62. - możliwości sprawdzenia interakcji poszczególnych leków oraz podpowiadanie

stopnia refundacji na podstawie weryfikacji z eWUŚ63. -możliwość określenia płatnika na wydruku czystej recepty64. - możliwości wydruku recepty (z rozmieszczaniem i nadrukiem na formularzach

recept),65. - na wydruku leki powinny być prezentowane w kolejności zgodnej z

kolejnością wpisywania66. - system powinien podpowiadać dane osoby zalogowanej, jako wystawiającej

receptę o ile osoba ta jest lekarze. Jeśli zalogowany użytkownik nie jest lekarzem, system powinien podpowiadać lekarz realizujący wizytę

67. - podpowiadanie ilości i jednostki, w jakich powinien zostać wydany lek68. - na recepcie na leki narkotyczne system powinien podpowiadać ilość

substancji narkotycznej69. - grupowe dodawanie leków na receptę70. - kopiowanie recept z poprzednich wizyt z weryfikacją poziomu refundacji wg

aktualnych danych ze słownika BAZYL lub słownika leków własnych71. - kopiowanie recept musi umożliwiać wybór recepty do skopiowania spośród:72. -- recept z poprzedniego pobytu w tym gabinecie73. -- recept z wizyty takiej jak aktualna (ta sama usługa), niezależnie od gabinetu

w jakim się odbywała74. -- z innych pobytów w tej samej jednostce75. - kopiowanie leków przepisanych na wcześniej wystawionych receptach76. - możliwości pomijania leków oznaczonych jako "wycofane" w słowniku BAZYL77. - możliwości wydruku recept tylko z puli lekarza zalogowanego78. - ponowny wydruk recepty już wydrukowanej powinien spowodować

utworzenie kopii recepty, dotyczy to również recept drukowanych w trybie nadruku na gotowych drukach

79. - oznaczenie wydrukowanej recepty jako anulowanej80. - system kontroluje przekroczenie minimalnej puli recept uwzględniając typ

recepty RP/RPW81. - system musi umożliwiać zawężanie pozycji słownika leków do leków

zarejestrowanych jako stale przyjmowane przez pacjenta, któremu tworzona




jest recepta.82. System musi umożliwiać podpowiadanie na recepcie płatnika oraz stopnia

refundacji na podstawie weryfikacji eWUŚ.83. Musi istnieć możliwość importu recept w formacie XMZ84. Musi istnieć możliwość wystawiania recept transgranicznych85. System musi umożliwić ustawienie domyślnego dawkowania dla leku.86. System musi umożliwić podpowiadanie wskazań dla leku podczas dodawania

lub kopiowania recepty.87. System musi umożliwić wystawienie recept dla pacjentów powyżej 75 roku

życia.88. System musi umożliwiać rozszerzenie rejestru leków stale przyjmowanych przez

pacjenta na podstawie utworzonej recepty. 89. System musi umożliwiać zbiorczy wydruk zaleceń dla wszystkich recept pacjenta

w ramach danego pobytu.90. W przypadku wystawienia pacjentowi wielu recept, system musi umożliwić ich

jednoczesny wydruk91. System musi umożliwiać wydruk recept pełnopłatnych bez nadanego numeru,

w przypadku braku wolnych numerów w puli użytkownika.92. Dokumentacja wizyty93. System musi umożliwiać wystawienie skierowania,94. System musi umożliwiać wystawienie skierowania na zewnątrz: do poradni

specjalistycznej (leczenie), do poradni specjalistycznej (konsultacja), , do szpitala, na rehabilitację, na zabieg ambulatoryjny, na badanie diagnostyczne, na badanie laboratoryjne.

95. Skierowanie do jednostki zewnętrznej, dla pacjenta niepełnoletniego, powinno zawierać imię i nazwisko oraz adres opiekuna

96. - leki podane podczas wizyty (współpraca z apteczką oddziałową), 97. - ewidencja szczepień:98. - możliwość oznaczenia podania leku jako szczepienia, 99. - możliwość wpisania przy podaniu leku danych charakteryzujących szczepienie,100. - automatyczny wpis do karty szczepień po oznaczeniu podania leku jako

szczepienia.101. - wykonane podczas wizyty dodatkowych usług i badania

102. - inne dokumenty (zaświadczenia, druki, na formularzach zdefiniowanych dla wizyty).

103. możliwość stosowania słownika tekstów standardowych do opisu danych wizyt

104. Możliwość stosowania „pozycji preferowanych” dla użytkowników, jednostek organizacyjnych (wyróżnienie najczęściej wykorzystywanych pozycji słowników).

105. obsługa zakończenia wizyty:

106. - autoryzacja medyczna wizyty,




107. - automatyczne tworzenie karty wizyty.

108. - możliwość bezpośredniego skierowania na IP

109. Kwalifikacja rozliczeniowa usług i świadczeń.

110. - wiązanie rozliczanych badań do kolejnej zaplanowanej wizyty

111. wgląd w rozliczenia NFZ z tytułu zrealizowanych w trakcie wizyty usług

112. automatyczna aktualizacja i przegląd Księgi Głównej Przychodni

113. System musi umożliwiać obsługę i wydruk dokumentacji zbiorczej tj.:

114. - Księga Oczekujących

115. - Księga Przyjęć



118. - Księga Zabiegów


120. System musi umożliwić podpowiadanie dat w danych pozycji Księgi Ratownictwa

121. System musi umożliwiać wprowadzenie wywiadu przedporodowego w gabinecie lekarskim.

122. System musi umożliwić wydruk pisma powiązanego z elementem leczenia podczas zakończenia wizyty/badania pacjenta.

123. System musi umożliwiać rejestrowanie treści głosowych w zastępstwie opisów tekstowych.

124. System musi umożliwiać odsłuchanie oraz przetwarzanie nagranych notatek głosowych przez operatora na tekst, prezentowany w miejscu dodania notatki.

125. System musi umożliwiać rozpoczęcie/wstrzymanie nagrywania oraz odsłuch i usunięcie nagranej notatki głosowej.

126. System musi umożliwić oznaczenie notatki głosowej jako pilnej.

127. System musi umożliwiać operatorowi przegląd w jednym oknie wszystkich notatek głosowych zarejestrowanych w ramach wybranej jednostki organizacyjnej.

128. Konfiguracja pracy gabinetu




129. System musi pozwalać na dostosowanie modułu do specyfiki gabinetu lekarskiego co najmniej w zakresie:

130. - możliwości zdefiniowania wzorców dokumentacji dedykowanej dla gabinetu

131. - możliwości zdefiniowania elementów menu (zakładek) w zależności od potrzeb i rodzaju usługi

132. - możliwość wykorzystania, zdefiniowanych wcześniej, wzorów dokumentów

133. System musi umożliwiać tworzenie raportów i wykazów pracy gabinetu

J.

Lp. TAB. IV.J. Rejestracja Spełnianie (TAK/NIE)

1. System musi umożliwiać określanie definiowanie dostępności usług placówki medycznej

2. System musi umożliwiać wybór kategorii płatnika oraz wystawienie dokumentu sprzedaży dla badania laboratoryjnego.

3. Definiowanie grafików pracy

4. System musi umożliwiać określanie dostępności zasobów w placówce (grafiki) dla gabinetów:

5. - określenie szablonu dla każdego z dni tygodnia,

6. - określenie czasu pracy,

7. - określenie zakresu realizowanych usług

8. System musi umożliwiać definiowanie szablonu pracy lekarza:

9. - określenie szablonu dla każdego z dni tygodnia,

10. - określenie czasu pracy,

11. - określenie gabinetu, w którym wykonywane są usługi (miejsce wykonania).

12. System musi umożliwiać definiowanie przedziału wieku pacjentów obsługiwanych przez zasób

13. System musi umożliwiać generowanie grafików dla lekarzy w powiązaniu z gabinetami w zadanym okresie czasu,

14. System musi umożliwiać ustawienie blokady w grafiku z podaniem przyczyny tj. urlop, remont

15. Obsługa skorowidza pacjentów




16. System musi umożliwiać przypisanie pacjentowi uprawnień do obsługi poza kolejnością

17. Informacja o posiadanych uprawnieniach do obsługi poza kolejnością musi być prezentowana na listach pacjentów

18. System musi umożliwiać wyszukiwanie pacjentów, co najmniej, wg kryterium:

19. - imię, nazwisko i PESEL pacjenta

20. - jednostka wykonująca

21. - osoba wykonująca

22. - osoba rejestrująca

23. - jednostka kierująca

24. - instytucja kierująca

25. - lekarz kierujący

26. - kartoteka


28. - świadczenie

29. - status na liście pacjentów (np. do obsłużenia, zaplanowany, zarejestrowany, anulowane, przyjęty/w realizacji)

30. - wizyty CITO

31. - status osoby: cudzoziemiec, VIP, uprawniony do obsługi poza kolejnością

32. - wymagające zafakturowania

33. Planowanie i rezerwacja wizyty pacjenta

34. System musi umożliwiać wyszukiwanie wolnych terminów jednoczesnej dostępności wymaganych zasobów:

35. - rezerwacja wybranego terminu lub „pierwszy wolny”.

36. - wyszukiwanie zasobów spełniających kryterium wieku pacjenta

37. - w przypadku braku wolnych terminów w preferowanych godzinach możliwość rezerwacji pierwszy wolny lub ręczny wybór terminu

38. - rezerwacja terminów dla pacjentów przebywających na oddziale58




39. - wstawianie terminu pomiędzy już istniejące wpisy w grafiku w przypadkach nagłych (dopuszczenie planowania wielu wizyt w tym samym terminie) z możliwością wpisania komentarza do tak zaplanowanej wizyty

40. - przegląd liczby zaplanowanych wizyt z podziałem na pierwszorazowe i kontynuacje leczenia

41. - przegląd terminarza zaplanowanych wizyt

42. - nadanie numeru rezerwacji w ramach rejestracji i jednostki wykonującej (gabinetu)

43. - tworzenie wpisu tymczasowej rezerwacji w terminarzu podczas planowania terminu.

44. System umożliwia ewidencję i usuwanie blokad terminarza bezpośrednio w oknie planowania terminu.

45. System musi umożliwić automatyczne anulowanie zaplanowanego terminu w przypadku jego wcześniejszej realizacji.

46. System musi umożliwiać zmianę usługi na inną wykonywaną w tej samej jednostce wykonującej, podczas przeplanowywania terminu.

47. System musi umożliwiać obsługa kolejek oczekujących zgodnie z obowiązującymi przepisami

48. Podczas planowania wizyty, system powinien sugerować dokonanie wpisu do kolejki oczekujących jeśli istnieje kolejka dla planowanej usługi lub gabinetu

49. System musi umożliwić wskazanie przyczyny skreślenia pacjenta z kolejki oczekujących podczas przeniesienia terminu.

50. System musi zapewnić możliwość sprawdzenia czy dla wybranego pacjenta istnieją inne wpisy w księdze oczekujących.


52. System musi umożliwić ograniczenie widoczności danych wrażliwych za pomocą uprawnień.

53. System musi umożliwić ewidencję notatek w terminarzu.

54. System musi umożliwić zbiorczą generację notatek w terminarzu.

55. Rejestracja na wizytę (usługę)

56. System musi umożliwić rejestrację pacjenta na wizytę (zaplanowaną w terminarzu i niezaplanowaną)

57. System musi umożliwiać rejstrację wywiadu dla pacjentów z zaplanowaną wizytą

58. System musi pozwalać na określenie miejsca wykonania usługi (wybór gabinetu) dla usług nie podlegających planowaniu i rezerwacji.

59. System musi umożliwiać zlecenie wykonania usługi pacjentowi we wskazanym (lub wynikającym z rezerwacji) miejscu wykonania,

60. System musi umożliwić rejestracje wielu badań w oparciu o jedno skierowanie.59




61. System musi umożliwić ewidencję i kontrolę:

62. - zgód pacjenta związanych z hospitalizacją i innymi czynnościami medycznymi

63. - listy osób upoważnionych dla pacjenta

64. Obsługa wyników:

65. - odnotowanie wydania wyniku,

66. - wpisywanie wyników zewnętrznych.

67. Wydruk recept i kuponów


69. - Księga Przyjęć





74. raporty i wykazy Rejestracji.

K.

Lp. TAB. IV.K Sprzedaż Usług Medycznych Spełnianie (TAK/NIE)

1. Indywidualne konto pacjenta (IKP)2. System musi umożliwiać prowadzenie kont rozrachunkowych pacjentów z

tytułu usług medycznych,3. System musi umożliwić naliczenie na IKP należności przed rozpoczęciem

realizacji usługi płatnej z góry4. System musi umożliwiać wystawienie dokumentu sprzedaży (paragonów,

faktur i faktur korygujących)5. System umożliwia wydruk dokumentu sprzedaży dla opiekuna pacjenta.6. System musi umożliwić zdefiniowanie powodu korekty dokumentu sprzedaży7. System musi umożliwiać automatyczną aktualizację sposobu płatności

dokumentu sprzedaży podczas operacji opłacenia.8. System musi umożliwić realizację wypłaty środków dokumentu sprzedaży.




9. System musi umożliwiać uwzględnianie kwoty odsetek wynikających z wystawionej w systemie Finansowo-Księgowym noty odsetkowej, podczas realizacji opłacenia dokumentu sprzedaży.

10. System musi posiadać możliwość skojarzenia paragonu/faktury ze schematem księgowania w module Finanse-Księgowość,

11. System musi umożliwiać ewidencję płatności mieszanej np. kartą i gotówką.12. System musi umożliwiać wydrukowanie załącznika do faktury, prezentującego

wartościowe zestawienie wykonanych usług.13. Obsługa pacjenta komercyjnego14. Musi istnieć możliwość indywidualnej zmiany ceny usługi dla pacjenta 15. System musi umożliwiać wybór płatnika w ramach kategorii (płatnik NFZ,

umowa komercyjna, pacjent płaci sam)16. Podczas przyjęcia pacjenta musi istnieć możliwość weryfikacji uprawnień do

świadczeń z tytułu umów w których pacjent jest beneficjentem17. Podczas weryfikacji uprawnień do świadczeń system powinien umożliwiać:18. System musi umożliwiać przegląd udostępnionych danych umowy,19. System powinien podczas rejestracji usługi komercyjnej weryfikować

zdefiniowane limity wykonanania usług na poziomie definicji umowy.20. System musi udostępniać informacje o powodzie niedostępności usługi i

ograniczeniach dostępności, 21. System musi umożliwić kopiowanie danych produktu22. Zarządzanie cennikami23. System musi umożliwiać określenie czasu obowiązywania cennika,24. System musi umożliwiać zdefiniowanie godzin dostępności usługi,25. System musi umożliwiać definiowanie cenników standardowych i specjalnych

(np. na dni świąteczne),26. System musi umożliwiać określenie miejsc realizacji usługi,27. System musi umożliwiać drukowanie cenników z podziałem na placówki28. System musi umożliwić podgląd placówek, w których obowiązuje cennik29. System musi umożliwiać wersjonowanie cenników 30. System musi umożliwiać przeglądanie informacji o okresach ważności

wszystkich wersji cennika31. System musi umożliwić przechowywanie historii zmian wartości pozycji cennika

wraz z informacją o okresach obowiązywania32. System musi umożliwić podgląd usuniętych pozycji cennika33. System musi umożliwiać konfigurację grup analitycznych związanych z definicją

cennika.34. System musi pozwalać na wprowadzanie rabatów:35. - ogólnych, do wykorzystania bez ograniczeń,36. - prywatnych, przyporządkowane do osoby,37. - dla placówki,38. System musi umożliwiać konstruowanie produktów (szablonów do

wykorzystania w umowach) w zakresie, co najmniej:39. - wprowadzania danych podstawowych produktu,




40. - wprowadzania zakresów usług medycznych w ramach produktu,41. - wprowadzania usług medycznych w ramach zakresu,42. System musi umożliwiać definiowanie trybów i terminów płatności dla

zakresów, co najmniej, w zakresie:43. - abonamentów, (niezależnie od wykonanych usług),44. - FFS (Fee For Service czyli za każde wykonanie usługi),45. - współpłatności w ramach FFS,46. - płatności mieszanych.47. System musi umożliwiać grupowanie zakresów usług (tworzenie

benefitplanów),48. System musi umożliwiać zmianę benefitplanu pacjenta49. System musi umożliwiać wprowadzanie limitów dla zakresów:50. - ilościowych,51. - kwotowych52. System musi umożliwiać obsługę umów na sprzedaż usług medycznych53. System musi umożliwiać ewidencję różnego typu umów, w szczególności:54. - umów ubezpieczeniowych,55. - umów abonamentowych,56. - umów z innymi ZOZ-ami, Indywidualnymi Praktykami Lekarskimi,57. System musi pozwalać na rejestrację umowy indywidualnej (polisy) na

świadczenie usług medycznych wg szablonu.58. System musi pozwalać na formułowanie oferty sprzedaży zamawiającego w

zakresie:59. - wprowadzanie struktury placówek medycznych Zamawiającego,60. - wprowadzania listy usług (oferta jednostek organizacyjnych),61. - wprowadzenie danych usługi tj.:62. -- wymagalność skierowania,63. -- warunki dostępności,64. wprowadzanie danych podstawowych umowy,65. przypisywanie produktu do umowy,66. definiowanie rabatów dla umowy,67. wprowadzanie list uprawnionych do grup zakresów (benefitplanów):68. - beneficjenci,69. - subbeneficjenci.70. import listy beneficjentów z pliku,71. tworzenie produktu dedykowanego dla umowy (wyodrębnienie umowy z

szablonu produktu),72. definiowanie wzorów faktur i załączników do faktur dla umowy,73. System musi umożliwiać zawarcie przekodowań w umowach umożliwiających

posługiwanie się kodami usług Zamawiającego i kontrahenta74. Wskazanie domyślnego numeru konta drukowanego na fakturach75. rozliczenia umów:76. - generowanie harmonogramów płatności umowy w oparciu o dane zakresów

umowy,




77. - generowanie faktur i załączników do faktur płatnych abonamentowo w oparciu o zdefiniowane wzorce i dane umowy,

78. - generowanie faktur i załączników do faktur płatnych za wykonanie w oparciu o zdefiniowane wzorce i dane umowy oraz dane o wykonanych usługach.

79. Możliwość automatycznego wyznaczania krotności usługi na podstawie liczby osobodni:

80. - z uwzględnieniem ostatniego dnia pobytu81. - bez ostatniego dnia pobytu82. Możliwość automatycznego wyznaczania wartości usługi na podstawie wartości

przypisanych leków do pacjenta83. Automatyczne powiadamianie w procesie rejestracji i przyjęcia do gabinetu o

ujemnym saldzie pacjenta (niedopłata)

L.

Lp. TAB. IV.L. Zlecenia Spełnianie (TAK/NIE)

1. Zlecanie leków:

2. System musi umożliwiać planowanie i zlecanie leków w powiązaniu z modułem Apteczki Oddziałowej

3. System musi umożliwiać kopiowanie zleceń leków z poprzednich pobytów lub hospitalizacji

4. System musi umożliwiać zakończenie wybranych zleceń leków.

5. System musi pozwalać na zlecanie leków wg nazwy handlowej i międzynarodowej

6. System musi umożliwiać zlecanie podań leków o określonych porach oraz co określony czas, od pierwszego podania co X godzin i Y minut

7. System musi pozwalać na wyróżnianie kolorem zleceń leków zlecanych z innych magazynów

8. Podczas zlecenia leków system powinien umożliwiać:

9. - podgląd karty leków

10. - kontrolę interakcji pomiędzy zleconymi lekami

11. - podgląd całej historii leczenia pacjenta

12. Podczas zlecania antybiotyku system powinien wymagać określenie rodzaju antybiotykoterapii: celowana, empiryczna, profilaktyka, WRZ

13. System powinien umożliwiać prezentację i wydruk indywidualnej karty zleceń podań leków

14. Musi istnieć możliwość zlecania leków:

15. - recepturowych63




16. - chemioterapii

17. - zlecenie chemioterapii z wykorzystaniem schematów leczenia (również do domu)

18. - pomp infuzyjnych

19. - możliwość określenia drogi podania leków

20. System musi umożliwić wydruk indywidualnej karty zleceń chemioterapii pacjenta

21. System musi umożliwić kontynuowanie podania leków będących antybiotykami.

22. System musi umożliwić zdefiniowanie listy leków dopuszczonych do podania bez zlecenia.

23. System musi umożliwiać weryfikację czy lek znajduje się na liście leków dopuszczonych do podania bez zlecenia.

24. System musi umożliwiać grupowe zarejestrowanie przyczyny niepodania dla wybranych leków.

25. Musi istnieć możliwość wydruku tacy leków z podaniem nazwiska osoby drukującej i czasu wydruku

26. Na tacy leków musi być drukowana informacja, dla każdego pacjenta, zleconym o leku, godzinie podania, dawce i drodze podania

27. Podczas realizacji zlecenia leku system powinien umożliwiać zastosowanie zamienników do zleconego leku

28. Podczas odnotowania podania leku system powinien umożliwiać wybór serii leku

29. System powinien umożliwiać realizację podań leków z wykorzystaniem kodów kreskowych

30. System powinien umożliwić grupowanie zleceń podania leków wg drogi podania

31. System musi umożliwić graficzne oznaczenie zleceń wymagających potwierdzenia rozpoczęcia lub kontynuacji.

32. System musi umożliwić użytkownikowi analizę porównawczą zmian zleceń leków dla pacjenta.

33. System musi umożliwić kopiowanie anulowanych zleceń leków z poprzedniego pobytu/hospitalizacji pacjenta.

34. System musi umożliwić obsługę wydań leków do domu.

35. System musi umożliwić potwierdzenie przez lekarza każdego podania leku.

36. System musi umożliwiać automatyczną zmianę godzin podań leków w przypadku zmiany godziny pierwszego podania.

37. System musi prezentować informację o ilości podań w ciągu doby dla leków doraźnych.




38. System podczas ewidencji zleceń leków umożliwia wprowadzenie leków wstrzymanych dla pacjenta.

39. Zlecanie badań

40. Dla pobytów oznaczonych „zagrożenie życia lub zdrowia” wszystkie zlecenia powinny być opatrzone statusem PILNE

41. System musi umożliwić planowanie i zlecanie badań diagnostycznych i laboratoryjnych, zabiegów, konsultacji przekazywanych z jednostek Zamawiającego, w tym:

42. - z Oddziału do: Pracowni Patomorfologicznej, Pracowni Diagnostycznej, Przychodni, Bloku operacyjnego, innego Oddziału, Gabinetu lekarskiego, Laboratorium

43. System powinien umożliwiać zlecanie wielu różnych badań w jednym miejscu, opatrzony wspólnym nagłówkiem i komentarzem

44. System powinien podpowiadać, na zleceniu, rozpoznania zasadniczego a w przypadku jego braku rozpoznania wstępnego

45. Możliwość utworzenia zlecenia laboratoryjnego z wykorzystaniem predefiniowanej karty kodów kreskowych

46. Dla zleceń laboratoryjnych musi istnieć możliwość odnotowania informacji o pobranym materiale dla pojedynczego badania lub zestawu badań

47. Dla zleceń laboratoryjnych musi istnieć możliwość określenia planowanej godziny wykonania badania. System powinien podpowiadać domyślne godziny pobrań materiałów

48. Dla zleceń do pracowni histopatologii powinny być widoczny numer SIMP, o ile badanie dotyczy cytologii ginekologicznej

49. W przypadku anulowania zlecenia, powód anulowania powinien być widoczny przy zleceniu

50. System musi umożliwiać planowanie i zlecanie badań i konsultacji w ramach zleceń zewnętrznych (z innych podmiotów)

51. System musi zapewnić możliwość definiowania zleceń złożonych:

52. - kompleksowych,

53. - panelowych,

54. - cyklicznych.

55. System powinien umożliwiać zapisanie zleconych badań jako panelu zleceń do wykorzystania w późniejszym terminie

56. Powinna istnieć możliwość przepisania opisu zlecenia z poprzedniego zlecenia

57. Powinna istnieć możliwość dwuetapowego wprowadzania zlecenia (wpisanie oraz potwierdzenia),

58. System musi umożliwiać powtarzanie zleceń co określony interwał czasu




59. System musi umożliwiać przegląd zleceń według ustalonych przez użytkownika kryteriów:

60. - dla pacjenta,

61. - typu zlecenia (laboratoryjne, diagnostyczne, podanie leku),

62. - okresu.

63. System musi umożliwiać wycofanie anulowanych zleceń i umożliwić jego ponowne wysłanie do jednostki wykonującej

64. Po wystawieniu zlecenia powinna istnieć możliwość zmiany jednostki, która zostanie obciążona kosztami realizacji zleconego badania.

65. System musi umożliwiać wydruki zleceń, w tym:

66. - dzienne zestawienie leków dla pacjenta,

67. - dzienne zestawienie badań do wykonania.

68. Musi istnieć możliwość wydruku wszystkich wyników pacjenta z bieżącej hospitalizacji lub ze wszystkich pobytów w szpitalu,

69. System musi umożliwiać przegląd wszystkich zleceń z jednostki zlecającej z możliwością wydruku wyniku wykonanego badania,

70. System musi umożliwić oznaczenie wyniku jako przeczytany.

71. System musi umożliwić wyszukiwanie wyników nieoznaczonych jako przeczytane.

72. Musi istnieć możliwość definiowania szablonów dokumentów skojarzonych z wprowadzanym zleceniem.

73. System musi zapewnić możliwość wyświetlania wyników w układzie tabelarycznym z możliwością śledzenia zmian wyników i zmiany kolejności porównywanych parametrów (np. w wyniku morfologii)

74. System musi zapewnić możliwość przeglądania wyników liczbowych w postaci graficznej (badanie trendu)

75. System musi umożliwić konfigurowanie list prezentowanych leków i procedur medycznych na wykresie wyników graficznych.

76. System musi umożliwić zaznaczenie wielu pozycji na liście zleceń, w celu grupowego przypisania/odpięcia wykonania.

77. System musi umożliwić graficzną prezentację wyników badań z uwzględnieniem, na osi czasu, podanych leków i wykonanych procedur

78. Podczas przeglądania wyników badan powinno być widoczne informacje o osobach realizujących badanie

M.

Lp. TAB. IV. M. Blok operacyjny Spełnianie (TAK/NIE)

1. Blok operacyjny66




2. System powinien umożliwiać wyłączanie niewykorzystanych zakładek

3. System powinien umożliwiać zmianę kolejności prezentacji zakładek

4. System powinien umożliwiać planowanie zabiegów operacyjnych dla pacjentów przebywających na oddziale

5. System powinien umożliwiać planowanie zabiegów operacyjnych podczas wizyty w gabinecie lekarskim, pacjentom nie przebywającym w szpitalu

6. System musi umożliwić jednoznaczne oznaczanie zabiegów:

7. -zaplanowanych i niewykonanych;

8. - niezakończonych;

9. -anulowanych

10. System powinien umożliwiać planowanie zabiegów dla pacjentów kierowanych na zabieg z innych jednostek

11. System musi umożliwiać dokonanie klasyfikacji lekarskiej (chirurgicznej) do zabiegu obejmującej, co najmniej:

12. - rodzaj planowanego zabiegu,

13. - tryb zabiegu (planowy, przyspieszony, pilny, natychmiastowy),

14. - rozpoznanie przedoperacyjne ICD9 oraz opisowe,

15. - dostęp do pola operacyjnego z wykorzystaniem definiowalnego słownika,

16. - wymagane ułożenie pacjenta z wykorzystaniem definiowalnego słownika, z możliwością wyboru wielu pozycji ,

17. - datę kwalifikacji,

18. - wskazanie, ze słownika personelu, lekarza dokonujący kwalifikacji,

19. - możliwość załączenia formularza definiowanego przez użytkownika,

20. Musi istnieć możliwość rejestracji danych kwalifikacji z poziomu oddziału i z poziomu bloku operacyjnego

21. Musi istnieć możliwość uproszczonego zlecania zabiegów przeprowadzanych w trybie nagłym

22. System musi umożliwić zaplanowanie przerw technicznych pomiędzy zabiegami (czas na przygotowanie i posprzątanie Sali)

23. System musi umożliwić prezentowanie na planie dziennym i okresowym operacji, informacji o tym czy pacjent przebywa już w szpitalu oraz czy wykonana została




kwalifikacja anestezjologiczna.24. System musi umożliwić skonfigurowanie kontroli limitów wykonań dla

zdefiniowanych grup zabiegów operacyjnych.25. System musi umożliwiać dokonanie klasyfikacji anestezjologicznej, co najmniej w

zakresie odnotowania:26. - rodzaju planowanego znieczulenia z wykorzystaniem słownika rodzajów

znieczulenia z możliwością definiowania własnych rodzajów znieczulenia,27. - klasyfikacji pacjenta wg skali ASA,

28. - opisu kwalifikacji,

29. - daty kwalifikacji,

30. - wskazania lekarza dokonującego kwalifikacji,

31. - możliwości rejestracji danych kwalifikacji z poziomu oddziału i z poziomu bloku operacyjnego

32. System musi umożliwić planowanie zabiegu operacyjnego w tym wpisanie:

33. - daty zabiegu, bloku operacyjnego i sali operacyjnej,

34. - planowanie powinno się odbywać w oparciu o terminarze bloku i sal operacyjnych

35. - po rejestracji zakończenia zabiegu, jeśli jego czas trwania był inny niż zaplanowano, system powinien zaktualizować terminarz dla pozostałych, zaplanowanych zabiegów

36. - materiałów,

37. - składu zespołu zabiegowego i anestezjologicznego z wykorzystaniem słownika personelu z możliwością określenia definiowania roli członków personelu,

38. - możliwość rejestracji danych planu z poziomu oddziału i z poziomu bloku operacyjnego

39. System musi umożliwić odnotowanie rozpoczęcia realizacji zabiegu operacyjnego w chwili zarejestrowania przyjęcia pacjenta na blok operacyjny.

40. Musi istnieć możliwość obsługi listy zabiegów bloku operacyjnego, obejmującej:

41. - dostęp do aktualnych i archiwalnych danych pacjentów.

42. - modyfikacja danych pacjentów,

43. System musi umożliwiać wyszukiwanie zabiegów na liście zabiegów wg różnych kryteriów, w tym:

44. - statusu zabiegu (planowany, w trakcie realizacji, opieka pooperacyjna, przekazany na oddział, anulowany),

45. - danych pacjenta (nazwisko, imię, PESEL),68




46. - identyfikatorze pacjenta

47. - tryb zabiegu,

48. - rodzaj zabiegu,

49. - planowanych i rzeczywistych dat wykonania zabiegu,

50. - bloku i sali operacyjnej,

51. - jednostki zlecającej,

52. - numeru księgi zabiegów,

53. - składu zespołu operacyjnego (operatora, pielęgniarski operacyjnej, anestezjologa, pielęgniarki anestezjologiczna).

54. - przeglądu zabiegów zaplanowanych na dzisiaj i/lub jutro

55. System musi umożliwiać przyjęcie pacjenta na blok operacyjny i odnotowanie związanych z tym danych tj.:

56. - czas przyjęcia i osoby przyjmującej,

57. - wpis do Księgi Bloku operacyjnego

58. System musi umożliwić odnotowanie danych medycznych przeprowadzonego zabiegu w tym:

59. - rodzaju wykonanego zabiegu,

60. - czasu trwania zabiegu,

61. - rozpoznania pooperacyjnego ICD9 i opisowego,

62. - procedur medycznych z możliwością automatycznego dodania procedur powiązanych z przeprowadzonym zabiegiem,

63. - opisu wykonanego zabiegu wraz z lekarzem opisującym,

64. - składu zespołu zabiegowego domyślnie uzupełnianego na podstawie planu,

65. - czasu pracy zespołu operacyjnego. Jeśli czas pracy nie zostanie wpisany powinien być uzupełniony przez system na podstawie czasu rozpoczęcia i zakończenia zabiegu

66. - możliwość załączenia formularza definiowanego przez użytkownika,

67. - możliwość dołączania załączników w postaci dowolnych plików (np. skany 69




dokumentów, pliki dźwiękowe i wideo),68. - odnotowanie przetoczeń krwi i preparatów krwiopochodnych z wpisem do księgi

transfuzyjnej, odnotowanie powikłań po przetoczeniu,69. - zużytych materiałów:

70. -- z wykorzystaniem kodów kreskowych lub poprzez manualny wybór pozycji ze słownika,

71. -- z możliwością automatycznego dodania materiałów z planu,

72. -- z możliwością automatycznego dodania materiałów powiązanych z wykonanym zabiegiem,

73. -- z możliwością automatycznego dodania zestawu narzędzi powiązanych z wykonywanym zabiegiem

74. - możliwość rejestracji danych z poziomu oddziału i z poziomu bloku operacyjnego

75. Po wykonaniu zabiegu, system powinien umożliwiać zmianę procedury głównej zabiegu

76. Jeśli nie zostały wpisane dane lekarza operującego to system powinien podpowiadać operatora na podstawie danych lekarza opisującego zabieg

77. System musi umożliwić wprowadzenie informacji dotyczących przygotowania pacjenta do zabiegu.

78. System musi umożliwiać wprowadzenie informacji dotyczących powikłań pooperacyjnych.

79. System musi umożliwiać wprowadzenie w ramach opieki pooperacyjnej pacjenta, danych opieki pielęgniarskiej.

80. System musi umożliwić definicję rodzajów znieczulenia.

81. System musi umożliwić rejestrację danych znieczulenia, w tym:

82. - czasu znieczulenia,

83. - czasu anestezjologicznego,

84. - rodzaju przeprowadzonego znieczulenia domyślnie wypełnianego na podstawie kwalifikacji z możliwością edycji,

85. - opisu znieczulenia ze wskazaniem osoby opisującej,

86. - zespołu anestezjologicznego domyślnie uzupełnionego na podstawie planu,

87. - czasu pracy zespołu anestezjologicznego. Jeśli czas pracy nie został wpisany system podpowiada na podstawie czasu anestezjologicznego lub, w przypadku braku, czasu pobytu na bloku

88. - podanych leków:

89. -- z wykorzystaniem kodów kreskowych lub poprzez manualny wybór pozycji ze 70




słownika,90. -- z możliwością automatycznego dodania leków powiązanych z wykonanym

zabiegiem91. System musi wspomagać opiekę pooperacyjną w zakresie:

92. - ewidencji czasu trwania opieki pooperacyjnej oraz lekarza przyjmującego,

93. - ewidencji wykonanych procedur,

94. - ewidencji podanych leków i zużytych materiałów,

95. - obsługi tacy leków

96. - oceny stanu pacjenta z wykorzystaniem zmodyfikowanej skali Aldrete'a

97. - opisu powikłań znieczulenia,

98. - opisu zaleceń pooperacyjnych,

99. - ewidencji daty przekazania pacjenta na oddział wraz ze wskazaniem lekarza przekazującego.

100. System musi umożliwiać graficzną prezentację podań leków na wydruku karty anestezjologicznej

101. System musi umożliwiać prowadzenie Księgi Bloku Operacyjnego w zakresie:

102. - możliwość definiowania księgi dla bloku operacyjnego, dla sali operacyjnej oraz dla grupy zabiegów,

103. - przegląd ksiąg bloku operacyjnego wg różnych kryteriów, w tym:

104. -- danych pacjenta (nazwisko, imię, PESEL),

105. -- trybu zabiegu,

106. -- rodzaju zabiegu,

107. -- dat wykonania zabiegu,

108. -- bloku i sali operacyjnej,

109. -- jednostki zlecającej,

110. -- księgi zabiegów,

111. -- roku księgi,




112. -- zakresu numerów księgi,

113. -- składu zespołu operacyjnego (operatora, pielęgniarski operacyjnej, anestezjologa, pielęgniarki anestezjologiczna),

114. - wydruk księgi bloku operacyjnego

115. System musi umożliwić przekazanie pacjenta na oddział opieki pooperacyjnej bez wprowadzonych danych realizacji zabiegu; z możliwością późniejszego uzupełnienia danych.

116. System musi wspomagać prowadzenie dokumentacji zabiegu operacyjnego, w tym:

117. - protokół z zabiegu operacyjnego,

118. - protokół przekazania pacjenta na oddział

119. - możliwość uzupełniania dokumentacji o materiały elektroniczne - skany dokumentów, zdjęcia, pliki dźwiękowe oraz wideo

120. - opcjonalne przechowywanie wszystkich wersji utworzonych dokumentów

121. Musi istnieć możliwość definiowania własnych szablonów wydruków

122. Musi istnieć możliwość obsługi raportów wbudowanych, w tym:

123. - raport z wykonań zabiegów operacyjnych z uwzględnieniem kryteriów: czas wykonania zabiegu, księga bloku, sala operacyjna z podziałem na rodzaj zabiegu, księgę bloku, salę i jednostkę zlecającą

124. System musi umozliwiać wybór formatu wydruku raportów, przynajmniej w zakresie: pdf, xls, xlsx.

125. Musi istnieć możliwość definiowania własnych wykazów

126. Musi istnieć możliwość projektowania formularzy dokumentacji medycznej

127. System musi zapewnić integrację z innymi modułami systemu medycznego w zakresie:

128. - dostępu do historii choroby i dokumentacji medycznej bieżącego pobytu szpitalnego,

129. - rejestracji kart zakażeń,

130. - automatycznej aktualizacji stanów magazynowych przy ewidencji leków i materiałów,

131. - wzajemnego udostępniania informacji o zleconych badaniach i konsultacjach,

132. - przeglądu wyników zleconych badań i konsultacji,

133. - przeglądu wszystkich poprzednich hospitalizacji pacjenta i wizyt w przychodni,72




134. System musi umożliwić pracę współbieżną użytkowników w zakresie pracy na tym samym zestawie danych. Ponadto system musi umożliwiać rozwiązywanie konfliktów występujących podczas jednoczesnej pracy na tym samym zestawie danych.

135. Blok porodowy

136. Ewidencja danych wywiadu położniczego w zakresie:

137. - Przebieg i powikłania ciąży (dane opisowe lub formularz)

138. - Dane statystyczne dot. poprzednich porodów pacjentki

139. -- Liczba dzieci ogółem

140. -- Liczba żywo urodzonych

141. -- Liczba martwo urodzonych

142. -- Liczba dzieci z wadami rozwojowymi

143. -- Liczba dzieci zmarłych

144. -- W aktualnym małżeństwie

145. -- Liczba ciąż

146. -- Liczba porodów

147. -- Liczba poronień

148. -- Liczba porodów o czasie

149. -- Liczba porodów przedwczesnych

150. -- Liczba porodów niewczesnych

151. -- Liczba porodów siłami natury

152. -- Liczba porodów patologicznych

153. - Data pierwszej miesiączki

154. - Dzień cyklu




155. - Dane poprzedniego porodu

156. -- Data poprzedniego porodu

157. -- żywe, martwe, brak danych

158. -- Informacje o ewentualnym zgonie noworodka

159. - Starsze potomstwo

160. -- Imię i nazwisko

161. -- Rok urodzenia

162. -- Stan zdrowia

163. -- Ewentualne przyczyny zgonu

164. - Wydruk dokumentu wywiadu położniczego (Pismo)

165. Medyczne dane pacjentki rodzącej (dostępne wszystkie dane związane z hospitalizacją pacjentki - analogicznie jak na standardowym oddziale). W tym między innymi:

166. - Rozpoznanie wstępne

167. - Rozpoznanie końcowe

168. - Wykonane procedur medycznych

169. - Zlecenia lekarskie

170. - Podawane leki

171. - Obserwacje lekarskie

172. - Epikryza

173. - Dokumentacja medyczna

174. Poród

175. Określenie podstawowych danych porodu w zakresie (dotyczy porodu fizjologicznego i operacyjnego):

176. - Mnogość porodu




177. - Miejsca porodu

178. - Charakter czasowy porodu

179. - Ułożenie płodu

180. - Rodzaj porodu (Zabiegowy, Fizjologiczny)

181. - Ewidencja danych znieczulenia zastosowanego podczas porodu fizjologicznego

182. - Rodzaj porodu zabiegowego

183. - Wskazania do cesarskiego cięcia

184. - Zespół porodowy (lekarz, położna, anestezjolog, inne wg konfiguracji)

185. - Ewidencja leków i środków medycznych użytych podczas porodu z wydzieleniem środków anestezjologicznych.

186. - Możliwość skierowania pacjentki na blok operacyjny w celu wykonania porodu operacyjnego

187. - Odnotowanie szczegółowych danych noworodków

188. -- Dane identyfikacyjne noworodka

189. -- Dane osobowe noworodka

190. -- Żywo/martwo urodzony

191. -- Czas urodzenia

192. -- płeć

193. -- Możliwość ewidencji danych dla urzędu stanu cywilnego oraz generacji "Karty urodzenia".

194. -- Możliwość wystawienia karty zgonu zarówno dla noworodka zmarłego w trakcie, po porodzie jak i martwo urodzonego.

195. -- Dane antropometryczne noworodka

196. -- Procedury i zabiegi wykonane na noworodku po urodzeniu

197. -- urazy okołoporodowe

198. -- Stwierdzone nieprawidłowości

199. -- Pierwsze badanie noworodka75




200. -- Ocena wg skali Apgar po: 1, 3, 5 i 10 min.

201. - Popłód

202. - Opis przebiegu porodu

203. - Wykonane zabiegi w trakcie i po porodzie

204. - Powikłania porodowe wraz ze szczegółowym opisem

205. - Czas rozpoczęcia porodu

206. - Czas zakończenia porodu

207. - Czas odpłynięcia płynu owodniowego

208. - Barwa płynu owodniowego

209. - Czas osiągnięcia pełnego rozwarcia szyjki macicy

210. - Czas urodzenia noworodka lub w przypadku ciąży mnogiej noworodków

211. - Czas urodzenia łożyska

212. - Czas trwania I, II i III okresu porodu (wyliczane automatycznie)

213. - Łączny czas trwania całego porodu

214. - Ewidencja utraty krwi przez rodzącą, z uwzględnieniem informacji dotyczących przetoczenia krwi, osocza, płytek

215. Poród operacyjny (dane dodatkowe rozszerzający zestaw danych podstawowych porodu)

216. Możliwość ewidencji wszystkich danych porodu na Bloku operacyjnym (porodowym)

217. Możliwość ewidencji danych noworodków na Bloku operacyjnym (porodowym)

218. Skierowanie pacjentki na blok operacyjny w celu wykonania porodu operacyjnego

219. Ewidencja rozpoznania przedoperacyjnego

220. Ewidencja rozpoznania pooperacyjnego

221. Zespół operacyjny (położnik, położna, operator, pielęgniarka operacyjna, Anestezjolog, pielęgniarka anestezjologiczna)




222. Ewidencja danych zabiegu operacyjnego

223. Ewidencja danych znieczulenia zastosowanego podczas porodu operacyjnego

224. Opis przebiegu porodu operacyjnego

225. Opis i przebieg znieczulenia

226. Ewidencja procedur medycznych wykonanych

227. Ewidencja zużycia materiałów i leków

228. Opieka pooperacyjna - obsługa opieki pooperacyjnej dla kobiet po porodzie operacyjnym

229. Automatyczne uzupełnienie danych porodu (tj. czas porodu, opis porodu itd. na podstawie danych porodu operacyjnego, naturalnego)

230. Obsługa księgi porodów i noworodków

231. - Automatyczna generacja i wydruk ksiąg porodów zgodnie z obowiązującym prawem

232. - Automatyczna generacja i wydruk ksiąg noworodków zgodnie z obowiązującym prawem



N.

Lp. TAB. IV. N. Punkt pobrań Spełnianie (TAK/NIE)

1. System powinien umożliwiać zarządzanie zleceniami na badania laboratoryjne, w szczególności:

2. - wprowadzanie zleceń zewnętrznych,

3. - możliwość wyszukiwania zleceń wg imienia i nazwiska, daty zlecenia oraz planowanej daty wykonania,

4. - dostęp do zleceń archiwalnych pacjenta,

5. - wyróżnianie zleceń CITO,

6. - dobieranie materiałów niezbędnych do realizacji zlecenia,

7. - wycofanie zlecenia

8. System musi wspomagać obsługę punktu przyjęcia i rozdzielni materiału w szczególności:

9. - wspomaganie rozdziału materiałów wg jednostek wykonujących (badania realizowane we własnych lub obcych laboratoriach),

10. - rejestracja wysłania materiałów do laboratoriów,

11. - oznakowanie pobieranych materiałów kodem kreskowym.

12. System musi umożliwiać rejestrację w systemie pobranych materiałów, w tym:

13. - automatyczne odnotowanie daty i godziny pobrania,

14. - odnotowanie osoby pobierającej materiał,

15. - odnotowanie dodatkowych uwag do pobrania,

16. - dla wybranych badań (np. oznaczenie grupy krwi) konieczność potwierdzenia danych pobrania (data i godzina, osoba, uwagi).

17. System musi umożliwiać wydruk dokumentu pobrania dla pojedynczego badania oraz dla panelu badań

18. obsługa i wydruk Księgi Pobrań

19. integracja z innymi modułami systemu medycznego:

O.

Lp. TAB. IV. O. Administrator Spełnianie (TAK/NIE)

1. Konfigurowanie systemu




2. Dynamiczne definiowanie widoków słowników (zakresu danych wyświetlanych) dla jednostki organizacyjnej, dla użytkownika,

3. Definiowanie terminarzy zasobów: pomieszczeń, łóżek, urządzeń

4. System musi umożliwić definiowanie i ewidencję ograniczeń terminarza dotyczących wieku i płci.

5. System musi umożliwić obsługę ograniczeń limitów dziennych dla terminarzy

6. Zarządzanie parametrami na poziomie systemu, jednostki organizacyjnej, stacji roboczej, użytkownika,

7. Definiowanie struktury dokumentów:

8. - ksiąg wykorzystywanych w przychodni, szpitalu, pracowniach,

9. - szablonów wydruków (pism),

10. Definiowanie elementów leczenia i złożonych szablonów zleceń wykorzystywanych przez jednostki zlecające,

11. zarządzanie słownikiem jednostek struktury organizacyjnej Zamawiającego na poziomie całego systemu:

12. - tworzenie i modyfikacja listy jednostek organizacyjnych (recepcje, gabinety, pracownie, oddziały, izby przyjęć, bloki operacyjne itp.),

13. - powiązanie struktury jednostek organizacyjnych ze strukturą kosztów.

14. Zarządzanie słownikami standardowymi (ogólnopolskimi):

15. - Międzynarodowa Klasyfikacja Procedur Medycznych ICD9 CM – druga polska edycja,

16. - Klasyfikacja chorób wg ICD – rewizja 10,

17. - Słownik Kodów Terytorialnych GUS,

18. - Słownik Zawodów.

19. System musi umożliwiać aktualizację słownika ICD 10 za pomocą pliku udostępnianego przez CSIOZ lub z pliku zapisanym na dysku.

20. System musi umożliwić aktualizację słownika ICD 10 z wykorzystaniem algorytmu Jaro-Winkler wraz z możliwością określenia wskaźnika stopnia podobieństwa porównywanych nazw.

21. Tworzenie, przegląd, edycja słowników własnych Zamawiającego:

22. - personelu,

23. - leków.




24. Zarządzanie strukturą użytkowników i ich uprawnieniami:

25. System zarządzania użytkownikami musi być wspólny dla wszystkich systemów, w szczególności dla modułu RCH, Apteka, Apteczki oddziałowe, Rozliczenia z NFZ

26. System zarządzania użytkownikami musi umożliwiać definiowanie listy użytkowników systemu

27. System zarządzania użytkownikami musi umożliwiać określenie uprawnień użytkowników,

28. System zarządzania użytkownikami musi umożliwiać połączenie listy użytkowników ze słownikiem personelu,

29. System umożliwia definiowanie preferowanego kanału komunikacji (sms,e-mail) dla pacjenta.

30. System musi umożliwać zatwierdzenie wniosku użytkownika o zmianę danych.

31. System musi umożliwiać podgląd złożonych wniosków oraz ich statusów w kontekście osoby składającej oraz wszystkich użytkowników.

32. System musi umożliwiać obsługę wniosków użytkownika o zmianę:

33. -danych personalnych

34. -danych kontaktowych

35. -danych wymaganych w dokumentacji medycznej (tytuł naukowy, tytuł zawodowy, specjalizacje)

36.W ramach użytkownika zalogowanego, system umożliwia wyznaczenie osoby zastępującej w zadanym okresie czasu, która czasowo przejmie prawa użytkownika zastępowanego. Użytkownik zastępujący ma możliwość odrzucenia zastępstwa.

37. Musi istnieć możliwość nadania użytkownikowi uprawnień do pracy wyłącznie w kontekście wybranej/ wybranych jednostek organizacyjnych. Np. tylko oddział wewnętrzny lub gabinet i izba przyjęć.

38. System musi posiadać mechanizmy umożliwiające zapis i przeglądanie danych o logowaniu użytkowników do systemu

39.

Administrator musi posiadać możliwość z poziomu aplikacji z modułu administratora nadawania danemu użytkownikowi unikalnego loginu oraz hasła. Administrator musi posiadać możliwość ustawienia parametrów hasła: długość, czas żywotności, czas przed wygaśnięciem, minimalna liczba dużych i małych liter oraz cyfr, liczb, minimalna i maksymalna liczba znaków specjalnych w haśle

40. Administrator musi mieć możliwość określenia ważności konta użytkownika. System prezentuje użytkownikowi informację o terminie zablokowania konta.

41. System uprawnień powinien być tak skonstruowany, aby można było użytkownikowi nadać uprawnienia z dokładnością do rodzaju wykonywanej operacji tj. osobne uprawnienie na odczyt danych i osobne na wprowadzanie/modyfikację danych. System uprawnień powinien umożliwiać definiowanie grup uprawnień, które to mogłyby być przydzielane poszczególnym




użytkownikom.

42. Równolegle musi istnieć możliwość nadawania użytkownikowi pojedynczych uprawnień z listy dostępnych. System musi umożliwiać definiowanie grup użytkowników i przydzielanie użytkowników do tych grup.

43. System musi umożliwić nadanie użytkownikowi lub grupie użytkowników uprawnień do wydruku dokumentu

44.System powinien umożliwiać nadawanie uprawnień użytkownikom do jednostek organizacyjnych w których pracują, np. lekarz pracujący na izbie przyjęć i oddziale wewnętrznym powinien w swoich aplikacjach widzieć tylko pacjentów izby przyjęć i tego jednego oddziału.

45. System musi umożliwiać podgląd aktualnie zalogowanych do systemu użytkowników.

46. Administrator musi posiadać z poziomu aplikacji możliwość wylogowania wszystkich użytkowników aplikacji

47. System umożliwia prowadzenie rejestru zgód i sprzeciwów pacjentów, opiekunów, personelu. Rejestracja oraz dezaktywacja zgód, sprzeciwów, oświadczeń możliwa jest z poziomu jednego okna.

48. System umożliwia administratorowi z poziomu aplikacji definiowanie i zmianę praw dostępu dla poszczególnych użytkowników i grup użytkowników z dokładnością do poszczególnych modułów oraz funkcji systemu

49. System powinien umożliwić przypisanie do komórki organizacyjnej jednostki, kodu technicznego NFZ. Powinna istnieć możliwość zmiany tego kodu w dowolnym momencie pracy systemu.

50. System musi umożliwić określenie jednostkom organizacyjnym oddzielnego numeru REGON, innego niż REGON zakładu opieki zdrowotnej

51. System musi umożliwiać zarządzanie międzymodułowym systemem komunikacyjnym umożliwiający pobranie lub wysłanie komunikatów do:

52. - użytkowników wybranych modułów,

53. - wskazanych użytkowników (nazwanych oraz ról jakie pełnią w systemie)

54. - wskazanych stacji roboczych

55. System musi umożliwiać przegląd dziennika operacji (logi),

56. System musi umożliwiać zapisywanie informacji o przeglądanych danych przez wybranego użytkownika.

57. System musi umożliwiać wykonanie funkcji optymalizacji bazy danych

58. System musi umożliwiać wyszukiwanie i łączenie podwójnie wprowadzonych danych pacjentów, lekarzy, instytucji.

59.System musi zachowywać dane pacjenta "scalonego" mechanizmem scalania pacjentów. Pacjent którego dane zostały scalone z danymi innego pacjenta nie może być usunięty z systemu. Dane pacjenta powinny być dostępne do wyszukiwania w szczególności wyszukiwania wg identyfikatora pacjenta.




60. System musi umożliwiać przegląd danych pacjenta usuniętego podczas scalania pacjentów.

P.

Lp. TAB. IV. P. Elektroniczna Dokumentacja Medyczna Spełnianie (TAK/NIE)

1. Możliwość archiwizacji dokumentacji medycznej w postaci elektronicznej.

2. Możliwość archiwacji dokumentów złożonych, wieloczęściowych i przyrostowych tj. księgi

3. Możliwość obsługi załączników do dokumentów

4. Możliwość rejestracji dokumentów elektronicznych generowanych przez system medyczny w repozytorium dokumentacji elektronicznej

5. Możliwość rejestracji dokumentów elektronicznych utworzonych poza systemem HIS, manualna rejestracja dokumentów zewnętrznych

6. Cyfryzacja dokumentu papierowego i dołączanie go do dokumentacji elektronicznej

7. Dostęp do całości dokumentacji przechowywanej w EDM:8. - z poziomu wbudowanych w systemy medyczne mechanizmów

9. Możliwość exportu/importu dokumentu elektronicznego do/z pliku w formacie XML

10. Możliwość złożenia podpisu elektronicznego na dokumencie oraz na zbiorze dokumentów

11. Możliwość złożenia podpisu elektronicznego na zbiorze dokumentów12. Możliwość znakowania czasem dokumentu13. Możliwość wykonania kontrasygnaty 14. Możliwość weryfikacji podpisu15. Możliwość weryfikacji integralności dokumentu16. Możliwość wydruku dokumentu

17. Możliwość wyszukiwania dokumentów za pomocą zaawansowanych kryteriów oraz meta danych.

18. Możliwość wersjonowania przechowywanych dokumentów z dostępem do pełnej historii poprzednich wersji.

19. Repozytorium EDM musi umożliwiać:20. - rejestrację dokumentu21. - pobieranie dokumentów w formacie XML22. - pobieranie dokumentów w formacie PDF23. - wyszukiwanie materializacji dokumentów24. Repozytorium EDM musi współdzielić z HIS:25. - słownik jednostek organizacyjnych26. - rejestr użytkowników27. - rejestr pacjentów

28. System uprawnień pozwalający na precyzyjne definiowanie obszarów dostępnych dla danego użytkownika pełniącego określoną rolę.

29. Możliwość zarządzania uprawnieniami dostępu do określonych operacji w



Lp. TAB. IV. P. Elektroniczna Dokumentacja Medyczna Spełnianie (TAK/NIE)

repozytorium. Przykłady uprawnień systemowych: uruchomienie systemu, zarządzanie uprawnieniami użytkowników, zarządzanie parametrami konfiguracyjnymi, zarządzanie typami dokumentów.

30.

Możliwość zarządzania uprawnieniami do wykonywania operacji na poszczególnych typach dokumentów w ramach całej placówki lub poszczególnych jednostek organizacyjnych. Przykłady uprawnień do dokumentów: dodawanie dokumentów do repozytorium, odczyt dokumentu, podpisywanie dokumentu, znakowanie czasem dokumentu, import i eksport dokumentu, anulowanie dokumentu, wydruk dokumentu itd.

31. Możliwość definiowania nowych typów dokumentów obsługiwanych przez repozytorium dokumentów elektronicznych.

32.Zakłada się także możliwość indeksowania dokumentów, których elektroniczna postać nie jest przechowywana w systemie HIS - np. indeksowanie dokumentów papierowych, obrazów radiologicznych przechowywanych w PACS.

33. Indeksowane powinny być wszystkie wersje dokumentu

34. Indeks powinien uwzględniać rozdzielenie danych osobowych od danych medycznych

35. Możliwość indeksowania dokumentów w celu łatwego jej wyszukiwania wg zadanych kryteriów

36.Indeks dokumentacji powinien być zorientowany na informacje o dokumencie: autor, data powstania, rozmiar, typ, data powstania itp., oraz na informacje o zdarzeniach

37. System musi umożliwić udostępnianie dokumentacji:38. - w celu realizacji procesów diagnostyczno-terapeutycznych w ZOZ39. - pacjentom i ich opiekunom40. - podmiotom upoważnionym np. prokurator

41. System powinien umożliwiać wymianę dokumentacji medycznej w ramach Systemu Informacji Medycznej:

42. - bezpośrednio pomiędzy jednostkami ochrony zdrowia43. - za pośrednictwem systemów regionalnych44. - z wykorzystaniem platformy P1.



V. Rozbudowa systemu HIS

Wykonawca w ramach realizacji przedmiotu zamówienia jest zobowiązany rozbudować system HIS o następujące moduły:

Lp. TAB. V.A. Dokumentacja Formularzowa Spełnianie (TAK/NIE)

1. Dokumentacja medyczna

2. Generowanie Historii Choroby z danych zgromadzonych w systemie

3. Generowanie Karty Informacyjnej z danych gromadzonych w systemie

4. Generowanie wyników badań dla zadanych kryteriów: pacjent, nazwa badania, jednostka organizacyjna, zadany czasu,

5. Generowanie wydruków kart obserwacji pacjenta

6. Generowanie wydruków kart zakażenia, kart drobnoustroju

7. Generowanie raportów z dyżuru lekarskiego na podstawie zarejestrowanych obserwacji pacjenta

8. Generowanie raportów z diagnoz pielęgniarskich

9. Wydruk diagnoz pielęgniarskich

10. System musi umożliwiać dopasowanie systemu do potrzeb Zamawiającego w zakresie dokumentowania procesu leczenia:

11. - definiowania własnych formularzy przeznaczonych do wpisywania danych w systemie.

12. - wyświetlanie, wprowadzanie i drukowanie informacji w ustalonej przez użytkownika postaci (definiowalne formularze oraz edytor wydruków dla badań, konsultacji, itp.).

13. - histogramy

14. - możliwość kojarzenia formularzy ze zleceniami i elementami leczenia

15. - rejestrowanie danych multimedialnych (rysunki, obrazy, dźwięki, itp.).

16. - dostęp do danych dla potrzeb analityczno-sprawozdawczych.

17. System powinien przechowywać wszystkie wersje utworzonej i wydrukowanej (lub zarchiwizowanej w archiwum elektronicznym) dokumentacji medycznej.

18. Wszystkie dokumenty dokumentacji medycznej pacjenta powinny być dostępne z jednego miejsca

19. Musi istnieć możliwość zdefiniowania drukarki dla każdego rodzaju dokumentu 84




tak aby dokument mógł być drukowany na odpowiedniej dla niego drukarce

20. Powinna istnieć możliwość podpisania elektronicznego i zarchiwizowania wszystkich dokumentów dokumentacji medycznej tworzonych przez system zgodnie z obowiązującymi przepisami.

21. System musi umożliwić udostępnianie pacjentowi dokumentacji medycznej w postaci elektronicznej zapisywanej na nośniku danych.

22. Możliwość zablokowania modyfikacji wpisów w historii choroby dokonanych przez innego lekarza niż lekarz aktualnie zalogowany/ autoryzujący wpis

23. Możliwość autoryzacji przez lekarza dokonującego wpis, fragmentu historii choroby, epikryzy lub rozpoznania

24. Podczas wydruku dokumentu system sprawdza i informuje czy dane źródłowe wykorzystane do utworzenia dokumentu uległy zmianie.

25. System musi być wyposażony w mechanizmy umożliwiające weryfikację, czy na określonym etapie procesu obsługi pacjenta zostały utworzone wszystkie wymagane dokumenty

26. Musi istnieć możliwość utworzenia dokumentu roboczego, umożliwiającego podgląd danych źródłowych w postaci dokumentu

27. System musi umożliwiać współpracę z systemami automatycznej digitalizacji dokumentacji papierowej.

28. System musi umożliwić wydruk czystych recept z różnych modułów systemu.

29.System umożliwia obsługę dokumentów o zmiennej treści, o ile nie stoi to w sprzeczności z wymaganiami zewnętrznymi dotyczącymi tych dokumentów (np. ściśle określony format lub zawartość informacyjna dla dokumentów skierowań, zleceń, recept)

30. System musi umożliwiać kopiowanie wyników badań do skierowania na leczenie uzdrowiskowe.

31. e - Zwolnienia

32.System musi zapewnić zgodność z interfejsem ZUS PUE, bazującym na usługach sieciowych, umożliwiającym wystawianie oraz korektę zwolnień lekarskich bezpośrednio z poziomu systemów dziedzinowych zewnętrznych względem ZUS dostawców oprogramowania.

33.System musi umożliwiać logowanie do systemu PUE - ZUS bezpośrednio z aplikacji gabinetowej. Logowanie możliwe jest poprzez podpisanie oświadczenia wygenerowanego przez ZUS za pomocą elektronicznego podpisu kwalifikowanego lub ePUAP.

34. System musi umożliwić wylogowanie z systemu PUE - ZUS, w chwili zamknięcia sesji pracy z systemem.

35.System musi umożliwać wystawienie zaświadczenia lekarskiego w trybie bieżącym. Aplikacja gabinetowa w czasie wystawiania zwolnienia powinna umożliwiać posługiwanie się zarówno danymi lokalnymi jak i danymi pobieranymi z systemu PUE - ZUS.

36. System musi umożliwiać podpisywanie dokumentu zaświadczenia lekarskiego podpisem kwalifikowanym, za pomocą ePUAP, podpisem w chmurze lub




certyfikatem ZUS PUE.37. System musi umozliwć przekazywanie utworzonych dokumentów zaświadczeń

lekarskich do systemu PUE-ZUS.38. System musi umozliwiać wydruk dokumentu zaświadczenia lekarskiego zgodnie z

opublikowanym przez ZUS wzorem.39. System musi umozliwiać anulowanie zaświadczenia przekazanego do PUE-ZUS

(dla zaświadczeń, dla których ZUS dopuszcza taką możliwość).

40.System musi umożliwiać pobranie i rezerwację puli serii i nr ZLA dla zalogowanego lekarza (użytkownika) na potrzeby późniejszego wykorzystania w trybie alternatywnym (np. w sytuacji braku możliwości połączenia się z systemem PUE-ZUS).

41.System musi umożliwić w aplikacji gabinetowej w przypadku braku połączenia z systemem PUE-ZUS, wystawienie zwolnienia w trybie alternatywnym (off-line) w oparciu o zarezerwowaną wcześniej dla bieżącego lekarza (użytkownika) pulę serii i nr ZLA.

42. System musi umozliwić wydruk dokumentu zaświadczenia lekarskiego wystawionego w trybie alternatywnym zgodnie z opublikowanym przez ZUS wzorem zarówno przed jego elektronizacją jak i po elektronizacji.

43. System musi umożliwiać unieważnienie zaświadczenia lekarskiego, jeśli nie dokonano jego elektronizacji (nie przesłano go do ZUS).

44. System musi umożliwić elektronizację zaświadczenia lekarskiego polegającą na przesłaniu do ZUS zaświadczenia wystawionych wcześniej w trybie alternatywnym.

45. System musi umożliwić zbiorczą elektronizację zaświadczeń lekarskich polegająca na przesłaniu do ZUS zaświadczeń wystawionych wcześniej w trybie alternatywnym.

46. System musi umożliwić anulowanie zaświadczenia przekazanego do PUE-ZUS (dla zaświadczeń, dla których ZUS dopuszcza taką możliwość).

47. System musi umożliwiać wystawianie oraz anulowanie zwolnień elektronicznych bezpośrednio w systemie HIS.

48. System musi umożliwiać przegląd danych źródłowych oraz dokumentów zaświadczeń lekarskich wystawionych w lokalnej aplikacji gabinetowej.

Lp. TAB. V.B. Zakażania Szpitalne Spełnianie (TAK/NIE)

1. Moduł realizuje wspomaganie Zakładu Opieki Zdrowotnej w zakresie kontroli występowania zakażeń szpitalnych i zapobiegania tym zakażeniom, zgodnie z odpowiednimi przepisami prawa. W szczególności:

2. prowadzenie Rejestru Kart Rejestracji Zakażenia Szpitalnego,

3. wydruki na podstawie danych Rejestru Kart Rejestracji Zakażenia Szpitalnego,

4. prowadzenie Rejestru Kart Rejestracji Drobnoustroju Alarmowego,

5. wydruki na podstawie danych Rejestru Kart Rejestracji Drobnoustroju 86




Alarmowego,6. System musi umożliwiać dodanie czynnika alarmowego do karty IKRD/CzA na

podstawie wyniku badania mikrobiologicznego.7. prowadzenie Rejestru zgłoszeń zachorowania na chorobę zakaźną,

8. wydruki na podstawie danych Rejestru zgłoszeń zachorowania na chorobę zakaźną,

9. prowadzenie Rejestru zgłoszeń zachorowania (podejrzenia zachorowania) na AIDS lub zgłoszenia zakażenia (podejrzenia zakażenia) HIV,

10. wydruki na podstawie danych Rejestru zgłoszeń zachorowania (podejrzenia zachorowania) na AIDS lub zgłoszenia zakażenia (podejrzenia zakażenia) HIV,

11. prowadzenie Rejestru zgłoszeń zachorowania (podejrzenia zachorowania) na chorobę przenoszoną drogą płciową,

12. wydruki na podstawie danych Rejestru zgłoszeń zachorowania (podejrzenia zachorowania) na chorobę przenoszoną drogą płciową,

13. prowadzenie Rejestru zgłoszeń zachorowania (podejrzenia zachorowania) na gruźlicę,

14. wydruki na podstawie danych Rejestru zgłoszeń zachorowania (podejrzenia zachorowania) na gruźlicę,

15. prowadzenie Rejestru zgłoszeń zgonu (podejrzenia zgonu) z powodu choroby zakaźnej,

16. wydruki na podstawie danych Rejestru zgłoszeń zgonu (podejrzenia zgonu) z powodu choroby zakaźnej,

17. System musi informować o wcześniejszym zgłoszeniu pacjenta w ramach danego formularza zgłoszenia zachorownia, w ramach danego pobytu.

18. prowadzenie Rejestru obserwacji potencjalnych źródeł zakażenia (wkłucia obwodowe, wkłucia centralne, cewniki, respiratory, operacje, infekcje),

19. System musi umożliwiać zbiorczy wydruk kart pomocniczych i formularzy zgłoszenia zachorowania.

20. prowadzenie Rejestru podejrzeń ognisk epidemicznych,

21. wydruki na podstawie danych Rejestru podejrzeń ognisk epidemicznych,

22. prowadzenie Rejestru potwierdzonych ognisk epidemicznych ,

23. wydruki na podstawie danych Rejestru potwierdzonych ognisk epidemicznych,

24. raporty zgodne z odpowiednim Rozporządzeniem Ministra Zdrowia,

25. analizy ilościowe zakażeń szpitalnych,

26. Współpraca z systemem RCH oraz Laboratorium w zakresie podań antybiotyków i zleceń badań do pracowni mikrobiologicznej:

27. - monitorowanie o konieczność założenia Indywidualnej Karty Zakażeń Szpitalnych w przypadku podania antybiotyku powyżej 3 dni




28. - monitorowanie o konieczność założenia Indywidualnej Karty Zakażeń Szpitalnych w przypadku wystąpienia patogenu w badaniu mikrobiologicznym

29. "System współpracuje z modułem Ruch Chorych w zakresie powiadomienia o konieczności założenia Indywidualnej Karty Zakażenia Szpitalnego, w przypadku wystąpienia temperatury ciała pacjenta powyżej X godz. od przyjęcia do szpitala.

30. "

31. "System umożliwia podgląd pacjentów gorączkujących powyżej określonej w parametrze wysokości temperatury

32. "

33. Prowadzenie Rejestru Kart zakażeń dla pracowników (dostępny również na Izbie Przyjęć)

34. Prowadzenie Rejestru szczepień i odmów szczepień pracowników

35. Możliwość dostosowania wydruku Kart zakażeń

36. Możliwość dostosowania widoczności pól na Kartach zakażeń oraz na Kartach drobnoustroju

37. Możliwość definicji walidacji pól na Kartach zakażenia oraz Kart drobnoustroju

38. Możliwość definicji powiązań zgłoszeń zachorowań na choroby zakaźne z: -patogenem -rozpoznaniem

39. Możliwość definicji diagnoz pielęgniarskich pod kątem wymagalności zakładania Kart zakażeń

40. Możliwość definicji rozpoznań dla których zakładana jest Karta zakażenia

41. Możliwość definicji zakładania Kart zakażeń na podstawie założonych Kart drobnoustroju

Lp. TAB. V.C. Pracownia Diagnostyczna Spełnianie (TAK/NIE)

1. Pracownia diagnostyczna

2. dostęp do listy pacjentów zarejestrowanych do pracowni

3. Na liście zleceń do wykonania powinna być wyświetlana informacja, czy badanie powinno być wykonane przy łóżku pacjenta

4. System musi umożliwiać prezentację badań wymagających zafakturowania.

5. System umożliwia prezentację na liście badań jednostki, realizowanych badań z jednostek powiązanych.

6. rejestracja rozpoczęcia obsługi wizyty pacjenta w pracowni (przyjęcie)88




7. wspomaganie obsługi pacjenta w pracowni:

8. przegląd danych pacjenta w następujących kategoriach:

9. - dane osobowe,

10. - podstawowe dane medyczne (grupa krwi, uczulenia, stale podawane leki, przebyte choroby, karta szczepień),

11. - uprawnienia z tytułu umów,

12. - Historia Choroby (dane ze wszystkich wizyt pacjenta) ,

13. - wyniki badań,

14. - przegląd rezerwacji.

15. możliwość zdefiniowania elementów menu (zakładek) w zależności od potrzeb i rodzaju usługi

16. Możliwość zdefiniowania wzorów dokumentów dedykowanych dla pracowni

17. Możliwość użytkowania zdefiniowanych wcześniej wzorców dokumentacji dedykowanej do wizyty,

18. Przegląd, wprowadzanie i modyfikacja danych wizyty w następujących kategoriach:

19. - informacje ze skierowania,

20. - skierowania, zlecenia,

21. - usługi, świadczenia w ramach wizyty,

22. - wystawione skierowania,

23. - wykonane podczas wizyty procedury dodatkowe

24. - inne dokumenty (zaświadczenia, druki, na formularzach zdefiniowanych dla wizyty).

25. - wynik badania

26. - możliwość przechwytywania pojedynczych klatek obrazu z kamery lub innego źródła np. aparatu USG i dołączanie go do wyniku badania

27. Możliwość stosowania słownika tekstów standardowych do opis danych wizyt

28. Możliwość stosowania „pozycji preferowanych” dla użytkowników, jednostek organizacyjnych (wyróżnienie najczęściej wykorzystywanych pozycji słowników).




29.System musi umożliwiać ewidencję proponowanego personelu wykonującego i opisującego badanie diagnostyczne. W przypadku integracji z systemem zewnetrznym, proponowany personel wykonujący i opisujący, powinien zostać wysłany do systemu zewnętrznego.

30. Możliwość ewidencji wykonania usług rozliczanych komercyjnie:

31. Obsługa zakończenia badania/wizyty:

32. - autoryzacja medyczna badania,

33. - automatyczne tworzenie karty wizyty/wyniku badania

34. Wgląd w rozliczenia NFZ z tytułu zrealizowanych w trakcie wizyty usług

35. Automatyczna generacja i przegląd Księgi Pracowni

36. Obsługa wyników badań:

37. - wprowadzanie opisów wyników badań diagnostycznych

38. - wprowadzanie opisów wyników badań na definiowalnych formularzach wyników dostosowanych do rodzaju wykonywanego badania

39. - autoryzacja wyników badań diagnostycznych

40. - wydruk wyniku wg wzoru, jakim posługuje się pracownia

41. - wydruk wielu egzemplarzy tego samego dokumentu

42. System prezentuje graficzną informację jeżeli autoryzowany wynik został wycofany i ponownie zmodyfikowany.







49. System powinien umożliwiać powtórny wydruk dokumentu już wydrukowanego.



Lp. TAB. V.D. Badania Kliniczne Spełnianie (TAK/NIE)

1. Zarządzanie definicjami badań klinicznych

2. - przegląd badań klinicznych

3. - ewidencja badania klinicznego

4. - definiowanie schematu wizyt

5. - przypisanie pacjenta do badania

6. Zarządzanie umowami na realizację badań klinicznych

7. Ewidencja danych realizacji badań klinicznych

8. System musi umożliwiać dostępność do danych badań klinicznych z poziomu innych modułów systemu.

9. Weryfikacja danych finansowych

10. Raport z udzielonych świadczeń w ramach badan klinicznych

11. Rozliczanie umów na podstawie informacji o realizacji w ramach badań klinicznych

Lp. TAB. V.E. Portal Pacjenta Spełnianie (TAK/NIE)

1.System musi umożliwiać pacjentom rezerwację terminów wizyt w jednostce ochrony zdrowia oraz anulowanie wcześniej dokonanych rezerwacji, z opcją potwierdzania wizyt pacjentek przez personel Szpitala poprzez przesłanie zwrotnej informacji potwierdzającą rezerwację lub nie.

2.Rezerwacja terminu udzielenia usługi – wskazanie daty i czasu planowanej realizacji wizyty, miejsca realizacji (element struktury organizacyjnej) i personelu realizującego (opcjonalnie; w zależności od statusu wyboru personelu zdefiniowanego dla usługi).

3. System umożliwia pacjentom wyszukiwanie usługi medycznej związanej z planowaną wizytą; wyszukiwanie usługi może odbywać się z wykorzystaniem następujących kryteriów:

4. -- nazwy usługi (poprzez podanie dowolnego ciągu znaków zawierającego się w nazwie usługi),

5. -- nazwy jednostki organizacyjnej szpitala, w której udzielana jest oczekiwana usługa,

6. -- imienia, nazwiska, tytułu naukowego i specjalności lekarza udzielającego oczekiwanej usługi.

7. Grupowanie usług do rezerwacji wg zdefiniowanych rodzajów usług.91




8. System umożliwia wybór jednostki organizacyjnej, jeżeli usługa udzielana jest w wielu miejscach.

9. System umożliwia wybór personelu/lekarza udzielającego usługi medycznej, jeżeli jest dostępny dla danej usługi.

10.

System umożliwia przegląd dostępnych dla rezerwacji internetowej terminów wizyt związanych z udzieleniem wybranej usługi medycznej oraz wybór wskazanego terminu. Po wybraniu terminu system blokuje możliwość wyboru tego terminu przez innych użytkowników zarówno systemu MPI jak i systemu szpitalnego.

11. System umożliwia prezentację szczegółowych danych planowanej wizyty, tj.:

12. -- wybranej usługi medycznej, w tym informacji o warunkach udzielenia usługi,

13. -- danych adresowych miejsca udzielenia usługi,

14. -- danych wybranego personelu/lekarza udzielającego usługi.

15. System umożliwia lub wymusza (w zależności od konfiguracji dla danej usługi) rejestrację danych skierowania, w przypadku rezerwacji terminu dotyczącego świadczeń wymagających skierowania.

16. Wydruk potwierdzenia rezerwacji wizyty zawierający informacje o usłudze, miejscu realizacji oraz planowaną datę udzielenia usługi.

17. Możliwość rezerwacji terminu wizyty dla podopiecznych; możliwość zmiany terminu wizyt dla podopiecznych; możliwość anulowania rezerwacji podopiecznych.

18. Przegląd rejestru rezerwacji wizyt pacjenta z wyróżnieniem stanu usługi (planowana, zrealizowana, anulowana).

19. System umożliwia przegląd zaplanowanych wizyt pacjenta.

20. System umożliwia prezentację szczegółowych danych zaplanowanej wizyty tj.:

21. - informacji o usłudze medycznej wraz z warunkami udzielenia usługi,

22. - danych teleadresowych miejsca udzielenia usługi,

23. - informacji o personelu udzielającym usługi (o ile jest wybrany na etapie rezerwacji terminu wizyty),

24. - planowanego terminu wizyty.

25. System umożliwia anulowanie rezerwacji wskazanego terminu wizyty.

26. System integruje się on-line z systemem HIS w zakresie:

27. -- pobierania dostępnych terminów udzielenia wybranych świadczeń,92




28. -- rezerwacji terminu wybranego świadczenia wraz z rejestracją danych skierowania, o ile są one wprowadzone przez pacjentów,

29. -- anulowania terminów zaplanowanych wizyt,

30. -- pobierania informacji o planowanych terminach wizyt.

Lp.TAB V.F Kalkulacja Kosztów Leczenia

Spełnianie (TAK/NIE)

1. kalkulacja indywidualnych kosztów leczenia pacjenta:

2. możliwość automatycznego pobierania danych o pacjencie w zakresie zrealizowanych mu świadczeń z aplikacji medycznych (Przychodnia, Ruch Chorych i Apteczka oddziałowa):

2a - osobodni,

2b - procedury,

2c - badania,

2d - leki.

3. możliwość wydruku kosztowej karty pacjenta dającej możliwość wyceny pobytu pacjenta (wydruk jako załącznik może być podstawą wystawienia faktury za pobyt pacjenta nieubezpieczonego) z wyszczególnieniem kosztów świadczeń i leków istotnych kosztowo oraz włączeniem kosztów pozostałych świadczeń do kosztów ogólnych pobytu:

3a - w zakresie kosztów leków – na poziomie cen leków z konkretnej dostawy, w ramach której zrealizowano podania dla pacjenta (integracja z modułami Apteka, Apteczka oddziałowa),

3b - w zakresie rzeczywistych kosztów świadczeń (z ostatniego miesiąca, dla którego taka wycena istnieje – integracja z modułem Koszty)

4. możliwość grupowania kosztowych kart pacjentów wg zdefiniowanych kryteriów i prowadzenia analiz ekonomicznych (np. wg jednostek chorobowych, produktów rozliczeniowych).

5. Możliwość definiowania wskaźników kosztowo-przychodowych w oparciu o predefiniowane funkcje dla:

5a · pacjentów,

5b · ośrodków powstawania kosztów,



Lp.TAB V.F Kalkulacja Kosztów Leczenia

Spełnianie (TAK/NIE)

5c · jednostek chorobowych,

5d · produktów kontraktowych.

6. Możliwość zestawienia przychodów i kosztów hospitalizacji na poziomie:

6a · pojedynczego pacjenta,

6b · kodu JGP,

6c · produktu jednostkowego,

6d · produktu kontraktowego,

6e · rozpoznania głównego.

7. Możliwość zestawienia statystyk kosztów pobytów z podziałem na lekarzy prowadzących.

8. Możliwość szacunkowej kalkulacji dotychczasowych kosztów pacjenta w trakcie trwania hospitalizacji w oparciu o dane historyczne lub zdefiniowane cenniki (w przypadku braku danych historycznych).

9. Możliwość prezentacji kosztów zleceń do jednostek zewnętrznych wg przyjętych cen umownych z daną jednostką

10.

Możliwość porównania liczby osobodni wynikającej z danych zaewidencjonowanych w systemie medycznym z liczbą osobni przesłaną do modułu KKL z modułu Rachunek Kosztów.

11.

Szkolenie stanowiskowe dla 2 osób, konfiguracja zgodnie z potrzebami Zamawiającego

VI. Integracja oprogramowania z systemem administracyjnym ERP

1. Zamawiający zapewni współpracę z Producentem posiadanego systemu ERP wskazanego w tabeli 2 przy uzyskaniu przez Wykonawcę opisów interfejsów do integracji, natomiast wykonanie integracji jest obowiązkiem Wykonawcy. Ustalenie kosztów integracji z systemami posiadanymi przez Zamawiającego jest obowiązkiem Wykonawcy. Zamawiający nie odpowiada za zawartość merytoryczną dokumentacji w zakresie opisów interfejsów, którą przekaże zainteresowanym stronom producent systemu ERP.

2. Zamawiający dopuszcza integrację z obecnymi systemami dziedzinowymi tylko i wyłącznie poprzez wyspecyfikowane interfejsy, których implementację udostępnia dany system



dziedzinowy ze względu na to, że integracja bezpośrednia na poziomie bazy danych mogłaby doprowadzić do niekontrolowanej utraty integralności danych co w skrajnym przypadku grozi uszkodzeniem danych wrażliwych procesu leczenia pacjentów.

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

Dane przesyłane z modułów części medycznej do administracyjnej Moduł Kasa Rejestr

SprzedażyKoszty FK Wycena

Procedur Medycznych

Pracownia Dokumenty kasowe

Faktury sprzedaży komercyjnej

Statystyka wykonań procedur z pracowni ze wskazaniem jednostek zlecających

SUM Faktury sprzedaży komercyjnej

Lecznictwo otwarte

Dokumenty kasowe


RCH Dokumenty kasowe


Liczba osobodni, liczba pobytów, liczba łóżek, średnie obłożenie łóżek, liczba hospitalizacji (zakres przekazywanych danych może być definiowany)

Apteka Dokumenty księgowe: PW, PZ

Indeksy leków oraz ceny tych leków.Rozchody leków na OPK

Transport sanitarny

Dane do wystawienia faktury

Dane przesyłane z modułów części administracyjnej do medycznejKoszty

KKL Koszty procedur medycznych



Koszty całkowite OPK

Wspólne kartoteki i słowniki Pacjenci Kontrahenci Ośrodki Powstawania Kosztów (OPK) ICD 9

PrzypisaniaCzęść administracyjna Część medycznaOśrodki Powstawania Kosztów (OPK) Jednostki Organizacyjne Szpitala (JOS)Świadczenia Elementy leczenia



VII. Dostawa systemu diagnostyki obrazowej PACS

dostawa systemu diagnostyki obrazowej (PACS) wraz z jego integracją z rozbudowywanym systemem HIS. Zakres integracji opisano w pkt. VII

Lp. TAB. VII. PACS Spełnianie (TAK/NIE)

I. OGÓLNE1. System PACS musi wykorzystywać relacyjny motor bazy danych przynajmniej w

zakresie przechowywania metadanych archiwizowanych plików DICOM. Dopuszcza się transakcyjny serwer relacyjnych baz danych ORACLE / Microsoft SQL / Sybase / MySQL / DB2. Musi istnieć możliwość wykupienia wsparcia technicznego u producenta dla oferowanej wersji silnika bazy danych. Oferent w ramach przedmiotu umowy dostarczy licencję na wykorzystany przez system relacyjny motor bazy danych.

2. Umiejscowienie bazy danych w systemie plikowym. Pliki bazy danych na macierzy dyskowej RAID.

3. Automatyczne uruchomienie serwera PACS do pełnej funkcjonalności po restarcie bez udziału administratora np. po awarii zasilania.

4. System musi być wyposażony w zabezpieczenia przed nieautoryzowanym dostępem na poziomie klienta (aplikacja) i serwera (serwer baz danych).

5. System musi archiwizować wyniki obrazowe w jakości diagnostycznej (DICOM)6. System musi archiwizować badania obrazowe w archiwum on-line, którego

pojemność może być przez Zamawiającego rozszerzana. 7. System musi automatycznie tworzyć kopie zapasową danych obrazowych na

wskazanej macierzy zapasowej i w razie awarii archiwum głównego, automatycznie przełączać się na dostęp do danych z archiwum zapasowego.

8. System musi umożliwiać wykonywanie kopii zapasowej bazy danych co najmniej raz dziennie bez zatrzymywania pracy systemu.

9. Wykonawca jest zobowiązany udzielić Zamawiającemu licencji bezterminowo i bez ograniczeń dla wszystkich programów wymaganych do poprawnego działania systemu w zakresie opisu przedmiotu zamówieniaOkreślenie licencji jako „bezterminowych i bez ograniczeń” oznacza, że muszą one charakteryzować się następującymi cechami:

a) nie są ograniczone czasowo i nie wygasną po zakończeniu trwania umowy;

b) nie ograniczają liczby zarejestrowanych w systemie użytkowników;c) nie mają ograniczeń stanowiskowych – Zamawiający będzie mógł

zainstalować dostarczone oprogramowanie na dowolnej liczbie posiadanych stanowisk komputerowych;

10. Wykonawca jest zobowiązany udzielić Zamawiającemu licencji dla potrzeb administracyjnych, umożliwiających konfigurowanie uprawnień dostępu do systemu PACS dla co najmniej 1 użytkownika korzystającego z dowolnego uprawnionego komputer.




11. Wykonawca jest zobowiązany udzielić Zamawiającemu licencji bezterminowo i bez ograniczeń na moduł dystrybucji sieciowej PACS dla systemu HIS (otwieranie obrazów z PACS przez system HIS).

12. System PACS musi być przygotowany do pracy niezależnie od HIS (np. przy wyłączonym systemie HIS).

13. Liczba licencji usług serwera PACS (w przypadku limitowania) musi wystarczyć do zaspokojenia potrzeb Zamawiającego czyli:- 1 x serwer obsługujący min. 7.000 badań/rok- 1 x klient diagnostyczny RTG (według szczegółowego opisu poniżej)- bez limitu dystrybucja na oddziały dla lekarzy klinicystów (klient kliniczny przeglądowy)- podłączenie do 15 urządzeń DICOM (DICOM Store SCU) - 1 x połączenie HL7 - 1 x obsługa DICOM Modality Worklist

14. Moduły takie jak: archiwum PACS / obsługa DICOM Modality Worklist / klient kliniczny przeglądowy / klient diagnostyczny / interfejs HL7 muszą pochodzić od jednego producenta

II. Moduł archiwizacji oraz dystrybucji danych obrazowych PACS15. System dystrybucji i udostępniania danych obrazowych posiada własne

oprogramowanie diagnostyczne oraz kliniczne działające w technice pełny klient-serwer. Aplikacje klienckie korzystają wyłącznie z bazy danych serwera PACS. Możliwość skonfigurowania systemu tak, aby obrazy nie były przechowywane na stacji klienta, lub były przechowywane w pamięci podręcznej przez określony czas po zakończeniu pracy aplikacji klienckiej.

16. Możliwość automatycznego udostępniania danych pacjenta i badania dla aparatów diagnostycznych (DICOM Modality WorkList). Aplikacja musi umożliwiać konfigurowanie list roboczych (MWL, Modality Worklist) dla poszczególnych urządzeń. Możliwość wprowadzenia konwersji polskich znaków diakrytycznych do znaków występujących w języku angielskim (np. zastąpienie liter ‘ą’ literą ‘a’) dla komunikacji z wybranymi urządzeniami lub grupą urządzeń. Możliwość zmiany strony kodowej w komunikacji z wybranym urządzeniem spośród co najmniej: Latin1 (IR 100), Latin2 (IR 101), Unicode (IR 192)

17. System umożliwia skonfigurowanie dostępu do danych dla użytkowników z dowolnego komputera w sieci. Możliwość wymuszenia szyfrowanego połączenia między serwerem a stacją kliencką bez instalacji dodatkowego oprogramowania.

18. System umożliwia archiwizację i wyświetlanie danych przesyłanych w oparciu o standard DICOM 3.0, min. klasy SOP (SCU):Standard CR Image Storage 1.2.840.10008.5.1.4.1.1.1Standard Digital X-ray Image Storage (presentation, processing) 1.2.840.10008.5.1.4.1.1.1.1, 1.2.840.10008.5.1.4.1.1.1.1.1Standard Mammography Image Storage (presentation, processing) 1.2.840.10008.5.1.4.1.1.1.2, 1.2.840.10008.5.1.4.1.1.1.2.1Standard Intra-oral X-ray Image Storage (presentation, processing)




1.2.840.10008.5.1.4.1.1.1.3, 1.2.840.10008.5.1.4.1.1.1.3.1Standard CT Image Storage 1.2.840.10008.5.1.4.1.1.2Enhanced CT Image Storage 1.2.840.10008.5.1.4.1.1.2.1Standard US Multiframe Image Storage (retired) 1.2.840.10008.5.1.4.1.1.3Standard US Multiframe Image Storage 1.2.840.10008.5.1.4.1.1.3.1Standard MR Image Storage 1.2.840.10008.5.1.4.1.1.4Enhanced MR Image Storage 1.2.840.10008.5.1.4.1.1.4.1Standard US Image Storage (retired) 1.2.840.10008.5.1.4.1.1.6Standard US Image Storage 1.2.840.10008.5.1.4.1.1.6.1Standard Secondary Capture Image Storage 1.2.840.10008.5.1.4.1.1.7Multi-frame Single Bit Secondary Capture Image Storage 1.2.840.10008.5.1.4.1.1.7.1Multi-frame Grayscale Byte Secondary Capture Image Storage 1.2.840.10008.5.1.4.1.1.7.2Multi-frame Grayscale Word Secondary Capture Image Storage 1.2.840.10008.5.1.4.1.1.7.3Multi-frame True Color Secondary Capture Image Storage 1.2.840.10008.5.1.4.1.1.7.4Standard Overlay Storage 1.2.840.10008.5.1.4.1.1.8Standard Modality LUT Storage 1.2.840.10008.5.1.4.1.1.10Standard VOI LUT Storage 1.2.840.10008.5.1.4.1.1.11Grayscale Softcopy Presentation State Storage 1.2.840.10008.5.1.4.1.1.11.1Standard X-ray Angio Image Storage 1.2.840.10008.5.1.4.1.1.12.1Standard X-ray Radio Fluoroscopy Image Storage 1.2.840.10008.5.1.4.1.1.12.2Standard NM Image Storage 1.2.840.10008.5.1.4.1.1.20Raw Data Storage 1.2.840.10008.5.1.4.1.1.66Spatial Registration Storage 1.2.840.10008.5.1.4.1.1.66.1Spatial Fiducials Storage 1.2.840.10008.5.1.4.1.1.66.2Standard VL Image Storage (retired) 1.2.840.10008.5.1.4.1.1.77.1Standard VL Multi-frame Image Storage 1.2.840.10008.5.1.4.1.1.77.2Standard VL Endoscopic Image Storage 1.2.840.10008.5.1.4.1.1.77.1.1Standard Video Endoscopic Image Storage 1.2.840.10008.5.1.4.1.1.77.1.1.1Standard VL Microscopic Image Storage 1.2.840.10008.5.1.4.1.1.77.1.2Standard Video Microscopic Image Storage 1.2.840.10008.5.1.4.1.1.77.1.2.1Standard VL Slide Microscopic Storage 1.2.840.10008.5.1.4.1.1.77.1.3Standard VL Photographic Image Storage 1.2.840.10008.5.1.4.1.1.77.1.4Standard Video Photographic Image Storage 1.2.840.10008.5.1.4.1.1.77.1.4.1Standard Ophthalmic Photographic 8 Bit Image Storage 1.2.840.10008.5.1.4.1.1.77.1.5.1Standard Ophthalmic Photographic 16 Bit Image Storage 1.2.840.10008.5.1.4.1.1.77.1.5.2Structured Reporting Storage (Basic Text, Enhanced SR, Comprehensive) 1.2.840.10008.5.1.4.1.1.88.11, 1.2.840.10008.5.1.4.1.1.88.22, 1.2.840.10008.5.1.4.1.1.88.33Mammography CAD SR 1.2.840.10008.5.1.4.1.1.88.50




Key Object Selection Document Storage 1.2.840.10008.5.1.4.1.1.88.59Chest CAD SR 1.2.840.10008.5.1.4.1.1.88.65Standard PET Image Storage 1.2.840.10008.5.1.4.1.1.128Standard PET Curve Storage 1.2.840.10008.5.1.4.1.1.129Standard RT Image Storage 1.2.840.10008.5.1.4.1.1.481.1Breast Tomosynthesis Image Storage 1.2.840.10008.5.1.4.1.1.13.1.3Encapsulated PDF Storage 1.2.840.10008.5.1.4.1.1.104.1Standard Waveform 12 Lead ECG Storage 1.2.840.10008.5.1.4.1.1.9.1.1Standard Waveform General ECG Storage 1.2.840.10008.5.1.4.1.1.9.1.2

19. System umożliwia archiwizację i wyświetlanie danych przesyłanych w oparciu o standard DICOM 3.0, min. klasy SOP (SCP):Standard Echo 1.2.840.10008.1.1Storage Commitment 1.2.840.10008.1.20.1Standard Digital X-ray Image Storage (presentation, processing) 1.2.840.10008.5.1.4.1.1.1.1, 1.2.840.10008.5.1.4.1.1.1.1.1Standard Mammography Image Storage (presentation, processing) 1.2.840.10008.5.1.4.1.1.1.2, 1.2.840.10008.5.1.4.1.1.1.2.1Standard Intra-oral X-ray Image Storage (presentation, processing) 1.2.840.10008.5.1.4.1.1.1.3, 1.2.840.10008.5.1.4.1.1.1.3.1Standard CR Image Storage 1.2.840.10008.5.1.4.1.1.1Standard CT Image Storage 1.2.840.10008.5.1.4.1.1.2Enhanced CT Image Storage 1.2.840.10008.5.1.4.1.1.2.1Standard US Multiframe Image Storage (retired) 1.2.840.10008.5.1.4.1.1.3Standard US Multiframe Image Storage 1.2.840.10008.5.1.4.1.1.3.1Standard MR Image Storage 1.2.840.10008.5.1.4.1.1.4Enhanced MR Image Storage 1.2.840.10008.5.1.4.1.1.4.1Standard US Image Storage (retired) 1.2.840.10008.5.1.4.1.1.6Standard US Image Storage 1.2.840.10008.5.1.4.1.1.6.1Standard Secondary Capture Image Storage 1.2.840.10008.5.1.4.1.1.7Multi-frame Single Bit Secondary Capture Image Storage 1.2.840.10008.5.1.4.1.1.7.1Multi-frame Grayscale Byte Secondary Capture Image Storage 1.2.840.10008.5.1.4.1.1.7.2Multi-frame Grayscale Word Secondary Capture Image Storage 1.2.840.10008.5.1.4.1.1.7.3Multi-frame True Color Secondary Capture Image Storage 1.2.840.10008.5.1.4.1.1.7.4Standard Overlay Storage 1.2.840.10008.5.1.4.1.1.8Standard Curve Storage 1.2.840.10008.5.1.4.1.1.9Standard Modality LUT Storage 1.2.840.10008.5.1.4.1.1.10Standard VOI LUT Storage 1.2.840.10008.5.1.4.1.1.11Grayscale Softcopy Presentation State Storage 1.2.840.10008.5.1.4.1.1.11.1Standard X-ray Angio Image Storage 1.2.840.10008.5.1.4.1.1.12.1Standard X-ray Radio Fluoroscopy Image Storage 1.2.840.10008.5.1.4.1.1.12.2Standard NM Image Storage 1.2.840.10008.5.1.4.1.1.20




Raw Data Storage 1.2.840.10008.5.1.4.1.1.66Spatial Registration Storage 1.2.840.10008.5.1.4.1.1.66.1Spatial Fiducials Storage 1.2.840.10008.5.1.4.1.1.66.2Standard VL Image Storage (retired) 1.2.840.10008.5.1.4.1.1.77.1Standard VL Multi-frame Image Storage 1.2.840.10008.5.1.4.1.1.77.2Standard VL Endoscopic Image Storage 1.2.840.10008.5.1.4.1.1.77.1.1Standard Video Endoscopic Image Storage 1.2.840.10008.5.1.4.1.1.77.1.1.1Standard VL Microscopic Image Storage 1.2.840.10008.5.1.4.1.1.77.1.2Standard Video Microscopic Image Storage 1.2.840.10008.5.1.4.1.1.77.1.2.1Standard VL Slide Microscopic Storage 1.2.840.10008.5.1.4.1.1.77.1.3Standard VL Photographic Image Storage 1.2.840.10008.5.1.4.1.1.77.1.4Standard Video Photographic Image Storage 1.2.840.10008.5.1.4.1.1.77.1.4.1Standard Ophthalmic Photographic 8 Bit Image Storage 1.2.840.10008.5.1.4.1.1.77.1.5.1Standard Ophthalmic Photographic 16 Bit Image Storage 1.2.840.10008.5.1.4.1.1.77.1.5.2Structured Reporting Storage (Basic Text, Enhanced SR, Comprehensive) 1.2.840.10008.5.1.4.1.1.88.11, 1.2.840.10008.5.1.4.1.1.88.22, 1.2.840.10008.5.1.4.1.1.88.33Mammography CAD SR 1.2.840.10008.5.1.4.1.1.88.50Key Object Selection Document 1.2.840.10008.5.1.4.1.1.88.59Chest CAD SR 1.2.840.10008.5.1.4.1.1.88.65Standard PET Image Storage 1.2.840.10008.5.1.4.1.1.128Standard PET Curve Storage 1.2.840.10008.5.1.4.1.1.129Standard RT Image Storage 1.2.840.10008.5.1.4.1.1.481.1Standard RT Dose Storage 1.2.840.10008.5.1.4.1.1.481.2Standard RT Structure Set Storage 1.2.840.10008.5.1.4.1.1.481.3Standard RT Plan Storage 1.2.840.10008.5.1.4.1.1.481.5Breast Tomosynthesis Image Storage 1.2.840.10008.5.1.4.1.1.13.1.3Encapsulated PDF Storage 1.2.840.10008.5.1.4.1.1.104.1Standard Waveform 12 Lead ECG Storage 1.2.840.10008.5.1.4.1.1.9.1.1Standard Waveform General ECG Storage 1.2.840.10008.5.1.4.1.1.9.1.2Patient Root Query/Retrieve - FIND 1.2.840.10008.5.1.4.1.2.1.1Patient Root Query/Retrieve - MOVE 1.2.840.10008.5.1.4.1.2.1.2Patient Root Query/Retrieve - GET 1.2.840.10008.5.1.4.1.2.1.3Study Root Query/Retrieve - FIND 1.2.840.10008.5.1.4.1.2.2.1Study Root Query/Retrieve - MOVE 1.2.840.10008.5.1.4.1.2.2.2Study Root Query/Retrieve - GET 1.2.840.10008.5.1.4.1.2.2.3Patient Study Only Query/Retrieve - FIND 1.2.840.10008.5.1.4.1.2.3.1Patient Study Only Query/Retrieve - MOVE 1.2.840.10008.5.1.4.1.2.3.2Patient Study Only Query/Retrieve - GET 1.2.840.10008.5.1.4.1.2.3.3

20. Obsługa poniższych Transfer Syntax:Implicit VR Little Endian Transfer Syntax 1.2.840.10008.1.2Explicit VR Little Endian Transfer Syntax 1.2.840.10008.1.2.1Explicit VR Big Endian Transfer Syntax 1.2.840.10008.1.2.2




JPEG Baseline Transfer Syntax 1.2.840.10008.1.2.4.50JPEG Extended Transfer Syntax 1.2.840.10008.1.2.4.51JPEG Lossless, Non-Hierarchical, First-Order Prediction Transfer Syntax 1.2.840.10008.1.2.4.70JPEG2000 Image Compression (Lossless Only) 1.2.840.10008.1.2.4.90JPEG2000 Image Compression 1.2.840.10008.1.2.4.91RLE Transfer Syntax 1.2.840.10008.1.2.5

21. Deklaracja potwierdzająca zgodność z wymogami zawartymi wyżej zarówno dla serwera PACS jak i oprogramowania klienckiego, tzw. DICOM Conformance Statement

22. System umożliwia konfigurację wielu ścieżek, w których będą przechowywane pliki obrazowe. Możliwość określenia typu badań i źródła obrazów które będą zapisywane w wybranej ścieżce.

23. Możliwość nadania priorytetu wybranej ścieżce określającego kolejność zapisywania danych w dostępnych ścieżkach (min. 8 priorytetów). Możliwość określenia maksymalnego zapełnienia dysku wybranej ścieżki, po przekroczeniu którego dane nie będą w niej zapisywane.

24. System umożliwia tworzenie kopii zapasowej obrazu w zdefiniowanej ścieżce. W przypadku awarii archiwum głównego następuje automatyczne przełączenie systemu na dostęp do danych z archiwum zapasowego bez przerwania pracy.

25. Walidacja odebranych badań na poziomie protokołu DICOM w stosunku do informacji ze zlecenia z systemu HIS. System musi sygnalizować, które badanie zostało zwalidowane jako wykonane do zlecenia i ma poprawne dane badania oraz rozróżniać badania niezwalidowane. Możliwość wyświetlenia tylko badań powiązanych ze zleceniami z systemu HIS.

26. Procesy aplikacji na stacji klienckiej mogą pracować na koncie standardowego użytkownika systemu Windows bez praw administratora.

27. Panel / menedżer licencji umożliwiający centralne zarządzanie licencjami. Poszczególne licencje na oprogramowanie klienckie może być przypisywane do wybranych grup lub użytkowników.

28. Archiwizacja wszystkich danych przekazywanych przez urządzenia diagnostyczne. Dane muszą być zapisywane w archiwum on-line a także w kopii zapasowej w formacie DICOM, bez utraty żadnych informacji.

29. Automatyczna zmiana informacji w odbieranych plikach DICOM. Minimum na podstawie AETitle nadawcy, rodzaju urządzenia.

30. Obsługa nagrywania lokalnego na stacji roboczej płyt CD/DVD z badaniami. Możliwość nagrania płyty CD / DVD z badaniami po anonimizacji, wyboru pojedynczego lub wielu badań do nagrania na jednej płycie, zawarcia opisu badania, adnotacji naniesionych przez radiologa.Płyta jest nagrywana z przeglądarką, która wyświetla dane demograficzne pacjenta i badania w konfigurowalny sposób.

31. Możliwość określenia rodzaju kompresji dla przechowywanych poszczególnych rodzajów obrazów, w tym co najmniej bez kompresji, skompresowane bezstratnie algorytmem JPEG2000.

32. Graficzny panel administracyjny pozwalający na zmianę danych pacjenta i




badania, dzielenie badania oraz łączenie badań, przenoszenie serii między badaniami.

33. Graficzny panel administracyjny umożliwiający:- zarządzanie użytkownikami- zarządzanie grupami użytkowników i prawami tych grup- zarządzanie węzłami DICOM- zarządzanie regułami autoroutingu

34. Rejestrowanie zdarzeń systemowych z datą i godzina oraz stacją źródłową, min: logowanie/wylogowanie użytkownika, otworzenie badania, zmiana danych pacjenta.

35. Graficzny panel statystyczny z możliwością eksportu danych do formatu akceptowanego przez MS Excel, min: liczba badań ze względu na typ, lekarza zlecającego; liczby opisanych badań ze względu na radiologa.

36. Możliwość tworzenia naukowej bazy badań, pozwalającej na przypisywanie badań lub obrazów do dowolnie skonfigurowanych kategorii prywatnych oraz publicznych.

37. Możliwość dostępu z oddalonej lokalizacji po szyfrowanym łączu do badań i opisów wraz z możliwością uruchomienia przeglądarki diagnostycznej z wyborem między trybem standardowym i dostosowanym do wolnego łącza Internetowego.

38. Moduł PACS musi posiadać certyfikat klasy minimum IIa, właściwy dla urządzeń lub oprogramowania medycznego używanego w procesie bezpośredniego diagnozowania lub/i monitorowania życiowych procesów fizjologicznych

39. Autorouting badań po zadanych regułach, min: typ badania, klasa SOP, ID pacjenta, nazwy badania, stacji źródłowej, lekarza zlecającego, ram czasowych ze względu na dzień tygodnia i godzinę. Możliwość określenia czy badanie ma być anonimizowane, przesłane zdekompresowane, skompresowane bezstratnie lub stratnie.

40. Administrator ma dostęp do plików logów dla innych usług powiązanych z systemem PACS - w tym dla następujących usług: autorouting; administrator PACS; listy robocze MWL; interfejs wymiany danych HL7; tworzenie kopii obrazów DICOM; system dystrybucji obrazów.

41. Aplikacja musi umożliwiać przeglądanie zawartości danych nagłówkowych plików DICOM

42. Aplikacja musi umożliwiać wyszukiwanie badań w PACS na podstawie kryteriów: nazwisko i imię pacjenta; data urodzenia pacjenta; identyfikator pacjenta; numer badania; zakres dat wykonania badania; nazwa badania;




lekarz zlecający; lekarz opisujący; data wykonania opisu; modalność; urządzenie, z którego zostało wysłane badanie.

43. Aplikacja musi umożliwiać wyszukiwanie badań na urządzeniach DICOM podłączonych do PACS - wraz możliwością pobrania ich do PACS lub przesłania do innych urządzeń DICOM podłączonych do PACS.

44. Aplikacja musi zapewniać możliwość przenoszenia badań pomiędzy pacjentami.45. Aplikacja musi umożliwiać zmianę danych pacjenta i badania znajdującego się w

archiwum DICOM w zakresie: imię, nazwisko pacjenta; data urodzenia pacjenta; płeć pacjenta; numer badania; nazwa badania.

46. Aplikacja musi umożliwiać przenoszenie pomiędzy badaniami (np. w przypadku błędu technika):

jednej lub wielu serii obrazów; jednego lub wielu obrazów.

47. Aplikacja musi umożliwiać śledzenie zmian danych pacjenta i badania w bazie danych.

48. Administrator ma możliwość skonfigurowanie serwera PACS w zakresie zmian następujących parametrów:

nazwa AE, numer portu nasłuchu, poziom logowania zdarzeń, ilość połączeń do serwera, Storage Commitment, parametry komunikacji HL7.

49. Administrator musi mieć możliwość podgląd stanu i kontroli usług (start - stop-restart) związanych z serwerem PACS min.:

autorouting; moduł list roboczych (MWL); interfejs wymiany danych HL7; system dystrybucji obrazów.

50. Aplikacja musi pozwalać na podgląd wykorzystania licencji dostępowych do serwera PACS oraz umożliwiać administratorowi rozłączanie sesji użytkowników.

51. Aplikacja musi pozwalać na zarządzanie grupami użytkowników i przypisywanie uprawnień do grupy:

Archiwizacja badań Ustawienia autoroutingu Usuwanie badań Eksport badań Zarządzanie użytkownikami i grupami użytkowników




Przesyłanie badań pomiędzy węzłami Zarządzanie węzłami

52. Możliwość ograniczenia dostępu do badań przechowywanych w PACS na podstawie typu badania (modalność), jednostki kierującej, lekarza zlecającego.Użytkownikowi można ograniczyć dostęp tylko do badań mu przypisanych.Możliwość przypisywania badań automatycznie na podstawie reguł jak i ręcznie przez osobę, która do danego badania ma dostęp.

53. Integracja z systemem HIS poprzez interfejs HL7 w zakresie wymiany informacji o pacjentach, zleceniach i opisach. Oferent musi uwzględnić w cenie integrację z systemem HISDostarczony system PACS musi współpracować z systemem HIS w sposób pozwalający na pracę wg następującego schematu:- badania są rejestrowane w systemie HIS bez udziału innych systemów klasy ERP (RIS, LIS, CIS itp.),- informacja o zarejestrowanym badaniu jest wysyłana do PACS w celu obsługi DICOM Modality Worklist (zakres wymiany danych – ID pacjenta, PESEL, Nazwisko i Imię, numer zlecenia, lekarz i oddział / placówka zlecająca, kod i nazwa procedury, zaplanowana data wykonania badania, termin rejestracji, komentarz do badania, urządzenie diagnostyczne, na którym badanie ma się odbyć,- system PACS informuje HIS o wykonaniu badania w Zakładzie Diagnostyki Obrazowej,- opis badań wykonany w jednym systemie uznanym za opisowy jest przekazywany do drugiego,- system HIS jest systemem nadrzędnym, wszelkie zmiany danych badania i pacjenta wykonuje się po stronie systemu HIS,- identyfikatory pacjentów oraz badań (zleceń) które w systemie PACS stanowią PatientID (0010,0020) oraz Accession Number (0008,0050) są nadawane przez system HIS.System PACS musi komunikować się z systemem HIS za pomocą protokołu HL7 w wersji 2.xSystem PACS musi obsługiwać komunikację HL7 z HIS bezpośrednio, bez jawnego bądź ukrytego udziału system typu RIS, moduły integracyjne muszą być zaimplementowane w systemie PACS lub, jeśli działają jako zewnętrzne aplikacje, muszą korzystać z bazy danych systemu PACS.System PACS musi generować DICOM Modality Worklist dla urządzeń diagnostycznych na podstawie odebranych od systemu HIS wiadomości HL7Generowana worklista musi mieć możliwość filtrowania wyników osobno dla każdego węzła AET (odpytującego aparatu diagnostycznego). Minimalne kryteria filtrowania wyników zapytań: - modalność- zakres dat- AET aparatu, np. przy wielu aparatach pytających o badania CR system PACS wystawi każdemu badania przypisane tylko dla danego aparatu podczas rejestracji w HIS (zgodnie z danymi przesłanymi w HL7 ze zleceniem)




System PACS musi automatycznie poprawiać/synchronizować dane w generowanej przez system PACS DICOM Modality Worklist, na podstawie danych odebranych od systemu HIS w wiadomościach HL7 Automatyczna zmiana statusu zleconego badania w generowanej przez system PACS DICOM Modality Worklist, dla urządzeń diagnostycznych w następujących przypadkach:- automatycznej zmianie statusu badania na zakończone po odebraniu wiadomości DICOM MPPS od urządzenia diagnostycznego,- automatycznej zmianie statusu badania na zakończone po odebraniu obrazu DICOM przypisanego danemu zleceniu przez system PACS od urządzenia diagnostycznego,- ręcznego połączenia odebranego badania z pozycją na liście badań DICOM Modality Worklist przez uprawnionego użytkownika (w przypadku gdy badanie zostało najpierw wykonane, a następnie zarejestrowane w systemie HIS).System PACS musi automatycznie usuwać pozycję DICOM Modality Worklist po wycofaniu (anulowaniu) zlecenia w systemie HIS na podstawie otrzymanego z systemu HIS komunikatu HL7System PACS po odebraniu wiadomości DICOM MPPS o zakończeniu badania od urządzenia diagnostycznego lub po odebraniu pierwszego obrazu badania od urządzenia diagnostycznego lub po ręcznym, w interfejsie/panelu użytkownika, wygenerowaniu informacji o zakończeniu, wysyła do systemu HIS za pomocą wiadomości HL7 ORMÔ01 lub ORU^R01 następujące informacje:- o zakończeniu badania (wywołuje zmianę statusu zlecenia po stronie HIS np. z "do realizacji" na "nieautoryzowane"),- odsyłacz do przeglądarki klinicznej (link musi się pojawić w załącznikach do wyników po stronie HIS)- identyfikator technika wykonującego pobrany z tagów DICOM archiwizowanych obrazów, np. 0008,1070 Operator'sName (zmapowany na odpowiedni identyfikator użytkownika w systemie HIS musi pojawić się na liście personelu uczestniczącego w wykonaniu badania).System PACS musi odbierać od systemu HIS komunikaty HL7 ORU^R01 z wynikami (opisami) badań. Odebrane opisy muszą być skonwertowane do formatu DICOM SR (DICOM Structured Report i dołączane do badania w systemie PACS jako kolejna seria, udostępniane stacjom diagnostycznym, do nagrania na płytę oraz prawidłowo wyświetlane w przeglądarce klinicznej. Minimum informacji niezbędnych do umieszczenia w utworzonej serii SR to:- dane pacjenta: imię i nazwisko, płeć, data urodzenia, identyfikator PatientID,- tekst opisu - status (autoryzowane),- dane lekarza autoryzującego badanie w systemie HIS,- data opisu (autoryzacji).Obsługa uaktualnień w obiegu danych dotyczących pacjenta (HL7 ADTÂ08), jego badań (HL7 ORMÔ01) oraz ich opisów (ORU^R01). Ewentualne zmiany są automatycznie uwidocznione w badaniach znajdujących się w systemie PACS i systemie dystrybucji obrazów. Nowe (aktualne) dane są udostępniane węzłom DICOM podczas operacji FIND, MOVE lub Query/Retrieve. Oryginalne dane




pozostają niezmienione na poziomie plików (dane w nagłówku pliku DICOM są niezmieniane). Obsługa scalania kart pacjenta – po odebraniu z systemu HIS wiadomości HL7 ADTÂ18 lub ADTÂ40 (wydarzenie patient merge) lub ADTÂ31 system PACS automatycznie przypisuje badania scalanego pacjenta do karty docelowego pacjenta i łączy historię badań pacjenta. Zmiany są automatycznie uwidocznione w badaniach znajdujących się w systemie PACS i systemie dystrybucji obrazów. Nowe (aktualne) dane są udostępniane węzłom DICOM podczas operacji FIND, MOVE lub Query/Retrieve. Oryginalne dane pozostają niezmienione na poziomie plików (dane w nagłówku pliku DICOM są niezmieniane).Administrator systemu PACS z panelu administracji ma możliwość połączenia istniejącego w systemie badania z odpowiednią pozycją Modality Worklist utworzoną na podstawie danych zlecenia z systemu HIS. Zmiany są automatycznie uwidocznione w badaniach znajdujących się w systemie PACS i systemie dystrybucji obrazów. Nowe (aktualne) dane są udostępniane węzłom DICOM podczas operacji FIND, MOVE lub Query/Retrieve. Oryginalne dane pozostają niezmienione na poziomie plików (dane w nagłówku pliku DICOM są niezmieniane). Po połączeniu system PACS musi wysłać do systemu HIS za pomocą wiadomości HL7 ORMÔ01 lub ORU^R01 następujące informacje:- o zakończeniu badania (wywołuje zmianę statusu zlecenia po stronie HIS np. z "do realizacji" na "nieautoryzowane"),- link do przeglądarki klinicznej (link musi się pojawić w załącznikach do wyników po stronie HIS)- identyfikator technika wykonującego pobrany z tagów DICOM archiwizowanych obrazów, np. 0008,1070 Operator'sName (zmapowany na odpowiedni identyfikator użytkownika w systemie HIS musi pojawić się na liście personelu uczestniczącego w wykonaniu badania).

54. Integracja desktopowa z dowolnego zewnętrznego systemu poprzez wywołanie z niego aplikacji PACS. Możliwość uruchomienia przeglądarki PACS ze wskazaniem użytkownika z systemu wywołującego. Wywoływanie minimum: Badania po numerze akcesji Badania po parze numerów – akcesji i identyfikatora pacjenta Badania po numerze STUDY INSTANCE UID Wszystkich badań danego pacjenta

55. Możliwość konfiguracji systemu aby powtórnie wysyłane badania były ponownie importowane (nadpisywane), buforowane (zapis w inne niż archiwum główne miejsce), usuwane bez zapisu.

56. Obsługa DICOM Query/Retrieve dla zewnętrznych węzłów DICOM (stacje diagnostyczne, urządzenia diagnostyczne, duplikatory). Możliwość ustawienia usługi Query/Retrieve na odrębnym porcie i innej nazwie niż usługa DICOM C-STORE. Możliwość konfiguracji unikatowych ustawień dla zapytań Query/Retrieve dla wybranych urządzeń (min. Konwersja polskich znaków diakrytycznych na postać znaków dostępnych w języku angielskim). Możliwość konfiguracji dostępu do badań przez DICOM Query/Retrieve dla węzłów DICOM tylko pochodzących z danej grupy urządzeń (np. tylko CT).




57. Obsługa woluminów tymczasowych do przetrzymywania części plików.58. Możliwość eksportu badania na dysk zewnętrzny w jakości diagnostycznej i

referencyjnej wraz z przeglądarką obrazów.III. Klient kliniczny – przeglądowy / dystrybucja sieciowa (Brak limitu liczby licencji)

60. Klient kliniczny przeglądowy tego samego producenta co system PACS.61. Automatyczna instalacja z sieci oprogramowania klienckiego na stacjach

roboczych. Aplikacja nie wymaga żadnej ingerencji użytkownika podczas instalacji na dowolnym komputerze w sieci.

62. Automatyczna aktualizacja oprogramowania bez ingerencji użytkownika63. Dostęp do systemu chroniony hasłem. Możliwość automatycznego wylogowania

użytkownika po zadanym okresie nieaktywności. Możliwość blokowania konta użytkownika po zdefiniowanej próbie nieudanych logowań.

64. Aplikacja automatycznie wykrywa ilość podłączonych monitorów i wybiera odpowiedni tryb wyświetlania na podstawie informacji zapisanych w profilu użytkownika, min: protokoły wyświetlania na poszczególnych monitorach.

65. W przypadku podłączenia czterech monitorów system umożliwia podział na następujące obszary wyświetlania: 1-1-1-1; 1-3; 1-2-1; 3-1; 1-1-2; 2-2; 2-1-1; 4

66. Wyszukiwanie badań co najmniej wg numeru ID badania, numeru ID pacjenta, nazwiska (imienia) pacjenta, daty wykonania, rodzaju badania, typu urządzenia, nazwy badania, daty wykonania opisu. Możliwość tworzenia i zapisywania własnych filtrów na podstawie zadanych kryteriów.

67. Zakładki „Ulubione” w którym przechowywane są odnośniki do wybranych przez użytkownika badań. Możliwość podziału zakładek na foldery i podfoldery.

68. Po wybraniu badania na liście roboczej oprogramowanie sygnalizuje obecność innych badań wygranego pacjenta, wyświetla opis badania oraz miniatury obrazów badania.

69. Możliwość szybkiego podglądu badań i opisów tego samego pacjenta z poziomu okna przeglądarki obrazów DICOM bez konieczności powrotu na listę badań.

70. Automatyczną aktualizacja list roboczych w wybranych przez użytkownika interwałach czasowych.

71. Możliwość wydruku opisu jak i obrazów badania na drukarce lokalnej72. Możliwość wydruku badania na drukarce medycznej (klisz), w tym na formacie

A3.73. Możliwość definiowania indywidualnych pasków narzędziowych z dostępnych

narzędzi do obróbki obrazu. Graficzny edytor pasków. Przypisywanie różnych pasków narzędziowych do różnych rodzajów badań.

74. Graficzny edytor definiowania indywidualnych protokołów wyświetlania w zależności od min. liczby podłączonych monitorów, typu badania, AETitle źródła badania, nazwy badania.Konfiguracja min: wybrania monitorów na którym mają być wyświetlane obrazy; podział obszaru min. 1x1,2x2,2x3,3x4,4x5; wybranego paska narzędziowego, wyświetlania poprzednich badań pacjenta, rozmieszczenia serii na ekranie (ustawienie umiejscowienia w zależności od numeru lub kolejności serii) i ustawień okna dla wybranej serii.

75. System umożliwia zapisanie indywidualnych ustawień wyświetlania dla każdego




użytkownika centralnie, tak żeby były one dostępne na każdej stacji roboczej. Indywidualne ustawienia zawierają co najmniej:protokoły wyświetlania z podziałem na ilość podłączonych monitorów do stacji klienckiej, skróty klawiszowe, ustawienia konfiguracji listy roboczej, predefiniowane filtry wyszukiwania badań, ustawienia przeszukiwania listy badań.Użytkownik logujący się z dowolnej maszyny otrzymuje ustawienia ze swojego profilu.

76. Wyświetlanie min. badań typu CR, DX, MG, USG, MR, CT, ECG, SC, OT, NM i PET77. Możliwość jednoczesnego wyświetlenia badan różnych pacjentów78. Możliwość jednoczesnego wyświetlania badania otwartego bezpośrednio z płyty

(bez importu do PACS) oraz pochodzącego z archiwum PACS.79. Sortowanie obrazów w serii według znaczników DICOM min. wg numeru ID

obrazu, pozycji warstwy, czasu akwizycji80. Możliwość ręcznego ustalenia dowolnej kolejności obrazów w serii.81. Możliwość otworzenia badania z wyświetleniem tylko obrazów „istotnych” –

kluczowych.82. Organizowanie przeglądania sekwencji obrazów, min:

- zmiana kolejności;- tryb animacji (ustawianie prędkości, kierunku, początku i końca zapętlanie animacji);- scalanie obrazów wybranych serii

83. System musi umożliwiać zapis (eksport) na lokalnym dysku obrazu z adnotacjami jako plik JPEG BMP, TIFF, DICOM, AVI. Przy zapisie plików wieloklatkowych do AVI – możliwość wyboru kodeka (w tym MPEG4).

84. System musi umożliwiać podział badania wieloklatkowego na pojedyncze obrazy85. Obróbka obrazów w zakresie podstawowym, min.

- ustawienia okna;- negatyw / pozytyw;- blendowanie;- obroty 90° i 180°, odbicia lustrzane;- wyświetlanie w trybie skali 1:1 - funkcja ruchomej lupy z płynnym powiększaniem;- ukrywanie danych pacjenta;- płynne powiększanie całości obrazu;- określenie zakresu działania modyfikacji obrazu – jeden obraz, cała seria;- filtr wyostrzający i wygładzający.

86. Pomiary na obrazach w zakresie podstawowym, min.:- Odległości po linii prostej;- Odległość po krzywej;- Histogram;- Kalibracja geometryczna;- Kąty między dwoma nieprzecinającymi się prostymi;- Kąty między kolejnymi nieprzecinającymi się prostymi;- Automatyczne kreślenie linii łączącej środki dwóch innych odcinków;




- Kąt między dwoma liniami łączącymi środki par innych odcinków;- Kąt cobba;- Balans kręgosłupa;- Wskaźnik sercowo-płucny;- Wskaźnik rozbieżności długości kości udowych;- Pomiar objętości obszaru na podstawie obrazów 2D z wyborem algorytmu eliptycznego, sferycznego i Lamberta; - Wyznaczanie linii centralnej;- Wartość piksela znajdującego się pod kursorem myszy (w przypadku badan TK, wartość HU);- Pomiary statystyczne na wybranym ROI w kształcie elipsy, wielokąta lub dowolnego kształtu z wyznaczeniem wartości minimalnej, maksymalnej średniej i odchylenia standardowego.

87. Nanoszenie i usuwanie adnotacji na obrazach- Tekst dowolny;- Tekst predefiniowany przez użytkownika; - Linie proste;- Strzałki z podpisem;- Notatka dodawana do wybranego miejsca obrazu, z wyświetleniem tylko tytułu tej notatki, z możliwością otworzenia pełnego tekstu;- Prostokąty;- Wielokąty regularne;- Okręgi;- Edycja (przesuwanie i zmiany zawartości / kształtów);- Szybkie ukrywanie i przywracanie;- Szybkie usuwanie wybranych oraz wszystkich adnotacji; - Etykietowanie kręgów.

88. Predefiniowanie indywidualnych ustawień okna z podziałem na typ badania, min. 10 ustawień

89. Automatyczna synchronizacja i przeglądanie synchroniczne serii TK i MR w obrębie badania. Ręczna synchronizacja i przeglądanie synchroniczne serii TK i MR w różnych badaniach.

90. Możliwość skopiowania wybranego kawałka obrazu do schowka systemowego91. Znacznik informujący użytkownika o wyświetleniu wszystkich obrazów w serii.92. Ostrzeżenie w postaci dodatkowego komunikatu w przypadku gdy nie wszystkie

obrazy z danego badania zostały wyświetlone.93. Progresywne wczytywanie obrazów z indywidualnym skokowym określeniem

domyślnej ilości wczytanych danych ze względu na typ badania.94. Indywidualnie definiowane skróty klawiszowe, min. wyświetl opis badania,

zamknij badanie, otwórz badanie, zmiana okna, minimalizacja, lista robocza, włącz/wyłącz dane demograficzne, włącz/wyłącz adnotacje i pomiary.

95. Możliwość dodania i odtworzenia głosowego opisu badania.96. Prezentacja statusu badania na liście roboczej. Min. status informujący o

oczekiwaniu na opis, zakończeniu opisu, zatwierdzeniu opisu.97. System umożliwia ustawienie aplikacji stacji klienckiej w stan czuwania, tak, że




badania spełniające zdefiniowane kryteria są ściągane do pamięci podręcznej stacji diagnostycznej bez ingerencji użytkownika.

98. Możliwość wyświetlenia listy badań z DICOMDIR znajdujących się na nośniku optycznym umieszczonym w lokalnym napędzie CD. Możliwość importu tych badań do systemu PACS z edycją podstawowych danych pacjenta.

99. Możliwość pobierania badań z innych systemów za pomocą DICOM Query/Retrieve

100. Możliwość otworzenia pojedynczych plików DICOM z lokalnego folderu101. Możliwość automatycznego otwierania wraz z badaniem komentarza do

zlecenia pochodzącego z systemu HIS bądź wpisanego przez innego użytkownika ręcznie w systemie PACS.

102. Automatyczne ładowanie przez przeglądarkę obrazów zaimportowanych po otwarciu badania.

103. Możliwość konfiguracji wyświetlanych jako etykiety na otwartych zdjęciach szczegółów badania / obrazu w tym możliwość wyświetlenia minimum:Imię i nazwisko pacjenta, identyfikator pacjenta, inne id pacjenta, numer badania, data urodzenia pacjenta, parametry ekspozycji i dawki

104. Aplikowanie tablic LUT przy wyświetlaniu dla zdjęć gdzie są one dostępne.105. Możliwość konfiguracji wyboru funkcji dostępnych pod klawiszami myszy.106. Możliwość logowania do systemu przy pomocy loginu i hasła z Active Directory

jak i hasła lokalnego.107. Klient diagnostyczny RTG tożsamy z klientem rozszerzony o poniższe

funkcjonalności108. Zapisywanie w systemie PACS i udostępnianie zmian wprowadzonych na

obrazach, min: adnotacje i pomiary, ustawienia okna, kalibracja, obrót, odbicie lustrzane.

109. Możliwość wykonywania tzw. zrzutów ekranowych min. z wybranego obraz, całego ekranu i dodanie ich do badania w archiwum jako nowa seria.

110. Możliwość oznaczenia wybranego obrazu w badaniu jako „istotny”.111. Możliwość umieszczania na wydruku opisu obrazów z badania lub wykonanych

zrzutów.112. Wtórne rekonstrukcje MPR warstw CT i MR (2D) płaszczyznach min, wieńcowej,

strzałkowej, skośnej. Możliwość zapisania rekonstrukcji jako nowa seria w badaniu ze wskazaniem ilości i odstępów między zapisywanymi rekonstruowanymi obrazami.

113. Wtórne rekonstrukcje MPR warstw TK i MR po dowolnej krzywej (3DMPR). Możliwość zapisania rekonstrukcji jako nowa seria w badaniu

114. Określenie grubości warstwy rekonstrukcji.115. Rekonstrukcje MIP, MinIP, z określeniem dowolnego VOI . Możliwość

„odcinania” nieistotnych części rekonstrukcji116. Tworzenie automatycznych sekwencji obrazów rekonstrukcji MIP w różnych

pozycjach i zapisanie ich do PACS.117. Możliwość oznaczenia kręgów na widoku w płaszczyźnie czołowej lub

strzałkowej, tak, że po przejściu do widoku płaszczyzny poziomej system powinien pokazywać informację na wysokości jakiego kręgu znajduje się




wyświetlany obraz.118. Możliwość tworzenia katalogów "kominkowych", w których można zapamiętać

chwilowe ustawienia parametrów wyświetlania danego badania (obraz w serii, parametry okna, obrót, rekonstrukcja) tak, aby można było w przyszłości wywołać to badanie z takimi ustawieniami wyświetlania jak zapisane bez konieczności indywidualnego przywracania poszczególnych parametrów wyświetlania – możliwość współdzielenia zapisanych stanów z innymi użytkownikami i tworzenia listy z zapisanych prac.

119. Możliwość zapisania zmian sposobu i układu wyświetlania badania, aby można było do niego wrócić z poziomu otwartego badania w przyszłości. Obsługa zapisu wielu stanów.

120. Możliwość zapisywanie powiększeń obrazu jako plików GSPS (Grayscale Softcopy Presentation State) oraz możliwość włączenia ich automatycznego aplikowania przy uruchamianiu badania.

121. Sygnalizacja pojawiania się nowych badań w systemie PACS.VI. Inne wymagania dla systemu i wdrożenia

123. Interfejs w języku polskim, pomoc w języku polskim124. Dla każdego zalogowanego użytkownika systemu dostęp do wewnętrznego

komunikatora umożliwiającego: - przesyłanie wiadomości tekstowych,- komunikację tekstową na żywo typu „czat”,- przesyłanie odnośników do badań, po naciśnięciu których następuje automatyczne otwarcie przeglądarki obrazów diagnostycznych

125. Grupowanie użytkownikówMożliwość definiowania uprawnień na poziomie grup użytkowników (ról)

126. Dzienniki zdarzeń Serwera PACSRejestrowanie zdarzeń związanych z pracą systemu PACS

127. Dzienniki zdarzeń systemu dystrybucji sieciowejRejestrowanie zdarzeń związanych z pracą systemu webowej dystrybucji badań

128. Notowanie zdarzenia protokołówPrzychodzące i wychodzące wiadomości DICOM i HL7 (DICOM Modality Worklist, MPPS, C-FIND)

129. Notowanie zdarzenia walidacji badańZmiany numerów i nazwisk pacjentów, numerów badań, dowiązywanie badań, negatywne weryfikacje

130. Analiza i statystyki zdjęć odrzuconych (w tym odrzucanie i przywracanie serii oznaczanych jako odrzucone). Obsługa analizy zdjęć odrzuconych obejmuje brak publikacji odrzuconych zdjęć / serii.

131. Możliwość wysyłki treści opisu do badań poprzez wiadomość e-mail, który jest szyfrowany certyfikatem lub hasłem.

132. Obsługa plików DICOM encapsulated PDF.133. Przechowywanie haseł w bazie danych w postaci wyniku funkcji skrótu

Hasło powinno zostać zmienione przez dodatkową zmienną wartość, a następnie z wyniku powinien być przeliczony skrót. W systemie przechowywana jest zmienna wartość dodana do hasła i skrót hasła z tą wartością.




Zalecane funkcje skrótu: SHA-2Niedozwolone funkcje skrótu: MD1 - MD5, SHA-1

134. Obsługa duplikatora płyt. Oprogramowanie do obsługi duplikatorów ma stanowić niezależny węzeł DICOM i być instalowane na komputerach sterujących, które dostarczy Zamawiający.Wymagania funkcjonalne oprogramowania:1. odbiór badań za pośrednictwem komunikacji DICOM2. odbieranie skompresowanych plików (JPEG2000)3. nagrywanie na nośniki CD/DVD wraz z przeglądarką DICOM

nieskompresowanych plików .dcm4. nagrywanie na nośniki CD/DVD wraz z przeglądarką pliki w postaci .jpg5. odbiór opisów badań za pośrednictwem komunikacji HL7 /opcja - w

przypadku, gdy system PACS/RIS/HIS potrafi obsłużyć taką funkcjonalność/6. nagrywanie na nośniki CD/DVD opisu w formacie .pdf oraz .txt 7. możliwość zdefiniowania szablonu opisu badania nagrywanego na nośnik w

zależności od modalności badania8. możliwość zdefiniowania szablonu etykietki drukowanej na nośnik w

zależności od modalności badania9. nagrywanie dowolnej ilości wybranych badań na jeden nośnik (jeżeli

objętość wybranych badań przekroczy dostępne miejsce na nośniku to aplikacja powinna automatycznie wypalić zadanie na kilku płytach).

10. obsługa wszystkich modeli robotów marek EPSON, RIMAGE (zmiana robota nie wymaga wykupienia dodatkowej licencji)

11. optymalizacja kosztów i automatyczny dobór nośników (CD/DVD) dla robotów umożliwiających pracę zarówno z nośnikami CD jak i z DVD

12. konfigurowalny czas automatycznego rozpoczęcia nagrywania płyty od zakończenia transferu plików badania (komunikacja DICOM)

13. optymalizacja czasu produkcji dużych zadań wymagających podziału na kilka nośników

14. weryfikacja poprawności przygotowanego zadania15. interfejs użytkownika desktopowy bądź webowy chroniony hasłem

obsługujący ekran dotykowy umożliwiający: Filtrowanie dostępnych badań zarchiwizowanych w systemie min po:

imię, nazwisko; data urodzenia; data badania; modalność; nazwa badania

Przeszukiwanie innych podpiętych systemów przez DICOM Query/Retrieve min po: imię, nazwisko; data urodzenia; data badania; modalność; nazwa badania

Możliwość pobierania badań z dodanych węzłów DICOM przez DICOM Query/Retrieve (konieczny podgląd statusu i progresu)[informacja jest automatycznie aktualizowana]

Możliwość definiowania dowolnej ilości użytkowników pracujących w aplikacji

Podgląd statusów przygotowywanych zadań wraz z i progresem (informacja jest automatycznie aktualizowana)




Definiowanie zadań zawierającymi kilka badań.16. możliwość ręcznego definiowania dostępnego miejsca na

nośnikach CD/DVD17. automatyczne kasowanie najstarszych badań z komputera

sterującego w przypadku przekroczenia limitu zajętości dysku.18. Możliwość dopasowania wyglądu strony powitalnej aplikacji

startującej po włożeniu nagranego nośnika do napędu komputera (z uwzględnieniem logo zamawiającego). Strona powitalna pozwala na wybór przeglądarki: JPEG / DICOM bądź otwarcie opisu wybranego badania.

19. Możliwość integracji z lokalnym systemem nadzoru aplikacji informatycznych: Zabbix, Nagios

135. Moduł analizy zdjęć odrzuconych umożliwiający znakowanie badań jako odrzucone wraz z podaniem powodów odrzucenia (lista definiowalna na etapie wdrożenia). Możliwość generowania statystyk jak poniżej:1. Raport zdjęć odrzuconych w określonym czasie 2. Raport zdjęć odrzuconych w określonym czasie dla wybranego operatora 3. Raport zdjęć odrzuconych w określonym czasie przez wybranego odrzucającego 4a. Raport zdjęć odrzuconych danej procedury w określonym czasie 4b. Raport zdjęć odrzuconych danej procedury w określonym czasie dla wybranego operatora 5a. Raport zdjęć odrzuconych danego powodu w określonym czasie 5b. Raport zdjęć odrzuconych danego powodu w określonym czasie dla wybranego operatora

136. Podpięcie do systemu posiadanych urządzeń DICOM. Zamawiający zapewnia licencje DICOM MWL i DICOM C Store do posiadanych urządzeń DICOM.

137. Możliwość rozbudowy systemu o następujące moduły tego samego producenta:- moduł do gromadzenia informacji o efektywnej dawce promieniowania wchłoniętego przez pacjenta w czasie badań radiologicznych- moduł do zaawansowanej diagnostyki badań tomograficznych obejmujący:

Rekonstrukcje 3D Wirtualną kolonoskopię System CAD do wykrywania i śledzenia guzków płucnych Perfuzja

138. Serwis dostarczonego systemu Zgłaszanie awarii: w elektronicznym systemie zgłoszeń udostępnionym przez Wykonawcę (lub drogą mailową w przypadku braku takiego systemu), a także telefonicznie w dni robocze w godzinach 8:00-16:00. Zapewnienie pomocy telefonicznej (helpdesku) w systemie w godzinach 8:00-16:00 we wszystkie dni robocze. Usuniecie awarii (oprogramowania lub sprzętu) w następnym dniu roboczym od daty zgłoszenia Awaria zgłoszona w godzinach pomiędzy 16.00 a 24.00 dnia roboczego




traktowana jest jak przyjęta o godz. 8.00 następnego dnia roboczego; Awaria zgłoszona w godzinach pomiędzy 0.00 a 8.00 dnia roboczego - traktowana jest jak przyjęty o godz. 8.00 danego dnia roboczego; Awaria zgłoszona w dniu ustawowo lub dodatkowo wolnym od pracy - traktowana jest jak przyjęty o godz. 8.00 najbliższego dnia roboczego; Wykonawca obejmie opieką serwisową wszystkie dostarczone elementy. Przez objecie opieką serwisową zamawiający rozumie utrzymanie wyposażenia w niezakłóconym działaniu, konserwacje zgodnie z wymogami producenta oraz dokonywanie wszelkich potrzebnych napraw. Wykonawca zapewni zdalne wsparcie systemu umożliwiające dokonywanie diagnozy awarii i napraw oprogramowania, oraz przedstawi imienny wykaz osób uprawnionych do pracy zdalnej. Wykonawca jest zobowiązany do prowadzenia rejestru kontaktów z Zamawiającym, obejmujący w szczególności: rozmowy telefoniczne, pisma, zmiany konfiguracji oprogramowania oraz wykonane czynności serwisowe co będzie załącznikiem do co miesięcznego rozliczenia usługi serwisowej. Zamawiający wymaga objęcia ochroną antywirusową zaoferowanych systemów posiadanym przez Zamawiającego programem antywirusowym. Rozbudowa sprzętowa systemu o dodatkowe zasoby dyskowe (rozbudowa macierzy archiwum PACS) nie będzie wymagała od Zamawiającego wykupywania dodatkowych licencji a konfiguracja nowego sprzętu odbędzie się w ramach obowiązującej umowy. W przypadku wymiany przez Zamawiającego urządzeń diagnostycznych podłączonych do zaoferowanych systemów Wykonawca wykona nieodpłatnie podłączenia nowych węzłów DICOM w ramach posiadanych licencji. Okres wsparcia 12 miesięcy

139. Nadzór autorski nad systemem Zgłaszanie i usuwanie błędów w oprogramowaniu odbywać się będzie na zasadach zgłaszania awarii systemu opisanych w punkcie wyżej Udostępnianie nowych wersji oprogramowania zgodnie z zaleceniami producenta. Nowe wersje oprogramowania są instalowane u Zamawiającego przez Wykonawcę, w sposób i liczbie pozwalającej na niezakłócone funkcjonowanie oprogramowania. Za aktualizację wersji oprogramowania u Zamawiającego odpowiedzialność ponosi Wykonawca, który ma zaplanować i przeprowadzić proces aktualizacji oprogramowania, w sposób zapewniający prawidłowe funkcjonowanie oprogramowania po zakończeniu procesu aktualizacji, na wszystkich stanowiskach objętych oprogramowaniem. Instalacja aktualizacji i nowych wersji oprogramowania aplikacyjnego dostosowujących systemy do zmian ustawowych i wymogów jakie Zamawiający musi spełniać w obszarze zakresu i formatu danych przekazywanych innym podmiotom w terminach wejścia ich w życie. Rozwój oprogramowania (nowe elementy systemu objętego niniejszym




postępowaniem zgodnie ze zmieniającymi się powszechnie obowiązującymi przepisami prawa, przepisami prawa wewnętrznie obowiązującymi wydanymi na podstawie delegacji ustawowej). Wykonawca ma obowiązek dostarczać zamawiającemu nieodpłatnie oprogramowanie podlegające każdorazowo aktualizacji wynikającej ze zmieniających się przepisów prawa, dotyczy to również wszelkich zmian i aktualizacji zakresu przepisów wydawanych przez NFZ. Wykonawca jest zobowiązany do stosowania wszystkich przepisów i regulaminów obowiązujących u Zamawiającego, które mogą mieć zastosowanie w realizacji niniejszego zamówienia, w tym obowiązujących wykładni prawnych lub wskazówek jednostek nadrzędnych (np. Narodowy Fundusz Zdrowia, Ministerstwo Zdrowia, Samorządowy Wydział Zdrowia, Organ Założycielski, inne). Okres nadzoru 12 miesięcy

VIII. Oprogramowanie bazodanowe

L.p. TAB. VIII. Wymagania funkcjonalne SpełnianieTAK/NIE

1. Oferowany motor bazy danych musi być dostępny zarówno na platformy systemów operacyjnych Windows jak i Linux.

2. Oferowany Motor bazy danych HIS musi mieć możliwość rozbudowy do wersji wspierającej możliwość synchronicznej replikacji danych w dwóch niezależnych centrach danych.

3. Oferowany Motor bazy danych HIS posiada komercyjne wsparcie producenta. Nie dopuszcza się zastosowania RBD typu open-source.

4. Oferowany Motor bazy danych HIS ma możliwość realizacji kopii bezpieczeństwa w trakcie działania (na gorąco).

5. Oferowany Motor bazy danych generuje kopie bezpieczeństwa automatycznie (o określonej porze) i na żądanie operatora oraz umożliwia odtwarzanie bazy danych z kopii archiwalnej, w tym sprzed awarii.

6. Oferowany Motor bazy danych umożliwia eksport i import danych z bazy danych w formacie tekstowym z uwzględnieniem polskiego standardu znaków.

7.Administrator posiada możliwość wyboru danych, które mają być monitorowane w logach systemu z dokładnością do poszczególnych kolumn w tabelach danych, a zarządzanie nimi może odbywać się z poziomu narzędzi do zarządzania bazami danych (dopuszcza się narzędzie na poziomie motoru bazy danych).

8. HIS posiada mechanizmy umożliwiające zapis i przeglądanie danych o logowaniu użytkowników do HIS pozwalające na uzyskanie informacji o czasie i miejscach ich pracy.

9. Hasła użytkowników są przechowywane w bazie danych w postaci niejawnej (zaszyfrowanej).




10. W HIS są zaimplementowane mechanizmy walidacji haseł zgodnie z wymaganiami ustawowymi przewidzianymi dla rodzaju danych przetwarzanych przez HIS.

11. HIS umożliwia automatyczne wylogowanie użytkownika z systemu (przy przekroczeniu zadanego czasu bezczynności ustanowionego uprzednio przez Administratora).

12.Dostępność oprogramowania na współczesne 64-bitowe platformy Unix (HP-UX dla procesorów PA-RISC i Itanium, Solaris dla procesorów SPARC i Intel/AMD, IBM AIX), Intel/AMD Linux 32-bit i 64-bit, MS Windows 32-bit i 64-bit. Identyczna funkcjonalność serwera bazy danych na ww. platformach

13. Niezależność platformy systemowej dla oprogramowania klienckiego / serwera aplikacyjnego od platformy systemowej bazy danych

14. Możliwość przeniesienia (migracji) struktur bazy danych i danych pomiędzy ww. platformami bez konieczności rekompilacji aplikacji bądź migracji środowiska aplikacyjnego

15.

Przetwarzanie z zachowaniem spójności i maksymalnego możliwego stopnia współbieżności. Modyfikowanie wierszy nie może blokować ich odczytu, z kolei odczyt wierszy nie może ich blokować do celów modyfikacji. Jednocześnie spójność odczytu musi gwarantować uzyskanie rezultatów zapytań odzwierciedlających stan danych z chwili jego rozpoczęcia, niezależnie od modyfikacji przeglądanego zbioru danych.

16.

Możliwość zagnieżdżania transakcji – powinna istnieć możliwość uruchomienia niezależnej transakcji wewnątrz transakcji nadrzędnej. Przykładowo – powinien być możliwy następujący scenariusz: każda próba modyfikacji tabeli X powinna w wiarygodny sposób odłożyć ślad w tabeli dziennika operacji, niezależnie czy zmiana tabeli X została zatwierdzona czy wycofana.

17. Wsparcie dla wielu ustawień narodowych i wielu zestawów znaków (włącznie z Unicode).

18. Możliwość migracji zestawu znaków bazy danych do Unicode

19. Możliwość redefiniowania przez klienta ustawień narodowych – symboli walut, formatu dat, porządku sortowania znaków za pomocą narzędzi graficznych.

20. Skalowanie rozwiązań opartych o architekturę trójwarstwową: możliwość uruchomienia wielu sesji bazy danych przy wykorzystaniu jednego połączenia z serwera aplikacyjnego do serwera bazy danych

21. Możliwość otworzenia wielu aktywnych zbiorów rezultatów (zapytań, instrukcji DML) w jednej sesji bazy danych

22. Wsparcie protokołu XA

23. Wsparcie standardu JDBC 3.0

24. Zgodność ze standardem ANSI/ISO SQL 2003 lub nowszym.

25. Motor bazy danych powinien umożliwiać wskazywanie optymalizatorowi SQL preferowanych metod optymalizacji na poziomie konfiguracji parametrów pracy




serwera bazy danych oraz dla wybranych zapytań. Powinna istnieć możliwość umieszczania wskazówek dla optymalizatora w wybranych instrukcjach SQL.

26. Brak formalnych ograniczeń na liczbę tabel i indeksów w bazie danych oraz na ich rozmiar (liczbę wierszy).

27.

Wsparcie dla procedur i funkcji składowanych w bazie danych. Język programowania powinien być językiem proceduralnym, blokowym (umożliwiającym deklarowanie zmiennych wewnątrz bloku), oraz wspierającym obsługę wyjątków. W przypadku, gdy wyjątek nie ma zadeklarowanej obsługi wewnątrz bloku, w razie jego wystąpienia wyjątek powinien być automatycznie propagowany do bloku nadrzędnego bądź wywołującej go jednostki programu

28.

Procedury i funkcje składowane powinny mieć możliwość parametryzowania za pomocą parametrów prostych jak i parametrów o typach złożonych, definiowanych przez użytkownika. Funkcje powinny mieć możliwość zwracania rezultatów jako zbioru danych, możliwego do wykorzystania jako źródło danych w instrukcjach SQL (czyli występujących we frazie FROM). Ww. jednostki programowe powinny umożliwiać wywoływanie instrukcji SQL (zapytania, instrukcje DML, DDL), umożliwiać jednoczesne otwarcie wielu tzw. kursorów pobierających paczki danych (wiele wierszy za jednym pobraniem) oraz wspierać mechanizmy transakcyjne (np. zatwierdzanie bądź wycofanie transakcji wewnątrz procedury).

29. Możliwość kompilacji procedur składowanych w bazie do postaci kodu binarnego (biblioteki dzielonej)

30.

Możliwość deklarowania wyzwalaczy (triggerów) na poziomie instrukcji DML (INSERT, UPDATE, DELETE) wykonywanej na tabeli, poziomie każdego wiersza modyfikowanego przez instrukcję DML oraz na poziomie zdarzeń bazy danych (np. próba wykonania instrukcji DDL, start serwera, stop serwera, próba zalogowania użytkownika, wystąpienie specyficznego błędu w serwerze). Ponadto mechanizm wyzwalaczy powinien umożliwiać oprogramowanie obsługi instrukcji DML (INSERT, UPDATE, DELETE) wykonywanych na tzw. niemodyfikowalnych widokach (views).

31.

W przypadku, gdy w wyzwalaczu na poziomie instrukcji DML wystąpi błąd zgłoszony przez motor bazy danych bądź ustawiony wyjątek w kodzie wyzwalacza, wykonywana instrukcja DML musi być automatycznie wycofana przez serwer bazy danych, zaś stan transakcji po wycofaniu musi odzwierciedlać chwilę przed rozpoczęciem instrukcji w której wystąpił ww. błąd lub wyjątek

32. Powinna istnieć możliwość autoryzowania użytkowników bazy danych za pomocą rejestru użytkowników założonego w bazie danych

33. Baza danych powinna umożliwiać na wymuszanie złożoności hasła użytkownika, czasu życia hasła, sprawdzanie historii haseł, blokowanie konta przez administratora bądź w przypadku przekroczenia limitu nieudanych logowań.

34. Przywileje użytkowników bazy danych powinny być określane za pomocą przywilejów systemowych (np. prawo do podłączenia się do bazy danych - czyli utworzenia sesji, prawo do tworzenia tabel itd.) oraz przywilejów dostępu do obiektów aplikacyjnych (np. odczytu / modyfikacji tabeli, wykonania procedury).




Baza danych powinna umożliwiać nadawanie ww. przywilejów za pośrednictwem mechanizmu grup użytkowników / ról bazodanowych. W danej chwili użytkownik może mieć aktywny dowolny podzbiór nadanych ról bazodanowych.

35.

Możliwość wykonywania i katalogowania kopii bezpieczeństwa bezpośrednio przez serwer bazy danych. Możliwość zautomatyzowanego usuwania zbędnych kopii bezpieczeństwa przy zachowaniu odpowiedniej liczby kopii nadmiarowych - stosownie do założonej polityki nadmiarowości backup'ów. Możliwość integracji z powszechnie stosowanymi systemami backupu (Legato, Veritas, Tivoli, OmniBack, ArcServe itd). Wykonywanie kopii bezpieczeństwa powinno być możliwe w trybie offline oraz w trybie online

36. Możliwość wykonywania kopii bezpieczeństwa w trybie online (hot backup).

37.Odtwarzanie powinno umożliwiać odzyskanie stanu danych z chwili wystąpienia awarii bądź cofnąć stan bazy danych do punktu w czasie. W przypadku odtwarzania do stanu z chwili wystąpienia awarii odtwarzaniu może podlegać cała baza danych bądź pojedyncze pliki danych.

38. W przypadku, gdy odtwarzaniu podlegają pojedyncze pliki bazy danych, pozostałe pliki baz danych mogą być dostępne dla użytkowników

39. Wbudowana obsługa wyrażeń regularnych zgodna ze standardem POSIX dostępna z poziomu języka SQL jak i procedur/funkcji składowanych w bazie danych.

40. Możliwość budowy klastra na węźle obsługiwanym przez maksymalnie 2 procesory



IX. Integracja z PACS

Zakłada się, że integracja (interoperacyjne współdziałanie) wchodzących w skład platformy systemów dziedzinowych i innych systemów funkcjonujących we wskazanym obszarze, będzie odbywać się z wykorzystaniem następujących standardów: HL7 oraz DICOM. Standardy te zostały przyjęte w Polsce i są obecnie stosowane przy budowie nowych rozwiązań informatycznych w obszarze ochrony zdrowia.

Lp. TAB. IX. Integracja z PACS Spełnianie (TAK/NIE)

1. Integracja z wykorzystaniem standardu HL7

2. Segmenty wspólne dla komunikatów wysyłanych przez HIS i RIS

3. Segment MSH - nagłówek komunikatu obejmujący:

4. - Kod systemu nadawcy

5. - Kod systemu adresata

6. - data i czas utworzenia komunikatu

7. - typ komunikatu

8. - unikatowy identyfikator komunikatu

9. - tryb interpretacji komunikatu

10. - wersja standardu HL7

11. - potwierdzenia: transportowe i aplikacyjne

12. - stosowany system kodowania znaków

13. - język komunikacji

14. Dane przesyłane z systemu HIS

15. Segment PID - dane demograficzne pacjenta obejmujące:

16. - PESEL

17. - Imiona i nazwisko pacjenta, nazwisko rodowe





19. - data urodzenia

20. - płeć

21. - adres

22. Segment PV1 - informacje o wizycie lub pobycie pacjenta, obejmujący:

23. - rodzaj pobytu: pobyt na IP, wizyta ambulatoryjna, hospitalizacja

24. - jednostka organizacyjna

25. - rodzaj świadczenia

26. - identyfikator pobytu, np. nr księgi

27. Segment IN1 - informacje o ubezpieczeniu pacjenta obejmujące:

28. - identyfikator płatnika

29. - rodzaj skierowania

30. Segment ORM^O01 - dane zlecenia obejmujące:

31. - nr zlecenia

32. - planowana data wykonania, pilność

33. - datę i czas zlecenia

34. - dane osoby zlecającej

35. - identyfikator zlecanego badania

36. - rozpoznanie ze zlecenia

37. - komentarz do zlecenia

38. - dane badania (kod i nazwa badania)

39. Anulowanie zlecenia

40. Modyfikacja zlecenia121




41. Dane przesyłane z systemu RIS

42. Segment ORU^R01 - wynik obejmujący:

43. - status wyniku

44. - dane zlecenia

45. - kod wykonanego badania

46. - datę wykonania

47. - dane personelu wykonującego: lekarz wykonujący, lekarz opisujący, lekarz konsultujący, technik, osoba autoryzująca

48. - wartość wyniku

49. odnośniki (załączniki)do wyników badań

50. Miniatury obrazów

51. Wyniki badań dozleconych (dodatkowych)

52. - dane personelne pacjentów (nazwisko, imię, PESEL, miejsce zamieszkania)

53. - dane zlecenia (numer zlecenia, techniczny identyfikator zlecenia, jednostka zlecająca, lekarz zlecający)




X. Integracja z systemem laboratoryjnym

Zakłada się, że integracja (interoperacyjne współdziałanie) wchodzących w skład platformy systemów dziedzinowych i innych systemów funkcjonujących we wskazanym obszarze, będzie odbywać się z wykorzystaniem następujących standardów: HL7. Standard ten został przyjęty w Polsce i jest obecnie stosowany przy budowie nowych rozwiązań informatycznych w obszarze ochrony zdrowia.

Lp. TAB. X. Integracja z systemem laboratoryjnym Spełnianie (TAK/NIE)

1. Integracja z wykorzystaniem standardu HL7

2. Segmenty wspólne dla komunikatów wysyłanych przez HIS i LIS

3. Segment MSH - nagłówek komunikatu obejmujący:

4. - Kod systemu nadawcy

5. - Kod systemu adresata

6. - data i czas utworzenia komunikatu

7. - typ komunikatu

8. - unikatowy identyfikator komunikatu

9. - tryb interpretacji komunikatu

10. - wersja standardu HL7

11. - potwierdzenia: transportowe i aplikacyjne

12. - stosowany system kodowania znaków

13. - język komunikacji

14. Dane przesyłane z systemu HIS

15. Segment PID - dane demograficzne pacjenta obejmujące:

16. - PESEL

17. - Imiona i nazwisko pacjenta, nazwisko rodowe





19. - data urodzenia

20. - płeć

21. - adres

22. Segment PV1 - informacje o wizycie lub pobycie pacjenta, obejmujący:

23. - rodzaj pobytu: pobyt na IP, wizyta ambulatoryjna, hospitalizacja

24. - jednostka organizacyjna

25. - rodzaj świadczenia

26. - identyfikator pobytu, np. nr księgi

27. Segment IN1 - informacje o ubezpieczeniu pacjenta obejmujące:

28. - identyfikator płatnika

29. - rodzaj skierowania

30. Segment ORM^O01 - dane zlecenia obejmujące:

31. - nr zlecenia

32. - planowana data wykonania, pilność

33. - datę i czas zlecenia

34. - dane osoby zlecającej

35. - identyfikator zlecanego badania

36. - dane pobrania tj.: osoba pobierająca, moment pobrania, pobrany material (rodzaj i numer próbki)

37. - rozpoznanie ze zlecenia

38. - komentarz do zlecenia


40. Anulowanie zlecenia

41. Modyfikacja zlecenia124




42. Dane przesyłane z systemu LIS

43. Segment ORU^R01 - wynik obejmujący:

44. - status wyniku

45. - dane zlecenia

46. - kod wykonanego badania

47. - datę wykonania

48. - dane personelu wykonującego: lekarz wykonujący, lekarz opisujący, lekarz konsultujący, technik, osoba autoryzująca

49. - wartość wyniku

50. - jednostka miary i wartość referencyjna, przekroczenie normy

51. Odnośnik (załączniki)do wyników badań

52. Wyniki badań do zleconych (dodatkowych)

53. Wyniki badan nie zleconych przez HIS

54. Anulowanie wyniku

55. Zmiana wyniku



XI. System długopisu elektronicznego wraz z integracją

System automatycznej digitalizacji dokumentów papierowych na potrzeby elektronicznej dokumentacji medycznej zgodnie z normą PN-EN ISO 10781 – Informatyka w ochronie zdrowia (przez system automatycznej digitalizacji dokumentów papierowych rozumiane jest sprzęt i oprogramowanie, które umożliwia jednoczesne powstawanie wersji papierowej i elektronicznej dowolnego, ustrukturyzowanego dokumentu. W ramach przetworzonego dokumentu powinna automatycznie powstawać wersja pdf tworzonego dokumentu oraz xml z danymi zawartymi w strukturze dokumentu)

L.p. Opis funkcjonalności Spełnianie (TAK/NIE)

A. System powinien gwarantować zapisy z normy w zakresie m.in.:1. IN.1.1 – uwierzytelnianie podmiotu tworzącego dokumentację poprzez

podpis biometryczny2. IN.1.5 – system powinien zawierać obiektywne znaczniki czasu identyfikujące

czas początkowego wpisu oraz modyfikacji danych, oraz identyfikować aktora/podmiot biorący udział w powstawaniu lub zmianie dokumentu.

3. IN.1.6 – dane powinny być zaszyfrowane w sposób uniemożliwiający ich odtworzenie na skutek zagubienia nośnika danych.

4. IN.1.7 – system powinien zapewniać możliwość powiązania każdej treści z autorem tej treści

5. IN.1.9 – system powinien zapewniać pacjentom możliwość weryfikacji dokumentacji w momencie jej powstawania, a także udzielania zgody na przetwarzane dane w sposób możliwy do zaakceptowania przez każdego pacjenta (złożenie podpisu odręcznego)

B. W ramach zamówienia Wykonawca zobowiązany jest do:1. Przeprowadzenia audytu w zakresie obowiązujących w szpitalu dokumentów

papierowych2. Dostawy sprzętu umożliwiającego wykonanie funkcjonalności systemu –

długopisy cyfrowe3. Instalacji i wdrożenia systemu automatycznej digitalizacji dokumentacji

papierowej4. Przeprowadzenia odpowiednich szkoleń w zakresie administrowania i

użytkowania systemu5. Świadczenia usługi serwisowej wraz z nadzorem autorskim dla wszystkich

przekazywanych licencji 6. Dostarczenie dodatkowych bezterminowych licencji Systemu:6.1. Licencje mają być zainstalowane w systemie z określeniem uprawnień do ich




wykorzystywania na serwerze i stacjach roboczych.6.2. Oświadczenie Wykonawcy, że przysługują mu prawa do sprzedaży licencji lub

posiada nadane przez jej autora prawo do udzielania sublicencji na użytkowanie Oprogramowania Aplikacyjnego.

6.3. Wykonawca udzieli Zamawiającemu licencji/sublicencji na użytkowanie Oprogramowania Aplikacyjnego, którego zakres funkcjonalny został określony poniżej.

6.4. Licencja/sublicencja na użytkowanie Oprogramowania Aplikacyjnego jest licencją niewyłączną i zostaje udzielona Zamawiającemu na czas nieokreślony, w ilości kopii niezbędnych do zapewnienia bezpieczeństwa ich działania.

6.5. Zamawiający ma prawo do rozpowszechniania bez ograniczeń danych i dokumentów utworzonych za pomocą Systemu.Wykonawca zapewni, że jest autorem tworzonego systemu i posiada prawa autorskie i majątkowe do kodów źródłowych aplikacji, dzięki czemu może w dowolny sposób kształtować potencjalne nowe funkcjonalności Systemu.

C. Wymagania dotyczące wdrożenia:1. Przeprowadzony zostanie audyt dokumentacji papierowej funkcjonującej u

Zamawiającego2. Wykonane zostanie: instalacja, konfiguracja oraz parametryzacja elementów

Systemu na serwerach wirtualnych oraz na stacjach roboczych,3. Wykonana zostanie konfiguracja dostarczonych długopisów cyfrowych w

zakresie umożliwiającym ich użytkowanie i przypisanie do użytkowników4. Przeprowadzone zostaną szkolenia dotyczące należytego posługiwania się

Systemem dla wszystkich obsługujących System od strony administracyjnej i długopisów cyfrowych

5. Zamawiający wymaga by System wdrożony przez Wykonawcę w ramach realizacji przedmiotu zamówienia były wdrożony w pełnej ich funkcjonalności w tabelach funkcjonalności opisanej.

6. Po dokonaniu instalacji i wdrożenia systemu, docelowo system powinien:6.1. spełniać wymagania określone niniejszym dokumentem,6.2. spełniać wymagania obowiązujących przepisów prawa i uwzględniać

charakter prowadzonej przez Zamawiającego działalności,6.3. powstające dokumenty winny spełniać normę PN-EN ISO 10781,6.4. wykonanie przez Wykonawcę testów poprawności działania systemu, 6.5. pisemne zaakceptowanie przez Zamawiającego przekazanych przez

Wykonawcę wyników testów.6.6. Po zakończeniu realizacji przedmiotu zamówienia Wykonawca wykona i

przekaże Zamawiającemu dokumentację powykonawczą dla administratorów zawierającą dokładny opis funkcjonalny Systemu z uwzględnieniem ich konfiguracji na etapie wdrożenia.

6.7. Wykonawca winien zagwarantować ciągłość rozwoju wdrożonego systemu przez okres minimum 5 lat, liczony od daty podpisania Końcowego Protokołu Odbioru (bezusterkowego). Wykonawca załączy do oferty oświadczenie na tę




okoliczność.6.8. Zapewnić bezpieczeństwo gromadzonych wrażliwych danych medycznych

oraz ich spójności.7. Zamawiający wymaga by docelowo elementy systemu zintegrowane z

systemem medycznym HIS, z którego korzysta Zamawiający spełniały następujące warunki:

7.1. zapewnienie automatycznego sposobu wprowadzania danych za pomocą intuicyjnego interfejsu,

7.2. zapewnienie pełnego wykorzystania i dostępu do danych zgromadzonych w Systemie,

7.3. zachowanie ciągłości obecnie stosowanej przez Zamawiającego numeracji dokumentacji medycznej.

D. Wymagania dotyczące serwisu i nadzoru autorskiego

1. W ramach usług serwisowych i udzielonej gwarancji - przez okres 24 miesięcy od daty podpisania Końcowego Protokołu Odbioru – bezusterkowego, Wykonawca zapewni pełną funkcjonalność systemu poprzez nieodpłatne usuwanie awarii, błędów i usterek programistycznych w dostarczonym i istniejącym oprogramowaniu, nieodpłatne dostarczanie nowych wersji oprogramowania, aktualizacji i poprawek oraz ich aplikowanie, stałą nieodpłatną adaptację do wymogów obowiązującego prawa oraz bezpłatne udzielanie konsultacji telefonicznych, wykonawca będzie nieodpłatne dostarczał nowe wersje oprogramowania, aktualizacje i poprawki wraz z ich aplikowaniem, stałą nieodpłatną adaptację do wymogów obowiązującego prawa jak również świadczył bezpłatnie usługę nadzoru autorskiego w tym okresie.

2. Warunki brzegowe realizacji usług serwisowych

2.1. Godziny pracy Serwisu - 800-1600 w ciągu dnia roboczego od poniedziałku do piątku.

2.2. Czas reakcji Serwisu – 4h, liczony od chwili zaewidencjonowania w serwisie Zgłoszenia Serwisowego do momentu przyjęcia zgłoszenia tj. nadania mu statusu „przyjęte/ zarejestrowane” w godzinach pracy serwisu.

2.3. Czas usunięcia Awarii – 48h, czas liczony w dniach roboczych od upłynięcia czasu reakcji

2.4. Czas usunięcia Wady Aplikacji – 7 dni; czas liczony w dniach roboczych od upłynięcia czasu reakcji

2.5. Czas usunięcia Usterki Programistycznej – 30 dni, czas liczony w dniach roboczych od upłynięcia czasu reakcji

2.6. Czas obsługi Konsultacji – 10 dni, Czas liczony w dniach roboczych od upłynięcia czasu reakcji.




E. Wymagania dotyczące sprzętu1. Długopisy cyfrowe – 15 szt.1.1. Parametry:1.1.1. czas normalnego użycia pomiędzy ładowaniami – 3 dni 1.1.2. wytrzymałość na upadek na dowolną powierzchnię z wysokości 1,5 m1.1.3. pojemność do 1000 wypełnionych dokumentów w przypadku standardowych

formularzy1.1.4. możliwość transmisji danych przez bluetooth1.1.5. możliwość transmisji danych przez złącze USB1.2. ładowanie długopisów przez złącze USB1.3. wbudowany zegar wewnętrzny synchronizowany automatycznie, bez udziału

użytkownika1.4. możliwość działania w zakresie temperatur od 10-35 stopni Celsjusza1.5. wbudowana bateria litowa lub litowo-polimerowa1.6. dołączony program instalacyjny ze sterownikami umożliwiający zgrywanie

danych i wysyłanie do centralnego repozytorium danych2. W ramach wymagań serwerowych Zamawiający zapewni wirtualną

przestrzeń zawierającą co najmniej dwa serwery wirtualne: jeden podstawowy, a drugi tworzący kopie zapasowe i działający w sytuacjach awaryjnych. Minimalne wymagania Serwera:

2.1. 1 Terabajt przestrzeni dyskowej dedykowanej dla rozwiązania2.2. 8 Gb pamięci Ram dedykowanej dla rozwiązania2.3. 8 rdzeniowy procesor do dyspozycji rozwiązania2.4. Procesor minimum Intel® Xeon® Processor E5-2620 v4 (20M Cache, 2.10

GHz), lub porównywalny2.5. System operacyjny Windows Server 2008 r2 lub wyższej2.6. Serwer bazy danych MS SQL w wersji Express 2008 r2 lub wyższej2.7. Możliwość uruchamiania aplikacji w technologii .NET2.8. Możliwość zdalnego dostępu do serwera na życzenie Wykonawcy, na czas

wykonywania prac serwisowych lub administracyjnych

F. Wymagania dotyczące gwarancji1. Warunki gwarancji na sprzęt (długopisy cyfrowe):1.1. 24 miesiące (dwa lata) gwarancji od momentu dostarczenia.1.2. Wszystkie naprawy gwarancyjne realizowane w siedzibie Zamawiającego, a w

przypadku, gdy jest to niemożliwe z przyczyn technicznych w innym miejscu po uzgodnieniu z Zamawiającym.

1.3. Wykonawca ponosi koszty napraw gwarancyjnych, włączając w to koszt części i transportu.

1.4. Serwis obejmuje podmianę sprzętu w razie zaistnienia takiej konieczności2. Warunki gwarancji na System:2.1. opisane w części dotyczącej serwisu




G. Wymagania Niefunkcjonalne Systemu1. Możliwość uruchomienia Aplikacji Systemu (w tym zgrywania danych) na

dowolnym komputerze z systemem operacyjnym Windows XP/7/Vista/8/10, wersje 32 lub 64-bitowe

2. Możliwość wydruku formularzy na dowolnej sieciowej drukarce laserowej autoryzowanej w Systemie

3. Możliwość zbierania danych na formularzach niezależnie od infrastruktury informatycznej (zbieranie danych off-line)

4. Możliwość zbierania danych na formularzach i odkładanie ich w repozytorium danych niezależnie od niedostosowania do przyjęcia danych Systemu HIS (możliwość uzupełnienia funkcjonalności Systemu back-hand’owego w terminie późniejszym)

5. Przygotowanie modułu transmisji danych do Zintegrowanego Systemu HIS 6. Integracja z system szpitalnym HIS polegać może na opracowaniu we

współpracy z zamawiającym dowolnej liczby sztuk formularzy, które będą mogły być wypełniane z wykorzystaniem długopisu cyfrowego, a następnie dane z nich zaistnieją w systemie HIS. Przykładem takich formularzy może być formularz wywiadu przedmiotowego, formularz oświadczenia pacjenta o osobach uprawnionych do informacji o przebiegu leczenia, zgoda na przetwarzanie danych osobowych, formularze wywiadu anestezjologicznego. Wypełniony formularz będzie z wykorzystaniem USB lub innych łączy transmisyjnych przenoszony automatycznie do systemu szpitalnego importowany i mapowany na odpowiednie pola w systemie. System będzie umożliwiał zapis formularza w formie przetwarzalnej – rozkodowanej na poszczególne pola w bazie danych jak i zapis oryginału w postaci skanu np. w formacie PDF.

7. System będzie w szczególności udostępniał zestaw protokołów komunikacyjnych niskiego poziomu, które umożliwią pobieranie danych z repozytorium dokumentów do zewnętrznego Systemu w postaci dokumentów PDF oraz plików XML z metadanymi.

8. Integracja Systemu z oprogramowaniem HIS powinno w szczególności być zrealizowane poprzez:

9. System powinien udostępnić HIS’owi sieciowy interfejs on-line umożliwiający wydruk sprofilowanych ankiet w postaci mikrodruków.

10. System powinien udostępnić HIS’owi sieciowy interfejs on-line umożliwiający błyskawiczne pozyskiwanie i przekazywanie wszystkich danych dotyczących przeanalizowanych formularzy papierowych.

11. Wszystkie interfejsy sieciowe powinny zostać opracowane w technologiach zdalnego wywołania metod (WebService) i przekazane wraz z dokumentacją wykonawcom oprogramowania HIS

12. Brak możliwości odtworzenia danych z długopisu cyfrowego bez wgrania danych i zalogowania się do systemu.




H. Wymagania Funkcjonalne Systemu1. System umożliwia odwzorowanie (tak jakby został zeskanowany) formularza

papierowego w wersji elektronicznej.2. System umożliwia automatyczne powiązanie z rodzajem formularza, który

został z jego pomocą wypełniony.3. System umożliwia stworzenie dowolnego formularza bazując na dowolnym

dokumencie w formacie PDF.4. System umożliwia w importowanej ankiecie zaznaczenie regionów

aktywnych, pól tekstowych oraz nadanie im unikalnych nazw.5. System umożliwia wydruk formularza w ten sposób, aby każdy wydrukowany

formularz był unikalny (na zasadzie druku ścisłego zarachowania). Oznacza to, że wypełnienie papierowego formularza długopisem cyfrowym tworzy wzajemnie jednoznacznie przyporządkowaną do niego wersje elektroniczną dokumentu. Formularzy nie można kserować (skserowane formularz nie działają, a długopis sygnalizuje to). Funkcjonalność ta powinna być zrealizowana poprzez zapewnienie na każdym dokumencie unikalnego mikrodruku.

6. System umożliwia pobranie danych z długopisów cyfrowych za pomocą stacji dokującej USB bądź też komunikacji bezprzewodowej bluetooth. Dane są jednoznacznie przyporządkowywane do formularzy.

7. System umożliwia przeglądanie oraz eksport nieprzetworzonych danych z wypełnionych formularzy do formatu PDF będącego wizualizacją „skanów” wypełnionych dokumentów.

8. System umożliwia automatyczne rozpoznawanie zawartości pól tekstowych i pól numerycznych zarówno w obszarze pisma blokowego jak i pisma ciągłego (oprogramowanie typu ICR).

9. System umożliwia edycję i walidację przetworzonych danych zwizualizowanych na formularzu z pól tekstowych i pól numerycznych przy jednoczesnym podglądzie danych pochodzących bezpośrednio z długopisów cyfrowych.

10. System umożliwia eksport rozpoznanych danych (tj. pól tekstowych liczb i pól wyboru) do formatów MS Excel oraz plików CSV lub XML.

11. System umożliwia publikację dowolnego formularza stworzonego w Systemie na stronie internetowej.

12. System umożliwia wypełnianie formularzy stworzonych w Systemie w trybie on-line, tj. korzystając z dowolnej przeglądarki internetowej, także na urządzeniach przenośnych typu tablet.

13. Aplikacja końcowa umożliwia podgląd stanu podłączonych do komputera długopisów cyfrowych, w szczególności stanu ich naładowania.

14. System umożliwia nadawanie długopisom unikalnych nazw i przypisywania ich do użytkowników

15. System umożliwia odtwarzanie całej historii powstałego dokumentu z podziałem na czas w jakim dane elementy powstały oraz autorów poszczególnych wpisów.



XII. Szkolenia e-Learning

Spełnienie wymagań jest obligatoryjne. Oferowane szkolenia muszą spełniać wszystkie wymagania opisane poniżej, są one określone jako bezwzględnie wymagane. W przypadku niespełnienia któregokolwiek z wymagań oferta zostanie odrzucona jako niekompletna.

W ramach weryfikacji spełniania poniższych wymagań Wykonawca dokona prezentacji oferowanych szkoleń e-Learningowych na wskazanym przez Zamawiającego komputerze wyposażonym w dostęp do sieci Internet.

Lp. TAB. XIII. Opis Szkolenia e-Learning Spełnianie (TAK/NIE)

1.Szkolenia e-Learning muszą zostać dostarczone, co najmniej do obszarów określonych w tabelach III.A. i III.B.

2Lekcje muszą zawierać slajd wprowadzający („w tej lekcji nauczymy się …”) oraz podsumowujący slajd kończący („w tej lekcji nauczyliśmy się…”).

3. Lekcje składać się muszą z ekranów (nie będzie to film, aby nie obciążać sieci). 4. Lekcje powinny być czytane przez lektora (preferowany głos męski). 5. Lekcja będzie trwała 20 – 25 minut i będzie podzielona na etapy. 6. Każdy Etap będzie się składał z: 7. - części lekcyjnej ( animacji trwającej ok. 6-8 minut) podzielonej na kroki,

8.- w trakcie trwania animacji po kilku krokach będzie występowało ćwiczenie (około 2 ćwiczeń, gdzie ćwiczenie będzie miało około 5 poleceń).

9.Po przeprowadzonej lekcji nastąpi egzamin praktyczny – (będzie składał się on z zadań praktycznych do wykonania lub pytań testowych).

10. Lekcja powinna zatrzymywać się, wyróżniać i wyraźnie podkreślać ważne elementy.

11.

W czasie trwania lekcji musi być możliwość cofania i zatrzymania lekcji, a w przypadku potrzeby przewinięcia do przodu, platforma powinna wymusić konieczność przynajmniej jednokrotnego przejścia przez całą lekcję – test z danej lekcji będzie udostępniany po zaliczeniu lekcji.

12.Po zdanym egzaminie student będzie miał możliwość dowolnego poruszania się po lekcji do czasu wygaśnięcia uprawnień na platformie.

13.

Lekcje będą składane w pakiety dedykowane konkretnym rolom użytkowników np. pakiet dla personelu lekarskiego szpitala modułu x, pakiet dla personelu pielęgniarskiego szpitala modułu x (w przypadku modułu Izba przyjęć będzie to jeden pakiet).

14.Lekcje ogólne nt. interfejsu i standardów aplikacji będą dołączane do różnych pakietów.



Lp. TAB. XIII. Opis Szkolenia e-Learning Spełnianie (TAK/NIE)

27

Ćwiczenia powinny mieć charakter dobrze zdefiniowanego zadania, przykładowo: „przyjmij pacjenta o danych NN na Izbę przyjęć …”. Niektóre kroki mogą być prawidłowo wykonane na kilka sposobów. Jeśli student wykona nieprawidłowy ruch, program podpowie prawidłowy po jednokrotnej nieudanej próbie. Student dostanie kompletne opisane zadanie do wykonania.

15.Tekst wypowiadany przez lektora powinien być również wyświetlony na ekranie na żądanie studenta.

16.Egzamin będzie posiadać wprowadzenie, w którym będą wyjaśnione zasady jego przeprowadzenia i oceny. Na końcu będzie podsumowanie wyników testu.

17.Student będzie mógł wykonać egzamin kilkukrotnie w celu uzyskania lepszego wyniku.

18.Egzamin po zakończeniu będzie pokazać błędne odpowiedzi i pozwalać na przeskok do danego fragmentu lekcji, w którym to zagadnienie było omawiane.

19.Lekcje, ćwiczenia, egzaminy, będą pokazywać w którym momencie przerabianego materiału jest student i ile kroków zostało do końca (liczbowo np. krok 7 z 30).

20.W szkoleniu znajdzie się miejsce, slajd, screen - jeden poświęcony informacji, gdzie jest środowisko testowe w szpitalu i jak się do niego zalogować.

21.Szkolenie umożliwi wywołanie konkretnej sekcji podręcznika elektronicznego dotyczącej omawianego materiału (podręcznik w formacie HTML).



XIII. Migracja danych

W ramach aktualizacji systemu HIS do najnowszej wersji Zamawiający wymaga przeniesienia/udostępnienia poniższego zakresu danych. W tym celu Zamawiający zapewni Wykonawcy dostęp do aktualnie posiadanego systemu HIS na prawach Administratora systemu. Zakres migracji

1. Dane personelu (nazwisko, imię, numer prawa, specjalizacje)2. Użytkownicy systemu3. Struktura organizacyjna4. Instytucje kierujące5. Wykonywane usługi (badania laboratoryjne, diagnostyczne, konsultacje, porady, zabiegi )6. Terminarze pracy personelu medycznego7. Dane osobowe i adresowe pacjentów8. Dokumenty uprawniające9. Dokumenty UE10. Dane dotyczące wizyt

a. Data wizytyb. Lekarzc. Rozpoznaniad. Skierowaniee. Opis wizytyf. Wyniki badań zleconych i wykonanych w trakcie wizyty

11. Wizyty zaplanowane12. Dane dotyczące hospitalizacji (archiwalne i bieżące)

a. Data przyjęcia, data wypisu (w przypadku pacjentów wypisanych)b. Rozpoznania c. Skierowanied. Pobyty na oddziałache. Dane historii choroby (badanie podmiotowe, przedmiotowe, wywiad, epikryza)f. Wyniki badań wykonane w trakcie hospitalizacji

13. Zabiegia. Rozpoznaniab. Opis zabieguc. Personel uczestniczący w zabiegu

14. Dane rozliczeniowe z NFZa. Kolejkib. Statystyki kolejekc. Wykonane świadczeniad. Szablony rachunkówe. Faktury



XIV. Infrastruktura sprzętowa

Na potrzeby realizacji niniejszego postepowania Wykonawca dostarczy infrastrukturę sprzętową o parametrach nie gorszych od niżej opisanych.Projekt zakłada zbudowanie kompletnego rozwiązania sprzętowego i aplikacyjnego, na którym można uruchomić kompletne zintegrowane systemy HIS, RIS i PACS.

1) Serwery bazodanowe – 2 szt.

Dwa niezależne serwery z zainstalowanym sklastrowanym silnikiem bazy danych połączone w klaster. Takie rozwiązanie zapewnia redundancję (tylko jeden serwer wystarczy do działania systemu) i rozłożenie obciążenia pomiędzy dwoma serwerami.

Serwer bazodanowy – 2 szt.

Producent/nazwa urządzenia: ……………………………………..(wpisać nazwę )

Lp. Parametr Wymagania minimalne TAK/NIE1. Obudowa - do zabudowy w szafie serwerowej 19”

- wysokość maksymalnie 1U- wyposażona w komplet szyn mocujących oraz ramię do prowadzenia kabli, pozwalających na wysuwanie serwera do celów serwisowych bez konieczności jego wyłączania- mieszcząca co najmniej 8 dysków 2,5” hot-swap

2. Zasilacz - co najmniej dwie sztuki dla zapewnienia redundancji- minimum 500W- hot-swap

3. Chłodzenie - nadmiarowe wentylatory hot-swap4. Płyta główna - możliwość instalacji dwóch procesorów

- wyposażona w 24 gniazda na potrzeby instalacji modułów pamięci RAM- wyposażona w 4 porty interfejsy LAN 1Gb RJ45- wyposażona w dedykowany interfejs do zarządzania i monitoringu- wyposażona w dedykowany port do instalacji dodatkowej karty sieciowej, która nie będzie wykorzystywała żadnego z dostępnych w serwerze złącz PCIe- wyposażona w dedykowany port do instalacji kontrolera macierzowego, który nie będzie zajmował żadnego z dostępnych slotów PCIe

5. Procesor - zainstalowany 1 procesor 12 rdzeni, x86-64 bity, osiągający w testach SPECint_rate_base2006 dla tego



Lp. Parametr Wymagania minimalne TAK/NIEmodelu serwera w konfiguracji dwuporcesorowej, w konfiguracji dwuprocesorowej wynik nie gorszy niż 1189 punktów- zamawiający wymaga złożenia wraz z ofertą wyników w/w testów

6. Pamięć RAM - co najmniej 128 GB w pełni buforowanej pamięci DDR4 ECC- taktowanie co najmniej 2666 MHz- zastosowany typ kości pamięci dual-rank

7. Kontroler dysków

- co najmniej 1 szt.- instalowany w dedykowanym złączu lub zintegrowany z płytą główną serwera- obsługujący co najmniej 8 dysków SAS/SATA o przepustowości 12Gb/s- obsługujący poziomy zabezpieczenia RAID 0, 1, 5, 10, 50, 6- wyposażony w minimum 2GB pamięci cache zabezpieczonej przed utratą danych w przypadku utraty zasilania- możliwość dokupienia licencji pozwalającej na szyfrowanie dysków

8. Dyski twarde - minimum dwa dyski 300GB 12Gb SAS 15k 2,5”, hot-swap- dyski wyposażone w oprogramowanie układowe podpisane cyfrowo

9. Karty sieciowe - czteroportowa karta sieciowa 10Gb Base-T, zainstalowana w dedykowanym porcie na płycie głównej, niezajmująca żadnego slotu PCIe- 2x dwuportowa karta sieciowa 10Gb SFP+, w pełni wyposażona w odpowiednie wkładki SFP+ SR MM 10Gb

10. Karta zarządzająca i oprogramowanie do zarządzania

- dedykowany port RJ-45 1Gbps- możliwość zdalnego przejęcia konsoli serwera oraz podłączenia zdalnego napędów i obrazów ISO- wbudowany sprzętowy system weryfikacji poprawności i bezpieczeństwa oprogramowania układowego- licencja na oprogramowanie zarządzające producenta serwera

11. Gwarancja - minimum 3-letnia gwarancja producenta na części, robociznę i naprawę w miejscu instalacji typu On-Site z czasem reakcji NBD- w przypadku awarii, uszkodzone dyski pozostają w posiadaniu zamawiającego

2) Serwery aplikacyjne – 2 szt.

Dwa niezależne serwery wykorzystujące wirtualizację. Każdy z serwerów dysponuje wystarczającą mocą, aby utrzymać działające kompletne środowisko. Pliki maszyn wirtualnych znajdują się na



współdzielonej macierzy. W czasie normalnej pracy system pracuje rozproszony po obu serwerach, w momencie ewentualnej awarii wszystkie komponenty można uruchomić na jednej maszynie, dzięki dostępowi do tych samym plików maszyn wirtualnych z poziomu obu maszyn.

Serwer aplikacyjny – 2 szt.


Lp. Parametr Wymagania minimalne TAK/NIE1. Obudowa - do zabudowy w szafie serwerowej 19”

- wysokość 1U- wyposażona w komplet szyn mocujących oraz ramię do prowadzenia kabli, pozwalających na wysuwanie serwera do celów serwisowych bez konieczności jego wyłączania- mieszcząca co najmniej 8 dysków 2,5” hot-swap- możliwość rozbudowy o kolejną przestrzeń przeznaczoną na instalację dysków twardych

2. Zasilacz - co najmniej dwie sztuki dla zapewnienia redundancji- minimum 500W- hot-swap

3. Chłodzenie - nadmiarowe wentylatory hot-swap4. Płyta główna - możliwość instalacji dwóch procesorów

- wyposażona w 24 gniazda na potrzeby instalacji modułów pamięci RAM- wyposażona w 4 porty interfejsy LAN 1Gb RJ45- wyposażona w dedykowany interfejs do zarządzania i monitoringu- wyposażona w dedykowany port do instalacji dodatkowej karty sieciowej, która nie będzie wykorzystywała żadnego z dostępnych w serwerze złącz PCIe- wyposażona w dedykowany port do instalacji kontrolera macierzowego, który nie będzie zajmował żadnego z dostępnych slotów PCIe

5. Procesor - zainstalowane 2 procesory 10 rdzeni, x86-64 bity, osiągające w testach SPECint_rate_base2006 dla tego modelu serwera, w konfiguracji dwuprocesorowej wynik nie gorszy niż 959 punktów- zamawiający wymaga złożenia wraz z ofertą wyników w/w testów

6. Pamięć RAM - co najmniej 128 GB w pełni buforowanej pamięci DDR4 ECC- taktowanie co najmniej 2666 MHz- zastosowany typ kości pamięci dual-rank

7. Kontroler dysków

- co najmniej 1 szt.- instalowany w dedykowanym złączu lub zintegrowany z płytą główną serwera



Lp. Parametr Wymagania minimalne TAK/NIE- obsługujący co najmniej 8 dysków SAS/SATA o przepustowości 12Gb/s- obsługujący poziomy zabezpieczenia RAID 0, 1, 5, 10, 50, 6- wyposażony w minimum 2GB pamięci cache zabezpieczonej przed utratą danych w przypadku utraty zasilania- możliwość dokupienia licencji pozwalającej na szyfrowanie dysków

8. Dyski twarde - minimum dwa dyski 300GB 12Gb SAS 15k 2,5”, hot-swap- dyski wyposażone w oprogramowanie układowe podpisane cyfrowo

9. Karty sieciowe

- czteroportowa karta sieciowa 10Gb Base-T, zainstalowana w dedykowanym porcie na płycie głównej, niezajmująca żadnego slotu PCIe- 2x dwuportowa karta sieciowa 10Gb SFP+, w pełni wyposażona w odpowiednie wkładki SFP+ SR MM 10Gb

10. Karta zarządzająca i oprogramowanie do zarządzania

- dedykowany port RJ-45 1Gbps- możliwość zdalnego przejęcia konsoli serwera oraz podłączenia zdalnego napędów i obrazów ISO- wbudowany sprzętowy system weryfikacji poprawności i bezpieczeństwa oprogramowania układowego- licencja na oprogramowanie zarządzające producenta serwera

11. Gwarancja - minimum 3-letnia gwarancja producenta na części, robociznę i naprawę w miejscu instalacji typu On-Site z czasem reakcji NBD- w przypadku awarii, uszkodzone dyski pozostają w posiadaniu zamawiającego

3) Macierz podstawowa - akcesoria

Macierz podstawowa – 1 szt.


Dedykowana półka rozszerzająca do posiadanej przez Zamawiającego macierzy QSAN XS3224D – 1 szt

Lp. Parametr Wymagania minimalne TAK/NIE1. Minimalna liczba obsługiwanych

dysków12

2. Obudowa Do montażu w szafie rack z kompletem szyn mocujących

3. Gwarancja 3 lata NBD



Dyski twarde 8 szt.

Wszystkie dyski twarde muszą być kompatybilne z posiadaną przez Zamawiającego macierzą QSAN XS3224D

Lp. Parametr Wymagania minimalne TAK/NIE1. Pojemność 4TB2. interfejs SAS3. Prędkość obrotowa 7200 obr./min4. Rozmiar 3,5”

Dyski twarde 10 szt.

Wszystkie dyski twarde muszą być kompatybilne z posiadaną przez Zamawiającego macierzą QSAN XS3224D

Lp. Parametr Wymagania minimalne TAK/NIE1. Pojemność 600GB2. interfejs SAS3. Prędkość obrotowa 15 000 obr./min4. Rozmiar 3,5”

Uwaga: w przypadku awarii uszkodzone dyski pozostają u zamawiającego.

4) Macierz zapasowa – 1 szt.Macierz zapasowa – 1 szt.


Macierz dyskowa wyposażona w 10 dysków twardych o pojemności 4TB, NL-SAS bądź SATA, spełniająca poniższe kryteria.

Lp. Parametr Wymagania minimalne TAK/NIE1. Rozbudowa Do 18 dysków bez użycia półek zewnętrznych 2. Gwarancja 3 lata Next Business Day 3. Wentylatory 2 x hot swap/redundatne moduły wentylatora



4. Zasilanie dwa zasilacze redundatne min. 250W 5. Zewnętrzne

interfejsyPCIe z możliwością podłączenia kart 40Gb/SASPCIe z możliwością podłączenia Thunderbolt 3.0

6. Procesor Procesor 2 rdzeniowy Intel Xeon, minimum 3,3Ghz

7. System plików ZFS, EXT2 (Virtual Volume), EXT3 (Virtual Volume), EXT4 (Virtual Volume), FAT (Virtual Volume), NTFS (Virtual Volume)

8. RAID Pojedynczy dysk, RAID 0, RAID 1 (Disk Mirroring), RAID 5, RAID 5 + hot spare, RAID 6, RAID 10, RAID 50, RAID 60

9. Cache kontrolera 8GB DDR4 ECC U-DIMM, rozbudowa do 64GB10. Obsługa Dysków SATA SSD, NVMe SSD, SATA11. Interfejsy

sieciowe4x 1GbE RJ-452x 10GbE SFP+

12. Zarządzanie dyskami

SSD Cache, Auto Tiering, Thin provisioning, Deduplikacja,, SSD Trim, Migawki do 4096

13. Zarządzanie plikami i folderami

CIFS, FTP, SFTP and WebDAV client, Mount Cloud (Google Drive, OneDrive, Dropbox), WORM (Write Once Read Many protection)

14. Backup serwerów

Wsparcie dla: Acronis True Image, CA Brightstor ARCserve Backup, EMC Retrospect, Symantec Backup Exec, LaCie Silverkeeper, Time machine , replikacja blokowa w czasie rzeczywistym, zarządzanie harmonogramem backupów, XMirror, Backup do chmury: Amazon S3, Synchronizacja z chmurą: Google Drive, Windows OneDrive, Dropbox

15. Backup urządzeń końcowych

100 dożywotnich licencji na backup urządzeń końcowych, wraz z możliwością kopii Bare Metal Recovery

16. Wsparcie dla systemów

Windows

Mac OS X

Linux (minimum 2.6) and UNIX

Uwaga: w przypadku awarii uszkodzone dyski pozostają u zamawiającego.

5) Przełączniki sieciowe

Dwa niezależne przełączniki obsługujące równolegle technologię 1 Gb/s (służącą do komunikacji z urządzeniami poza systemem oraz wewnątrz z macierzą zapasową) oraz 10 Gb/s (obsługującą



wewnętrzną komunikację urządzeń składowych systemu – serwery bazodanowe, aplikacyjne, macierz podstawowa).Przełączniki pracujące w klastrze, oba połączone niezależnie z każdym urządzeniem składowym systemu – dzięki czemu mamy pełną redundancję połączeń i nieprzerwaną pracę w przypadku awarii pojedynczego przełącznika.

Przełączniki sieciowe – 2 szt.


Wymaga się aby urządzenia posiadały następujące porty, protokoły oraz spełniały następujące funkcje:

Lp. Parametr Wymagania minimalne TAK/NIE1. Ilość portów 12 portów SFP+ oraz 12 portów 10GBaseT niezależne2. Chłodzenie od przodu do tyłu obudowy3. Tablica MAC min. 16K4. Tablica ARP/NDP min. 2K5. Bufor 32Mb6. MTBF min. 133176 godzin7. Wydajność min. 357 Mp/s8. Przepustowość min. 480 Gb/s9. Dodatkowe porty Port USB

Port miniUSB Port zarządzania Out-of-band;

10. Możliwości zarządzania, komunikacji i uwierzytelniania

Web GUI HTTPs CLI Telnet SSH SNMP MIB RSPAN Radius TACACS+

11. Obsługiwane protokoły i standardy

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



Lp. Parametr Wymagania minimalne TAK/NIE 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 sFlow 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



Lp. Parametr Wymagania minimalne TAK/NIE Ilość reguł na listę min. 1023 na wejściu i 511

na wyjściu Zasilacz z certyfikatem 80+ CE mark, commercial FCC Part 15 Class A VCCI Class A Class A EN 55022 (CISPR 22) Class A Class A C-Tick EN 50082-1 EN 55024 CSA certified (CSA 22.2 #950) UL listed (UL 1950)/cUL IEC 950/EN 60950

12. Procesor min 800 Mhz13. RAM Min 1GB14. Flash Min 256MB15. ilość obsługiwanych

VLANMin 4k

16. DHCP Server min 2K rezerwacji17 Możliwości łączenia

w stos 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

18. Gwarancja Gwarancja 3 lata z naprawą bądź wymianą NBD

6. Oprogramowanie do tworzenia kopii zapasowych:

Tworzenie kopii zapasowych systemu (kopie zapasowe wszystkich komponentów są przechowywane na macierzy zapasowej):

kopie zapasowe bazy danych są tworzone bez zatrzymania pracy systemu co ustalony przedział czasu (np. co 4 godziny) (dodatkowa kopia zapasowa plików bazy danych jest przechowywana na macierzy głównej QSAN);

kopie zapasowe maszyn wirtualnych są tworzone po każdorazowej istotnej zmianie w ich systemach operacyjnych;

kopie zapasowe badań są tworzone na bieżąco zaraz po imporcie badań.

Oprogramowanie do tworzenia kopii zapasowych/licencja – 1 szt.



Producent/nazwa oprogramowania: ……………………………………..(wpisać nazwę )

Lp. Parametr Wymagania minimalne TAK/NIE1. Wymagania ogólne Oprogramowanie musi pozwalać na tworzenie

kopii co najmniej 5 maszyn wirtualnych Oprogramowanie musi współpracować z

infrastrukturą VMware w wersji 4.1, 5.0, 5.1, 5.5, 6.0 oraz Microsoft Hyper-V 2012, 2012 R2 i 2016. Wszystkie funkcjonalności w specyfikacji muszą być dostępne na wszystkich wspieranych platformach wirtualizacyjnych, chyba, że wyszczególniono inaczej

Oprogramowanie musi współpracować z hostami zarządzanymi przez VMware vCenter oraz pojedynczymi hostami.

Oprogramowanie musi współpracować z hostami zarządzanymi przez System Center Virtual Machine Manger, klastrami hostów oraz pojedynczymi hostami.

Oprogramowanie musi zapewniać tworzenie kopii zapasowych wszystkich systemów operacyjnych maszyn wirtualnych wspieranych przez vSphere i Hyper-V

Dla oprogramowania należy zapewnić wsparcie producenta na 3 lata w trybie 24/7

2. Całkowite koszty posiadania

• Oprogramowanie musi być licencjonowanie w modelu “per - maszyna wirtualna”. Wszystkie funkcjonalności zawarte w tym dokumencie powinny być zapewnione w tej licencji. Jakiekolwiek dodatkowe licencjonowanie (per zabezpieczony TB, dodatkowo płatna deduplikacja) nie jest dozwolone

• Oprogramowanie musi być niezależne sprzętowo i umożliwiać wykorzystanie dowolnej platformy serwerowej i dyskowej

• Oprogramowanie musi tworzyć “samowystarczalne” archiwa do odzyskania których nie wymagana jest osobna baza danych z metadanymi deduplikowanych bloków

• Oprogramowanie musi mieć mechanizmy deduplikacji i kompresji w celu zmniejszenia wielkości archiwów. Włączenie tych mechanizmów nie może skutkować utratą jakichkolwiek funkcjonalności wymienionych w



Lp. Parametr Wymagania minimalne TAK/NIEtej specyfikacji

• Oprogramowanie nie może przechowywać danych o deduplikacji w centralnej bazie. Utrata bazy danych używanej przez oprogramowanie nie może prowadzić do utraty możliwości odtworzenia backupu. Metadane deduplikacji muszą być przechowywane w plikach backupu.

• Oprogramowanie nie może instalować żadnych stałych agentów wymagających wdrożenia czy upgradowania wewnątrz maszyny wirtualnej dla jakichkolwiek funkcjonalności backupu lub odtwarzania

• Oprogramowanie musi zapewniać backup jednoprzebiegowy - nawet w przypadku wymagania granularnego odtworzenia

• Oprogramowanie musi zapewniać mechanizmy informowania o wykonaniu/błędzie zadania poprzez email lub SNMP. W środowisku VMware musi mieć możliwość akutalizacji pola „notatki” na wirtualnej maszynie

• Oprogramowanie musi mieć możliwość uruchamiania dowolnych skryptów przed i po zadaniu backupowym lub przed i po wykonaniu zadania snapshota w środowisku VMware.

• Oprogramowanie musi zapewniać bezpośrednią integrację z VMware vCloud Director 5.5, 5.6, 8.0, 8.10 i archiwizować również metadane vCD. Musi też umożliwiać odtwarzanie tych metadanych do vCD

• Oprogramowanie musi mieć wbudowane mechanizmy backupu konfiguracji w celu prostego odtworzenia systemu po całkowitej reinstalacji

• Oprogramowanie musi mieć wbudowane mechanizmy szyfrowania zarówno plików z backupami jak i transmisji sieciowej. Włączenie szyfrowania nie może skutkować utratą jakiejkolwiek funkcjonalności wymienionej w tej specyfikacji

• Oprogramowanie musi wspierać backup maszyn wirtualnych używających współdzielonych dysków VHDX na Hyper-V (shared VHDX)

• Oprogramowanie musi posiadać architekturę klient/serwer z możliwością instalacji wielu



Lp. Parametr Wymagania minimalne TAK/NIEinstancji konsoli administracyjnych.

3. Wymagania RPO • Oprogramowanie musi wykorzystywać mechanizmy Change Block Tracking na wszystkich wspieranych platformach wirtualizacyjnych. Mechanizmy muszą być certyfikowane przez dostawcę platformy wirtualizacyjnej

• Oprogramowanie musi automatycznie wykrywać i usuwać snapshoty-sieroty (orphaned snapshots), które mogą zakłócić poprawne wykonanie backupu. Proces ten nie może wymagać interakcji administratora

• Oprogramowanie musi wspierać kopiowanie plików na taśmy

• Oprogramowanie musi mieć możliwość wydzielenia osobnej roli typu tape server

• Oprogramowanie musi mieć możliwość kopiowania backupów do lokalizacji zdalnej

• Oprogramowanie musi mieć możliwość tworzenia retencji GFS (Grandfather-Father-Son)

• Oprogramowanie musi wspierać BlockClone API w przypadku użycia Windows Server 2016 z systemem pliku ReFS jako repozytorium backupu.

• Oprogramowanie musi mieć możliwość replikacji włączonych wirtualnych maszyn bezpośrednio z infrastruktury VMware vSphere, pomiędzy hostami ESXi, włączając asynchroniczną replikacją ciągłą. Dodatkowo oprogramowanie musi mieć możliwość użycia plików kopii zapasowych jako źródła replikacji.

• Oprogramowanie musi umożliwiać przechowywanie punktów przywracania dla replik

• Oprogramowanie musi umożliwiać wykorzystanie istniejących w infrastrukturze wirtualnych maszyn jako źródła do dalszej replikacji (replica seeding)

• Oprogramowanie musi posiadać takie same funkcjonalności replikacji dla Hyper-V

• Oprogramowanie musi wykorzystywać wszystkie oferowane przez hypervisor tryby transportu (sieć, hot-add, LAN Free-SAN)

• Oprogramowanie musi dawać możliwość tworzenia backupów ad-hoc z konsoli jak i z



Lp. Parametr Wymagania minimalne TAK/NIEklienta webowego vSphere

• Oprogramowanie musi przetwarzać wiele wirtualnych dysków jednocześnie (parallel processing)

4. Wymagania RTO • Oprogramowanie musi umożliwić uruchomienie wielu maszyn wirtualnych bezpośrednio ze zdeduplikowanego i skompresowanego pliku backupu, z dowolnego punktu przywracania, bez potrzeby kopiowania jej na storage produkcyjny. Funkcjonalność musi być oferowana niezależnie od rodzaju storage’u użytego do przechowywania kopii zapasowych. Dla srodowiska vSphere powinien być wykorzystany wbudowany w oprogramowanie serwer NFS. Dla Hyper-V powinna być zapewniona taka sama funkcjonalność realizowana wewnętrznymi mechanizmami oprogramowania

• Oprogramowanie musi pozwalać na migrację on-line tak uruchomionych maszyn na storage produkcyjny. Migracja powinna odbywać się mechanizmami wbudowanymi w hypervisor. Jeżeli licencja na hypervisor nie posiada takich funkcjonalności - oprogramowanie musi realizować jaką migrację swoimi mechanizmami

• Oprogramowanie musi umożliwiać pełne odtworzenie wirtualnej maszyny, plików konfiguracji i dysków

• Oprogramowanie musi umożliwiać pełne odtworzenie wirtualnej maszyny bezpośrednio do Microsoft Azure.

• Oprogramowanie musi umożliwić odtworzenie plików na maszynę operatora, lub na serwer produkcyjny bez potrzeby użycia agenta instalowanego wewnątrz wirtualnej maszyny. Funkcjonalność ta nie powinna być ograniczona wielkością i liczbą przywracanych plików

• Oprogramowanie musi mieć możliwość odtworzenia plików bezpośrednio do maszyny wirtualnej poprzez sieć, przy pomocy VIX API dla platformy VMware i PowerShell Direct dla platformy Hyper-V.

• Oprogramowanie musi wspierać odtwarzanie plików z następujących systemów plików:o Linux

- ext, ext2, ext3, ext4, ReiserFS (Reiser3),



Lp. Parametr Wymagania minimalne TAK/NIEJFS, XFS, Btrfs

o BSD - UFS, UFS2

o Solaris - ZFS, UFS

o Mac - HFS, HFS+

o Windows - NTFS, FAT, FAT32, ReFS

o Novell OES - NSS

• Oprogramowanie musi wspierać przywracanie plików z partycji Linux LVM oraz Windows Storage Spaces.

• Oprogramowanie musi umożliwiać szybkie granularne odtwarzanie obiektów aplikacji bez użycia jakiegokolwiek agenta zainstalowanego wewnątrz maszyny wirtualnej.

• Oprogramowanie musi wspierać granularne odtwarzanie obiektów Active Directory takich jak konta komputerów, konta użytkowników, grupy oraz pozwalać na odtworzenie haseł.

• Oprogramowanie musi wspierać granularne odtwarzanie Microsoft Exchange 2010 i nowszych (dowolny obiekt w tym obiekty w folderze "Permanently Deleted Objects").

• Oprogramowanie musi wspierać granularne odtwarzanie Microsoft SQL 2005 i nowsze.

• Oprogramowanie musi wspierać granularne odtwarzanie Microsoft Sharepoint 2010 i nowsze.

• Funkcjonalność ta nie może wymagać pełnego odtworzenia wirtualnej maszyny ani jej uruchomienia.

• Oprogramowanie musi indeksować pliki Windows i Linux w celu szybkiego wyszukiwania plików w plikach backupowych.

• Oprogramowanie musi używać mechanizmów VSS wbudowanych w system operacyjny Microsoft Windows

• Oprogramowanie musi wspierać także specyficzne metody odtwarzania w tym "reverse CBT" oraz odtwarzanie z wykorzystaniem sieci SAN

5. Monitoring • System musi zapewnić możliwość monitorowania środowiska wirtualizacyjnego



Lp. Parametr Wymagania minimalne TAK/NIEopartego na VMware vSphere i Microsoft Hyper-V bez potrzeby korzystania z narzędzi firm trzecich

• System musi umożliwiać monitorowanie środowiska wirtualizacyjnego VMware w wersji 4.1, 5.x oraz 6.0 – zarówno w bezpłatnej wersji ESXi jak i w pełnej wersji ESX/ESXi zarządzane przez konsole vCenter Server lub pracujące samodzielnie

• System musi umożliwiać monitorowanie środowiska wirtualizacyjnego Microsoft Hyper-V 2008 R2 SP1, 2012, 2012 R2 oraz 2016 zarówno w wersji darmowej jak i zawartej w płatnej licencji Microsoft Server zarządzane poprzez System Center Virtual Machine Manager lub pracujące samodzielnie.

• System musi mieć status „VMware Ready” i być przetestowany i certyfikowany przez VMware

• System musi mieć możliwość instalacji na systemach operacyjnych w wersjach 64 bitowych: o Microsoft Windows 2008 SP2 o Microsoft Windows 2008 R2 SP1 o Microsoft Windows 7 SP1o Microsoft Windows 8o Microsoft Windows 2012o Microsoft Windows 2012 R2o Microsoft Windows 8.1o Microsoft Windows 10o Microsoft Windows 2016

• System musi obsługiwać następujące bazy danych w wersjach 32 i 64 bitowych:o Microsoft SQL Server 2008o Microsoft SQL Server 2008 R2o Microsoft SQL Server 2012 R2o Microsoft SQL Server 2014o Microsoft SQL Server 2016

• System musi umożliwiać kategoryzacje obiektów infrastruktury wirtualnej niezależnie od hierarchii stworzonej w vCenter

• System musi umożliwiać tworzenie alarmów dla całych grup wirtualnych maszyn jak i pojedynczych wirtualnych maszyn

• System musi dawać możliwość układania



Lp. Parametr Wymagania minimalne TAK/NIEterminarza raportów i wysyłania tych raportów przy pomocy poczty elektronicznej w formacie HTML oraz Excel

• System musi dawać możliwość podłączenia się do kilku instancji vCenter Server i serwerów Hyper-V jednocześnie, w celu centralnego monitorowania wielu środowisk

• Silnik raportowania powinien być oparty o SQL Server Reporting Services w celu zapewnienia bezpiecznego dostępu do raportów dla wielu użytkowników z uwzględnieniem ról, jakie pełnią w organizacji

• System musi mieć wbudowane predefiniowane zestawy alarmów wraz z możliwością tworzenia własnych alarmów i zdarzeń przez administratora

• System musi mieć wbudowane połączenie z bazą wiedzy opisującą problemy z predefiniowanych alarmów

• System musi mieć centralną konsolę z sumarycznym podglądem wszystkich obiektów infrastruktury wirtualnej (ang. Dashboard)

• System musi mieć możliwość monitorowania platformy sprzętowej, na której jest zainstalowana infrastruktura wirtualna

• System musi zapewnić możliwość podłączenia się do wirtualnej maszyny (tryb konsoli) bezpośrednio z narzędzia monitorującego

• System musi mieć możliwość integracji z oprogramowaniem do tworzenia kopii zapasowych tego samego producenta

• System musi mieć możliwość monitorowania obciążenia serwerów backupowych, ilości zabezpieczanych danych oraz statusu zadań kopii zapasowych, replikacji oraz weryfikacji odzyskiwalności maszyn wirtualnych.

• System musi mieć możliwość granularnego monitorowania infrastruktury, zależnego od uprawnień nadanym użytkownikom dla platformy VMware

• System musi mieć możliwość monitorowania instancji VMware vCloud Director w wersji 5.5, 5.6, 8.0 oraz 8.10

6. Raportowanie • System raportowania musi umożliwić tworzenie raportów z infrastruktury wirtualnej bazującej na VMware ESX/ESXi 4.1, 5.x oraz 6.0, vCenter



Lp. Parametr Wymagania minimalne TAK/NIEServer 4.1, 5.x oraz 6.0 jak również Microsoft Hyper-V 2008 R2 SP1, 2012, 2012 R2i 2016.

• System musi wspierać wiele instancji vCenter Server i Microsoft Hyper-V jednocześnie bez konieczności instalowania dodatkowych modułów.

• System musi być certyfikowany przez VMware i posiadać status „VMware Ready”

• System musi instalować się na następujących systemach operacyjnych:o Microsoft Windows 2008 SP2 o Microsoft Windows 2008 R2 SP1 o Microsoft Windows 7 SP1o Microsoft Windows 8o Microsoft Windows 2012o Microsoft Windows 2012 R2o Microsoft Windows 8.1o Microsoft Windows 10o Microsoft Windows 2016

• System musi wspierać jako silnik bazodanowy następujące bazy danych:o Microsoft SQL Server 2008o Microsoft SQL Server 2008 R2o Microsoft SQL Server 2012o Microsoft SQL Server 2014o Microsoft SQL Server 2016

• System do prezentacji raportów powinien używać SQL Server Reporting Services w celu jednoczesnego dostępu do raportów wielu użytkowników z określonymi przez administrator systemu uprawnieniami.

• System musi być systemem bezagentowym. Nie dopuszcza się możliwości instalowania przez system agentów na monitorowanych hostach ESXi i Hyper-V

• System musi mieć możliwość eksportowania raportów do formatów Microsoft Word, Microsoft Excel, Microsoft Visio, Adobe PDF

• System musi mieć możliwość ustawienia harmonogramu kolekcji danych z monitorowanych systemów jak również możliwość tworzenia zadań kolekcjonowania danych ad-hoc

• System musi mieć możliwość ustawienia harmonogramu generowania raportów i dostarczania ich do odbiorców w określonych



Lp. Parametr Wymagania minimalne TAK/NIEprzez administratora interwałach

• Minimalny interwał czasowy dla zadań kolekcjonowania i raportowania musi wynosić min 1 godzinę

• System w raportach musi mieć możliwość uwzględniania informacji o zmianach konfiguracji monitorowanych systemów

• System musi mieć możliwość generowania raportów z dowolnego punktu w czasie zakładając, że informacje z tego czasu nie zostały usunięte z bazy danych

• System musi posiadać predefiniowane szablony z możliwością tworzenia nowych jak i modyfikacji wbudowanych

• System musi mieć możliwość analizowania „przeszacowanych” wirtualnych maszyn wraz z sugestią zmian w celu optymalnego wykorzystania fizycznej infrastruktury

• System musi mieć możliwość generowania raportów na podstawie danych uzyskanych z oprogramowania do tworzenia kopii zapasowych tego samego producenta

• System musi mieć możliwość generowania raportu dotyczącego zabezpieczanych maszyn wirtualnych, zdefiniowanych zadań tworzenia kopii zapasowych oraz replikacji jak również wykorzystania zasobów serwerów backupowych.

• System musi mieć możliwość generowania raportu planowania pojemności (capacity planning) bazującego na scenariuszach ‘what-if’.

• System musi mieć możliwość granularnego raportowania infrastruktury, zależnego od uprawnień nadanym użytkownikom dla platformy VMware

• System musi mieć możliwość generowania raportów dotyczących tzw. migawek-sierot (orphaned snapshots)

• System musi mieć możliwość generowania personalizowanych raportów zawierających informacje z dowolnych predefiniowanych raportów w pojedynczym dokumencie



XV. Sieć teleinformatyczna rozbudowa – zabezpieczenia sieciowe

1. System bezpieczeństwa sieciowego składający się z 3 urządzeń.

Urządzenia 1 i 2 zapewniające ochronę Firewall, Antywirus, IPS, DLP oraz Routing i VPN na styku sieci lokalnej (LAN) z siecią Internet (WAN). Urządzenia zostaną zainstalowane w dwóch lokalizacjach: serwerownia w budynku Szpitala oraz siedziba Biura Zarządu i muszą zapewnić bezpieczne połączenie VPN między nimi. Urządzenia muszą być w pełni kompatybilne ze sobą.

Urządzenie 3 zostanie zainstalowane w serwerowni Szpitala i musi zapewniać ochronę kont pocztowych oraz serwera pocztowego.



Urządzenie bezpieczeństwa sieciowego 1 – 1 szt.


Lp. FIREWALL Minimalne parametry techniczno-eksploatacyjne(wymagane przez Zamawiającego)

W każdej pozycji wpisać oświadczenie dot.

Zaoferowanego sprzętu/oprogramowania

– spełnia/nie spełnia: TAK / NIE

1 OGÓLNE WYMAGANIA

1.1Całość dostarczanego sprzętu i oprogramowania pochodzi z autoryzowanego kanału sprzedaży na terenie Polski

1.2

Oferowane urządzenia są nowe i nieużywane. Wyprodukowane nie wcześniej niż 6 miesięcy przed upływem terminu składania ofert. Oferowane urządzenia na dzień złożenia ofert nie są przeznaczone przez producenta do wycofania z produkcji lub sprzedaży.

1.3Na żądanie Zamawiającego na etapie badania i oceny ofert zostaną przedstawione testy poszczególnych funkcjonalności.

1.4Sprzęt i oprogramowanie nie posiada ograniczeń licencyjnych dotyczących liczby chronionych urządzeń po stronie sieci wewnętrznej.

1.5Autentykacja użytkowników odbywa się za pomocą wbudowanych mechanizmów urządzenia (lokalna lista użytkowników), LDAP lub Radius.

2 FUNKCJONALNOŚCI

2.1Router zapewniający dostęp do sieci Internet (porty WAN – RJ45) Funkcje: Brama Internetowa; NAT

2.2 Sieć LAN – możliwość tworzenia profili podsieci i VLAN; Funkcje: 2.2.1 Tworzenie wielu profili sieci (min. 5) 2.2.2 VLAN routing 2.2.3 IP routing

2.3Firewall - przepustowość min. 4000 Mbps (dla 64b ramki danych). Funkcje:

2.3.1 NAT, PAT, Bridge 2.3.2 Trawersowanie NAT (SIP/H.323/SCCP) 2.3.3 Tagowanie VLAN (802.1Q) 2.4 IPS – wykrywanie zagrożeń na podstawie sygnatur, wykrywanie







nowych zagrożeń na podstawie ruchu w sieci, przepustowość min 1,6Gbps. Funkcje:

2.4.1 Automatyczna aktualizacja sygnatur 2.4.2 Automatyczne wykrywanie ataków w tym DoS

2.5Antywirus – zabezpieczenie przed zagrożeniami typu wirus, spyware, worm i inne zagrożenia. Funkcje:

2.5.1 Automatyczna aktualizacja sygnatur

2.5.2 Kontrola ruchu pochodzącego z aplikacji w tym zaufanych aplikacji

2.5.3 Kwarantanna

2.6VPN –o wydajności min. 3,5Gbps (IPSec, mierzone dla pakietów 512b) i 200 Mbps (SSL). Funkcje:

2.6.1 SSL, IPSec 2.6.2 Autentykacja DES, AES, 3DES, SHA-1/MD5 2.6.3 Client pass-through 2.6.4 Kontrola antywirusowa 2.6.5 Aplikacja klienta VPN 2.7 Kontrola aplikacji. Funkcje 2.7.1 Wykrywanie aplikacji bez względu na protokół i port 2.7.2 Możliwość zablokowania ruchu aplikacji 2.7.3 Zapis w logach urządzenia

2.8Filtrowanie treści WWW – filtry tematyczne oraz w oparciu o czarną listę.

2.9 Antyspam – filtrowanie ruchu POP3, SMTP, IMAP 2.10 Kontrola pasma internetowego. Funkcje: 2.10.1 Przydział pasma 2.10.2 Kontrola w oparciu o grupy IP/VLAN 2.11 Liczba jednoczesnych sesji TCP: 1 500 000 2.12 Liczba dopuszczalnych nowych sesji TCP na sekundę: 25 000 2.13 Monitorowanie wycieku danych. Funkcje: 2.13.1 Znakowanie plików 2.13.2 Możliwość zablokowania transmisji pliku na zewnątrz

2.13.3 Możliwość zapisu w logach informacji o wyjściu pliku na zewnątrz

2.14 Logi z urządzenia i informacje o wydajności. Funkcje:







2.14.1 Zapis ruchu przychodzącego i wychodzącego 2.14.2 Zapis informacji o wykrytych zagrożeniach 2.14.3 Wysyłka logów na email zgodnie z zadanym harmonogramem 2.14.4 Wysyłka logów na serwer syslog

2.14.5Informacja z poziomu GUI o kondycji urządzenia – użycie zasobów (CPU, pamięć)

3 PORTY I PARAMETRY TECHNICZNE 3.1 Dostęp do Internetu: 3.1.1 WAN – min. 2 porty RJ45, 3.1.2 1 port USB z obsługą modemu 3G/4G 3.2 Sieć LAN: 3.2.1 LAN – min.12 portów RJ45 10/100/1000Mbps, 3.2.2 2 porty SFP (dopuszczalne porty współdzielone z RJ45) 3.3 DMZ – 1 port RJ45 10/100/1000Mbps 3.4 Zarządzanie – 1 port USB, 1 port RJ45

3.5 Wymiary i instalacja: urządzenie z możliwością instalacji w szafie RACK.

3.6 Zasilanie: Wbudowany zasilacz 220 – 240 V, 50/60 Hz, prąd zmienny.

4 OPROGRAMOWANIE I LICENCJE 4.1 Zarządzanie z poziomu przeglądarki internetowej po przez GUI.

4.2 Zarządzanie z poziomu CLI poprzez klienta SSH/Telnet

4.3Możliwość obsługi min. 550szt. oprogramowania klienckiego producenta firewall dla IPSEC VPN i SSL VPN wliczona w cenę urządzenia.

4.45 lat licencji na użytkowanie składników ochrony (jak IPS, antywirus, antyspam) i innych funkcjonalności (filtrowanie ruchu, VPN, firewall, kontrola aplikacji)

5 CERTYFIKATY

5.1 ICSA Labs w zakresie: IPS, Firewall, IPSec VPN, SSL VPN, Antywirus

5.2 Zgodność z: CE, VCCI, FCC Part 15 Class B. 6 GWARANCJA I WSPARCIE 6.1 5 lat gwarancji onsite

6.2 Wsparcie 24/7, wymiana urządzenia w przypadku awarii najpóźniej na







następny dzień roboczy.

Wkładki 10Gb SFP+ - 4szt.

Wkładki muszą być kompatybilne z posiadaną przez Zamawiającego macierzą QSAN XS3224D

Lp. Parametry Wymagania minimalne TAK/NIE1. Prędkość przesyłu danych 10Gb/s2. Medium transmisyjne Multi-mode fiber3. Złącze LC Duplex4. Wersja SFP+ / SR

Patchcordy światłowodowe – 14 szt.

Lp. Paramertry Wymagania minimalne TAK/NIE1. Patchcord światłowodowy Światłowód krosowy LC-LC duplex

50/125 OM3, MM, długość min. 2m







1 OGÓLNE WYMAGANIA








1.2



1.4Sprzęt i oprogramowanie nie posiada ograniczeń licencyjnych dotyczących liczby chronionych urządzeń po stronie sieci wewnętrznej.


2 FUNKCJONALNOŚCI

2.1Router zapewniający dostęp do sieci Internet (porty WAN – RJ45) Funkcje: Brama Internetowa; NAT

2.2 Sieć LAN – możliwość tworzenia profili podsieci i VLAN; Funkcje: 2.2.1 Tworzenie wielu profili sieci (min. 5) 2.2.2 VLAN routing 2.2.3 IP routing

2.3 Firewall - przepustowość min. 900 Mbps Funkcje:

2.3.1 NAT, PAT, Bridge 2.3.2 Trawersowanie NAT (SIP/H.323/SCCP) 2.3.3 Tagowanie VLAN (802.1Q)

2.4IPS – wykrywanie zagrożeń na podstawie sygnatur, wykrywanie nowych zagrożeń na podstawie ruchu w sieci, przepustowość min 600 Mbps. Funkcje:

2.4.1 Automatyczna aktualizacja sygnatur 2.4.2 Automatyczne wykrywanie ataków w tym DoS

2.5Antywirus – zabezpieczenie przed zagrożeniami typu wirus, spyware, worm i inne zagrożenia. Funkcje:

2.5.1 Automatyczna aktualizacja sygnatur

2.5.2 Kontrola ruchu pochodzącego z aplikacji w tym zaufanych aplikacji

2.5.3 Kwarantanna







2.6VPN –o wydajności min. 70Mbps (IPSec, mierzone dla pakietów 512b) i 30 Mbps (SSL). Funkcje:

2.6.1 SSL, IPSec 2.6.2 Autentykacja DES, AES, 3DES, SHA-1/MD5 2.6.3 Client pass-through 2.6.4 Kontrola antywirusowa 2.6.5 Aplikacja klienta VPN 2.7 Kontrola aplikacji. Funkcje 2.7.1 Wykrywanie aplikacji bez względu na protokół i port 2.7.2 Możliwość zablokowania ruchu aplikacji 2.7.3 Zapis w logach urządzenia

2.8Filtrowanie treści WWW – filtry tematyczne oraz w oparciu o czarną listę.

2.9 Antyspam – filtrowanie ruchu POP3, SMTP, IMAP 2.10 Kontrola pasma internetowego. Funkcje: 2.10.1 Przydział pasma 2.10.2 Kontrola w oparciu o grupy IP/VLAN 2.11 Liczba jednoczesnych sesji TCP: 800 000 2.12 Liczba dopuszczalnych nowych sesji TCP na sekundę: 12 000 2.13 Monitorowanie wycieku danych. Funkcje: 2.13.1 Znakowanie plików 2.13.2 Możliwość zablokowania transmisji pliku na zewnątrz

2.13.3 Możliwość zapisu w logach informacji o wyjściu pliku na zewnątrz

2.14 Logi z urządzenia i informacje o wydajności. Funkcje: 2.14.1 Zapis ruchu przychodzącego i wychodzącego 2.14.2 Zapis informacji o wykrytych zagrożeniach 2.14.3 Wysyłka logów na email zgodnie z zadanym harmonogramem 2.14.4 Wysyłka logów na serwer syslog

2.14.5Informacja z poziomu GUI o kondycji urządzenia – użycie zasobów (CPU, pamięć)

3 PORTY I PARAMETRY TECHNICZNE 3.1 Dostęp do Internetu: 3.1.1 WAN – min. 1 port RJ45, 3.1.2 1 port USB z obsługą modemu 3G/4G







3.2 Sieć LAN: 3.2.1 LAN – min.4 porty RJ45 10/100/1000Mbps,

3.3DMZ – 1 port RJ45 10/100/1000Mbps, możliwość konfiguracji DMZ z wykorzystaniem jednego z istniejących portów LAN.

3.4 Zarządzanie – 1 port USB, 1 port RJ45




4.2 Zarządzanie z poziomu CLI poprzez klienta SSH/Telnet

4.3Możliwość obsługi min. 180szt. oprogramowania klienckiego producenta firewall dla IPSEC VPN i SSL VPN wliczona w cenę urządzenia.

4.45 lat licencji na użytkowanie składników ochrony (jak IPS, antywirus, antyspam) i innych funkcjonalności (filtrowanie ruchu, VPN, firewall, kontrola aplikacji)

5 CERTYFIKATY

5.1 ICSA Labs w zakresie: IPS, Firewall, IPSec VPN, SSL VPN, Antywirus


6.2Wsparcie 24/7, wymiana urządzenia w przypadku awarii najpóźniej na następny dzień roboczy.





Lp. Minimalne parametry techniczno-eksploatacyjne(wymagane przez Zamawiającego)


Zaoferowanego sprzętu/oprogramowania – spełnia/nie spełnia: TAK

/ NIE1 OGÓLNE WYMAGANIA


1.2



1.4Sprzęt i oprogramowanie nie posiada ograniczeń licencyjnych dotyczących liczby chronionych kont pocztowych.


1.6 Obsługiwane tryby pracy: transparentny, Gateway,2 FUNKCJONALNOŚCI

2.1 System ochrony poczty posiadający:

2.1.1 Wsparcie dla co najmniej 2 domen pocztowych,

2.1.2 Mechanizm analizy i ochrony poczty przychodzącej i wychodzącej,

2.1.3Polityki filtrowania poczty w oparciu o adresy mailowe, adresy IP, nazwy domenowe,

2.1.4Email routing na bazie reguł lokalnych lub zewnętrznego serwera LDAP,

2.1.5Szczegółowe polityki wykrywania zagrożeń oraz spamu w tym definicja polityki w oparciu o użytkownika serwera LDAP,

2.1.6

Kwarantanna użytkownika z dostępem z poziomu przeglądarki internetowej z możliwością samodzielnego uwalniania wiadomości, informacja o pojawieniu się wiadomości w kwarantannie za pośrednictwem wiadomości email.

2.1.7 Archiwizacja poczty przychodzącej i wychodzącej

2.1.8 Backup poczty na lokalnym dysku lub zewnętrznych zasobach (co






/ NIEnajmniej iSCSI)

2.1.9Definicja czarnych i białych list adresów mailowych globalnie oraz dla poszczególnych użytkowników.

2.1.10 Monitorowanie wycieku danych i informacji poufnych

2.2 OCHRONA ANTYWIRUSOWA

2.2.1Skanowanie wiadomości SMTP oraz załączników (w tym skompresowanych), kwarantanna dla zainfekowanych pików,

2.2.2 Blokowanie załączników w oparciu o typ pliku

2.2.3Możliwość zdefiniowania co najmniej 10 polityk kontroli antywirusowej

2.2.4 Możliwość zdefiniowania komunikatów w języku polskim

2.2.5

Możliwość współpracy z dedykowaną usługą chmurową w celu zidentyfikowania nieznanych zagrożeń. Możliwość zatrzymania wiadomości w kolejce do czasu otrzymania wyniku skanowania z usługi chmurowej.

2.3 KONTROLA ANTYSPAMOWA

2.3.1

Metody filtrowania spamu w oparciu o: reputację adresów i domen pocztowych oraz sumy kontrolne wiadomości (z baz dostarczonych przez producenta oprogramowania), filtrowanie na podstawie treści i załączników (w tym plików graficznych i PDF), kategorie URL (co najmniej malware i hacking),

2.3.2Definiowanie różnych akcji dla poszczególnych metod wykrywania spamu

2.3.3 Kontrola nagłówka wiadomości, 2.3.4 Analiza Heurystyczna, 2.3.5 Współpraca z zewnętrznymi serwerami RBL/SURBL

2.3.6Filtrowanie w oparciu o filtry Bayes’a (z opcją dostrajania globalnie i na użytkowników)

2.3.7 Kwarantanna systemowa i użytkownika.

2.3.8

Kwarantanna użytkownika z dostępem z poziomu przeglądarki internetowej z możliwością samodzielnego uwalniania wiadomości, informacja o pojawieniu się wiadomości w kwarantannie za pośrednictwem wiadomości email.

2.3.9 Możliwość zdefiniowania co najmniej 10 polityk antyspamowych,164






/ NIE2.3.10 Kontrola w oparciu o greylisting oraz SPF,2.3.11 Ochrona typu outbreak

2.3.12Skanowanie antyspamowe z wydajnością co najmniej 2000 wiadomości na godzinę,

2.4 OCHRONA USŁUGI POCZTOWEJ

2.4.1 Ochrona przed atakami na adres odbiorcy

2.4.2Definiowanie maksymalnej ilości wiadomości otrzymanych w jednostce czasu

2.4.3 Anty-Spoofing – kontrola Reverse DNS2.4.4 Sprawdzenie poprawności adresu nadawcy

2.5 RAPORTOWANIE

2.5.1 Logi zdarzeń systemowych i zmian konfiguracji,

2.5.2 Logi o przetworzonych zagrożeniach,

2.5.3 Możliwość wysyłki logów do zewnętrznego serwera SYSLOG, 2.5.4 Powiadomienia administratora przez email o wykrytych zagrożeniach,2.5.5 Podgląd logów w czasie rzeczywistym,2.5.6 Predefiniowane szablony raportów z możliwością edycji,

2.5.7Możliwość generowania raportów zgodnie z harmonogramem i na żądanie.

2.6 AKTUALIZACJE SYGNATUR

2.6.1 W oparciu o bazę spamu oraz url 2.6.2 Bazy uaktualniane w czasie rzeczywistym

2.6.3Aktualizacja szczepionek antywirusowych zgodnie z ustalonym harmonogramem (co najmniej raz na godzinę)

2.6.4Bazy spamu oraz sygnatur wirusów muszą być dostarczane przez producenta urządzenia.

2.7 ZARZĄDZANIE 2.7.1 Z poziomu przeglądarki internetowej z użyciem protokołu https, 2.7.2 Przez SSH,

2.8 FUNKCJA SERWERA POCZTY






/ NIE

2.8.1Możliwość zdefiniowania co najmniej 50 lokalnych skrzynek pocztowych,

2.8.2 Integracja z serwerem LDAP 2.8.3 Obsługa SMTP, POP3, IMAP 2.8.4 Wsparcie szyfrowania SSL dla SMTP (SSL, TLS 1.0/1.1/1.2) 2.8.5 Interfejs webmail w języku polskim 3 PORTY I PARAMETRY TECHNICZNE 3.1 Co najmniej 4 interfejsy sieciowe RJ45, 3.2 Dysk twardy o pojemności co najmniej 500GB,




4.2 Zarządzanie z poziomu CLI poprzez klienta SSH

4.35 lat licencji na użytkowanie składników ochrony (jak antywirus, antyspam) i innych funkcjonalności

5 CERTYFIKATY

5.1 VBSpam and VB100 rated lub Common Criteria NDPP, FIPS 140-2 Certified


6.2Wsparcie 24/7, wymiana urządzenia w przypadku awarii najpóźniej na następny dzień roboczy.

Oprogramowanie wirtualizacyjne/licencja – 1 szt.








1.

Licencje powinny umożliwiać uruchomianie wirtualizacji (pełne wykorzystanie procesorów i pamięci operacyjnej) na trzech maksymalnie dwuprocesorowych serwerach fizycznych, oraz jednej konsoli do zarządzania całym środowiskiem.

2.

Wszystkie licencje powinny być dostarczone wraz z 3 letnim wsparciem, świadczonym przez producenta oprogramowania wirtualnego.

3.Wsparcie powinno umożliwiać zgłaszanie problemów 5 dni w tygodniu przez 12 godzin

4. Warstwa wirtualizacji powinna być rozwiązaniem systemowym tzn. powinna być zainstalowana bezpośrednio na sprzęcie fizycznym.

5.

Rozwiązanie powinno zapewnić możliwość obsługi wielu instancji systemów operacyjnych na jednym serwerze fizycznym i powinno się charakteryzować maksymalnym możliwym stopniem konsolidacji sprzętowej.

6.Oprogramowanie do wirtualizacji musi zapewnić możliwość skonfigurowania maszyn wirtualnych z możliwością dostępu do min 6TB pamięci operacyjnej.

7.Oprogramowanie do wirtualizacji musi zapewnić możliwość skonfigurowania maszyn wirtualnych do 128 procesorów wirtualnych każda z krokiem co jeden)

8.Rozwiązanie powinno umożliwiać łatwą i szybką rozbudowę infrastruktury o nowe usługi bez spadku wydajności i dostępności pozostałych wybranych usług.

9. Rozwiązanie powinno w możliwie największym stopniu być niezależne od producenta platformy sprzętowej.

10.

Rozwiązanie powinno wspierać następujące systemy operacyjne: Windows XP, Windows Vista, Windows 7 , Windows 2000, Windows Server 2003, Windows Server 2008, Windows Server 2008R2, Windows Server 2012, Windows Server 2016, RHEL w wersjach 3.x do 7.x, Debian w wersjach 6x – 9.x, CentOS w wersjach 5.x – 7.x, Oracle Linux w wersjach 4.9 – 7.x, FreeBSD w wersjach 7.x – 11.x, Ubuntu , SCO OpenServer, SCO Unixware.

11. Rozwiązanie powinno posiadać centralną konsolę graficzną do

zarządzania maszynami wirtualnymi i usługami.

12. Rozwiązanie powinno zapewnić możliwość monitorowania 167







wykorzystania zasobów fizycznych infrastruktury wirtualnej.

13.

Oprogramowanie do wirtualizacji powinno zapewnić możliwość wykonywania kopii migawkowych instancji systemów operacyjnych na potrzeby tworzenia kopii zapasowych bez przerywania ich pracy.

14.

Oprogramowanie do wirtualizacji powinno zapewnić możliwość klonowania systemów operacyjnych wraz z ich pełną konfiguracją i danymi.

15.

Oprogramowanie zarządzające musi posiadać możliwość przydzielania i konfiguracji uprawnień z możliwością integracji z usługami katalogowymi Microsoft Active Directory.

16.Rozwiązanie musi umożliwiać udostepnienie maszynie wirtualnej większej ilości zasobów dyskowych aniżeli fizycznie zarezerwowane.

17.Rozwiązanie powinno mieć możliwość przenoszenia maszyn wirtualnych w czasie ich pracy pomiędzy serwerami fizycznymi.

18.

Powinna zostać zapewniona odpowiednia redundancja i nadmiarowość zasobów tak by w przypadku awarii np. serwera fizycznego usługi na nim świadczone zostały przełączone na inne serwery infrastruktury. Czas niedostępności innych usług nie powinien przekraczać kilkunastu minut

19.

Rozwiązanie powinno umożliwiać łatwe i szybkie ponowne uruchomienie systemów/usług w przypadku awarii poszczególnych elementów infrastruktury.Rozwiązanie powinno zapewniać mechanizm bezpiecznego uaktualniania warstwy wirtualizacyjnej, hostowanych systemów operacyjnych (np. wgrywania patch-y) i aplikacji tak, aby zminimalizować ryzyko awarii systemu na skutek wprowadzenia zamiany.

8. Zasilacz awaryjny



Zasilacz awaryjny/UPS – 1 szt.


Lp. Parametr Wymagania minimalne TAK/NIE

1. Moc pozorna min. 10000 VA

2. Moc rzeczywista min. 9000 W

3. Architektura UPSa online

4. Kształt napięcia przy pracy akumulatorowej sinusoida

5. Czas przełączenia na baterię 0 ms

6. Liczba i rodzaj gniazdek z utrzymaniem zasilania 4 x IEC C13 4 x IEC C19

7. Typ gniazda wejściowego Zaciski8. Czas podtrzymania dla

obciążenia 100% 4 min

9. Czas podtrzymania przy obciążeniu 50% 12 min

10.Czas podtrzymania przy zastosowaniu zewnętrznych modułów bateryjnych (100%)

63 min

11. Zimny start tak

12. Układ automatycznej regulacji napięcia (AVR) tak

13. Napięcie znamionowe: 230V

14. Dopuszczalny zakres częstotliwości 40-70Hz

15. Porty komunikacji USB, Intellislot, RS232

16. Karta SNMP tak

17. Funkcja EPO - Emergency Power Off tak



Lp. Parametr Wymagania minimalne TAK/NIE

18. Typ baterii wewnętrznych: kwasowo-ołowiowe, bezobsługowe, co najmniej 12V - 9Ah

19. Czas ładowania baterii max. 5h - do 90%

20.Ilość zewnętrznych modułów baterii możliwych do dołączenia

max. 6

21. Możliwość pracy równoległej tak22. Komunikacja Diody sygnalizacyjne, LCD

23. Alarmy dźwiękowepraca z baterii, awaria sieci zasilającej, znaczne wyczerpanie baterii

24. Wyposażenie standardowe

Instrukcja obsługi, Kabel RS232, Kabel USB, Oprogramowanie na CD, Podstawki do montażu Tower Zintegrowany Bypass serwisowy

25. Typ obudowy 6U Rack / Tower, dostarczone szyny dynamiczne

26. Masa netto max. 75 kg27. Temperatura pracy zasilacza: od 0ºC do +40ºC28. Poziom hałasu: < 50 dBA

29. Certyfikaty:

• CE • RoHS2 (6 by 6) Compliant• REACH and WEEE Compliant• ISTA Procedure 1A/1E• TUV/GS and CE compliance mark and Australia C-tick (C√) mark

30. Gwarancja na urządzenie i baterie 36 m-cy

31. Rodzaj gwarancjiNaprawa/wymiana w miejscu użytkowania- okno zgłoszeń i napraw 5x8BD: dni robocze w godzinach 8.00-17.00- czas naprawy/wymiany /5BD: do 5 dni roboczych od zgłoszenia



XVI. Prezentacja systemu Zamawiający zastrzega sobie prawo do zaproszenia Wykonawców, którzy złożyli oferty, a ich

oferta nie została odrzucona lub nie zostali wykluczeni na prezentację oferowanego oprogramowania oraz weryfikacje zapisów oferty.

Prezentacja musi być przeprowadzona na testowym środowisku z przykładową bazą danych. W trakcie prezentacji komisja powołana do przeprowadzenia postępowania oceni zgodność z

prawdą zamieszczonych w ofercie informacji. Stwierdzenie jakiejkolwiek niezgodności z deklaracją w ofercie w zakresie wymagań

obligatoryjnych, wymaganych i ocenianych skutkować będzie odrzuceniem (podstawa prawna: art. 14 ustawy z dnia 16 kwietnia 1993 r. „o zwalczaniu nieuczciwej konkurencji”).

Prezentacja odbędzie się wyłącznie z wykorzystaniem laptopa z zainstalowanym i w pełni skonfigurowanym oferowanym systemem medycznym z uwzględnieniem oferowanych modułów.

Nie dopuszcza się, aby prezentowana wersja testowa systemu działała w wersji zdalnej przez jakiekolwiek połączenia zdalne albo była prezentacją multimedialną np. PowerPoint.

Wymagania dotyczące Oprogramowania będącego próbką:1) Zamawiający wymaga założenia konta użytkownika systemu posiadającego prawa

administracyjne do Oprogramowania, tak aby możliwe było założenie nowego użytkownika systemu, wprowadzenie danych testowych, wykonywanie wykazów oraz wszelkich innych czynności umożliwiających przeprowadzenie weryfikacji oferowanego Oprogramowania.

2) Niemożność uruchomienia Oprogramowania na zdeponowanym laptopie i przeprowadzenia weryfikacji funkcjonalności wskazanych w odpowiednim załączniku do SIWZ, skutkować będzie odrzuceniem oferty Wykonawcy jako niespełniającej wymagania postawione w SIWZ.

Wymagania dotyczące organizacji weryfikacji i oceny:1) Przewidywany czas weryfikacji to maksymalnie 6 godzin dziennie przy założeniu, że

weryfikacja będzie się odbywać w godzinach 9:00 – 15:00. Weryfikacja zostanie poprzedzona prezentacją z udziałem przedstawiciela Wykonawcy.

2) Zamawiający na czas prezentacji zapewni projektor z wejściem VGA/HDMI. Projektor będzie podłączony do laptopa zawierającego prezentację przed uruchomieniem laptopa, pozostanie stale włączony w trakcie prezentacji i będzie wyświetlać cały czas kopię bieżącego ekranu laptopa. Niedozwolone jest wygaszanie projektora, zatrzymywanie obrazu w projektorze oraz zmiana wejścia sygnałowego.

3) Do laptopa zawierającego prezentację nie wolno podłączać żadnych urządzeń zewnętrznych poza urządzeniami np. drukarka kodów kreskowych, czytnik OCR, mysz, klawiatura.

4) Laptop zawierający prezentację nie może w żaden sposób komunikować się z jakimkolwiek urządzeniem zewnętrznym z wykorzystaniem transmisji bezprzewodowej. Komisja przetargowa w celu weryfikacji tego wymagania może zażądać od Wykonawcy demonstracji stanu urządzeń komunikacyjnych w laptopie zawierającym prezentację, a



w szczególności wyłączenia wszystkich bądź części z nich w czasie pracy laptopa zawierającego prezentację.

5) Weryfikacja będzie prowadzona w oparciu o scenariusz opracowany przez Zamawiającego i zostanie przekazany Wykonawcom, którzy złożyli ofertę. Scenariusz prezentacji będzie zawierał te same funkcjonalności dla każdego z Wykonawców.

6) Weryfikacja będzie przebiegać zgodnie z kolejnością opisaną w scenariuszu prezentacji. Niedozwolone jest pomijanie punktów prezentacji. Przejście do kolejnego punktu możliwe jest wyłącznie po zakończonej pozytywnie weryfikacji punktu poprzedniego lub jednoznacznej deklaracji Wykonawcy, że poprzedni punkt nie zostanie zaprezentowany, co zostanie wpisane do protokołu z posiedzenia komisji przetargowej.

7) Łączny czas przerw z winy Wykonawcy nie może przekroczyć 1 godziny zegarowej, przy czym maksymalny czas jednej przerwy na wniosek Wykonawcy nie może przekraczać 30 minut zegarowych.

8) Komisja przetargowa może w trakcie weryfikacji zadawać Wykonawcy pytania zmierzające do ustalenia czy dana funkcjonalność jest realizowana. W trakcie prezentacji Wykonawca może udzielać Zamawiającemu dodatkowych informacji związanych z weryfikowaną funkcjonalnością.

9) Wykonawca na żądanie komisji przetargowej musi udostępnić na laptopie zawierającym prezentację:a) podgląd uruchomionych w systemie (lub systemach, jeśli komputer zawiera więcej

instalacji np. w oparciu o maszyny wirtualne) wszystkich procesów,b) podgląd zapytań SQL kierowanych do bazy danych w postaci nieszyfrowanej,c) podgląd ruchu sieciowego na wyszczególnionym interfejsie sieciowym i/lub porcie

sieciowym z uwzględnieniem stanu połączenia, adresu źródłowego i docelowego, typu protokołu oraz ilości pakietów bez podglądu zawartości pakietów,

d) podgląd konfiguracji interfejsów służących do komunikacji.10) Wykonawca powinien w sposób jednoznaczny wykazać, że weryfikowana funkcjonalność

jest dostępna w Oprogramowaniu, oraz że wybrane przez Zamawiającego funkcjonalności Oprogramowania są zgodne z wymaganiami opisanymi w Opisie przedmiotu zamówienia, stanowiącym odpowiedni załącznik do SIWZ.

11) Przeprowadzenie weryfikacji będzie udokumentowane pisemnym protokołem Komisji przetargowej, który zostanie włączony do akt przedmiotowego postępowania o udzielenie zamówienia publicznego oraz utrwaleniem wyłącznie przez Zamawiającego dźwięku i obrazu w postaci nagrania przeprowadzonej prezentacji.

12) Wykonawca w trakcie prezentacji nie może używać żadnych dodatkowych urządzeń elektronicznych, w szczególności: laptopów, tabletów, telefonów.

13) Podczas weryfikacji nie będzie oceniana szybkość działania Oprogramowania.

1) Podczas weryfikacji po stronie Wykonawcy może uczestniczyć tyle osób, ile on uzna za stosowne, aby skutecznie przeprowadzić weryfikację wskazanego Oprogramowania, jednak nie więcej niż trzy osoby w tym samym czasie. Wykonawca przedstawi listę osób uczestniczących w weryfikacji, ze wskazaniem jaką funkcję pełni każdy członek zespołu oraz załącza dla wskazanych osób informację o możliwości reprezentowania Wykonawcy na podstawie stosownych odpisów z rejestrów lub załączonego do oferty pełnomocnictwa do reprezentowania Wykonawcy. Rejestracja nagrania przeprowadzonej prezentacji zostanie użyta jako pomoc w sporządzeniu pisemnego protokołu z przeprowadzenia weryfikacji i stanowić będzie jednocześnie załącznik do przedmiotowej dokumentacji.



2) Bezpośrednio po otwarciu ofert Zamawiający wyznaczy kolejność prezentacji dla wszystkich wykonawców w drodze losowania na posiedzeniu jawnym w obecności wszystkich osób uczestniczących w otwarciu ofert.

3) Informacja o wyniku losowania zostanie przekazana wszystkim Wykonawcom zgodnie z danymi podanym w ofercie niezwłocznie po otwarciu ofert.

4) Pierwsza weryfikacja odbędzie się nie wcześniej niż 3 dni robocze po otwarciu ofert.5) Informacje o terminach prezentacji Zamawiający przekaże Wykonawcom zgodnie z podanym w

SIWZ sposobem komunikacji. Terminy wskazane przez Zamawiającego w wezwaniu nie będą krótsze niż 3 dni roboczych od dnia wysłania Wykonawcy wezwania.

6) Nie dopuszcza się prezentacji typu: Power Point, PDF itp.

Zamawiający zastrzega sobie możliwość interaktywnego udziału w prezentacji platformy szkoleniowej.

Zamawiający zastrzega sobie możliwość rejestracji Audio i Video prezentacji próbki oferowanych systemów.



XVII. Wdrożenie i szkolenia

Zakres wdrożenia obejmuje:a) instalację i konfigurację dostarczanych modułów części medycznejb) Parametryzację dostarczonych i wdrożonych modułów,c) Świadczenie asysty powdrożeniowej d) przeprowadzenie testów akceptacyjnych sparametryzowanego i skonfigurowanego

produkcyjnie oprogramowania aplikacyjnego e) przeprowadzenie szkoleń administratorów i użytkowników z dostarczanych modułówf) dostęp do platformy szkoleniowej dla pracowników Zamawiającego przez okres 4 miesięcy w

zakresie i na zasadach określonych w pkt XII niniejszego dokumentug) szkolenia stanowiskowe w wymiarze minimum 15 minut na stanowisko.


uczkin.pluczkin.pl/storage/files/zamówienia/Informatyka UE/SIWZ-Załącznik nr... · Web viewLp....

Documents

Transcript of uczkin.pluczkin.pl/storage/files/zamówienia/Informatyka UE/SIWZ-Załącznik nr... · Web viewLp....