swpppo_zsi_olk_3

advertisement
Szczecin, 05.08.2015 r.
SZCZEGÓŁOWE WARUNKI PISEMNEGO PUBLICZNEGO PRZETARGU OFERTOWEGO
Organizator przetargu zaprasza do wzięcia udziału w przetargu i złożenia oferty na:
przygotowanie projektów wykonawczych, dostawę licencji oraz instalację i integrację
oprogramowania typu HIS, RIS, LIS i Zaopatrzeniowego dla Nowy Szpital w Olkuszu
Sp. z o.o.
Postępowanie realizowane w ramach projektu "Wdrożenie systemu teleinformatycznego
zarządzania szpitalem i udostępnienie e-usług z zakresu ochrony zdrowia w Nowym Szpitalu
w Olkuszu" współfinansowanego przez Unię Europejską z Europejskiego Funduszu Rozwoju
Regionalnego, w ramach Małopolskiego Regionalnego Programu Operacyjnego na lata
2007-2013, w ramach Działania 1.2 Rozwój społeczeństwa informacyjnego, Oś Priorytetowa
1. Warunki dla rozwoju społeczeństwa opartego na wiedzy (konkurs Nr 1/2013/1.2)
na zasadach określonych poniżej.
1. Zamawiający i Organizator przetargu:
1.1.
Zamawiający::
Nowy Szpital w Olkuszu Sp. z o.o. z siedzibą w Olkuszu, ul. 1000-lecia 13, 32-300 Olkusz,
wpisana do Rejestru Przedsiębiorców Krajowego Rejestru Sądowego prowadzonego przez
Sąd Rejonowy dla Krakowa – Śródmieścia w Krakowie XII Wydział Gospodarczy KRS pod
numerem 0000310871,NIP 9552268113, REGON 320592435, o kapitale zakładowym
50 000 zł., zwany dalej „Zamawiającym”
1.2. Organizator przetargu:
Grupa Nowy Szpital Sp. z o.o.
ul. Mazowiecka 13b/6
70-526 Szczecin
działający jako pełnomocnik Zamawiającego
2. Sposób prowadzenia postępowania:
2.1. Zamówienie zostanie udzielone Oferentowi, wybranemu w drodze konkursu ofert na
podstawie przepisów art. 701 – art. 705 Kodeksu cywilnego oraz zgodnie z niniejszymi
1
Szczegółowymi Warunkami Pisemnego Publicznego Przetargu Ofertowego, zwanymi w
dalszej części „Warunkami” lub „SWPPPO”.
2.2. Postępowanie odbędzie się z podziałem na część: jawną i niejawną. Oferenci mogą
uczestniczyć w części jawnej
2.3. W części jawnej postępowania Organizator przetargu:
1)
dokonuje otwarcia ofert;
2)
ogłasza wyniki postępowania;
2.4. W części niejawnej postępowania Organizator przetargu:
1)
stwierdza ważność złożonych ofert;
2)
odrzuca oferty w przypadku niespełnienia przez Oferentów wymogów niniejszego
postępowania;
3)
w toku dokonywania badania i oceny złożonych ofert może żądać od Oferentów
wyjaśnień dotyczących złożonych przez nich ofert;
4)
ma możliwość przeprowadzenia negocjacji z Oferentami.
2.5. Wyniki niniejszego postępowania zostaną ogłoszone na stronie internetowej
Organizatora przetargu - www.nowyszpital.pl, a ponadto o wyborze najkorzystniejszej oferty
niezwłocznie, drogą elektroniczną, poinformowani zostaną wszyscy Oferenci.
2.6. Organizator przetargu zastrzega sobie prawo dokonania zmiany warunków przetargu
w jego trakcie, a także prawo unieważnienia przetargu bez podawania powodu oraz prawo
do zamknięcia przetargu bez dokonywania wyboru żadnej oferty.
2.7. Organizator zastrzega sobie możliwość organizacji II etapu konkursu w formie negocjacji
z Oferentami. W takim przypadku negocjacje polegały będą na zaproszeniu do rozmów w
toku których zaproszeni Oferenci zobowiązani będą przedstawić dalsze oferty, których
warunki nie będą gorsze niż oferty już złożone w postępowaniu.
3. Wadium:
Organizator przetargu nie żąda wniesienia wadium w prowadzonym postępowaniu.
4. Opis przedmiotu zamówienia:
4.1.
Przedmiotem zamówienia jest przygotowanie projektów wykonawczych, dostawa
licencji oraz instalacja i integracja oprogramowania typu HIS, RIS, LIS i
Zaopatrzeniowego (łącznie zwanego dalej również Oprogramowaniem) zgodnie ze
Specyfikacją wymaganych parametrów techniczno- użytkowych zawartą w
Załączniku nr 3 do SWPPPO, dla:
2
4.1.1.
4.2.
Nowego Szpitala w Olkuszu Sp. z o.o.;
Przedmiot zamówienia podzielony został na następujące zadania:
Zadanie 1: Przygotowanie projektów wykonawczych oprogramowania typu HIS,
RIS, LIS i Zaopatrzeniowego
Zadanie 2: Dostawa licencji oprogramowania typu HIS
Zadanie 3: Dostawa licencji oprogramowania typu RIS
Zadanie 4: Dostawa licencji oprogramowania typu LIS
Zadanie 5: Dostawa licencji oprogramowania typu Zaopatrzeniowego
Zadanie 6: Instalacja oprogramowania typu HIS, RIS, LIS i Zaopatrzeniowego
Zadanie 7: Integracja oprogramowania typu HIS, RIS, LIS i Zaopatrzeniowego
4.3. Szczegółowy wykaz wymaganych parametrów techniczno- użytkowych zawiera
Załącznik nr 3 - Specyfikacja wymaganych parametrów technicznoużytkowych.
4.4. W ramach realizacji Zadania 7 Zamawiający wymaga przeprowadzenia integracji
dostarczanego Oprogramowania z wykorzystywanymi przez Zamawiającego:
oprogramowaniem i systemami IT.
4.5. Szczegółowe warunki i zasady realizacji umowy określa Wzór umowy stanowiący
Załącznik nr 4 do SWPPPO.
4.6. Wskazane przez Zamawiającego w SWPPPO lub w załącznikach do SWPPPO
nazwy własne produktów, producenta, wskazania modeli służą jedynie określeniu
klasy produktu, będącego przedmiotem zamówienia i służą ustaleniu standardu, a
nie wskazują na konkretny wyrób lub konkretnego producenta.
4.7. Zamawiający wymaga dostarczenia licencji typu OPEN (lub rozwiązania
równoważnego - nie ograniczonego ilością użytkowników nazwanych lub
jednoczesnych t.j. bez jakichkolwiek limitów ze względu na sposób pracy
Zamawiającego.). Jednocześnie Zamawiający informuje, iż z jego punktu widzenia
krytycznym jest spełnienie funkcjonalności określonych w Załączniku nr 3 (Formularz
nr 3 – Specyfikacja wymaganych parametrów techniczno-użytkowych) w obrębie
dostarczonych licencji. Zamawiający przewiduje możliwość zastosowania wyłączeń
lub ograniczeń, co zostanie ustalone na etapie negocjacji.
4.8. Zamawiający wyjaśnia, iż Gwarancja na Oprogramowanie obejmuje obowiązek
wykonywania napraw usterek oraz błędów krytycznych oraz modyfikacje
Oprogramowania w zakresie niezbędnym do wykonania tych napraw. W ramach
Gwarancji Zamawiający będzie nadto uprawniony do:
a) zgłaszania błędów poprzez system serwisowy;
b) dostępu do systemu serwisowego;
c) zgłoszenia uwag i propozycji modyfikacji Oprogramowania, które będą uwzględniane;
3
d) doradztwa w zakresie rozbudowy Oprogramowania o kolejne moduły i funkcjonalności;
e) gotowość przyjmowania i rozpatrywania indywidualnych żądań zmian (tj. modyfikacji
płatnych) Oprogramowania;
f) bezpłatnego dostosowania Oprogramowania do zmian prawnych dotyczących sposobu
rozliczania świadczeń medycznych finansowanych ze środków NFZ.
5. Opis warunków udziału w postępowaniu:
5.1 W postępowaniu wziąć mogą udział Oferenci, którzy spełniają następujące warunki:
a)
posiadają uprawnienia do wykonywania określonej działalności lub czynności, jeżeli
przepisy prawa nakładają obowiązek posiadania takich uprawnień.
5.2. W celu potwierdzenia, że Oferent posiada uprawnienia do wykonywania określonej
działalności lub czynności. Organizator przetargu żąda, w formie oryginału lub kserokopii
poświadczonej za zgodność z oryginałem przez osobę uprawnioną do reprezentacji Oferenta
w obrocie gospodarczym, następujących dokumentów:
a)
aktualnego odpisu z właściwego rejestru albo aktualnego zaświadczenia
o wpisie do ewidencji działalności gospodarczej, jeżeli odrębne przepisy wymagają wpisu do
rejestru lub zgłoszenia do ewidencji działalności gospodarczej, wystawionego nie wcześniej
niż 6 miesięcy przed upływem terminu składania ofert;
b)
zezwolenie na prowadzenie działalności gospodarczej w zakresie objętym niniejszym
postępowaniem, jeśli jest wymagane;
5.3. Dodatkowo do oferty należy dołączyć (Formularz nr 2 - Oświadczenie):
a)
oświadczenie, że nie jest wobec niego, jego firmy prowadzone postępowanie
upadłościowe, ani upadłości nie ogłoszono,
b)
oświadczenie że zapoznał się z przedmiotem i warunkami
przetargu
oraz treścią umowy i wyraża zgodę na zawarcie umowy na warunkach określonych we
wzorze stanowiącym załącznik do warunków przetargu
c)
oświadczenie, że wypełnia zobowiązania podatkowe, uiszcza opłaty w tym składki na
ubezpieczenia społeczne,
d)
oświadczenie, że znajduje się w sytuacji finansowej i ekonomicznej zapewniającej
należyte wykonanie umowy.
5.4. Dokumenty określone w ust. 5.2. oraz w ust. 5.3. składają wszyscy członkowie
konsorcjum.
4
5.4.a. Oferent może polegać na wiedzy i doświadczeniu, potencjale technicznym, osobach
zdolnych do wykonania zamówienia lub zdolnościach finansowych innych podmiotów w celu
wykazania spełniania warunków udziału w postępowaniu. Oferent w takiej sytuacji
zobowiązany jest udowodnić Zamawiającemu, iż będzie dysponował zasobami niezbędnymi
do realizacji zamówienia, w szczególności przedstawiając w tym celu pisemne zobowiązanie
tych podmiotów do oddania mu do dyspozycji niezbędnych zasobów na okres korzystania z
nich przy wykonaniu zamówienia. O ile Oferent polegał będzie na zasobach podmiotu
trzeciego i podmiot ten będzie uczestniczył w realizacji zamówienia Oferta zawierać musi
dokumenty wskazane w ust. 5.2. i 5.3. dotyczące sytuacji podmiotu trzeciego.
5.5. Ocena spełnienia warunków określonych w ust. 5.1. dokonana zostanie zgodnie
z formułą „spełnia - nie spełnia" w oparciu o informacje zawarte w oświadczeniach
i dokumentach wyszczególnionych w ust. 5.2. i 5.3. Z treści załączonych dokumentów
i oświadczeń musi wynikać jednoznacznie czy wymienione w ust. 5.2 i 5.3 oświadczenia i
dokumenty spełniają wymogi określone przez Organizatora przetargu. Nie złożenie
chociażby jednego z w/w dokumentów i oświadczeń oraz udzielenie informacji nieprawdziwej
skutkować będzie wykluczeniem Oferenta z postępowania. Ofertę Oferenta wykluczonego
uznaje się za odrzuconą z uwzględnieniem ust 5.6.
5.6. Organizator wezwie Oferentów, którzy w określonym terminie nie złożą wymaganych
przez Organizatora oświadczeń lub dokumentów, o których mowa w ust. 5.2 i 5.3., lub
którzy nie złożą pełnomocnictw, albo którzy złożą wymagane przez Organizatora
oświadczenia i dokumenty, o których mowa w art. 5.2. oraz 5.3., zawierające błędy lub którzy
złożą wadliwe pełnomocnictwa, do ich złożenia w wyznaczonym terminie chyba, że mimo ich
złożenia oferta Oferenta podlegałaby odrzuceniu.
6. Opis sposobu przygotowywania oferty:
6.1. Oferta musi być trwale zszyta i sporządzona czytelnie w języku polskim. Oferty
nieczytelne zostaną odrzucone. W przypadku złożenia oferty w drodze przesłania skanu
oferty wymaga się przesłania oryginału oferty na adres Organizatora przetargu w przeciągu 7
dni od terminu złożenia ofert, o którym mowa w pkt 9.
6.2. Wszystkie strony oferty wraz ze wszystkimi załącznikami muszą być odpowiednio
ponumerowane, opieczętowane pieczątką firmową Oferenta i podpisane przez osoby
upoważnione do reprezentacji Oferenta.
6.3. Upoważnienie do podpisania oferty musi być dołączone do oferty, o ile nie wynika
z innych dokumentów załączonych przez Oferenta.
5
6.4. Wszelkie zmiany w ofercie dokonane przez Oferenta, muszą być podpisane
i opieczętowane przez Oferenta lub osoby przez niego upoważnione.
6.5. Oferent składa tylko jedną ofertę.
6.6. Oferent ponosi wszelkie koszty związane z przygotowaniem i złożeniem oferty
bez względu na wynik postępowania.
6.7. Oferent jest zobowiązany umieścić ofertę w kopercie, która musi być zaadresowana
na adres Organizatora i zawierać oznaczenie:
Oferta na przygotowanie projektów wykonawczych, dostawę licencji oraz instalację i
integrację oprogramowania typu HIS, RIS, LIS i Zaopatrzeniowego dla Nowy Szpital w
Olkuszu Sp. z o.o.
w ramach projektu:
"Wdrożenie systemu teleinformatycznego zarządzania szpitalem i udostępnienie e-usług z
zakresu ochrony zdrowia w Nowym Szpitalu w Olkuszu".
nie otwierać przed 11.08.2015 r. przed godz. 14:00.
6.8. Oferent może wprowadzić zmiany oraz wycofać złożoną przez siebie ofertę
przed terminem składania ofert. W przypadku wycofania oferty, Oferent składa pisemne
oświadczenie, że ofertę swą wycofuje. W przypadku zmiany oferty, Oferent składa pisemne
oświadczenie, iż ofertę swą zmienia, określając jednocześnie zakres i rodzaj tych zmian;
a jeśli oświadczenie o zmianie pociąga za sobą konieczność wymiany czy też przedłożenia
nowych dokumentów – Oferent winien dokumenty te złożyć. Powyższe oświadczenie
i ewentualne dokumenty należy zamieścić w zamkniętej kopercie, oznaczonej jak w ust. 6.7,
przy czym powinna ona mieć dopisek „zmiany”. Przedmiotowe oświadczenie oraz
dokumenty mogą zostać złożone w drodze przesłania skanów na adres poczty
elektornicznej: [email protected], przy czym oryginały dokumentów muszą zostać
dostarczone do siedziby Organizatora przetargu w przeciągu 7 dni od daty złożenia ofert, o
której mowa w pkt. 9.
6.9. W przypadku, gdy Oferent, jako załącznik do oferty, zamiast oryginału dołącza kopię
dokumentu, musi być ona poświadczona przez niego za zgodność z oryginałem.
Nieprawidłowe poświadczenie lub brak poświadczenia kopii dokumentów skutkować będzie
odrzuceniem oferty.
6.10. Wymaga się złożenie oferty i załączników do oferty w następującej kolejności:
6
wypełniony Formularz nr 1 – Oferta;
wypełniony Formularz nr 2 – Oświadczenie;
wypełniony Formularz nr 3 – Specyfikacja wymaganych parametrów technicznoużytkowych;
d)
dokumenty i zaświadczenia wymagane w ustępie 5;
e)
dokument pełnomocnictwa, dla osoby podpisującej ofertę, jeżeli z przedstawionych
dokumentów wynika, że osoba ta nie jest uprawniona do reprezentacji Oferenta
w obrocie gospodarczym. Załączyć należy dokument pełnomocnictwa wystawionego w
sposób określony przepisami prawa cywilnego. W przypadku złożenia kopii pełnomocnictwa
musi być ono potwierdzone za zgodność z oryginałem przez osoby udzielające
pełnomocnictwa lub notariusza;
f)
inne dokumenty których załączenie Oferent uzna za stosowne (np. informacja o
firmie, nagrody itp.).
6.11. Oferenci przedstawią oferty ściśle z wymaganiami niniejszego postępowania.
Zamawiający nie dopuszcza składania ofert wariantowych. Nie dopuszcza się składania
ofert częściowych na poszczególne pozycje lub zadania.
6.12. Oferty składane przez Oferentów wspólnie ubiegających się o zamówienie muszą
spełniać następujące wymagania:
1)
oferta musi być sporządzona zgodnie z wymaganiami niniejszego postępowania
oraz zawierać wszystkie wymagane oświadczenia i dokumenty, każdego z Oferentów
wspólnie ubiegających się o zamówienie;
2)
oferta wraz z załącznikami musi być podpisana przez osoby upoważnione
do reprezentacji Oferentów;
4)
do oferty należy dołączyć dokument ustanawiający pełnomocnika dla reprezentacji
Oferentów wspólnie ubiegających się o zamówienie.
a)
b)
c)
Oferta oraz wszelkie dokumenty składane w trakcie postępowania są jawne,
z wyjątkiem informacji stanowiących tajemnicę przedsiębiorstwa w rozumieniu ustawy
o zwalczaniu nieuczciwej konkurencji, a także w odniesieniu do tych informacji, co do
których Oferent zastrzegł, że nie mogą być one udostępniane innym uczestnikom
postępowania. Zastrzeżeniu nie może podlegać składany przez Oferenta wypełniony
Formularz nr 1 Oferta.
6.13. Oferent nie może wycofać oferty ani wprowadzić do niej zmian po upływie terminu
składania ofert.
7. Informacja o sposobie porozumiewania się organizatora przetargu z Oferentami:
W niniejszym postępowaniu wszelkie oświadczenia, wnioski, zawiadomienia oraz informacje
Organizator przetargu i Oferent przekazują w formie elektronicznej (e-mail). Organizator
przetargu dopuszcza możliwość przekazywania oświadczeń, wniosków, zawiadomień,
7
informacji za pomocą faksu lub poczty, przy czym każda ze stron na żądanie drugiej strony
niezwłocznie potwierdza fakt ich otrzymania. Oferta winna zostać złożona wyłącznie w
formie pisemnej. Oferent może złożyć ofertę w drodze przesłania skanu oferty na
adres poczty elektronicznej: [email protected], przy czym
wymaga się
przesłania oryginału oferty na adres Organizatora przetargu w przeciągu 7 dni od terminu
złożenia ofert, o którym mowa w pkt 9.
Organizator przetargu zastrzega sobie, że zmiany dotyczące postępowania
– w szczególności: zmiana terminu, miejsca składania, otwarcia ofert umieszczał będzie
wyłącznie na stronie internetowej www.nowyszpital.pl.
8. Wyjaśnienia treści Warunków przetargu:
Oferent może zwrócić się na piśmie do Organizatora przetargu o wyjaśnienie treści
postanowień Warunków niniejszego postępowania. Organizator przetargu przekaże treść
zapytań wraz z wyjaśnieniami Oferentom, na stronie internetowej, na której ukazało się
ogłoszenie o postępowaniu. Organizator przetargu udzieli wyjaśnień Oferentowi, jeżeli
wniosek wpłynie do niego nie później niż do 10.08.2015 r. do godziny 10:00.
Osobą uprawnioną do kontaktu z Oferentami jest Łukasz Tamborski, stanowisko:
Specjalista.
Dział
Usług
Zewnętrznych,
telefon
komórkowy
512 144
454;
e- mail: [email protected]
9. Miejsce i termin składnia ofert:
Ofertę należy złożyć w sekretariacie Organizatora przetargu, tj. Grupa Nowy Szpital spółka
z o.o. z siedzibą w Szczecinie, ul. Mazowiecka 13b/6, 70-526 Szczecin w terminie do dnia
11.08.2015 r. do godz. 14:00.
10. Miejsce i termin otwarcia ofert:
Otwarcie ofert odbędzie się w siedzibie Organizatora przetargu tj. Grupa Nowy Szpital spółka
z o.o. z siedzibą w Szczecinie, ul. Mazowiecka 13b/6, 70-526 Szczecin w dniu 11.08.2015
r. o godz. 14:00.
11. Termin związania z Ofertą:
Oferent będzie związany złożoną ofertą przez okres 60 dni.
12. Kryteria oceny i wyboru najkorzystniejszej oferty:
Kryterium jakim Organizator będzie się kierował przy wyborze oferty jest łączna cena brutto
poszczególnych zadań.
12.1. Zaoferowana cena musi zawierać wszystkie proponowane przez oferenta upusty,
rabaty. Należy podawać tylko jedną cenę, w tym także tylko jedną cenę jednostkową
8
na daną pozycję i zadanie, bez przedstawiania opcji, wariantów czy alternatyw. Cena
powinna obejmować pełny koszt realizacji zamówienia.
12.2. Kwoty powinny być podane z dokładnością do dwóch miejsc po przecinku. Trzecią
liczbę po przecinku należy zaokrąglić od 5 w górę.
12.3. Dokonując oceny ofert Organizator będzie się kierował łączną ceną brutto
poszczególnych zadań.
12.4. Organizator przetargu dokona badania ofert w celu stwierdzenia czy Oferenci
nie podlegają wykluczeniu. Następnie Organizator przetargu dokona oceny, czy oferty
Oferentów nie wykluczonych z postępowania nie podlegają odrzuceniu.
12.5. Z postępowania wyklucza się :
1)
Oferentów, w stosunku do których otwarto likwidację lub których upadłość ogłoszono, z
wyjątkiem Oferentów, którzy po ogłoszeniu upadłości zawarli układ zatwierdzony
prawomocnym postanowieniem sądu, jeżeli układ nie przewiduje zaspokojenia wierzycieli
przez likwidację majątku upadłego;
2)
Oferentów, którzy zalegają z uiszczeniem podatków, opłat lub składek
na ubezpieczenia społeczne lub zdrowotne, z wyjątkiem przypadków, gdy uzyskali
oni przewidziane prawem zwolnienie, odroczenie, rozłożenie na raty zaległych płatności lub
wstrzymanie w całości wykonania decyzji właściwego organu;
3)
Oferentów, którzy złożyli nieprawdziwe informacje mające wpływ lub mogące mieć
wpływ na wynik przetargu;
4)
Oferentów, którzy nie wykazali spełniania warunków udziału w postępowaniu.
5)
Oferentów, którzy w odpowiedzi na wezwanie dotyczące treści złożonych ofert i
dokumentów nie przedstawili wyjaśnień lub nie przedstawili dokumentów.
12.6.
W toku badania i oceny ofert Organizator przetargu może żądać od Oferentów
wyjaśnień dotyczących treści złożonych ofert i dokumentów potwierdzających spełnianie
warunków udziału w postępowaniu.
12.7. Zamawiający może zażądać dostarczenia próbki oferowanego Systemu w postaci
komputera przenośnego (laptopa) z zainstalowanymi wszystkimi modułami przedstawionymi
w ofercie, wraz z działającą, testową bazą danych, oraz wszelkimi niezbędnymi do
prawidłowego działania systemu elementami umożliwiającymi prawidłowe działanie systemu,
takimi jak zmienne środowiskowe, biblioteki systemowe, komponenty systemu operacyjnego
itp. Próbka ma umożliwić Zamawiającemu przeprowadzenie weryfikacji oferowanego
systemu.
1. Wymagania Zamawiającego co do próbki:
9
a. Komputer przenośny (laptop) musi posiadać wszelkie parametry techniczne
umożliwiające działanie systemu w celu przeprowadzenia jego weryfikacji;
b. Do próbki musi być dołączona dokumentacja użytkowa, odpowiednia dla
zainstalowanej
wersji
oprogramowania
aplikacyjnego.
Dostarczona
dokumentacja użytkowa musi pozwalać w szczególności na samodzielną
weryfikację
przez
Zamawiającego
spełniania
przez
zaoferowane
oprogramowanie aplikacyjne wszystkich kryteriów oceny;
c. Próbka musi zawierać również oprogramowanie niezbędne do instalacji
środowiska wirtualnego;
d. Zamawiający wymaga założenia konta użytkownika systemu posiadającego
prawa administracyjne do oprogramowania dziedzinowego, tak aby możliwe
było zakładanie nowych użytkowników systemu, wprowadzenie danych
testowych, wykonywanie wykazów oraz wszelkich innych czynności
umożliwiających przeprowadzenie weryfikacji oferowanego oprogramowania
dziedzinowego, celem potwierdzenia, iż oferta odpowiada treści SIWZ.
e. Testowa baza danych:
1. Baza danych powinna zawierać co najmniej kilkaset rekordów
testowych, w celu przeprowadzenia weryfikacji oferowanego
systemu;
2. Baza nie może zawierać danych osobowych rzeczywistych
osób;
f. Oprogramowanie Aplikacyjne będące próbką:
1. Oprogramowanie stanowiące próbkę musi być zgodne z
przedstawioną
ofertą,
z
działającymi
wszystkimi
funkcjonalnościami, zgodnie z wymogami;
2. Zamawiający wymaga założenia konta użytkownika systemu
posiadającego prawa administracyjne do oprogramowania
aplikacyjnego, tak aby możliwe było założenie nowego
użytkownika systemu, wprowadzenie danych testowych,
wykonanie wykazów oraz wszelkich innych czynności
umożliwiających przeprowadzenie weryfikacji oferowanego
systemu, celem potwierdzenia, iż oferta odpowiada treści
SIWZ;
3. Login użytkownika posiadającego prawa administracyjne do
oprogramowania: ADMIN.
12.8.
Organizator przetargu może poprawić w tekście oferty oczywiste omyłki pisarskie
oraz omyłki rachunkowe lub inne omyłki w obliczeniu ceny, niezwłocznie zawiadamiając o
10
tym danego Oferenta. Oferent winien wyrazić zgodę na daną poprawę. W przypadku
odmowy Organizator przetargu odrzuca ofertę.
12.9. Oferty nie odrzucone zostaną poddane procedurze oceny zgodnie z kryteriami oceny
ofert określonymi w Warunkach przetargu.
12.10. Organizator przetargu wybierze ofertę najkorzystniejszą spośród ofert złożonych
przez Oferentów niepodlegających wykluczeniu i ofert nie podlegających odrzuceniu na
podstawie kryteriów oceny ofert określonych w Warunkach przetargu.
12.11 O ile Organizator zorganizuje II etap przetargu – negocjacje – do II etapu zaproszeni
zostaną trzej Oferenci, których oferty uzyskały najlepsze oceny. O ile Oferentów, którzy
złożyli oferty będzie mniej niż trzech zaproszeni zostaną wszyscy. O ile Oferentów, którzy
złożyli oferty będzie więcej niż trzech, a oferty kilku z nich uzyskają taką samą ocenę
zaproszeni zostaną wszyscy, których oferty uzyskały trzy najwyższe oceny.
12.12 W toku negocjacji Oferenci poproszeni zostaną o złożenie w wyznaczonym terminie
ofert dodatkowych modyfikujących pierwotnie złożoną ofertę. Oferty dodatkowe nie mogą
zawierać warunków gorszych niż oferty złożone pierwotnie.
12.13 W przypadku zorganizowania II etapu przetargu w ramach oceny ofert Organizator
przeprowadzał będzie ocenę ofert dodatkowych.
12.14. Niezwłocznie po wyborze najkorzystniejszej oferty Organizator przetargu
zawiadomi Oferentów, którzy złożyli oferty o:
a)
wyborze najkorzystniejszej oferty, podając nazwę (firmę) i adres tego Oferenta,
którego ofertę wybrano, oraz uzasadnienie jej wyboru,
b)
Oferentach, których oferty zostały odrzucone, podając uzasadnienie,
c)
Oferentach, którzy zostali wykluczeni z postępowania podając uzasadnienie.
12.14.a. O ile Oferent, którego oferta wybrana została jako najkorzystniejsza odmówi
podpisania umowy Zamawiający będzie uprawniony do zaproponowania podpisania umowy
Oferentowi, którego oferta została sklasyfikowana na następnym miejscu.
12.15. Organizator przetargu odrzuci ofertę jeżeli:
a)
jej treść nie odpowiada treści Warunków, z zastrzeżeniem ust. 12.8
b)
jej złożenie stanowi czyn nieuczciwej konkurencji w rozumieniu przepisów
o zwalczaniu nieuczciwej konkurencji;
c)
została złożona przez Oferenta wykluczonego z udziału w postępowaniu;
d)
zawiera błędy w obliczeniu ceny;
11
e)
f)
Oferent w terminie 3 dni od dnia doręczenia zawiadomienia sprzeciwił się
poprawieniu przez Organizatora przetargu omyłki, o której mowa w ust. 12.8
jest nieważna na podstawie odrębnych przepisów.
13. Informacje o umowie:
1. Postanowienia umowne zostały przedstawione w załączonym projekcie umowy
stanowiącym załącznik nr 4 do niniejszych Warunków.
2. Umowa zostanie zawarta na warunkach określonych w niniejszym projekcie.
3. Termin zawarcia umowy zostanie podany w treści informacji o wyborze najkorzystniejszej
oferty.
14. Termin wykonania zamówienia:
14.1.
Zamawiający
wymaga
zakończenia
nieprzekraczalnym terminie:
14.1.1. W zakresie Zadania nr 1 - do 31.08.2015 r.;
14.1.2. W zakresie Zadania nr 2-7 - do 29.09.2015 r.
realizacji
zamówienia
w
15. Terminy płatności:
W ciągu 60 dni od daty dostarczenia do siedziby Zamawiającego prawidłowo wystawionej
faktury VAT.
16. Sposób pobierania Zaproszenia do składania ofert:
Zaproszenie do składania ofert jest do pobrania w siedzibie Organizatora przetargu: Grupa
Nowy Szpital spółka z o.o. z siedzibą w Szczecinie, ul. Mazowiecka 13b/6, 70-526 Szczecin
lub na stronie www.nowyszpital.pl
17. Adres strony internetowej, na której znajduje się informacja o przetargu:
www.nowyszpital.pl
18. Zastrzeżenia przetargowe Zamawiającego:
Zamawiający zastrzega sobie prawo dokonania zmiany warunków przetargu w jego trakcie,
a także prawo unieważnienia przetargu bez podawania powodu oraz prawo do zamknięcia
przetargu bez dokonywania wyboru oferty na każdym etapie jego postępowania.
19. Data zamieszczenia ogłoszenia na:
Stronie www - 05.08.2015 r.
Załączniki:
1. Formularz nr 1 - Oferta
12
2. Formularz nr 2 - Oświadczenie
3. Formularz nr 3 – Specyfikacja wymaganych parametrów techniczno-użytkowych
4. Wzór umowy
13
Formularz nr 1 – Oferta
/pieczęć Oferenta/
OFERTA
na przygotowanie projektów wykonawczych, dostawę licencji oraz instalację i integrację
oprogramowania typu HIS, RIS, LIS i Zaopatrzeniowego dla Nowy Szpital w Olkuszu Sp. z
o.o.
Ja (My), niżej podpisany (ni)
..................................................................................................................................................,
Działając w imieniu i na rzecz
....................................................................................................................................................
....................................................................................................................................................
zgodnie z potwierdzonym Formularzem nr 3 – Specyfikacja wymaganych
parametrów techniczno- użytkowych składamy niniejszą ofertę na przygotowanie
projektów wykonawczych, dostawę licencji oraz instalację i integrację oprogramowania
typu HIS, RIS, LIS i Zaopatrzeniowego dla Nowy Szpital w Olkuszu Sp. z o.o.:
Nr
zadania
Nazwa zadania
1
Przygotowanie
projektów
wykonawczych
oprogramowania
typu
HIS,
RIS,
LIS
i
Zaopatrzeniowego
2
3
4
5
Cena
netto [zł]
Dostawa licencji oprogramowania
typu HIS
Dostawa licencji oprogramowania
typu RIS
Dostawa licencji oprogramowania
typu LIS
Dostawa licencji oprogramowania
typu Zaopatrzeniowego
1
Podatek VAT
[zł]
Cena brutto
[zł]
6
7
Instalacja oprogramowania typu
HIS, RIS, LIS i Zaopatrzeniowego
Integracja oprogramowania typu
HIS, RIS, LIS i Zaopatrzeniowego
Razem:
1. Termin płatności 60 dni od daty dostarczenia do siedziby Zamawiającego prawidłowo
wystawionej faktury VAT. Wykonawca zrzeknie się prawa do naliczania odsetek
ustawowych za opóźnienie w zapłacie wynagrodzenia za okres od 31 dnia po wykonaniu
swojego świadczenia i doręczeniu Zamawiającemu faktury VAT do dnia zapłaty, nie
później jednak niż do dnia wymagalności roszczenia z tytułu wynagrodzenia.
2. Przedmiot zamówienia objęty zostaje 12 miesięczną Gwarancją obejmującą między
innymi serwis oraz nadzór autorski (od daty odbioru przedmiotu zamówienia przez
Zamawiającego), o której mowa w ust. 4 pkt 4.8 SWPPO.
3. Gwarantujemy stałą opłatę za serwis i nadzór autorski w zakresie nie węższym niż serwis
i nadzór autorski świadczony w okresie Gwarancji na poziomie: …..………. zł netto
(……………….. zł brutto) rocznie. Gwarancja stałości ceny za serwis oraz nadzór
autorski obowiązuje do 2024 r.
4. Oświadczamy, że uważamy się za związanych niniejszą ofertą przez okres 60 dni.
5. Oświadczamy, że wszystkie stronice (tj. pierwsza strona każdej karty) naszej oferty
łącznie
ze wszystkimi załącznikami są ponumerowane i cała oferta składa się z ....................
stronic.
6. Oświadczamy, iż osobą odpowiedzialną za przygotowanie niniejszej oferty, uprawnioną
do udzielania informacji oraz wyjaśnień dotyczących treści niniejszej oferty, jest:
Pani/Pan: …………………………………………………..
nr tel. stacjonarny: ……………………………………………………….
nr tel. komórkowy: ………………………………………………………
adres poczty elektronicznej: ……………………………………………..
2
adres poczty elektronicznej biura/sekretariatu Oferenta:
…………………………………………….
..........................., dnia .............................
.....................................
3
Formularz nr 2 - Oświadczenie
.........................................................
(pieczęć Oferenta)
Oświadczenie
1. Oświadczam, że Oferent, którego reprezentuję:
1) posiada uprawnienia niezbędne do wykonania określonej działalności
lub czynności jeżeli przepisy odrębne nakładają obowiązek posiadania takich
uprawnień;
2) posiada niezbędną wiedzę i doświadczenie;
3) znajduje się w sytuacji ekonomicznej i finansowej zapewniającej wykonanie
zamówienia;
4) że nie jest wobec niego, jego firmy prowadzone postępowanie upadłościowe,
ani upadłości nie ogłoszono,
5) oświadczenie, że wypełnia zobowiązania podatkowe, uiszcza opłaty
w tym składki na ubezpieczenia społeczne;
6) zapoznał się z warunkami zawartymi w Szczegółowych Warunkach
Nieograniczonego Postępowania Ofertowego / Szczegółowych Warunkach
Pisemnego Publicznego Przetargu Ofertowego do złożenia ofert i nie wnosi
do nich żadnych zastrzeżeń, a także, że zdobył konieczne informacje
potrzebne
do właściwego wykonania zamówienia;
7) akceptuje projekt umowy stanowiący załącznik do Szczegółowych Warunków
Pisemnego Publicznego Przetargu Ofertowego i zobowiązuje się w przypadku
wybrania jego oferty do zawarcia umów na warunkach zawartych w
Szczegółowych Warunkach Pisemnego Publicznego Przetargu Ofertowego, w
miejscu i terminie wyznaczonym przez Organizatora przetargu.
2. Oświadczam, iż oferowany przez nas produkt posiada wszystkie niezbędne
dokumenty potwierdzające dopuszczenie go do użytku szpitalnego zgodnie
z obowiązującymi przepisami prawa. Oświadczam, iż w przypadku wybrania naszej
oferty na żądanie Zamawiającego zobowiązujemy się do dostarczenia kompletu
w/w dokumentów, które stanowić będą załącznik do umowy.
1
........................., dnia .............................
................................................................
(Podpis)
2
Formularz nr 3 – Specyfikacja wymaganych parametrów techniczno-użytkowych
Uwaga! Wszystkie funkcjonalności opisane w niniejszym załączniku muszą zostać
dostarczone przez Oferenta w licencji bez jakichkolwiek ograniczeń.
………………………………
(pieczęć Oferenta)
1. Opis przedmiotu zamówienia
Przedmiot niniejszego zamówienia obejmuje
przeznaczone do wykonania przez Oferenta.
przedstawione
poniżej
zadania,
Oprogramowanie – zbiór aplikacji zawierających oprogramowanie HIS, RIS, LIS
oraz Zaopatrzeniowe.
Celem realizacji niniejszego projektu jest wdrożenie i uruchomienie w warunkach
Zamawiającego, Oprogramowania, za pomocą którego, Zamawiający wprowadzi i będzie
stosował w codziennej pracy szpitala oraz specjalistycznej przychodni przyszpitalnej,
elektronicznej dokumentacji medycznej wszystkich pacjentów.
Zamawiający oczekuje zbudowania Oprogramowania, szczegółowo opisanego w dalszej
części niniejszego załącznika, poprzez:
1. Dostawę licencji Oprogramowania, umożliwiającej również pracę na urządzeniach
mobilnych typu tablet, w zakresie funkcjonalnym opisanym szczegółowo w niniejszym
załączniku, w tabelach funkcjonalności oczekiwanego Systemu. Oferent zobligowany
jest do wypełnienia załączonych poniżej tabel, w miejscach do tego przeznaczonych,
zgodnie ze stanem faktycznym oferowanego rozwiązania.
a. Wszystkie funkcjonalności opisane w niniejszym załączniku muszą zostać
dostarczone przez Oferenta w licencji bez jakichkolwiek ograniczeń, zarówno
ilości użytkowników, stacji roboczych, przestrzeni dyskowej na które mogą
być wykorzystywane, czy jakichkolwiek innych obostrzeń Producenta czy
Oferenta, dostarczanego rozwiązania. Zamawiający oczekuje dostawy tzw.
licencji otwartych, tj. bez jakichkolwiek limitów ze względu na sposób pracy
Zamawiającego.
2. Dostawę kompletu usług pozwalających na bezproblemową pracę użytkowników
Zamawiającego z dostarczonym przez Oferenta rozwiązaniem, tj. usług instalacji,
1
konfiguracji, parametryzacji do pracy Systemu w warunkach Zamawiającego, a także
przeszkolenia personelu Zamawiającego.
a. Oferent zobligowany jest do przeprowadzenia prac instalacyjnokonfiguracyjnych, obejmujących zainstalowanie wszystkich dostarczonych
modułów Oprogramowania, w szczególności dotyczy to instalacji na
serwerach i uruchomieniu oprogramowania na stacjach użytkowników.
Wykonawca zobligowany jest do skonfigurowania każdego dostarczonego
modułu Oprogramowania, zgodnie z jego przeznaczeniem, w ramach
funkcjonalności dostarczonych w niniejszym postępowaniu.
b. Ze względu na czas realizacji zadania Zamawiający wymaga, aby w ramach
programu szkoleń użytkowników personelu medycznego Zamawiającego,
Oferent obligatoryjnie wprowadził, obok tradycyjnych szkoleń oraz konsultacji
stanowiskowych dla użytkowników, również szkolenia elektroniczne, tzw.
szkolenia e-learning, do których dostęp posiadać będzie każdy wskazany
przez Zamawiającego pracownik jego personelu medycznego, który będzie
korzystał z przedmiotowego oprogramowania aplikacyjnego w ramach
Oprogramowania. Szczegółowy opis wymagań funkcjonalnych w zakresie
szkoleń elektronicznych przedstawiony jest w formie tabelarycznej w dalszej
części niniejszego załącznika.
c. W ramach szkolenia użytkowników Zamawiającego przekazana musi zostać
wiedza niezbędna do poprawnego użytkowania dostarczonego przez
Oferenta rozwiązania, zgodnie z jego zakresem funkcjonalnym, tworzeniem i
gromadzeniem danych związanych z wykonywaniem czynności służbowych,
tworzeniem i gromadzeniem dokumentów, wykonywaniem analiz i
sprawozdań,
współpracy
pomiędzy
poszczególnymi
jednostkami
organizacyjnymi Zamawiającego.
d. W ramach realizacji usług szkoleniowych Oferent przeszkoli personel
Zamawiającego w zakresie korzystania z dostarczonego rozwiązania:
i. cały personel medyczny Zamawiającego w zakresie korzystania
z funkcjonalności dostarczonego rozwiązania Oprogramowania,
stosownie do zakresu obowiązków poszczególnych osób personelu
medycznego Zamawiającego,
ii. administratorów IT Zamawiającego w zakresie zarządzania oraz
administrowania dostarczonym rozwiązaniem Oprogramowania,
iii. pracowników działu informatyki Grupy Nowy Szpital sp. z o.o, (Grupy
jako organu właścicielskiego Zamawiającego) w zakresie korzystania
z funkcjonalności dostarczonego rozwiązania Oprogramowania.
3. Na etapie wdrożenia Oferent zaimplementuje do wersji elektronicznych w
dostarczonym Systemie, w sposób uzgodniony z Zamawiającym, szablony formularzy
oraz dokumentów, stanowiących dokumentację medyczną pacjentów, a
2
4.
5.
6.
7.
wykorzystywaną dotychczas w wersji papierowej przez Zamawiającego. Wykonawca
opracuje wzory wydruków w uzgodnieniu z Zamawiającym.
Łączny czas wszelkich usług dostarczonych przez Oferenta związanych z wdrożeniem
i uruchomieniem dostarczonego rozwiązania, w tym wszelkich szkoleń użytkowników,
nie może być krótszy niż 1500 godzin. Oferent zapewni w ramach czasu usług tzw.
konsultacje stanowiskowe dla użytkowników Zamawiającego (fizyczna obecność
przedstawiciela Oferenta w siedzibie Zamawiającego, w godzinach 7.30-15.00 w dni
robocze), w okresie pierwszych dwóch miesięcy po odbiorze i uruchomieniu wszystkich
modułów dostarczonego Systemu, objętych niniejszym zamówieniem.
Wykonawca zobligowany jest do dostarczenia elektronicznych wersji dokumentacji dla
użytkowników poszczególnych modułów Systemu, uwzględniającej dostarczoną
funkcjonalność.
Zamawiający opracuje listy uczestników szkoleń oraz zapewni pomieszczenia do
przeprowadzenia szkoleń, z niezbędnymi stacjami roboczymi, z dostępem do serwera
bazy danych.
Oferent
przeprowadzi oraz udokumentuje uruchomienie wszystkich modułów
oferowanego Systemu w zakresie oraz trybie ustalonym z Zamawiającym podczas
realizacji projektu. Zamawiający zapewni obecność w swoich jednostkach
organizacyjnych pracowników Zamawiającego objętych uruchomieniem.
Oferent
zapewni nadzór co najmniej 1 osoby w każdej komórce organizacyjnej objętej
wdrożeniem.
3
2. Zakres dostarczanych licencji
Zamawiający wymaga dostawy następujących funkcjonalności, umownie podzielonych na
przedstawione poniżej moduły, w nawiasach określono jakiego oprogramowania dotyczy
dany moduł. Oferent zobligowany jest do wypełnienia poniższego zestawienia podając w
kolejnych kolumnach (C, D, F) następujące informacje:
C
– nazwę producenta oferowanego rozwiązania oraz nazwę narzędzia - modułu,
realizującego funkcjonalności opisane w dalszej części Opisu Przedmiotu
Zamówienia,
D
– nazwę wykorzystywanego serwera bazy danych do pracy oferowanego
rozwiązania,
F
– Oferent określa, czy wyszczególniona w danym wierszu funkcjonalność pracuje na
tej samej instancji bazy danych co pozostałe, oferowane funkcjonalności.
ta sama
ta sama
Instancja Instancja
Nazwa
Nazwa
Producent / nazwa
bazy
bazy
Lp.
serwera bazy
funkcjonalności
modułu
danych (1) danych (1)
danych
wymagane oferowane
A
B
C
D
E
F
1. Izba
1 Przyjęć (HIS)
TAK
2. Oddział
2
szpitalny (HIS)
TAK
3.
4.
5.
6.
7.
8.
9.
Symulator JGP (HIS)
Statystyka Medyczna
(HIS)
Rozliczenia z NFZ
(HIS)
TAK
TAK
TAK
Apteka Szpitalna
(Zaopatrzenie)
Apteczka Oddziałowa
(Zaopatrzenie)
Zlecenia medyczne
(LIS)
Punkt Pobrań (HIS)
TAK
TAK
TAK
TAK
10. Bank Krwi (HIS)
Pracownia
11.
Diagnostyczna (RIS)
TAK
TAK
4
12. Blok Operacyjny (HIS)
TAK
Dokumentacja
Medyczna (HIS)
Obchód (aplikacja
14.
mobilna) (HIS)
Przychodnia
15.
Rejestracja (HIS)
Przychodnia Gabinet
16.
Lekarski (HIS)
13.
17.
18.
19.
20.
21.
22.
23.
24.
TAK
TAK
TAK
TAK
Przychodnia Statystyka
(HIS)
TAK
Kolejki Oczekujących
(HIS)
Deklaracje POZ (HIS)
Rehabilitacja (HIS)
Pracownia
Patomorfologii (HIS)
Zakażenia Szpitalne
(HIS)
Dializy (HIS)
Transport sanitarny
(HIS)
TAK
TAK
TAK
TAK
TAK
TAK
TAK
Elektroniczna
25. Dokumentacja
Medyczna (HIS)
26.
NIE
System Informacji
Zarządczej (HIS)
NIE
5
Poniższe moduły funkcjonalne, ze względów bezpieczeństwa nie muszą pracować na tej
samej instancji co pozostałe, powyższe funkcjonalności medyczne Oprogramowania
Zamawiającego, jednakże Zamawiający wymaga, aby instancja na której pracują poniższe
funkcjonalności łączyła się bezpośrednio do instancji, na której pracuje cały powyższy zakres
funkcjonalny Systemu:
Lp Nazwa
. funkcjonalności
A
B
27. e-Rejestracja (HIS)
28. e-Kontrahent (HIS)
Konfigurator do e29. Rejestracji i eKontrahenta (HIS)
Łączność
z
Nazwa
instancją
Producent / nazwa
serwera bazy
bazy
modułu
danych
danych
(1)wymagane
C
D
E
TAK
TAK
Łączność
z instancją
bazy
danych (1)
oferowane
F
TAK
Zamawiający oczekuje, że ze względu na swoją rolę w procesach zachodzących jednostce
Zamawiającego, poniższa lista funkcjonalności pracować będzie na jednej instancji bazy
danych, odrębnej od instancji bazodanowej (nr 1), wymienionej na poprzedniej stronie, ale
mającej z instancją medyczną połączenie:
Lp
.
A
Nazwa
funkcjonalności
B
Sprzedaż Usług
30.
Medycznych (HIS)
Rejestr Sprzedaży
31.
(HIS)
32. Kasa (HIS)
ta sama
ta sama
Instancja Instancja
Nazwa
Producent / nazwa
bazy
bazy
serwera bazy
modułu
danych (2) danych (2)
danych
wymagane oferowane
C
D
E
F
TAK
TAK
TAK
6
Kalkulacja Kosztów
Leczenia (HIS)
Wycena Kosztów
34.
Normatywnych (HIS)
33.
TAK
TAK
7
3. Wymagania dotyczące szkoleń elektronicznych
Szkolenia elektroniczne (e-Learning)
Lp.
Wymaganie (e-Learning)
Wymaga
ne
2.
Szkolenia elektroniczne typu „e-Learning” muszą zostać
dostarczone, co najmniej do następujących obszarów:
- Izba Przyjęć (HIS)
3.
4.
- Oddział Szpitalny (HIS)
- Rejestracja w Przychodni (HIS)
TAK
TAK
5.
6.
7.
- Gabinet Lekarski (HIS)
- Pracownia Diagnostyczna (RIS)
- Apteczka oddziałowa (Zaopatrzenie)
Lekcje muszą zawierać slajd wprowadzający („w tej lekcji
nauczymy się …”) oraz podsumowujący slajd kończący („w tej
lekcji nauczyliśmy się…”).
Lekcje muszą składać się z ekranów (nie ma być to film, aby nie
obciążać sieci).
Lekcje powinny być czytane przez lektora z preferowanym
głosem męskim.
Lekcja mają trwać ok. 20–25 minut i mają być podzielone na
etapy.
Każdy Etap będzie się składał z:
- części lekcyjnej ( animacji trwającej ok. 6-8 minut) podzielonej
na kroki,
- w trakcie trwania animacji po kilku krokach musi występować
około 2 ćwiczeń, gdzie ćwiczenie będzie miało około 5 poleceń.
TAK
TAK
TAK
1.
8.
9.
10.
11.
12.
13.
14.
Po przeprowadzonej lekcji musi nastąpić egzamin praktyczny,
15. składający się on z zadań praktycznych do wykonania lub pytań
testowych.
Lekcja musi zatrzymywać się, wyróżniać i wyraźnie podkreślać
16.
ważne elementy.
W czasie trwania lekcji musi być możliwość cofania i
zatrzymania lekcji, a w przypadku potrzeby przewinięcia do
17. przodu, platforma powinna wymusić konieczność przynajmniej
jednokrotnego przejścia przez całą lekcję – test z danej lekcji
będzie udostępniany po zaliczeniu lekcji.
18. Po zdanym egzaminie Uczący się będzie miał możliwość
8
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
Oferowa
ne
19.
20.
21.
22.
23.
24.
dowolnego poruszania się po lekcji do czasu wygaśnięcia
uprawnień na platformie.
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).
Lekcje ogólne nt interfejsu i standardów aplikacji muszą być
dołączane do różnych pakietów.
Ćwiczenia muszą mieć charakter dobrze zdefiniowanego
zadania, przykładowo: „przyjmij pacjenta o danych NN na izbie
przyjęć …”. Niektóre kroki mogą być prawidłowo wykonane na
kilka sposobów. Jeśli Uczący się wykona nieprawidłowy ruch,
program powinien podpowiedzieć prawidłowy po jednokrotnej
nieudanej próbie. Uczący się otrzyma kompletne opisane
zadanie do wykonania.
Tekst wypowiadany przez lektora musi być również wyświetlony
na ekranie na żądanie Uczącego się.
Egzamin musi posiadać wprowadzenie, w którym będą
wyjaśnione zasady jego przeprowadzenia i oceny. Na końcu
będzie podsumowanie wyników testu.
Uczący się może wykonać egzamin kilkukrotnie w celu
uzyskania lepszego wyniku.
TAK
TAK
TAK
TAK
TAK
TAK
Egzamin po zakończeniu pokazywać będzie błędne odpowiedzi
25. i pozwalać na przeskok do danego fragmentu lekcji, w którym to
zagadnienie było omawiane.
TAK
Lekcje, ćwiczenia, egzaminy, będą pokazywać w którym
26. momencie przerabianego materiału jest Uczący się, i ile kroków
zostało do końca (liczbowo np. krok 10 z 25).
TAK
W szkoleniu znajdzie się miejsce, slajd, ekran - jeden
27. poświęcony informacji, gdzie jest środowisko testowe w
Szpitalu Zamawiającego, i jak się do niego zalogować.
Szkolenie umożliwi wywołanie konkretnej sekcji podręcznika
28. elektronicznego dotyczącej omawianego materiału (podręcznik
w formacie HTML).
9
TAK
TAK
4. Wymagania ogólne w zakresie dostawy oprogramowania
Wymagania ogólne dla modułów oprogramowania aplikacyjnego składających się na
Oprogramowanie Nowego Szpitala w Olkuszu:
Lp.
Wymagania ogólne
Wykonawca – dostawca/producent Oprogramowania,
zobowiązany jest do przekazania Zamawiającemu wszystkich
loginów i haseł Administratora bazy danych, związanych z
zarządzaniem bazą danych i danymi Oprogramowania,
1.
umożliwiających Zamawiającemu, pełną kontrolę i możliwość
pełnego zarządzania bazą danych oraz wszystkimi danymi
gromadzonymi w Oprogramowaniu Zamawiającego, tj.
Nowego Szpitala w Olkuszu.
System musi posiadać interfejs graficzny dla wszystkich
2.
modułów.
3.
4.
5.
6.
System musi pracować w środowisku graficznym MS
Windows na stanowiskach użytkowników (preferowane
środowisko MS Windows XP/Vista/7).
Wszystkie oferowane moduły Zintegrowanego Szpitalnego
Systemu
Informacyjnego
Zamawiającego, tj. Nowego Szpitala w Olkuszu muszą
działać w oparciu o jeden motor bazy danych.
System musi komunikować się z użytkownikiem w języku
polskim. Musi być wyposażony w system podpowiedzi (help).
W
przypadku
oprogramowania
narzędziowego
i
administracyjnego serwera bazy danych - częściowa
komunikacja może odbywać się w języku angielskim.
W funkcjach związanych z wprowadzaniem danych system
musi udostępniać podpowiedzi, automatyczne wypełnianie
pól, słowniki grup danych (katalogi leków, procedur
medycznych, danych osobowych, terytorialnych).
System musi zapewniać odporność struktur danych (baz
danych) na uszkodzenia oraz pozwala na szybkie
7. odtworzenie ich zawartości i właściwego stanu, jak również
posiadać łatwość wykonania ich kopii bieżących oraz łatwość
odtwarzania z kopii. System musi być wyposażony w
10
Wymagane Oferowane
TAK
TAK
TAK
TAK
TAK
TAK
TAK
zabezpieczenia przed nieautoryzowanym dostępem.
Dane muszą być przechowywane w relacyjnym modelu baz
danych, z wykorzystaniem aktywnego serwera baz danych.
System musi być kompatybilny z istniejącą infrastrukturą
8.
Zamawiającego – Klaster Oracle RAC Standard (jedna
instancja serwera do wykorzystania, możliwość utworzenia
wielu baz/schematów).
Musi istnieć możliwość nadania użytkownikowi uprawnień do
pracy wyłącznie w kontekście wybranych jednostek
9.
organizacyjnych np. tylko oddział wewnętrzny i/lub gabinet
POZ i/lub izba przyjęć.
System musi umożliwić zmianę jednostki organizacyjnej, na
10. której pracuje użytkownik bez konieczności wylogowania się
z systemu.
System zarządzania użytkownikami musi być wspólny dla
11.
wszystkich modułów.
System musi być wyposażony w zabezpieczenia przed
nieautoryzowanym dostępem. Zabezpieczenia muszą
12.
funkcjonować na poziomie klienta (aplikacja) i serwera
(serwer baz danych),
System musi posiadać mechanizmy umożliwiające zapis i
13.
przeglądanie danych o logowaniu użytkowników do systemu.
14.
System
musi
umożliwiać
podgląd
zalogowanych do systemu użytkowników.
listy
aktualnie
System musi tworzyć i utrzymywać log systemu, rejestrujący
wszystkich użytkowników systemu i wykonane przez nich
15.
najważniejsze czynności z możliwością analizy historii
zmienianych wartości danych.
Administrator musi posiadać możliwość, z poziomu aplikacji z
modułu „Administrator”, nadawania danemu użytkownikowi
16. unikalnego loginu oraz hasła. Administrator musi posiadać
możliwość ustawienia parametrów hasła: długość, czas
żywotności, czas przed wygaśnięciem.
Administrator musi posiadać z poziomu aplikacji możliwość
17. wylogowania wszystkich użytkowników aplikacji oraz
zablokowania im dostępu do niej przez określony czas.
18. W przypadku przechowywania haseł w bazie danych, hasła
11
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
muszą być zapamiętane w postaci niejawnej (zaszyfrowanej).
Dane muszą być chronione przed niepowołanym dostępem
przy pomocy mechanizmu uprawnień użytkowników. Każdy
użytkownik systemu powinien mieć odrębny login i hasło.
Jakakolwiek funkcjonalność systemu (niezależnie od ilości
modułów) będzie dostępna dla użytkownika dopiero po jego
zalogowaniu.
System
uprawnień
musi
być
tak
19.
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.
Równolegle
musi
istnieć
możliwość
nadawania
użytkownikowi pojedynczych uprawnień z listy dostępnych.
20.
System musi umożliwiać definiowanie grup użytkowników i
przydzielanie użytkowników do tych grup.
System
musi
umożliwiać
nadawanie
uprawnień
użytkownikom do jednostek organizacyjnych, w których
21. pracują, np. lekarz pracujący na izbie przyjęć i oddziale
wewnętrznym powinien w swoich aplikacjach widzieć tylko
pacjentów izby przyjęć i tego jednego oddziału.
System musi umożliwiać administratorowi z poziomu aplikacji
definiowanie i zmianę praw dostępu dla poszczególnych
22.
użytkowników i grup użytkowników z dokładnością do
poszczególnych modułów oraz funkcji systemu.
System musi umożliwić skanowanie danych z dokumentów
23. np. dowodów osobistych i na tej podstawie dokonywanie
automatycznej identyfikacji pacjenta.
System powinien umożliwić obsługę procesów biznesowych
24. realizowanych w szpitalu oraz podpowiadać kolejne kroki
procesu.
System powinien automatycznie wylogowywać lub blokować
25.
sesję użytkownika po zadanym czasie braku aktywności.
Użytkownik po zalogowaniu powinien widzieć pulpit
26. zawierający wszystkie funkcje i moduły dostępne dla tego
użytkownika.
W systemie musi zostać zachowana zasada jednokrotnego
27.
wprowadzania danych. Wymiana danych pomiędzy modułami
12
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
musi odbywać się na poziomie bazy danych.
System
musi
umożliwić
przypisanie
do
komórki
organizacyjnej jednostki, kodu technicznego NFZ. Musi
28.
istnieć możliwość zmiany tego kodu
w czasie pracy
Systemu.
System musi posiadać zintegrowany moduł do planowania
czasu pracy i dyżurów personelu (tworzenie grafików). Dane
29. zawarte w module muszą posiadać funkcję importu/eksportu
danych do zewnętrznych systemów typu kadry-płace, FK, czy
analityka.
System musi autoryzować użytkowników przy pomocy usługi
30.
katalogowej Active Directory.
Moduł LIS będący przedmiotem zamówienia musi potrafić
przesyłać zlecenia badań do laboratorium firmy Diagnostyka
31. oraz odbierać wyniki i przyporządkowywać je do pacjentów i
zleceń w systemie. Słownik badań oraz materiałów musi być
ujednolicony we wszystkich systemach.
Moduł RIS (pracownia diagnostyczna) będący przedmiotem
zamówienia musi integrować się z systemem PACS Agfa
32. IMPAX będącym w posiadaniu Zamawiającego na poziomie
minimum opisanym w funkcjonalnościach oferowanego
rozwiązania.
System musi wspierać serwer wydruku posiadany przez
33.
Zamawiającego (CUPS).
System musi być przygotowany na instalację w środowisku
34. wirtualnym. Musi być kompatybilny z hypervisorem Citrix
XenServer posiadanym przez Zamawiającego.
13
TAK
TAK
TAK
TAK
TAK
TAK
TAK
5. Funkcjonalności oferowanego rozwiązania.
Izba Przyjęć
Lp
Wymaganie (Izba Przyjęć)
.
1. Moduł musi działać w architekturze trójwarstwowej.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Interfejs użytkownika modułu musi być dostępny z poziomu
przeglądarki internetowej i nie może wymagać instalowania
żadnego dodatkowego oprogramowania na stacjach klienckich
(system nie może wymagać korzystania ze specjalnych
programów klienckich technologii typu Citrix, VNC, innych, w
celu realizacji wymagań funkcjonalnych).
Moduł musi umożliwiać pracę z poziomu najbardziej
popularnych przeglądarek, co najmniej Microsoft Internet
Explorer, Google Chrome, Mozilla Firefox, Opera.
Moduł musi umożliwiać pracę na tabletach medycznych lub
komputerach wyposażonych w monitory dotykowe. Pełna
funkcjonalność modułu musi być dostępna na komputerach tego
typu.
Moduł musi umożliwić skanowanie danych z dokumentów
tożsamości - dowodów osobistych lub prawo jazdy i na tej
podstawie dokonywanie automatycznej identyfikacji pacjenta.
Moduł musi umożliwiać obsługę kodów 2D do rejestracji
skierowań pochodzących z innych zakładów opieki.
Moduł musi umożliwiać wykonanie nowej operacji w systemie
bez
konieczności
przerywania
czynności
dotychczas
wykonywanej (np. obsługa zdarzenie w trybie nagłym) i powrót
do zawieszonej czynności bez utraty danych, kontekstu itp.
Wszystkie błędy niewypełnienia pól obligatoryjnych oraz
błędnego wypełnienia muszą być prezentowane w jednym
komunikacie, z możliwością szybkiego przejścia do tego miejsca
aplikacji (np. poprzez odpowiedni link), gdzie te błędy wystąpiły.
Wyróżnienie pól:
- których wypełnienie jest wymagane,
- przeznaczonych do edycji,
- wypełnionych niepoprawnie.
Obsługa rejestru pacjentów
System musi umożliwić obsługę skorowidza pacjentów,
14
Wymaga
ne
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Oferowa
ne
wspólnego dla innych modułów medycznych tj.: Przychodnia,
Pracownia Diagnostyczna, Oddział
15.
System umożliwia wyszukiwanie pacjentów w skorowidzu wg
różnych parametrów:
Tak
16. - status eWUŚ
17. - nazwisko, imię i nr PESEL
Tak
Tak
18. - identyfikator pacjenta w systemie informatycznym
19. - rok pobytu
Tak
Tak
20. - nr w księdze
21. - rozpoznanie
Tak
Tak
22. - lekarz badajacy
Tak
23. System umożliwia rejestrację i modyfikację danych pacjentów
Tak
24. System umożliwia rejestrację pacjenta z Unii Europejskiej,
System umożliwia rejestrację pacjenta przyjmowanego decyzją
25.
wójta/burmistrza
System musi przechowywać historię zmian danych osobowych
pacjenta. Wgląd w dane medyczne sprzed zmiany danych
26. osobowych powinno umożliwić przeglądanie I wydruk
dokumentacji z danymi pacjenta aktualnymi na dzień tworzenia
tej dokumentacji
Z poziomu danych pacjenta NN musi istnieć możliwość
27. powiązania rekordu pacjenta NN z rekordem pacjenta
zarejestrowanego w systemie
Tak
System musi umożliwiać przegląd
pacjenta:
29. - w zakresie danych osobowych,
28.
danych
archiwalnych
Tak
Tak
Tak
Tak
Tak
30. - w zakresie danych z poszczególnych pobytów szpitalnych
31. Rejestracja pacjenta w Izbie Przyjęć
System musi umożliwić pacjenta przyjęcie w trybie nagłym oraz
32.
planowym
Tak
Tak
Tak
Dla przyjęć w trybie nagłym, system musi oznaczać pobyt jako
"zagrożenie życia lub zdrowia"
Tak
Podczas przyjmowania pacjenta skierowanego z gabinetu
34. lekarskiego, działającego w strukturach jednostki, system
powinien informować, że pacjent taki oczekuje na przyjęcie
Tak
33.
System musi umożliwiać rejestrację rozpoznań: wstępnego,
towarzyszących i rozpoznania końcowego
Wprowadzenie danych o rozpoznaniu musi odbywać się z
36.
wykorzystaniem słownika ICD10
35.
15
Tak
Tak
System musi umożliwiać kopiowanie rozpoznań z: poprzedniej
37. jednostki, poprzedniej hospitalizacji, poprzedniego pobytu w
Izbie Przyjęć.
38. System musi umożliwiać:
39. - wprowadzenie danych ze skierowania,
40. - wprowadzenie danych płatnika
41.
Tak
Tak
Tak
Tak
- wpisanie wywiadu wstępnego z możliwością użycia słownika
tekstów standardowych lub dedykowanego formularza
System musi umożliwić odnotowanie wykonanych elementów
leczenia tj:
43. - procedury,
42.
44. - podane leki,
45. - konsultacje.
Podczas uzupełniania danych wywiadu lub badania wstępnego,
system musi umożliwić wykorzystanie informacji uzupełnionych
46.
wcześniej tj: wywiad wstępny, rozpoznanie wstępne lub
rozpoznanie ze skierowania, badanie fizykalne wstępne
System powinien umożliwiać wprowadzenie informacji o
47.
dokumentach uprawniających do uzyskania świadczeń
System musi umożliwiać śledzenie historii dokumentów
48.
uprawniających do uzyskania świadczeń.
System musi umożliwiać rejestrację informacji o wymaganym
49.
transporcie medycznym pacjenta
System musi umożliwiać rejestrację informacji o planowanym
50.
czasie hospitalizacji
System musi posiadać możliwość ewidencji usług rozliczanych
51. komercyjnie.
System
musi
umożliwiać
planowanie,
kosztorysowanie i ofertowanie takich hospitalizacji.
52. Zakończenie pobytu w Izbie Przyjęć
Rejestracja opuszczenia Izby Przyjęć przez pacjenta powinna
53.
umożliwiać wybór jednego z trybów:
54. - skierowanie na oddział,
55. - przeniesienie pacjenta na inną izbę przyjęć,
- odmowa przyjęcia pacjenta do szpitala, skutkująca wpisem do
56.
Księgi Odmów i Porad Ambulatoryjnych,
- zaplanowanie późniejszego terminu przyjęcia, skutkująca
57.
wpisem do Księgi Oczekujących,
- zgon pacjenta na Izbie Przyjęć, skutkujący wpisem do Księgi
58.
Zgonów.
16
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
System musi umożliwiać cofnięcie skierowania na oddział lub
inną izbą przyjęć
Po zatwierdzeniu skierowania pacjenta do oddziału system
60.
drukuje opaskę z kodem kreskowym identyfikującym pacjenta
59.
61.
System umożliwia drukowanie wielu etykiet opatrzonym
identyfikatorem pacjenta np. w postaci kodu paskowego
Podczas kierowania pacjenta na oddział, system podpowiada
planowaną liczbą dni pobytu
63. System musi umożliwić autoryzację danych Izby Przyjęć,
62.
64.
System musi umożliwić ewidencję danych do rozliczenia
produktów kontraktowanych z NFZ
Tak
Tak
Tak
Tak
Tak
Tak
65. Tworzenie dokumentacji Izby Przyjęć
System musi umożliwiać tworzenie i wydruk dokumentacji
66.
indywidualnej pacjentów Izby Przyjęć: tj.:
67. - Karta Wypisowa,
68. - Historia choroby – pierwsza strona
69. - Karta Odmowy.
70. System musi umożliwiać obsługę dokumentacji zbiorczej tj:
71. - Księga Główna,
Tak
72. - Księgi Izby Przyjęć,
73. - Księga Oczekujących,
Tak
Tak
74. - Odmów i Porad Ambulatoryjnych,
75. - Zgonów.
Tak
Tak
76. System musi posiadać wbudowane raporty standardowe:
77. - Ruch chorych Izby Przyjęć – osobowy,
Tak
Tak
78. - Ruch chorych Izby Przyjęć – sumaryczny.
Musi istnieć możliwość definiowania własnych wykazów w
79.
oparciu o zgromadzone w systemie dane
Tak
80.
System musi umożliwiać projektowanie własnych formularzy
dokumentacji medycznej,
System musi zapewniać integrację z innymi modułami systemu
medycznego realizującymi funkcjonalność w zakresie:
82. Integracja z innymi elementami systemu
- ewidencji zużytych leków i materiałów oraz automatycznej
aktualizacji stanów magazynu medycznego, wymagana jest
83.
integracja z dostarczanymi w ramach niniejszego postępowania
modułami „Zlecenia medyczne”, „Apteczka”, „Apteka Szpitalna”,
- wzajemnego udostępniania danych zleceń i danych o ich
84.
wykonaniu - wymagana jest integracja z dostarczanymi w
81.
17
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
ramach niniejszego postępowania modułami „Zlecenia
medyczne”, „Blok Operacyjny”, „Pracownia Diagnostyczna”,
opisanymi w niniejszej specyfikacji,
- wzajemnego udostępniania danych zleceń i danych o ich
85. wykonaniu - wymagana jest integracja z systemem
„Laboratorium”, z którego korzysta centralnie Zamawiający,
- wzajemnego udostępniania danych zleceń i danych o ich
86. wykonaniu - wymagana jest integracja z systemem PACS, z
którego korzysta centralnie Zamawiający.
18
Tak
Tak
Oddział Szpitalny
Lp.
Wymaganie (Oddział szpitalny)
Wymagane Oferowane
Moduł musi działać w architekturze trójwarstwowej.
Interfejs użytkownika modułu musi być dostępny z poziomu
przeglądarki internetowej i nie może wymagać instalowania
żadnego dodatkowego oprogramowania na stacjach
klienckich (system nie może wymagać korzystania ze
specjalnych programów klienckich technologii typu Citrix,
VNC, innych, w celu realizacji wymagań funkcjonalnych).
Moduł musi umożliwiać pracę z poziomu najbardziej
popularnych przeglądarek, co najmniej Microsoft Internet
Explorer, Google Chrome, Mozilla Firefox, Opera.
Moduł musi umożliwiać pracę na tabletach medycznych lub
komputerach wyposażonych w monitory dotykowe. Pełna
funkcjonalność modułu musi być dostępna na komputerach
tego typu.
Moduł musi umożliwiać wykonanie nowej operacji w systemie
bez konieczności przerywania czynności dotychczas
wykonywanej (np. obsługa zdarzenie w trybie nagłym) i
powrót do zawieszonej czynności bez utraty danych,
kontekstu itp.
Wszystkie błędy niewypełnienia pól obligatoryjnych oraz
błędnego wypełnienia muszą być prezentowane w jednym
komunikacie, z możliwością szybkiego przejścia do tego
miejsca aplikacji (np. poprzez odpowiedni link), gdzie te błędy
wystąpiły.
Wyróżnienie pól:
- których wypełnienie jest wymagane,
Tak
9. - przeznaczonych do edycji,
10. - wypełnionych niepoprawnie.
Pulpit główny modułu powinien zawierać podstawowe
informacje liczbowe informujące o liczbie aktualnie
11.
przebywających w oddziale pacjentach, o liczbie pacjentów
wypisywanych, do przyjęcia, liczbie zleceń do obsłużenia
12. Obsługa rejestru pacjentów
System musi umożliwiać wyszukiwanie pacjentów na liście
13.
wg różnych parametrów, w tym:
Tak
Tak
1.
2.
3.
4.
5.
6.
7.
8.
19
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
14.
- stan pacjenta
Tak
16.
17.
18.
19.
20.
- status pacjenta ( przysłany z IP, przebywający na oddziale,
skierowany do innej jednostki, na przepustce, uciekinier)
- status eWUŚ
- identyfikator pacjenta
- lekarz prowadzący
- nazwisko i imię
- nr księgi głównej
21.
22.
- rozpoznanie
- płatnik
Tak
Tak
23.
24.
- nr kartoteki i karty pacjenta
- zlecenia modyfikowane w ciągu ostatnich X godzin
Tak
Tak
25.
- z aktualnymi zleceniami leków
Tak
26.
27.
28.
29.
30.
31.
- obsługiwani w innych jednostkach
- z przepustkami do zatwierdzenia
- zlecenia leków do potwierdzenia
- obsługiwani w trybie IOM
- bez opisu historii choroby
- daty urodzenia
- wyszukanie pacjenta z wykorzystanie kodu paskowego z
opaski
System musi umożliwić modyfikację danych osobowych
pacjentów przebywających na oddziale.
System musi umożliwić przeglądanie danych archiwalnych
pacjenta w zakresie:
- danych osobowych,
- danych z poszczególnych pobytów szpitalnych,
System musi umożliwiać rejestrację i śledzenie historii
dokumentów uprawniających do uzyskania świadczeń.
Przyjęcie pacjenta na oddział
Tak
Tak
Tak
Tak
Tak
Tak
15.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
Przyjęcie pacjenta do oddziału powinno odbywać się w
jednym z trybów:
- w trybie nagłym w wyniku przekazania przez zespół
ratunkowy
- w trybie nagłym
- planowane na podstawie skierowania
- planowane, poza kolejnością, na podstawie posiadanych
uprawnień
20
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
44.
- przymusowe
Tak
45.
46.
- przeniesienie z innego szpitala
- przyjęcie osoby podlegającej obowiązkowemu leczeniu
Tak
Tak
- noworodka, w wyniku porodu w tym szpitalu (dla oddziału
neonatologicznego)
System musi umożliwić rejestrację odmowy lub anulowania
przyjęcia do Oddziału, skutkujące wycofaniem danych
48.
pacjenta na Izbę Przyjęć lub innej jednostki kierującej (inny
oddział)
47.
49.
50.
51.
52.
53.
54.
System musi umożliwiać zaplanowanie późniejszego terminu
przyjęcia – wpis do Księgi Oczekujących Oddziału,
System powinien prezentować czas, jaki upłynął od ostatniej
hospitalizacji, w tym hospitalizacji o tym samym rozpoznaniu,
co aktualna
Podczas rejestracji przyjęcia pacjenta na oddział system
powinien umożliwiać:
- nadanie numeru Księgi Oddziałowej – automatycznego lub
wpisanie przez użytkownika,
- wprowadzenie danych lekarza prowadzącego,
- możliwość modyfikacji danych płatnika,
- wprowadzenie danych o miejscu hospitalizacji w ramach
oddziału: odcinka oddziałowego, łóżka,
- wprowadzenie danych o rodzaju hospitalizacji do celów
56. statystycznych, np. całodobowa z zabiegiem operacyjnym,
dzienna z bez zabiegów i badań laboratoryjnych, itp.
55.
- podpowiadanie czasu trwania pobytu na oddziale. System
57. powinien umożliwiać określanie domyślnej liczby dni pobytu
dla oddziałów
58. Pobyt pacjenta na oddziale
System musi umożliwić rejestrację wywiadu wstępnego z
59. możliwością użycia słownika tekstów standardowych lub
zdefiniowanych formularzy,
System musi umożliwiać rejestrację rozpozń: wstępnego,
60.
końcowego, przyczyny zgonu,
System musi podpowiadać rozpoznanie wstępne –
61. oddziałowego, takie samo, jak rozpoznanie z poprzedniego
pobytu
Podczas rejestracji danych dot pobytu system, w zależności
62.
od statusu pobytu, podpowiada do wypełnienia odpowiedni
21
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
63.
64.
65.
66.
67.
68.
69.
70.
typ rozpoznania. Jeśli pobyt nie posiada statusu "zamknięty"
to domyslnie podpowiadanym rozpoznaniem,
jest
rozpoznanie wstępne
System
powinien
sygnalizować
brak
rozpoznania
dodatkowego z zakresu V-Y przy podanym rozpoznaniu
zasadniczym z grup S-T
System musi umożliwiać autoryzację, przez lekarza,
rejestrowanych elementów historii choroby
Dla wpisów autoryzowanych, system musi prezentować
informacje o dacie i godzinie autoryzacji oraz osobie
autoryzującej
System
musi
umożliwiać
rejestrację
informacji
o
zdeponowanych przez pacjenta rzeczach, z wpisem do
wybranej księgi depozytów
System musi umożliwić wpisanie planowanego czasu trwania
hospitalizacji
System powinien umożliwać zdefiniowanie standardowego
czasu pobytu pacjenta dla każdego z oddziałów. Czas ten
powinien być podpowiadany podczas przyjęcie pacjenta na
oddział.
Dla oddziału psychiatrycznego, system powinien umożliwiać
wyliczanie długości pobytu zależnej od rozpoznania
System musi informować o przeterminowanych pobytach w
zależności od rozpoznania
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
System
musi
umożliwić
zamówienie
dokumentacji
71. medycznej, przechowywanej w archiwum, dla pacjentów
przebywających w oddziale
Tak
System musi umożliwiać przegląd historii zmian danych
pobytu w oddziale
Tak
72.
73.
74.
75.
76.
77.
78.
79.
System musi umożliwiać rejestrację wykonanych oraz
zlecanych pacjentowi elementów leczenia, w szczególności:
- procedur, w tym zabiegów, z możliwością ich
wprowadzania wg zdefiniowanych grup
- badań diagnostyczne,
- leków,
- konsultacji,
- diet,
Powinna istnieć możliwość jednoczesnego dodawania i
usuwania wielu procedur
22
Tak
Tak
Tak
Tak
Tak
Tak
Tak
80. System musi umożliwić ewidencję przepustek
Tak
W danych medycznych pacjenta musi istnieć możliwość
rejestracja informacji o szczepieniach, alergii, chorobach
81. przewlekłych, grupie krwi. Dane te powinny być na stałe
przypisane do pacjenta i widoczne w kontekście każdego
pobytu.
Tak
Dla grupy krwi powinna być możliwość potwierdzenia przez
82. lekarza oraz możliwość załączenia skanu dokumentu
potwierdzającego grupę
Tak
Ewidencja danych do rozliczenia kontraktowanych produktów
z płatnikiem, w tym rozliczanie kart TISS28,
Tak
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
System musi umożliwić tworzenie kart kwalifikacji do żywienia
dojelitowego i pozajelitowego
Opieka pielęgniarska
System musi umożliwiać ewidencję diagnoz pielęgniarskich,
co najmniej, w zakresie:
- wprowadzania diagnoz (przy użyciu słownika diagnoz
funkcjonującego w szpitalu)
- realizacji procedur wynikających z diagnoz,
- dodania lub usuwania wielu procedur jednocześnie
- odnotowania realizacji wielu procedur jednocześnie
- edycji opisu wykonanej procedury
- planu realizacji
- wydruku indywidualnej karty procesu pielęgnacji
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
System
musi umożliwiać wydruk karty gorączkowej z
94. możliwością wyboru pomiarów , jakie powinny pojawić się na
karcie
Tak
Ewidencja pomiarów dokonywanych pacjentowi wg ustalonej
przez użytkownika kolejności
Tak
Musi istnieć możliwość wydruku siatek centylowych dla
96. pomiaru wzrostu, wagi, obwodu głowy i BMI dla pacjentów w
różnych grupach wiekowych.
Tak
97. System musi umożliwić ewidencję przebiegów pielęgniarskich
98. System musi umożliwiać wydruk przebiegów pielegniarskich
Tak
Tak
95.
Musi istnieć możliwość wykorzystania definiowanych
formularzy do opisu przebiegu pielęgniarskiego
Tworzenie zapotrzebowania żywnościowego dla pacjentów
100.
oddziału z możliwością przeliczenia ilości zamawianych
99.
23
Tak
Tak
posiłków wg przypisanych pacjentom diet
101.
Możliwość uzupełnienie zapotrzebowania żywnościowego o
zamówienia dodatkowych posiłków i materiałów
Musi istnieć możliwość odnotowania podania leku
należącego do pacjenta
System musi umozliwić tworzenie dokumentacji związanej z
103.
oceną stanu odżywiania pacjenta
104. Oddział ginekologiczno - położniczy
102.
System musi umożliwić ewidencję danych porodu, co
najmniej w zakresie :
106. - wpis do Księgi Porodów,
107. - odnotowanie personelu uczestniczącego,
108. - odnotowanie danych noworodka (medyczne, Apgar)
105.
Dla porodów zabiegowych musi istnieć możliwość
odnotowania rodzaju porodu:
110. - cesarskie cięcie
111. - kleszcze
112. - próżnociąg
113. Musi istnieć możliwość drukowania karty obserwacji porodu
System powinien umożliwiać określanie reguł nadawania
114.
imion noworodkom
Na oddziale Neonatologicznym, w danych medycznych
115.
noworodka wgląd w dane porodu i dane matki
116. Chemioterapia/onkologia
System musi posiadać obsługę oddziału chemioterapii
117. onkologicznej i posiadać funkcję zlecania chemioterapii oraz
zlecania i rozliczania anestetyków.
118. Zakończenie pobytu
109.
System musi umożliwić rejestrację opuszczenia oddziału
przez pacjenta w jednym z trybów:
- przeniesienie/wycofanie przeniesienia pacjenta na inny
120.
Oddział.
- przeniesienie w trybie nagłym na inny Oddział (bez
121.
uzupełnienia danych wypisowych z poprzedniego oddziału),
122. - wypis pacjenta ze Szpitala,
119.
123. - zgon pacjenta na Oddziale, z możliwością odnotowania:
124. -- innej osoby wypisującej a innej stwierdzającej zgon
125. -- danych medycznych po zarejestrowaniu zgonu pacjenta
24
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
-- rodzaju zgonu: nagły, śródoperacyjny, śródzabiegowy,
inny
127. -- oznaczenia pacjenta jako dawcy organów
128. -- wycofanie aktywnych deklaracji POZ
Odnotowanie faktu wydania pacjentowi druków, zaświadczeń,
129.
skierowań itp.,
126.
Podczas rejestracji zgonu pacjenta, system powinien
130. anulować wszystkie zlecenia, zaplanowane wizyty oraz wpisy
w kolejce oczekujących
131. Przygotowanie dokumentacji medycznej
System musi umożliwić autoryzację danych oddziałowych, co
132.
najmniej w zakresie:
133. - rozpoznań,
134. - epikryz,
135. - obserwacji lekarskich.
Danych autoryzowanych nie można usunąć ani modyfikować,
136.
jedynie oznaczyć jako nieaktualne
Podczas wpisywania treści rozpoznania opisowego, system
137. musi umożliwiać wykorzytsnie wszystkich tekstów zapisanych
wcześniej w historii choroby pacjenta.
138. Możliwość projektowania formularzy dokumentacji medycznej
139. Możliwość definiowania własnych szablonów wydruków,
140. Możliwość definiowania własnych wykazów
System musi informować o konieczności utworzenia
141. właściwego dokumentu w oparciu o informacje o wyniku
badania (patogen alarmowy)
142. Przechowywanie wszystkich wersji utworzonych dokumentów
Przegląd i modyfikacja pełnej historii choroby, wszystkie jej
143. elementy powinny być dostępne w jednym miejscu, na
jednym ekranie
144. Prowadzenie i wydruk Historii Choroby w podziale na:
145. - dane przyjęciowe,
146. - wywiad wstępny (przedmiotowo, podmiotowo),
147. - przebieg choroby,
- epikryza (możliwością wykorzystania słownika tekstów
148.
standardowych).
- kopiowanie wyników badania i danych wypisowych z
poprzednich pobytów w ramach jednej hospitalizacji
150. System musi umożliwić wydruk dokumentów wewnętrznych
149.
25
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
oddziału, w tym:
151. - Karty Wypisowa,
152. - Karty Informacyjna.
Tak
Tak
System musi umożliwić wydruk dokumentów zewnętrznych
oddziału, w tym:
154. - Karty Statystyczna,
155. - Karty Leczenia Psychiatrycznego,
- System musi umożliwić kopiowanie kart leczenia
156.
psychiatrycznego
157. - Karta Zakażenia Szpitalnego,
153.
Tak
Tak
Tak
Tak
Tak
158. - Karta Nowotworowa,
159. - Karta Zgłoszenia Choroby Zakaźnej,
Tak
Tak
160. - Karta Zgonu,
161. - Karta TISS28.
162. System musi umożliwić obsługę ksiąg:
163. - Księga Główna,
164. - Oddziałowa,
165. - Oczekujących,
166. - Zgonów,
167. - Noworodków,
168. - Zabiegów.
169. - Transfuzji
170. - Raportów Lekarskich
171. - Raportów Pielęgniarskich
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Podczas wydruku zbiorczej dokumentacji medycznej musi
istnieć możliwość definiowania zakresów ksiąg do wydruku
172.
obejmująca:
wybrane strony, wybrane jednostki organizacyjne
System musi posiadać możliwość utworzenia i wydrukowania
173.
standardowych raportów:
- zestawienie pacjentów, nowoprzyjętych, wypisanych,
174. przebywających na oddziale (dzienne, tygodniowe, za
dowolny okres)
- liczba osobodni z uwzględnieniem przepustek, w zadanym
175.
okresie
176. - obłożenie łóżek na dany moment
177. - diety podane pacjentom oddziału.
- zaświadczenie o pobycie pacjenta zawierające: nazwisko i
178.
imię pacjenta, nazwę oddziału(kliniki), okres pobytu,
26
Tak
Tak
Tak
Tak
Tak
Tak
Tak
rozpoznanie zasadnicze
179. - raport z dyżuru lekarskiego
- raport z przebiegów pielęgniarskich powinien uwzględniać
180. sortowanie w porządku malejącym lub rosnącym wg daty
wykonania i osoby wykonującej
Integracja z innymi modułami systemu medycznego
181.
realizującymi funkcjonalność w zakresie:
- ewidencji zużytych leków i materiałów oraz aktualizacji
182.
stanów magazynowych (Apteczka oddziałowa),
- wzajemnego udostępniania danych zlecenia i danych o
183. jego wykonaniu (Przychodnia, Pracownia Diagnostyczna,
Blok Operacyjny).
184. - tworzenia zamówień na krew i preparaty krwiopochodne
185. - tworzenie zamówień na krew na "ratunek życia"
- odnotowanie podań krwi i preparatów krwiopochodnych z
186. wpisem do księgi transfuzyjnej, odnotowanie powikłań po
przetoczeniu
Możliwość ewidencji
wykonania usług
rozliczanych
187.
komercyjnie.
188. JGP:
Wyznaczanie Jednorodnych Grup Pacjentów na podstawie
danych hospitalizacji za pomocą wbudowanego grupera JGP
Import aktualnego słownika procedur medycznych ICD9
190.
(komunikat ICD9),
191. Wyznaczanie JGP dla hospitalizacji
189.
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Możliwość wyznaczania JGP dla każdego z pobytów
oddzielnie
Tak
Zapewnienie sprawnego zasilania systemu w aktualne
193. charakterystyki JGP wynikające z publikowanych Zarządzeń
Prezesa NFZ
Tak
192.
Wyznaczanie JGP za pomocą wbudowanego (lokalnego)
grupera JGP w zakresie umów: leczenie szpitalne,
194.
rehabilitacja
stacjonarna,
ambulatoryjna
opieka
specjalistyczna
Możliwość ręcznego wyznaczenia JGP dla hospitalizacji z
195.
pominięciem grupera lokalnego i grupera NFZ
Możliwość automatycznego przypisania JGP do pobytu na
196. oddziale, z którego pochodzi element kierunkowy
wyznaczonej JGP
27
Tak
Tak
Tak
Wsteczna weryfikacja poprawności wyznaczonych wcześniej
JGP z możliwością aktualizacji JGP na poprawną
Różnice wynikające z wczytania nowych wersji grupera, które
198. opublikowano z wsteczną datą obowiązywania, które mogą
obejmować
199. - Różnice w zaewidencjonowanych taryfach,
197.
Tak
Tak
Tak
200. - Różnice w zaewidencjonowanych JGP,
Różnice wynikające z modyfikacji danych statystycznych
201.
hospitalizacji, a mające wpływ na wyznaczoną JGP:
Tak
202. - Konieczność zmiany JGP,
203. - Konieczność zmiany taryfy,
Tak
Tak
204. - Konieczność przepięcia JGP do pobytu na innym oddziale
205. Wyszukiwanie hospitalizacji wg poniższych kryteriów
206. - Data zakończenia hospitalizacji,
207. - Wersja grupera za pomocą którego wyznaczono JGP
208. - Kod JGP,
209. - Rozpoznanie główne
210. - Kod procedury medycznej,
211. - Status rozliczenia
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Wskazanie możliwości uzyskania JGP o większej taryfie w
przypadku zmiany kombinacji rozpoznań wypisowych
Wsteczna weryfikacja z możliwością aktualizacji JGP pod
213.
kątem znalezienia bardziej optymalnej JGP
212.
Jeśli dla hospitalizacji istnieje aktywne świadczenie JGP ze
wskazanym sposobem rozliczenia związanym z urazami
wielonarządowymi (UJ1, UJ2, UJ3), system powinien
214.
sprawdzić, czy wśród rozpoznań wypisowych hospitalizacji
występuje rozpoznanie z listy T07 dla wersji grupera zgodnej
ze wskazanej w świadczeniu JGP
Możliwość wydrukowania charakterystyki wybranej JGP w
formie podręcznej karty
Możliwość wykonywania symulacji wyznaczania JGP
216.
(funkcjonalność Symulatora JGP)
215.
28
Tak
Tak
Tak
Tak
Tak
Tak
Symulator JGP
Lp.
Wymaganie (Symulator JGP)
Wymagane Oferowane
Moduł musi działać w architekturze trójwarstwowej.
Interfejs użytkownika modułu musi być dostępny z poziomu
przeglądarki internetowej i nie może wymagać instalowania
żadnego dodatkowego oprogramowania na stacjach
klienckich (system nie może wymagać korzystania ze
specjalnych programów klienckich technologii typu Citrix,
VNC, innych, w celu realizacji wymagań funkcjonalnych).
Moduł musi umożliwiać pracę z poziomu najbardziej
popularnych przeglądarek, co najmniej Microsoft Internet
Explorer, Google Chrome, Mozilla Firefox, Opera.
Moduł musi umożliwiać pracę na tabletach medycznych lub
komputerach wyposażonych w monitory dotykowe. Pełna
funkcjonalność modułu musi być dostępna na komputerach
tego typu.
Moduł musi umożliwiać wykonanie nowej operacji w systemie
bez konieczności przerywania czynności dotychczas
wykonywanej (np. obsługa zdarzenie w trybie nagłym) i
powrót do zawieszonej czynności bez utraty danych,
kontekstu itp.
Wszystkie błędy niewypełnienia pól obligatoryjnych oraz
błędnego wypełnienia muszą być prezentowane w jednym
komunikacie, z możliwością szybkiego przejścia do tego
miejsca aplikacji (np. poprzez odpowiedni link), gdzie te błędy
wystąpiły.
Wyróżnienie pól:
- których wypełnienie jest wymagane,
Tak
9. - przeznaczonych do edycji,
10. - wypełnionych niepoprawnie.
Symulator dostępny w systemie, działający w oparciu o dane
11.
medyczne zgromadzone w systemie medycznym
Symulator dostępny poprzez przeglądarkę www bez
12.
konieczności dostępu do zewnętrznej sieci Internet
Wstępne zasilenie symulatora danymi z wybranej
13.
hospitalizacji
14. Możliwość sprawnej modyfikacji danych w symulatorze i
Tak
Tak
1.
2.
3.
4.
5.
6.
7.
8.
29
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
obserwacja wpływu zmian na wyznaczane JGP
15. Modyfikacja danych pacjenta (wiek, płeć),
Modyfikacja danych hospitalizacji (data przyjęcia, data
16. wypisu, tryb przyjęcia, tryb wypisu, tryb i charakter
hospitalizacji,
17. Dodanie lub usuniecie pobytu
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
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))
Wyróżnianie kolorami danych hospitalizacji nieistotnych z
punktu widzenia wyznaczenia JGP
Możliwość określenia wersji grupera, za pomocą którego
wyznaczone zostaną JGP
Wersja grupera wynikająca z daty zakończenia hospitalizacji,
Dowolna wersja grupera istniejąca w systemie,
Wskazywanie JGP z podziałem na:
- JGP, dla której hospitalizacja spełnia warunki wyboru,
- JGP, dla których hospitalizacja nie spełnia warunków,
- JGP, które istnieją w planie umowy świadczeniodawcy,
Wyróżnienie kolorem pozycji w celu odzwierciedlenia
ważności wyznaczonych JGP z punktu widzenia
świadczeniodawcy (np. istniejących w planie umowy a tym
samym możliwych do rozliczenia)
W przypadku wskazania JGP do których pacjent mógłby
zostać zakwalifikowany jednak nie zostały spełnione
wszystkie warunki - wskazanie tych warunków
Możliwość przeglądu podstawowych informacji o wybranej
JGP
30. Wartości taryf dla poszczególnych trybów hospitalizacji,
29.
Parametry związane z mechanizmem osobodni (liczba dni
finansowana grupą, taryfa dla hospitalizacji trwających < 2
31.
dni, wartość punktowa osobodnia ponad ryczałt finansowany
grupą),
32. Parametry JGP (warunki, które musi spełniać hospitalizacja),
Wykorzystanie planu umowy dla JGP w przypadku, gdy JGP
33. istnieje
w umowie,
34. Prezentacja wykresów ilustrujących zależność naliczonych
30
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
taryf od czasu hospitalizacji pacjenta
31
Statystyka Medyczna
Lp.
1.
2.
3.
4.
5.
6.
7.
8.
Wymaganie (Statystyka medyczna)
Moduł musi działać w architekturze trójwarstwowej.
Interfejs użytkownika modułu musi być dostępny z poziomu
przeglądarki internetowej i nie może wymagać instalowania
żadnego dodatkowego oprogramowaniach na stacjach
klienckich (system nie może wymagać korzystania ze
specjalnych programów klienckich technologii typu Citrix,
VNC, innych, w celu realizacji wymagań funkcjonalnych).
Moduł musi umożliwiać pracę z poziomu najbardziej
popularnych przeglądarek, co najmniej Microsoft Internet
Explorer, Google Chrome, Mozilla Firefox, Opera.
Moduł musi umożliwiać pracę na tabletach, w tym także
tabletach medycznych oraz komputerach wyposażonych w
monitory dotykowe. Pełna funkcjonalność modułu musi być
dostępna na komputerach tego typu.
Moduł musi umożliwiać wykonanie nowej operacji w systemie
bez konieczności przerywania czynności dotychczas
wykonywanej (np. obsługa zdarzenie w trybie nagłym) i
powrót do zawieszonej czynności bez utraty danych,
kontekstu itp.
Wszystkie błędy niewypełnienia pól obligatoryjnych oraz
błędnego wypełnienia muszą być prezentowane w jednym
komunikacie, z możliwością szybkiego przejścia do tego
miejsca aplikacji (np. poprzez odpowiedni link), gdzie te błędy
wystąpiły.
Wyróżnienie pól:
- których wypełnienie jest wymagane,
9. - przeznaczonych do edycji,
10. - wypełnionych niepoprawnie.
Obsługa głównego i jedynego skorowidza pacjentów
11.
Oprogramowania Zamawiającego:
- wyszukiwanie pacjentów w skorowidzu wg różnych
12.
parametrów,
13. - rejestracja i modyfikacja danych pacjentów.
14. Przegląd danych archiwalnych pacjenta:
15. - w zakresie danych osobowych,
32
Wymagane Oferowane
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
16.
- w zakresie danych z poszczególnych pobytów szpitalnych.
Potwierdzenia wypisu pacjenta pod kątem kompletności i
17.
poprawności dokumentacji.
18. Wbudowane wydruki zewnętrzne:
Tak
19.
20.
Tak
Tak
- Karta statystyczna,
- Karta leczenia psychiatrycznego,
21. - Karta zgonu,
22. Obsługa Ksiąg:
Tak
Tak
Tak
Tak
23.
24.
- Księga główna,
- Księga odmów,
Tak
Tak
25.
26.
- Księga zgonów,
- Księga noworodków,
Tak
Tak
27. Możliwość definiowania własnych szablonów wydruków.
28. Wbudowane raporty standardowe:
- zestawienie pacjentów, nowoprzyjętych, wypisanych,
29. przebywających na oddziale (dzienne, tygodniowe, za
dowolny okres),
- liczba osobodni z uwzględnieniem przepustek, w zadanym
30.
okresie,
Tak
Tak
- obłożenie łóżek na dany moment,
- diety podane pacjentom oddziału.
Możliwość definiowania własnych wykazów w zakresie
33.
danych gromadzonych w module.
Tak
Tak
31.
32.
Możliwość projektowania formularzy dokumentacji medycznej
w miarę pojawiających się indywidualnych potrzeb
34.
użytkowników, na podstawie danych gromadzonych w
module.
35. Wbudowane raporty standardowe:
36.
37.
38.
39.
40.
41.
- statystyczne z oddziałów: np. Dziennik ruchu chorych,
wskaźniki szpitalne w okresie (liczba. przyjętych, liczba
wypisanych, liczba osobodni),
- z obłożenia łóżek,
- zestawienia wg jednostek chorobowych, czasu leczenia
jednostki chorobowej (sumaryczne i osobowe).
Elektroniczna komunikacja z instytucjami nadrzędnymi, w
tym:
- Oddziały NFZ,
- Centrum Zdrowia Publicznego.
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
33
Eksport danych statystycznych oraz ilościowych o
wykonanych świadczeniach do pliku tekstowego lub w
42. formacie .xls, z możliwością wykorzystania przez moduł
Kalkulacji kosztów leczenia, oferowane przez Oferenta w
niniejszym postępowaniu, a opisany w niniejszej specyfikacji.
34
Tak
Rozliczenia z NFZ
Lp.
Wymaganie (Rozliczenia z NFZ)
Wymagane Oferowane
Tak
7.
8.
Moduł musi działać w architekturze trójwarstwowej.
Interfejs użytkownika modułu musi być dostępny z poziomu
przeglądarki internetowej i nie może wymagać instalowania
żadnego dodatkowego oprogramowaniach na stacjach
klienckich (system nie może wymagać korzystania ze
specjalnych programów klienckich technologii typu Citrix,
VNC, innych, w celu realizacji wymagań funkcjonalnych).
Moduł musi umożliwiać pracę z poziomu najbardziej
popularnych przeglądarek, co najmniej Microsoft Internet
Explorer, Google Chrome, Mozilla Firefox, Opera.
Moduł musi umożliwiać pracę na tabletach medycznych lub
komputerach wyposażonych w monitory dotykowe. Pełna
funkcjonalność modułu musi być dostępna na komputerach
tego typu.
Moduł musi umożliwiać wykonanie nowej operacji w systemie
bez konieczności przerywania czynności dotychczas
wykonywanej (np. obsługa zdarzenie w trybie nagłym) i
powrót do zawieszonej czynności bez utraty danych,
kontekstu itp.
Wszystkie błędy niewypełnienia pól obligatoryjnych oraz
błędnego wypełnienia muszą być prezentowane w jednym
komunikacie, z możliwością szybkiego przejścia do tego
miejsca aplikacji(np. poprzez odpowiedni link), gdzie te błędy
wystąpiły.
Wyróżnienie pól:
- których wypełnienie jest wymagane,
9.
10.
11.
12.
13.
14.
15.
16.
- przeznaczonych do edycji,
- wypełnionych niepoprawnie.
Zarządzanie umowami NFZ.
Import pliku umowy w postaci komunikatu UMX.
Przegląd i modyfikacja szczegółów umowy:
- okres obowiązywania umowy,
- pozycje planu umowy,
- miejsca realizacji świadczeń,
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
17.
- limity na realizację świadczeń i ceny jednostkowe,
Tak
1.
2.
3.
4.
5.
6.
35
Tak
Tak
Tak
Tak
Tak
Tak
Tak
- słowniki związane z umowami (słownik zakresów
18. świadczeń, świadczeń jednostkowych, pakietów świadczeń,
schematów leczenia itd.),
19. - parametry pozycji pakietów świadczeń.
Moduł musi korzystać bezpośrednio z danych
20. zaewidencjonowanych na oddziałach i w poradniach bez
konieczności importu i kopiowania danych.
Weryfikacja wprowadzonych pozycji rozliczeniowych pod
kątem zgodności ze stanem, po wczytaniu aneksu umowy (ze
21. wstecznym okresem obowiązywania). Możliwość zbiorczej
modyfikacji pozycji rozliczeniowych, w których znaleziono
różnice:
Tak
Tak
Tak
Tak
Tak
Tak
25.
26.
27.
28.
- różnica w cenie świadczenia,
- różnica w wadze efektywnej świadczenia,
- różnica w sposobie obliczania krotności i okresu
sprawozdawczego.
Definiowanie dodatkowych walidacji:
- liczba realizacji świadczeń w okresie,
- liczba realizacji świadczeń w ramach zakresu w okresie.
Możliwość ewidencji i rozliczenia realizowanych świadczeń :
29.
30.
- ubezpieczonym,
- nieubezpieczonym a uprawnionym do świadczeń,
Tak
Tak
31.
32.
- uprawnionym na podstawie decyzji wójta/burmistrza,
- uprawnionym na podstawie przepisów o koordynacji,
Tak
Tak
- uprawnionym na podstawie Karty Polaka ,
- kobietom w ciąży, w okresie połogu oraz młodzieży do 18
34.
roku życia.
Tak
22.
23.
24.
33.
35.
Możliwość zbiorczej modyfikacji pozycji rozliczeniowych w
zakresie zmian dotyczących:
36.
37.
38.
39.
- numeru umowy,
- zakresu świadczeń,
- wyróżnika,
- świadczenia jednostkowego.
Możliwość wprowadzenia dodatkowego poziomu kontroli
40. wprowadzonych świadczeń poprzez funkcjonalność
autoryzacji świadczeń przez osobę uprawnioną.
41.
Po otrzymaniu informacji z NFZ, uprawniony użytkownik
działu rozliczeń musi mieć możliwość modyfikacji danych.
36
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Sprawozdawczość z do oddziałów NFZ w zakresie
42. komunikacji przez pocztę elektroniczną musi odbywać się
automatycznie, z poziomu Oprogramowania.
W przypadku komunikatów, w których NFZ wymaga
43. kompresowania lub szyfrowania danych, operacje te muszą
odbywać się automatycznie w Oprogramowaniu.
System musi umożliwić harmonogramowanie eksportów
44. danych: o wyznaczonej godzinie, co określoną liczbę godzin,
za określoną liczbę godzin.
45.
46.
47.
48.
49.
50.
Weryfikacja świadczeń pod kątem poprawności i
kompletności wprowadzonych danych.
Wyszukiwanie pozycji błędnie potwierdzonych w
komunikatach zwrotnych NFZ.
Wyszukiwanie po numerach w księgach .
Wyszukiwanie zestawów bez zaewidencjonowanych
procedur ICD9.
Wyszukiwanie zestawów po numerze paczki, w której
wyeksportowano dane do NFZ.
Wyszukiwanie po instytucji kierującej .
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
51. Wyszukiwanie po personelu kierującym/ realizującym.
52. Wyszukiwanie zestawów bez pozycji rozliczeniowych.
Wyszukiwanie zestawów z niekompletnymi danymi
53.
rozliczeniowymi.
Wyszukiwanie pozycji rozliczeniowych, które nie zostały
54.
jeszcze rozliczone.
Tak
Tak
55. Wyszukiwanie po statusie rozliczenia.
Wyszukiwanie zestawów zawierających rozliczenia ze
56.
wskazanej umowy.
Tak
57.
Wyszukiwanie zestawów zawierających wskazane
świadczenie jednostkowe.
Wyszukiwanie zestawów świadczeń z JGP wyznaczoną w
58. zadanej wersji - wyszukania świadczeń z wyznaczonymi
grupami JGP wg. konkretnej wersji grupera.
Wyszukiwanie zestawów świadczeń ratujących życie i
zdrowie.
Wyszukiwanie zestawów świadczeń zrealizowanych dla
60.
wybranych uprawnień pacjenta.
Wyszukiwanie świadczeń, które zostały skorygowane, a
61.
informacja o skorygowaniu nie została sprawozdana do
59.
37
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
systemu NFZ.
Generowanie i eksport komunikatu fazy I (komunikat SWIAD)
w aktualnie obowiązującej wersji publikowanej przez płatnika.
Import potwierdzeń do danych przekazanych w komunikacie I
63.
fazy (komunikat P_SWI).
Import danych z pliku z szablonami rachunków (komunikat
64.
R_UMX).
62.
Tak
Tak
Tak
65.
Eksport komunikatów związanych ze sprawozdawczością
POZ:
Tak
66.
- eksport komunikatu DEKL – informacje o deklaracjach,
Tak
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
- eksport komunikatu ZBPOZ – informacje o świadczeniach
zrealizowanych w ramach POZ.
Import potwierdzeń związanych ze sprawozdawczością POZ:
- import komunikatu P_DEK – potwierdzenia danych dla
przesłanych deklaracji,
- import komunikatu Z_WDP – wyniki weryfikacji deklaracji,
- import komunikatu Z_RDP – rozliczenia deklaracji.
Eksport komunikatów związanych ze sprawozdawczością
kolejek oczekujących:
- eksport komunikatu LIOCZ – informacje o statystykach
kolejek oczekujących,
- eksport komunikatu KOL – informacje o oczekujących na
świadczenia wysokospecjalistyczne.
Import potwierdzeń związanych ze sprawozdawczością
kolejek oczekujących.
Import komunikatu P_LIO – potwierdzenie statystyk
przekazanych w komunikacie LIOCZ.
Przegląd szablonów rachunków wygenerowanych i
przekazanych przez płatnika.
78. Generowanie i wydruk rachunków na podstawie szablonów.
79. Generowanie i wydruk faktur na podstawie rachunków.
Generowanie i wydruk zestawień i raportów związanych ze
sprawozdawczością wewnętrzną (możliwość śledzenia
80.
postępów wykonania zakontraktowanych świadczeń w ciągu
trwania okresu rozliczeniowego).
Raport z wykonanych świadczeń z możliwością ograniczenia
81.
danych do m.in.:
82. - numeru umowy,
38
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
83.
- zakresu miesięcy sprawozdawczych,
Tak
84.
85.
- miesiąca rozliczeniowego,
- jednostki realizującej,
Tak
Tak
86.
87.
- zakresu świadczeń i wyróżnika,
- świadczenia,
Tak
Tak
88.
89.
- numeru szablonu,
- uprawnienia pacjenta do świadczeń.
Tak
Tak
90. Zestawienie z realizacja planu umowy.
91. Zestawienie wykonań w okresie.
Tak
Tak
92. Zestawienie wykonań przyrostowo.
93. Zestawienie wykonań według miejsc realizacji.
Tak
Tak
94. Sprawozdanie rzeczowe.
Eksport danych do popularnych formatów (XLS, TXT, CSV,
95.
HTML).
Generowanie i wydruk dokumentów związanych ze
96.
sprawozdawczością wymaganą przez OW NFZ.
97. Sprawozdanie finansowe.
Zestawienie świadczeń udzielonych świadczeniobiorcom
98.
innym niż ubezpieczeni.
Zestawienie świadczeń wykonanych pacjentom na podstawie
99.
przepisów o koordynacji (UE).
Zestawienie świadczeń wykonanych pacjentom na podstawie
100.
art. 2 ust. 1 ustawy (decyzja wójta/burmistrza).
Zestawienie świadczeń wykonanych pacjentom
101. nieubezpieczonym, rozliczanym na podstawie art. 12 lub art.
13 ustawy.
Tak
102. Załącznik nr 4 do umowy – chemioterapia.
103. Załącznik nr 4 do umowy – programy terapeutyczne.
Tak
Tak
104. Załączniki do umów POZ.
105. Ewidencja faktur zakupowych.
Tak
Tak
106. Import słownika produktów handlowych (komunikat PRH).
107. Możliwość przekodowania produktów handlowych na leki.
Tak
Tak
108. Ewidencja faktur zakupowych.
Generowanie i eksport faktur zakupowych do NFZ w
109.
aktualnym formacie komunikatu FZX.
110. Import potwierdzeń do faktur zakupowych (komunikat FZZ).
Generowanie i wydruk załącznika nr 4 do umowy – ewidencja
111.
faktur zakupowych.
112. Obsługa sprawozdawczości w zakresie POZ.
Tak
39
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Tak
Integracja z innymi modułami Oprogramowania
113. Zamawiającego dostarczanymi przez Oferenta w ramach
niniejszego postępowania:
- ewidencja pozycji rozliczeniowych w „Ruch Chorych” oraz
114.
„Przychodni Specjalistycznej”,
- ewidencja faktur zakupowych za leki w chemioterapii w
115.
module „Apteka Szpitalna”,
- eksport faktur rozliczeniowych do centralnego modułu
116.
„Finanse-Księgowość”,
117.
- przekazywanie danych o hospitalizacji do narzędzia
umożliwiającego symulację JGP w Oprogramowaniu.
40
Tak
Tak
Tak
Tak
Tak
Apteka szpitalna
Lp.
1.
2.
3.
4.
5.
6.
7.
8.
9.
Wymaganie (Apteka Szpitalna)
Moduł musi działać w architekturze trójwarstwowej.
Interfejs użytkownika modułu musi być dostępny z poziomu
przeglądarki internetowej i nie może wymagać instalowania
żadnego dodatkowego oprogramowania na stacjach
klienckich (system nie może wymagać korzystania ze
specjalnych programów klienckich technologii typu Citrix,
VNC, innych, w celu realizacji wymagań funkcjonalnych).
Moduł musi umożliwiać pracę z poziomu najbardziej
popularnych przeglądarek, co najmniej Microsoft Internet
Explorer, Google Chrome, Mozilla Firefox, Opera.
Moduł musi umożliwiać pracę na tabletach lub komputerach
wyposażonych w monitory dotykowe. Pełna funkcjonalność
modułu musi być dostępna na komputerach tego typu.
Moduł musi umożliwiać wykonanie nowej operacji w systemie
bez konieczności przerywania czynności dotychczas
wykonywanej (np. obsługa zdarzenie w trybie nagłym) i
powrót do zawieszonej czynności bez utraty danych,
kontekstu itp.
Wszystkie błędy niewypełnienia pól obligatoryjnych oraz
błędnego wypełnienia muszą być prezentowane w jednym
komunikacie, z możliwością szybkiego przejścia do tego
miejsca aplikacji (np. poprzez odpowiedni link), gdzie te błędy
wystąpiły.
Wyróżnienie pól:
- których wypełnienie jest wymagane,
- przeznaczonych do edycji,
10. - wypełnionych niepoprawnie.
11. Obsługa magazynu leków apteki szpitalnej.
12. Konfiguracja magazynu apteki:
- możliwość wykorzystania słowników: leków, grup ATC,
13.
nazw międzynarodowych,
- możliwość definiowania własnych grup leków (globalnych i
14.
lokalnych),
- możliwość tworzenia lokalnych słowników leków dla
15.
magazynów,
41
Wymagane Oferowane
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
16.
- możliwość definiowania własnych dokumentów (np.
Rozchód Darów, Przyjęcie bezpłatnych próbek itp.),
TAK
17.
- możliwość automatycznego numerowania dokumentów wg
definiowanego wzorca.
TAK
18.
19.
20.
21.
22.
23.
24.
25.
Sporządzanie zamówień doraźnych do dostawców środków
farmaceutycznych i materiałów medycznych. Zamówienia
mogą być przygotowywane automatycznie, na podstawie
aktualnych stanów magazynowych, stanów minimalnych i
maksymalnych.
Dostawa środków farmaceutycznych i materiałów
medycznych do apteki:
- dostawa od dostawców, z możliwością wprowadzania ich
drogą elektroniczną (możliwość rejestrowania również dostaw
nie fakturowanych),
- sporządzanie preparatów laboratoryjnych, preparatów
galenowych, leków recepturowych oraz płynów infuzyjnych,
- sporządzanie roztworów spirytusowych,
- import docelowy zakładowy i indywidualny,
- zwrot z oddziałów z automatyczną aktualizacją stanów
apteczki oddziałowej,
- dary,
- korekta dokumentów ewidencjonujących dostawy środków
farmaceutycznych i materiałów medycznych.
27. Wydawanie środków farmaceutycznych z apteki:
26.
28.
29.
30.
31.
32.
33.
34.
35.
36.
- wydawanie na oddziały za pomocą dokumentów RW lub
MM na podstawie zamówień elektronicznych lub papierowych
(współpraca z modułem Apteczka oddziałowa
funkcjonującym w Zamawiającego),
- możliwość elektronicznego potwierdzenia realizacji
zamówienia z oddziału Oprogramowania Zamawiającego:
- wydawanie na zewnątrz,
- zwrot do dostawców,
- ubytki i straty nadzwyczajne,
- korekta wydań środków farmaceutycznych.
Korekta stanów magazynowych:
- korekta stanów magazynowych (ilościowa i jakościowa) na
podstawie arkusza spisu z natury z dokładnością do dostawy
lub asortymentu,
- generowanie arkusza do spisu z natury,
42
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
37.
- bieżąca korekta jakościowa stanu magazynowego,
38.
- odnotowanie wstrzymania lub wycofania leku z obrotu,
- kontrola dat ważności oraz możliwość automatycznego
39. zdejmowania ze stanów magazynowych leków
przeterminowanych.
Przegląd stanów magazynowych bieżących oraz na wybrany
40.
dzień.
41. Wspieranie obsługi i kontroli zamówień (w tym publicznych)
- kontrola realizacji dostaw i poziomu cen w ramach
zwycięskiej oferty (umowy).
43. Raporty i zestawienia:
42.
44.
45.
46.
47.
TAK
TAK
TAK
TAK
TAK
TAK
TAK
- na podstawie rozchodów,
- na podstawie przychodów,
- na podstawie obrotów,
- możliwość eksportu do pliku XLS.
Możliwość przekazywania wszystkich wydruków do plików w
48.
formacie PDF.
49. Wspomaganie decyzji farmakoterapeutycznych:
50. - przechowywanie informacji o leku,
TAK
TAK
TAK
TAK
51. - mechanizm „stop-order”,
52. - odnotowywanie działań niepożądanych.
53. Możliwość definiowania receptariusza szpitalnego.
Integracja z innymi modułami Oprogramowania
54.
Zamawiającego, realizującymi funkcjonalność w zakresie:
a) Finanse – Księgowość – wymagana integracja z
55.
centralnym oprogramowaniem FK,
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
56.
- dostępność funkcji wartościowego, syntetycznego zapisu
obrotu materiałowego na kontach księgi głównej FK,
TAK
57.
- możliwość zapisu dokumentów rozchodowych (koszty) na
poziomie wydania z magazynu apteki,
TAK
- możliwość zapisu dokumentów rozchodowych (koszty) na
poziomie wydania z magazynu apteczki oddziałowej,
- możliwość elastycznego tworzenia wzorców eksportu do
59.
FK,
- możliwość wykorzystania słowników systemu FK:
60. kontrahentów, rodzajów kosztów, ośrodków powstawania
kosztów;
61. b) Rachunek kosztów leczenia:
58.
43
TAK
TAK
TAK
TAK
- w zakresie udostępnienia indeksu leków i danych o
62. aktualnych cenach leków do określenia normatywów
materiałowych świadczeń (w zakresie leków);
63. c) Ruch Chorych, Przychodnia:
64.
- w zakresie głównego skorowidza pacjentów
Oprogramowania Zamawiającego.
TAK
TAK
TAK
Apteczka oddziałowa
Lp.
1.
2.
3.
Wymaganie (Apteczka oddziałowa)
Moduł musi działać w architekturze trójwarstwowej.
Interfejs użytkownika modułu musi być dostępny z poziomu
przeglądarki internetowej i nie może wymagać instalowania
żadnego dodatkowego oprogramowaniach na stacjach
klienckich (system nie może wymagać korzystania ze
specjalnych programów klienckich technologii typu Citrix,
VNC, innych, w celu realizacji wymagań funkcjonalnych).
Moduł musi umożliwiać pracę z poziomu najbardziej
popularnych przeglądarek, co najmniej Microsoft Internet
Explorer, Google Chrome, Mozilla Firefox, Opera.
Moduł musi umożliwiać pracę na tabletach medycznych lub
komputerach wyposażonych w monitory dotykowe. Pełna
4.
funkcjonalność modułu musi być dostępna także na
komputerach tego typu.
Moduł musi umożliwiać wykonanie nowej operacji w systemie
bez konieczności przerywania czynności dotychczas
5. wykonywanej (np. obsługa zdarzenie w trybie nagłym) i
powrót do zawieszonej czynności bez utraty danych,
kontekstu itp.
Wszystkie błędy niewypełnienia pól obligatoryjnych oraz
błędnego wypełnienia muszą być prezentowane w jednym
6. komunikacie, z możliwością szybkiego przejścia do tego
miejsca aplikacji (np. poprzez odpowiedni link), gdzie te błędy
wystąpiły.
7. Wyróżnienie pól:
8. - których wypełnienie jest wymagane,
9. - przeznaczonych do edycji,
10. - wypełnionych niepoprawnie.
11. Generowanie elektronicznych zamówień do apteki głównej.
12. Obsługa magazynu apteczki oddziałowej:
44
Wymagane Oferowane
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
13.
14.
15.
16.
17.
18.
19.
a) wydawanie środków farmaceutycznych z apteczki
oddziałowej:
- wydawanie na oddział/pacjenta - współpraca z modułami
„Ruch Chorych” oraz modułami systemu „Przychodnia
Specjalistyczna”,
- zwrot do apteki,
- ubytki i straty nadzwyczajne,
- korekta wydań środków farmaceutycznych;
b) korekta stanów magazynowych:
- korekta stanów magazynowych (ilościowa i jakościowa) na
podstawie arkusza spisu z natury,
20. - generowanie arkusza do spisu z natury,
21. - bieżąca korekta jakościowa stanu magazynowego.
22. Możliwość definiowania receptariusza oddziałowego.
23. Możliwość obsługi apteczek własnych pacjentów.
45
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
Zlecenia medyczne
Lp.
Wymaganie (Zlecenia medyczne)
1.
Moduł musi działać w architekturze trójwarstwowej.
Interfejs użytkownika modułu musi być dostępny z poziomu
przeglądarki internetowej i nie może wymagać instalowania
żadnego dodatkowego oprogramowania na stacjach
klienckich (system nie może wymagać korzystania ze
specjalnych programów klienckich technologii typu Citrix,
VNC, innych, w celu realizacji wymagań funkcjonalnych).
Moduł musi umożliwiać pracę z poziomu najbardziej
popularnych przeglądarek, co najmniej Microsoft Internet
Explorer, Google Chrome, Mozilla Firefox, Opera.
Moduł musi umożliwiać pracę na tabletach medycznych lub
komputerach wyposażonych w monitory dotykowe. Pełna
funkcjonalność modułu musi być dostępna na komputerach
tego typu.
Moduł musi umożliwiać wykonanie nowej operacji w systemie
bez konieczności przerywania czynności dotychczas
wykonywanej (np. obsługa zdarzenie w trybie nagłym) i
powrót do zawieszonej czynności bez utraty danych,
kontekstu itp.
Wszystkie błędy niewypełnienia pól obligatoryjnych oraz
błędnego wypełnienia muszą być prezentowane w jednym
komunikacie, z możliwością szybkiego przejścia do tego
miejsca aplikacji (np. poprzez odpowiedni link), gdzie te błędy
wystąpiły.
TAK
Wyróżnienie pól:
- których wypełnienie jest wymagane,
TAK
TAK
2.
3.
4.
5.
6.
7.
8.
9. - przeznaczonych do edycji,
10. - wypełnionych niepoprawnie.
TAK
TAK
TAK
TAK
TAK
TAK
TAK
Planowanie i zlecanie leków w powiązaniu z modułem
„Apteczka Oddziałowa”.
Planowanie i zlecanie badań diagnostycznych i
12. laboratoryjnych, zabiegów, konsultacji przekazywanych z
jednostek Zamawiającego, w tym:
11.
13.
Wymagane Oferowane
- z Izby Przyjęć (IP) oraz Oddziału do Pracowni
Diagnostycznej dostarczanej przez Oferenta w niniejszym
46
TAK
TAK
TAK
postępowaniu,
- z Izby Przyjęć (IP) oraz Oddziału do Przychodni
14. Specjalistycznej dostarczanej przez Oferenta w niniejszym
postępowaniu,
- z Izby Przyjęć (IP) oraz Oddziału do Bloku Operacyjnego
15.
dostarczanego przez Oferenta w niniejszym postępowaniu,
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
- z Izby Przyjęć (IP) oraz Oddziału do innego Oddziału w
ramach Oprogramowania Zamawiającego,
- z Izby Przyjęć (IP) oraz Oddziału do Pracowni
Patomorfologii dostarczanej przez Oferenta w niniejszym
postępowaniu,
- z Izby Przyjęć (IP) oraz Oddziału do modułu Bank Krwi,
dostarczanego przez Oferenta w niniejszym postępowaniu,
- z Izby Przyjęć (IP) oraz Oddziału do systemu laboratorium
firmy Diagnostyka poprzez protokół HL7;
- z Izby Przyjęć (IP) oraz Oddziału do centralnego systemu
PACS.
Zlecanie wielu różnych badań w jednym miejscu, opatrzonych
wspólnym nagłówkiem i komentarzem.
Planowanie i zlecanie badań i konsultacji w ramach zleceń
zewnętrznych (z innych podmiotów).
Indywidualna karta zleceń podań leków.
Możliwość definiowania zleceń złożonych:
- kompleksowych,
26. - panelowych,
27. - cyklicznych.
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
Możliwość dwuetapowego wprowadzania zlecenia (wpisanie
oraz potwierdzenia).
Przegląd zleceń według ustalonych przez użytkownika
29.
kryteriów:
30. - dla pacjenta,
28.
TAK
TAK
TAK
31. - typu zlecenia (laboratoryjne, diagnostyczne, podanie leku),
32. - okresu.
TAK
TAK
33. Wydruki zleceń, w tym:
34. - dzienne zestawienie leków dla pacjenta,
TAK
TAK
35. - dzienne zestawienie badań do wykonania.
Możliwość wydruku wszystkich wyników pacjenta z bieżącej
36.
hospitalizacji lub ze wszystkich pobytów w szpitalu.
TAK
47
TAK
Przegląd wszystkich zleceń z jednostki zlecającej z
możliwością wydruku wyniku.
Możliwość definiowania szablonów dokumentów
38.
skojarzonych z wprowadzanym zleceniem.
37.
TAK
TAK
Możliwość przeglądania wyników liczbowych w postaci
graficznej (badanie trendu).
TAK
Podgląd zleconych badań i ich wyników w innej komórce
40. obsługującej danego pacjenta – zapobieżenie dublowaniu
zleceń badań.
TAK
39.
48
Punkty pobrań
Lp.
Wymaganie (Punkty pobrań)
1.
Moduł musi działać w architekturze trójwarstwowej.
Interfejs użytkownika modułu musi być dostępny z poziomu
przeglądarki internetowej i nie może wymagać instalowania
żadnego dodatkowego oprogramowaniach na stacjach
klienckich (system nie może wymagać korzystania ze
specjalnych programów klienckich technologii typu Citrix,
VNC, innych, w celu realizacji wymagań funkcjonalnych).
Moduł musi umożliwiać pracę z poziomu najbardziej
popularnych przeglądarek, co najmniej Microsoft Internet
Explorer, Google Chrome, Mozilla Firefox, Opera.
Moduł musi umożliwiać pracę na tabletach medycznych lub
komputerach wyposażonych w monitory dotykowe. Pełna
funkcjonalność modułu musi być dostępna na komputerach
tego typu.
Moduł musi umożliwiać wykonanie nowej operacji w systemie
bez konieczności przerywania czynności dotychczas
wykonywanej (np. obsługa zdarzenie w trybie nagłym) i
powrót do zawieszonej czynności bez utraty danych,
kontekstu itp.
Wszystkie błędy niewypełnienia pól obligatoryjnych oraz
błędnego wypełnienia muszą być prezentowane w jednym
komunikacie, z możliwością szybkiego przejścia do tego
miejsca aplikacji(np. poprzez odpowiedni link), gdzie te błędy
wystąpiły.
TAK
Wyróżnienie pól:
- których wypełnienie jest wymagane,
TAK
TAK
2.
3.
4.
5.
6.
7.
8.
Wymagane Oferowane
TAK
TAK
TAK
TAK
TAK
9. - przeznaczonych do edycji,
10. - wypełnionych niepoprawnie.
TAK
TAK
11. Zarządzanie zleceniami na badania laboratoryjne:
- przyjmowanie zleceń badań laboratoryjnych z obszaru
Oprogramowania z możliwością określenia domyślnego
punktu pobrań dla zleceniodawcy - wymagana jest integracja
12.
z modułami „Izba Przyjęć”, „Oddział” „Przychodnia
Specjalistyczna”, „Pracownia Diagnostyczna”, „Blok
Operacyjny”, i innymi, opisanym w niniejszej specyfikacji,
TAK
49
TAK
13. - wprowadzanie zleceń zewnętrznych,
- możliwość wyszukiwania zleceń wg imienia i nazwiska,
14.
daty zlecenia oraz planowanej daty wykonania,
15. - dostęp do zleceń archiwalnych pacjenta,
TAK
16. - wyróżnianie zleceń CITO,
- automatyczne dobieranie materiałów niezbędnych do
17.
realizacji zlecenia.
18. Obsługa punktu przyjęcia i rozdzielni materiału:
TAK
- wspomaganie rozdziału materiałów wg jednostek
wykonujących,
20. - rejestracja wysłania materiałów do laboratoriów,
19.
TAK
TAK
TAK
TAK
TAK
TAK
- oznakowanie pobieranych materiałów kodem kreskowym.
Rejestracja w systemie pobranych materiałów:
- automatyczne odnotowanie daty i godziny pobrania,
- odnotowanie osoby pobierającej materiał,
- odnotowanie dodatkowych uwag do pobrania,
- dla wybranych badań (np. oznaczenie grupy krwi)
26. konieczność potwierdzenia danych pobrania (data i godzina,
osoba, uwagi).
TAK
TAK
TAK
TAK
TAK
27. Obsługa i wydruk Księgi Pobrań.
Przekazywanie elektronicznego potwierdzenia pobrania
28. materiału do zleceniodawców Oprogramowania
Zamawiającego oraz do centralnego „Laboratorium”.
TAK
21.
22.
23.
24.
25.
50
TAK
TAK
Bank krwi
Lp.
1.
2.
3.
4.
5.
Wymaganie (Bank krwi)
Możliwość przyjęcia krwi lub preparatu krwiopochodnego na
magazyn z wykorzystaniem czytnika kodów kreskowych.
Przegląd stanów magazynowych.
Obsługa zamówień indywidualnych na krew lub preparat
krwiopochodny z jednostek zamawiających – wymagana
integracja z modułami medycznymi Oprogramowania
funkcjonującymi w Zamawiającego – moduły: „Izba Przyjęć”,
„Oddział”, oraz dostarczanymi w niniejszym postępowaniu, w
tym przede wszystkim „Zlecenia medyczne”, „Laboratorium
szpitalne – serologia”.
Obsługa „cito’wych” zamówień z jednostek zamawiających –
wymagana integracja z modułami medycznymi
funkcjonującymi w Zamawiającego – moduły: „Izba Przyjęć”,
„Oddział”, oraz dostarczanymi w niniejszym postępowaniu, w
tym przede wszystkim „Zlecenia medyczne”.
Sporządzanie zamówień do stacji krwiodawstwa.
Wymagane Oferowane
TAK
TAK
TAK
TAK
TAK
8.
Możliwość dopisania pozycji do zamówienia do stacji
krwiodawstwa w trakcie realizacji zamówienia
indywidualnego.
Możliwość rezerwacji krwi lub preparatu krwiopochodnego
dla zamówienia indywidualnego przekazanego drogą
elektroniczną z innych modułów Oprogramowania.
Obsługa dokumentów magazynowych:
9.
10.
- bilans otwarcia,
- przychód,
TAK
TAK
11.
12.
- rozchód,
- kasacja,
TAK
TAK
6.
7.
13.
TAK
TAK
TAK
- zwrot do dostawcy.
Przegląd wyników badań serologicznych zarejestrowanych w
14. wynikach badań laboratoryjnych pacjenta - wymagana
integracja z modułem centralnego „Laboratorium”.
15. Przegląd zamówień indywidualnych dla pacjentów.
TAK
16. Raporty i zestawienia:
17. - dla zużycia preparatów,
18. - dla obrotów,
TAK
TAK
TAK
51
TAK
TAK
19.
- dla stanów magazynowych.
TAK
20. Księga przychodów i rozchodów.
21. Konfiguracja ustawień:
TAK
TAK
- możliwość definiowania słownika magazynów,
- możliwość przeglądu i edycji słownika odbiorców:
indywidualnego lub „centralnego” słownika odbiorców
23.
Zamawiającego, zdefiniowanego w centralnym module
„Finanse-Księgowość”,
TAK
22.
TAK
24.
25.
- możliwość definiowania słownika preparatów,
- możliwość definiowanie słownika rodzaju preparatu,
TAK
TAK
26.
27.
- możliwość definiowanie słownika jednostek miar,
- możliwość definiowania słownika rodzaju dokumentów,
TAK
TAK
28.
29.
30.
31.
32.
33.
- możliwość definiowania indywidualnego słownika
kontrahentów lub słownika kontrahentów Zamawiającego,
zdefiniowanego w centralnym module „FinanseKsięgowość”,
- możliwość definiowania cenników.
Współpraca z modułem „Oddział” Zamawiającego w
zakresie:
- zamówień indywidualnych na krew i preparaty
krwiopochodne,
- przetoczeń,
Przegląd I wydruk księgi transfuzji.
52
TAK
TAK
TAK
TAK
TAK
TAK
Pracownia Diagnostyczna
Lp.
1.
2.
3.
4.
5.
6.
7.
8.
Wymaganie (Pracownia diagnostyczna)
Moduł musi działać w architekturze trójwarstwowej.
Interfejs użytkownika modułu musi być dostępny z poziomu
przeglądarki internetowej i nie może wymagać instalowania
żadnego dodatkowego oprogramowaniach na stacjach
klienckich (system nie może wymagać korzystania ze
specjalnych programów klienckich technologii typu Citrix,
VNC, innych, w celu realizacji wymagań funkcjonalnych).
Moduł musi umożliwiać pracę z poziomu najbardziej
popularnych przeglądarek, co najmniej Microsoft Internet
Explorer, Google Chrome, Mozilla Firefox, Opera.
Moduł musi umożliwiać pracę na tabletach medycznych lub
komputerach wyposażonych w monitory dotykowe. Pełna
funkcjonalność modułu musi być dostępna na komputerach
tego typu.
Moduł musi umożliwiać wykonanie nowej operacji w
systemie bez konieczności przerywania czynności
dotychczas wykonywanej (np. obsługa zdarzenie w trybie
nagłym) i powrót do zawieszonej czynności bez utraty
danych, kontekstu itp.
Wszystkie błędy niewypełnienia pól obligatoryjnych oraz
błędnego wypełnienia muszą być prezentowane w jednym
komunikacie, z możliwością szybkiego przejścia do tego
miejsca aplikacji(np. poprzez odpowiedni link), gdzie te błędy
wystąpiły.
Wyróżnienie pól:
- których wypełnienie jest wymagane,
9. - przeznaczonych do edycji,
10. - wypełnionych niepoprawnie.
Dostęp do listy pacjentów zarejestrowanych do pracowni –
wymagana jest integracja ze skorowidzem pacjentów
11. Oprogramowania Zamawiającego – z dostarczanym
podsystem „Ruch Chorych” – moduły „Izba Przyjęć”,
„Oddział”.
Rejestracja rozpoczęcia obsługi wizyty pacjenta w pracowni
12.
(przyjęcie) wraz z wyborem urządzenia.
53
Wymagane Oferowane
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
13. Wspomaganie obsługi pacjenta w pracowni:
TAK
14. przegląd danych pacjenta w następujących kategoriach:
15. - dane osobowe,
TAK
TAK
- podstawowe dane medyczne (grupa krwi, uczulenia, stale
podawane leki, przebyte choroby, karta szczepień),
17. - uprawnienia z tytułu umów,
18. - Historia Choroby (dane ze wszystkich wizyt pacjenta) ,
19. - wyniki badań,
16.
TAK
TAK
TAK
TAK
- przegląd rezerwacji.
Możliwość zdefiniowania elementów menu (zakładek) w
zależności od potrzeb i rodzaju pracowni.
Możliwość zdefiniowania wzorów dokumentów
dedykowanych dla danej pracowni.
Możliwość użytkowania zdefiniowanych wcześniej wzorców
dokumentacji dedykowanej do wizyty.
Przegląd, wprowadzanie i modyfikacja danych wizyty w
następujących kategoriach:
- informacje ze skierowania,
- skierowania, zlecenia,
TAK
- usługi, świadczenia w ramach wizyty,
- wystawione skierowania,
- wykonane podczas wizyty procedury drobne (nie będące
29.
usługami),
TAK
TAK
20.
21.
22.
23.
24.
25.
26.
27.
28.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
- inne dokumenty (zaświadczenia, druki, na formularzach
zdefiniowanych dla wizyty).
Możliwość stosowania słownika tekstów standardowych do
opis danych wizyt.
Możliwość stosowania „pozycji preferowanych” dla
użytkowników, jednostek organizacyjnych (wyróżnienie
najczęściej wykorzystywanych pozycji słowników).
Możliwość ewidencji wykonania usług rozliczanych
komercyjnie:
- obsługa stanowiska kasowego (jak w Rejestracji/Recepcji).
Obsługa zakończenia badania/wizyty:
- autoryzacja medyczna badania,
- automatyczne tworzenie karty wizyty/wyniku badania.
Kwalifikacja rozliczeniowa usług i świadczeń.
Wgląd w rozliczenia z NFZ z tytułu zrealizowanych w trakcie
wizyty usług - wymagana jest integracja z systemem
54
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
rozliczeniowym z Narodowym Funduszem Zdrowia - moduł
„Rozliczenia z NFZ” Zintegrowanego Szpitalnego Systemu
Informacyjnego Zamawiającego.
40. Automatyczna generacja i przegląd Księgi Pracowni.
TAK
41. Obsługa wyników badań:
42. - wprowadzanie opisów wyników badań diagnostycznych,
TAK
TAK
- wprowadzanie opisów wyników badań na definiowalnych
43. formularzach wyników dostosowanych do rodzaju
wykonywanego badania,
TAK
- autoryzacja wyników badań diagnostycznych,
- wydruk wyniku wg wzoru, jakim posługuje się pracownia.
TAK
TAK
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
System musi umożliwiać powtórny wydruk dokumentu już
wydrukowanego.
Raporty i wykazy dla danej Pracowni.
Automatyczne generowanie Księgi Pracowni.
Brak możliwości wydruku wyników bez zapisania informacji
w systemie (po zapisaniu, badanie można tylko oznaczyć
jako skasowane). Możliwość wykonywania zestawień
zbiorczych i szczegółowych, uwzględniających badania
zlecane, wprowadzane do systemu w trybie pilnym oraz
skasowane.
Możliwość zapisu czasu wykonania badania, celem
wyliczenia jego długości.
Ujednolicenie słownika badań z urządzeniami
radiologicznymi.
Przesyłanie informacji o zarejestrowanych pacjentach
protokołem HL7 do systemu PACS firmy Agfa IMPAX
będącego w posiadaniu Zamawiającego. Informacje mają
być podstawą do generowania worklist.
Przesyłanie aktualizacji o np. zmianie danych pacjenta, typie
badania, oddziału, lekarza zlecającego, daty i godziny
badania itp. do systemu IMPAX.
Przyjmowanie z systemu IMPAX informacji o rozpoczęciu i
zakończeniu badania oraz jego ID.
Możliwość opisywania i wydruku opisów badań
radiologicznych bezpośrednio z systemu.
Możliwość przypisania do loginu lekarza odpowiedniej nazwy
jednostki opisującej widocznej na wydruku.
57. Możliwość otwierania bezpośrednio z modułu z formularza
56.
55
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
do opisywania badań przeglądarki Agfa IMPAX z otwartym
odpowiednim badaniem.
Przesyłanie do systemu IMPAX informacji o zakończeniu
58.
opisywania badania oraz o zatwierdzeniu opisu.
Możliwość otwarcia przez lekarza klinicystę z poziomu
przeglądania wynikó pacjenta zarówno opisu wykonanego w
59.
module RIS (Pracownia Diagnostyczna), jak i przeglądarki
Agfa XERO z otwartym odpowiednim badaniem.
Możliwość udostępnienia do Agfa Xero linku do opisu
60. badaniu i/lub przesyłania treści samego opisu do systemu
IMPAX celem wyświetlenia w przeglądarce Agfa XERO.
Koszty integracji po stronie Agfa poniesie Zamawiający,
Zamawiający jest w posiadaniu dokumentacji do ww.
61.
integracji i ma możliwość jej udostępnienia na żądanie (nie
jest to informacja publiczna).
56
TAK
TAK
TAK
TAK
Blok operacyjny
Lp.
1.
2.
3.
4.
5.
6.
7.
8.
9.
Wymaganie (Blok operacyjny)
Moduł musi działać w architekturze trójwarstwowej.
Interfejs użytkownika modułu musi być dostępny z poziomu
przeglądarki internetowej i nie może wymagać instalowania
żadnego dodatkowego oprogramowaniach na stacjach
klienckich (system nie może wymagać korzystania ze
specjalnych programów klienckich technologii typu Citrix, VNC,
innych, w celu realizacji wymagań funkcjonalnych).
Moduł musi umożliwiać pracę z poziomu najbardziej
popularnych przeglądarek, co najmniej Microsoft Internet
Explorer, Google Chrome, Mozilla Firefox, Opera.
Moduł musi umożliwiać pracę na tabletach medycznych lub
komputerach wyposażonych w monitory dotykowe. Pełna
funkcjonalność modułu musi być dostępna na komputerach
tego typu.
Moduł musi umożliwiać wykonanie nowej operacji w systemie
bez konieczności przerywania czynności dotychczas
wykonywanej (np. obsługa zdarzenie w trybie nagłym) i powrót
do zawieszonej czynności bez utraty danych, kontekstu itp.
Wszystkie błędy niewypełnienia pól obligatoryjnych oraz
błędnego wypełnienia muszą być prezentowane w jednym
komunikacie, z możliwością szybkiego przejścia do tego
miejsca aplikacji(np. poprzez odpowiedni link), gdzie te błędy
wystąpiły.
Wyróżnienie pól:
- których wypełnienie jest wymagane,
- przeznaczonych do edycji,
10. - wypełnionych niepoprawnie.
System musi umożliwiać dokonanie klasyfikacji lekarskiej
11.
(chirurgicznej) do zabiegu obejmującej, co najmniej:
12. - rodzaj planowanego zabiegu,
- tryb zabiegu (planowany, przyspieszony, pilny,
13.
natychmiastowy),
14. - rozpoznanie przedoperacyjne ICD9 oraz opisowe,
- dostęp do pola operacyjnego z wykorzystaniem
15.
definiowalnego słownika,
57
Wymaga
ne
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
Oferowa
ne
16.
- wymagane ułożenie pacjenta z wykorzystaniem
definiowalnego słownika, z możliwością wyboru wielu pozycji ,
- datę kwalifikacji,
- wskazanie, ze słownika personelu, lekarza dokonujący
18.
kwalifikacji,
- możliwość załączenia formularza definiowanego przez
19.
użytkownika,
Musi istnieć możliwość rejestracji danych kwalifikacji z poziomu
20.
oddziału i z poziomu bloku operacyjnego
17.
21.
22.
23.
24.
25.
26.
27.
Musi istnieć możliwość uproszczonego zlecania zabiegów
przeprowadzanych w trybie nagłym
System musi umożliwiać dokonanie klasyfikacji
anestezjologicznej, co najmniej w zakresie odnotowania:
- rodzaju planowanego znieczulenia z wykorzystaniem
słownika rodzajów znieczulenia z możliwością definiowania
własnych rodzajów znieczulenia,
- klasyfikacji pacjenta wg skali ASA,
- opisu kwalifikacji,
- daty kwalifikacji,
- wskazania lekarza dokonującego kwalifikacji,
- możliwości rejestracji danych kwalifikacji z poziomu oddziału i
z poziomu bloku operacyjnego
System musi umożliwić planowanie zabiegu operacyjnego w
29.
tym wpisanie:
30. - daty zabiegu, bloku operacyjnego i sali operacyjnej,
28.
31.
32.
33.
34.
35.
36.
37.
38.
- materiałów,
- zamówienia preparatów krwi wymaganych do
przeprowadzenia zabiegu z możliwością wydrukowania
zamówienia do banku krwi,
- składu zespołu zabiegowego i anestezjologicznego z
wykorzystaniem słownika personelu z możliwością określenia
definiowania roli członków personelu,
- możliwość rejestracji danych planu z poziomu oddziału i z
poziomu bloku operacyjnego
Musi istnieć możliwość obsługi listy zabiegów bloku
operacyjnego, obejmującej:
- dostęp do aktualnych i archiwalnych danych pacjentów.
- modyfikacja danych pacjentów,
System musi umożliwiać wyszukiwanie zabiegów na liście
58
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
zabiegów wg różnych kryteriów, w tym:
40.
41.
42.
43.
44.
- statusu zabiegu (planowany, w trakcie realizacji, opieka
pooperacyjna, przekazany na oddział, anulowany),
- danych pacjenta (nazwisko, imię, PESEL),
- tryb zabiegu,
- rodzaj zabiegu,
- planowanych i rzeczywistych dat wykonania zabiegu,
- bloku i sali operacyjnej,
45.
46.
- jednostki zlecającej,
- numeru księgi zabiegów,
TAK
TAK
47.
- składu zespołu operacyjnego (operatora, pielęgniarski
operacyjnej, anestezjologa, pielęgniarki anestezjologiczna).
TAK
39.
TAK
TAK
TAK
TAK
TAK
TAK
- przeglądu zabiegów zaplanowanych na dzisiaj i/lub jutro
System musi umożliwiać przyjęcie pacjenta na blok operacyjny i
odnotowanie związanych z tym danych:
- czas przyjęcia i osoby przyjmującej,
- wpis do Księgi Bloku operacyjnego
System musi umożliwić odnotowanie danych medycznych
przeprowadzonego zabiegu w tym:
TAK
- rodzaju wykonanego zabiegu,
- czasu trwania zabiegu,
- rozpoznania pooperacyjnego ICD9 i opisowego,
- procedur medycznych z możliwością automatycznego
56.
dodania procedur powiązanych z przeprowadzonym zabiegiem,
57. - opisu wykonanego zabiegu wraz z lekarzem opisującym,
TAK
TAK
TAK
48.
49.
50.
51.
52.
53.
54.
55.
58.
- składu zespołu zabiegowego domyślnie uzupełnianego na
podstawie planu,
- możliwość załączenia formularza definiowanego przez
użytkownika,
- możliwość dołączania załączników w postaci dowolnych
60.
plików (np. skany dokumentów, pliki dźwiękowe i wideo),
- odnotowanie przetoczeń krwi i preparatów krwiopochodnych z
61. wpisem do księgi transfuzyjnej, odnotowanie powikłań po
przetoczeniu,
62. - zużytych materiałów:
59.
-- z wykorzystaniem kodów kreskowych lub poprzez manualny
wybór pozycji ze słownika,
64. -- z możliwością automatycznego dodania materiałów z planu,
65. -- z możliwością automatycznego dodania materiałów
63.
59
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
powiązanych z wykonanym zabiegiem,
66.
67.
68.
69.
70.
- możliwość rejestracji danych z poziomu oddziału i z poziomu
bloku operacyjnego
System musi umożliwić rejestrację danych znieczulenia, w tym:
- czasu znieczulenia,
- czasu anestezjologicznego,
- rodzaju przeprowadzonego znieczulenia domyślnie
wypełnianego na podstawie kwalifikacji z możliwością edycji,
- opisu znieczulenia ze wskazaniem osoby opisującej,
- zespołu anestezjologicznego domyślnie uzupełnionego na
72.
podstawie planu,
73. - podanych leków:
71.
-- z wykorzystaniem kodów kreskowych lub poprzez manualny
wybór pozycji ze słownika,
-- z możliwością automatycznego dodania leków powiązanych
75.
z wykonanym zabiegiem
76. System musi wspomagać opiekę pooperacyjną w zakresie:
- ewidencji czasu trwania opieki pooperacyjnej oraz lekarza
77.
przyjmującego,
74.
78.
79.
- ewidencji wykonanych procedur,
- ewidencji podanych leków i zużytych materiałów,
- oceny stanu pacjenta z wykorzystaniem zmodyfikowanej skali
Aldrete'a
81. - opisu powikłań znieczulenia,
80.
- opisu zaleceń pooperacyjnych,
- ewidencji daty przekazania pacjenta na oddział wraz ze
83.
wskazaniem lekarza przekazującego.
System musi umożliwiać prowadzenie Księgi Bloku
84.
Operacyjnego w zakresie:
- możliwość definiowania księgi dla bloku operacyjnego, dla
85.
sali operacyjnej oraz dla grupy zabiegów,
82.
86.
87.
88.
89.
90.
91.
92.
- przegląd ksiąg bloku operacyjnego wg różnych kryteriów, w
tym:
-- danych pacjenta (nazwisko, imię, PESEL),
-- trybu zabiegu,
-- rodzaju zabiegu,
-- dat wykonania zabiegu,
-- bloku i sali operacyjnej,
-- jednostki zlecającej,
60
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
93.
-- księgi zabiegów,
TAK
94.
95.
-- roku księgi,
-- zakresu numerów księgi,
TAK
TAK
-- składu zespołu operacyjnego (operatora, pielęgniarski
operacyjnej, anestezjologa, pielęgniarki anestezjologiczna),
97. - wydruk księgi bloku operacyjnego
System musi wspomagać prowadzenie dokumentacji zabiegu
98.
operacyjnego, w tym:
96.
99. - protokół z zabiegu operacyjnego,
100. - protokół przekazania pacjenta na oddział
- możliwość uzupełniania dokumentacji o materiały
101. elektroniczne - skany dokumentów, zdjęcia, pliki dźwiękowe
oraz wideo
- opcjonalne przechowywanie wszystkich wersji utworzonych
102.
dokumentów
Musi istnieć możliwość definiowania własnych szablonów
103.
wydruków
104. Musi istnieć możliwość obsługi raportów wbudowanych, w tym:
- raport z wykonań zabiegów operacyjnych z uwzględnieniem
kryteriów: czas wykonania zabiegu, księga bloku, sala
105.
operacyjna z podziałem na rodzaj zabiegu, księgę bloku, salę i
jednostkę zlecającą
106. Musi istnieć możliwość definiowania własnych wykazów
Musi istnieć możliwość projektowania formularzy dokumentacji
107.
medycznej
System musi zapewnić integrację z innymi modułami
108. Zintegrowanego Szpitalnego Systemu Informacyjnego w
zakresie:
- dostępu do historii choroby i dokumentacji medycznej
109.
bieżącego pobytu szpitalnego,
110. - rejestracji kart zakażeń,
- automatycznej aktualizacji stanów magazynowych przy
111.
ewidencji leków i materiałów,
-przekazywanie zamówień na krew i preparaty krwiopochodne
112.
do banku krwi,
- przekazywanie preparatów krwi z banku krwi na blok
113.
operacyjny,
- aktualizacja stanów magazynowych banku krwi na podstawie
114.
danych z bloku operacyjnego,
61
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
- wzajemnego udostępniania informacji o zleconych badaniach
i konsultacjach,
116. - przeglądu wyników zleconych badań i konsultacji,
- przeglądu wszystkich poprzednich hospitalizacji pacjenta i
117.
wizyt w przychodni,
- eksportu danych statystycznych oraz ilościowych o
wykonanych świadczeniach, podanych lekach i zużytych
118.
materiałach z możliwością wykorzystania przez moduł
Rachunku Kosztów Leczenia.
115.
62
TAK
TAK
TAK
TAK
Dokumentacja Medyczna
Lp.
1.
2.
3.
4.
5.
6.
7.
8.
Wymaganie (Dokumentacja Medyczna)
Wymagane Oferowane
Moduł musi działać w architekturze trójwarstwowej.
Interfejs użytkownika modułu musi być dostępny z poziomu
przeglądarki internetowej i nie może wymagać instalowania
żadnego dodatkowego oprogramowaniach na stacjach
klienckich (system nie może wymagać korzystania ze
specjalnych programów klienckich technologii typu Citrix,
VNC, innych, w celu realizacji wymagań funkcjonalnych).
Moduł musi umożliwiać pracę z poziomu najbardziej
popularnych przeglądarek, co najmniej Microsoft Internet
Explorer, Google Chrome, Mozilla Firefox, Opera.
Moduł musi umożliwiać pracę na tabletach medycznych lub
komputerach wyposażonych w monitory dotykowe. Pełna
funkcjonalność modułu musi być dostępna na komputerach
tego typu.
Moduł musi umożliwiać wykonanie nowej operacji w systemie
bez konieczności przerywania czynności dotychczas
wykonywanej (np. obsługa zdarzenie w trybie nagłym) i
powrót do zawieszonej czynności bez utraty danych,
kontekstu itp.
Wszystkie błędy niewypełnienia pól obligatoryjnych oraz
błędnego wypełnienia muszą być prezentowane w jednym
komunikacie, z możliwością szybkiego przejścia do tego
miejsca aplikacji(np. poprzez odpowiedni link), gdzie te błędy
wystąpiły.
TAK
Wyróżnienie pól:
- których wypełnienie jest wymagane,
TAK
TAK
TAK
TAK
TAK
TAK
TAK
9. - przeznaczonych do edycji,
10. - wypełnionych niepoprawnie.
TAK
TAK
Generowanie Historii Choroby z danych zgromadzonych w
11. Zintegrowanym Szpitalnym Systemie Informacyjnym
Zamawiającego.
TAK
Generowanie Karty Informacyjnej z danych gromadzonych w
12. Zintegrowanym Szpitalnym Systemie Informacyjnym
Zamawiającego.
13. Generowanie wyników badań dla zadanych kryteriów:
63
TAK
TAK
pacjent, nazwa badania, jednostka organizacyjna, zadany
czasu,
14. Generowanie wydruków kart obserwacji pacjenta
15. Generowanie wydruków kart zakażenia, kart drobnoustroju
Generowanie raportów z dyżuru lekarskiego na podstawie
16.
zarejestrowanych obserwacji pacjenta
TAK
TAK
17. Generowanie raportów z diagnoz pielęgniarskich
18. Wydruk diagnoz pielęgniarskich
TAK
TAK
System musi umożliwiać dopasowanie systemu do potrzeb
19. Zamawiającego w zakresie dokumentowania procesu
leczenia :
TAK
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
- definiowania własnych formularzy przeznaczonych do
wpisywania danych w systemie.
- wyświetlanie, wprowadzanie i drukowanie informacji w
ustalonej przez użytkownika postaci (definiowalne formularze
oraz edytor wydruków dla badań, konsultacji, itp.).
- histogramy
- możliwość kojarzenia formularzy ze zleceniami i
elementami leczenia
- rejestrowanie danych multimedialnych (rysunki, obrazy,
dźwięki, itp.).
- dostęp do danych dla potrzeb analitycznosprawozdawczych.
System musi przechowywać wszystkie wersje utworzonej i
wydrukowanej i/lub zarchiwizowanej w archiwum
elektronicznym dokumentacji medycznej.
Wszystkie dokumenty dokumentacji medycznej pacjenta
muszą być dostępne z jednego miejsca.
Musi istnieć możliwość zdefiniowania drukarki dla każdego
rodzaju dokumentu tak, aby dokument mógł być drukowany
na odpowiedniej dla niego drukarce.
Powinna istnieć możliwość podpisania elektronicznego i
zarchiwizowania wszystkich dokumentów dokumentacji
medycznej tworzonych przez system zgodnie z
obowiązującymi przepisami.
Możliwość zablokowania modyfikacji wpisów w historii
choroby dokonanych przez innego lekarza niż lekarz
aktualnie zalogowany/ autoryzujący wpis
Możliwość autoryzacji przez lekarza dokonującego wpis,
64
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
fragmentu historii choroby, epikryzy lub rozpoznania
Podczas wydruku dokumentu system musi sprawdzać i
32. informować, czy dane źródłowe wykorzystane do utworzenia
dokumentu uległy zmianie.
System musi być wyposażony w mechanizmy umożliwiające
33. weryfikację, czy na określonym etapie procesu obsługi
pacjenta zostały utworzone wszystkie wymagane dokumenty
Musi istnieć możliwość utworzenia dokumentu roboczego,
34. umożliwiającego podgląd danych źródłowych w postaci
dokumentu.
System musi umożliwiać obsługę dokumentów o zmiennej
treści, o ile nie stoi to w sprzeczności z wymaganiami
35. zewnętrznymi dotyczącymi tych dokumentów (np. ściśle
określony format lub zawartośc informacyjna dla dokumentów
skierowań, zleceń, recept)
TAK
TAK
TAK
TAK
Obchód - mobilny dostęp do Oprogramowania
Lp.
1.
2.
3.
4.
5.
6.
7.
8.
9.
Wymaganie (Obchód - moduł mobilny)
Aplikacja dedykowane do pracy na tabletach z ekranem o
wielkości 7” lub 10”.
Aplikacja dostępna na wszystkie rodzaje systemów
operacyjnych tabletów, tj. system android, system Ios oraz
MS Windows.
System logowania do aplikacji mobilnej zgodny z systemem
logowania do całego Oprogramowania Zamawiającego.
Dostęp do zarejestrowanych i zgromadzonych danych, wraz z
edycją danych, Oprogramowania Zamawiającego:
- graficzny przegląd miejsca pobytu pacjenta - zachowanie
układu Oddział, sala, pacjent,
- przypisanie pacjentów do sal,
- wyszukiwanie pacjenta po kodzie EAN - obsługa kodów
kreskowych przydzielonych pacjentom w ramach systemu
identyfikacji pacjentów,
- przegląd statystyki pacjentów oddziału,
- zlecanie leków, zgodne co do zakresu danych ze sposobem
zlecenia leków w Oprogramowaniu Zamawiającego,
65
Wymagan
e
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
Oferowan
e
10.
11.
12.
13.
14.
15.
- prezentacja danych o lekach zleconych oraz o lekach
podanych,
- zlecanie badań laboratoryjnych,
- prezentacja danych o zleconych badaniach laboratoryjnych,
- przegląd wyników badań laboratoryjnych pacjenta,
- zlecanie badań diagnostycznych,
- prezentacja danych o zleconych badaniach
diagnostycznych,
16. - przegląd wyników badań diagnostycznych pacjenta,
- wprowadzanie wyników pomiarów dla pacjenta w ramach
17.
czynności opieki pielęgniarskiej.
- możliwość identyfikowania pacjenta po kodzie paskowym na
18.
opasce, celem uniknięcia pomyłki.
Możliwość rejestracji obchodu w formie nagrań wideo lub
19. audio i tworzenia dokumentacji w formie zdjęć. Zadanie może
być wykonywane aplikacjami zewnętrznymi.
66
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
eRejestracja (dla pacjentów)
Lp.
1.
2.
3.
4.
5.
6.
7.
8.
Wymaganie (eRejestracja)
Rejestracja nowego pacjenta – użytkownika systemu
Potwierdzenie rejestracji pacjenta poprzez wprowadzenie
kodu udostępnionego przez SMS.
Potwierdzenie rejestracji pacjenta poprzez wprowadzenie
kodu udostępnionego przez e-Mail.
Możliwość samodzielnej autoryzacji (określenie danych
dostępowych – login/hasło) użytkownika – pacjenta po
poprawnym potwierdzeniu rejestracji; możliwość wyłączenia
trybu samodzielnej autoryzacji pacjentów.
Możliwość ograniczenia samodzielnej autoryzacji
użytkowników – pacjentów do osób zarejestrowanych w
Oprogramowaniu Zamawiającego (na podstawie zgodności
numeru PESEL i nazwiska); możliwość wyłączenia trybu
autoryzacji pacjentów w oparciu o rejestr Oprogramowania.
Logowanie pacjenta/użytkownika – autentykacja użytkownika
systemu.
Aktualizacja profilu pacjenta/użytkownika systemu; możliwość
aktualizacji danych kontaktowych: adresu e-mail, nr-telefonu;
adresu zamieszkania.
Możliwość zablokowania zmiany danych osobowych pacjenta
(imię, nazwisko, PESEL) w profilu pacjenta.
Możliwość rejestracji podopiecznych pacjenta; dla
podopiecznych, którzy są użytkownikami systemu
konieczność akceptacji objęcia opieką przez innego pacjenta;
9. możliwość odrzucenia wniosku o objęcie opieką przez innego
pacjenta - użytkownika eRejestracji lub możliwość trwałego
zablokowania wnioskowania o objęcie opieką przez danego
użytkownika.
Możliwość przeglądu opiekunów; możliwość usunięcia
opiekuna; możliwość zablokowania opiekuna - opiekun nie
10.
będzie miał możliwości ponownego wnioskowania o objęcie
opieką.
Możliwość określenia przez pacjenta parametrów
11. powiadomień o zbliżającym się terminie udzielenia usługi
(interwał czasu przed planowanym terminie, tryb
67
Wymagan
e
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
Oferowan
e
powiadamiania) zdefiniowanych w systemie jako możliwe do
ustawienia przez użytkownika/pacjenta.
12. Możliwość zmiany hasła pacjenta – użytkownika systemu.
Możliwość ustawienia nowego hasła, po poprawnej
13. weryfikacji adresu e-mail lub numeru telefonu poprzez
wprowadzenie przesłanego kodu potwierdzenia.
14.
15.
16.
17.
18.
19.
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).
Możliwość/konieczność rejestracji danych skierowania w
czasie rezerwacji terminu udzielenia dla usług o odpowiednim
statusie wymagalności danych skierowania.
Grupowanie usług do rezerwacji wg zdefiniowanych rodzajów
usług.
Grupowanie usług wg zawodu personelu realizującego (np.
lekarze, lekarze-dentyści, fizjoterapeuci).
Przegląd rejestru rezerwacji wizyt pacjenta z wyróżnieniem
stanu usługi (planowana, zrealizowana, anulowana).
Możliwość anulowania przez pacjenta rezerwacji wizyty.
20. Możliwość zmiany terminu wizyty przez pacjenta.
Możliwość rezerwacji terminu wizyty dla podopiecznych;
21. możliwość zmiany terminu wizyt dla podopiecznych;
możliwość anulowania rezerwacji podopiecznych
Wydruk potwierdzenia rezerwacji wizyty zawierający
22. informacje o usłudze, miejscu realizacji oraz planowaną datę
udzielenia usługi.
Możliwość wysyłania przez SMS, e-mail lub wiadomości na
23. portalu pacjenta przypomnień o zbliżających się terminach
wizyt lub wynikach badań.
Możliwość wysyłania przez SMS, e-mail lub wiadomości na
24. portalu pacjenta powiadomień o anulowaniu rezerwacji przez
pracowników jednostki ochrony zdrowia.
Możliwość wysyłania przez SMS, e-mail lub wiadomości na
portalu pacjenta powiadomień o zmianie terminu realizacji
25.
usługi dokonanej przez pracowników jednostki ochrony
zdrowia.
26. Wysyłanie wiadomości do jednostki ochrony zdrowia;
68
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
27.
28.
29.
30.
31.
32.
33.
34.
35.
możliwość formatowania treści wiadomości (czcionka, kolor,
justowanie, odnośniki do innych stron).
Wysyłanie wiadomości SMS, e-mail lub wiadomości na
portalu pacjenta o konieczności potwierdzenia rezerwacji
terminu wizyty
Potwierdzenie rezerwacji wizyty w określonym czasie przed
realizacją dla rezerwacji wymagających takich potwierdzeń
Przegląd wysłanych wiadomość; wyróżnienie wiadomości
nieprzeczytanych; wyszukiwanie wiadomości wg tematu, daty
wysłania i odbiorcy.
Edycja wysłanych i jeszcze nieprzeczytanych przez
pracowników jednostki ochrony zdrowia wiadomości.
Przegląd wiadomości odebranych od pacjentów;
wyszukiwanie wiadomości wg tematu, daty wysłania,
nadawcy; wyróżnienie wiadomości nieprzeczytanych.
Rejestracja nowego pacjenta – użytkownika systemu
Potwierdzenie rejestracji pacjenta poprzez wprowadzenie
kodu udostępnionego przez SMS.
Potwierdzenie rejestracji pacjenta poprzez wprowadzenie
kodu udostępnionego przez e-Mail.
Możliwość samodzielnej autoryzacji (określenie danych
dostępowych – login/hasło) użytkownika – pacjenta po
poprawnym potwierdzeniu rejestracji; możliwość wyłączenia
trybu samodzielnej autoryzacji pacjentów.
Możliwość ograniczenia samodzielnej autoryzacji
użytkowników – pacjentów do osób zarejestrowanych w
36. Oprogramowaniu Zamawiającego (na podstawie zgodności
numeru PESEL i nazwiska); możliwość wyłączenia trybu
autoryzacji pacjentów w oparciu o rejestr Oprogramowania.
Logowanie pacjenta/użytkownika – autentykacja użytkownika
systemu.
Aktualizacja profilu pacjenta/użytkownika systemu; możliwość
38. aktualizacji danych kontaktowych: adresu e-mail, nr-telefonu;
adresu zamieszkania.
Możliwość podglądu przez pacjenta historii leczenia i wyników
39.
badań w portalu eRejestracja/e-pacjent.
37.
69
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
eKontrahent (dla kontrahentów Zamawiającego)
Lp.
1.
2.
3.
4.
5.
6.
7.
Wymaganie (eKontrahent)
Rejestracja użytkowników systemu - pracowników
kontrahenta; definiowanie uprawnień dla użytkowników przez
pracowników kontrahenta, posiadających uprawnienie
lokalnego administratora.
Rejestracja danych lekarzy zlecających - pracowników
kontrahenta.
Rejestracja pacjentów związanych z kontrahentem.
Przegląd usług realizowanych w Jednostce Ochrony Zdrowia
na rzecz kontrahenta wraz z harmonogramami realizacji
usług.
Rezerwacja terminu udzielenia usługi dla wskazanego
pacjenta kontrahenta.
Możliwość wskazania/zlecenia badań do realizacji w czasie
rezerwowanej wizyty pacjenta.
Anulowanie rezerwacji terminu udzielenia usługi medycznej.
Wymagan
e
TAK
TAK
TAK
TAK
TAK
TAK
TAK
8.
Zmiana planowanego terminu realizacji usługi medycznej dla
wskazanej rezerwacji.
TAK
9.
Przegląd rezerwacji terminów udzielenia usług medycznych
z wyróżnieniem stanu rezerwacji (planowane, zrealizowane,
anulowane).
TAK
10.
Wydruk potwierdzenia rezerwacji terminu udzielenia usług
medycznych.
TAK
Możliwość rejestracji zlecenia wykonania badań; rejestracja
11. danych skierowania na badania: instytucja kierująca, lekarz
kierujący.
12.
13.
14.
15.
16.
Możliwość rejestracji danych o pobraniu materiałów do
zleconych badań.
Możliwość wydruku potwierdzenia zlecenia badań.
Przegląd zarejestrowanych zleceń wykonania badań z
wyróżnieniem stanu realizacji badania
(zarejestrowane/zlecone/w trakcie
realizacji/zrealizowane/anulowane).
Wydruk raportu prezentującego liczby zrealizowanych usług
w określonym czasie.
Wydruk raportu – zestawienia usług zrealizowanych na rzecz
70
TAK
TAK
TAK
TAK
TAK
TAK
Oferowan
e
danego kontrahenta w określonym czasie.
71
Konfigurator dla eRejestracja/eKontrahent
Lp.
Wymaganie (Konfigurator)
Rejestracja struktury organizacyjnej Jednostki Zamawiającego
w układzie hierarchicznym, w postaci interaktywnego diagramu.
Możliwość rejestracji i prezentacji formatowanych opisów
2.
jednostek organizacyjnych.
Możliwość rejestracji godzin pracy jednostek organizacyjnych;
3. możliwość przepisania godzin pracy z informacji
zarejestrowanych dla jednostki nadrzędnej.
Integracja rejestru struktury organizacyjnej z odpowiadającym
4.
rejestrem Oprogramowania Zamawiającego.
Publikacja informacji o elementach struktury organizacyjnej
5.
szpitala na portalu Zamawiającego.
Publikacja informacji o o usługach medycznych realizowanych
6. w jednostkach organizacyjnych szpitala na portalu
Zamawiającego.
Rejestracja informacji o personelu realizującym usługi
7. medyczne; rejestracja informacji o grupach zawodowych i
specjalnościach personelu.
Rejestracja informacji o godzinach pracy personelu
8.
(harmonogramach pracy personelu).
Integracja rejestru personelu z odpowiadającym rejestrem
9.
Oprogramowania Zamawiającego.
Rejestracja informacji o usługach realizowanych w Jednostce
Zamawiającego; rejestracja opisów usługi w postaci
10.
formatowanych tekstów; rejestracja informacji o wymagalności
skierowania.
1.
11.
12.
13.
14.
Definiowanie wymagalności istnienia w systemie aktywnej
deklaracji POZ określonego typu w czasie rejestracji terminu
realizacji wskazanej usługi.
Definiowanie rodzajów świadczonych usług, przypisywanie
usług do zdefiniowanych rodzajów
Definiowanie statusu wyboru personelu dla definiowanych usług
(wybór personelu dopuszczalny, niemożliwy, wymagany).
Definiowanie wymagalności skierowania do realizacji usługi;
określenie możliwości lub konieczności rejestracji danych
skierowania w czasie rezerwacji terminu udzielenia usługi.
72
Wymaga
ne
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
Oferowa
ne
Rejestracja informacji o szczególnych warunkach udzielania
15. usług (zalecenia dla pacjentów odnośnie realizacji usługi) w
postaci formatowanych tekstów.
Rejestracja informacji o dokumentach (załącznikach)
16.
związanych z definiowaną usługą.
Definiowanie kwestionariuszy umożliwiających pozyskanie
dodatkowych informacji od pacjenta w procesie rezerwacji
terminu udzielenia usługi/wizyty; możliwość zdefiniowania pytań
17. dla których podanie odpowiedzi jest wymagane, możliwość
zdefiniowania pytań zamkniętych, dla których odpowiedź
udzielana jest poprzez wybór pozycji na liście dostępnych
wartości.
18.
19.
20.
21.
22.
23.
24.
25.
Integracja rejestru usług medycznych z odpowiadającym
rejestrem Oprogramowania Zamawiającego; powiązanie usług
zdefiniowanych w portalu z usługami w Oprogramowaniu;
przepisywanie wybranych usług z Oprogramowania do rejestru
portalu.
Publikacja informacji o wskazanej usłudze w module
eRejestracja.
Wskazanie usług, dla których możliwa jest rezerwacja terminu
udzielania usług w module eRejestracja.
Rejestracja usług zlecanych stanowiących grupy badań
dostępnych dla kontrahenta; przypisanie badań do usług
zlecanych.
Rejestracja informacji o dokumentach (załącznikach)
wymaganych do udzielenia usług; możliwość dołączenia pliku
załącznika.
Przypisanie zarejestrowanych załączników do wskazanych
usług.
Definiowanie postaci skierowań drukowanych podczas
rezerwacji terminów wizyt przez jednostki współpracujące
(kontrahentów) - obsługa szablonów skierowań.
Definiowanie dni wolnych od pracy.
Rejestracja informacji o dostępności elementów struktury
organizacyjnej Jednostek Zamawiającego; podpowiadanie
26. definicji harmonogramów pracy jednostki na podstawie godzin
otwarcia jednostki; możliwość uwzględnienia zdefiniowanych
dni wolnych od pracy.
27. Rejestracja przerw w dostępności elementów struktury
73
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
organizacyjnej Jednostki Zamawiającego.
Rejestracja informacji o dostępności usług w jednostkach
28. organizacyjnych szpitala na postawie zdefiniowanej wcześniej
dostępności jednostek organizacyjnych.
29.
30.
31.
32.
33.
Możliwość definiowania parametrów rezerwacji dla usług
dostępnych w jednostkach organizacyjnych: maksymalna liczba
jednoczasowych rezerwacji tego samego pacjenta; minimalny
interwał czasu pomiędzy datą rejestracji a datą realizacji usługi;
maksymalny okres czasu względem daty rezerwacji,
w którym możliwe jest określenie planowanego terminu
udzielenia usługi.
Możliwość zdefiniowania wymagalności potwierdzenia
rezerwacji terminu wskazanej usługi realizowanej w danej
jednostce organizacyjnej w określonym przedziale czasu przed
realizacją wizyty;
Rejestracja informacji o dostępności usług w jednostkach
organizacyjnych szpitala na postawie harmonogramu;
podpowiadanie definicji harmonogramu na podstawie godzin
otwarcia jednostki; możliwość rejestracji ciągłej dostępności
usług w jednostkach organizacyjnych; możliwość uwzględnienia
zdefiniowanych dni wolnych od pracy
Rejestracja informacji o dostępności personelu na podstawie
harmonogramu; podpowiadanie harmonogramów dla personelu
na podstawie godzin pracy zdefiniowanych w rejestrze
personelu.
Rejestracja informacji o dostępności usług udzielanych przez
określony personel na podstawie zdefiniowanej wcześniej
dostępności personelu.
Rejestracja informacji o dostępności usług udzielanych przez
określony personel na podstawie harmonogramów;
34.
podpowiadanie harmonogramów na podstawie godzin pracy
personelu.
Możliwość dowolnej modyfikacji definiowanych dostępności:
35. usuwanie dostępnych okresów; modyfikacja dat dostępnych
okresów; dodawanie nowych okresów dostępności.
Możliwość zdefiniowania długości przedziału czasowego dla
rezerwacji terminów udzielenia usługi przez wskazany personel;
36.
możliwość określenia maksymalnej liczby równoczesnych
rezerwacji w zdefiniowanym przedziale czasowym
74
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
Definiowanie klas pacjentów – użytkowników modułu
eRejestracja.
Definiowanie parametrów rezerwacji dla poszczególnych klas
pacjentów: maksymalnej liczby rezerwacji terminów udzielenia
usługi dostępnych dla pacjentów określonej klasy; maksymalny
38.
okres rezerwacji terminów udzielenia usług; tryb potwierdzenia
rezerwacji (bez potwierdzenia/potwierdzenie email/potwierdzenie SMS).
Możliwość określenia sposobu powiadamiania pacjentów
określonej klasy o anulowaniu rezerwacji w jednostce ochrony
39.
zdrowia (brak powiadomień, powiadomienie SMS,
powiadomienie e-mail).
37.
Możliwość określenia sposobu powiadamiania pacjentów
określonej klasy o zmianie planowanego terminu udzielenia
40.
usługi w jednostce ochrony zdrowia (brak powiadomień,
powiadomienie SMS, powiadomienie e-mail).
Możliwość określenia sposobu powiadamiania pacjentów
określonej klasy o potwierdzeniu planowanego terminu
41.
udzielenia usług w Oprogramowaniu (brak powiadomień,
powiadomienie SMS, powiadomienie e-mail).
Możliwość określenia sposobu powiadamiania pacjentów
określonej klasy o potwierdzeniu planowanego terminu
42.
udzielenia usług w Oprogramowaniu (brak powiadomień,
powiadomienie SMS, powiadomienie e-mail).
Możliwość określenia sposobu powiadamiania pacjentów
określonej klasy o zbliżającym się terminie udzielenia usługi
(brak powiadomień, powiadomienie SMS, powiadomienie email), możliwość określenia interwału czasu przed planowanym
43.
terminem udzielenia usługi, kiedy zostanie wysłane
powiadomienie; możliwość definiowania wielu powiadomień
o zbliżającym się terminie udzielenia usługi dla danej
rezerwacji.
Możliwość definiowania uprawnień do modułu e-pacjent dla
pacjentów określonej klasy; integracja uprawnień do modułu
44.
eRejestracja z uprawnieniami zarządzanymi w administratorze
systemu.
Przegląd pacjentów zarejestrowanych na portalu
45.
Zamawiającego.
46. Zatwierdzenie zarejestrowanych pacjentów jako użytkowników
75
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
systemu przez pracowników szpitala (autoryzacja przez
pracowników szpitala).
Rejestracja pacjentów jak użytkownika systemu przez
pracowników szpitala – możliwość udostępnienia
47.
funkcjonalności eRejestracja bez konieczności rejestrowania się
pacjenta na stronie internetowej.
Przypisanie pacjentom - użytkownikom systemu
48. podopiecznych; możliwość rejestracji danych podopiecznych
nie zarejestrowanych wcześniej w systemie.
49.
50.
51.
52.
53.
Możliwość zablokowania konta pacjenta - zablokowania
dostępu wybranym pacjentom do eRejestracja.
Możliwość wygenerowania raportów zawierających:
- wykaz pacjentów z liczbą dokonanych rezerwacji
internetowych (wyszukanie pacjentów, którzy wykonali
najwięcej rezerwacji internetowych),
- wykaz pacjentów z liczbą niewykorzystanych rezerwacji tj.
nieoznaczonych jako zrealizowane z przekroczonym
planowanym terminem wizyty.
Integracja rejestru pacjentów z odpowiadającym rejestrem
Oprogramowania; możliwość wyszukiwania pacjentów
zarejestrowanych wg identyfikatora w systemie
Oprogramowania.
Rejestracja kontrahenta obsługiwanego w systemie.
Rejestracja pracowników kontrahenta – użytkowników systemu;
przydzielanie uprawnień pracownikom kontrahenta.
54. Rejestracja pacjentów powiązanych z danym kontrahentem.
Import danych pacjentów związanych z kontrahentem z pliku
55.
zewnętrznego (plik csv o określonym formacie).
56. Rejestracja umów zawartych z kontrahentem.
57.
58.
59.
60.
61.
Rejestracja usług realizowanych na rzecz danego kontrahenta
na podstawie określonej umowy; możliwość rejestracji
ilościowych limitów usług.
Rejestracja dostępności usług w ramach określonych umów
zawartych z kontrahentem.
Integracja rejestru kontrahentów z odpowiadającym rejestrem
Oprogramowania.
Możliwość definiowania postaci wiadomości generowanych
przez system - definiowanie szablonów wiadomości;
Możliwość przypisania zdefiniowanych szablonów wiadomości
76
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
związanych z zaplanowanymi/realizowanymi usługami do
rodzaju usług - możliwość zdefiniowania różnych szablonów
wiadomości dla różnych typów usług
Wysyłanie wiadomości do pacjentów zarejestrowanych w
systemie (wiadomości powinny być prezentowane w module
eKontrahent); wysyłanie wiadomości do wszystkich pacjentów;
62. wysyłanie wiadomości do wybranych pacjentów; wysyłanie
komunikatów – wiadomości, na które nie można odpowiadać;
możliwość formatowania treści wiadomości (czcionka, kolor,
justowanie, odnośniki do innych stron).
63.
64.
65.
66.
67.
68.
Możliwość wysyłania wiadomości e-mail do pacjentów –
użytkowników portalu.
Możliwość wysyłania wiadomości SMS do pacjentów –
użytkowników portalu.
Przegląd wysłanych wiadomość; wyróżnienie wiadomości
nieprzeczytanych; wyszukiwanie wiadomości wg tematu, daty
wysłania i odbiorcy.
Edycja nieprzeczytanych, wysłanych wiadomości.
Logiczne usunięcie wiadomości – oznaczenie wiadomości jako
usuniętej – niewidocznej dla adresatów.
Przegląd wiadomości odebranych od pacjentów; wyszukiwanie
wiadomości wg tematu, daty wysłania, nadawcy; wyróżnienie
wiadomości nieprzeczytanych.
77
TAK
TAK
TAK
TAK
TAK
TAK
TAK
Przychodnia - Rejestracja
Lp.
Wymaganie (Przychodnia specjalistyczna - rejestracja)
Wymagane Oferowane
TAK
7.
Moduł musi działać w architekturze trójwarstwowej.
Interfejs użytkownika musi być dostępny z poziomu
przeglądarki internetowej i nie może wymagać instalowania
żadnego dodatkowego oprogramowania na stacjach
klienckich (system nie może wymagać korzystania ze
specjalnych programów klienckich technologii typu Citrix,
VNC, innych, w celu realizacji wymagań funkcjonalnych).
Moduł musi umożliwić pracę z poziomu najbardziej
popularnych przeglądarek, co najmniej MS Internet Explorer,
Google Chrome i Mozilla Firefox, Opera.
Moduł musi umożliwiać obsługę kodów 2D do rejestracji
skierowań pochodzących z innych zakładów opieki
zdrowotnej.
Moduł musi umożliwiać wykonanie nowej operacji w
systemie bez konieczności przerywania czynności
dotychczas wykonywanej (np. obsługa zdarzenie w trybie
nagłym) i powrót do zawieszonej czynności bez utraty
danych, kontekstu itp.
Wszystkie błędy niewypełnienia pól obligatoryjnych oraz
błędnego wypełnienia muszą być prezentowane w jednym
komunikacie, z możliwością szybkiego przejścia do tego
miejsca aplikacji(np. poprzez odpowiedni link), gdzie te błędy
wystąpiły.
Moduł musi umożliwić wyróżnianie pól:
8.
9.
- których wypełnienie jest wymagane,
- przeznaczonych do edycji,
TAK
TAK
1.
2.
3.
4.
5.
6.
10. - wypełnionych niepoprawnie.
W każdym polu edycyjnym(opisowym) tj np. treść wywiadu,
musi istnieć możliwość wybrania i skorzystania z dowolnego
formularza, tekstu standardowego lub wczytania tekstu
11. zapisanego w pliku zewnętrznym. Musi 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.
12. Moduł musi umożliwiać wykonanie nowej operacji w
78
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
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.
Moduł musi zawierać wbudowany komunikator
13. umożliwiający wymianę wiadomości pomiędzy
użytkownikami.
TAK
14. Definiowanie dostępności usług placówki medycznej
15. Określanie dostępności zasobów w placówce (grafiki).
TAK
TAK
16. Definiowanie szablonu pracy zasobu typu gabinet :
17. - określenie szablonu dla każdego z dni tygodnia,
TAK
TAK
18. - określenie czasu pracy gabinetu,
19. - określenie zakresu usług realizowanych w gabinecie.
20. Definiowanie szablonu pracy zasobu typu lekarz:
21. - określenie szablonu dla każdego z dni tygodnia,
22. - określenie czasu pracy,
- określenie zakresu usług realizowanych przez lekarza w
23.
ramach umów,
- określenie gabinetu, w którym wykonywane są usługi
24.
(miejsce wykonania),
- generacja grafików dla lekarzy w powiązaniu z gabinetami
25.
w zadanym okresie czasu,
26. - blokada grafików (urlopy, remonty).
Obsługa głównego skorowidza pacjentów Oprogramowania
27.
Zamawiającego.
Możliwość zastosowania kart identyfikacyjnych do
28.
wyszukania pacjenta.
TAK
TAK
TAK
TAK
TAK
29. Planowanie i rezerwacja wizyty pacjenta.
Wyszukiwanie wolnych terminów jednoczesnej dostępności
30.
wymaganych zasobów:
31. - rezerwacja wybranego terminu lub „pierwszy wolny”,
- automatyczna rezerwacja terminów dla zgłoszeń
32.
internetowych wg preferencji pacjenta,
- w przypadku braku wolnych terminów w preferowanych
33. godzinach możliwość rezerwacji pierwszy wolny lub ręczny
wybór terminu,
- rezerwacja terminów dla pacjentów przebywających na
34. oddziałach Zamawiającego, obsługiwanych
w module „Oddział" Zintegrowanego Szpitalnego Systemu
TAK
79
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
Informacyjnego, Zamawiającego,
35.
36.
37.
38.
39.
40.
41.
42.
- wstawianie terminu pomiędzy już istniejące wpisy w grafiku
w przypadkach nagłych
Przegląd rezerwacji.
Rejestracja pacjenta do wykonania usługi.
Określenie miejsca wykonania usługi (wybór gabinetu) dla
usług nie podlegających planowaniu i rezerwacji.
Zlecenie wykonania usługi pacjentowi we wskazanym (lub
wynikającym z rezerwacji) miejscu wykonania – wymagana
jest integracja z dostarczanym modułem „Zlecenia
medyczne” oraz pozostałymi funkcjonalnościami
Zintegrowanego Szpitalnego Systemu Informacyjnego
Zamawiającego,
Możliwość wykorzystania szablonów zleceń złożonych –
wymagana jest integracja z dostarczanym modułem
„Zlecenia medyczne”.
Obsługa kolejek oczekujących zgodnie z obowiązującymi
przepisami.
Obsługa wyników:
43. - odnotowanie wydania wyniku,
44. - wpisywanie wyników zewnętrznych.
45. Raporty i wykazy Rejestracji.
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
80
Przychodnia - Gabinet lekarski
Lp.
Wymaganie (Przychodnia specjalistyczna – gabinet
lekarski)
Wymagane Oferowane
TAK
6.
Moduł musi działać w architekturze trójwarstwowej.
Interfejs użytkownika musi być dostępny z poziomu
przeglądarki internetowej i nie może wymagać instalowania
żadnego dodatkowego oprogramowania na stacjach
klienckich (system nie może wymagać korzystania ze
specjalnych programów klienckich technologii typu Citrix,
VNC, innych, w celu realizacji wymagań funkcjonalnych).
Moduł musi umożliwić pracę z poziomu najbardziej
popularnych przeglądarek, co najmniej MS Internet Explorer,
Google Chrome i Mozilla Firefox, Opera.
Moduł musi umożliwiać wykonanie nowej operacji w
systemie bez konieczności przerywania czynności
dotychczas wykonywanej (np. obsługa zdarzenie w trybie
nagłym) i powrót do zawieszonej czynności bez utraty
danych, kontekstu itp.
Wszystkie błędy niewypełnienia pól obligatoryjnych oraz
błędnego wypełnienia muszą być prezentowane w jednym
komunikacie, z możliwością szybkiego przejścia do tego
miejsca aplikacji(np. poprzez odpowiedni link), gdzie te błędy
wystąpiły.
Moduł musi umożliwić wyróżnianie pól:
7.
8.
- których wypełnienie jest wymagane,
- przeznaczonych do edycji,
TAK
TAK
1.
2.
3.
4.
5.
- wypełnionych niepoprawnie.
W każdym polu edycyjnym(opisowym) tj np. treść wywiadu,
musi istnieć możliwość wybrania i skorzystania z dowolnego
formularza, tekstu standardowego lub wczytania tekstu
10. zapisanego w pliku zewnętrznym. Musi 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.
Moduł musi umożliwiać wykonanie nowej operacji w
systemie bez konieczności przerywania czynności
11.
dotychczas wykonywanej (np. obsługa zdarzenie w trybie
nagłym) i powrót do zawieszonej czynności bez utraty
9.
81
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
danych, kontekstu itp.
Moduł musi zawierać wbudowany komunikator
12. umożliwiający wymianę wiadomości pomiędzy
użytkownikami.
Dostęp do listy pacjentów zarejestrowanych do gabinetu z
13. poziomu rejestracji (moduł Przychodnia specjalistyczna –
rejestracja).
Rejestracja rozpoczęcia obsługi wizyty pacjenta w gabinecie
14.
(przyjęcie).
TAK
TAK
TAK
15. Wspomaganie obsługi pacjenta w gabinecie:
16. Przegląd danych pacjenta w następujących kategoriach:
TAK
TAK
17.
TAK
18.
19.
20.
21.
22.
23.
24.
25.
- dane osobowe,
- podstawowe dane medyczne (grupa krwi, uczulenia, stale
podawane leki, przebyte choroby, karta szczepień),
- uprawnienia z tytułu umów,
- Historia Choroby (dane ze wszystkich wizyt pacjenta) ,
- wyniki badań,
- przegląd rezerwacji,
- wykluczenia (rozpoznania ograniczające uprawnienia z
umowy).
Możliwość użytkowania zdefiniowanych wcześniej wzorców
dokumentacji dedykowanej do wizyty (w zależności od
kategorii medycznej wizyty).
Możliwość zdefiniowania elementów menu (zakładek) w
zależności od potrzeb i rodzaju gabinetu.
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
26.
Możliwość zdefiniowania wzorów dokumentów
dedykowanych dla gabinetu.
TAK
27.
Przegląd, wprowadzanie i modyfikacja danych wizyty w
następujących kategoriach:
TAK
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
- wywiad (na formularzu zdefiniowanym dla wizyty),
- opis badania (na formularzu zdefiniowanym dla wizyty),
- informacje ze skierowania,
- skierowania, zlecenia,
- planowanie i rezerwacja zleceń z wizyty,
- możliwość wykorzystania szablonów zleceń złożonych,
- usługi, świadczenia w ramach wizyty,
- rozpoznanie (główne, dodatkowe),
- zalecenia z wizyty (w tym zwolnienia lekarskie),
- leki przepisane wg słownika leków, recepty (z
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
82
rozmieszczaniem i nadrukiem na formularzach recept),
38.
- wystawione skierowania,
- leki podane podczas wizyty (współpraca z podręcznym
39. magazynkiem leków) - wymagana jest integracja z modułem
„Apteczka” Oprogramowania Zamawiającego,
40. - zlecenia szczepień,
TAK
- możliwość oznaczenia podania leku jako szczepienia:,
- możliwość wpisania przy podaniu leku danych
42.
charakteryzujących szczepienie,
- automatyczny wpis do karty szczepień po oznaczeniu
43.
podania leku jako szczepienia;
TAK
41.
44.
45.
46.
47.
48.
49.
50.
- wykonane podczas wizyty drobne procedury, nie mające
wpływu na rozliczenie pacjenta,
- inne dokumenty (zaświadczenia, druki, na formularzach
zdefiniowanych dla wizyty).
Możliwość stosowania słownika tekstów standardowych do
opisu danych z wizyt.
Możliwość wykorzystania definiowalnych formularzy do opisu
danych wizyty.
Możliwość stosowania „pozycji preferowanych” dla
użytkowników, jednostek organizacyjnych (wyróżnienie
najczęściej wykorzystywanych pozycji słowników).
Możliwość ewidencji wykonania usług rozliczanych
komercyjnie:
- obsługa stanowiska kasowego (jak w module Rejestracja).
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
51. Obsługa zakończenia wizyty:
52. - autoryzacja medyczna wizyty,
TAK
TAK
53. - automatyczne tworzenie karty wizyty.
54. Kwalifikacja rozliczeniowa usług i świadczeń.
TAK
TAK
Wgląd w system do rozliczania świadczeń z Narodowym
55. Funduszem Zdrowia z tytułu zrealizowanych w trakcie wizyty
usług.
TAK
Automatyczna aktualizacja i przegląd Księgi Głównej
Przychodni.
57. Raporty i wykazy Gabinetu.
56.
83
TAK
TAK
Przychodnia - Statystyka
Lp.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Wymaganie (Przychodnia specjalistyczna - statystyka)
Moduł musi działać w architekturze trójwarstwowej.
Interfejs użytkownika musi być dostępny z poziomu
przeglądarki internetowej i nie może wymagać instalowania
żadnego dodatkowego oprogramowania na stacjach
klienckich (system nie może wymagać korzystania ze
specjalnych programów klienckich technologii typu Citrix,
VNC, innych, w celu realizacji wymagań funkcjonalnych).
System musi umożliwić pracę z poziomu najbardziej
popularnych przeglądarek, co najmniej MS Internet Explorer,
Google Chrome i Mozilla Firefox, Opera.
Moduł musi umożliwiać wykonanie nowej operacji w systemie
bez konieczności przerywania czynności dotychczas
wykonywanej (np. obsługa zdarzenie w trybie nagłym) i
powrót do zawieszonej czynności bez utraty danych,
kontekstu itp.
Wszystkie błędy niewypełnienia pól obligatoryjnych oraz
błędnego wypełnienia muszą być prezentowane w jednym
komunikacie, z możliwością szybkiego przejścia do tego
miejsca aplikacji(np. poprzez odpowiedni link), gdzie te błędy
wystąpiły.
System musi umożliwić wyróżnianie pól:
- których wypełnienie jest wymagane,
- przeznaczonych do edycji,
- wypełnionych niepoprawnie.
System musi zawierać wbudowany komunikator
umożliwiający wymianę wiadomości pomiędzy
użytkownikami.
Obsługa statystyki rozliczeniowej i medycznej na podstawie
danych zgromadzonych w modułach „Przychodnia
specjalistyczna – rejestracja” oraz „Przychodnia
specjalistyczna – gabinet lekarski”.
Automatyczna generacja Księgi Przychodni.
Dostęp do wszystkich ksiąg placówki Zamawiającego.
Raporty i wykazy statystyczne.
84
Wymagane Oferowane
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
Kolejki oczekujących
Lp.
Wymaganie (Kolejki oczekujących)
Wymagane Oferowane
1.
Moduł musi działać w architekturze trójwarstwowej.
TAK
2.
Interfejs użytkownika musi być dostępny z poziomu
przeglądarki internetowej i nie może wymagać instalowania
żadnego dodatkowego oprogramowania na stacjach
klienckich (system nie może wymagać korzystania ze
specjalnych programów klienckich technologii typu Citrix,
VNC, innych, w celu realizacji wymagań funkcjonalnych).
TAK
3.
4.
5.
Moduł musi umożliwić pracę z poziomu najbardziej
popularnych przeglądarek, co najmniej MS Internet Explorer,
Google Chrome i Mozilla Firefox, Opera.
Moduł musi umożliwiać wykonanie nowej operacji w
systemie bez konieczności przerywania czynności
dotychczas wykonywanej (np. obsługa zdarzenie w trybie
nagłym) i powrót do zawieszonej czynności bez utraty
danych, kontekstu itp.
Wszystkie błędy niewypełnienia pól obligatoryjnych oraz
błędnego wypełnienia muszą być prezentowane w jednym
komunikacie, z możliwością szybkiego przejścia do tego
miejsca aplikacji(np. poprzez odpowiedni link), gdzie te błędy
wystąpiły.
TAK
TAK
TAK
6.
Moduł musi umożliwić wyróżnianie pól:
TAK
7.
- których wypełnienie jest wymagane,
TAK
8.
- przeznaczonych do edycji,
TAK
9.
- wypełnionych niepoprawnie.
TAK
10.
11.
12.
13.
14.
Definiowanie kolejek oczekujących zgodnie z wymaganiami
płatnika:
- kolejki oczekujących do komórek organizacyjnych
Zamawiającego,
- kolejki oczekujących do procedur medycznych lub
świadczeń wysokospecjalistycznych zdefiniowanych przez
płatnika.
System musi umożliwiać prowadzenie kolejek oczekujących
Zamawiającego.
System musi umożliwiać prowadzenie wykazu osób
oczekujących w kolejce Zamawiającego.
85
TAK
TAK
TAK
TAK
TAK
15.
16.
17.
18.
19.
20.
Możliwość planowania daty z dokładnością do dnia lub
tygodnia (w przypadku odległego terminu realizacji
świadczenia).
Przyporządkowanie oczekujących do jednej z kategorii
medycznych (przypadki pilne/przypadki stabilne).
Rejestrowanie przypadków zmian terminu udzielenia
świadczenia wraz z przyczyną zmiany.
Możliwość zbiorczego przenoszenia oczekujących pomiędzy
kolejkami:
- wszystkich aktywnych pozycji,
- wybranych oczekujących.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
TAK
TAK
TAK
TAK
TAK
Wskazanie tych definicji kolejek oczekujących, które po
wczytaniu aneksu do umowy posiadają nieaktualne
21. informacje o kodzie komórki wg NFZ wraz z możliwością
automatycznej aktualizacji kodu komórki wg NFZ na
podstawie aktualnych zapisów w umowie z NFZ.
Generowanie statystyk kolejek z podziałem na przypadki
22.
pilne i stabilne:
23. - liczba oczekujących,
24.
TAK
- szacunkowy czas oczekiwania w kolejce,
- średni rzeczywisty czas oczekiwania w kolejce (zgodnie z
algorytmem opublikowanym w rozporządzeniu).
Generowanie i eksport komunikatów XML w aktualnie
obowiązujących wersjach z zakresu sprawozdawczości
związanej z kolejkami oczekujących:
- komunikat LIOCZ – komunikat szczegółowy o kolejkach
oczekujących,
- komunikat KOL – komunikat o kolejkach oczekujących do
świadczeń wysokospecjalistycznych.
Import komunikatu „potwierdzeń odbioru” danych o kolejkach
oczekujących.
Wydruk listy oczekujących z uwzględnieniem poniższych
kryteriów:
- rodzaj kolejki (do komórki organizacyjnej, do procedury
medycznej/świadczenia wysokospecjalistycznego),
- kod kolejki,
- stan wpisu w kolejce (aktywne, wykreślone, zakończone
realizacją),
- kategoria medyczna (pilny, stabilny),
86
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
35.
- data wpisu (od .. do ..),
TAK
36.
37.
- data planowanej realizacji (od .. do ..),
- data skreślenia z kolejki (od .. do ..).
TAK
TAK
Deklaracje POZ
Lp.
1.
2.
3.
4.
Wymaganie (Deklaracje POZ)
Moduł musi działać w architekturze trójwarstwowej.
Interfejs użytkownika musi być dostępny z poziomu
przeglądarki internetowej i nie może wymagać instalowania
żadnego dodatkowego oprogramowania na stacjach
klienckich (system nie może wymagać korzystania ze
specjalnych programów klienckich technologii typu Citrix,
VNC, innych, w celu realizacji wymagań funkcjonalnych).
Moduł musi umożliwić pracę z poziomu najbardziej
popularnych przeglądarek, co najmniej MS Internet Explorer,
Google Chrome i Mozilla Firefox, Opera.
Moduł musi umożliwiać wykonanie nowej operacji w
systemie bez konieczności przerywania czynności
dotychczas wykonywanej (np. obsługa zdarzenie w trybie
nagłym) i powrót do zawieszonej czynności bez utraty
danych, kontekstu itp.
Wymagane Oferowane
TAK
TAK
TAK
TAK
5.
Wszystkie błędy niewypełnienia pól obligatoryjnych oraz
błędnego wypełnienia muszą być prezentowane w jednym
komunikacie, z możliwością szybkiego przejścia do tego
miejsca aplikacji(np. poprzez odpowiedni link), gdzie te błędy
wystąpiły.
TAK
6.
Moduł musi umożliwić wyróżnianie pól:
TAK
7.
- których wypełnienie jest wymagane,
TAK
8.
- przeznaczonych do edycji,
TAK
9.
- wypełnionych niepoprawnie.
TAK
10. Import umów w rodzaju POZ
TAK
11. Ewidencja deklaracji POZ/KAOS
TAK
12.
- Deklaracje do lekarza rodzinnego,
TAK
13.
- Deklaracje do pielęgniarki,
TAK
14.
- Deklaracje do położnej,
TAK
15.
- Deklaracje z zakresu medycyny szkolnej,
- Kompleksowa ambulatoryjna opieka nad pacjentem z
16.
cukrzycą,
87
TAK
TAK
17.
- Kompleksowa ambulatoryjna opieka nad pacjentem
zarażonym HIV
18. Ewidencja porad POZ
Generowanie i eksport komunikatów XML w aktualnie
19. obowiązujących wersjach z zakresu sprawozdawczości
związanej z deklaracjami POZ/KAOS
Komunikat DEKL – komunikat szczegółowy deklaracji
20.
POZ/KAOS
Komunikat ZBPOZ – komunikat szczegółowy danych
21.
zbiorczych o świadczeniach udzielonych w ramach POZ
22.
23.
24.
25.
26.
27.
28.
29.
Import komunikatów zwrotnych XML w obowiązujących
wersjach
Import komunikatu „potwierdzeń odbioru” danych
przesłanych komunikatami DEKL i ZBPOZ
Import komunikatu potwierdzeń do deklaracji POZ/KAOS
(komunikat P_DEK)
Import komunikatu zwrotnego z weryfikacji deklaracji
POZ/KAOS (komunikat P_WDP)
Import komunikatu zwrotnego rozliczenia deklaracji
POZ/KAOS (komunikat Z_RDP)
Przegląd potwierdzeń deklaracji POZ/KAOS
Przegląd weryfikacji deklaracji POZ/KAOS z możliwością
zbiorczego wycofania deklaracji, które nie zostały zaliczone
przez NFZ
Generowanie rachunków deklaracji POZ
Generowanie i wydruk załączników i sprawozdań POZ
zgodnie z wytycznymi płatnika
31. Załącznik nr 4 do umowy POZ
30.
Załącznik nr 5 do umowy POZ w zakresie: nocna i
świąteczna opieka lekarska i pielęgniarska w POZ
Załącznik nr 6 do umowy POZ w zakresie: transport
33.
sanitarny w POZ
Półroczne sprawozdanie z wykonanych badań
34.
diagnostycznych
32.
88
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
Rehabilitacja
Lp.
Wymaganie (Rehabilitacja)
Wymagane Oferowane
1.
Moduł musi działać w architekturze trójwarstwowej.
TAK
2.
Interfejs użytkownika musi być dostępny z poziomu
przeglądarki internetowej i nie może wymagać instalowania
żadnego dodatkowego oprogramowania na stacjach
klienckich (system nie może wymagać korzystania ze
specjalnych programów klienckich technologii typu Citrix,
VNC, innych, w celu realizacji wymagań funkcjonalnych).
TAK
3.
4.
5.
Moduł musi umożliwić pracę z poziomu najbardziej
popularnych przeglądarek, co najmniej MS Internet Explorer,
Google Chrome i Mozilla Firefox, Opera.
Moduł musi umożliwiać wykonanie nowej operacji w
systemie bez konieczności przerywania czynności
dotychczas wykonywanej (np. obsługa zdarzenie w trybie
nagłym) i powrót do zawieszonej czynności bez utraty
danych, kontekstu itp.
Wszystkie błędy niewypełnienia pól obligatoryjnych oraz
błędnego wypełnienia muszą być prezentowane w jednym
komunikacie, z możliwością szybkiego przejścia do tego
miejsca aplikacji(np. poprzez odpowiedni link), gdzie te błędy
wystąpiły.
TAK
TAK
TAK
6.
Moduł musi umożliwić wyróżnianie pól:
TAK
7.
- których wypełnienie jest wymagane,
TAK
8.
- przeznaczonych do edycji,
TAK
9.
- wypełnionych niepoprawnie.
TAK
10. Konfiguracja modułu
TAK
System musi umożliwiać definiowanie listy zdarzeń
medycznych/elementów leczenia dla miejsca wykonania
System musi umożliwiać zarządzanie słownikiem stanowisk i
12.
urządzeń rehabilitacyjnych
System umożliwia zarządzanie grafikami i terminarzami
13.
stanowisk i urządzeń rehabilitacyjnych
11.
TAK
TAK
TAK
14. System musi umożliwiać realizację zabiegów w warunkach:
TAK
15.
- rehabilitacji ambulatoryjnej
TAK
16.
- rehabilitacji oddziału dziennego
TAK
17.
- rehabilitacji stacjonarnej
TAK
89
System musi umożliwiać prowadzenie słownika rozpoznań
18. kwalifikujących do stopnia pilności „pilny”, wg Klasyfikacji
chorób ICD – rewizja 10 dla rehabilitacji medycznej
System musi umożliwić określenie warunków dostępności
19. elementu leczenia (zabiegu), poprzez przypisanie
odpowiednich kategorii zasobów typu:
TAK
TAK
20.
- personel,
TAK
21.
- pomieszczenie,
TAK
22.
- stanowisko rehabilitacyjne.
TAK
23.
System musi umożliwić określenie standardowego czasu
trwania porad, wizyt i zabiegów
TAK
System musi umożliwić obsługę skorowidza pacjentów
modułów obsługi Zakładu/Działu Rehabilitacji
System umożliwia definiowanie jednostek, które mają dostęp
25.
do funkcjonalności- Rehabilitacji
26. Planowanie zabiegów
24.
System musi umożliwiać wprowadzenie nowego programu
rehabilitacji dla pacjenta. Program jest elementem
27.
skierowania i jest listą zabiegów do wykonania z określoną
kolejnością, warunkami i krotnością wykonania.
System musi mieć możliwość podpowiadania trybu
28.
wykonania na podstawie rozpoznania ze skierowania
System musi umożliwiać przypisanie do programu lekarza
29.
prowadzącego oraz terapeuty prowadzącego
30.
31.
32.
33.
34.
35.
System musi umożliwiać planowanie elementów leczenia
programu rehabilitacji w terminarzach terapeutów,
pomieszczeń, stanowisk rehabilitacyjnych i w karcie
zabiegowej pacjenta
System musi umożliwiać planowanie porad kontrolnych, w
ramach programu, do lekarza prowadzącego
System musi umożliwiać „ręczne” planowanie zabiegów,
polegające na wskazaniu w terminarzu konkretnego wolnego
terminu
System umożliwia anulowanie całego programu lub
wybranych, niezrealizowanych zabiegów z jednoczesnym
anulowaniem rezerwacji zasobów
System musi umożliwiać wgląd do terminarza gabinetu na
dany dzień
System musi umożliwiać wgląd do terminarza terapeuty na
90
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
dany dzień
System umożliwia wprowadzenie rozszerzonej postaci
skierowania. Oprócz standardowych elementów skierowania,
skierowanie na rehabilitację zawiera :
36. - dane rozpoznania ("rehabilitacyjnego")
- dane programu rehabilitacji (zabiegów)
- dodatkowe dane o istotnych wynikach badań i wykonanych
zabiegach i operacjach.
37.
System umożliwią wystawienie skierowania wewnętrznego
(zlecenia) z dowolnego Gabinetu / Oddziału
TAK
TAK
System umożliwia wprowadzenie uwag do zlecenia oraz
38. daje możliwość modyfikacji uwag z oznaczeniem daty
obowiązywania danej uwagi
TAK
39. System umożliwia definiowanie grupowych pozycji zabiegu.
TAK
40. System umożliwia definiowane schematów planu leczenia
System umożliwia modyfikację programu rehabilitacyjnego
41.
polegającą na zmianie terminu danego zabiegu
System umożliwia modyfikację programu rehabilitacyjnego
42.
polegającą na dodaniu nowej pozycji programu .
TAK
Planowanie pozycji programu z uwzględnieniem preferencji
pacjenta .
System umożliwia zdefiniowanie i zapamiętanie preferencji
pacjenta do planowania terminów zabiegów w zakresie:
• możliwości ustalenia preferowanych godzin realizacji
(domyślnych dla dowolnego dnia tygodnia, określonych dni
tygodnia).
• możliwości ustalenia "nieodpowiadających" godzin
43.
realizacji (domyślnych dla dowolnego dnia tygodnia,
określonych dni tygodnia).
• oznaczenia dowolności planowania godzin dla dowolnych
lub wybranych dni tygodnia
• oznaczenia blokady planowania dla dowolnych lub
wybranych dni tygodnia
Ustawienia mogą być definiowane dla wszystkich lub
wybranych tygodni
System umożliwia definiowane schematów preferencji
44.
pacjenta
TAK
TAK
TAK
TAK
45. System umożliwia przeplanowanie zabiegów
TAK
46. Realizacja zabiegów
TAK
91
System umożliwia dostęp do bieżącego programu
rehabilitacji pacjenta
System umożliwia oznaczenie realizacji zabiegu uprzednio
48.
zaplanowanej lub z pominięciem planowania
47.
49.
50.
51.
52.
53.
54.
55.
56.
57.
System musi umożliwić lekarzowi i terapeucie bieżące
tworzenie i uzupełnianie dokumentacji medycznej pacjenta,
System musi umożliwić dostęp do dokumentacji medycznej
pacjenta
System musi umożliwiać lekarzowi wystawianie skierowań,
recept i zleceń
System musi umożliwiać ewidencję zrealizowanych
świadczeń
System musi umożliwiać ewidencję czasu trwania porady i
zabiegu
potwierdzenie wykonania zabiegu w karcie zabiegowej
pacjenta
System musi umożliwiać dostęp (wgląd) do wszystkich
wcześniejszych programów rehabilitacji pacjenta
System musi umożliwiać wgląd do wszystkich
wcześniejszych zleceń i wyników badań pacjenta
System musi umożliwić ewidencję wykonania zabiegów w
postaci Karty zabiegów rehabilitacyjnych z możliwością
zbiorczego oznaczenia wykonania
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
58. System musi umożliwić graficzną prezentację:
TAK
59.
- oznaczenie wykonania zabiegu
TAK
60.
- oznaczenia niewykonania zabiegu
TAK
61.
- oznaczenie nieautoryzowanego zabiegu
TAK
System umożliwia oznaczenie realizacji zabiegów typu
'Trening rehabilitacyjny'. Prezentowana jest Karta
62.
treningowa, która jest listą parametrów treningowych oraz
możliwy jest jej wydruk
TAK
System wspomaga ewidencję wykonań zabiegów poprzez
63. wykorzystanie czytników kodów kreskowych do identyfikacji
pacjenta, oraz zrealizowanych świadczeń.
TAK
64.
System musi umożliwiać przypisanie kodu kreskowego do
elementu leczenia (zabiegu).
65. System musi umożliwiać dodanie uwag do realizacji zabiegu.
System musi umożliwiać potwierdzenie wykonania zabiegu
66.
w karcie zabiegowej pacjenta.
92
TAK
TAK
TAK
93
Pracownia Patomorfologii
Lp.
Wymaganie (Pracownia Patomorfologii)
Dostęp do katalogu pacjentów w ramach podsystemów Ruch
Chorych i Przychodnia Oprogramowania Zamawiającego.
2. Rejestracja badania:
3. - rejestrowanie zleceń wewnętrznych,
1.
- rejestrowanie zleceń zewnętrznych (z innych szpitali,
pacjentów komercyjnych, rejestracja danych skierowania),
- możliwość uzupełnienia/poprawienia niepoprawnie
5. wprowadzonych danych przez jednostki zlecające np. okolice
pobrania, rodzaj materiału,
6. - obsługa obiegu zleceń i wyników „do konsultacji”.
7. Przyjęcie próbki:
8. - możliwość podziału materiału na oddzielne próbki,
- sumaryczne zbieranie wyników badań z poszczególnych
9.
badań wykonywanych na próbkach,
10. rejestracja i zarządzanie wynikami:
- możliwość ewidencji kilku rozpoznań (z podaniem numeru
11.
próbki materiału, którego to rozpoznanie dotyczy:
12. - ewidencja wg klasyfikacji ICD 10,
13. - ewidencja wg klasyfikacji SNOMED.
- możliwość stosowania tekstów standardowych w opisach
14.
wyników (formularze opisowe),
- ewidencja personelu wykonującego: lekarza wykonującego,
15.
sprawdzającego oraz konsultującego
- autoryzacja wyniku oraz wydruk pisma wg zdefiniowanego
16.
szablonu,
17. - przegląd i odpisy wyników badań.
18. - możliwość korzystania z klasyfikacji standardowych:
19. - rozpoznania wg ICD10,
20. - SNOMED,
21. - lokalizacje,
22. - rozpoznania mikroskopowe łacińskie,
23. - PAP,
24. - system Bethesda,
- rozpoznania sekcyjne (choroba zasadnicza, powikłania,
25.
schorzenia dodatkowe, przyczyna zgonu).
4.
94
Wymagane Oferowane
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
Możliwość obsługi badań z użyciem dedykowanych
formularzy, w tym:
27. - biopsje cienkoigłowe,
28. - cytologia złuszczeniowa,
29. - konsultacja preparatów,
30. - badanie śródoperacyjne,
31. - badanie FISH,
32. - badanie antygeny powierzchniowe
26.
TAK
TAK
TAK
TAK
TAK
TAK
TAK
33. - badanie DNA
34. - badanie histopatologiczne,
TAK
TAK
35. - badanie cytologiczne,
- cytologia ginekologiczna (klasyfikacja Bethesda, PAP, opis
36.
makroskopowy, opis mikroskopowy, zalecenia).
37. - formularz sekcji zwłok (sekcja zwłok, protokół sekcyjny):
38. - badanie sekcyjne noworodka,
39. - badanie sekcyjne osoby dorosłej.
40. Statystyka:
41. - zestawienia ilościowe (sumaryczne i analityczne):
42. - wykonanych badań wg rodzaju,
43. - wykonanych badań wg personelu,
44. - wykonanych badań wg jednostki kierującej.
- zestawienia badań na potrzeby rozliczeń z kontrahentami
45.
(sumarycznie i analitycznie).
46. Obsługa ksiąg badań:
TAK
47. - przegląd, wydruk,
- możliwość definiowania niezależnych ksiąg dla
48.
poszczególnych rodzajów badań.
TAK
95
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
Zakażenia Szpitalne
Lp.
Wymaganie (Zakażenia szpitalne)
Moduł musi realizować wspomaganie pracy personelu w
zakresie kontroli występowania zakażeń szpitalnych i
1.
zapobiegania tym zakażeniom, zgodnie z odpowiednimi
przepisami prawa. W szczególności:
- prowadzenie Rejestru Kart Rejestracji Zakażenia
2.
Zakładowego,
- wydruki na podstawie danych Rejestru Kart Rejestracji
3.
Zakażenia Zakładowego,
- prowadzenie Rejestru Kart Rejestracji Drobnoustroju
4.
Alarmowego,
- wydruki na podstawie danych Rejestru Kart Rejestracji
5.
Drobnoustroju Alarmowego,
- prowadzenie Rejestru zgłoszeń zachorowania na chorobę
6.
zakaźną,
- wydruki na podstawie danych Rejestru zgłoszeń
7.
zachorowania na chorobę zakaźną,
- prowadzenie Rejestru zgłoszeń zachorowania (podejrzenia
8. zachorowania) na AIDS lub zgłoszenia zakażenia
(podejrzenia zakażenia) HIV,
- wydruki na podstawie danych Rejestru zgłoszeń
9. zachorowania (podejrzenia zachorowania) na AIDS lub
zgłoszenia zakażenia (podejrzenia zakażenia) HIV,
- prowadzenie Rejestru zgłoszeń zachorowania (podejrzenia
10.
zachorowania) na chorobę przenoszoną drogą płciową,
- wydruki na podstawie danych Rejestru zgłoszeń
11. zachorowania (podejrzenia zachorowania) na chorobę
przenoszoną drogą płciową,
- prowadzenie Rejestru zgłoszeń zachorowania (podejrzenia
zachorowania) na gruźlicę,
- wydruki na podstawie danych Rejestru zgłoszeń
13.
zachorowania (podejrzenia zachorowania) na gruźlicę,
- prowadzenie Rejestru zgłoszeń zgonu (podejrzenia zgonu) z
14.
powodu choroby zakaźnej,
- wydruki na podstawie danych Rejestru zgłoszeń zgonu
15.
(podejrzenia zgonu) z powodu choroby zakaźnej,
12.
96
Wymagane Oferowane
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
- prowadzenie Rejestru obserwacji potencjalnych źródeł
16. zakażenia (wkłucia obwodowe, wkłucia centralne, cewniki,
respiratory, operacje, infekcje),
17. - prowadzenie Rejestru podejrzeń ognisk epidemicznych,
18.
- wydruki na podstawie danych Rejestru podejrzeń ognisk
epidemicznych,
- prowadzenie Rejestru potwierdzonych ognisk epidemicznych
,
- wydruki na podstawie danych Rejestru potwierdzonych
20.
ognisk epidemicznych,
- raporty zgodne z odpowiednim Rozporządzeniem Ministra
21.
Zdrowia,
22. - analizy ilościowe zakażeń zakładowych,
- analizy kosztów podań antybiotyków i badań
23.
mikrobiologicznych związanych z zakażeniami zakładowymi.
Współpraca z systemem „Ruch Chorych” Zamawiającego
oraz centralnym systemem „Laboratorium” w ramach
24.
Oprogramowania Zamawiającego, w zakresie podań
antybiotyków i zleceń badań do pracowni mikrobiologicznej:
19.
- monitorowanie o konieczność założenia Indywidualnej Karty
25. Zakażeń Szpitalnych w przypadku podania antybiotyku
powyżej 3 dni,
- monitorowanie o konieczność założenia Indywidualnej Karty
26. Zakażeń Szpitalnych w przypadku wystąpienia patogenu w
badaniu mikrobiologicznym,
- szybki podgląd listy pacjentów dla nowo założonych: kart
27. obserwacji, kart zakażenia, kart drobnoustroju,
alertpatogenów.
97
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
Dializy
Lp.
Wymaganie (Dializy)
Wymagane Oferowane
1. Zarządzanie konfiguracją i planowaniem usług:
2. prowadzenie katalogu usług wykonywanych w Stacji Dializ,
prowadzenie listy dializatorów z możliwością przypisywanie do
3. nich pacjentów i konfigurowaniem liczby reutylizacji
dializatora,
TAK
TAK
4. prowadzenie listy aparatów,
5. prowadzenie listy personelu medycznego,
TAK
TAK
generacja grafików (terminarzy) z dokładnością do sal i
dziennych tur dializ,
wprowadzanie planu badań laboratoryjnych dla grupy
7.
pacjentów stałych w zadanym okresie, np. roku,
prowadzenie listy biorców w celu generowania skierowań na
8.
dodatkowe badania zgodnie z planem badań.
9. przegląd i modyfikacja danych pacjenta:
dostęp do skorowidza pacjentów z pozostałymi podsystemami
10. medycznymi: Ruch Chorych i Przychodnia Oprogramowania
Zamawiającego.
wyszukiwanie pacjentów w skorowidzu wg różnych
11.
parametrów.
6.
TAK
TAK
TAK
TAK
TAK
TAK
TAK
12. rejestracja i modyfikacja grup danych o pacjentach, w tym:
13. - dane osobowe,
TAK
TAK
14. - dane o ubezpieczycielu,
15. - dane o zatrudnieniu,
TAK
TAK
16. - dane o dokumentacji i miejscu jej składowania,
- dane o dializach z podziałem na dane ogólne, dane o
antygenach i przeciwciałach, dane o dostępie naczyniowym,
17.
dane o aktualnym dializatorze, dane o aktualnym statusie na
liście biorców,
TAK
- wskaźniki „wydializowania” (wskaźnik używany przez stację
może być wybrany z listy dostępnych wskaźników)
możliwość ograniczenia zakresu wprowadzanych danych w
19.
przypadku dializ ostrych,
przegląd danych archiwalnych pacjenta i śledzenie historii
20.
zmian,
21. przegląd kontaktów pacjenta ze Stacją Dializ, w zakresie:
22. - wizyt w Stacji Dializ,
18.
98
TAK
TAK
TAK
TAK
TAK
TAK
- usług wykonanych pacjentowi w Stacji Dializ z
uwzględnieniem personelu wykonującego,
24. - pobytów na oddziałach szpitalnych,
25. - wyników badań.
26. wprowadzanie zleceń na usługi Stacji Dializ:
- możliwość realizacji zleceń wewnętrznych z innych
27. jednostek organizacyjnych Zamawiającego (w przypadku
systemu zintegrowanego),
23.
- możliwość wprowadzania zleceń zewnętrznych (skierowań z
innych podmiotów).
wspomaganie planowania dializ w oparciu o grafiki
29.
(terminarze) sal i tur:
- rezerwacja wolnych terminów na dializy w oparciu o
30.
dostępne aparaty i dializatory,
- możliwość kopiowania zaplanowanych dializ dla pacjentów
31.
z tygodnia bieżącego na kolejny,
32. przegląd listy zaplanowanych dializ i badań laboratoryjnych,
33. wizualizacja (różne kolory) stanu realizacji dializy
34. możliwość anulowania zaplanowanych wizyt,
35. przegląd i wydruk listy zarejestrowanych pacjentów,
36. możliwość pominięcia planowania w przypadku dializ ostrych.
automatyczna generacja zleceń na badania laboratoryjne dla
37.
pacjentów stałych w oparciu o wprowadzony plan badań,
automatyczna generacja zleceń na badania laboratoryjne dla
38.
biorców w oparciu o wprowadzony plan badań,
39. wspomaganie realizacji wizyty (dializy):
28.
dostęp do wszystkich kategorii danych o pacjencie
40. zaewidencjonowanych w systemie, w tym danych z
poprzednich wizyt,
41. ewidencja danych o przebiegu wizyty:
42. - czas trwania wizyty,
43. - wykonane procedury,
44. - podane leki,
45. - zużyte materiały (w tym dializatory),
46. - personel wykonujący dializę.
ewidencja parametrów przebiegu dializy z możliwością
47. kopiowania z poprzedniej wizyty, z podziałem na grupy
danych o:
48. - wykonaniu dializy,
99
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
49. - pacjencie,
TAK
50. - programie dializy,
51. - płynie,
TAK
TAK
52. - wkłuciach,
53. - ultrafiltracji.
TAK
TAK
54. wprowadzanie zleceń na inne usługi,
55. ewidencja danych do rozliczeń z płatnikiem,
TAK
TAK
56. ewidencja wydanych skierowań i innych dokumentów.
57. prowadzenie statystyki i dokumentacji medycznej:
TAK
TAK
58. prowadzenie ksiąg, rejestrów:
59. - Księga Dializ
TAK
TAK
60. - Rejestr Biorców, także w postaci elektronicznej
możliwość wykorzystania zdefiniowanych szablonów
61.
wydruków:
62. - Przebieg hemodializy,
- Karta informacyjna o wykonanych hemodializach (dla
63.
pacjentów nie będących pacjentami stałymi),
- Karta informacyjna o sposobie dializowania (dla pacjentów
64.
planujących czasowe dializowanie w innym miejscu).
65. możliwość definiowania własnych szablonów wydruków.
TAK
66. czynności analityczno – sprawozdawcze:
67. możliwość wykorzystania raportów wbudowanych, w tym:
TAK
TAK
68. - liczba wykonanych hemodializ,
69. - zestawienie wykonanych hemodializ.
TAK
TAK
70. możliwość definiowania własnych wykazów (moduł Wykazy).
71. integracja z innymi modułami systemu medycznego:
TAK
TAK
- współpraca z modułem Apteczka Oddziałowa w zakresie
72. ewidencji zużytych leków i materiałów (w tym dializatorów)
oraz aktualizacji stanów magazynowych,
TAK
- współpraca z pozostałymi podsystemami medycznymi w
zakresie wzajemnego udostępniania danych
73.
o pacjentach, danych zlecenia i danych o jego wykonaniu (w
tym centralnym Laboratorium),
- współpraca z modułem Dokumentacji Medycznej w zakresie
74. wykorzystania formularzy zaprojektowanych przez
użytkownika,
75. - współpraca z modułami Rachunku Kosztów Leczenia.
100
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
Transport
Lp.
Wymaganie (Transport)
Wymagane Oferowane
Gromadzenie danych o zleceniach na transport medyczny,
rejestrowanych w oddziałach szpitalnych (wymagana jest
1.
integracja z podsystemem Ruch Chorych Oprogramowania
Zamawiającego) w minimalnym zakresie informacji:
TAK
2.
3.
TAK
TAK
- Pacjent,
- Usługa transportowa,
- Miejsce docelowe transportu (system wyznacza miejsce
4. docelowe transportu jako adres zamieszkania pacjenta po
zaznaczeniu opcji transport osobowy),
- Planowany czas realizacji usługi.
Rejestracja zleceń na transport medyczny bez uwzględnienia
6.
pacjenta.
Odnotowanie realizacji usługi transportowej w minimalnym
7.
zakresie informacji:
8. - Umowa na podstawie której realizowana jest usługa,
9. - Data wykonania usługi,
10. - Czas realizacji usługi,
11. - Ilość km,
12. - Wartość / h,
13. - Wartość / km.
14. Odnotowanie przebytej trasy tam i z powrotem.
Rozliczanie wykonanej usługi zgodnie z warunkami zawartej
15.
umowy na usługi transportowe
System udostępnia zestawienia z wykonanych usług
16. transportowych z podziałem na: umowy, ośrodki kosztów,
usługi, kontrahentów.
5.
101
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
Sprzedaż Usług Medycznych
Lp.
Wymaganie (Sprzedaż Usług Medycznych)
Wymagane Oferowane
1. Formułowanie oferty sprzedaży Zamawiającego:
wprowadzanie struktury placówek medycznych
2.
Zamawiającego,
TAK
3. wprowadzanie listy usług (oferta jednostek organizacyjnych),
4. wprowadzenie danych usługi:
TAK
TAK
5.
6.
- wymagalność skierowania,
- warunki dostępności,
TAK
TAK
TAK
- kody w umowach w zależności od płatnika np.
przekodowanie usługi na
8. Grupowanie usług,
9. Wprowadzanie cenników:
10. - Okres obowiązywania,
11. - Godziny dostępności,
- Możliwość definicji cenników standardowych i specjalnych
12.
(np. na dni świąteczne),
13. - Miejsca realizacji,
7.
14. - Możliwość przyporządkowania cennika do personelu,
15. Wprowadzanie rabatów:
16. - Rabaty ogólne do wykorzystania bez ograniczeń,
17. - Rabaty prywatne – przyporządkowane do osoby,
18. - Rabaty do placówki,
Obsługa głównego skorowidza pacjentów – wymagana
19.
integracja
Konstruowanie produktów (szablonów do wykorzystania w
20.
umowach):
21. wprowadzanie danych podstawowych produktu,
wprowadzanie zakresów usług medycznych w ramach
produktu,
23. wprowadzanie usług medycznych w ramach zakresu,
24. wprowadzanie trybów i terminów płatności dla zakresów:
25. - abonament, (niezależnie od wykonanych usług),
26. - FFS (Fee For Service czyli za każde wykonanie usługi),
27. - współpłatność w ramach FFS,
22.
28. - płatności mieszane.
29. Grupowanie zakresów usług (benefitplany),
102
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
30. Wprowadzanie limitów dla zakresów:
TAK
31. - ilościowe,
32. - kwotowe.
TAK
TAK
33. Ewidencja i obsługa umów:
34. obsługa różnego typu umów:
TAK
TAK
35. obsługa umów na sprzedaż usług medycznych:
36. ewidencja różnego typu umów:
TAK
TAK
37. - umowy ubezpieczeniowe,
38. - umowy abonamentowe,
TAK
TAK
- umowy z innymi ZOZ-ami, Indywidualnymi Praktykami
Lekarskimi,
40. wprowadzanie danych podstawowych umowy,
41. przypisywanie produktu do umowy,
42. definiowanie rabatów dla umowy,
wprowadzanie list uprawnionych do grup zakresów
43.
(benefitplanów):
44. - beneficjenci,
45. - subbeneficjenci.
46. import listy beneficjentów z pliku,
tworzenie produktu dedykowanego dla umowy (wyodrębnienie
47.
umowy z szablonu produktu),
definiowanie wzorów faktur i załączników do faktur dla
48.
umowy,
49. rozliczenia umów:
- generowanie harmonogramów płatności umowy w oparciu o
50.
dane zakresów umowy,
39.
103
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
- generowanie faktur i załączników do faktur płatnych
abonamentowo w oparciu o zdefiniowane wzorce i dane umowy,
- generowanie faktur i załączników do faktur płatnych za
52. wykonanie w oparciu o zdefiniowane wzorce i dane umowy oraz
dane o wykonanych usługach.
53. współpraca z modułem Finanse-Księgowość:
- eksport wygenerowanych faktur do modułu Rejestr Sprzedaży
54.
pakietu Finanse-Księgowość,
51.
55. Raporty i wykazy dotyczące sprzedaży.
TAK
TAK
TAK
TAK
TAK
104
Rejestr Sprzedaży
Lp.
Wymaganie (Rejestr Sprzedaży)
Możliwość obsługi wielu rejestrów sprzedaży (Centralny
Rejestr Sprzedaży),
Dostęp do wszystkich rejestrów sprzedaży w placówkach
2.
medycznych Zamawiającego,
Możliwość pracy rejestru sprzedaży w kontekście placówki
medycznej Zamawiającego (na wydruku umieszczane
3.
powinny być oprócz danych Zamawiającego, także dane
placówki medycznej wystawiającej fakturę),
1.
Wymagane Oferowane
TAK
TAK
TAK
4. Dostęp do katalogu kontrahentów i pracowników,
Dostęp do głównego skorowidza pacjentów Oprogramowania
5.
Zamawiającego,
Prowadzenie katalogów (cenników) sprzedawanych
6.
składników:
7. - materiałów przeznaczonych do odsprzedaży,
8. - świadczonych usług.
9. Definicja rejestrów sprzedaży,
Określenie sposobu numeracji dokumentów sprzedaży
(roczna lub miesięczna), w przypadku numeracji miesięcznej
10.
możliwość równoczesnej pracy w więcej niż jednym miesiącu
rozrachunkowym,
Wprowadzanie dokumentów sprzedaży z możliwością obsługi
11.
VAT:
TAK
12. - określenie formy płatności,
- określenie typu wystawianego dokumentu (faktura, faktura
13.
korygująca),
14. - określenie nabywcy (płatnika),
15. - określenie odbiorcy,
TAK
16.
- określenie zawartości faktury – wybór z cennika
sprzedawanych składników,
- automatyczne generowanie faktur w oparciu o dane o
wykonanych usługach medycznych z aplikacji medycznych
17.
(np. Recepcja, Gabinet, Pracownia) – dla każdej
zrealizowanej odpłatnie usługi medycznej,
- określenie rozdziału stosunku wpływów ze sprzedaży na
18.
ośrodki powstawania kosztów.
19. Wydruk dokumentu sprzedaży zgodnie z określonym typem
105
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
wystawianego dokumentu (faktura, faktura korygująca,
paragon zafiskalizowany, paragon niezafiskalizowany),
20. Możliwość współpracy z drukarkami fiskalnymi,
Możliwość wydruku zestawień na podstawie dokumentów
21.
sprzedaży:
22. - rejestru sprzedaży,
23. 24. 25.
zestawienia dokumentów sprzedaży,
zestawienia w podziale na sprzedane usługi,
- zestawienia przychodów wg ośrodków powstawania
kosztów i wg usług,
26. - zestawienia według nabywców.
27. Wystawianie faktur wewnątrzwspólnotowych.
106
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
Kasa
Lp.
Wymaganie (Kasa)
Możliwość obsługi wielu stanowisk kasowych (Centralny
Rejestr Kasowy),
Możliwość dedykowania stanowisk kasowych do placówek
2.
medycznych Zamawiającego,
Możliwość pracy kasy w kontekście placówki medycznej
Zamawiającego (na wydruku umieszczane powinny być
3.
oprócz danych Zamawiającego, także dane placówki
medycznej wystawiającej dokument kasowy),
1.
Wymagane Oferowane
TAK
TAK
TAK
4. Dostęp do raportów kasowych wszystkich stanowisk,
Dostęp do katalogu kontrahentów i pracowników
5.
zintegrowanego z systemem Rejestr Sprzedaży,
Dostęp do głównego skorowidza pacjentów Oprogramowania
6.
Zamawiającego,
7. Wprowadzanie dokumentów kasowych dla stanowisk:
- automatyczne tworzenie raportu kasowego – praca w
8.
kontekście raportu kasowego,
- automatyczne generowanie operacji kasowych na
stanowiskach dedykowanych dla placówki medycznej w
9. oparciu o wystawiane w niej automatycznie faktury (dla każdej
zrealizowanej odpłatnie usługi medycznej) – integracja z
fakturowaniem na poziomie placówki,
10. - operacje otwarcia/zamknięcia raportu kasowego,
11. - obsługa operacji gotówkowych
12. - obsługi operacji bezgotówkowych (np. karty płatnicze),
13. - obsługi operacji walutowych,
14. - wydruk dokumentów kasowych.
Możliwość dodania dodatkowych dekretów uzupełniających w
15.
raporcie kasowym przed jego zamknięciem
16. Wydruk raportu kasowego,
TAK
17. Bieżące i wsteczne zestawienia stanu kasy na podstawie:
18. - bieżących obrotów,
TAK
TAK
19. - raportów kasowych.
Możliwość zapisu wartościowego operacji kasowych na
kontach księgi głównej i ksiąg pomocniczych w module
20.
realizującym funkcjonalność w zakresie Finanse –
Księgowość.
TAK
107
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
21. Obsługa drukarek fiskalnych
TAK
108
Kalkulacja Kosztów Leczenia
Lp.
Wymaganie (Kalkulacja Kosztów Leczenia)
Wymagane Oferowane
1. Kalkulacja indywidualnych kosztów leczenia pacjenta:
możliwość automatycznego pobierania danych o pacjencie w
zakresie zrealizowanych mu świadczeń z aplikacji
2. medycznych (Przychodnia, Ruch Chorych i Apteczka
oddziałowa) – wymagana integracja z Oprogramowaniem
Zamawiającego:
TAK
3. 4. -
TAK
TAK
osobodni,
procedury,
5. - badania,
6. - leki.
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
7.
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:
- w zakresie kosztów leków – na poziomie cen leków z
konkretnej dostawy, w ramach której zrealizowano podania
8.
dla pacjenta (wymagana integracja z modułami Apteka,
Apteczka oddziałowa Oprogramowania Zamawiającego),
- w zakresie rzeczywistych kosztów świadczeń (z ostatniego
9. miesiąca, dla którego taka wycena istnieje – integracja z
modułem Koszty)
możliwość grupowania kosztowych kart pacjentów wg
10. zdefiniowanych kryteriów i prowadzenia analiz ekonomicznych
(np. wg jednostek chorobowych, produktów rozliczeniowych).
Możliwość definiowania wskaźników kosztowo11.
przychodowych w oparciu o predefiniowane funkcje dla:
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
12. ·
13. ·
pacjentów,
ośrodków powstawania kosztów,
TAK
TAK
14. ·
15. ·
jednostek chorobowych,
produktów kontraktowych.
TAK
TAK
Możliwość zestawienia przychodów i kosztów hospitalizacji na
poziomie:
17. ·
pojedynczego pacjenta,
16.
18. ·
kodu JGP,
TAK
TAK
TAK
109
19. ·
produktu jednostkowego,
TAK
20. ·
21. ·
produktu kontraktowego,
rozpoznania głównego.
TAK
TAK
Możliwość zestawienia statystyk kosztów pobytów z
podziałem na lekarzy prowadzących.
Możliwość szacunkowej kalkulacji dotychczasowych kosztów
pacjenta w trakcie trwania hospitalizacji w oparciu o dane
23.
historyczne lub zdefiniowane cenniki (w przypadku braku
danych historycznych).
22.
24.
Możliwość prezentacji kosztów zleceń do jednostek
zewnętrznych wg przyjętych cen umownych z daną jednostką
Możliwość porównania liczby osobodni wynikającej z danych
zaewidencjonowanych w systemie medycznym z liczbą
25.
osobni przesłaną do modułu Kalkulacji Kosztów Leczenia z
modułu Rachunek Kosztów.
110
TAK
TAK
TAK
TAK
Wycena Kosztów Normatywnych Świadczeń
Lp.
Wymaganie (Wycena Kosztów Normatywnych
Świadczeń)
Możliwość opisania normatywnych nakładów osobowych i
1. materiałowych niezbędnych do wykonania świadczenia lub
grupy JGP :
2.
3.
4.
5.
6.
- określenie nakładów materiałowych potrzebnych do
wykonania świadczenia lub grupy JGP na podstawie
zdefiniowanego słownika materiałów i słownika leków z
możliwością systemowej integracji w tym zakresie ze
słownikami użytkowanymi przez moduły realizujące
funkcjonalność w zakresie obsługi magazynu materiałów i
obsługi magazynu leków,
- określenie nakładów osobowych personelu
uczestniczącego w wykonaniu świadczenia,
- określenie ilości lub czasu pracy urządzenia użytego do
wykonania świadczenia oraz jednostkowego kosztu pracy
(dane alternatywnie pobierane z modułu Środki Trwałe i
wyliczane na podstawie amortyzacji) lub wpisanie wartości
kosztów w podziale na koszty rodzajowe ręcznie,
- możliwość wykorzystania do opisu świadczenia świadczeń
prostych wcześniej opisanych,
- możliwość wykorzystania do opisu JGP świadczeń
wcześniej opisanych, z określeniem miejsca wykonania,
- określenie średniej ilości osobodni w ramach JGP dla
oddziału rozliczającego dane JGP lub innego oddziału,
8. - możliwość wydruku przygotowanych opisów świadczeń,
7.
- możliwość automatycznego stworzenia opisu świadczenia
9. dla ośrodka na podstawie wzorca przygotowanego dla całego
zakładu.
Możliwość opisywania tych samych świadczeń w sposób różny
10.
dla każdego ośrodka wykonującego,
Możliwość aktualizacji kosztów nakładów materiałowych w
trybie miesięcznym poprzez:
12. - aktualizację „ręczną”,
- automatyczne przepisanie kosztów materiałów i leków z
13.
poprzedniego miesiąca,
14. - integrację w zakresie średnich cen dostaw materiałów i
11.
111
Wymagane Oferowane
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
leków z modułami realizującymi funkcjonalność w zakresie
obsługi magazynu materiałów i obsługi magazynu leków,
15. Uaktualnienie kosztów nakładów osobowych personelu,
16. Wyliczenie aktualnych sumarycznych kosztów normatywnych,
17. Wydruk wyliczonych kosztów normatywnych.
Raporty kontroli celowości wydania materiałów z magazynu
materiałów do miejsc udzielania świadczeń (w ramach
18. systemowej integracji z modułem realizującym funkcjonalność
obsługi magazynu i ewidencją udzielonych świadczeń w
miejscach udzielania,
Analizy porównawcze kosztów zaksięgowanych w kartotece
19. ośrodka powstawania kosztów FK z kosztami wynikającymi z
normatywu i zaewidencjonowanej ilości wykonań.
Możliwość określenia kosztu osobodnia do wyliczenia kosztu
20.
JGP poprzez:
21. - aktualizację „ręczną”,
- automatyczne przepisanie kosztów osobodnia z
22.
poprzedniego miesiąca,
- obliczenie kosztu osobodnia z na podstawie kosztów
rzeczywistych (do wyboru koszty bezpośrednie, całkowite,
23. wytworzenia, sprzedaży) z wybranych miesięcy, z
wyłączeniem wybranych kosztów szczegółowych , wg
określonego klucza podziału.
112
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
Elektroniczna Dokumentacja Medyczna
Lp.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Wymaganie (Elektroniczna Dokumentacja Medyczna) Wymagane Oferowane
Możliwość archiwizacji dokumentacji medycznej w
postaci elektronicznej.
Możliwość archiwizacji dokumentów złożonych,
wieloczęściowych i przyrostowych tj. księgi
Możliwość obsługi załączników do dokumentów
Możliwość rejestracji dokumentów elektronicznych
generowanych przez system medyczny w repozytorium
dokumentacji elektronicznej
Możliwość rejestracji dokumentów elektronicznych
utworzonych poza Oprogramowaniem Zamawiającego,
manualna rejestracja dokumentów zewnętrznych
Cyfryzacja dokumentu papierowego i dołączanie go do
dokumentacji elektronicznej
Dostęp do całości dokumentacji przechowywanej w EDM:
- z poziomu wbudowanych w systemy medyczne
mechanizmów
- z poziomu dedykowanego interfejsu
Możliwość exportu/importu dokumentu elektronicznego
do/z pliku w formacie XML
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
13.
Możliwość złożenia podpisu elektronicznego na
dokumencie oraz na zbiorze dokumentów
Możliwość złożenia podpisu elektronicznego na zbiorze
dokumentów
Możliwość znakowania czasem dokumentu
14.
15.
Możliwość wykonania kontrasygnaty
Możliwość weryfikacji podpisu
TAK
TAK
16.
17.
Możliwość weryfikacji integralności dokumentu
Możliwość wydruku dokumentu
TAK
TAK
18.
Możliwość wyszukiwania dokumentów za pomocą
zaawansowanych kryteriów oraz meta danych.
TAK
19.
Możliwość wersjonowania przechowywanych
dokumentów z dostępem do pełnej historii poprzednich
wersji.
TAK
20.
21.
Repozytorium EDM musi umożliwiać:
- rejestrację dokumentu
TAK
TAK
11.
12.
113
TAK
TAK
TAK
22.
- pobieranie dokumentów w formacie XML
TAK
23.
24.
- pobieranie dokumentów w formacie PDF
- wyszukiwanie materializacji dokumentów
TAK
TAK
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
Repozytorium EDM musi współdzielić z
Oprogramowaniem Zamawiającego:
- słownik jednostek organizacyjnych,
- rejestr użytkowników,
- rejestr pacjentów,
System uprawnień pozwalający na precyzyjne
definiowanie obszarów dostępnych dla danego
użytkownika pełniącego określoną rolę.
Możliwość zarządzania uprawnieniami dostępu do
określonych operacji w repozytorium. Przykłady
uprawnień systemowych: uruchomienie systemu,
zarządzanie uprawnieniami użytkowników, zarządzanie
parametrami konfiguracyjnymi, zarządzanie typami
dokumentów.
Możliwość zarządzania uprawnieniami do wykonywania
operacji na poszczególnych typach dokumentów w
ramach całej placówki lub poszczególnych jednostek
organizacyjnych. Przykłady uprawnień do dokumentów:
dodawanie dokumentów do repozytorium, odczyt
dokumentu, podpisywanie dokumentu, znakowanie
czasem dokumentu, import i eksport dokumentu,
anulowanie dokumentu, wydruk dokumentu itd.
Możliwość definiowania nowych typów dokumentów
obsługiwanych przez repozytorium dokumentów
elektronicznych.
Zakłada się także możliwość indeksowania dokumentów,
których elektroniczna postać nie jest przechowywana w
Oprogramowaniu - np. indeksowanie dokumentów
papierowych, obrazów radiologicznych przechowywanych
w PACS.
Indeksowane powinny być wszystkie wersje dokumentu
Indeks powinien uwzględniać rozdzielenie danych
osobowych od danych medycznych
Możliwość indeksowania dokumentów w celu łatwego jej
wyszukiwania wg zadanych kryteriów
114
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
37.
38.
Indeks dokumentacji powinien być zorientowany na
informacje o dokumencie: autor, data powstania, rozmiar,
typ, data powstania itp., oraz na informacje o zdarzeniach
System musi umożliwić udostępnianie dokumentacji:
TAK
TAK
39.
- w celu realizacji procesów diagnostycznoterapeutycznych w Zamawiającego
TAK
40.
41.
- pacjentom i ich opiekunom
- podmiotom upoważnionym (np. Prokurator)
TAK
TAK
43.
System powinien umożliwiać wymianę dokumentacji
medycznej w ramach Systemu Informacji Medycznej:
- bezpośrednio pomiędzy jednostkami ochrony zdrowia
44.
45.
- za pośrednictwem systemów regionalnych
- z wykorzystaniem platformy P1.
42.
115
TAK
TAK
TAK
TAK
System zbierania i przetwarzania informacji zarządczych
Lp.
Wymaganie (System Zbierania i Przetwarzania
Informacji Zarządczych)
1.
Wymagana ilość licencji aplikacji – nieograniczona ilością
użytkowników / stacji roboczych.
2.
3.
4.
5.
6.
Wymagania ogólne dotyczące architektury, logiki
działania systemu, środowiska i warunków
użytkowania
Wymaga się aby architektura systemu była zgodna z
zasadami budowy rozwiązań klasy Bussines Intelligence,
czyli aby system posiadał wydzielone repozytorium
hurtowni danych, wydzielone repozytorium metadanych,
warstwę analityczną, zasilanie danymi realizowane w
oparciu o mechanizmy ETL.
Wymagana jest możliwość posadowienia platformy
technicznej systemu na serwerowych systemach
operacyjnych min. MS Windows Serwer 2008, Redhat
Enterprise Linux.
Wymaga się, aby zasilanie hurtowni danych było
realizowane poprzez udokumentowane interfejsy, a
dokumentacja interfejsów będzie umożliwiała
dostosowanie systemów źródłowych do wymagań
wynikających z konieczności zasilenia hurtowni danych,
także w takim wypadku, gdy producentem systemów
źródłowych będzie inny podmiot niż dostawca systemu
analiz zarządczych i controlingu. Zakłada się że definicja
interfejsów będzie wskazywała między innymi na zakres
wymaganych danych i sposób ich udostępnienia.
Wszystkie funkcje dostarczanego oprogramowania
przeznaczone dla użytkowników końcowych mają być
dostępne poprzez interfejs WWW. Dostęp przez
przeglądarkę internetową nie może wymagać instalacji w
przeglądarce internetowej żadnych dodatkowych wtyczek.
Minimum obsługa w aktualnych wersjach przeglądarek MS
Internet Explorer, Google Chrome i Mozilla Firefox.
Poza wykorzystaniem wskazanych w wymaganiach
standardowych raportów, użytkownik musi mieć możliwość
definiowania własnych analiz opartych o dane
116
Wymagane Oferowane
TAK
TAK
TAK
TAK
TAK
TAK
gromadzone w hurtowni ( w zakresie danych
udostępnianych dla raportów standardowych).
7.
8.
9.
10.
11.
12.
13.
14.
15.
Wymaga się, aby system umożliwiał na poziomie warstwy
analitycznej prezentowanie wyników analiz także w
postaci graficznej np. w postaci wykresów adekwatnych do
rodzaju prezentowanych danych.
Wymaga się, aby na poziomie warstwy analitycznej
system zapewniał możliwość drążenia danych w ramach
powiązań występujących na poziomie modelu danych
udostępnianych poprzez zdefiniowane raporty
standardowe.
Wymagania funkcjonalne dla zakresu – Finanse i
Księgowość (Raporty standardowe)
Wymagany raport: Zestawienie aktywów i pasywów
Zamawiającego, wg stanu na koniec wybranego miesiąca
w danym roku, łącznie z możliwością wizualizacji stanów
wszystkich pozycji na koniec więcej niż jednego miesiąca.
Wymagany raport: Prezentacja bilansu Zamawiającego,
wg stanu na koniec wybranego miesiąca w danym roku
łącznie z możliwością wizualizacji stanów wszystkich
pozycji na koniec więcej niż jednego miesiąca.
Wymagany raport: Prezentacja zmian w kapitale własnym
Zamawiającego, wg stanu na koniec wybranego miesiąca
w danym roku.
Wymagany raport: Prezentacja rachunku wyniku w
obydwu wariantach (porównawczym i kalkulacyjnym) wg
stanu na koniec wybranego miesiąca w danym roku,
łącznie z możliwością wizualizacji stanów wszystkich
pozycji na koniec więcej niż jednego miesiąca.
Wymagany raport: Prezentacja przepływów pieniężnych
dla metody pośredniej wg stanu na dany rok.
Wymagany raport: Zestawienie zobowiązań i należności
Zamawiającego, wg stanu na koniec wybranego miesiąca
w danym roku, z możliwością wizualizacji wszystkich
pozycji na koniec więcej niż jednego miesiąca.
Wymagany raport: Zestawienie przychodów
117
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
16.
17.
18.
19.
20.
21.
22.
23.
24.
Zamawiającego, wg stanu na koniec wybranego miesiąca
w danym roku z możliwością wizualizacji wszystkich
pozycji na koniec więcej niż jednego miesiąca.
Wymagany raport: Wykaz stanów kont (saldo, obroty, BO,
persaldo) wg stanu na koniec wybranego miesiąca w
danym roku.
Wymagany raport: Prezentacja wartości wskaźników
rentowności wg stanu na koniec wybranego miesiąca w
danym roku. Prezentowane wskaźniki: rentowność
majątku, kapitału własnego, rentowność sprzedaży netto,
rentowność działalności operacyjnej, rentowność netto,
rentowność zasobów osobowych.
Wymagany raport: Prezentacja w postaci wykresu
obejmującego dany rok miesięcznych wartości
wskaźników rentowności.
Wymagany raport: Prezentacja wartości wskaźników
płynności finansowej wg stanu na koniec wybranego
miesiąca w danym roku. Prezentowane wskaźniki:
wskaźnik płynności bieżącej, wskaźnik płynności szybkiej,
wskaźnik płynności natychmiastowej, wskaźnik handlowej
zdolności kredytowej.
Wymagany raport: Prezentacja w postaci wykresu
obejmującego dany rok miesięcznych wartości
wskaźników płynności finansowej.
Wymagany raport: Prezentacja wartości wskaźników
analizy poziomej i pionowej wg stanu na koniec
wybranego miesiąca w danym roku. Prezentowane
wskaźniki: złota reguła bilansowa, złota reguła bilansowa
II, złota reguła finansowania.
Wymagany raport: Prezentacja w postaci wykresu
obejmującego dany rok miesięcznych wartości
wskaźników analizy poziomej i pionowej.
Wymagany raport: Prezentacja wartości wskaźników
zadłużenia wg stanu na koniec wybranego miesiąca w
danym roku. Prezentowane wskaźniki: wskaźnik ogólnego
zadłużenia, wskaźnik zadłużenia długoterminowego,
wskaźnik zadłużenia kapitału własnego.
Wymagany raport: Prezentacja w postaci wykresu
obejmującego dany rok miesięcznych wartości
118
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
wskaźników zadłużenia.
25.
26.
27.
28.
Wymagany raport: Prezentacja wartości wskaźników
struktury kosztów Zamawiającego, wg stanu na koniec
wybranego miesiąca w danym roku.
Prezentowane wskaźniki:
- wskaźnik struktury kosztów I – amortyzacja,
- wskaźnik struktury kosztów II – zużycie materiałów,
- wskaźnik struktury kosztów III – zużycie leków,
- wskaźnik struktury kosztów IV – zużycie sprzętu
jednorazowego,
- wskaźnik struktury kosztów V – zużycie odczynników
chemicznych i materiałów diagnostycznych,
- wskaźnik struktury kosztów VI – zużycie energii,
- wskaźnik struktury kosztów VII – usługi obce,
- wskaźnik struktury kosztów VIII – podatki i opłaty,
- wskaźnik struktury kosztów IX – wynagrodzenie, składki
ZUS, fundusz pracy.
Wymagany raport: Prezentacja w postaci wykresu
obejmującego dany rok miesięcznych wartości
wskaźników struktury kosztów.
Wymagany raport: Prezentacja wg stanu na koniec
wybranego miesiąca w danym roku wartości
następujących wskaźników:
- wskaźnik EBITDA,
- wskaźnik zastosowania kapitału własnego,
- wskaźnik zastosowania kapitału obcego,
- wskaźnik ogólnej sytuacji finansowej,
- wskaźnik poziomu kosztów.
Wymagany raport: Prezentacja w postaci wykresu
obejmującego dany rok, miesięcznych wartości
następujących wskaźników:
- wskaźnik EBITDA,
- wskaźnik zastosowania kapitału własnego,
- wskaźnik zastosowania kapitału obcego,
- wskaźnik ogólnej sytuacji finansowej,
- wskaźnik poziomu kosztów.
Wymagania funkcjonalne dla zakresu – Analiza
Kosztów (Raporty standardowe)
29. Wymagany raport: Zestawienie kosztów bezpośrednich w
119
TAK
TAK
TAK
TAK
TAK
podziale na rodzaje kosztów zdefiniowane w
Zamawiającego, wg stanu na koniec wybranego miesiąca
w danym roku, łącznie z możliwością wizualizacji stanów
wszystkich pozycji na koniec więcej niż jednego miesiąca.
30.
Wymagany raport: Zestawienie przychodów i kosztów
OPK (ośrodek powstawania kosztów) Zamawiającego, wg
stanu na koniec wybranego miesiąca w danym roku.
TAK
31.
Wymagany raport: Zestawienie dla danego OPK
Zamawiającego głównych pozycji kosztowych, wg stanu
na koniec wybranego miesiąca.
TAK
Wymagania funkcjonalne dla zakresu – Kontrola
Budżetu (Raporty standardowe)
32.
33.
34.
35.
36.
37.
Wymagany raport: Prezentacja planu i wykonania
budżetu przez komórkę budżetową wg stanu na koniec
wybranego miesiąca w danym roku, łącznie z możliwością
wizualizacji danych za wybrany miesiąc lub narastająco.
Wymagany raport: Prezentacja prognozy wykonania
całości budżetu przez komórkę budżetową na podstawie
średniej z dotychczasowego wykonania budżetu.
Wymagania funkcjonalne dla zakresu – Kadry i Płace
(Raporty standardowe)
Wymagany raport: Zestawienie prezentujące informacje
o liczbie pracowników w etatach oraz osobach, liczbie
przyjęć i zwolnień, średniej liczbie etatów oraz osób w
przekroju grup zawodowych.
Wymagany raport: Zestawienie prezentujące informacje
o liczbie pracowników w etatach oraz osobach, liczbie
przyjęć i zwolnień, średniej liczbie etatów oraz osób w
przekroju ośrodków powstawania kosztów.
Wymagany raport: Zestawienie prezentujące informacje
o nieobecnościach chorobowych pracowników
Zamawiającego, w podziale na nieobecności krótkie (do 7
dni), średniej długości (powyżej 7 a krócej niż 30 dni) oraz
długie (powyżej 30 dni).
Wymagany raport: Zestawienie prezentujące informacje
o płacach pracowników Zamawiającego z uwzględnieniem
składników płacowych.
Wymagania funkcjonalne dla zakresu – Realizacja
Kontraktów NFZ (Raporty standardowe)
120
TAK
TAK
TAK
TAK
TAK
TAK
38.
39.
40.
41.
42.
43.
Wymagany raport: Aktualny stan realizacji umów
Zamawiającego z NFZ, zawartych w poszczególnych
latach, z możliwością prezentacji danych w dotyczących
planu i wykonania w wartościach punktowych lub
kwotowo, w przekroju na:
- miesiąc sprawozdawczy,
- umowę,
- komórkę organizacyjną,
- OPK.
Wymagany raport: Aktualny stan realizacji umów
Zamawiającego z NFZ, zawartych w zakresie określonych
rodzajów umów we wskazanym roku, w przekroju na:
rodzaje umów i poszczególne umowy.
Wymagany raport: Aktualny stan realizacji umowy
Zamawiającego z NFZ dla wskazanej komórki
organizacyjnej, z dokładnością do zakresu świadczeń i
miesiąca sprawozdawczego, w przekroju na:
- umowę,
- zakres świadczeń,
- miesiąc sprawozdawczy.
Wymagany raport: Raport szczegółowy realizacji umowy
Zamawiającego z NFZ, z dokładnością do wybranej
pozycji planu umowy (identyfikowanej przez: zakres
świadczeń, wyróżnik i miesiąc sprawozdawczy), w
przekroju na:
- zakres świadczeń z wyróżnikiem,
- komórkę organizacyjną -miejsce udzielania świadczeń,
- miesiąc sprawozdawczy.
Wymagany raport: Stan realizacji bieżących umów
Zamawiającego z NFZ, w porównaniu do realizacji umów
dotyczących tego samego rodzaju świadczeń w
analogicznym okresie w poprzednich latach. Na jednym
raporcie możliwe jest porównanie aktualnych danych z
danymi z jednego wskazanego roku.
Wymagany raport: Monitorowanie potwierdzeń rozliczeń
poszczególnych umów Zamawiającego z NFZ, do
poziomu zakresu świadczeń dla całego roku lub kolejnych
miesięcy sprawozdawczych, w przekroju na: umowę,
121
TAK
TAK
TAK
TAK
TAK
TAK
zakres świadczeń, miesiąc sprawozdawczy.
44.
Wymagany raport: Wartość rozliczeń JGP w
poszczególnych latach dla oddziałów Zamawiającego.
TAK
45.
Wymagany raport: Wartość rozliczeń JGP dla komórek
organizacyjnych Zamawiającego dla kolejnych miesięcy
sprawozdawczych.
TAK
46.
47.
48.
Wymagany raport: Wartość rozliczeń JGP dla komórki
organizacyjnej Zamawiającego, z dokładnością do pozycji
planu umowy - dla kolejnych miesięcy sprawozdawczych z
rozbiciem na zakresy świadczeń z wyróżnikiem, i kody
grup JGP.
Wymagany raport: Szczegóły rozliczeń JGP dla komórki
organizacyjnej i miesiąca, z dokładnością do umowy i
pozycji planu umowy - dla miesiąca sprawozdawczego z
rozbiciem na zakresy świadczeń i kody grup JGP.
Wymagany raport: Porównanie wartości rozliczeń JGP dla
komórek organizacyjnych - Oddziałów - dla kolejnych
miesięcy sprawozdawczych.
TAK
TAK
TAK
Wymagania funkcjonalne dla zakresu – Statystyka
Medyczna (Raporty standardowe)
49.
Wymagany raport: Zestawienie prezentujące informacje
statystyczne dla pobytów szpitalnych obejmujące dane:
- liczba pacjentów przyjętych,
- liczba pacjentów wypisanych,
- liczba pacjentów aktualnie hospitalizowanych,
- średni koszt pobytu (o ile takie dane są dostępne w
systemach źródłowych),
- liczba osobodni,
- liczba łóżek,
- wykorzystanie łóżek,
- liczb etatów lekarskich,
- liczba etatów pielęgniarskich.
Dane prezentowane powinny być w przekroju na: miesiąc,
jednostkę organizacyjną (oddział szpitalny), OPK.
TAK
50.
Wymagany raport: zestawienie prezentujące informacje
statystyczne dotyczące porad ambulatoryjnych
TAK
122
51.
52.
obejmujące dane: liczba porad, średni koszt porady, w
przekroju na: miesiąc sprawozdawczy, jednostkę
organizacyjną (poradnie), OPK.
Wymagany raport: Zestawienie prezentujące informacje
statystyczne dla procedur medycznych obejmujące dane:
liczba wykonań i średni koszt procedury.
Dane prezentowane powinny być w przekroju na: miesiąc
sprawozdawczy, procedurę medyczną, jednostkę
organizacyjną (oddziały, poradnie), OPK.
Wymagany raport: Zestawienie prezentujące informacje
statystyczne dotyczące wykonanych badań
Zamawiającego, obejmujące dane: liczba wykonanych
badań i średni koszt badania. Dane prezentowane
powinny być w przekroju na: miesiąc sprawozdawczy,
badanie, jednostkę organizacyjną (pracownie), OPK.
TAK
TAK
Wymagania dotyczące sposobu zasilenia hurtowni
danymi, organizacji procesów
53.
54.
55.
56.
57.
58.
59.
Wymaga się, aby zasilanie hurtowni realizowane było
automatycznie poprzez procesy ETL, zgodnie z
harmonogramem zasilania, w oparciu o zdefiniowane
interfejsy.
Harmonogram zasilania hurtowni podlegać będzie edycji i
dostosowaniu do specyfiki systemów źródłowych.
Musi być możliwość zdefiniowania dla poszczególnych
obszarów hurtowni różnych parametrów określających
częstotliwość zasilania dla danego obszaru, zgodnie ze
zmiennością danych w systemach źródłowych.
Wymagane jest, aby uprawniony użytkownik systemu
mógł uruchomić „ręcznie” poszczególne ścieżki zasilania
ETL.
Wymagane jest, aby zasilanie hurtowni danymi za
wybrany okres mogło być powtarzane wielokrotnie bez
konieczności dokonywania specjalnych operacji
administracyjnych na poziomie bazy rejestrów hurtowni.
Definicje ścieżek ETL muszą być przechowywane w
plikach w formacie XML lub repozytorium, w celu
ułatwienia zarządzania i weryfikowania na poziomie
administratora systemu.
Repozytorium ETL może być rozmieszczone na dowolnej
123
TAK
TAK
TAK
TAK
TAK
TAK
TAK
relacyjnej bazie danych.
60.
61.
62.
63.
64.
65.
66.
67.
68.
W ramach dostarczanego systemu musi być dostępne
narzędzie do graficznej prezentacji i edycji ścieżek ETL.
Narzędzie do tworzenia ścieżek ETL musi umożliwiać
podgląd struktur danych i zawartości danych po stronie
źródeł zasilających hurtownię danych.
Zastosowane rozwiązanie ETL musi umożliwiać
pobieranie danych z dowolnych relacyjnych baz danych.
Zastosowane rozwiązanie ETL musi umożliwiać
pobieranie danych z baz „NoSQL” (np. Cassandra, MapR,
MongoDB).
Zastosowane rozwiązanie ETL musi umożliwiać
pobieranie danych z plików płaskich csv, arkuszy
kalkulacyjnych, usług sieciowych, stron WWW.
Zastosowane rozwiązanie ETL musi umożliwiać
pobieranie danych w formacie Json, HL7, LDIF, XML.
Zastosowane rozwiązanie ETL musi umożliwiać
automatyczne tworzenie dokumentacji ścieżek ETL w
formacie PDF, HTML, DOC, XLS.
Zastosowane rozwiązanie ETL musi posiadać
elastyczny/konfigurowalny mechanizm logowania z
dokładnością do jednego przetwarzanego rekordu danych.
Zastosowane rozwiązanie ETL musi umożliwiać
przenoszenie repozytorium definicji ścieżek ETL meta
danych pomiędzy instalacjami poprzez funkcje eksportu i
importu repozytorium.
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
Wymagania dotyczące zarządzania metadanymi i
translacji danych importowanych do hurtowni
69.
70.
71.
Wymaga się, aby rozwiązanie zawierało narzędzie, które
umożliwia zarządzanie słownikami hierarchicznymi
opisującymi dane biznesowe w ramach repozytorium
metadanych (zarządzanie wymiarami).
Budowane słowniki w ramach repozytorium metadanych
powinny mieć znaczniki czasowe określające, która z
wersja hierarchii obowiązuje w danym okresie czasowym.
Rozwiązanie powinno zawierać wyodrębniony słownik
translacji, umożliwiający zarządzanie regułami
przetwarzania danych źródłowych na dane biznesowe
reprezentowane w modelu logicznym hurtowni
124
TAK
TAK
TAK
(przetworzenie danych źródłowych na pojęcia biznesowe).
72
W szczególności rozwiązanie powinno zapewniać
możliwość takiej współpracy z źródłami udostępniającymi
dane z zakresu finansów i księgowości Zamawiającego,
aby okresowe zmiany w zakładowym planie kont w
źródłowym systemie Finanse - Księgowość
Zamawiającego, nie wymagały modyfikacji indywidualnych
raportów bazujących na hurtowni danych , a jedynie
jednokrotnej zmiany konfiguracji globalnej rozwiązania.
TAK
Wymagania dotyczące zarządzania prawami dostępu
do informacji i bezpieczeństwa danych
73.
74.
75.
76.
77.
Wymaga się, aby dostęp do systemu był możliwy tylko po
uwierzytelnieniu użytkownika.
Wymaga się, aby dostęp użytkownika do systemu był
ograniczony przez rolę jaką użytkownik ma przyznaną w
systemie.
Wymaga się, aby system gromadził informacje o źródle, z
którego pochodzą dane.
Wymaga się, aby system gromadził informacje o
wszystkich dostępach do danych przetwarzanych na
poziomie hurtowni Zamawiającego.
Wymaga się, aby system gromadził informacje
dokumentujące wykonanie poszczególnych ścieżek ETL.
TAK
TAK
TAK
TAK
TAK
Ja (My), niżej podpisany (ni)
...............................................................................................................................................
Działając w imieniu i na rzecz
...............................................................................................................................................
...............................................................................................................................................
Oświadczam (y), iż oferowany produkt spełnia wszystkie wymienione powyżej wymogi
dotyczące parametrów techniczno- użytkowych.
........................., dnia .............................
................................................................
(Podpis)
125
Załącznik nr 4 – Wzór umowy
UMOWA NR …………………
NA WDROŻENIE OPROGRAMOWANIA,
UDZIELENIE LICENCJI I OBJĘCIE NADZOREM AUTORSKIM
zawarta w dniu ………2015r. w ….., pomiędzy:
…………………………………………………………………
z
siedzibą
w
………………………………..,
ul. ……………………………, ..-… ……………………., NIP: ………………………, wpisaną
do Rejestru Przedsiębiorców prowadzonego przez Sąd Rejonowy w ………………………..,
……….Wydział Gospodarczy Krajowego Rejestru Sądowego, pod numerem KRS
…………………….., z kapitałem zakładowym w wysokości ………… zł, wpłaconym w
całości, REGON ………………, którą reprezentują:
……….………………………………………
………………………………………………………………...
-
………………..……………………………...
………………………………………………………………….
-
zwana w treści niniejszej umowy Zamawiającym,
oraz
…………………………………………………………………
z
siedzibą
w
………………………………..,
ul. ……………………………, ..-… ……………………., NIP: ………………………, wpisaną do
Rejestru Przedsiębiorców prowadzonego przez Sąd Rejonowy w ………………………..,
……….Wydział Gospodarczy Krajowego Rejestru Sądowego, pod numerem KRS
…………………….., z kapitałem zakładowym w wysokości ………… zł, wpłaconym w całości,
REGON ………………, którą reprezentują:
……….………………………………………
…………………………………………………………………...
1
-
………………..……………………………...
…………………………………………………………………...
-
zwaną w treści niniejszej umowy Wykonawcą,
o następującej treści:
§ 1. Definicje
1.
Na potrzeby niniejszej umowy Strony nadają wymienionym niżej pojęciom następujące
znaczenie:
Nazwany
- oznacza osobę należąca do personelu Zamawiającego,
Użytkownik
posiadającą uprawnienia do korzystania z danego
Modułu Oprogramowania Aplikacyjnego, nadane jej
przez Wykonawcę lub Zamawiającego zgodnie z
warunkami licencyjnymi określonymi w § 4;
Dedykowane Stacje - Oznacza komputery klasy PC udostępnione Wykonawcy
Robocze
przez Zamawiającego na podstawie § 3 ust. 4 lit. b, o
właściwościach i konfiguracji określonej w załączniku nr
3;
Moduł
- Oznacza pojedynczy program komputerowy wymieniony
Oprogramowania
w załączniku nr 1, wchodzący w skład Oprogramowania
Aplikacyjnego
Aplikacyjnego;
2
Oznacza traktowane łącznie programy komputerowe
wymienione w załączniku nr 1 (oprogramowanie typu
HIS, RIS, LIS i Zaopatrzeniowe) do których Wykonawcy
przysługują autorskie prawa majątkowe.
Oprogramowanie
- Oznacza program komputerowy co najmniej w wersji
Bazodanowe
Oracle Database Server Standard Edition 11
Oprogramowanie
- Oznacza programy komputerowe niezbędne do
Systemowe
prawidłowego działania Oprogramowania Aplikacyjnego i
Oprogramowania Bazodanowego, ale nie wchodzące w
skład Oprogramowania Aplikacyjnego i Oprogramowania
Bazodanowego, zainstalowane przez Zamawiającego na
Dedykowanych Stacjach Roboczych i Serwerze;
Projekt
- Oznacza świadczenia Wykonawcy opisane w § 2
(inaczej przedmiot umowy);
Serwer
- Oznacza serwer (-y) sieciowy (-e) udostępniony
Wykonawcy przez Zamawiającego na podstawie § 3 ust.
4 lit. b, o właściwościach i konfiguracji określonej w
załączniku nr 3;
System
- Oznacza całość funkcjonujących u Zamawiającego
Informatyczny
urządzeń komputerowych i oprogramowania, w tym sieci
komputerowe LAN i WAN, Serwery, Dedykowane stacje
robocze, inne stacje robocze, drukarki, Oprogramowanie
Aplikacyjne,
Oprogramowanie
Bazodanowe,
Oprogramowanie Systemowe;
Usługi
- Oznacza usługi opisane w załączniku nr 6, świadczone
Wdrożeniowe
przez Wykonawcę w trakcie wizyt w siedzibie
Zamawiającego, których liczbę określa załącznik nr 1;
Ilekroć w postanowieniach niniejszej umowy pojęcia wymienione w ust. 1 niniejszego
paragrafu zostały napisane dużą literą, pojęciom tym nadaje się znaczenie określone
powyżej, chyba że określony termin został użyty w innym znaczeniu, co zostało wyraźnie
zaznaczone w odpowiednim postanowieniu lub odmienne znaczenie danego pojęcia
wynika z oczywistego kontekstu w jakim zostało ono użyte w przedmiotowym
postanowieniu, a Strony zgodne są co do takiego znaczenia, odmiennego od określonego
w ust. 1 niniejszego paragrafu.
§ 2. Przedmiot umowy
Przedmiotem niniejszej umowy jest:
Zadanie 1: Przygotowanie projektów wykonawczych oprogramowania typu HIS,
RIS, LIS i Zaopatrzeniowego
Oprogramowanie
Aplikacyjne
2.
1.
-
3
2.
1.
2.
3.
4.
5.
Zadanie 2: Dostawa licencji oprogramowania typu HIS
Zadanie 3: Dostawa licencji oprogramowania typu RIS
Zadanie 4: Dostawa licencji oprogramowania typu LIS
Zadanie 5: Dostawa licencji oprogramowania typu Zaopatrzeniowego
Zadanie 6: Instalacja oprogramowania typu HIS, RIS, LIS i Zaopatrzeniowego
Zadanie 7: Integracja oprogramowania typu HIS, RIS, LIS i Zaopatrzeniowego
a. Udzielenie licencji na korzystanie z Oprogramowania Aplikacyjnego, w wersji bez
limitów i ograniczeń ilości użytkowników, wymienionych w Załączniku nr 1 do niniejszej
umowy;
b. Świadczenie usług instalacji Oprogramowania Aplikacyjnego na Serwerze (Serwerach)
i Dedykowanych Stacjach Roboczych w pomieszczeniach Zamawiającego (zakres
usług opisany jest w załączniku nr 1 i 6);
c. Świadczenie Usług Wdrożenia (konfiguracji, parametryzacji i szkoleń) dotyczących
Oprogramowania Aplikacyjnego w siedzibie Zamawiającego (zakres usług opisany jest
w załączniku nr 1 i 6, specyfikację funkcjonalną Oprogramowania Aplikacyjnego
określa załącznik nr 7 do Umowy);
d. Objęcie przez Wykonawcę uruchomionego Oprogramowania Aplikacyjnego 12
miesięcznym gwarancyjnym nadzorem autorskim, licząc od daty zawarcia niniejszej
Umowy;
Szczegółowy zakres usług składających się na przedmiot umowy oraz zasady ich
wykonywania,
z podziałem na etapy określają załączniki do niniejszej umowy.
§ 3. Terminy realizacji umowy
Umowa została zawarta na czas jej realizacji wynikający z harmonogramu zawartego w
Załączniku nr 5 do Umowy, tj. do 29.09.2015r.
Umowa wchodzi w życie z dniem jej podpisania przez ostatnią ze Stron ze skutkiem na
dzień ………. 2015r.
Umowa będzie realizowana wg ramowego harmonogramu określonego w załączniku nr 5
do niniejszej umowy. Dla celów realizacji przedmiotu niniejszej umowy Kierownik Projektu
może przygotować szczegółowy harmonogram będący rozszerzeniem ramowego
harmonogramu określonego w załączniku nr 5 do niniejszej umowy.
Zamawiający zobowiązany jest do realizacji ciążących na nim zobowiązań przewidzianych
niniejszą umową zgodnie ze Standardami Wdrożeniowymi, przedstawionymi w niniejszej
umowie w § 5 i 6 oraz w załączniku nr 6.
Zamawiający zobowiązany jest, w terminie 7 dni od daty zawarcia niniejszej umowy:
a) przekazać na piśmie Wykonawcy dane dotyczące posiadanego sprzętu
komputerowego
i Systemu Informatycznego oraz Oprogramowania Systemowego, konieczne dla
prawidłowego zrealizowania usług;
4
udostępnić Wykonawcy na czas realizacji Usług Wdrożeniowych Serwer (-y) i
Dedykowane Stacje Robocze o minimalnych parametrach określonych w załączniku nr
3;
c) przekazać na pisemną prośbą piśmie Wykonawcy informacje i dane, konieczne dla
prawidłowego zrealizowania usług.
W terminie 7 dni od daty spełnienia wszystkich wymagań określonych w ust. 4 niniejszego
paragrafu Wykonawca przystąpi do wykonywania niniejszej umowy. W przypadku, gdy
Wykonawca nie otrzyma wymaganych informacji określonych w ust. 4 niniejszego
paragrafu terminy realizacji Projektu ulegają odpowiedniemu przesunięciu o liczbę dni
pomiędzy wymaganym terminem wykonania przez Zamawiającego zobowiązań
określonych w ust. 4, a rzeczywistym terminem ich wykonania.
Termin wykonania przedmiotu umowy zostanie dotrzymany pod warunkiem realizacji przez
Zamawiającego w wymaganych terminach wszystkich zadań określonych niniejszą umową,
w szczególności w ust. poprzedzających, jak również określonych przez Wykonawcę
w harmonogramie szczegółowym lub protokołach Usług Wdrożeniowych. Jeżeli
Zamawiający nie będzie wykonywać terminowo powołanych zadań, termin realizacji
Projektu
może
ulec
wydłużeniu
z winy Zamawiającego, jednakże nie więcej niż okres zwłoki w realizacji przez
Zamawiającego wykonania zadań określonych niniejszą umową.
§ 4. Licencja i dostarczenie oprogramowania
Warunki licencji na poszczególne Moduły Oprogramowania Aplikacyjnego określa załącznik
nr 2.
§ 5. Realizacja Usług Wdrożeniowych do Oprogramowania Aplikacyjnego
Szczegółowe zasady realizacji Projektu określają Standardy Wdrożeniowe określone w
niniejszej umowie w § 5 i § 6 oraz w załączniku nr 6.
Usługi Wdrożeniowe dotyczące Oprogramowania Aplikacyjnego w tym szkolenia,
konsultacje, wizyty instalacyjne, itp. odbywały się będą w pomieszczeniach
Zamawiającego. W przypadku nie przyjęcia przedstawionych przez Wykonawcę propozycji
terminów wizyt, terminy określone w § 3 i załączniku nr 5 ulegają stosunkowemu
przedłużeniu, o tyle samo dni, o ile Zamawiający przesunął termin wizyty.
Wykonanie Usług Wdrożeniowych dla każdego z Modułów Oprogramowania Aplikacyjnego
będzie potwierdzone odpowiednim protokołem. Za zrealizowanie Projektu w zakresie Usług
Wdrożeniowych przyjmuje się zrealizowanie przez Wykonawcę wszystkich przewidzianych
w niniejszej umowie Usług Wdrożeniowych określonych w załączniku nr 1.
Dla celów realizacji Usług Wdrożeniowych w zakresie Oprogramowania Aplikacyjnego
zakłada się nie więcej wizyt wdrożeniowych niż określono w załączniku nr 1, przy założeniu
otrzymania wszelkich niezbędnych informacji od Zamawiającego, o których mowa w § 3.4.
Jeżeli zajdzie konieczność zrealizowania dodatkowych usług, usługi te będą traktowane
jako prace dodatkowe, nie objęte przedmiotem niniejszej umowy.
b)
6.
7.
1.
2.
3.
4.
5
5.
6.
7.
8.
9.
1.
2.
3.
4.
Każda wizyta Wykonawcy w pomieszczeniach Zamawiającego oraz wykonane w czasie tej
wizyty zadania zostaną potwierdzone stosownym protokołem podpisywanym ze Strony
Zamawiającego przez osoby wymienione w ust. 6 lub 9, ze strony Wykonawcy przez
wdrożeniowca realizującego wizytę.
Osobą odpowiedzialną za realizację niniejszej umowy po stronie Zamawiającego jest
…………………………………………..,
tel.
…………………,
e-mail
………………………………
Osobą odpowiedzialną za realizację niniejszej umowy po stronie Wykonawcy jest
…………………………………………..,
tel.
…………………,
e-mail
………………………………
Osobami mogącymi przeprowadzić procedurę odbioru prac określoną w § 6 są osoby
wskazane
w ust. 6 i 7 niniejszego paragrafu. Zmiana osób, wskazanych w ust. 6 i 7 nie stanowi
zmiany niniejszej Umowy i jest skuteczna z chwilą pisemnego powiadomienia drugiej
Strony o zmianie.
Osobami wyznaczonymi przez Zamawiającego do kontaktów z Wykonawcą w sprawach
realizacji niniejszej umowy są osoby wskazane w Dodatku nr 2 do Załącznika nr 6 niniejszej
umowy (Informacje o Zamawiającym).
§ 6. Procedura odbioru prac
O zakończeniu każdego etapu świadczenia usług Wykonawca powiadamia
Zamawiającego, proponując termin dokonania odbioru. Wykonawca i Zamawiający
uzgadniają pisemnie lub telefonicznie termin dokonania odbioru. Termin powiadomienia
określony w zdaniu poprzedzającym nie może być krótszy niż 7 dni przed proponowaną a
następnie uzgodnioną datą odbioru.
Jeżeli bez uzasadnionej przyczyny (przekazanej na piśmie Wykonawcy do terminu
dokonania odbioru, o którym mowa w ust.1 niniejszego paragrafu) Zamawiający nie
przystąpi do procedury odbioru lub bez uzasadnionej przyczyny (przekazanej na piśmie
Wykonawcy w terminie dokonania odbioru lub terminie, w którym Zamawiający powinien
przystąpić do odbioru, o którym mowa w ust.1 niniejszego paragrafu) odmówi podpisania
jakiegokolwiek protokołu, Wykonawca zastrzega sobie prawo dokonania odbioru
jednostronnego oraz jednostronnego sporządzenia i podpisania protokołu, który stanowić
będzie podstawę płatności i stwierdzenia wykonania prac nim objętych.
Ciężary i ryzyka związane ze stanowiącym przedmiot odbioru elementem Projektu
przechodzą na Zamawiającego z chwilą przyjęcia od Wykonawcy danego elementu
przedmiotu Umowy. Udzielenie licencji na korzystanie z Oprogramowania Aplikacyjnego
następuje z chwilą podpisania protokołu odbioru wdrożenia danego modułu
Oprogramowania Aplikacyjnego, podlegającego odbiorowi.
Jeżeli z jakichkolwiek przyczyn w toku realizacji przedmiotu niniejszej umowy, świadczenie
stanie się niemożliwe do wykonania, bądź jedna ze Stron odstąpi od umowy lub ją rozwiąże
6
5.
6.
1.
2.
3.
4.
1.
2.
(za wypowiedzeniem lub ze skutkiem natychmiastowym) bądź też umowa zostanie
rozwiązana za porozumieniem Stron, Strony zobowiązane są niezwłocznie, nie później
jednak niż do 2 dni od daty wystąpienia takiej przyczyny lub zdarzenia, sporządzić
uzgodniony protokół stanu zaawansowania Projektu.
Termin sporządzenia protokołu zaawansowania Projektu proponuje Wykonawca w
uzgodnieniu z Zamawiającym, w trybie określonym w § 6 ust 1. Wykonawca zastrzega
sobie prawo jednostronnego sporządzenia i podpisania protokołu, jeżeli w uzgodnionym
terminie Zamawiający nie podpisze protokołu.
W protokole stanu zaawansowania Projektu, Strony określą zakres usług dotychczas
wykonanych oraz – w razie potrzeby - zasady rozliczenia i wynagrodzenia za usługi
wykonane i rozpoczęte, z uwzględnieniem zasad przewidzianych postanowieniami
niniejszej umowy.
§ 7. Płatności
Za realizację przedmiotu umowy, opisanego w § 2 niniejszej umowy, Zamawiający zapłaci
Wykonawcy wynagrodzenie w wysokości:
………………….zł
netto
(słownie:
…………………………………………złotych),
tj.
……………………………..
zł
brutto
(słownie:
…………………………………………..złotych).
Szczegółowe zestawienie składników wynagrodzenia i zasady rozliczenia przedstawiono
w załączniku nr 1 i 4.
Wynagrodzenie będzie płatne na podstawie faktur VAT, w terminie do ……. dni od dat ich
wystawienia, przelewem na rachunek bankowy na nich wskazany.
Zamawiający oświadcza, że upoważnia Wykonawcę do wystawiania faktur bez podpisu
Zamawiającego.
§ 8. Zobowiązania Zamawiającego
Zamawiający zobowiązuje się dołożyć niezbędnych starań zmierzających do umożliwienia
Wykonawcy sprawnego wykonywania postanowień niniejszej umowy, w szczególności
poprzez udzielenie wszelkich niezbędnych informacji, jak również zapewni Wykonawcy
dostęp do Systemu Informatycznego oraz Oprogramowania Systemowego i
Bazodanowego, w tym niezbędnych urządzeń, na których będzie instalowane
Oprogramowanie Aplikacyjne.
Zamawiający obowiązany jest zabezpieczyć posiadane przez siebie dane oraz
oprogramowanie, znajdujące się bądź zainstalowane w Systemie Informatycznym, w
szczególności poprzez:
a) Sporządzenie kopii zapasowych wszelkich danych oraz oprogramowania znajdujących
się bądź zainstalowanych w Systemie Informatycznym, bezpośrednio przed
udostępnieniem Systemu Informatycznego Wykonawcy (backup),
b) Regularne, (co najmniej raz dziennie lub częściej w przypadku istotniejszych operacji,
bądź na zalecenie przedstawiciela Wykonawcy) sporządzanie kopii zapasowych
7
1.
2.
3.
4.
1.
2.
3.
wszelkich danych oraz oprogramowania znajdujących się bądź zainstalowanych w
Systemie Informatycznym w trakcie wykonywania niniejszej umowy.
§ 9. Siła Wyższa
Żadna ze Stron Umowy nie będzie odpowiedzialna za niewykonanie lub nienależyte
wykonanie zobowiązań wynikających z Umowy spowodowane przez okoliczności
traktowane jako Siła Wyższa. Przez Siłę Wyższą rozumie się nadzwyczajne zdarzenia
zewnętrzne pozostające poza kontrolą każdej ze Stron, których nie mogły one przewidzieć
ani zapobiec, a które zakłócają lub uniemożliwiają realizację Umowy.
W przypadku zaistnienia Siły Wyższej, Strona, której taka okoliczność uniemożliwia
lub utrudnia prawidłowe wywiązanie się z jej zobowiązań niezwłocznie, powiadomi drugą
Stronę o takich okolicznościach i ich przyczynie.
Jeżeli Siła Wyższa, będzie trwała nieprzerwanie przez okres 180 dni lub dłużej, Strony
mogą w drodze wzajemnego uzgodnienia rozwiązać Umowę, bez nakładania na żadną
ze Stron dalszych zobowiązań, oprócz płatności należnych z tytułu wykonanych usług.
Okres występowania Siły Wyższej i jej następstw powoduje odpowiednie przesunięcie
terminów realizacji usług określonych w Umowie.
§ 10. Ochrona Danych Osobowych
W celu prawidłowego wykonania przez Wykonawcę obowiązków wynikających z niniejszej
Umowy i wyłącznie w zakresie niezbędnym dla wykonania przez Wykonawcę takich
obowiązków, Zamawiający będący Administratorem Danych Osobowych w rozumieniu
Ustawy o ochronie danych osobowych (t. jedn. z 2002 r. Dz. U. nr 101, poz. 926 z późn.
zm.) powierza Wykonawcy przetwarzanie wszelkich rodzajów danych osobowych
przetwarzanych w systemie informatycznym Zamawiającego przy użyciu Oprogramowania
Aplikacyjnego, w zakresie określonym szczegółowo w dokumentacji technicznej
Oprogramowania Aplikacyjnego (umieszczonej w wersji elektronicznej na serwerze ftp:
…………………..), jednak wyłącznie w zakresie ich opracowywania, utrwalania
i przechowywania na podstawie ustawy z dnia 29 sierpnia 1997 r. o ochronie danych
osobowych. Wykonywanie przez Wykonawcę operacji przetwarzania danych w zakresie lub
celu przekraczających zakres i cel opisane powyżej wymaga każdorazowej pisemnej zgody
Zamawiającego.
Dostęp Wykonawcy do danych osobowych odbywa się z zastrzeżeniem dopełnienia przez
Zamawiającego wymogów określonych w rozporządzeniu Ministra Spraw Wewnętrznych i
Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych
osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać
urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz.U. nr
100, poz. 1024).
Wykonawca oświadcza, iż zastosuje środki zabezpieczające, o których mowa w art. 36-39
ustawy o ochronie danych osobowych oraz w rozporządzeniu Ministra Spraw
Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji
8
4.
5.
6.
1.
2.
przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim
powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych
osobowych.
Zamawiający oświadcza, że przetwarza powierzone dane osobowe na podstawie art. 27
ust. 2 pkt 7 Ustawy o ochronie danych osobowych
Zamawiający wyraża zgodę na powierzenie realizacji niniejszej Umowy osobom trzecim, w
tym na dalsze powierzenie tym osobom przetwarzania danych osobowych przy
odpowiednim zastosowaniu zasad określonych w ust. 1 do 3 oraz na udostępnienie
informacji poufnych Zamawiającego, uzyskanych w związku z realizacją niniejszej Umowy.
Jednocześnie Wykonawca oświadcza, że za działania lub zaniechania osób trzecich,
którym powierzono wykonanie umowy odpowiada jak za własne działania lub zaniechania.
Zamawiający udziela pełnomocnictwa Wykonawcy do powierzenia w imieniu
Zamawiającego przetwarzania danych osobowych, o których mowa w ust. 1, osobom
trzecim, którym Wykonawca powierzył wykonanie przedmiotu niniejszej Umowy.
§ 11. Ochrona tajemnicy przedsiębiorstwa
Strony zobowiązują się do utrzymania w tajemnicy i nie ujawniania, nie publikowania, nie
przekazywania i nie udostępniania w żaden inny sposób osobom trzecim, jakichkolwiek
nieupublicznionych danych o przedsiębiorstwach, transakcjach i Klientach (pacjentach)
Stron, jak również:
a. wszelkich danych medycznych i organizacyjno-medycznych,
b. oferowanych cen, stosowanych marż, posiadanych upustów lub warunków handlowych;
c. informacji i danych stanowiących tajemnicę przedsiębiorstwa Stron w rozumieniu
przepisów ustawy o zwalczaniu nieuczciwej konkurencji (tekst jednolity z 2003 r. Dz. U.
153, poz. 1503);
d. innych informacji prawnie chronionych;
które to informacje uzyskają w trakcie lub w związku z realizacją niniejszej Umowy, bez
względu na sposób i formę ich utrwalenia lub przekazania, w szczególności w formie
pisemnej, kserokopii, faksu i zapisu elektronicznego, o ile informacje takie nie są
powszechnie znane, bądź obowiązek ich ujawnienia nie wynika z obowiązujących
przepisów, orzeczeń sądów lub decyzji odpowiednich władz, albo gdy przekazanie
następuje na rzecz podwykonawcy, który będzie realizował zobowiązania jednej ze Stron.
Obowiązkiem zachowania poufności nie jest objęty fakt zawarcia Umowy ani jej treść w
zakresie określonym obowiązującymi przepisami prawa.
Każdej ze Stron wolno ujawnić informacje poufne z ograniczeniami wynikającymi
z przepisów prawa, o których mowa w niniejszym paragrafie członkom swoich władz,
podwykonawcom i pracownikom oraz członkom władz, podwykonawcom i pracownikom
podmiotów powiązanych lub zależnych, kancelariom prawnym, firmom audytorskim,
pracownikom organów nadzoru. w takim zakresie, w jakim będzie to niezbędne
do wypełnienia przez nią zobowiązań i obowiązków na podstawie Umowy, przy czym
9
Strona przekazująca takie informacje wymienionym wyżej osobom będzie ponosić
odpowiedzialność za przestrzeganie przez te osoby zasad poufności opisanych w
niniejszym rozdziale.
3. Wszelkie dane udostępnione Wykonawcy przez Zamawiającego są nadal jego wyłączną
własnością. Rozporządzanie nimi przez Wykonawcę nie wynikające z realizacji niniejszej
Umowy wymaga pisemnej zgody Zamawiającego.
4. Wykonawca zobowiązany jest zapewnić poufność informacji dotyczących Zamawiającego
uzyskanych w związku z realizacją niniejszej Umowy i nie ujawniać tych informacji bez
uprzedniej pisemnej zgody Zamawiającego w czasie trwania niniejszej Umowy chyba, że
przepisy szczególne przewidują dłuższy okres ochrony informacji.
5. Wykonawca zobowiązuje się wykorzystywać informacje, o których mowa w § 10 ust. 1)
wyłącznie w celu należytego wykonania niniejszej Umowy.
6. Wykonawca przedstawi osobom wyznaczonym do realizacji przedmiotu umowy mających
dostęp do informacji chronionych, zobowiązanie do zachowania tajemnicy wg wzoru z
Dodatku nr 3 załącznika nr 6 do Umowy.
7. Zamawiający zobowiązuje się do zapewnienia poufności udostępnionej dokumentacji
technicznej Oprogramowania Aplikacyjnego, z wyłączeniem dokumentacji zewnętrznych
interfejsów wymiany danych.
8. Naruszenie obowiązku zachowania poufności, o którym mowa w niniejszym paragrafie
skutkować będzie obowiązkiem zapłaty przez Stronę naruszającą ten obowiązek kary
umownej wynoszącej 50.000,00 zł (słownie: pięćdziesiąt tysięcy zł) za każdy przypadek
naruszenia, z prawem Zamawiającego do dochodzenia dalej idącego odszkodowania
powyżej zastrzeżonej kary na zasadach ogólnych w przypadkach naruszenia ochrony
danych pacjentów (danych osobowych i/lub medycznych).
9. Obowiązek zachowania poufności, o którym mowa w niniejszym paragrafie nie ma
zastosowania w przypadkach, w których Zamawiający lub Wykonawca zobowiązany jest do
ujawnienia informacji na mocy obowiązujących przepisów albo decyzji lub orzeczenia
uprawnionego organu państwowego.
10. Strony Umowy mają prawo do wykorzystania informacji o fakcie zawarcia Umowy oraz
wskazania ogólnego przedmiotu i Stron Umowy dla celów referencyjnych i marketingowych.
Na żądanie Zamawiającego, Wykonawca winien zaprzestać takiego wykorzystywania i na
żądanie Wykonawcy, Zamawiający winien zaprzestać takiego wykorzystywania.
§ 12.
Rozwiązanie Umowy i odpowiedzialność
1. Umowa może zostać rozwiązana bez wypowiedzenia przez każdą ze Stron, wyłącznie
w przypadkach przewidzianych bezwzględnie obowiązującymi przepisami prawa oraz z
ważnych przyczyn, obejmujących:
a) W wypadku rozwiązania umowy przez Zamawiającego:
(1) Zwłokę Wykonawcy w wykonaniu umowy w stosunku do terminu określonego w §
3.6 wynikającą z wyłącznej winy Wykonawcy, jeżeli zwłoka ta przekracza 30 dni,
10
2.
3.
4.
5.
a po upływie tego terminu Zamawiający wyznaczył Wykonawcy na piśmie (pod
rygorem nieważności) dodatkowy, nie krótszy jednak niż 30 dni termin na
wykonanie umowy, który to termin nie został przez Wykonawcę dotrzymany;
b) W wypadku rozwiązania umowy przez Wykonawcę:
(1) Zwłokę Zamawiającego w wykonaniu zobowiązań określonych w Umowie, w
stosunku do terminów wynikających z umowy lub wyznaczonych przez
Wykonawcę, jeśli po upływie tych terminów, Wykonawca wyznaczył
Zamawiającemu na piśmie (pod rygorem nieważności) dodatkowy, nie krótszy niż
7 dni termin na wykonanie zobowiązań wynikających z umowy, a który to termin
nie został dotrzymany;
(2) Opóźnienia Zamawiającego w zapłacie dowolnej części wynagrodzenia
Wykonawcy w stosunku do terminów określonych w § 7.3, jeżeli opóźnienie to
przekracza 30 dni, a po upływie tego terminu Wykonawca wyznaczył
Zamawiającemu na piśmie (pod rygorem nieważności) dodatkowy, nie krótszy
jednak niż 14 dni termin na dokonanie płatności umowy, który to termin nie został
przez Zamawiającego dotrzymany;
(3) Wszczęcia postępowania likwidacyjnego w stosunku do Zamawiającego;
W przypadku opóźnienia Zamawiającego w zapłacie dowolnej części wynagrodzenia
Wykonawcy w stosunku do terminów określonych w § 7.3, Wykonawca może – niezależnie
od innych uprawnień wynikających z niniejszej umowy i przepisów prawa – wstrzymać się z
realizacją wszystkich pozostałych świadczeń przewidzianych niniejszą umową do czasu
uregulowania przez Zamawiającego wszystkich zaległych należności. Wstrzymanie
wykonywania niniejszej umowy następuje poprzez powiadomienie Zamawiającego w formie
pisemnej i nie powoduje dla Wykonawcy żadnych negatywnych konsekwencji prawnych.
W wypadku rozwiązania za wypowiedzeniem niniejszej umowy oraz w przypadku
odstąpienia od umowy, Wykonawcy w każdym wypadku przysługuje wynagrodzenie za
świadczenia (prace) wykonane, jak również za zamówione na potrzeby Zamawiającego
oprogramowanie/produkty osób trzecich, o ile ich zamówienie zostało udokumentowane.
Ponadto, jeżeli rozwiązanie lub odstąpienie nastąpiło w przyczyn, za które jedna ze stron
ponosi odpowiedzialność, Strona ta zobowiązana będzie do zapłaty stronie rozwiązującej
lub odstępującej od umowy karę umowną w wysokości 10 % wynagrodzenia netto
przewidzianego w § 7.1.
Odpowiedzialność odszkodowawcza Wykonawcy wynikająca z nienależytego wykonania
przedmiotu Umowy ogranicza się do rzeczywistej straty Zamawiającego, bez utraconych
korzyści, lecz nie więcej niż równowartość 100% wynagrodzenia otrzymanego przez
Wykonawcę na podstawie niniejszej Umowy.
Ograniczenie odpowiedzialności nie dotyczy jednakże sytuacji, gdy w przypadku
wyrządzenia przez Wykonawcę szkody Zamawiającemu w zakresie naruszenia ochrony
danych pacjentów (danych osobowych i/lub medycznych) oraz sytuacji, gdy szkoda
11
6.
7.
Zamawiającego
wyniknie
z rażącego niedbalstwa Wykonawcy. Zamawiający ma wówczas prawo do dochodzenia
dalej idącego odszkodowania na zasadach ogólnych.
Strony oświadczają, że wszelka odpowiedzialność Wykonawcy z tytułu rękojmi za wady
fizyczne na podstawie art. 55 ustawy o prawie autorskim i prawach pokrewnych, jak i na
podstawie jakiegokolwiek tytułu prawnego, ulega wyłączeniu.
Wykonawca nie ponosi odpowiedzialności odszkodowawczej za skutki korzystania
z Oprogramowania Aplikacyjnego. Ponadto Wykonawca nie ponosi odpowiedzialności
odszkodowawczej w przypadku korzystania z Oprogramowania Aplikacyjnego w warunkach
- leżących poza Wykonawcą - nieprawidłowej pracy Systemu Informatycznego
(spowodowanej wadami sprzętu lub niewłaściwą instalacją i działaniem systemów
operacyjnych bądź sieciowych), w przypadku nieprawidłowej obsługi (tzn. innej niż opisanej
w dokumentacji użytkownika), błędnej interpretacji otrzymanych wyników, ingerencji przez
osoby nieuprawnione w Oprogramowanie Aplikacyjne (lub Bazodanowe) objęte niniejszą
umową, w przypadku braku zabezpieczania systemu przed dostępem osób
nieuprawnionych (system użytkowników i haseł) oraz utratą danych (archiwizacja).
Wykonawca zaleca systematyczne (najlepiej codzienne) wykonywanie kopii wprowadzanych danych w użytkowanym przez siebie oprogramowaniu objętym niniejszą
umową (archiwizacja).
Kary umowne
Zamawiający zastrzega sobie prawo do naliczenia kar umownych w przypadkach i
wysokościach określonych poniżej:
a)
za przekroczenie terminu wykonania przedmiotu umowy - w wysokości 0,1%
wynagrodzenia umownego netto, o którym mowa w § 7 ust. 1 za każdy dzień
zwłoki, licząc od upływu terminu wykonania przedmiotu umowy wskazanego w § 3
ust. 1 niniejszej umowy.
b)
za odstąpienie od umowy z przyczyn, za które odpowiedzialność ponosi
Wykonawca
w wysokości 10% wynagrodzenia umownego netto, o którym mowa w § 7 ust. 1.
c)
za niedotrzymanie terminów reakcji na wezwania związane z awarią
Oprogramowania Aplikacyjnego objętego niniejszą umową lub odmowę udzielenia
pomocy, w przypadku problemów wynikających z niewłaściwej pracy
Oprogramowania Aplikacyjnego objętego niniejszą umową, Zamawiający może
naliczyć Wykonawcy karę umowną dla każdego zgłoszenia, w następującej
wysokości:
(1) w przypadku sytuacji opisanej powyżej i dotyczącej tzw. błędu krytycznego
(tj. uniemożliwiającego korzystanie z Oprogramowania Aplikacyjnego
objętego niniejszą umową) – 0,1% wartości wynagrodzenia netto określonego
§ 13.
1.
12
(2)
w §7 ust.1 za każdy dzień zwłoki;
w przypadku sytuacji opisanej powyżej i dotyczącej tzw. „błędu zwykłego” 0,05% wartości wynagrodzenia netto określonego w §7 ust.1 za każdy dzień
zwłoki.
Postanowienia końcowe
Wszelkie zmiany niniejszej umowy wymagają formy pisemnej pod rygorem nieważności.
W sprawach nieuregulowanych niniejszą umową mają zastosowanie odpowiednie przepisy
prawa polskiego w szczególności Kodeksu spółek handlowych, Kodeksu cywilnego oraz
ustawy z 4 lutego 1994 roku o prawie autorskim i prawach pokrewnych (Dz. U. 2006 r. Nr
90 poz. 631).
Sprawy mogące wyniknąć na tle niniejszej umowy będą rozstrzygane przez sąd właściwy
dla siedziby Zamawiającego.
Umowa została sporządzona w dwóch jednobrzmiących egzemplarzach, po jednym
egzemplarzu dla każdej ze Stron.
Załączniki nr 1, 2, 3, 4, 5, 6, 7 stanowią integralną cześć umowy.
§ 14.
1.
2.
3.
4.
5.
Zamawiający:
Wykonawca:
13
ZAŁĄCZNIK NR 1
do UMOWY nr ……………………..
na wdrożenie oprogramowania, udzielenie licencji i objęcie nadzorem autorskim
SZCZEGÓŁOWE ZESTAWIENIE SKŁADNIKÓW PRZEDMIOTU UMOWY
Nr
zadania
1
2
3
4
5
6
7
Cena
netto [zł]
Nazwa zadania
Podatek VAT
[zł]
Cena brutto
[zł]
Przygotowanie
projektów
wykonawczych
oprogramowania
typu
HIS,
RIS,
LIS
i
Zaopatrzeniowego
Dostawa licencji oprogramowania
typu HIS
Dostawa licencji oprogramowania
typu RIS
Dostawa licencji oprogramowania
typu LIS
Dostawa licencji oprogramowania
typu Zaopatrzeniowego
Instalacja oprogramowania typu
HIS, RIS, LIS i Zaopatrzeniowego
Integracja oprogramowania typu
HIS, RIS, LIS i Zaopatrzeniowego
Razem:
RAZEM słownie netto:
RAZEM słownie brutto:
…………………………………………………… złotych,
…………………………………………………… złotych.
1
ZAŁĄCZNIK NR 2
do UMOWY nr ……………………..
na wdrożenie oprogramowania, udzielenie licencji i objęcie nadzorem autorskim
WARUNKI UDZIELENIA LICENCJI
A
Przedmiot
umowy
Na podstawie niniejszej umowy, Wykonawca udziela Zamawiającemu
niewyłącznej, nieograniczonej w czasie, odwołalnej, licencji na korzystanie z
poszczególnych Modułów Oprogramowania Aplikacyjnego określonych w pkt. C
wyłącznie na terytorium Rzeczypospolitej Polskiej, na polach eksploatacji
wymienionych w pkt. D.
Oprogramowanie Aplikacyjne objęte jest do dnia 30.09.2020r. gwarancyjnym
nadzorem autorskim Wykonawcy, na zasadach określonych w załączniku nr 6
B Nadzór Autorski do Umowy, pod warunkiem posiadania w tym czasie ważnej umowy nadzoru
autorskiego na moduły współpracujące z przedmiotowym oprogramowaniem
Zintegrowanego Szpitalnego Systemu Informacyjnego …………………………..
Lp
.
Oprogramowani
C
e Aplikacyjne
Liczba
Nazwanych
Użytkowników
(NU)
Nazwa Modułu /
Funkcjonalności
oznaczenie Systemu
1.
Izba Przyjęć
bez limitu
2.
Oddział szpitalny
bez limitu
3.
Symulator JGP
bez limitu
4.
5.
Statystyka Medyczna
Rozliczenia z NFZ
Termin
udzielenia
licencji
po podpisaniu
protokołu
odbioru
po podpisaniu
protokołu
odbioru
po podpisaniu
protokołu
odbioru
bez limitu
po podpisaniu
protokołu
odbioru
bez limitu
po podpisaniu
protokołu
odbioru
6.
Apteka Szpitalna
bez limitu
7.
Apteczka Oddziałowa
bez limitu
1
Wersja
bazodanowa
po podpisaniu
protokołu
odbioru
po podpisaniu
protokołu
odbioru
8.
Zlecenia medyczne
bez limitu
9.
Punkt Pobrań
bez limitu
10. Bank Krwi
11.
bez limitu
Pracownia
Diagnostyczna
bez limitu
12. Blok Operacyjny
bez limitu
Dokumentacja
Medyczna
Obchód (aplikacja
14.
mobilna)
13.
bez limitu
bez limitu
15. e-Rejestracja
bez limitu
16. e-Kontrahent
bez limitu
Konfigurator do e17. Rejestracji i eKontrahenta
bez limitu
18. Przychodnia Rejestracja
bez limitu
Przychodnia Gabinet
Lekarski
bez limitu
19.
20. Przychodnia Statystyka
bez limitu
21. Kolejki Oczekujących
bez limitu
22. Deklaracje POZ
bez limitu
23. Rehabilitacja
bez limitu
24.
Pracownia
Patomorfologii
bez limitu
25. Zakażenia Szpitalne
bez limitu
26. Dializy
bez limitu
27. Transport sanitarny
bez limitu
Sprzedaż Usług
Medycznych
bez limitu
28.
29. Rejestr Sprzedaży
bez limitu
2
po podpisaniu
protokołu
odbioru
po podpisaniu
protokołu
odbioru
30. Kasa
31.
bez limitu
Kalkulacja Kosztów
Leczenia
bez limitu
Wycena Kosztów
Normatywnych
Elektroniczna
33. Dokumentacja
Medyczna
32.
bez limitu
bez limitu
System Informacji
bez limitu
Zarządczej
Zwielokrotnienie Modułów Oprogramowania Aplikacyjnego w
pamięci komputerów i korzystanie z Modułów Oprogramowania
Aplikacyjnego przez liczbę Nazwanych Użytkowników lub na
ograniczonej ilości Dedykowanych Stacji Roboczych, określonych
dla każdego Modułu w pkt C. )
Instalacja na twardych dyskach Dedykowanych Stacji Roboczych, z
zastrzeżeniem, że za Dedykowaną Stację Roboczą uznaje się
komputer klasy PC udostępniony przez Zamawiającego do pracy
przedmiotowych Modułów Oprogramowania Aplikacyjnego.
Instalacja
na
serwerze
sieciowym
Zamawiającego
z
udostępnieniem dla ilości Nazwanych Użytkowników lub na
ograniczoną ilość Dedykowanych Stacji Roboczych, określonych w
pkt C dla każdego Modułu Oprogramowania Aplikacyjnego.
Sporządzenie 1 kopii zapasowej (-ych) każdego nośnika
Oprogramowania Aplikacyjnego.
34.
D
E
Pola
eksploatacji
Czas
eksploatacji
Tak
Tak
Tak
Tak
Nieoznaczony
Sublicencja
Niedopuszczalna
F
Przeniesienie
Niedopuszczalne
licencji
G Wynagrodzenie Opłata licencyjna Zgodnie z załącznikiem nr 1 do niniejszej umowy.
Zamawiający zobowiązuje się zorganizować i utrzymywać środki bezpieczeństwa zapobiegające
H jakiemukolwiek nieautoryzowanemu wykorzystaniu Oprogramowania Aplikacyjnego wskazanego w
pkt. C niniejszej umowy.
Postanowienia
Dodatkowe
3
Z Oprogramowania Aplikacyjnego mogą korzystać wyłącznie Nazwani Użytkownicy, którzy uzyskali
uprawnienia do korzystania z Oprogramowania Aplikacyjnego. Korzystanie przez inną osobę niż
Nazwany Użytkownik z Oprogramowania Aplikacyjnego przy wykorzystaniu login’u (identyfikatora) i
hasła Nazwanego Użytkownika stanowi naruszenie warunków niniejszej umowy. Zamawiający nie
ma prawa do dokonywania modyfikacji, zmian układu czy jakichkolwiek zmian programów
komputerowych Oprogramowania Aplikacyjnego, za wyjątkiem realizacji praw licencjobiorcy
przyznanych bezwzględnie obowiązującymi przepisami prawa. Zmodyfikowane przez
Zamawiającego programy komputerowe Oprogramowania Aplikacyjnego, w zakresie w jakim
zostały zmodyfikowane, nie są objęte gwarancyjnym nadzorem autorskim Wykonawcy.
Wykonawca nie odpowiada za szkody, jakie Zamawiający poniósł w związku z korzystaniem z
Oprogramowania Aplikacyjnego, z wyjątkiem przypadków, gdy taką odpowiedzialność przewidują
bezwzględnie obowiązujące przepisy prawa. Wykonawca odpowiada za wady fizyczne nośnika
(CD, DVD), na którym dostarczono Oprogramowanie Aplikacyjne.
Wykonawca nie ponosi odpowiedzialności za:
a) skutki korzystania z Oprogramowania,
b) jakiekolwiek szkody wynikłe z nieprawidłowego działania lub zaprzestania funkcjonowania
Oprogramowania Aplikacyjnego związane z nieprawidłowym korzystaniem z
Oprogramowania Aplikacyjnego;
c) korzystanie z Oprogramowania Aplikacyjnego przez osoby nieupoważnione;
d) dokonywanie modyfikacji Oprogramowania Aplikacyjnego przez osoby inne niż
upoważnione przez Wykonawcę;
e) udostępnienie hasła lub jakichkolwiek innych informacji identyfikujących Użytkownika;
f) wadliwe działanie sieci telekomunikacyjnej;
g) nieprawidłowe działanie lub brak działania Oprogramowania Aplikacyjnego osób trzecich,
komunikującego się z oprogramowaniem Wykonawcy;
h) nieautoryzowaną ingerencję Zamawiającego lub osób trzecich w struktury baz danych
Oprogramowania Aplikacyjnego;
i) siłę wyższą;
Odpowiedzialność odszkodowawcza Wykonawcy ogranicza się do rzeczywistej straty, bez
utraconych korzyści Zamawiającego. Odpowiedzialność odszkodowawcza Wykonawcy
ograniczona także jest do 50% wartości wynagrodzenia należnego Wykonawcy z tytułu udzielenia
licencji.
Strony oświadczają, że wszelka odpowiedzialność Wykonawcy z tytułu rękojmi za wady fizyczne na
podstawie art. 55 ustawy o prawie autorskim i prawach pokrewnych jak i na podstawie
jakiegokolwiek tytułu prawnego, ulega wyłączeniu.
Wykonawca może rozwiązać niniejszą umowę licencyjną bez zachowania terminów
wypowiedzenia, gdy Zamawiający:
I a) narusza warunki niniejszej umowy licencji w odniesieniu do miejsca, zakresu lub sposobu
korzystania z każdego z Modułów Oprogramowania Aplikacyjnego lub jego części;
b) opóźnia się w zapłacie wynagrodzenia określonego w niniejszej umowie za okres
4
przekraczający 14 dni;
c) uniemożliwia przedstawicielom Wykonawcy sprawdzenie sposobu wykorzystywania
Oprogramowania Aplikacyjnego;
d) w inny sposób narusza prawa autorskie do Oprogramowania Aplikacyjnego lub postanowienia
niniejszej umowy.
W terminie 14 dni od rozwiązania umowy, Zamawiający ma obowiązek zaprzestania korzystania z
Oprogramowania Aplikacyjnego - w tym celu Zamawiający ma obowiązek usunięcia
Oprogramowania Aplikacyjnego z serwerów oraz stacji roboczych, na których zostało ono
zainstalowane a także zwrócenia nośników Oprogramowania Aplikacyjnego i wszystkich jego kopii.
Art. 59 ustawy o prawie autorskim i prawach pokrewnych nie stosuje się.
Wszelkie zmiany niniejszej umowy winny być dokonywane w formie pisemnej pod
rygorem nieważności.
J
Postanowieni W zakresie nieuregulowanym niniejszą umową zastosowanie mają przepisy prawa
a końcowe
polskiego, w szczególności Kodeksu cywilnego i ustawy z 4 lutego 1994 o prawie
autorskim i prawach pokrewnych (Dz. U. 2006 r. Nr 90 poz. 631 z późniejszymi
zmianami).
5
ZAŁĄCZNIK NR 3
do UMOWY nr ……………………..
na wdrożenie oprogramowania, udzielenie licencji i objęcie nadzorem autorskim
MINIMALNE oraz ZALECANE WYMAGANIA SPRZĘTOWE
Wykonawca poda minimalne i zalecane
wymagania sprzętowe dotyczące
przedmiotowego Oprogramowania
Aplikacyjnego.
1
ZAŁĄCZNIK NR 4
do UMOWY nr ……………………..
na wdrożenie oprogramowania, udzielenie licencji i objęcie nadzorem autorskim
SZCZEGÓŁOWY HARMONOGRAM PŁATNOŚCI
1.
Rozliczenie wynagrodzenia za przedmiot niniejszej umowy nastąpi na podstawie
faktury wystawionej po realizacji przedmiotu umowy, na podstawie protokołu odbioru.
a)
faktura na kwotę: ……………… zł netto + podatek VAT tytułem udzielenia
licencji na Oprogramowanie Aplikacyjne (po dostarczeniu kluczy licencyjnych i
certyfikatu licencji Oprogramowania Aplikacyjnego, potwierdzonym stosownym
protokołem),
1
ZAŁĄCZNIK NR 5
do UMOWY nr ……………………..
na wdrożenie oprogramowania, udzielenie licencji i objęcie nadzorem autorskim
RAMOWY HARMONOGRAM USŁUG WDROŻENIOWYCH I DOSTAW
W zakresie Zadania nr 1 - do 31.08.2015 r.;
W zakresie Zadania nr 2-7 - do 29.09.2015 r.
Wykonawca przygotuje stosowną propozycję harmonogramu do zaakceptowania
Zamawiającego
1
ZAŁĄCZNIK NR 6
do UMOWY nr ……………………..
na wdrożenie oprogramowania, udzielenie licencji i objęcie nadzorem autorskim
SZCZEGÓŁOWE ZASADY REALIZACJI NADZORU AUTORSKIEGO
§ 1.
Przedmiot Umowy
Przedmiotem niniejszej Umowy jest objęcie nadzorem autorskim, w zakresie wskazanym w
§2 niniejszej Umowy modułów Oprogramowania aplikacyjnego (oprogramowanie typu HIS,
RIS, LIS i Zaopatrzeniowe) ……………………………………… wymienionych w Załączniku nr
1 do niniejszej Umowy (dalej: „Oprogramowanie Aplikacyjne”).
Zobowiązania Wykonawcy
1) W ramach nadzoru autorskiego, o którym mowa w §1 niniejszej Umowy, Wykonawca
zapewnia:
a) udostępnienie poprawek do Oprogramowania Aplikacyjnego, w przypadku
stwierdzenia przez Zamawiającego błędu Oprogramowania Aplikacyjnego (tzn. nie
spowodowanego przez Zamawiającego powtarzalnego działania Oprogramowania
Aplikacyjnego, w tym samym miejscu programu, prowadzącego w każdym przypadku
do otrzymania błędnych wyników jego działania):
i) w przypadku tzw. błędu krytycznego, tj. takiego, który uniemożliwia użytkowanie
Oprogramowania Aplikacyjnego (w zakresie jego podstawowej funkcjonalności
wskazanej w dokumentacji użytkownika) i prowadzi do zatrzymania jego
eksploatacji, utraty danych lub naruszenia ich spójności, w wyniku których
niemożliwe jest prowadzenie działalności z użyciem Oprogramowania
Aplikacyjnego:
(1) czas reakcji Wykonawcy na zgłoszenie Zamawiającego (tj. czas od
otrzymania zgłoszenia do chwili podjęcia przez Wykonawcę czynności
zmierzających do naprawy zgłoszonego „błędu krytycznego”) wynosi 1 dzień
roboczy;
(2) czas dokonania i udostępnienia Zamawiającemu odpowiednich korekt
Oprogramowania Aplikacyjnego wyniesie do 3 dni roboczych od chwili
rozpoczęcia czynności serwisowych;
(3) w przypadku wystąpienia „błędu krytycznego” Wykonawca może wprowadzić
tzw. rozwiązanie tymczasowe, doraźnie rozwiązujące problem błędu
krytycznego; w takim przypadku dalsza obsługa usunięcia dotychczasowego
błędu krytycznego będzie traktowana jako błąd zwykły;
ii) w pozostałych przypadkach:
§ 2.
1
(1) czas reakcji Wykonawcy na zgłoszenie Zamawiającego (tj. czas od
otrzymania zgłoszenia do chwili podjęcia przez Wykonawcę czynności
zmierzających do naprawy zgłoszonego błędu zwykłego) wynosi do 15 dni
roboczych;
(2) czas dokonania i udostępnienia Zamawiającemu odpowiednich korekt
Oprogramowania Aplikacyjnego wyniesie do 60 dni roboczych od chwili
rozpoczęcia czynności serwisowych;
iii) w wyjątkowych wypadkach, za zgodą Zamawiającego, czas dokonania korekt
będzie uzgodniony pomiędzy Wykonawcą i Zamawiającym;
iv) Wykonawca wymaga udostępnienia przez Zamawiającego zdalnego dostępu do
baz danych i Oprogramowania Aplikacyjnego. Zasady zdalnego dostępu określa
Załącznik nr 4 do niniejszej Umowy.
v) zgłoszenie błędu przez Zamawiającego odbywać się będzie poprzez witrynę
internetową Centralnego Help-Desku Wykonawcy ………………………………; w
razie trudności z rejestracją zgłoszenia na w/w witrynie internetowej, Zamawiający
może dokonać zgłoszenia telefonicznie pod numerem telefonu:
(1) ………………………………… – …………………………………
(2) ………………………………… – …………………………………
lub pisemnie na formularzu przesyłanym za pomocą poczty elektronicznej na
adres
………………………………….,
opcjonalnie
faksem
na
numer
…………………………., wzór formularza stanowi Załącznik nr 2 do niniejszej
Umowy; wypełnienie jednego formularza może dotyczyć tylko jednego rodzaju
problemu występującego w konkretnym module;
(1) w przypadku, gdy formularz zgłoszenia błędu zostanie przyjęty przez
Wykonawcę:
(a) w godzinach pomiędzy 16.00 a 24.00 dnia roboczego – traktowany jest jak
przyjęty o godz. 8.00 następnego dnia roboczego;
(b) w godzinach pomiędzy 0.00 a 8.00 dnia roboczego - traktowany jest jak
przyjęty o godz. 8.00 danego dnia roboczego;
(c) w dniu ustawowo lub dodatkowo wolnym od pracy - traktowany jest jak
przyjęty o godz. 8.00 najbliższego dnia roboczego;
b) wprowadzanie zmian w Oprogramowaniu Aplikacyjnym w zakresie dotyczącym
istniejących funkcjonalności, objętych niniejszą Umową, w zakresie wymaganym
zmianami powszechnie obowiązujących przepisów prawa lub przepisów prawa
wewnętrznie obowiązujących wydanych na podstawie delegacji ustawowej, z
zastrzeżeniem, że Wykonawca zobowiązany jest do:
i) przekazania Zamawiającemu informacji o nowych wersjach Oprogramowania
Aplikacyjnego, ukazujących się do czterech (4) razy w roku, co odbywać się
będzie poprzez wysłanie pocztą elektroniczną na adres e-mail Zamawiającego
2
wskazany w Załączniku nr 3 do niniejszej umowy (Informacje o Zamawiającym)
opublikowanie odpowiedniego komunikatu na witrynie Centralnego Help-Desku;
ii) udostępniania uaktualnień Oprogramowania Aplikacyjnego (nowych wersji
Oprogramowania
Aplikacyjnego)
poprzez
serwer
ftp:
…………………………………………………,
c) możliwość pisemnego zgłoszenia uwag i propozycji modyfikacji Oprogramowania
Aplikacyjnego poprzez witrynę Centralnego Help- Desku, lub na formularzu, którego
wzór stanowi Załącznik nr 2 do niniejszej Umowy; zgłoszenia takie wynikają z
zobowiązania Wykonawcy do dokonywania rozwoju Oprogramowania Aplikacyjnego,
o którym mowa w punkcie poprzedzającym, będą one rozpatrywane w czasie prac
analitycznych przy rozwoju Oprogramowania Aplikacyjnego;
d) gotowość przyjmowania i rozpatrywania indywidualnych żądań zmian (tj. modyfikacji
płatnych) Oprogramowania Aplikacyjnego objętego niniejszą Umową (propozycji jego
udoskonaleń, modyfikacji i rozwoju), oraz zmian w Oprogramowaniu Aplikacyjnym w
odniesieniu do dodania nowej funkcjonalności, w zakresie wymaganym zmianami
powszechnie obowiązujących przepisów prawa lub przepisów prawa wewnętrznie
obowiązujących, wydanych na podstawie delegacji ustawowej, przy czym realizacja
powyższych żądań nie będzie wchodziła w zakres niniejszej Umowy; zgłoszenia
żądania zmiany należy dokonywać poprzez witrynę Centralnego Help-Desku lub na
formularzu, którego wzór stanowi Załącznik nr 2 do niniejszej Umowy, z
zastrzeżeniem, że zasady realizacji zgłoszonych żądań będą każdorazowo
uzgadniane pomiędzy Wykonawcą i Zamawiającym.
§ 3. Zobowiązania Zamawiającego
1) Zamawiający jest zobowiązany do:
a) wyznaczenia osoby odpowiedzialnej za realizację całości niniejszej Umowy, dane tej
osoby zostały wskazane w Załączniku nr 3 do niniejszej umowy (Informacje o
Zamawiającym), oraz powiadomienia Wykonawcy o każdej zmianie tej osoby (w
formie pisemnej lub elektronicznej);
b) wykonywania niezwłocznie czynności zaleconych przez Wykonawcę, w
szczególności czynności związanych z bezpieczeństwem pracy systemu i
bezpieczeństwem danych gromadzonych w systemie funkcjonującym u
Zamawiającego, w tym w Oprogramowaniu Aplikacyjnym;
c) powstrzymania się od samodzielnego lub przy udziale osób trzecich dokonywania
jakichkolwiek zmian w konfiguracji oprogramowania (zgodnie z art. 74 ust. 4 pkt 2
ustawy o prawie autorskim i prawach pokrewnych) lub sprzętu komputerowego, na
którym wykorzystywane jest Oprogramowanie Aplikacyjne objęte niniejszą Umową, w
tym Zamawiający zobowiązuje się nie dokonywać nieautoryzowanych przez
Wykonawcę modyfikacji zawartości baz danych Oprogramowania Aplikacyjnego; w
przypadku zaistnienia takiej potrzeby Wykonawca dopuszcza zmiany konfiguracji
Oprogramowania Aplikacyjnego lub sprzętu komputerowego, ale muszą one zostać
3
wcześniej zgłoszone Wykonawcy, a wszelkiego rodzaju zmiany muszą być
wykonywane za uprzednią wyraźną zgodą Wykonawcy lub przez Autoryzowanego
Partnera Serwisowego Wykonawcy. Aktualna lista Autoryzowanych Partnerów
Serwisowych
zamieszczona
jest
na
witrynie
internetowej
…………………………………………………..;
d) prowadzenia rejestru kontaktów z Wykonawcą, obejmującego w szczególności
rozmowy telefoniczne, wysyłane faksy i pisma, zmiany konfiguracji Oprogramowania
Aplikacyjnego oraz wykonane czynności;
e) dostarczenia na wniosek Wykonawcy wskazanych fragmentów lub całości baz
danych Oprogramowania Aplikacyjnego, w przypadku uzasadnionej potrzeby ich
użycia do prawidłowej realizacji przedmiotu niniejszej Umowy poza siedzibą
Zamawiającego przy zachowaniu poniższej procedury:
i) Uprawiony pracownik Zamawiającego przekaże bazę danych Wykonawcy
poprzez jej skopiowanie na serwer SFTP o adresie ………………………….., w
pliku archiwum (np. w formacie zip) zabezpieczonym hasłem (minimum 12
znakowym, uwzględniającym minimum 2 znaki specjalne i minimum 2 cyfry).
Hasło do pliku archiwum zawierającego bazę danych będzie przekazywane
SMS'em osobie ze Strony Wykonawcy, która wnioskowała o udostępnienie bazy
danych. Zaszyfrowany plik archiwum z bazą danych będzie skopiowany przez
pracownika Zamawiającego do katalogu domowego Zamawiającego na
wskazanym wyżej serwerze SFTP, skąd będzie go mógł pobrać pracownik
Wykonawcy, wnioskujący o udostępnienie bazy danych.
ii) Uprawiony pracownik Zamawiającego przekaże bazę danych Autoryzowanemu
Przedstawicielowi Wykonawcy poprzez jej skopiowanie na serwer SFTP o adresie
………………………………… w pliku archiwum (np. w formacie zip)
zabezpieczonym hasłem (minimum 12 znakowym, uwzględniającym minimum 2
znaki specjalne i minimum 2 cyfry). Hasło do pliku archiwum zawierającego bazę
danych będzie przekazywane SMS'em osobie ze Strony Autoryzowanego
Przedstawiciela Wykonawcy, która wnioskowała o udostępnienie bazy danych.
Zaszyfrowany plik archiwum z bazą danych będzie skopiowany przez pracownika
Zamawiającego do katalogu domowego Zamawiającego na wskazanym wyżej
serwerze SFTP, skąd będzie go mógł pobrać pracownik Autoryzowanego
Przedstawiciela Wykonawcy, wnioskujący o udostępnienie bazy danych.
iii) Listę osób mogących wnioskować o udostępnienie bazy danych ze Strony
Wykonawcy, przy użyciu indywidualnego konta na serwerze SFTP, o którym
mowa w pkt i (wraz z adresem e-mail oraz numerem telefonu komórkowego),
zawiera załącznik nr 4 do niniejszej Umowy;
iv) Listę osób mogących wnioskować o udostępnienie bazy danych ze Strony
Autoryzowanego Przedstawiciela Wykonawcy, przy użyciu indywidualnego konta
4
f)
g)
h)
i)
j)
k)
l)
m)
na serwerze SFTP, o którym mowa w pkt ii (wraz z adresem e-mail oraz
numerem telefonu komórkowego), zawiera załącznik nr 4 do niniejszej Umowy;
v) Listę osób mogących udostępniać bazę danych ze Strony Zamawiającego, przy
użyciu indywidualnego konta na serwerze SFTP, o którym mowa w pkt i) oraz pkt
ii), (wraz z adresem e-mail i numerem telefonu komórkowego), zawiera załącznik
nr 3 do niniejszej Umowy;
vi) Dostęp do serwerów SFTP wymaga uwierzytelnienia identyfikatorem i hasłem.
Każdy użytkownik zarówno ze strony Zamawiającego, Wykonawcy jak i
Autoryzowanego Przedstawiciela Wykonawcy, chcący skorzystać z zasobów
serwera i mając do tego uprawnienie wynikające ze wskazania go w załączniku
odpowiednio nr 3 i nr 4, będzie zobowiązany do posiadania własnego
identyfikatora..
delegowania i upoważnienia pracowników do współpracy z Wykonawcą w zakresie
potrzebnym do świadczenia usług określonych niniejszą umową;
zapewnienia, aby Oprogramowanie Aplikacyjne, zainstalowane u Zamawiającego,
wymienione w Załączniku nr 1 było używane wyłącznie przez użytkowników
upoważnionych przez Zamawiającego do korzystania z ww. oprogramowania zgodnie
z dokumentacją i instrukcjami Wykonawcy;
dokonywania zgłoszeń ewentualnych błędów zgodnie z niniejszą Umową oraz
dostarczania Wykonawcy rzetelnych i wyczerpujących informacji o stanie
Oprogramowania Aplikacyjnego i o zamiarach wprowadzenia zmian w działalności
Zamawiającego (z odpowiednim wyprzedzeniem) oraz materiałów potrzebnych do
wykonania usług w zakresie niniejszej umowy;
przekazywania na bieżąco Wykonawcy wszystkich przepisów i regulaminów
obowiązujących u Zamawiającego, które mogą mieć zastosowanie w realizacji
niniejszej Umowy, 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);
zapewnienia Wykonawcy możliwości stałego dostępu do Oprogramowania
Aplikacyjnego objętego zakresem, określonym w §2 niniejszej umowy, w tym pracy w
godzinach popołudniowych i wieczornych, a także zapewnienia obecności w tym
czasie, upoważnionego przedstawiciela Zamawiającego;
udostępnienia Wykonawcy sprzętu komputerowego i Oprogramowania Aplikacyjnego
Zamawiającego lub oprogramowania osób trzecich w zakresie potrzebnym do
świadczenia usług określonych w §2 niniejszej umowy;
zapewnienia pracownikom Wykonawcy warunków do świadczenia usług określonych
w §2 niniejszej umowy, z uwzględnieniem obowiązujących u siebie przepisów BHP;
zapewnienia zdalnego dostępu do Oprogramowania Aplikacyjnego objętego usługami
określonymi w §2 niniejszej umowy, o ile to będzie konieczne.
5
2) Jeśli Zamawiający nie wywiąże się z obowiązków wymienionych powyżej,
okoliczność ta traktowana będzie jako zwłoka Zamawiającego, a Wykonawca nie
ponosi odpowiedzialności za dotrzymanie terminów przewidzianych Umową.
Okres obowiązywania Umowy
Niniejsza umowa została zawarta na czas określony od … do:.
§ 4.
Odpowiedzialność Wykonawcy
1) Wykonawca nie ponosi odpowiedzialności za:
a) treść i integralność danych, otrzymywanych i przechowywanych przez użytkownika
lub administratora Zamawiającego;
b) jakiekolwiek szkody wynikłe z nieprawidłowego działania lub zaprzestania
funkcjonowania Oprogramowania Aplikacyjnego związane z nieprawidłowym
korzystaniem z Oprogramowania Aplikacyjnego;
c) korzystanie z Oprogramowania Aplikacyjnego przez osoby nieupoważnione;
d) dokonywanie modyfikacji Oprogramowania Aplikacyjnego przez osoby inne niż
upoważnione przez Wykonawcę;
e) udostępnienie hasła lub jakichkolwiek innych informacji identyfikujących użytkownika
lub administratora Zamawiającego względem Wykonawcy, włącznie z treścią
wiadomości przekazywanych przez użytkownika lub przez niego odbieranych,
osobom upoważnionym na podstawie właściwych przepisów prawa lub regulaminów
Wykonawcy oraz umów z podmiotami trzecimi, które biorą udział w świadczeniu
usług;
f) wadliwe działanie sieci telekomunikacyjnej;
g) nieprawidłowe działanie lub brak działania Oprogramowania Aplikacyjnego,
spowodowane nieprawidłowym działaniem lub brakiem działania oprogramowania
osób trzecich, komunikującego się z oprogramowaniem Wykonawcy;
h) nieprawidłowe działanie lub brak działania oprogramowania osób trzecich
komunikującego się z oprogramowaniem Wykonawcy;
i) nieautoryzowaną ingerencję Zamawiającego lub osób trzecich w struktury baz
danych Oprogramowania Aplikacyjnego;
j) siłę wyższą.
§ 5.
6
ZAŁĄCZNIK NR 7
do UMOWY nr ……………………..
na wdrożenie oprogramowania, udzielenie licencji i objęcie nadzorem autorskim
SPECYFIKACJA FUNKCJONALNA OPROGRAMOWANIA APLIKACYJNEGO
1
Download