Załącznik nr 3 do siwz opis przedmiotu zamówienia (opz) dot przetargu nieograniczonego znak: A/ZP/szp. 251-37/16 na: „dostawę wraz z wdrożeniem zintegrowanego elektronicznego systemu zarządzania dokumentacją medyczną”


Zintegrowany System Medyczny (ZSM)



Pobieranie 4.65 Mb.
Strona2/13
Data24.10.2017
Rozmiar4.65 Mb.
1   2   3   4   5   6   7   8   9   ...   13

Zintegrowany System Medyczny (ZSM)


Działanie systemu w zakresie części białej (medycznej z wyłączeniem modułu laboratorium) muszą wspierać komponenty infrastruktury odpowiadające za bezpieczeństwo, licencje, słowniki, komunikację asynchroniczną itp. Aplikacja kliencka dostępna za pośrednictwem przeglądarki WWW udostępni je w postaci usług sieciowych, dostępnych poprzez dedykowany protokół. Wymagany moduł Web API ma udostępniać wybrane usługi (związane z obsługą rejestracji pacjenta), celem wykorzystania ich np. w aplikacjach zintegrowanych z ZSM.

Wykorzystywane technologie implementacyjne


System ZSM ma zostać zaprojektowany zgodnie z standardami aplikacji klasy Enterprise aby zapewniać jak największą skalowalność, zarządzalność, wydajność, bezpieczeństwo i elastyczność.

Stan docelowy


Zamawiający wymaga aby w wyniku realizacji projektu uzyskał produkt w postaci wyposażonego w co najmniej zdefiniowane moduły ZSM opisane w dalszej części załącznika.
Etapy realizacji

Wykaz zadań planowanych do realizacji:



Nazwa wydatku (koszty kwalifikowalne)




Prace przygotowawcze

Szt./komplet

 Termin realizacji – w miesiącach licząc od dnia podpisania umowy z wybranym Wykonawcą

Opracowanie dokumentacji technicznej - analiza przedwdrożeniowa

1

do 1 miesiąca od podpisania umowy z wybranym Wykonawcą

Opracowanie dokumentacji technicznej - projekt instalacji teletechnicznej i systemu bezpieczeństwa

1

do 4 miesięcy od podpisania umowy z wybranym Wykonawcą

Zakup licencji Zintegrowanego Elektronicznego Systemu Zarządzania Dokumentacją Medyczną

liczba szt. licencja

 Termin realizacji – w miesiącach licząc od dnia podpisania umowy z wybranym Wykonawcą

Moduł Poradnia - Rejestracja

1

do 1 miesiąca od podpisania umowy z wybranym Wykonawcą

wraz z licencjami należy dostarczyć najwyższą/najszerszą z dostępnych u Wykonawcy usługę gwarancji, asysty technicznej i konserwacji producenta na okres minimum 60 miesięcy




Moduł Poradnia - Gabinet

1

Moduł Laboratorium

1

Moduł Ruch Chorych – izba przyjęć

1

Moduł Ruch Chorych – oddział

1

Moduł Ruch Chorych – statystyka

1

Moduł Rozliczeń

1

Moduł Dokumentacja Medyczna

1

Moduł Zlecenia Medyczne

1

Moduł Archiwum Dokumentacji

1

Moduł Blok Operacyjny/Porodowy

1

Moduł Pracownia Diagnostyczna

1

System Identyfikacji Pacjenta

1

Moduł Pracownia Diagnostyczna -RIS/PACS

1

Moduł Integracji HL7

1

Moduł Mikrobiologia

1

Moduł Zakażeń

1

Elektroniczny Medyczny Rekord Pacjenta

1

System Informowania Kierownictwa

1

Moduł Administracyjny

1

Apteka Centralna

1

Apteczki Oddziałowe

1

Podpis Elektroniczny dla 15 osób na okres 24 miesięcy

ilość miesięcy

 Termin realizacji – w miesiącach licząc od dnia podpisania umowy z wybranym Wykonawcą




360

do 12 miesięcy od podpisania umowy z wybranym Wykonawcą

Zakup licencji w celu świadczenia e-usług publicznych – e-Portal:

liczba szt. licencja

 Termin realizacji – w miesiącach licząc od dnia podpisania umowy z wybranymWykonawcą

e-Rejestracja

1

do 1 miesiąca od podpisania umowy z wybranym Wykonawcą
60-miesięczna gwarancja


e-Dokumentacja

1

e-Powiadomienia

1

e-Potwierdzenia

1

e-Kontrahent

1

e-Samokontrola

1

e-Konsultacje

1

e-Wywiad

1

e-usługi mobilne dla Pacjentów

1

Szyna integracyjna z Platformą P1

szt.

 Termin realizacji – w miesiącach licząc od dnia podpisania umowy z wybranym Wykonawcą




1

do 1 miesiąca od podpisania umowy z wybranym Wykonawcą

Wraz z licencjami należy dostarczyć najwyższą/najszerszą z dostępnych u Wykonawcy usługę gwarancji, asysty technicznej, serwisu i konserwacji producenta na okres minimum 60 miesięcy




Oprogramowanie bazodanowe

szt.

 Termin realizacji – w miesiącach licząc od dnia podpisania umowy z wybranym Wykonawcą




2

do 4 miesięcy od podpisania umowy z wybranym Wykonawcą

Prace instalacyjne, konfiguracyjne i optymalizacyjne

 Termin realizacji – w miesiącach licząc od dnia podpisania umowy z wybranym Wykonawcą

Instalacja i konfiguracja Zintegrowanego Elektronicznego Systemu Zarządzania Dokumentacją Medyczną

do 1 miesiąca od podpisania umowy z wybranym Wykonawcą

Instalacja i konfiguracja e-Portalu

do 12 miesięcy od podpisania umowy z wybranym Wykonawcą

e-Rejestracja

e-Dokumentacja

e-Powiadomienia

e-Potwierdzenia

e-Kontrahent

e-Samokontrola

e-Konsultacje

e-Wywiad

e-usługi mobilne dla Pacjentów

Instalacja i konfiguracja infrastruktury teleinformatycznej

do 4 miesięcy od podpisania umowy z wybranym Wykonawcą

Prace optymalizacyjne - testy i optymalizacja systemu teleinformatycznego

do 12 miesięcy od podpisania umowy z wybranym Wykonawcą

Zakup sprzętu teleinformatycznego

ilość szt.

 Termin realizacji – w miesiącach licząc od dnia podpisania umowy z wybranym Wykonawcą

Zestaw Serwerowy 1 komplet

1

do 4 miesięcy od podpisania umowy z wybranym Wykonawcą

Wyposażenie Centrum Przetwarzania Danych 1 komplet

1

do 4 miesięcy od podpisania umowy z wybranym Wykonawcą

Usługa kolokacji e-Portalu

Ilość miesięcy

 Termin realizacji – w miesiącach licząc od dnia podpisania umowy z wybranym Wykonawcą




24

do 12 miesięcy od podpisania umowy z wybranym Wykonawcą

W przypadku gdy dostarczany będzie inny system niż obecnie użytkowany, Wykonawca w ramach pierwszego etapu musi zapewnić przeniesienie wszystkich danych zgromadzonych w systemie,, w tym przeniesienie kont użytkowników z ich loginami i hasłami, szablonów wydruków, raportów i formularzy w układzie obecnie używanym przez Zamawiającego, danych rozliczeniowych oraz danych medycznych pacjentów i danych kontrahentów wprowadzonych do systemu w terminie zgodnym z Etapem realizacji to jest 1 miesiąc od podpisania umowy.Zamawiający wymaga zestawienia środowiska testowego, na którym zostaną przeprowadzone automatyczne i manulane testy poprawności importu.

Import w zakresie danych osobowych pacjentów.

Import danych w zakresie historii pobytów - ruchu chorych na oddziale.

Import danych w zakresie historii wizyt w poradni.

Import danych opisowych.

Import danych o pacjentach oczekujących (kolejki).

Import umów dla płatników NFZ.

Import umów dla płatników innych niż NFZ.

Import danych w zakresie grafików.

Import danych w zewnętrznego systemu PACS.

Zamawiający wymaga 100% zgodności danych

Dostawa platformy serwerowej i bazodanowej dedykowanej systemowi HIS wraz z migracją (w tym przeniesienie kont użytkowników z ich loginami i hasłami, szablonów wydruków i formularzy w układzie obecnie używanym przez Zamawiającego oraz danych medycznych pacjentów i danych kontrahentów wprowadzonych do systemu), instalacją i konfiguracją Zintegrowanego Elektronicznego Systemu Zarządzania. Uruchomienie w ramach dostarczonych licencji funkcjonalności modułów na nowej bazie danych i nowym sprzęcie serwerowym. Przeniesienie bazy danych funkcjonującej u Zamawiającego na nowe oprogramowanie bazodanowe wraz z konfiguracja zapewniającą ciągłość pracy i dostęp do danych zgromadzonych w systemie w tym przeniesienie kont użytkowników z ich loginami i hasłami, szablonów wydruków, raportów i formularzy w układzie obecnie używanym przez Zamawiającego oraz danych medycznych pacjentów i danych kontrahentów wprowadzonych do systemu.



Informacje nt Zamawiającego

Lekarze

163

Pielęgniarki i Położne

283

Kierownicy Medyczni

56

Pielęgniarki i Położne
Oddziałowe i Koordynujące

21

Technicy Medyczni

59

Salowe/robotnicy/
laboranci

116

Inni z Wyższym /
Naukowi nielekarze

125

Sekretarki Administracyjne

5

Sekretarki Medyczne

43

Pozostali - Administracja

135

Struktura jednostki (składająca się z VI pionów) jest rozbudowana, a jej główny trzon tworzą:

  • Poliklinika z 27 poradniami i gabinetem antropologicznym,

  • 7 Klinik wraz z dwoma Oddziałami (Chirurgii Kręgosłupa i Hospitalizacji Jednego Dnia),

  • 12 Zakładów wraz z Centralnym Laboratorium i Ambulatorium

  • Blok Operacyjny

  • Izba Przyjęć

Wykaz klinik i zakładów (wg stanu na koniec 2014 roku):

  1. Klinika Anestezjologii i Oddział Intensywnej Terapii

  2. Klinika Chirurgii Dzieci i Młodzieży

  3. Klinika Chirurgii Onkologicznej Dzieci i Młodzieży

  4. Klinika Neonatologii i Intensywnej Terapii Noworodka

  5. Klinika Neurologii Dzieci i Młodzieży

  6. Klinika Pediatrii

  7. Klinika Położnictwa i Ginekologii

  8. Izba Przyjęć

  9. Blok Operacyjny

  10. Oddział Chirurgii Kręgosłupa i Ortopedii

  11. Oddział Hospitalizacji Jednego Dnia

  12. Ambulatorium,

  13. Centralne Laboratorium

  14. Zakład Genetyki Medycznej

  15. Zakład Badań Przesiewowych

  16. Zakład Immunologii Klinicznej

  17. Zakład Diagnostyki Obrazowej

  18. Zakład Farmakologii

  19. Zakład Patomorfologii

  20. Zakład Usprawniania Leczniczego

  21. Zakład Żywienia

  22. Zakład Zdrowia Dzieci i Młodzieży

  23. Zakład Epidemiologii

  24. Zakład Zdrowia Prokreacyjnego

  25. Zakład Wczesnej Interwencji Psychologicznej


Założenia projektowe

  1. Opracowanie dokumentacji technicznej - analiza przedwdrożeniowa

Wykonawca w ramach wykonania przedmiotu zamówienia zobligowany będzie do opracowania metodologii założeń do wdrożenia zintegrowanego systemu teleinformatycznego, która umożliwi odpowiednie zaprojektowanie i wdrożenie systemu  oraz technologii informacyjno-komunikacyjnych. Powstała analiza stanowić będzie podstawę do dopasowania zaprojektowanego systemu teleinformatycznego do elektronicznego zarządzania dokumentacją medyczną, wdrozenia funkcjonalnosci, rozwiazan, raportow, m.in recept, punktow pobran, dokumentacji w wersji elektronicznej, podłączenia do HIS/LIS/PACS wszystkich wewnętrznych zakładów wykonujących badania/usługi na rzecz IMID, całościowych szkoleń dla personelu medycznego IMiD w tym certyfikowanych dla administratorów systemu z dostarczonego w ramach projektu oprogramowania, przeszkolenie pracownikow wyznaczonych także przez Partnerów projektu z zakresu obslugi oprogramowania wraz z dostarczeniem sprzętu/oprogramownia oraz świadczenia e-usług na rzecz Pacjentów oraz Partnerów w modelu SaaS z uwzględnieniem oczekiwań  w zakresie rezultatów. W celu prawidłowej implementacji systemu teleinformatycznego, niezbędne jest opracowanie dokumentacji technicznej w postaci analizy przedwdrożeniowej wraz z którą niezbędne jest dostarczenie dokumentacji struktury bazy danych wraz z dokumentacją procesów zachodzących w systemach HIS/LIS/PACS.

W skład Partnerów w niniejszym projekcie wchodzą:

- Samodzielny Zespół Publicznych Zakładów Opieki Zdrowotnej im. Dzieci Warszawy

05-092 Dziekanów Leśny, ul. Marii Konopnickiej 65

- Samodzielny Publiczny Zakład Opieki Zdrowotnej

05-430 Celestynów, ul. Regucka 5

- Samodzielny Publiczny Zakład Opieki Zdrowotnej

05-340 Kołbiel, ul. Szkolna 3

- Samodzielny Zespół Publicznych Zakładów Opieki Zdrowotnej w Wieliszewie

Wieliszew, ul. Modlińska 1


  1. Opracowanie dokumentacji technicznej - projekt instalacji teletechnicznej i systemu bezpieczeństwa

Wykonawca w ramach wykonania przedmiotu zamówienia zobligowany będzie do opracowania dokumentacji technicznej, która zapewnieni odpowiedni poziom zabezpieczeń i architektury bezpieczeństwa całej infrastruktury teleinformatycznej oraz Centrum Przetwarzania Danych. Z uwagi, iż celem projektu będzie wprowadzenie elektronicznej dokumentacji medycznej, i integracji
z platformą krajową P1, a także zważywszy na fakt przetwarzania danych wrażliwych w systemie oaz politykę bezpieczeństwa, niezbędne jest stworzenie bezpiecznej, redundantnej architektury teletechnicznej z uwzględnieniem aspektów bezpieczeństwa.

W wyniku realizacji projektu centrala część systemu wraz z bazami danych zostanie zainstalowana na klastrze redundantnych serwerów: dwóch serwerów bazodanowych oraz 2 serwerów aplikacyjnych, macierzy i bibliotece taśmowej – tworzące profesjonalną, infrastrukturę sprzętową pod Zintegrowany System Zarządzania Dokumentacją Medyczną. Taka konstrukcja architektury sprzętowej jako Klaster serwerów aplikacyjnych oraz klaster serwerów bazodanowych wymaga odpowiedniego zaprojektowania instalacji teletechnicznych oraz systemów bezpieczeństwa. Tym samym, opracowanie powyższej dokumentacji technicznej, jest elementem niezbędnym do prawidłowej implementacji systemu opartego o sprzęt teletechniczny wskazany w projekcie.



DOKUMENTACJA PROJEKTOWA POMIESZCZENIA SERWEROWNI

1.

Projekt wykonawczy architektury pomieszczenia serwerowni

Kpl.

1

2.

Projekt wykonawczy instalacji elektrycznych

Kpl.

1

3.

Projekt wykonawczy instalacji klimatyzacji i wentylacji

Kpl.

1

4.

Projekt instalacji teletechnicznych  oraz systemów bezpieczeństwa

Kpl.

1

5.

Projekt systemu gaszenia gazem FM-200

Kpl.

1

6.

Przygotowanie wydruków  dokumentacji projektowej - 5 Kpl.

Kpl.

1

  1. Zintegrowany Elektroniczny System Zarządzania Dokumentacją Medyczną – 1 szt., obejmujący następujące moduły:

  • Moduł Poradnia – Rejestracja

  • Moduł Poradnia - Gabinet

  • Moduł Laboratorium

  • Moduł Ruch Chorych – Izba Przyjęć

  • Moduł Ruch Chorych – oddział

  • Moduł Ruch Chorych – statystyka

  • Moduł Rozliczeń

  • Moduł Dokumentacja Medyczna

  • Moduł Zlecenia Medyczne

  • Moduł Archiwum Dokumentacji

  • Moduł Blok Operacyjny/Porodowy

  • Moduł Pracownia Diagnostyczna

  • System Identyfikacji Pacjenta

  • Moduł Pracowania Diagnostyczna RIS/PACS

  • Moduł Integracji HL7

  • Moduł Mikrobiologia

  • Moduł Zakażeń

  • Elektroniczny Medyczny Rekord Pacjenta

  • System Informowania Kierownictwa

  • Moduł Administracyjny

  • Apteka Centralna

  • Apteczki Oddziałowe

System zarządzania dokumentacją medyczną powinien umożliwiać wprowadzenie Elektronicznej Dokumentacji Medycznej (EDM) i integrację wszystkich aplikacji medycznych w jeden organizm, gromadząc dane niezbędne do wspomagania decyzji oraz prowadzenia elektronicznej dokumentacji medycznej. System zarządzania dokumentacją medyczną będzie stanowił również podstawę do uruchomienia e-usług publicznych świadczonych za pomocą e-Portalu. Ze względu na skalę przedsięwzięcia wdrożeniowego oraz liczbę użytkowników (w Instytucie zatrudnionych ok 1000 osób- dane na 2015r.) przewidziano nabycie licencji otwartych (nieograniczonych) objętych pięcioletnią gwarancją wraz z aktualizacją tzn. modułów bez limitu użytkowników, co oznacza iż system jest skalowalny w osi czasu i gwarantuje trwałość projektu. Zakup powyższych modułów zintegrowanego systemu zarządzania dokumentacją medyczną jest niezbędny do zapewnienia funkcjonowania systemu mającego na celu archiwizację, przetwarzanie i udostępnianie danych związanych z realizacją procesu diagnostyczno-terapeutycznego. System będzie funkcjonował nie tylko na urządzeniach stacjonarnych (PC) lecz również będzie kompatybilny z urządzeniami mobilnymi jak tablety, e-długopisy cyfrowe czy infomaty. Zintegrowana konstrukcja modułowa systemu będzie skutkowała tym, że raz wprowadzone do systemu dane będą w nim widoczne na różnych poziomach i nie będzie konieczne wprowadzanie ich kilkukrotnie, czy przepisywanie do innych modułów, co stanowi uproszczenie nie tylko dla personelu, lecz również pacjenta, gdyż wiąże się z szybszą obsługą oraz bezpieczeństwem dokumentacji.

W ramach projektu zostaną nabyte niezbędne moduły systemu zarządzania dokumentacją medyczną, które umożliwią wprowadzenie EDM oraz będą podstawą do uruchomienia e-usług świadczonych za pośrednictwem E-Portalu.



Poniżej umieszczono ogólny opis głównych funkcji każdego z modułów zintegrowanego systemu zarządzania dokumentacją medyczną, które wspólnie tworzyć będą jeden zintegrowany system zarządzania dokumentacją medyczną i stanowią podstawę do wdrożenia e-usług publicznych:

  • Moduł Poradnia – Rejestracja – powinien zapewniać funkcje związane z przyjęciem pacjenta do poradni, wyznaczeniem daty wizyty i numeru gabinetu, w którym ma się ona odbyć, jak również wyborem lekarza. W module prowadzona będzie baza pacjentów z możliwością przeglądania, wyszukiwania, dodawania i edycji danych. W module będą również zbierane informacje o opiekunach, osobach upoważnionych, ubezpieczeniach itp. System powinien prowadzić pełną historię zmian danych osobowych pacjenta, oraz przechowywane będą informacje o dacie modyfikacji i użytkowniku który dokonał zmiany, zapewniając tym samym pełną archiwizację zmian na karcie pacjenta wraz z datami jej wprowadzania. Moduł powinien umożliwiać łatwe dodawanie i sprawdzenie terminów wizyt oraz zapewni mechanizm kontroli liczby wizyt dodatkowych (wykluczanie nakładania się rejestracji w tym samym czasie dla danego pacjenta, lekarza lub gabinetu). Dzięki integracji modułu z pozostałymi modułami systemu, w jednym miejscu powinno być możliwe sprawdzenie grafików i dostępności lekarzy, gabinetów lub możliwości dodatkowego wykonania badań w określonym czasie. Ponadto, moduł powinien posiadać mechanizmy weryfikacji uprawnień pacjenta do wykonania usługi w ramach umowy NFZ itp. W momencie rezerwacji, a następnie ponownie na etapie rejestracji.

  • Moduł Poradnia – Gabinet powinien realizować funkcje związane z przyjęciem pacjenta, wykonaniem na jego rzecz usług i procedur medycznych, wyznaczeniem kolejnej wizyty i numeru gabinetu, w którym ma się ona odbyć, jak również wyborem lekarza. Moduł powinien umożliwiać gromadzenie danych medycznych związanych z wizytą pacjenta tj:

    • Rozpoznanie,

    • Wywiad,

    • Badania,

    • Zastosowane leczenie,

    • Zalecenia

    • recepty

W module powinny być gromadzone także dane o wadze i wzroście pacjenta, BMI, możliwość odnotowania wykonanych pacjentowi w trakcie wizyty elementów leczenia (opis, procedury, leki, badania, zabiegi, konsultacje, odnotowanie o zużytych podczas wizyty materiałach, zapis świadczeń NFZ itp.).

  • Moduł Laboratorium powinien gromadzić dane z badań laboratoryjnych oraz prowadzić kontrolę ilości odczynników, materiałów zużywalnych, kalibratorów będących na stanie magazynu. Moduł zapewni m.in. automatyczne kierowanie badań do stanowisk, na których mają być wykonane, z uwzględnieniem alternatywnych metod wykonywania, w tym możliwość przekierowywania badań do innej pracowni oraz zapewni archiwizację pełnych wyników diagnostycznych wraz z opisami i uwagami, kontrolę jakości i wiarygodności wyników.

  • Moduł Ruch Chorych – izba przyjęć powinien pozwolać na zapis danych pacjenta w izbie przyjęć, wykonanych zabiegów, postawionych diagnoz itp. Moduł umożliwi prezentacje raportów statystycznych określające liczbę różnych rodzajów przypadków w izbie przyjęć. Moduł powinien umożliwić prowadzenie rejestru pacjentów (wspólnego dla wszystkich modułów) z możliwością przeglądu danych archiwalnych dotyczących danych z poszczególnych pobytów w szpitalu (rejestr pobytów).

  • Moduł Ruch Chorych – oddział powinien realizować funkcje związane z przyjęciem pacjenta na oddział, rejestracją danych dotyczących jego pobytu na oddziale, przeniesieniem na inny oddział lub wypisem ze szpitala.

  • Zadaniem modułu Ruch Chorych – Statystyka powinno być umożliwienie prowadzenia ksiąg szpitalnych (Księgi Głównej, Ksiąg Oddziałowych, Księgi Zgonów, Księgi Noworodków) w postaci elektronicznej, przygotowanie kart statystycznych oraz tworzenie analiz statystycznych na podstawie danych zgromadzonych w systemie.

  • Moduł Rozliczeń powinien umożliwiać w szybki i prosty sposób kompleksowe rozliczenie jednostki z NFZ, a także umożliwiać wczytywanie elektronicznych wersji umów oraz aneksów z NFZ, wyszukiwanie kontekstowe oraz prezentowanie informacji o rozliczeniach z kanału RSS Narodowego Funduszu Zdrowia.

  • Moduł Dokumentacja Medyczna powinien pozwlać na gromadzenie sukcesywnie całości dokumentacji odzwierciedlającej proces terapeutyczny związany z konkretnym pobytem pacjenta w placówce wraz z możliwością prezentacji wszystkich danych wprowadzonych do modułu dokumentacji medycznej w ujęciu chronologicznym. Możliwość zapisu następujących elementów dokumentacji medycznej: obserwacje lekarskie, obserwacje pielęgniarskie, zalecenia, epikryza, notatki, wywiad. Możliwość definiowania wywiadów, na których lekarz może zaznaczyć punkty na graficznym schemacie (np. organu), a następnie opisać zaznaczone punkty, możliwość tworzenia własnej struktury hierarchicznej dokumentów.

  • Moduł Zalecenia Medyczne powinien pozwalać na śledzenie zleceń dla wybranego pacjenta oraz umożliwiać wprowadzanie, zmianę, anulowanie zleceń wraz z odpowiednimi wydrukami, jak również wprowadzanie, zmianę i przegląd wyników.

  • Moduł Archiwum Dokumentacji – Moduł powinien pozwolać na zapis aktualnego miejsca przechowywania dokumentacji, jak również na śledzenie historii lokalizacji dokumentacji.

  • Moduł Blok Operacyjny/Porodowy - powinien umożliwiać zebranie wszystkich danych niezbędnych do odzwierciedlenia przeprowadzonego zabiegu w dokumentacji medycznej pacjenta. Moduł powinien umożliwiać przypisanie zespołów chirurgicznych i anestezjologicznych do wykonania danych operacji, możliwość ustalania dat oraz sali operacyjnej w planowaniu zabiegów, potwierdzanie przyjęcia pacjenta na wykonanie zabiegu oraz ewidencję wykonanych procedur medycznych. Moduł powinien umożliwić m.in. prezentację zaplanowanych zabiegów z uwzględnieniem następujących informacji: rozpoznanie, skład zespołu operacyjnego, sala operacyjna, pacjent, planowana data wykonania, rodzaj planowanego znieczulenia. W module powinna być możliwość zarówno autoryzacji (np. przez ordynatora oddziału) lub odrzucenia wykonania operacji z podaniem przyczyny.

  • Moduł Pracownia Diagnostyczna – w module powinna być możliwość prowadzenia ewidencji badań i wyników w tym m.in.: realizacja zlecenia w pracowni (zaplanowanie badania, rejestracja badania, opis, zużycie zasobów, weryfikacja wyników), możliwość wprowadzania danych zlecenia i wyników badań w postaci ustrukturyzowanych formularzy składających się z różnego rodzaju pól (m. in. pola tekstowe, pola numeryczne, pola wyboru, listy rozwijane, pola z datą oraz pole umożliwiające załączenie pliku związanego z danym badaniem), możliwość wprowadzenia jednego opisu badania dla kilku badań zleconych dla jednego pacjenta w ramach jednej jednostki wykonującej i tego samego formularza wynikowego, możliwość tworzenia predefiniowanych fraz opisowych / wzorców / szablonów tekstów możliwych do późniejszego wykorzystania przez użytkownika lub grupę użytkowników z możliwością określenia ich dostępności. Moduł powinien umożliwiać prowadzenie terminarza pracy pracowni/zakładu z możliwością rezerwowania czasu dla poszczególnych urządzeń diagnostycznych oraz lekarzy.

  • System Identyfikacji Pacjenta jpowinien umożliwiać zaopatrywanie (identyfikację) pacjenta w niezbędne znaki identyfikacyjne umieszczone na opaskach dedykowanych dla noworodków, dzieci, dorosłych bez konieczności korzystania z innej aplikacji niż moduł ruch chorych Systemu. Znak identyfikacyjny nadany przez system powinien zawierać informacje pozwalające na ustalenie imienia i nazwiska oraz daty urodzenia pacjenta, zapisane w sposób uniemożliwiający identyfikację pacjenta przez osoby nieuprawnione.

  • Moduł Pracownia Diagnostyczna RIS/PACS - Moduł obsługi zakładu diagnostyki obrazowej powinien zapewniać płynną pracę całego zakładu, precyzyjną ewidencję i raportowanie oraz współpracę z urządzeniami pracującymi w standardzie DICOM. Moduł ogólno-szpitalnej dystrybucji obrazów zapewni bieżący dostęp do aktualnych i historycznych badań z dowolnego miejsca w jednostce Służby Zdrowia. Moduł powinien archiwizować zarówno wyniki obrazowe w jakości diagnostycznej (DICOM) , jak również ich odpowiedniki w jakości referencyjnej (w formacie JPG).

  • Moduł Integracji HL7 - Koncepcja tworzenia szpitalnych zintegrowanych systemów informatycznych na świecie opiera się na wykorzystaniu otwartych, uznanych międzynarodowych standardów wymiany danych takich jak HL7. Standard HL7 powinien pozwolać na wymianę danych on-line z wykorzystaniem protokołu TCP/IP lub wymianę plikową. Wymiana danych może zawierać szeroki zakres informacji: zlecanie badań do systemów specjalistycznych, zlecanie leków do systemu aptecznego, wymianę danych z systemami finansowymi itp.

  • Moduł Mikrobiologia powinien umożliwiać obsługę pracowni bakteriologicznej poprzez automatyzację pracy wykonywanej w pracowni. Moduł powinien zawierać m.in. definicje słowników obejmujące: podłoża, antybiotyki stosowane w pracowni, organizmy, mechanizmy lekooporności, komentarze, możliwość automatyzacji pracy poprzez wspomaganie procesu doboru antybiotyków, lekooporności, wykonywanie raportów i statystyk, zarówno ilościowych, jak także dotyczących mikroorganizmów, lekooporności oraz możliwość podłączenia medycznych aparatów mikrobiologicznych. Moduł powinien wspomagać wieloetapową pracę nad wynikiem oraz zapewniać bogate możliwości raportowania i statystyk.

  • Moduł Zakażeń powinien umożliwiać obsługę stanowiska ds. zakażeń. Informacje o zakażeniu powinny być wprowadzane w kontekście pobytu pacjenta w szpitalu. Komplet informacji o zakażeniu gromadzony za pomocą formularzy zorganizowanych w jedną funkcję przy wykorzystaniu zakładek. Osoba odpowiedzialna za rejestrację karty zakażeń powinna mieć możliwość przeglądania informacji dotyczących wykonania procedur, wyników badań laboratoryjnych oraz podań leków.

  • Elektroniczny Medyczny Rekord Pacjenta – (tzw. EPR – Elektronic Patient Record) powinien umożliwiać kompletny zapis wszelkich danych dotyczących stanu zdrowotnego pacjenta i zastosowanego leczenia tj. gromadzi w jednym miejscu wszystkie informacje związane z danym pacjentem. Moduł powinien umożliwiać klarowną prezentację krytycznych danych na stałe związanych z pacjentem m.in.: alergie, chroniczne choroby, inne stany i cechy, które mogą mieć wpływ na leczenie, a także zapewni logiczną prezentację danych przychodzących z modułów i systemów satelitarnych (wyniki z laboratorium, diagnostyki obrazowej itp.), i hierarchiczną ważność prezentowanych danych (zgodność z chronologią i akcentowanie odchyleń od wartość prawidłowych).

  • System Informowania Kierownictwa powinien umożliwiać szybki i pewny dostęp do informacji niezbędnych do prawidłowej oceny sytuacji jednostki Służby Zdrowia. Połączenie z pozostałymi modułami systemu informatycznego oraz programami zewnętrznymi powinno gwarantować uzyskiwanie realnych, bieżących informacji na temat kosztów wykonywanych procedur i świadczeń medycznych. Moduł powinien umożliwiać pełną kontrolę nad Szpitalem/Poradnią oraz umożliwiać analizę stopnia realizacji kontraktów wraz z analizą ich opłacalności, także pod kątem optymalnego wykorzystania zasobów.

  • Moduł Administracyjny powinien umożliwiać administrowanie systemem przez pracowników Działu Informatyki tj. nadawanie uprawnień poszczególnym grupom pracowników Jednostki. Moduł będzie wymagany do prawidłowego funkcjonowania i nadawania uprawnień systemowych dla użytkowników.

  • Moduł Apteka Centralna powinien stanowić kompleksowe rozwiązanie umożliwiające informatyzację wszystkich obszarów funkcjonalnych związanych z apteką szpitalną. Powinien umożliwiać prowadzenie dystrybucji leków na oddziały, notowanie zamówień i zakupów, zarządzanie magazynem, tworzenie zestawień, analiz oraz prowadzenie rozliczeń, wraz z wyznaczaniem kosztów zużycia leków na pacjenta i lekarza

  • Moduł Apteczki Oddziałowe w module powinna być możliwość: wprowadzania zleceń, przyjmowania leków z apteki, rozdziału leków do dyżurek, przyjęcia środka od pacjenta, definiowania mechanizmu stop-order na poziomie pacjenta, wprowadzania dodatkowych informacji związanych z terapią antybiotykową, odnotowania podania leków pacjentom.




  1. Podpis Elektroniczny 15 szt. (dla 15 osób na 24 miesiące)

Wykonawca powinien zapewnić integralność, niezaprzeczalność, uwierzytelnienie i autoryzację elektronicznej dokumentacji medycznej oraz bezpieczeństwa systemu. Powinno zostać zapewnione również bezpieczeństwo przesyłanych informacji i identyfikacji osób. Podpis elektroniczny powinien umożliwić potwierdzanie za zgodność z oryginałem dokumentów EDM przed elektronicznym ich przesłaniem do instytucji zewnętrznych. W ramach projektu przewidziano zakup 15 szt. licencji bezpiecznego podpisu elektronicznego dla 15 osób (pracowników Wnioskodawcy) odpowiedzialnych za autoryzację dokumentów. Zakup obejmuje 15 szt. licencji na bezpieczny podpis elektroniczny przez okres realizacji projektu.

  1. Zakup licencji w celu świadczenia e-usług publicznych - E-Portal - 1 szt. składający się z następujących modułów (funkcjonalności):

  • e-Rejestracja

  • e-Dokumentacja

  • e-Powiadomienia

  • e-Potwierdzenia

  • e-Kontrahent

  • e-Samokontrola

  • e-Konsultacje

  • e-Wywiad

  • e-usługi mobilne dla Pacjentów

Zakup powyższych modułów jest niezbędny w celu uruchomienia świadczenia e-usług publicznych on-line za pośrednictwem e-Portalu. E-Portal za pomocą którego będą świadczone e-usługi w modelu SaaS (ang. Software as a Service tj. oprogramowanie jako usługa), polegać będzie na zdalnym udostępnianiu oprogramowania poprzez sieć Internet i umożliwiać będzie interakcję poprzez interfejs przeglądarki internetowej. E-Portal będzie systemem do komunikacji i zarządzania wymianą danych przechowywanych w Zintegrowanym Elektronicznym Systemie Zarządzania Dokumentacją Medyczną. Komunikacja z e-Portalem zostanie zapewniona dzięki asymetrycznej architekturze oprogramowania klient – serwer i udostępnionych WEBSERWISÓW oraz połączeniu tunelowym – łączenie portem 3306, szyfrowane bezpiecznym protokołem SSL. Infrastruktura klucza publicznego przewiduje, iż certyfikat SSL jest wystawiany przez zaufany urząd certyfikacji (CA), minimum: GeoTrust (min. QuickSSL Premium) lub Thawte (min. SSL 123). E-usługi świadczone będą z myślą o korzystaniu z niej w sposób zdalny przez wielu interesariuszy jednocześnie (model SaaS) w oparciu o architekturę wielowarstwową (ang. multi-tier-architecture). Architektura wielowarstwowa stanowi jedną z odmian architektury klient-serwer, polegającą na rozdzieleniu interfejsu użytkownika, przetwarzania i składowania danych na kilka osobnych warstw, które dzięki temu mogą być oddzielnie rozwijane, aktualizowane i zarządzane, i dzięki czemu zapewniony zostanie najwyższy poziom bezpieczeństwa danych gromadzonych w systemie teleinformatycznym. Logowanie do e-Portalu, na którym będą świadczone e-usługi będzie realizowane za pomocą loginu i hasła. Z uwagi na zapewnienie najwyższego poziomu bezpieczeństwa, w celu zabezpieczenia danych, zarówno wysyłanych jak i odbieranych przez system, zastosowana zostanie technologia szyfrowanego połączenia SSL (Secure Socket Layer) wykorzystywana między innymi w systemach internetowego dostępu do kont bankowych. Protokół SSL służy do szyfrowania danych pomiędzy serwerem WWW a łączącym się z nim użytkownikiem. Technologia ta pozwala zabezpieczyć się przed programami wyłapującymi dane przesyłane i odbierane przez dany komputer lub sieć komputerową (tzw. snifferami).

Istota działania protokołu SSL polega na wykorzystaniu kryptografii asymetrycznej, która przewiduje wykorzystanie pary kluczy: prywatnego oraz publicznego (często zwanego certyfikatem). Klient (przeglądarka) przy połączeniu do serwera web wykorzystującego protokół https uzgadnia przy wykorzystaniu kryptografii asymetrycznej klucz symetryczny używany podczas sesji. W konsekwencji cały ruch sieciowy od i do serwera jest szyfrowany silnymi algorytmami kryptograficznymi. Bezpieczeństwo danych udostępnianych w publicznej sieci Internet zostanie dodatkowo wzmocnione przez odseparowanie wewnętrznej sieci intranetowej świadczeniodawcy strefą DMZ i szyfrowaną komunikacją oraz bezpiecznymi interfejsami WebServices między e-Usługami udostępnionymi w publicznej sieci Internet a aplikacjami medycznymi i bazą danych zawierającą dane medyczne zainstalowanymi w sieci intranet placówki medycznej. Ponadto żadna z e-Usług udostępnionych w publicznej sieci Internet nie będzie przechowywać trwale wrażliwych danych medycznych. Komunikacja z e-Usługami będzie zabezpieczona szyfrowanym kanałem komunikacji HTTPS z certyfikatem. Poniżej przedstawiono opis głównych funkcjonalności modułów e-Portalu:



  • e-Rejestracja

Moduł powinien umożliwiac wybór i zarezerwowanie terminu wizyty w poradni metodą zdalną za pośrednictwem Internetu (na podstawie elektronicznego grafiku zintegrowanego z systemem szpitalnym) oraz udostępni informacje on-line o kolejkach oczekujących wraz z przybliżonym czasem oczekiwania na przyjęcie. Moduł e-rejestracji powinien umożliwiac Pacjentowi wyszukanie wolnych terminów wizyt wg kryteriów: lekarza, poradni lub usługi medycznej, daty wizyty oraz czasu jej trwania (od do). Po wybraniu jednego z głównych kryteriów (lekarza, poradni lub usługi medycznej) lista wyboru dla pozostałych kryteriów zawęzi się (np. po wybraniu poradni pediatrycznej w polu lekarz będziemy mieli do wyboru jedynie lekarzy pediatrów). Po wprowadzeniu kryteriów zdefiniowanych przez Pacjenta wyświetla listę wszystkich wolnych wizyt spełniających kryteria. Dodatkowo, w ramach usługi będzie zaprojektowana interaktywna mapa dla pacjentów prezentująca lokalizację miejsca wykonania usług. Cały proces rejestracji i potwierdzenia rejestracji powinien odbywać się elektronicznie. E-rejestracja utworzona zdalnie przez Pacjenta powinna zostać automatycznie zapisana w centralnej bazie danych systemu.

  • e-Dokumentacja

Dzięki wprowadzeniu elektronicznej dokumentacji medycznej oraz integracji e-Portalu z Elektronicznym Rekordem Medycznym Pacjenta systemu szpitalnego, moduł ten umożliwi dostęp (odbiór) dokumentacji medycznej przez pacjenta tj. wyników badań, obrazów, itp. metodą zdalną za pośrednictwem Internetu. Wyniki badań udostępniane on-line pacjentom będą dotyczyć zarówno elementów dokumentacji jak i wyników obrazowych z systemu PACS, który będzie zintegrowany z systemem Zarządzania Elektroniczną Dokumentacją Medyczną. Pacjent korzystając z funkcjonalności e-Portalu powinien móc się zalogować, wybrać na podstawie różnych kryteriów (jednostka wykonująca, nazwa badania, status) interesujące go wyniki odczytać, pobrać lub wydrukować.

  • e-Powiadomienia

E-Portal powinien zostać wsparty modułem e-powiadomień indywidualnych dla Pacjentów (SMS/email/e-Portal), który powinien zapewniać wdrażanym e-usługom osiągnięcie 5 poziomu dojrzałości systemu. Moduł automatycznych powiadomień pacjenta o zbliżających się terminach wizyt oraz innych zdarzeń medycznych (np. termin badania, odbiór wyników, uzyskanie odpowiedzi od lekarza ale także informacje związane z profilaktyką) powinien powiadamiać Pacjenta za pomocą 3 kanałów komunikacji: SMS, e-mail, wiadomości systemowe e-Portalu pacjenta dostępne po zalogowaniu do portalu.

  • e-Potwierdzenia

W przypadku konieczności zmiany terminu wizyty/badania przez szpital, powinna zostać uruchomiona elektroniczna funkcja e-potwierdzeń. Pacjent powinien otrzymać elektroniczne powiadomienie (SMS/e-mail/informacja na E-Portalu po zalogowaniu) o zmianie terminu wizyty i propozycji nowego terminu. Potwierdzenie Pacjenta powinno móc być wprowadzone z poziomu e-Portalu jak również poprzez wysłanie zwrotnej informacji kanałem SMS, e-mail, na otrzymany komunikat, np. SMS z odpowiedzią NIE na pytanie czy pacjent akceptuje zmianę terminu, gdzie w przypadku braku akceptacji, system anuluję wizytę i zwolni termin dla innych pacjentów.

  • e-Kontrahent

Moduł powinien umożliwiaćwspółpracę z Partnerami w celu przeprowadzenia zdalnych konsultacji medycznych pomiędzy specjalistami Wnioskodawcy a jego Partnerami, w tym placówkami medycznymi zlokalizowanymi na terenach wiejskich w woj. mazowieckim. Dzięki zastosowaniu modułu e-kontrahent Partner powinien mieć do dyspozycji potężne narzędzie udostępnione zdalnie (poprzez sieć Internet) przez Wnioskodawcę. W celu realizacji e-usług zintegrowanego leczenia pacjenta, Partner otrzyma od Instytutu login i hasło, dzięki którym, po wejściu na odpowiednią stronę internetową, powinien móc korzystać z funkcjonalności tworzenia i udostępniania elektronicznych kartotek pacjentów, wystawiania e-skierowań na badania specjalistyczne, czy e-konsultacji medycznych ze specjalistami z Instytutu (wideo konsultacje i konsultacje pisemne). Wprowadzenie takiej usługi zapewni kompleksowość i ciągłość procesu leczenia, z wglądem w elektroniczny rekord pacjenta. Wprowadzenie usługi zintegrowanego leczenia, usprawni proces wymiany informacji pomiędzy lekarzami prowadzącymi po stronie Partnera i Instytutu, co wpłynie na jakość i szybkość leczenia Pacjenta. Dzięki modułowi e-kontrahent powinno być możliwe zdalne konsultowanie danego przypadku medycznego przez konsylium lekarzy różnych specjalizacji ze strony Partnera jak i Instytutu z bieżącym dostępem do pełnej dokumentacji i historii leczenia.

  • e-Samokontrola

Moduł powinien umożliwiać prowadzenie elektronicznego dziennika kontroli przez pacjenta za pośrednictwem e-Portalu w sposób zdalny przez Internet. Dzienniczek samokontroli jest niezbędnym elementem procesu leczenia dla pacjentów chorych na choroby przewlekłe. Dziennik kontroli powinien mieć wbudowane funkcje przeliczeń i prezentacji dla wybranych schorzeń i być zintegrowanym z systemem szpitalnym, dzięki czemu lekarz prowadzący powinien mieć bieżący wgląd w dziennik kontroli swojego Pacjenta, i na tej podstawie będzie mógł formułować dodatkowe e-zalecenia dla swojego Pacjenta on-line.

  • e-Konsultacje

Moduł powinien umożliwiać pozyskanie przez pacjenta specjalistycznej porady lekarskiej na żądany temat, bez konieczności wychodzenia z domu, w sposób zdalny przez Internet. Usługa powinna umożliwiać konsultacje pisemne lub video-konsultacje według ustalonego terminarza. Dzięki wprowadzeniu elektronicznego rekordu pacjenta (elektroniczna dokumentacja medyczna) zarówno pacjent jak i lekarz powinni mieć dostęp do wyników pacjenta i historii leczenia. Moduł e-konsultacji powinien umożliwiać zadawanie pytań / zgłaszanie uwag przez pacjentów poprzez wewnętrzny system komunikacji. Oprócz e-konsultacji pisemnych, moduł powinien umożliwiać także przeprowadzenie wideokonferencji z lekarzem w celu wykonania konsultacji medycznej on-line. W trakcie wideo konsultacji, lekarz powinien mieć dostęp do udostępnionej na portalu dokumentacji medycznej (wyników badań, karty informacyjnej, obrazów diagnostycznych). Konsultacje on-line obrazu i dźwięku powinny móc się odbywać się w jakości HD oraz niższej, w zależności od podłączonej stacji nadawczej i możliwości sieci pacjenta. Wideo konsultacje powinny być realizowane zdalnie i powinny mieć możliwość obsługiwać do kilkunastu jednoczesnych połączeń (np. konsultacja 4-ech lekarzy jednocześnie) i być realizowane z dedykowanych terminali, telefonów, tabletów, komputerów PC, pozwalając na udostępnienie np. obrazu z pulpitu roboczego. Usługa powinna zapewniać bezpieczną transmisję danych zgodną z obecnie panującymi standardami i wymogami prawnymi.

  • e-Wywiad

Moduł powinien umożliwiać elektroniczne wprowadzenie przez pacjenta informacji dotyczących zdrowia jego i rodziny przed wizytą w celu skrócenia czasu wizyty. Usługa e-wywiadu jest szczególnie istotna w celu zebrania wszelkich niezbędnych informacji od pacjenta i wprowadzeniu ich do Elektronicznego Rekordu Medycznego. Dane wprowadzone na formularzach powinny być natychmiast dostępne w systemie medycznym; ściśle zintegrowane z systemem informatycznym oraz formularzami Dokumentacji Medycznej. Dzięki temu modułowi Pacjent powienienmieć możliwość uzupełniania informacji, celem przekazania ich do lekarza specjalisty. Moduł będzie zdalnie prowadził Pacjenta przez pytania pomocnicze, które będą pomocne w procesie wyboru sposobu leczenia. W odpowiedzi na umieszczony przez pacjenta opis, lekarz prowadzący powinien mieć możliwość dopytać pacjenta o jego dolegliwości w odniesieniu do umieszczonego wpisu. Pacjent powinien mieć możliwość dołączania zdjęć do swojego opisu.

  • e-usługi mobilne dla Pacjentów

Moduł powinien umożliwiać obsługę e-Portalu w dowolnym miejscu, w dowolnym czasie i za pomocą dowolnego urządzenia mobilnego mającego dostęp do sieci Internet. Moduł niezbędny do zapewnienia responsywności e-Portalu na różnych urządzeniach mobilnych (smartfony, tablety, komputery, infomaty). E-Portal powinien być systemem do komunikacji i zarządzania wymianą danych, opatrzonym w odpowiednio przygotowane interfejsy, za pomocą których dane będą mogły być obustronnie przekazywane w architekturze trójwarstwowej zabezpieczonej protokołem bezpieczeństwa SSL. Projekt będzie udostępniał e-Usługi dopasowujące się we właściwy sposób do urządzenia, na którym są uruchamiane, zapewniona zostanie responsywność aplikacji internetowych e-Usług. Dzięki temu niezależnie od systemu operacyjnego czy urządzenia (laptop, tablet, smartfon, infomat) możliwe będzie korzystanie z e-Usług, które będą wspierać co najmniej Windows na komputery PC, Linux, MacOS, Unix, iOS, Android. W związku z tym, rozwiązania TIK w obszarze usług publicznych będą w jak najszerszym stopniu zapewniać kompatybilność z urządzeniami mobilnymi.

  1. Szyna integracyjna z Platformą P1 – 1 szt.

Zakup szyny integracyjnej powinien zapewnić efektywną współpracę, integrację i elektroniczną wymianę danych pomiędzy systemem teleinformatycznym Wnioskodawcy a krajową platformą P1, nie dublując przy tym jej funkcjonalności, zgodnie z rekomendacjami Centrum Systemów Informacyjnych Ochrony Zdrowia. Aby informacje np. o skierowaniach, zwolnieniach i receptach były gromadzone na platformie P1, muszą zostać uprzednio zasilone danymi ze szpitalnego systemu zarządzania dokumentacją medyczną. W tym celu system Wnioskodawcy zostanie rozbudowany o szynę integracyjną P1, aby w sposób automatyczny i elektroniczny wymieniać dane z krajową platformą P1. W ramach systemu powinno być możliwe również korzystanie z e-Usług udostępnianych przez NFZ (eWUS), komunikacji z Internetowym Kontem Pacjenta (IKP), komunikacji z e-Receptą, czy też e-Zwolnieniem ZUS. Realizacja projektu zapewni efektywną współpracę z platformami krajowymi, w tym krajową Platformą P1 (Elektroniczna Platforma Gromadzenia, Analizy i Udostępnienia Zasobów Cyfrowych o Zdarzeniach Medycznych). Odbędzie się to za pomocą wbudowanych w system informatyczny mechanizmów integracji (szyna integracyjna P1) za pomocą interfejsów komunikacyjnych udostępnionych przez CSIOZ. Pozwoli to na możliwość korzystania z krajowych platform nie dublując przy tym ich funkcjonalności, zgodnie z rekomendacjami Centrum Systemów Informacyjnych Ochrony Zdrowia. Tym samym, niniejszy projekt polegający na wdrożeniu i zarządzaniu elektroniczną dokumentacją medyczną, elektronicznym obiegiem dokumentów i świadczeniu e-usług opisanych w projekcie będzie uzupełnieniem/rozwinięciem krajowych platform medycznych, będzie z nimi kompatybilny i dostosowany do wymiany danych z krajową platformą P1.

  1. Oprogramowanie bazodanowe – 4 szt.

Niezbędny jest zakup oprogramowania bazodanowego – 4 licencje lub zgodnie z licencjonowaniem producenta bazy danych dla 2 serwerów przewidzianych w projekcie. Moduły systemu teleinformatycznego będą realizować i przetwarzać zapytania użytkowników do bazy danych. Baza danych musi być przeznaczona do systemów obliczeniowych typu grid np. Oracle database 12c, z wykorzystaniem mechanizmów wbudowanych w bazę danych: triggerów, procedur, funkcji i pakietów, umożliwiających m.in. wdrożenie jednej bazy danych na klastrze serwerów w architekturze grid (Oracle RAC, Oracle Clusterware lub równorzędne). Zapewni to optymalizację, spójność i pełne bezpieczeństwo samej bazy przechowującej kluczowe dane. Relacyjna baza danych Oracle posługuje się standardowym językiem zapytań SQL oraz posiada wbudowany wewnętrzny język tworzenia procedur składowanych PL/SQL - będący proceduralnie obudowanym językiem SQL. Baza danych musi być wydajna i skalowana na serwerach Windows, Linux i UNIX.

Oprogramowanie bazodanowe

Przedmiotem dostawy są 4 licencje (lub zgodnie z licencjonowaniem producenta bazy danych dla 2 serwerów przewidzianych w projekcie) na motor bazy danych typu Oracle Standard Edition Two lub kompatybilny umożliwiająca uruchomienie na 2 fizycznych procesorów klasy intel x86 (po 1 w 2 serwerach spiętych w klaster). Licencja musi być dożywotnia, bez ograniczeń formalnych na wykorzystanie z aplikacjiami pochodzącymi od dowolnych dostawców. Wraz z licencją należy dostarczyć usługę asysty technicznej i konserwacji producenta na okres minimum 60 miesięcy


- Dostępność oprogramowania na współczesne 64-bitowe platformy Unix (HP-UX dla Itanium, Solaris dla procesorów SPARC/x86-64, IBM AIX), Intel Linux 64-bit, MS Windows 64-bit. Identyczna funkcjonalność serwera bazy danych na ww. platformach.

- Niezależność platformy systemowej dla oprogramowania klienckiego / serwera aplikacyjnego od platformy systemowej bazy danych.

- Możliwość przeniesienia (migracji) struktur bazy danych i danych pomiędzy ww. platformami bez konieczności rekompilacji aplikacji bądź migracji środowiska aplikacyjnego.

- Przetwarzanie transakcyjne wg reguł ACID (Atomicity, Consistency, Independency, Durability) z zachowaniem spójności i maksymalnego możliwego stopnia współbieżności. Mechanizm izolowania transakcji powinien pozwalać na spójny odczyt modyfikowanego obszaru danych bez wprowadzania blokad, z kolei spójny odczyt nie powinien blokować możliwości wykonywania zmian.

Oznacza to, że 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.

- Wsparcie dla wielu ustawień narodowych i wielu zestawów znaków (włącznie z Unicode).

- Możliwość migracji 8-bitowego zestawu znaków bazy danych (np. MS Windows CP 1252, ISO 8859-2) do Unicode.

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

- Brak formalnych ograniczeń na liczbę tabel i indeksów w bazie danych oraz na ich rozmiar (liczbę wierszy).

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

- Możliwość kompilacji procedur składowanych w bazie danych do postaci kodu binarnego.

- 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).

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

- 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ń.

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

- 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, Data Protector itd). Wykonywanie kopii bezpieczeństwa powinno być możliwe w trybie offline oraz w trybie online.

- Możliwość wykonywania kopii bezpieczeństwa w trybie online (hot backup).

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

- W przypadku, gdy odtwarzaniu podlegają pojedyncze pliki bazy danych, pozostałe pliki baz danych mogą być dostępne dla użytkowników.

- Wsparcie dla typu danych DICOM obsługiwanego wewnętrznie przez serwer bazy danych.

- Możliwość zakładania w tabelach kolumn typu obsługującego standard DICOM.

- Możliwość przeszukiwania zakładania indeksów na grupie atrybutów metadanych składowanych w kolumnach przechowujących dane w formacie DICOM.

- Możliwość przeszukiwania metadanych

* wszystkich bądź niektórych atrybutów,

* możliwość zakładania indeksów na wybranych atrybutach,

* możliwość wyszukiwania pełno tekstowego,

* możliwość nawigacji zgodnej z hierarchią atrybutów.

- Składowanie metadanych DICOM i treści DICOM odbywa się wewnątrz bazy danych.

- Operowanie na danych DICOM za pomocą konstrukcji języka SQL, procedur składowanych, dostęp za pomocą Java API.

- Wbudowane mechanizmy konwersji treści DICOM do formatów JPEG, GIF, MPEG, AVI.

- możliwość budowy klasta typu active-active opartego o maksymalnie 2 węzły (maksymalnie 2 x 1 CPU)

- Możliwość zwiększenia przepustowości bazy danych poprzez uruchomienie dodatkowych serwerów obsługujących tą samą bazę danych (w klastrze).

- Zwiększenie bądź zmniejszenie liczby serwerów obsługujących klastrową bazę danych nie może powodować konieczności reorganizacji fizycznej (zmiana organizacji plików danych) oraz logicznej struktury baz danych (tabel / indeksów).

- Unieruchomienie jednego z serwerów bazy danych nie może powodować braku dostępu do jakiejkolwiek części danych – baza danych musi być nadal dostępna za pośrednictwem funkcjonujących dalej serwerów

- Możliwość kontynuacji pracy użytkowników podłączonych do serwera klastrowej bazy danych, który uległ awarii. Powinna istnieć możliwość przeniesienia sesji na inny serwer oraz automatycznego powiadomienia aplikacji o wykonaniu przełączenia.

- Obraz bazy danych (metadane, obiekty bazy danych, stan danych) w klastrowej bazie danych musi być niezależny od serwera do którego zostało nawiązane połączenie


Oprogramowanie wirtualizacyjne dla dwóch serwerów dwuprocesorowych

  1. Warstwa wirtualizacji musi być zainstalowana bezpośrednio na sprzęcie fizycznym bez dodatkowych pośredniczących systemów operacyjnych

  2. Rozwiązanie musi 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.

  3. Pojedynczy klaster może się skalować do 64 fizycznych hostów (serwerów) z zainstalowaną warstwą wirtualizacji.

  4. Oprogramowanie do wirtualizacji zainstalowane na serwerze fizycznym potrafi obsłużyć
    i wykorzystać procesory fizyczne wyposażone w 480 logicznych wątków oraz do 6TB pamięci fizycznej RAM.

  5. Oprogramowanie do wirtualizacji musi zapewnić możliwość skonfigurowania maszyn wirtualnych 1-128 procesorowych.

  6. Oprogramowanie do wirtualizacji musi zapewniać możliwość stworzenia dysku maszyny wirtualnej o wielkości do 62 TB.

  7. Oprogramowanie do wirtualizacji musi zapewnić możliwość skonfigurowania maszyn wirtualnych
    z możliwością przydzielenia do 4 TB pamięci operacyjnej RAM.

  8. Oprogramowanie do wirtualizacji musi zapewnić możliwość skonfigurowania maszyn wirtualnych ,z których każda może mieć 1-10 wirtualnych kart sieciowych.

  9. Oprogramowanie do wirtualizacji musi zapewnić możliwość skonfigurowania maszyn wirtualnych , z których każda może mieć 32 porty szeregowe.

  10. Rozwiązanie musi umożliwiać łatwą i szybką rozbudowę infrastruktury o nowe usługi bez spadku wydajności i dostępności pozostałych wybranych usług.

  11. Rozwiązanie powinno w możliwie największym stopniu być niezależne od producenta platformy sprzętowej.

  12. Polityka licencjonowania musi umożliwiać przenoszenie licencji na oprogramowanie do wirtualizacji pomiędzy serwerami różnych producentów z zachowaniem wsparcia technicznego i zmianą wersji oprogramowania na niższą (downgrade). Licencjonowanie nie może odbywać się w trybie OEM.

  13. Rozwiązanie musi wspierać następujące systemy operacyjne: MS-DOS 6.22, Windows 3.1, Windows 95, Windows 98, Windows XP, Windows Vista , Windows NT 4.0, Windows 2000, Windows Server 2003, Windows Server 2008, Windows Server 2012, Windows 7, Windows 8, SLES 11, SLES 10, SLES 9, SLES 8, RHEL 6, RHEL 5, RHEL 4, RHEL 3, Solaris 11 ,Solaris 10, Solaris 9, Solaris 8, OS/2 Warp 4.0, NetWare 6.5, NetWare 6, NetWare 5, OEL 4, OEL 5, Debian, CentOS, FreeBSD, Asianux, Mandriva, Ubuntu 14, Ubuntu 12, SCO OpenServer, SCO Unixware, Mac OS X.

  14. Rozwiązanie musi umożliwiać przydzielenie większej ilości pamięci RAM dla maszyn wirtualnych niż fizyczne zasoby RAM serwera w celu osiągnięcia maksymalnego współczynnika konsolidacji.

  15. Rozwiązanie musi umożliwiać udostępnienie maszynie wirtualnej większej ilości zasobów dyskowych niż jest fizycznie zarezerwowane na dyskach lokalnych serwera lub na macierzy.

  16. Rozwiązanie powinno posiadać centralną konsolę graficzną do zarządzania maszynami wirtualnymi i do konfigurowania innych funkcjonalności. Centralna konsola graficzna powinna mieć możliwość działania zarówno, jako aplikacja na maszynie fizycznej lub wirtualnej, jak i jako gotowa, wstępnie skonfigurowana maszyna wirtualna tzw. virtual appliance.

  17. Rozwiązanie musi zapewnić możliwość bieżącego monitorowania wykorzystania zasobów fizycznych infrastruktury wirtualnej (np. wykorzystanie procesorów, pamięci RAM, wykorzystanie przestrzeni na dyskach/wolumenach) oraz przechowywać i wyświetlać dane maksymalnie sprzed roku.

  18. Oprogramowanie do wirtualizacji powinno zapewnić możliwość wykonywania kopii migawkowych instancji systemów operacyjnych (tzw. snapshot) na potrzeby tworzenia kopii zapasowych bez przerywania ich pracy.

  19. Oprogramowanie do wirtualizacji musi zapewnić możliwość klonowania systemów operacyjnych wraz z ich pełną konfiguracją i danymi.

  20. Oprogramowanie do wirtualizacji oraz oprogramowanie zarządzające musi posiadać możliwość integracji z usługami katalogowymi Microsoft Active Directory.

  21. Rozwiązanie musi zapewniać mechanizm bezpiecznego uaktualniania warstwy wirtualizacyjnej (hosta, maszyny wirtualnej) bez potrzeby wyłączania wirtualnych maszyn.

  22. Rozwiązanie musi zapewnić wbudowany, bezpieczny mechanizm do automatycznego tworzenia kopii zapasowych, odtwarzania wskazanych maszyn wirtualnych. Mechanizm ten musi umożliwiać również odtwarzanie pojedynczych plików z kopii zapasowej oraz zapewnia stosowanie deduplikacji dla kopii zapasowych. Mechanizm zapewnia możliwość wykonywania spójnych kopii zapasowych serwerów aplikacyjnych (Microsoft SQL Server, Microsoft Exchange Server, Microsoft SharePoint Server) oraz replikację kopii zapasowych.

  23. Rozwiązanie musi zapewniać mechanizm replikacji wskazanych maszyn wirtualnych w obrębie klastra serwerów fizycznych.

  24. Rozwiązanie musi mieć możliwość przenoszenia maszyn wirtualnych w czasie ich pracy pomiędzy serwerami fizycznymi. Mechanizm powinien umożliwiać 4 lub więcej takich procesów przenoszenia jednocześnie.

  25. Rozwiązanie musi mieć możliwość przenoszenia zwirtualizowanych dysków maszyn wirtualnych w czasie ich pracy pomiędzy fizycznymi zasobami dyskowymi.

  26. Musi zostać zapewniona odpowiednia redundancja i taki mechanizm (wysokiej dostępności HA) , aby w przypadku awarii lub niedostępności serwera fizycznego wybrane przez administratora i uruchomione nim wirtualne maszyny zostały uruchomione na innych serwerach z zainstalowanym oprogramowaniem wirtualizacyjnym.

  27. Oprogramowanie do wirtualizacji musi zapewniać mechanizm takiego zabezpieczenia wybranych przez administratora wirtualnych maszyn, aby w przypadku awarii lub niedostępności serwera fizycznego maszyny, które na nim pracowały, były bezprzerwowo dostępne na innym serwerze z zainstalowanym oprogramowaniem wirtualizacyjnym. Mechanizm ten umożliwia zabezpieczenie maszyn wirtualnych wyposażonych w minimum 2 wirtualne procesory.

  28. System musi posiadać funkcjonalność wirtualnego przełącznika (virtual switch) umożliwiającego tworzenie sieci wirtualnej w obszarze hosta i pozwalającego połączyć maszyny wirtualne w obszarze jednego hosta, a także na zewnątrz sieci fizycznej. Pojedynczy przełącznik wirtualny powinien mieć możliwość konfiguracji do 4000 portów.

  29. Pojedynczy wirtualny przełącznik musi posiadać możliwość przyłączania do niego dwóch i więcej fizycznych kart sieciowych, aby zapewnić bezpieczeństwo połączenia ethernetowego w razie awarii karty sieciowej.

  30. Wirtualne przełączniki musza obsługiwać wirtualne sieci lokalne (VLAN).

  31. Wraz z licencją należy dostarczyć usługę asysty technicznej i konserwacji producenta na okres minimum 60 miesięcy

Oprogramowanie do backupu dla dwóch serwerów dwuprocesorowych


Pobieranie 4.65 Mb.

Share with your friends:
1   2   3   4   5   6   7   8   9   ...   13




©operacji.org 2020
wyślij wiadomość

    Strona główna
warunków zamówienia
istotnych warunków
przedmiotu zamówienia
wyboru operacji
Specyfikacja istotnych
produktu leczniczego
oceny operacji
rozwoju lokalnego
strategii rozwoju
kierowanego przez
specyfikacja istotnych
Nazwa przedmiotu
Karta oceny
ramach działania
przez społeczno
obszary wiejskie
dofinansowanie projektu
lokalnego kierowanego
Europa inwestująca
Regulamin organizacyjny
przetargu nieograniczonego
kryteria wyboru
Kryteria wyboru
Lokalne kryteria
Zapytanie ofertowe
Informacja prasowa
nazwa produktu
Program nauczania
Instrukcja obsługi
zamówienia publicznego
Komunikat prasowy
programu operacyjnego
udzielenie zamówienia
realizacji operacji
opieki zdrowotnej
przyznanie pomocy
ramach strategii
Karta kwalifikacyjna
oceny zgodno
Specyfikacja techniczna
Instrukcja wypełniania
Wymagania edukacyjne
Regulamin konkursu
lokalnych kryteriów
strategia rozwoju
sprawozdania finansowego
ramach programu
ramach poddziałania
kryteriów wyboru
operacji przez
trybie przetargu