ZP/11/HIS+ERP/2020/UE



NIP: 1132866688 REGON: 012298823


SPECYFIKACJA ISTOTNYCH WARUNKÓW ZAMÓWIENIA

dla zamówienia publicznego dokonywanego w trybie przetargu nieograniczonego


na dostawę i wdrożenie systemu informatycznego e-Usługi wraz z modernizacją lub wymianą zintegrowanego systemu zarządzania (HIS + ERP), systemów

powiązanych i sprzętu


ZP/11/HIS+ERP/2020/UE


w ramach projektu współfinansowanego z funduszy europejskich w ramach Regionalnego Programu Operacyjnego Województwa Mazowieckiego

na lata 2014-2020 (RPO WM 2014-2020)

„Rozwój e-usług poprzez rozbudowę systemu informatycznego

w Szpitalu Praskim p.w. Przemienienia Pańskiego Sp. z o.o. w Warszawie”


Termin składania ofert: 22.04.2020 r. ,godz. 10:00 Termin otwarcia ofert: 22.04.2020 r. ,godz. 10:30

Podstawa prawa:

Ustawa z dnia 29 stycznia 2004 r. – Prawo zamówień publicznych – tekst jednolity (Dz. U. 2019 r. poz. 1843), zwana dalej „ustawą” oraz zgodnie z wydanymi na jej podstawie rozporządzeniami wykonawczymi.

Postępowanie o udzielenie zamówienia publicznego prowadzone jest w trybie przetargu nieograniczonego (art. 39 ustawy) o wartości zamówienia większej od kwoty określonej w przepisach wydanych na podstawie art. 11 ust.8.

1 INFORMACJE O ZAMAWIAJĄCYM.

SZPITAL PRASKI P.W. PRZEMIENIENIA PAŃSKIEGO SPÓŁKA Z OGRANICZONĄ ODPOWIEDZIALNOŚCIĄ

Xxxxx Xxxxxxxxxxxx 00, 00-000 Xxxxxxxx


nr tel.: 00 000 00 00 (centrala), 22 555 11 54 (Dział Zamówień Publicznych) e-mail: xxxxxxxxxx@xxxxxxxxxxxxx.xx

adres strony internetowej Zamawiającego: xxx.xxxxxxxxxxxxx.xx


2 TRYB UDZIELENIA ZAMÓWIENIA.

1. Postępowanie o udzielenia zamówienia publicznego prowadzone jest w trybie przetargu nieograniczonego, o wartości przekraczającej kwoty określone w przepisach wydanych na podstawie art. 11 ust.8Ustawy z dnia 29 stycznia 2004 roku Prawo zamówień publicznych (Dz. U. 2018 r. poz. 1986), zwaną dalej „ustawą Pzp”.

2. W zakresie nieuregulowanym w niniejszej Specyfikacji Istotnych Warunków Zamówienia, zwanej dalej

„SIWZ”, mają zastosowanie przepisy ustawy Pzp i wydanych do niej aktów wykonawczych.


3 SŁOWNIK POJĘĆ



Na potrzeby SIWZ, jak i we wszystkich związanych z nią dokumentach nadaje się wymienionym niżej pojęciom następujące znaczenia:

OPZ – ogólnie opis przedmiotu zamówienia przedstawiony w tym dokumencie.

SIWZ – specyfikacja istotnych warunków zamówienia przedstawiona w tym dokumencie.

Szpital, Zamawiający – Szpitalu Praskim p.w. Przemienienia Pańskiego Sp. z o.o. w Warszawie.

Oferent, Wykonawca – podmiot składający ofertę w postępowaniu przetargowym opisanym w niniejszym dokumencie.

Użytkownik - oznacza osobę należącą do personelu Zamawiającego, posiadającą uprawnienia do korzystania wdrażanego Oprogramowania Aplikacyjnego.

Stacja Robocza - Oznacza komputery klasy PC lub/i terminal z monitorem używany przez Użytkownika, na którym będzie użytkowane wdrażane Oprogramowanie Aplikacyjne ERP.

Oprogramowanie, Aplikacja, Zintegrowany System Informatyczny, ZSI - zbiór współdziałających i współpracujących ze sobą aplikacji, opisanych w niniejszym dokumencie, wykonujący swoje procedury we wzajemnej interakcji, realizujący procesy biznesowe Szpitala, będący utworem o właściwościach w rozumieniu ustawy z dnia 4 lutego 1994 r. „o prawie autorskim i prawach pokrewnych” [tj. Dz.U. 2006 nr 90 poz. 631 ze zm.], do którego prawa autorskie i majątkowe przysługują producentowi (autorowi) lub Wykonawcy, będący przedmiotem Projektu Wdrożeniowego, który zostanie zrealizowany w wyniku niniejszego postępowania.

Moduł Oprogramowania - część składowa ZSI, charakteryzująca się spójnym zakresem merytorycznym realizowanych funkcji i procesów, wykonująca swoje procedury we wzajemnej interakcji z innymi aplikacjami wchodzącymi w skład Oprogramowania Aplikacyjnego. Moduł nie jest zdolny w tym rozumieniu do samodzielnego działania w oderwaniu od innych aplikacji Oprogramowania Aplikacyjnego.

Aplikacja - część składowa ZSI, charakteryzująca się spójnym zakresem merytorycznym realizowanych funkcji i procesów, wykonująca swoje procedury we wzajemnej interakcji z innymi aplikacjami wchodzącymi w skład Oprogramowania i zdolna do samodzielnego działania w oderwaniu od innych aplikacji ZSI.

Rozwiązanie Business Intelligence, BI - System Informowania Kierownictwa klasy business intelligence (BI) oparty o wielowymiarową bazę danych typu OLAP wraz z warstwą prezentacji raportów i analiz.

Hospital Information System, HIS - część ZSI wspomagająca funkcjonowanie i zarządzanie Szpitalem w zakresie obsługi pacjenta, zarządzania ruchem chorych, obsługi procedur medycznych i procesów leczenia pacjentów, zwana też „częścią białą” ZSI.

Picture Archiving and Communication System, PACS - system informatyczny wspomagający gromadzenie, udostępnianie i wymianę obrazów medycznych.

Radiology Information System, RIS - System informatyczny wspomagający przechowywanie, przetwarzanie i udostępnianie radiologicznych obrazów medycznych.

Laboratory Information System, LIS - System informatyczny wspomagający gromadzenie, przechowywanie i przetwarzanie danych medycznych wytwarzanych przez laboratorium diagnostyki medycznej oraz zarządzanie laboratorium.

Oprogramowanie bazodanowe (motor bazy danych) - oprogramowanie umożliwiające gromadzenie, przechowywanie i udostępnianie zorganizowanych danych, najczęściej motor bazy danych typu SQL.

Oprogramowanie systemowe (system operacyjny) - oprogramowanie zarządzające systemem komputerowym, tworzące środowisko do uruchamiania i kontroli zadań użytkownika lub udostępniania usług w sieci (serwerowy system operacyjny). Serwerowy System Operacyjny jest niezbędny do prawidłowego funkcjonowania Oprogramowania Bazodanowego i ZSI.

Usługi Wdrożeniowe - oznacza wszelkie świadczenia Oferenta opisane w dokumentach SIWZ, OPZ oraz wzorze umowy realizowane w celu wdrożenia i uruchomienia Oprogramowania w przedsiębiorstwie Zamawiającego.

Projekt - zorganizowane przedsięwzięcie realizowane przez Zamawiającego zmierzające do uruchomienia w jego przedsiębiorstwie Oprogramowania składające się z Usług Wdrożeniowych realizowanych przez Wykonawcę oraz prac wykonywanych przez Xxxxxxxxxxxxx, zgodnie z przyjętą metodyką wdrożeniową.

Serwer/serwery - system komputerowy dysponujący zasobami umożliwiającymi zainstalowanie i eksploatację Oprogramowania Bazodanowego i Oprogramowania Aplikacyjnego, udostępniony(-e) Wykonawcy przez Zamawiającego, przeznaczony(-e) do gromadzenia i przetwarzania danych.

4 OPIS PRZEDMIOTU ZAMÓWIENIA.

1. Numer referencyjny postępowania: ZP/11/HIS+ERP/2020/UE.

2. Opis przedmiotu zamówienia:

1) przedmiotem zamówienia jest dostawa i wdrożenie systemu informatycznego e-Usługi wraz z modernizacją lub wymianą zintegrowanego systemu zarządzania (HIS + ERP), systemów powiązanych i sprzętu na rzecz Szpitala Praskiego p.w. Przemienienia Pańskiego Sp. z o.o. w Warszawie, którego sposób realizacji został szczegółowo opisany w Załącznikach nr 1-3 do SIWZ oraz Rozdziale SIWZ - Założenia początkowe oraz wymagania ogólne,Rozdziale SIWZ - Dostawa i wdrożenie szpitalnego systemu informatycznego, Rozdziale SIWZ - Szczegółowy opis przedmiotu zamówienia.

3. Nazwa i kod według Wspólnego Słownika Zamówień (CPV).

Zgodnie nomenklaturą CPV na przedmiot zamówienia składają się:


Główny kod CPV:

48000000-8 Pakiety oprogramowania i systemy informatyczne


Uzupełniające kody CPV:


48600000-4

Pakiety oprogramowania dla baz danych i operacyjne,

72000000-5

Usługi informatyczne: konsultacyjne, opracowywania oprogramowania, internetowe i wsparcia,

80500000-9

Usługi szkoleniowe,

72253200-5

Usługi w zakresie wsparcia systemu.


4. Zamawiający nie dopuszcza składania ofert częściowych

5. Zamawiający nie dopuszcza składania ofert wariantowych

6. Zamawiający nie przewiduje zastosowania aukcji elektronicznej przy wyborze oferty najkorzystniejszej.

7. Zamawiający zastrzega możliwość udzielenia dotychczasowemu wykonawcy dostawzamówienia na dodatkowe dostawy zgodnie z art. 67 ust. 1 pkt. 7 ustawyPzp. Warunki, na jakich zostaną udzielone wyżej wymienione zamówienia:

1) zamówienie będzie mogło być udzielone w przypadku, gdy Zamawiający będziedysponował środkami finansowymi na jego realizację;

2) umowa zostanie zawarta po przeprowadzeniu negocjacji z Wykonawcą;

3) termin wykonania zamówienia będzie proporcjonalny do zakresu zamówienia;

4) wzór umowy zostanie przekazany Wykonawcy wraz z zaproszeniem do negocjacji;

5) kary umowne będą przewidziane w takich samych wypadkach i w wysokości niewyższej jak w umowie zawartej w postępowaniu na zamówienie podstawowe;

6) obowiązki Wykonawcy i Zamawiającego będąuregulowane na zasadach analogicznychdo umowy zawartej w wyniku rozstrzygnięcia zamówienia podstawowego.

8. Zamawiający przewiduje możliwośćudzielenia zamówień, o których mowa w art. 67ust. 1 pkt. 7 ustawy w wysokości do 30 % wartości zamówienia podstawowego.

9. Jeżeli w opisie przedmiotu zamówienia wskazano jakikolwiek znak towarowy, patentczy pochodzenie – należy przyjąć, że wskazane patenty, znaki towarowe, pochodzenie określają parametry techniczne, eksploatacyjne, użytkowe, co oznacza, że Zamawiający dopuszcza złożenie oferty w tej części

przedmiotu zamówienia o równoważnych parametrach technicznych, eksploatacyjnych i użytkowych. Jednocześnie przypominamy, że zgodnie z art. ust. 5 ustawy Wykonawca, który powołuje się na rozwiązania równoważne, jest obowiązany wykazać, że oferowany przez niego przedmiot zamówienia spełnia wymagania określone przez Zamawiającego. Zamawiający wskazuje również, że użył w niniejszej treści SIWZ znaków towarowych i wskazał pochodzenie w celu opisu posiadanego środowiska informatycznego i jego komponentów.

10. Zamawiający nie przewiduje zwrotu kosztów postępowania.

11. Zamawiającyżąda od Wykonawcy wskazania w Formularzu ofertowym, jaką część zamówienia powierzy do realizacji podwykonawcom oraz podania przez Wykonawcę nazw firm podwykonawców. W przypadku pozostawienia tej części formularza ofertowego bez wypełnienia Zamawiający uzna, że Wykonawca wykona zamówienie samodzielnie, chyba że z dokumentacji załączonej do oferty będzie wynikało co innego. Wykonawca, którego oferta zostanie wybrana jako najkorzystniejsza zobowiązany będzie podać przed przystąpieniem do wykonania zamówienia, nazwy albo imiona i nazwiska oraz dane kontaktowe podwykonawców i osób do kontaktu z nimi, o ile będą już znane. Wykonawca zobowiązany będzie także do powiadamiania Zamawiającego o wszelkich zmianach danych dot. podwykonawców w trakcie realizacji zamówienia oraz przekazywać informacje na temat nowych podwykonawców, którym w późniejszym okresie zamierza powierzyć realizację części zamówienia. Jeżeli zmiana albo rezygnacja z podwykonawcy dotyczyć będzie podmiotu, na którego zasoby powoływał się Wykonawca na zasadach określonych w art. 22a ust. 1 w celu wykazania spełniania warunków udziału w postępowaniu, Wykonawca będzie zobowiązany wykazać Zamawiającemu, że proponowany inny podwykonawca lub Wykonawca samodzielnie spełnia je w stopniu nie mniejszym niż podwykonawca, na którego zasoby Wykonawca powoływał się w trakcie postępowania o udzielenie zamówienia. Powierzenie wykonania części zamówienia Podwykonawcom nie zwalnia Wykonawcy z odpowiedzialności za należyte wykonanie tego zamówienia.

12. Zamawiający żąda od Wykonawcy uczestnictwa w wizji lokalnej, w terminie wyznaczonym przez

Zamawiającego na dzień 31.03.2020 r. godz. 10:00, z zastrzeżeniem, iż zgodnie z art. 9 a ustawy Pzp oferty mogą zostać złożone jedynie po odbyciu przez wykonawcę wizji lokalnej.


5      ZAŁOŻENIA   POCZĄTKOWE   ORAZ WYMAGANIA   OGÓLNE.           


5.1 CEL PROJEKTU

Celem niniejszego projektu jest wdrożenie e-usług poprzez modernizację lub wymianę zintegrowanego systemu informatycznego, zakup i wdrożenie rozwiązań pomocniczych, integrację z pozostałymi systemami szpitala oraz systemami zewnętrznymi, a także dostawę urządzeń i oprogramowania systemowego koniecznego do realizacji projektu.

Podstawowe cele projektu oraz jego założenia zostały zawarte we wniosku o dofinansowanie Zawarte zostały w treści SIWZ.


5.2 Akty prawne

Dostarczone rozwiązania teleinformatyczne, ze szczególnym uwzględnieniem dostarczanego i wdrażanego Oprogramowania, muszą być zgodne z powszechnie obowiązującymi przepisami prawa polskiego i europejskiego. Musi pozwalać na gromadzenie, przetwarzanie i analizowanie danych i informacji w obszarach objętych wdrożeniem, na bazie tych danych musi umożliwiać wytwarzanie prawidłowej, kompletnej, ujętej w obowiązujących przepisach prawa dokumentacji (dokumenty, raporty, wykazy, oświadczenia, zaświadczenia itp.) , a w tym w szczególności z następującymi aktami prawnymi i ich późniejszymi aktualizacjami oraz aktami normatywnymi niższego rzędu wydanymi na ich podstawie, jeśli

zakres funkcjonowania systemu pokrywa się z zakresem przedmiotowym poszczególnych wymienionych aktów:

- Ustawy z dnia 15 kwietnia 2011 o działalności leczniczej (Dz. U. 2018, poz.2190),

- Ustawy z dnia 28 kwietnia 2011 o systemie informacji w ochronie zdrowia (Dz. U. 2019, poz.408),

- Ustawy z dnia 5 grudnia 1996 r. o zawodach lekarza i lekarza dentysty (Dz. U. 2019, poz.537),

- Ustawy z dnia 27 sierpnia 2004 r. o świadczeniach opieki zdrowotnej finansowanych ze środków publicznych (Dz.U. 2019, poz.1373),

- Ustawy z dnia 6 listopada 2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta (Dz.U. 2019, poz.1127),

- Ustawy o statystyce publicznej z dnia 29 czerwca 1995 r. (Dz.U.2019, poz.649)

- Ustawy o ustawa z dnia 10 maja 2018 r. o ochronie danych osobowych (Dz.U.2019.1781) ,

- Rozporządzenia Ministra Zdrowia z dnia 9 listopada 2015 r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania (Dz.U.2015, poz.2069), wraz z uwzględnieniem wdrażanych aktualizacji tego zakresu

- Rozporządzenia Ministra Zdrowia z dnia 8 maja 2018 r. w sprawie rodzajów elektronicznej dokumentacji medycznej (Dz.U.2018, poz.941)

- Rozporządzenia Ministra Zdrowia z dnia 26 czerwca 2019 r. w sprawie zakresu niezbędnych informacji przetwarzanych przez świadczeniodawców, szczegółowego sposobu rejestrowania tych informacji oraz ich przekazywania podmiotom zobowiązanym do finansowania świadczeń ze środków publicznych (Dz.U.2019, poz.1207)

- Rozporządzenia Ministra Zdrowia z dnia 8 września 2015 r.w sprawie ogólnych warunków umów o udzielanie świadczeń opieki zdrowotnej (Dz.U.2016, poz.1146),

- Rozporządzenia Ministra Zdrowia z dnia 13 kwietnia 2018 r. w sprawie recept (Dz.U.2018, poz.745),

- Rozporządzenia Ministra Zdrowia z dnia 29 marca 2019 r. w sprawie szczegółowego zakresu danych objętych wpisem do rejestru podmiotów wykonujących działalność leczniczą oraz szczegółowego trybu postępowania w sprawach dokonywania wpisów, zmian w rejestrze oraz wykreśleń z tego rejestru (Dz. U. 2019, poz.605),

- Rozporządzenia Ministra Zdrowia z dnia 17 maja 2012 r. w sprawie systemu resortowych kodów identyfikacyjnych dla zakładów opieki zdrowotnej oraz szczegółowych zasad ich nadawania (Dz.U.2019, poz.173),

- Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U.2017, poz.2247) ,

- Zarządzeń Prezesa Narodowego Funduszu Zdrowia w sprawie warunków postępowania dotyczących zawierania umów o udzielanie świadczeń opieki zdrowotnej,

- Ustawy z dnia 27 sierpnia 2009 r. o finansach publicznych (Dz.U.2019, poz.869),

- Rozporządzenia Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie

swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (Dz.U.UE.L.2016.119.1),

- Ustawy z dnia 11 marca 2004 roku o podatku od towarów i usług (Dz.U.2020.106), wraz z aktami wykonawczymi

- Ustawy z dnia 29 sierpnia 1997 r. ordynacja podatkowa (Dz.U.2019.900),

- Ustawy z dnia 29 września 1994 r. o rachunkowości(Dz.U.2019, poz.351),

- Ustawy z dnia 26 lipca 1991 r. o podatku dochodowym od osób fizycznych ( Dz.U.2019, poz.1387),

- Ustawy z dnia 15 lutego 1992 r. o podatku dochodowym od osób prawnych(Dz.U.2019, poz.865),

- Ustawy z dnia 29 lipca 2005 r. o przeciwdziałaniu narkomanii (Dz.U.2019.852),

- Ustawy z dnia 5 grudnia 2008 r. o zapobieganiu oraz zwalczaniu zakażeń i chorób zakaźnych u ludzi (Dz.U.2019.1239), wraz z aktami wykonawczymi

- Ustawy z dnia 6 września 2001 r. prawo farmaceutyczne (Dz.U.2019, poz.499).

- Ustawy z dnia 25 czerwca 1999 r. o świadczeniach pieniężnych z ubezpieczenia społecznego w razie choroby i macierzyństwa (Dz. U. z 2019 r. poz. 645).

- Ustawy z dnia 13 października 1998 r. o systemie ubezpieczeń społecznych (Dz.U.2019, poz.300).

- Ustawy 26 czerwca 1974 r. kodeks pracy (Dz.U.2019, poz.1040),

- Ustawy z dnia 8 września 2006 r. o Państwowym Ratownictwie Medycznym (Dz.U.2019, poz.993),

- Ustawy z dnia 25 września 2015 r. o zawodzie fizjoterapeuty (Dz.U.2019, poz.952),

- Ustawy z dnia 27 lipca 2001 r. o diagnostyce laboratoryjnej (Dz.U.2019, poz.849),

- Ustawy z dnia 22 sierpnia 1997 r. o publicznej służbie krwi (Dz. U. z 2019 r. poz. 1222).

Powyższy wykaz aktów prawa nie ogranicza ani nie wyłącza przepisów, które oferowane oprogramowanie musi spełniać, a odpowiedzialnością Oferenta jest zapewnienie zgodności z wymaganymi przepisami prawa stosownymi do zakresu funkcjonowania przedsiębiorstwa Zamawiającego.

W okresie gwarancji Oferent będzie zobowiązany dostosować System do zmian przepisów prawa bezpłatnie w terminie uzgodnionym z Zamawiającym, nie zakłócającym jego pracy, jednak nie dłuższym niż 90 dni od momentu uprawomocnienia się decyzji o wprowadzeniu zmian. W szczególności zobowiązuje się do dostosowania systemu do wymiany informacji z systemami centralnymi administracji rządowej i ubezpieczeniowej projektowanymi w ramach Ustawy o Systemie Informacji w Ochronie Zdrowia.


5.3 Przedmiot Zamówienia

Przedmiotem niniejszego postępowania jest wdrożenie e-Usług opisanych w dalszej treści SIWZ z programu operacyjnego RPO WM 2014-2020, a w tym wdrożenie lub wymiana następujących elementów systemów informatycznych w przedsiębiorstwie Zamawiającego:


▪ e-Usługi oraz Zintegrowany System Informatyczny

1. Modernizacji lub wymiany zintegrowanego systemu informatycznego obejmującego moduły medyczne tzw. część „białą” (HIS) w celu umożliwienia wdrożenia e-usług oraz integracją z pozostałymi elementami systemów informatycznych szpitala, a także obszaru e-zdrowie oraz z przygotowaniem

szpitalnego systemu informatycznego do planowanego wdrożenia aptecznych systemów robotycznych automatyzujących obrót produktem farmaceutycznym oraz kontrolę bezpieczeństwa, a w tym:

a. Rozbudowę systemu o moduł żywienia klinicznego;

b. Wdrożenie e-usług (e-rejestracja, e-wyniki, e-ankiety, e-kontrahent);

c. Rozbudowę systemu o moduł Elektronicznej Dokumentacji Medycznej (EDM);

d. Wdrożenie systemu zarządzania ruchem pacjentów;

e. Wdrożenie rozwiązania w udostępnionej chmurze obliczeniowej;

f. Zakup podpisów kwalifikowanych;

g. Zakup sprzętu teleinformatycznego, licencji oraz migracji danych;

h. Rozbudowę systemu o moduł logistyki obrotu produktem leczniczym oraz bezpieczeństwa farmakoterapii, w tym moduły apteczne,

i. Rozbudowę systemu o moduł wspierający zarządzanie papierowym archiwum dokumentacji medycznej.

2. Modernizacji lub wymiany modułów administracyjnych, tzw. część „szarą” (ERP), a w tym:

a. finanse i księgowość: podatkowa, statutowa, raportowanie zarządcze,

b. banki, kasy gotówkowe,

x. xxxxxxxxxxxx, należności, windykacja,

d. majątek trwały,

e. gospodarka magazynowa,

f. zapotrzebowania, zamówienia zakupu, księgowanie i rozliczenie zakupu, postępowania przetargowe, umowy z dostawcami,

g. sprzedaż pozostała, rejestracja sprzedaży detalicznej, rejestracja sprzedaży do NFZ, umowy z klientami,

x. xxxxx i płace, rozliczanie grafików i dyżurów, czasu pracy, umów cywilnoprawnych oraz kontraktów lekarskich,

i. rachunek ekonomiczny projektów i inwestycji,

x. xxxxxxxxxxxx i rozliczenie budżetu,

x. xxxxxxxxxxx z płatnikami ubezpieczeń,

l. analiza zarządcza, raportowanie statutowe i podatkowe,

m. rozwiązanie klasy BI/OLAP pozwalające na analizę zarządczą danych finansowych oraz ilościowych pochodzących z budowanego rozwiązania.

Szczegółowe wymaga dla poszczególnych elementów wyżej wymienionego rozwiązania znajdują się w dalszej części dokumentacji.

W ramach wdrożenia powyższych elementów zintegrowanego rozwiązania Zamawiający oczekuje poza realizacją wzajemnej integracji w/w elementów także integrację istniejących systemów Zamawiającego z modernizowanym rozwiązaniem, a w tym:

a) OptimedNext Dializa,

b) OptiNFZcom,

c) AlleradChazon (Pixel),

d) AlleradExhibeon (Pixel),

e) Centrum LSI (Xxxxxx),

f) Endobase (Olympus).

g) Medok (Elmi),

h) Diagnostyka,

i) System Delphyn (Serologia, Toczenia),

j) Integrację z rozwiązaniami bankowymi (ERP) w tym realizacja „Płatności podzielonej”,

k) Integrację z systemami zewnętrznymi („Biała Lista”, JPK, systemy ZUS, inne wymagane prawem),

l) Kasy fiskalne online i offline,

m) Integracja z systemem obsługującym Laboratorium Histopatologiczne w Szpitalu na Solcu w zakresie wymiany zleceń oraz wyników badań,

n) Integracja z systemami zewnętrznymi, zgodnie z wymaganiami NFZ, Państwowej Inspekcji Farmaceutycznej (ZSMOPL), Państwowej Inspekcji Sanitarnej, oraz wspomnianą wcześniej platformą e-Zdrowie (P1, P2),

o) Platforma elektronicznej wymiany faktur PEF Expert.


Zamawiający oczekuje integracji ze wszystkim systemami zewnętrznymi wymaganymi prawem na dzień uruchomienia rozwiązania (nie zależnie od obszaru).


5.3.1 System kolejkowy – zarządzanie ruchem pacjentów

System zarządzania kolejkami ma na celu sprawne zarządzanie ruchem Pacjentów w obszarze Poradni Specjalistycznych. System ma zapewnić uporządkowanie kolejności obsługi pacjentów w szpitalu poprzez kierowanie pacjenta do odpowiednich gabinetów z zachowaniem pobranego numeru kolejkowego oraz informowanie pacjentów i numerze w zajmowanych klientach do poszczególnych gabinetów.

System musi umożliwić obsługiwanie minimum (3) trzech niezależnych od siebie miejsc oczekiwania pacjentów (podsystemów). Dla każdego z tych miejsc musi istnieć możliwość skonfigurowania dowolnej

ilości kolejek do gabinetów, wspólnych lub charakterystycznych do danych podsystemów. Dla każdej z kolejki powinna istnieć możliwość nadania unikalnego w skali całego systemu skrótów, który zostanie wykorzystany w celu zmniejszenia informacji na wydrukach biletów oraz wyświetlaczach stanowiskowych.

System obejmuje kompleksowe wykonanie prac związanych z dostawą i wdrożeniem systemu zarządzania kolejkami. System ma zostać zainstalowany w Poradniach Specjalistycznych znajdujących się w obszarach wskazanych przez Zamawiającego oraz posiadać możliwość rozbudowy w przyszłości o kolejne wyświetlacze i automaty biletowe.

System zarządzania kolejkami obejmować będzie (16) szesnaście gabinetów lekarskich.


Realizacja obejmuje w szczególności:


− Dostawę i montaż sprzętu zgodnie z opisem technicznym sprzętu (pkt. Opis techniczny sprzętu),

− Dostawę i zainstalowanie licencjonowanego oprogramowania zgodnie z opisem funkcjonalnym oprogramowania (pkt Opis funkcjonalny sprzętu),

− Uruchomienie i konfigurację systemu,

− Wykonanie integracji dostarczanego systemu kolejkowego z zaoferowanym ZSI

− Przygotowanie dokumentacji użytkowej (instrukcje użytkowania systemu),

− Szkolenie pracowników z zarządzania i obsługi wdrożonego systemu kolejkowego.


▪ Integracja z centralnym systemem e-Zdrowie

Istotnym wymaganiem i założeniem niniejszego projektu i postępowania jest zapewnienie przez wdrożone rozwiązanie integracji funkcjonalnej z systemem teleinformatycznym, o którym mowa w art. 7 ust. 1 ustawy o systemie informacji w ochronie zdrowia (tj. Dz. U. z 2019 r. poz. 408 z x.xx.), co najmniej w zakresie opisanym w dokumentach: „Opis usług biznesowych Systemu P1 wykorzystywanych w systemach usługodawców” oraz „Opis funkcjonalny Systemu P1 z perspektywy integracji systemów zewnętrznych”, a także Projekt P2 ,,Platforma udostępniania on-line przedsiębiorcom usług i zasobów cyfrowych rejestrów medycznych" opublikowanych przez CSIOZ.

W zakresie integracji i komplementarności z centralnymi systemami e-zdrowia, na Oferenta będzie spoczywał obowiązek dostosowania zaoferowanego rozwiązania do wymagań ujętych w dokumentach publikowanych poprzez CSIOZ, w tym w szczególności do:

• Zakresu funkcjonalnego Projektu P1 (system musi posiadać x.xx. możliwość wystawiania recept elektronicznych oraz wystawiania i odbierania skierowań elektronicznych),

• Opisu funkcjonalnego Systemu P1 z perspektywy integracji systemów zewnętrznych,

• Minimalne wymagania dla systemów usługodawców oraz dokumentacja integracyjna dla obszaru Zdarzeń Medycznych i Indeksów EDM.

• Korzystania z rejestrów udostępnionych w ramach projektu P2 (dokument CSIOZ: „Funkcjonalności P2.docx”), w tym w szczególności ZSMOPL.

Dokumenty te dostępne są na stronie internetowej CSIOZ, pod adresem: xxxx://xxxxx.xxx.xx.

W zakresie integralności zaoferowanego Systemu, Oferent powinien uwzględnić i w razie obowiązującego wymogu wdrożyć poniższe wytyczne i założenia:

• Systemy CSIOZ dostępne będą dla odpowiednio zarejestrowanych w CSIOZ systemów usługodawców i systemów regionalnych wyłącznie poprzez standardowe interfejsy Web Services. Wymagane jest dwustronne uwierzytelnianie systemów nawiązujących komunikację, a także podpisywanie komunikatów certyfikatem dostarczanym bądź wskazanym przez CSIOZ.

• Komunikaty przesyłane do systemów e-Zdrowie muszą być podpisane elektronicznie certyfikatem wydanym przez usługodawcę rozwiązania zgodnie z aktualnie obowiązującymi wymaganiami. Wymagania w zakresie rodzaju stosowanego certyfikatu mogą ulec zmianie w wyniku wejścia w życie Rozporządzenia Parlamentu Europejskiego i Rady (UE) nr 910/2014 z dnia 23 lipca 2014r. w sprawie identyfikacji elektronicznej i usług zaufania w odniesieniu do transakcji elektronicznych na rynku wewnętrznym oraz uchylające dyrektywę 1999/93/WE (Dz.U.UE.L.2014.257.73 , tzw. rozporządzenie eIDAS) lub wprowadzenia centralnych rozwiązań w zakresie uwierzytelniania użytkowników w obszarze e-zdrowia.

• W przypadku informacji o zdarzeniu medycznym – obowiązuje Model Informacji o Zdarzeniu Medycznym i Indeksie Dokumentacji Medycznej (dalej: EDMiZM) publikowany przez CSIOZ.

• W przypadku rejestru (indeksu) elektronicznej dokumentacji medycznej – obowiązuje EDMiZM publikowany przez CSIOZ

• Zgoda pacjenta na udostępnienie jego dokumentacji medycznej – funkcjonalność ta jest wymagana i powinna być zgodna z modelem dokumentu zgody oraz modelami interfejsów pozwalających na wnioskowanie o zgodę, które zostaną opublikowane przez CSIOZ.

• Wymiana elektronicznej dokumentacji medycznej (dalej: EDM) – funkcjonalność ta jest wymagana i powinna być zgodna z modelem wniosku i dokumentu udostępnienia oraz modelami interfejsów, które zostaną opublikowane przez CSIOZ.

Jednocześnie, zaoferowany system powinien spełniać następujące założenia funkcjonalne:

• Prowadzenie i wymianę Elektronicznej Dokumentacji Medycznej (EDM), w tym indywidualnej dokumentacji medycznej (wewnętrznej, zewnętrznej), uwzględniać musi rozwiązania umożliwiające zbieranie przez podmiot udzielający świadczeń opieki zdrowotnej jednostkowych danych medycznych w elektronicznym rekordzie pacjenta oraz tworzenie EDM zgodnej co najmniej ze standardem HL7 CDA, opracowanym i opublikowanym przez CSIOZ – Polską Implementacją Krajową HL7 CDA (tzw. IG).

• System powinien uwzględniać funkcjonalności dotyczące prowadzenia repozytorium EDM (z obsługą przechowywania EDM) oraz uwzględniać rozwiązania zapewniające wymianę EDM pomiędzy repozytorium Zamawiającego a Platformą P1. Platforma P1 będzie zawierała katalog EDM, w którym znajdować się będą informacje o EDM tworzonym i przechowywanym u Zamawiającego.

• Repozytorium EDM powinno realizować, co najmniej usługę przyjmowania, archiwizacji i udostępniania EDM zgodnej z HL7 CDA, a w przypadku repozytoriów badań obrazowych, przyjmowania, archiwizacji i udostępniania obiektów DICOM.

• Zaoferowany Szpitalny System Informatyczny musi być dostosowany do współpracy z systemem, o którym mowa w art. 33a ustawy z dnia 8 września 2006r. o Państwowym Ratownictwie medycznym (Dz. U. z 2019 r. poz. 993, 1590)

• Zaoferowany Szpitalny System Informatyczny musi być dostosowany do współpracy z systemem, o którym mowa w art. 17 Ustawy z dnia 22 sierpnia 1997 r. o publicznej służbie krwi (Dz. U. z 2019 r. poz. 1222).

• Zaoferowany system musi być zintegrowany w zakresie wykorzystania Rejestrów Medycznych dostępnych w systemie P2 (xxxxx://xxxxxxxxxxxxxxxx.xxxxx.xxx.xx/) w celu weryfikacji i standaryzacji danych oraz rejestracji podmiotów lub weryfikacji podmiotów udostępnionych w ramach rejestrów e-Zdrowie, a w szczególności wykorzystania:

o Rejestru Produktów Leczniczych,

o Rejestru Systemów Kodowania,

Ale także innych rejestrów dostępnych w tym rozwiązaniu.


5.3.2 Dostawa Sprzętu Komputerowego oraz oprogramowania systemowego i narzędziowego


• Stacje robocze

Zamawiający oczekuje dostawy sprzętu komputerowego – stacji roboczych pod wdrażany system w ilości 50 szt. o parametrach optymalnych dla realizacji właściwych zadań przez użytkowników na tych stacjach, jednak nie gorszych niż podane w Załączniku nr 1 do SIWZ.


• Platforma sprzętowa i oprogramowanie systemowe

Zamawiający oczekuje dostawy podstawowej infrastruktury serwerowej pod wdrażane rozwiązanie w tym postępowaniu, w postaci serwerów fizycznych – hostów pod maszyny wirtualne, w terminie uzgodnionym z dostawcą i wymaganym do prawidłowej realizacji projektu, w ilości:

- Serwery bazodanowe – 2 szt.

- Serwery aplikacyjne – 2 szt.

zgodnych ze specyfikacją podaną w Załączniku nr 2.

Wraz z dostawą serwerów zamawiający oczekuje dostawy właściwego oprogramowania systemów operacyjnych oraz bazodanowych w ilości uzasadnionej zamawianą ilością maszyn fizycznych i oczekiwaną ilością maszyn wirtualnych zgodnie z wymaganiami zaproponowanego rozwiązania systemu zintegrowanego.

Dostarczona platforma serwerowa będzie posadowiona w wyznaczonej lokalizacji własnej lub wyznaczonej kolokacji. Budowa właściwego dostępu sieciowego do tak zbudowanej platformy serwerowej będzie zadaniem Zamawiającego.


• Urządzenia rozwiązania organizacji ruchu chorych w przychodniach – system kolejkowy

W ramach postępowania Zamawiający oczekuje dostawy kompletnego zintegrowanego rozwiązania kolejkowego do zarządzania ruchem chorych opisanego w części OPZ, obsługującego docelową liczbę gabinetów w ilości 16, a w szczególności:


Lp.

Element

Ilość sztuk

1

Automat biletowy

3

2

Wyświetlacz stanowiskowy LED 4 znakowy

3

3

Serwer zarządzający

1

4

Drukarka biletowa do rejestracji

3

5

Monitor gabinetowy

16

6

Monitor centralny recepcji

1

Specyfikacja techniczna zamawianych urządzeń znajduje się w Załączniku nr 3.


• Silniki baz danych i inne oprogramowanie narzędziowe

Oferent dostarczy właściwe dla wdrażanego oprogramowania (wraz z BI) silniki baz danych (oprogramowanie) typu SQL wraz z niezbędną liczbą licencji do pracy wyżej wymienionego oprogramowania w modelu opłaty jednorazowej, nieograniczonych czasowo, obejmujących ilość użytkowników równą ilości użytkowników wdrażanych systemów. Dla pewności zakłada się, że użytkownicy poszczególnych modułów nie pokrywają się.


5.3.3 Inne wymagania

- Przedmiot zamówienia musi być dostarczany i wdrożony w całości do siedziby Zamawiającego (poza platformą serwerową, która może zostać wdrożona w wyznaczonej kolokacji).

- W ramach realizacji projektu Oferent dostarczy następujące usługi i będzie za nie odpowiedzialny:

- Dostawa, wdrożenie, instalacja i utrzymanie kompletnych środowisk rozwojowych, testowych, szkoleniowych oraz pozostałych koniecznych do efektywnego przeprowadzenia projektu wdrożeniowego wraz z niezbędnymi licencjami na czas realizacji projektu oraz trwania serwisu gwarancyjnego (niezbędnych do jego realizacji) w okresie trwania ww. usług. Zamawiający nie przewiduje dostawy własnego, dodatkowego sprzętu ani oprogramowania na ten cel.

- Szkolenia personelu Zamawiającego w zakresie obsługi oprogramowania aplikacyjnego, oraz oprogramowania bazodanowego, systemowego, narzędziowego i pozostałych dostarczonych w ramach projektu wdrożeniowego zgodnie z zakresem odpowiedzialności poszczególnych profili użytkowników.

- Migracja danych w tym słownikowych, kartotekowych, bilansów otwarcia koniecznych do uruchomienia oraz niezakłóconej kontynuacji działalności operacyjnej oraz raportowej Zamawiającego – tak automatyczna jak i ręczna.

- Dostosowywanie wdrożonych systemów do zmieniających się przepisów prawa, bez dodatkowych opłat po stronie Zamawiającego, w terminach uzgodnionych z Zamawiającym, jednak nie dłuższych niż do momentu wejścia zmian prawa w życie, w całym okresie realizacji projektu wdrożeniowego oraz trwania usługi gwarancyjnej.

- Utrzymanie w ruchu wdrożonego i przekazanego do eksploatacji oprogramowania przez okres min. 36 miesięcy od rozpoczęcia eksploatacji (wsparcie w administracji).

- Zarządzanie projektem wdrożeniowym, zgodnie z uzgodnioną miedzy stronami metodyką wdrożeniową w tym wykonanie wszystkich innych niezbędnych czynności koniecznych do wdrożenia w/w oprogramowania zgodnie z najlepszą praktyką rynkową.

- Wszystkie dostarczane:

• Produkty (rozumiane jako elementarny efekt działań/prac/dostaw objętych całym zakresem Przedmiotu Zamówienia wykonywanych przez Wykonawcę podczas realizacji Umowy w poszczególnych Etapach),

• Komponenty (rozumiane jako integralna część dostawy i wdrożenia Przedmiotu Zamówienia, składający się przynajmniej z jednego Produktu lub wielu Produktów powiązanych ze sobą merytorycznie) podlegają usługom projektowania, dostaw, instalacji, konfiguracji i wdrożenia.

- Usługi projektowania, instalacji, konfiguracji i wdrożenia Oferent przeprowadzi zgodnie z zapisami OPZ w uzgodnieniu z Zamawiającym zgodnie z obowiązującymi przepisami, zasadami wykonywania projektów teleinformatycznych oraz najlepszymi praktykami w ich realizacji. Oferent jest zobowiązany do realizacji Przedmiotu Zamówienia zgodnie z zasadami i wytycznymi Zamawiającego, zapisami OPZ oraz Umowy.

- Ilekroć w niniejszym OPZ Zamawiający użył w opisie oznaczeń norm, aprobat, specyfikacji technicznych i systemów odniesienia, o których mowa w art. 30 ust. 1-3 Pzp należy je rozumieć jako przykładowe. Zamawiający zgodnie z art. 30 ust. 4 ustawy Pzp dopuszcza produkty równoważne opisywanym w treści SIWZ. Jeżeli zapisy uszczegóławiające przedmiot zamówienia wskazywałyby w odniesieniu do rozwiązań, materiałów lub urządzeń znaki towarowe lub pochodzenie Zamawiający, zgodnie z art. 29 ust. 3 ustawy PZP, dopuszcza składanie ofert na „produkty” równoważne. Wszelkie

„produkty” pochodzące od konkretnych producentów określają minimalne parametry jakościowe i cechy użytkowe, jakim musi odpowiadać produkt, aby spełnić wymagania stawiane przez Zamawiającego i stanowią wyłącznie wzorzec jakościowy przedmiotu zamówienia. Poprzez zapis dot. minimalnych wymagań parametrów jakościowych Zamawiający rozumie wymagania materiałów, sprzętu i urządzeń zawarte w ogólnie dostępnych źródłach, katalogach, stronach internetowych producentów. Operowanie przykładowymi nazwami producenta ma jedynie na celu doprecyzowanie poziomu oczekiwań Zamawiającego w stosunku do określonego rozwiązania. Tak więc posługiwanie się nazwami producentów /produktów/ ma wyłącznie charakter przykładowy. Zamawiający, przy opisie przedmiotu zamówienia, wskazując oznaczenie konkretnego producenta (dostawcy) lub konkretny produkt, dopuszcza jednocześnie produkty równoważne o parametrach jakościowych i cechach użytkowych, co najmniej na poziomie parametrów wskazanego produktu, uznając tym samym każdy produkt o wskazanych parametrach lub lepszych. W takiej sytuacji Zamawiający wymaga złożenia stosownych dokumentów, wykazujących spełnienie przez produkty równoważne ww. parametrów i cech.

- Oferent musi dostarczyć wszelkie urządzenia i elementy, które są niezbędne do prawidłowego funkcjonowania całości. W przypadku, gdy w trakcie realizacji Przedmiotu Zamówienia okaże się, że brakuje jakiegokolwiek urządzenia i/lub elementu, którego brak spowoduje nieprawidłowe funkcjonowanie całości Przedmiotu Zamówienia, Oferent dostarczy je na własny koszt.

- Zamawiający wymaga aby zaoferowane rozwiązanie (system) było rozwiązaniem istniejącym, działającym, gotowym do wdrożenia i zapewniającym realizację wszystkich wymaganych w SIWZ (w szczególności OPZ) funkcjonalności na dzień składania ofert i nie może być w fazie opracowywania, budowy, testów, projektowania itp.

- Wszelkie dostarczane urządzenia:

• Muszą być fabrycznie nowe, pochodzić z autoryzowanego kanału sprzedaży producenta i reprezentować model bieżącej linii produkcyjnej. Nie dopuszcza się urządzeń: demonstracyjnych lub powystawowych.

• Nie dopuszcza się urządzeń posiadających wadę prawną w zakresie pochodzenia sprzętu, wsparcia technicznego i gwarancji producenta.

• Elementy, z których zbudowane są urządzenia muszą być produktami producenta urządzeń lub być przez niego certyfikowane oraz całe muszą być objęte gwarancją producenta.

• Urządzenia i ich komponenty muszą być oznakowane w taki sposób, aby możliwa była identyfikacja zarówno produktu jak i producenta.

• Urządzenia muszą być dostarczone Zamawiającemu wraz z oryginalnymi opakowaniach producenta.

• Do każdego urządzenia` musi być dostarczony komplet standardowej dokumentacji w dla użytkownika w języku polskim lub angielskim w formie papierowej lub elektronicznej.

• Gwarancja i serwis na urządzenia musi być świadczony przez firmę autoryzowaną przez producenta lub jego przedstawicielstwo w Polsce w przypadku gdy Oferent nie posiada takiej autoryzacji.

• Urządzenia na etapie dostawy od producenta do Zamawiającego nie mogą podlegać modyfikacjom.


• Zachowanie integralności i wiarygodności dokumentacji

System powinien współpracować z serwerem autentykacji użytkowników wykorzystującym posiadaną przez Zamawiającego domenę Windows. System powinien dawać możliwość podpisywania eksportowanej dokumentacji, wydruków i raportów certyfikatem użytkownika (kwalifikowanym lub nie).

System powinien zapewniać zarządzanie uprawnieniami dostępu użytkowników do poszczególnych elementów systemu, funkcji, formatek, raportów, danych poprzez system profili lub ról użytkowników odzwierciadlający role biznesowe tych użytkowników w realizacji procesów biznesowych oraz realizujących segregację odpowiedzialności.

System powinien posiadać zintegrowany mechanizm zarządzania uprawnieniami wspólny dla funkcjonalności ZSI oraz BI (ten sam model uprawnień: grup, profili, ról użytkowników) przynajmniej na poziomie jednorodnej autentykacji użytkowników (domena Windows).

Żadna transakcja w systemie, w tym w szczególności księgowa, nie może być usuwana przez użytkownika w sposób uniemożliwiający jej odtworzenie jak też skuteczny audyt. Usunięcie wpisu, transakcji, oznacza jedynie jego faktyczną dezaktywację lub inne oznaczenia jako nieaktualny. Takie usunięcie lub modyfikacji wpisu może dokonać osoba dokonująca wpisu lub osoba posiadająca specjalne wyodrębnione uprawnienie

do tych operacji. Fakt ten musi zostać odnotowany w systemie dla celów audytowych wraz z zachowaniem historii zmiany to jest: oznaczenia osoby dokonującej zmiany, czasu dokonania zmiany oraz zachowania wersji z przed dokonania zamiany. Jako spełnienie wymogu nie będzie uważane jedynie zapisywanie logu transakcji i wyszukiwanie zmian na poziomie administratora bazy danych.

System musi zapewniać możliwość audytowania tworzenia, zmiany i usuwania rekordów (audittrial).


• Zarządzanie centralnymi danymi słownikowymi

Wdrażane rozwiązanie powinno umożliwiać zastosowanie zarządzania słownikami danych (masterdata) przynajmniej w zakresie:

− audytowalności tworzenia i zmian danych,

− uniemożliwienia usuwania danych, a jedynie ich dezaktywacji,

− zatwierdzania zmian w danych (np. danych dostawców, klientów, pracowników) dwu lub trzypoziomowo – przepływy pracy,

− jednorodności danych (spójnych, pojedynczych, wspólnych słowników dla wszystkich modułów systemu),

− zarządzania rekordami, w tym automatycznej dezaktualizacji danych (czas życia rekordów), możliwości anonimizacji danych na żądanie właściciela danych, zmiany danych na żądanie, z pełnymi logowanie zmian i powodów zmian – zgodnie z obowiązującymi przepisami prawa,

− śledzenia zmian w danych osobowych, audytowanie zmian, ograniczenie do przetwarzania danych osobowych zgodnie z wymaganiami RODO,

− jednorodności danych (spójnych, pojedynczych, wspólnych słowników dla wszystkich modułów systemu),

− pojedynczego, spójnego wprowadzania informacji „tylko jedne raz” do całego systemu, tzn. dany rekord (np. dane pacjenta, klienta, dostawcy, indeksu magazynowego) powinien być wprowadzony do systemu tylko jedne raz i w razie potrzeby propagowany w inne jego części jeśli to jest konieczne, jak także powinien być dostępny wszędzie tam gdzie proces tego przewiduje i jest to biznesowo uzasadnione.

• Integracja rozwiązania wewnętrzna oraz zewnętrzna

Celem Zamawiającego jest zakupienie i wdrożenie zintegrowanego systemu informatycznego w którym dane, funkcje i procesy biznesowe będą spójne i jednolicie obsługiwane w całym systemie oraz systemach z nim zintegrowanych.

o Wewnętrzna spójność pomiędzy modułami systemu

Wymagana jest integracja pomiędzy poszczególnymi modułami systemu. Integracja o której mowa musi polegać co najmniej na następujących elementach:

▪ integracja w zakresie weryfikacji uprawnień użytkowników - jeżeli użytkownik jest zalogowany do jednego modułu może przesłać i odczytać dane z innego modułu bez konieczności dodatkowej autoryzacji,

▪ integracja semantyczna – moduły muszą w sposób jednoznaczny identyfikować informacje wymieniane pomiędzy nimi. Integracja musi uwzględniać integrację pojęciową jak i słownikową. Jeżeli moduły korzystają z różnych słowników Wykonawca musi zapewnić opracowanie i utrzymywanie tabeli przekodowań,

▪ wspólny model danych – poszczególne moduły muszą pracować na wspólnym modelu danych, tzn. przechowywać dane we wspólnych, współdzielonych tabelach, co najmniej w obszarach „białym” (HIS) oraz „szarym” (ERP), a pomiędzy nimi wymieniać informacje w sposób „przezroczysty” dla użytkownika, tj. bez jego interakcji.

Oznacza to też, że wymiana informacji musi odbywać się w sposób automatyczny i elektroniczny bez konieczności ręcznego przepisywania danych pomiędzy systemami.

o Integracja z systemami zewnętrznymi (trzecimi).

Integracyjna wymiana danych pomiędzy ZSI oraz systemami zewnętrznymi powinna odbywać się z wykorzystaniem właściwych standardów i technologii odpowiednich dla tych systemów, a w szczególności z wykorzystaniem standardów branżowych, takich jak:

o standard HL7 jako podstawowa technologia wymiany danych pomiędzy ZSI i innymi systemami własnymi Szpitala jak i systemami zewnętrznymi,

o w przypadku gdy to nie jest technicznie możliwe formatem wymiany danych pomiędzy integrowanymi systemami może być XML oraz webserwisy (SOAP, REST).

o dopuszcza się też użycie mechanizmów SQL, ETL jeśli odbywa się ona w pełni automatycznie. Zastosowanie innych mechanizmów musi zostać wcześniej uzgodnione z Zamawiającym.

o Komunikacja pomiędzy integrowanymi systemami powinna być szyfrowana. W innych przypadkach konieczna jest zgoda Zamawiającego.

Wszystkie technologie wymiany danych użyte przez Wykonawcę powinny być wcześniej uzgodnione i zatwierdzone przez Zamawiającego w celu utrzymania zgodności z polityką budowy rozwiązań systemowych w przedsiębiorstwie Zamawiającego.

Intencją Zamawiającego jest unikanie technologii niezapewniających bezpieczeństwa lub oferujących niski poziom bezpieczeństwa wymiany danych, jak też nie wspieranych przez środowisko informatyczne Zamawiającego, takich jak np.: wymiana danych poprzez pliki składowane w sieci (txt, csv, ANSI), czy protokoły ftp, SQL, jeżeli wymiana danych odbywa się kanałami nie oferującymi szyfrowania danych lub za pośrednictwem niezaszyfrowanych zbiorów danych.

Wymiana danych co do zasady powinna oferować możliwość audytowania wymienionych danych pomiędzy systemami oraz sygnalizować wszystkie błędy komunikacji pomiędzy punktami końcowymi.


o Termin realizacji Przedmiotu Zamówienia

Termin realizacji całości Przedmiotu zamówienia: nie później niż w tym zgodnie z podziałem na etapy:


Etap

Zakres prac obejmuje

Termin zakończenia

I

Analiza przedwdrożeniowa

Do 60 dni od podpisania umowy

II.

Dostawa, instalacja, konfiguracja i wdrożenie

oprogramowania i sprzętu komputerowego.

Do 30 dni od zakończenia etapu I


III.

Instalacja oraz konfiguracja niezbędnych baz danych na potrzeby Systemu, a także dostawa i instalacja

licencji na oprogramowanie


Do 30 dni od zakończenia etapu II

IV.

Wdrożenie

Do 60 dni od zakończenia etapu III

V.

Uruchomienie e-usług

Nie dłużej niż 30 dni od zakończenia etapów

II, III i IV.

VI.

Odbiór końcowy Przedmiotu Zamówienia

Do 31 grudnia 2020 r.

Oferent zobowiązany jest przedstawienia szczegółowego planu wdrożenia (harmonogramu) przed jego rozpoczęciem, wraz ze strukturą planowanych zadań oraz aktualizację planu wdrożenia co najmniej raz w miesiącu na potrzeby


5.4 Organizacja wdrożenia


5.4.1 Założenia podstawowe

- Przedmiot Zamówienia będzie realizowany w oparciu o opracowany przez Oferenta i zaakceptowany przez Zamawiającego harmonogram wdrożenia, a następnie odpowiednio aktualizowany w toku realizacji Przedmiotu Zamówienia.

- Oferent w Harmonogramie wdrożenia musi uwzględnić w szczególności podział na zadania takie jak projektowanie, dostawy, usługi instalacji/konfiguracji, testowanie, wdrożenie i odbiory.

- Oferent umożliwi Zamawiającemu udział we wszystkich pracach realizowanych przez Wykonawcę w ramach realizacji Przedmiotu Zamówienia (x.xx. w czasie projektowania, dostawach, instalacji/budowie, konfiguracji i wdrożeniu i testowaniu).

- Oferent zobowiązany jest do udziału w cyklicznych naradach przeglądu prac w siedzibie Zamawiającego. Zamawiający przewiduje częstotliwość narad maksymalnie do 1 w miesiącu chyba że, nadzwyczajna sytuacja w realizacji przedmiotu umowy wymagała będzie częstszych spotkań.

- Oferent zobowiązany jest przeprowadzić dostawy Przedmiotu Zamówienia w dokładnych terminach i godzinach uzgodnionych z Zamawiającym.

- W przypadku dostarczania Sprzętu komputerowego musi być on oznakowany w taki sposób, aby możliwa była identyfikacja systemowa zarówno produktu jak i producenta, pochodzić z oficjalnych kanałów dystrybucji producentów i dostarczony w oryginalnych opakowaniach fabrycznych.

- Wdrożenie należy rozumieć jako szereg uporządkowanych i zorganizowanych działań mających na celu wykonanie Przedmiotu Zamówienia.

- Wdrożenie będzie realizowane w ramach powołanych do tego celu struktur organizacyjnych po stronie Oferenta. Na etapie analizy przedwdrożeniowej Oferent przygotuje informacje na temat struktury organizacyjnej Zespołu Oferenta zajmującej się realizacją Przedmiotu Zamówienia, w ramach której muszą zostać powołane minimum następujące role:

o Kierownik Projektu ze strony Oferenta,

o Zespół Analityczny ze strony Oferenta

o Zespół Wdrożeniowy ze strony Oferenta.

- Wdrożenie muszą realizować osoby wymienione w ofercie Oferenta, przy czym:

o Osoby Zespołu Oferenta muszą być dyspozycyjne w trakcie wykonywania prac,

o Oferent przekaże Zamawiającemu wykaz numerów telefonów kontaktowych do osób biorących udział w realizacji Przedmiotu Zamówienia po stronie Oferenta.

- Oferent zorganizuje prace tak, aby w maksymalnym stopniu nie zakłócać ciągłości funkcjonowania prac u Zamawiającego.

- Obiekty podlegające inwestycji (obiekty służby zdrowia w których świadczone są usługi medyczne) są użytkowane w trybie ciągłym w czasie godzin pracy przez cały okres wykonywania Przedmiotu Zamówienia, co może powodować utrudnienia w miejscu prowadzenia prac. Nie ma możliwości całkowitego wyłączenia i zamknięcia w/w obiektów lub ich części na czas realizacji Przedmiotu Zamówienia. Poszczególne prace będą realizowane etapowo, tak aby zachować ciągłość świadczenia usług medycznych.

- Oferent musi uwzględnić, że wszystkie prace wykonywane będą w użytkowanych obiektach przy dużym ruchu pracowników i chorych, tzn. organizacja prac powinna przede wszystkim zapewniać bezpieczeństwo przebywających w oddziałach pracowników i chorych oraz zachowanie ciszy nocnej w godzinach właściwych dla Zamawiającego.

- Oferent dostarczy i zapewni podczas trwania Umowy aplikację internetową będącą Systemem zgłoszeń i obsługi Wad oraz stanowiąca repozytorium Dokumentacji dla potrzeb realizacji Przedmiotu Zamówienia.


5.4.2 Wymagania dotyczące szkoleń.

- Zamawiający oczekuje, że Oferent przedłoży w ofercie propozycję szkoleń personelu Zamawiającego z podziałem na bloki tematyczne, długość trwania oraz ilość przewidzianych teoretycznie uczestników poszczególnych szkoleń, a w tym:

o administrowanie wdrożonymi bazami danych i innymi komponentami technicznymi,

o administrowanie poszczególnymi modułami oprogramowania w tym poprzez zmianę ustawień tych modułów,

o eksploatacji wdrożonych modułów oprogramowania zgodnie z opracowanymi procedurami oraz instrukcjami stanowiskowymi (dokumentacją użytkowników) w podziale na bloki tematyczne i odpowiednie grupy,

- Zamawiający, w ramach szkolenia użytkowników, przewiduje szkolenia grupowe oraz indywidualne.

- Zamawiający przewiduje przeszkolenie całego personelu w ilości odpowiadającej ilości licencji użytkowników.

- Administratorów systemów (2 osoby) należy przeszkolić w pełnym zakresie wdrażanych systemów.

- Szkolenia nie mogą odbywać się w grupach większych niż 10 osób.

- W ramach przeprowadzonych szkoleń Oferent zapewni użytkownikom dostęp do systemu testowego skonfigurowanego podobnie oraz zawierającego przykładowe ale adekwatne dane umożliwiającego samodzielne dokonywanie ćwiczeń z systemem podczas szkoleń oraz poza nimi (nauka własna), podczas trwania projektu i w całym okresie gwarancji. System szkoleniowy (testowy) powinien umożliwiać przeprowadzanie tych samych operacji o odtworzenia procesów co system produkcyjny.

- System szkoleniowy powinien umożliwiać ćwiczenia co najmniej 10 użytkownikom jednocześnie.

- Szkolenia grupowe winny się odbywać w podziale na grupy zawodowe, a tym samym w podziale na poszczególną funkcjonalność modułów.

- Czas szkolenia z danego modułu systemu dla danej grupy zawodowej powinien uwzględniać stopień skomplikowania modułu.

- Każde szkolenie grupowe winno zakończyć się krótkim testem sprawdzającym wiedzę szkolonego personelu uzyskaną podczas szkolenia oraz podpisaniem protokołu z realizacji szkolenia zawierającym: czas trwania szkolenia, jego zakres merytoryczny, wyniki testu końcowego, wykaz uczestników. Protokół winien być podpisany i przez osoby szkolące i uczestniczące w szkoleniu.

- Oferent po zawarciu umowy dostarczy harmonogram szkoleń do akceptacji Zamawiającego.

- Zamawiający nie dopuszcza szkoleń on-line lub samodzielnych dla natywnych aplikacji dostarczonego rozwiązania (działających bezpośrednio pod kontrolą systemu Windows), a dopuszcza szkolenia on-line lub samodzielne szkolenia dla funkcji dostępnych przez portale WWW.


5.5 Wymagania dotyczące personelu Oferenta

- Wdrożenie i szkolenie muszą realizować osoby wymienione w ofercie Oferenta w Wykazie osób przedstawionym do realizacji umowy.

- Zamawiający wymaga, by prace instalacyjne i wdrożeniowe systemu, szkolenia grupowe i indywidualne personelu Zamawiającego przeprowadzały osoby posiadające doświadczenie w zakresie produktów, których dotyczyć będzie instalacja oraz wdrożenie.

- Osoby wykonujące prace instalacyjne i wdrożeniowe oraz szkolące muszą być dyspozycyjne w trakcie trwania prac instalacyjnych, wdrożeniowych oraz szkoleń. Wymagany jest stały kontakt roboczy z Zamawiającym.

- Oferent przekaże Zamawiającemu wykaz numerów telefonów kontaktowych do osób wykonujących prace instalacyjne, wdrożeniowe i szkolenia. Stały kontakt oznacza dyspozycyjność osób wykonujących prace instalacyjne i wdrożeniowe w trakcie trwania prac instalacyjnych i wdrożeniowych w godzinach pracy Zamawiającego tj. 8:00 do 15:00.

- Zamawiający wymaga, by wszelkie zastępstwa lub trwała zmiana w osobach instalujących i wdrażających zgłaszana była niezwłocznie przez Wykonawcę, z zastrzeżeniem, że osoba zastępująca musi posiadać niemniejsze kwalifikacje niż osoba zastępowana. Zastępstwo lub trwała zmiana danej osoby wymaga akceptacji ze strony Zamawiającego.

- Zamawiający może zażądać zmiany osoby wdrażającej.


5.5.1 Przygotowanie Dokumentacji

• W ramach prac Xxxxxxx opracuje dla Zamawiającego Dokumentację Przedmiotu Zamówienia (zwaną dalej Dokumentacja, Dokumentacja PZ), która składa się z nw. zakresów:

o Harmonogram Wdrożenia

o Dokumentacja Analizy Przedwdrożeniowej (DAP)

o Dokumentacja Powykonawcza

• Dokumentacja powyższa będzie zawierać bazowe zapisy opisujące budowane rozwiązania, procesy oraz sposób organizacji prac i wdrożenia. Na podstawie zapisów w Dokumentacji będą prowadzone i odbierane poszczególne etapy realizowane w ramach Przedmiotu zamówienia. Dokumenty te wraz ze Specyfikacją Istotnych Warunków Zamówienia (dalej zwanych SIWZ) będę stanowiły podstawę do weryfikacji wdrożenia w trakcie odbiorów.

• Dokumentacja podlega uzgadnianiu i akceptacji Zamawiającego. Akceptacja Harmonogramu wdrożenia i DAP warunkuje rozpoczęcie prac Oferenta.

• Oferent zobowiązuje się do oznakowania dostarczanego w ramach zamówienia sprzętu, nośników, dokumentacji dla poszczególnych Zamawiających zgodnie z wytycznymi w zakresie informacji i promocji projektów dofinansowanych w ramach Regionalnego Programu Operacyjnego Województwa Łódzkiego na lata 2014-2020. W celu oznakowania dostarczanego sprzętu oraz nośników Oferent otrzyma od Zamawiającego odpowiednio przygotowane naklejki informacyjne.

• Dokumentacja Harmonogramu Wdrożenia oraz Analizy Przedwdrożeniowej DAP zostanie opracowana w oparciu o wymagania określone w OPZ.


5.5.2 Harmonogram wdrożenia


Oferent zobowiązany jest opracować na podstawie SIWZ szczegółowy harmonogram wdrożenia. Harmonogram należy przedstawić Zamawiającemu w terminie do 14 dni od podpisania Umowy.


5.5.3 Analiza Przedwdrożeniowa

1) Analiza przedwdrożeniowa, którą należy rozumieć jako zakres czynności do wykonania przez Wykonawcę mający na celu analizę środowiska biznesowego i informatycznego Zamawiającego. W wyniku przeprowadzenia Analizy przedwdrożeniowej Oferent przedstawi Zamawiającemu Dokumentację analizy przedwdrożeniowej (zwana dalej DAP), na podstawie której będzie realizowany organizacyjnie i technicznie Przedmiot Zamówienia. DAP będzie podlegała uzgodnieniu i akceptacji Zamawiającego.

2) Dokumentacja Analizy Przedwdrożeniowej DAP powinna zawierać w szczególności:


Skład DAP

ZSI i eUsługi

- wykaz oraz szczegółowy opis i harmonogram budowy ZSI i eUsług

- architekturę ZSI i eUsług

- analizę migracji danych oraz opis sposobu migracji

- przygotowanie planu instalacji Sprzętu komputerowego, serwerowego, macierzy

- określone założenia integracji z innymi systemami informatycznymi, które posiada Zamawiający

- plan pracy na dalsze etapy Wdrożenia

- plan migracji danych z ZSI, który posiada Zamawiający

- szczegółową specyfikację oprogramowania objętego zakresem umowy

- wykaz oraz szczegółowy opis i harmonogram niezbędnych prac konfiguracyjnych

- ustawienia konfiguracyjne urządzeń i oprogramowania wchodzących w skład ZSI

- propozycje scenariuszy testowych uwzględniających zakres czynności operacyjnych, które należy wykonać w celu potwierdzenia, że wskazane wymagane funkcjonalności zostały prawidłowo skonfigurowane i działają zgodnie z opisami procesów

- harmonogram instruktażu personelu oraz administratorów ZSI

Zarządcze

- plan i sposób komunikacji Stron

- plan zarządzania jakością w Projekcie

- plan zarządzania zagadnieniami w Projekcie

- sposób obsługi zmian projektowych,

- plan zarządzania ryzykiem w Projekcie

- skład Zespołu Wdrożeniowego wraz z podziałem na role i zadania poszczególnych członków zespołu

Sprzętu komputerowego

- podział Przedmiotu Zamówienia na Produkty, a następnie ich pogrupowanie w Komponenty

- analizę wymagań Przedmiotu Zamówienia zawierającą opis sposobu realizacji wymagań, sposób testowania i odbioru

- karty katalogowe potwierdzające spełnienie wymagań

- dokumentacje i plan dostaw

- plan i opis instalacji i wdrożenia systemów wdrażanych wraz ze Sprzętem komputerowym

- plan i opis modernizacji i budowy Sprzętu komputerowego,

- listę Komponentów, które będę podlegały osobnym odbiorom

- szczegółowe uzgodnienia Stron Umowy dotyczące zakresu i sposobu integracji dostarczanych rozwiązań z istniejącą infrastrukturą,

- zakres prac realizowanych przez podwykonawców,

- szczegółowy zakres i zawartość pozostałej Dokumentacji

- plan Instruktaży stanowiskowych i Administratora oraz sposób ich wykonania


5.5.4 Dokumentacja Powykonawcza

Warunkiem dokonania Odbioru Końcowego jest dostarczenie przez Wykonawcę Dokumentacji Powykonawczej obejmującej dokumentację użytkową, techniczną i eksploatacyjną. Dokumentacja

Powykonawcza musi być dostarczona w języku polskim, w wersji elektronicznej w formacie edytowalnym oraz w co najmniej jednym egzemplarzu papierowym.

W dokumentacji muszą być zawarte opisy wszelkich cech, właściwości i funkcjonalności pozwalających na poprawną z punktu widzenia technicznego eksploatację rozwiązań.

W szczególności dokumentacja ta powinna zawierać:

1) Pełna charakterystyka licencjonowania wszystkich elementów aplikacji i środowiska;

2) Opis architektury technicznej;

a. wyszczególnienie oraz opis powiązań wszystkich komponentów sprzętowych, systemowych i aplikacyjnych występujących lub wymaganych do poprawnej pracy aplikacji zgodnie z wymaganiami wydajności, funkcjonalności i bezpieczeństwa (minimalny, maksymalny, rekomendowany),

b. dla komponentów innych dostawców, należy dokładnie określić wykorzystywane i dopuszczalne wersje;

3) Konfiguracja musi obejmować wszystkie urządzenia wdrożone, zainstalowane w ramach budowy systemu IT;

4) Przykładowy zestaw wymaganych danych konfiguracyjnych obejmuje:

a. serwery – parametry sprzętowe (procesor, pamięć, dyski, karty sieciowe, zasilanie, itp.);

b. sieć (adresacja IP, itp.),

c. podsystem dyskowy (punkty montowania/litery dysków, wolumeny logiczne, grupy wolumenowe, zasoby dyskowe, RAID, itp.),

d. system operacyjny (parametry jądra, moduły, usługi, stos TCP/IP, itp.),

e. klaster (węzły fizyczne, paczki klastrowe, kolejność przełączania, itp.),

f. listę zainstalowanego oprogramowania, itp.;

g. macierze – parametry sprzętowe (cache, półki dyskowe, dyski, karty/porty fibre channel, itp.), grupy dyskowe, zasoby dyskowe, maskowanie, kopie biznesowe, replikacja, itp.;

h. infrastrukturę sieciową– parametry sprzętowe (porty fibre channel, aktywne licencje, itp.), fabric, zonning, aliasy, itp.


5) Opis aplikacji i konfiguracji aplikacji/systemu.

a. opis musi obejmować ogół oprogramowania wdrożonego, zainstalowanego w ramach budowy systemu IT.

b. opis musi zawierać opis systemu lub systemów informatycznych, zawierający wykaz programów, procedur lub funkcji, w zależności od struktury oprogramowania, wraz z opisem algorytmów i parametrów oraz programowych zasad ochrony danych, w tym w szczególności metod zabezpieczania dostępu do danych i systemu ich przetwarzania, sposobu komunikacji pomiędzy systemami, zakresu wymienianych danych i sposobu ich szyfrowania.

c. przykładowy zestaw wymaganych danych konfiguracyjnych obejmuje: wersję oprogramowania, narzędzia, użytkowników i grupy systemowe, katalog instalacyjny, położenie plików konfiguracyjnych, pierwotne parametry konfiguracyjne i zmodyfikowane w procesie instalacji, położenie plików logów, położenie i opis innych kluczowych plików i katalogów, parametry instancji, itp.;

d. konfiguracja musi obejmować wersję aplikacji, pełen zestaw parametrów konfiguracyjnych aplikacji wraz z opisem użycia, katalogi instalacyjne, położenie plików konfiguracyjnych, położenie plików logów, położenie i opis innych kluczowych plików i katalogów, itp.

6) Opis architektury logicznej:

a. schemat i opis powiązań logicznych poszczególnych komponentów i ich rolę w architekturze.

7) Mapa i opis Interface’ów.

a. interfejsy muszą zawierać szczegółowy opis techniczny, w szczególności zawierać informację o: typie interfejsu, wykorzystywanych protokołach, portach sieciowych, strukturze interfejsu, itp. oraz o zakresie wymiany danych i sposobu kontroli prawidłowości działania. W szczególności opis musi zawierać szczegółową dokumentację procesów wymiany danych pomiędzy osobnymi systemami medycznymi z uwzględnieniem podania typu komunikacji (HL7 2.x / HL7 3.x / inne) oraz zestawienie komunikatów.

8) Opis struktur baz danych

a. opis wykorzystywanych struktur danych musi w szczególności zawierać: listę tabel bazy danych wraz z opisem pól, formaty danych, itp., kryteria walidacji danych wejściowych, opis zmiennych konfiguracyjnych.

9) Opis wymagań sprzętowych, systemowych, sieciowych, itp.

10) Wymagania dla poszczególnych komponentów architektury, odniesienia do oczekiwanych wymagań wydajnościowych, funkcjonalnych i bezpieczeństwa (minimalny, maksymalny, rekomendowany).

11) Procedury tworzenia środowisk pomocniczych

a. zasady i procedury tworzenia środowisk (testowych, rozwojowych, raportowych) oraz metod klonowania i anonimizacji (depersonalizacji)1 danych przenoszonych pomiędzy środowiskami;

12) Procedury eksploatacji.

a. w szczególności dokumentacja zawiera procedury tworzenia/odtwarzania kopii bezpieczeństwa operacyjnego i kopii zapasowych oraz odtwarzania/kreowania z kopii wszystkich komponentów aplikacji i środowiska (bazy danych, komponenty serwera aplikacji, klienta itp.);

b. odtworzenia systemów i środowiska informatycznego Zamawiającego po katastrofie (DisasterRecovery):




1Poprzez ‘anonimizację’ Zamawiający rozumie ‘zakodowanie’ danych dowolną metodą tak, aby usunięte zostały dane osobowe lub odczytanie tych danych nie było możliwe w sposób trwały i nieodwracalny.

• procedury muszą opisywać kolejne kroki pozwalające na bezpieczne zatrzymanie/uruchomienie elementu infrastruktury hardware’owej oraz aplikacji i elementów infrastruktury software’owej, lub całego środowiska sprzętowo-software’owego.

• dokumenty obejmują również procedury i instrukcje instalacji krok po kroku środowiska produkcyjnego „od zera” na:

• środowisku fizycznych hostów danego Zamawiającego rozpoczynając od dostarczonego wirtualizatora,

• standardowym zastosowanym systemie operacyjnym dla poszczególnych dostarczonych systemów informatycznych.

13) Procedury lub instrukcje instalacji, reinstalacji, deinstalacji oraz aktualizacji.

a. szczegółowy opis postępowania w przypadku tworzenia lub zmian w środowisku; jeśli wykorzystywane są procedury innych dostawców dla standardowych komponentów (np. baz danych) wystarczy wskazać w dokumentacji szczegółowe odniesienie do procedur standardowych właściwych dla tych komponentów.

14) Procedury backupowe:

a. zalecany tryb backupu aplikacji i elementów infrastruktury software’owej, oraz zakres danych podlegających backupowi. Procedury odtworzeniowe, muszą w szczególności opisywać sposób odtworzenia funkcjonalności aplikacji i elementów infrastruktury software’owej w przypadku błędu lub awarii.

15) Dokumentacja administracyjna związana z poprawną eksploatacją

a. opis (w postaci procedur lub instrukcji) wszystkich rutynowych czynności administracyjnych dla aplikacji i systemu informatycznego (dziennych, tygodniowych, miesięcznych itp.) oraz działań pozwalających na utrzymanie wymaganej dostępności, wydajności i bezpieczeństwa.

b. wymagane jest dostarczenie poprawnych inicjalnych sekwencji realizowanych czynności administracyjnych i utrzymaniowych i zasad ich aktualizacji i budowy; opis zasad pielęgnacji i utrzymania aplikacji. Procedury administracyjnepowinny w szczególności zawierać informacje

o okresowych zadaniach, które muszą być wykonane przez administratora, np. weryfikacja zajętości przestrzeni tabel, konieczność wykonywania analizy tabel, czyszczenia logów, itp.

16) Dokumentacja procesu parametryzacji:

a. wyszczególnienie wszystkich parametryzowanych elementów systemu wraz z opisem ich znaczenia i dopuszczalnych wartości oraz stosowanych wartości domyślnych.

17) Dokumenty z testów:

a. plan testów, scenariusze testowe i protokoły z testów akceptacyjnych, wydajnościowych, testów operacji administratora technicznego oraz testów bezpieczeństwa w tym ciągłości działania (przełączanie, odtwarzanie, weryfikacja poprawności).

18) Dokumentacja wdrożeniowa:

a. dokumentacja powdrożeniowa: zawiera szczegółowy opis wykonanych czynności instalacyjnych oraz konfiguracyjnych wszystkich komponentów systemu;

b. dokumentacja parametryzacji: wyszczególnienie wartości wszystkich ustawionych parametrów użytkowych zarówno samej aplikacji jak i pozostałych komponentów systemu, parametry systemu operacyjnego oraz parametry sprzętu, w tym konfiguracji środowiska produkcyjnego (serwery baz danych, serwery aplikacji, inne zastosowane);

c. dokumentacja uruchomieniowa: opisuje wszystkie istotne kroki (czynności) wykonane w celu pierwszego uruchomienia aplikacji/systemu, w tym opis migracji/konwersji danych, testy uruchomieniowe;

d. dokumentacja pilotażowa: jeśli był stosowany w trakcie wdrożenia pilotaż jako element stabilizacji i testów.

19) Wersjonowanie:

a. opis zasad wersjonowania i sposobu patchowania aplikacji.

20) Zalecenia:

a. opis zasad i zaleceń strojenia aplikacji.

21) Instrukcje obsługi i instrukcje użytkowania dla wersji dostarczonego oprogramowania z podziałem na poszczególne moduły.

22) W zakresie obszarów administratora dokumentacja powinna zawierać dodatkowo co najmniej:

a) opis podstawowych ról użytkowników i zasad ich kreowania;

b) opis zarządzania uprawnieniami użytkownika i tworzenia profili;

c) lista dostępnych uprawnień użytkownika wraz z opisem efektu w zakresie dostępu do danych w ZSI;

d) opis zarządzania autoryzacją i autentykacją użytkowników.

Wkład do Polityki bezpieczeństwa w zakresie wdrożonego Systemu oraz Instrukcję zarządzania systemem informatycznym służącym do przetwarzania danych osobowych opracowane zgodnie z wymaganiami określonymi w Rozporządzeniu Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne rozporządzenie o ochronie danych).

23) Wkład do Polityki Bezpieczeństwa będzie zawierać w szczególności:

a. wykaz zbiorów danych osobowych wraz ze wskazaniem programów zastosowanych do przetwarzania tych danych;

b. opis struktury zbiorów danych wskazującej zawartość poszczególnych pól informacyjnych i powiązań między nimi;

c. informacje o sposobie przepływu danych pomiędzy poszczególnymi systemami;

d. opis środków technicznych i organizacyjnych niezbędnych dla zapewnienia poufności, integralności i rozliczalności przetwarzanych danych.

5.5.5 Odbiór Etapu/Dokumentacji/Końcowy


1. Odbiory Etapów/Dokumentacji będą się odbywać po zakończeniu określonych prac danego Etapu/Dokumentacji.

2. Odbiór końcowy Przedmiotu Zamówienia ma na celu potwierdzenie wykonania wszystkich zadań wynikających z Umowy, w tym odebrania wszystkich Komponentów i Etapów oraz dostarczenia wymaganej zamówieniem Dokumentacji.

3. Odbiory będą odbywać się zgodnie z IPU stanowiącej Załącznik nr 11 do SIWZ. Na potwierdzenie odbioru Etapu/Końcowego Strony Umowy podpiszą odpowiednio:

a) Protokół Odbioru Etapu – protokół przygotowany przez Wykonawcę, będący potwierdzeniem przyjęcia przez Zamawiającego wykonanych przez Wykonawcę prac będących przedmiotem poszczególnych Etapów.

b) Protokół Odbioru Końcowego – protokół, który po podpisaniu bez zastrzeżeń przez Xxxxxxxxxxxxx oraz Wykonawcę stanowi potwierdzenie wykonania i odbioru Przedmiotu Zamówienia.


5.5.6 Dostawa i instalacja oprogramowania standardowego

1. Oprogramowanie standardowe rozumiane jako oprogramowanie dostarczone i zainstalowane na sprzęcie komputerowym posiadanym przez Zamawiającego i/lub dostarczanym zgodnie z IPU, stanowiącymi Załącznik nr 11do SIWZ oraz w istniejących systemach informatycznych zgodnie z wymaganiami niniejszego Opisu Przedmiotu Zamówienia w taki sposób, aby zapewnić prawidłowe funkcjonowanie Oprogramowania aplikacyjnego, sprzętu oraz istniejących systemów informatycznych na wszystkich stanowiskach pracy (stanowiska komputerowe) Zamawiającego.

2. Dostawa i instalacja zostaną wykonane w lokalizacjach zgodnych z instalacją sprzętu u Zamawiającego zgodnie z harmonogramem (planem) wdrożenia, jednak nie później niż 14 dni przed rozpoczęciem pierwszego zadania projektu, które wymaga uruchomienia tego oprogramowania.

3. Oprogramowanie standardowe musi zostać skonfigurowane tak, aby działało poprawnie zgodnie z jego przeznaczeniem i architekturą Systemu oraz zapewniało prawidłową pracę Oprogramowania aplikacyjnego.


5.5.7 Dostawa, instalacja, konfiguracja i wdrożenie Oprogramowania aplikacyjnego

- Zadanie dostawy, instalacji, konfiguracji i wdrożenia Oprogramowania aplikacyjnego obejmuje:

o Szpitalny System Informatyczny (HIS, ERP) wraz z integracjami (LIS, RIS, PACS, patomorfologia, mikrobiologia)

o E-usługi.

- Dostawa i instalacja mają być wykonane w wyznaczonych lokalizacjach Zamawiającego.

- Po zakończeniu prac instalacyjnych Oprogramowanie musi zostać skonfigurowane i wdrożone w sposób kompleksowy tak, aby oferowało wszystkie funkcjonalności opisane w SIWZ oraz zgodnie z Dokumentacją i wskazanymi przez Xxxxxxxxxxxxx wytycznymi na etapie analizy przedwdrożeniowej oraz samego procesu wdrażania oczekiwaniami konfiguracyjnymi (w zakresie opisanych w OPZ wymagań funkcjonalnych).

- Oprogramowanie aplikacyjne musi zostać zainstalowane przez Wykonawcę w szczególności z wykorzystaniem Sprzętu dostarczanego przez Wykonawcę i w środowiskach informatycznych Zamawiającego. Oprogramowanie aplikacyjne musi zostać zainstalowane i skonfigurowane w sposób kompleksowy na wszystkich stanowiskach komputerowych Zamawiającego.

Zamawiający na potrzeby realizacji przedmiotu zamówienia przewidział infrastrukturę i oprogramowanie o parametrach wskazanych w rozdziale III OPZ.


5.5.8 Godziny rozwojowe


Zamawiający w ramach wdrożenia wymaga puli 200 godzin rozwojowych, przez co rozumie pulę godzin do dyspozycji Zamawiającego na modyfikacje, których nie dało się przewidzieć na etapie budowy niniejszego dokumentu.


5.5.9 Zestawienia raportowe

Zamawiający w ramach wdrożenia ZSI oczekuje zaimplementowania puli raportów niezbędnych Zamawiającemu do codziennej pracy z systemem. Listę raportów oraz ich wzory Oferent opracuje w ramach analizy przedwdrożeniowej.

Zamawiający oczekuje, że system będzie umożliwiał tworzenie raportów formularzowych przez uprawnionych użytkowników wraz z możliwością dowolnego definiowania pól obligatoryjnych. Zamawiający nie dopuszcza, aby tworzenie raportów formularzowych wymagało od uprawnionych użytkowników zaawansowanej wiedzy programistycznej.

Raporty o charakterze tabelarycznym powinny umożliwiać export do formatu arkusza Excel.


5.5.10 Testy

1. W ramach zadania zostaną przeprowadzone wszystkie testy opisane w Dokumentacji. Celem testów jest weryfikacja przez Zamawiającego, czy wszystkie prace wykonane w trakcie realizacji Przedmiotu Zamówienia zostały wykonane prawidłowo i zgodnie z założeniami funkcjonalnymi i jakościowymi. Testy będą przeprowadzane przez Wykonawcę przy współudziale Zamawiającego jak i wskazanych przez danego Zamawiającego osób i podmiotów zewnętrznych.

2. Pozytywne zakończenie testów wraz z usunięciem wskazanych Wad jest niezbędne aby dla poszczególnych Komponentów oraz całego Przedmiotu Zamówienia dokonać odbiorów w ramach poszczególnych Etapów i Odbioru końcowego.

3. Zamawiający ma prawo do weryfikacji należytego wykonania Umowy dowolną metodą, w tym także z wykorzystaniem opinii zewnętrznego audytora. W szczególności uzgodnienie określonych scenariuszy testowych nie wyklucza prawa do weryfikacji prac innymi testami i scenariuszami.

4. Zamawiający w końcowej fazie wdrożenia oczekuje realizacji przez Wykonawcę testów bezpieczeństwa. Testy obejmować będą swym zakresem:

a. Testy penetracyjne wskazanych zasobów wykonywane metodą white, black lub grey –box.

b. Testy bezpieczeństwa aplikacji wytworzonych i dostarczonych w ramach projektu wskazanych przez Zamawiającego na etapie Analizy przedwdrożeniowej.

c. Testy poprawności konfiguracji i parametryzacji sprzętu serwerowego oraz sprzętu sieciowego aktywnego na styku komunkacji z zewnętrzną siecią.

Testy te będą prowadzone w środowisku produkcyjnym systemu teleinformatycznego w co najmniej 2 iteracjach.

W przypadku zidentyfikowania Błędów lub Wad Oferent jest zobowiązany do ich poprawy przed odbiorem Przedmiotu Zamówienia.


5.5.11 Dodatkowe zobowiązania Oferenta

1. Wykonanie Przedmiotu Zamówienia z efektywnością oraz zgodnie z praktyką i wiedzą zawodową.

2. Wykonanie w całości Przedmiotu Zamówienia w zakresie określonym w Umowie będącej załącznikiem nr 11 do SIWZ.

3. Dokonanie z Zamawiającym wszelkich koniecznych ustaleń mogących wpływać na zakres i sposób realizacji Przedmiotu Zamówienia oraz ciągła współpraca z Zamawiającymi na każdym etapie realizacji.

4. Stosowanie się do wytycznych i polityk bezpieczeństwa informacji obowiązujących u danego Zamawiającego.

5. Udzielanie na każde żądanie danego Zamawiającego pełnej informacji na temat stanu realizacji Przedmiotu Zamówienia.

6. Współdziałanie z osobami wskazanymi przez Zamawiającego.


6 Dostawa i wdrożenie Szpitalnego Systemu

                       Informatycznego                      


6.1 Wymogi dotyczące interoperacyjności lub migracji dla oferowanego

ZSI

1) Oferent zobowiązuje się dostarczyć Zamawiającemu wymagane funkcjonalności ZSI w taki sposób, aby w jak najszerszym zakresie zostały zaspokojone potrzeby Zamawiającego. Zamawiający dopuszcza wymianę posiadanego obecnie rozwiązania. Koniecznym jest zachowanie pełnej wzajemnej interoperacyjności nowo wdrażanych modułów/grup funkcjonalności, a także w przypadku rozbudowy, pełnej interoperacyjności z modułami/grupami/systemami funkcjonalności już funkcjonującymi u Zamawiającego.

2) Szpitalny System Informatyczny, stanowiący źródło Elektronicznej Dokumentacji Medycznej EDM musi mieć zaimplementowane i uruchomione mechanizmy integracji oraz zapewnić prawidłową integrację z systemem EDM,

3) Szpitalny System Informatyczny, jako produkt z zakresu tzw. e-Zdrowia, musi spełniać wymogi i zalecenia im stawiane, takie jak:

1. Zapewnienie pełnej zgodności z Rekomendacjami dla Kryteriów dostępu, zdefiniowanymi w wymogach i rekomendacjach Komitetu Sterującego do spraw koordynacji interwencji EFSI w sektorze zdrowia, które zostały zdefiniowane w załączniku do jego Xxxxxxx Xx 00/0000 z dnia 29 kwietnia 2016 r.

2. Zapewnienie pełnej zgodności na dzień odbioru z opracowaniami publikowanymi przez Centrum Systemów Informacyjnych Ochrony Zdrowia.

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

4. Ustawa z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowia (tj. Dz. U. z 2019 r. poz. 408 z późn. zm.)

5. Zapewnienie komunikacji umożliwiającej wymianę aktualnych danych z rejestrami Platformy Rejestrów Medycznych (P1 oraz P2), odpowiadających analogicznym rejestrom zaimplementowanym w modułach ZSI.

6. Zapewnienie wsparcia obsługi dla Karty Specjalisty Medycznego (KSM).


Realizacja niniejszych powyższych wymagań jest jednym z celów projektu objętego niniejszym postępowaniem i wchodzi w jego zakres.


6.2 Dostępność dostarczanego rozwiązania

Szpitalny System Informatyczny działa w trybie 24 godzinnym przez wszystkie dni w roku z dostępnością co najmniej na poziomie 99% w skali miesiąca dla części białej HIS oraz 97% dla części szarej ERP. System nie jest dostępny, gdy występuje sytuacja uniemożliwiająca wykorzystanie którejś z jego funkcji z przyczyn leżących wewnątrz Systemu (np. awarii, spadku przepustowości Systemu i wynikającego stąd przeciążenia Systemu). Planowane prace serwisowe (tzw. down time) odbywają się w godzinach od 2:00 do 5:00. W ciągu jednego miesiąca mogą odbyć się maksymalnie cztery takie przerwy. Czas planowych prac serwisowych (down time) nie jest liczony jako niedostępność i musi być uzgodniony z Zamawiającym i przez niego zaakceptowanym w formie pisemnej (mailowej lub w formie pisma).


6.3 Wymagany stan docelowy


Zamawiający oczekuje dostarczenia Szpitalnego Systemu Informatycznego co najmniej z modułami (podział na moduły jest jedynie umowny i może przebiegać odmiennie dla zaproponowanego rozwiązania):


Nazwa modułu

Ilość licencji

Zakłada się że w ramach części medycznej systemu szpitalnego zostaną wdrożone co najmniej następujące moduły systemu:

• Izba przyjęć

• SOR

• Oddział

• Panel lekarski

• Ordynacja lekarska

• Opieka pielęgniarska

• Diety / Żywienie pozajelitowe

• Leki – zlecenia / realizacja

Open (bez ograniczeń na liczbę użytkowników). W chwili obecnej Szpital posiada 742 aktywne konta użytkowników w części białej.

• Blok operacyjny

• Blok porodowy

• Bank krwi – zlecenia

• Zakażenia szpitalne

• Apteka

• Apteczka Oddziałowa

• Zlecenia i skierowania

• Zlecenia laboratorium

• Punkt pobrań

• Wyniki pacjenta

• Recepty

• Rehabilitacja

• Xxxxxxxxxxx x XXX

• Rozliczenia komercyjne

• Terminarz

• Gabinet

• Gabinet POZ

• Obsługa kolejek

• Stomatologia

• Laboratorium / Diagnostyka obrazowa / Sterylizacja

• Zarządzanie aparaturą medyczną

• Transport medyczny

• Dializy

• Medycyna pracy

• e-usługi

• Raporty BI

• Kalkulacja kosztów leczenia

• Zarządzanie procedurami medycznymi

• System kolejkowy


Zakłada się że w ramach rozbudowy części administracyjnej systemu szpitalnego zostaną wdrożone następujące moduły systemu:

• Finanse i księgowość

• Koszty

• Rejestr sprzedaży

• Rejestr zakupów

• Zamówienia zakupu oraz kontrakty

• Zamówienie sprzedaży pozamedycznej, zamówienia cykliczne

• Windykacja

• Kasa

Łączna ilość licencji umożliwiająca pracę w części szarej to 70 użytkowników.

W chwili obecnej Szpital posiada 64 aktywne konta (z wyłączeniem portalów

samoobsługowych

• Gospodarka Magazynowa

• Środki trwałe

• Wyposażenie

• Kadry

• Płace

• Grafiki (open)

• Kalkulacja Kosztów Leczenia

• Wycena Procedur Medycznych

• Budżetowanie

• Raportowanie AOTMiT

• Portal pracowniczy

• Zamówienia publiczne

• Kalkulacja kosztów

o projektów, inwestycji

o kosztów leczenia na pacjenta

o innych nośników kosztowych nie ujętych rodzajowo w planie kont (dodatkowe wymiary księgowe, cechy)

– pracowniczych).

Dla portalu samoobsługowego pracowniczego Zamawiający oczekuje licencji bez ograniczeń na liczbę użytkowników.


W chwili obecnej szpital posiada 806 aktywnych unikatowych kont użytkowników w systemach informatycznych części białej i szarej.


Zamawiający dopuszcza, aby poszczególne funkcjonalności mogły być realizowane przez moduły o innych nazwach. Oferowane produkty w ramach zintegrowanego rozwiązania muszą posiadać i realizować co najmniej funkcjonalności przedstawione w rozdziale Wymagania Szczegółowe.


6.4 Dane do przeniesienia do nowego ZSI

Oferent zapewni właściwe wsparcie związane z przeniesieniem (migracją i konwersją danych) we własnym zakresie. Wsparcie o którym mowa będzie polegać na pobraniu, przygotowaniu (konwersji), kontroli spójności i poprawności danych, a następnie importu do nowego wdrażanego rozwiązania i kontroli końcowej poprawności.

Dobór środków technicznych koniecznych do wykonania tak opisanego zadania leży w całości po stronie Oferenta.


6.4.1 HIS

W przypadku, gdy Oferent dokonuje rozbudowy systemu posiadanego przez Zamawiającego przy użyciu produktu z innej linii produktowej (rozumianej jako produkt o innej nazwie handlowej lub innym zarejestrowanym znaku towarowym) lub w przypadku wymiany systemu na nowy, Oferent zobowiązany jest do migracji danych do nowego systemu. Wówczas Zamawiający oczekuje migracji danych z użytkowanych dotychczas systemów, które będą wymieniane do nowego systemu w zakresie umożliwiającym pełną kontynuację pracy w nowym rozwiązaniu.

Oznacza to, że Zamawiający oczekuje, że wykonawca dokona migracji co najmniej: danych pacjentów, pobytów i wizyt oraz danych słownikowych (w tym różnych karotek, list cech, kartotek produktów medycznych, danych kartotekowych, kontraktów, stanów magazynowych). Niemniej ostateczny i

szczegółowy zakres danych do przeniesienia zostanie określony na etapie analizy przedwdrożeniowej przy czym zakłada się, że migracji podlegać będą wszystkie dane, które dostępne są w obecnych systemach.


6.4.2 ERP

Zamawiający oczekuje, że Xxxxxxx przygotuje i skonwertuje dane podstawowe w tym co najmniej kartoteki:

- Dostawców,

- Odbiorców, Płatników,

- Pracowników,

- Indeksów magazynowych,

- Produktów i usług,

- Środków trwałych,

- Kas, banków,

- Oraz wszystkie inne konieczne do prawidłowego uruchomienia systemu i zachowania ciągłości pracy.

Zakres konwersji danych ma zapewniać ciągłość pracy Zamawiającego w nowym systemie bez konieczności odwoływania się (poszukiwania, pobierania, przenoszenia) danych pomiędzy starymi oraz nowym systemem ZSI w okresie co najmniej rok wstecz od momentu uruchomienia systemu.

Zamawiający oczekuje, że Xxxxxxx przygotuje i skonwertuje dane bilansów otwarcia oraz transakcje z roku bieżącego do dnia uruchomienia systemu, a w tym:

- Bilans otwarcia dla roku w którym nastąpi uruchomienie systemu,

- Otwarte transakcje należności na dzień uruchomienia,

- Otwarte transakcje zobowiązań na dzień uruchomienia,

- Nierozliczone salda innych kont bilansowych na dzień uruchomienia,

- Minimum salda poszczególnych miesięcy za okres od początku roku do dnia uruchomienia systemu, tak aby możliwe było wykonanie kompletnego i poprawnego „bilansu próbnego” za dowolny okres narastająco w roku uruchomienia systemu.

- Danych kadrowych oraz płacowych na dzień uruchomienia oraz za poprzednie lata, koniecznych do zachowania ciągłości rozliczeń bez konieczności odwoływania się do danych z innego źródła lub wprowadzania ich ręcznie;jak także na potrzeby prowadzenia sprawozdawczości wewnętrznej oraz zewnętrznej,

- Grafików i harmonogramów pracy na dzień uruchomienia tak aby zapewnić ciągłość rozliczeń kadrowo- płacowych oraz wymagań raportowych.

Zamawiający oczekuje, że konwersja bilansów otwarcia obejmie zakres minimalnie taki, aby zapewnił ciągłość pracy oraz raportowania z wdrożonego ZSI.


6.4.3 Integracja z urządzeniami

W zakresie części HIS oraz ERP Zamawiający oczekuje integracji z wdrażanym rozwiązaniem urządzeń x.xx. z aparatami EKG, KTG, Tomografem komputerowym, angiografem, aparatami RTG, kasami fiskalnymi i innymi


6.4.4 Warunki przeniesienia danych

Zamawiający informuje, że nie posiada dokumentacji struktur baz danych posiadanych systemów. Na prośbę Oferenta, na podstawie art. 9a ust. 2 ustawy Pzp, Zamawiający umożliwi Oferenta dostęp do baz danych posiadanych systemów informatycznych (wizja lokalna) i udzieli wsparcia Oferenta w dokonaniu przeniesienia danych poprzez: nadanie wskazanym pracownikom Oferenta niezbędnych uprawnień do pracy w systemie oraz do zapoznania się ze strukturami tabel w bazach danych posiadanych systemów. Dostęp do baz danych posiadanych systemów informatycznych i ich dokumentacji, może być udzielony po uprzednim uzgodnieniu terminu wizyty Oferenta i po uregulowaniu zasad dostępu do chronionych danych osobowych.

Zamawiający umożliwi Oferenta przeprowadzenie wizji lokalnej w dni robocze, pomiędzy godziną 9:00 a 14:00.

Zamawiający udostępni wykonawcy z którym podpisze umowę posiadane instrukcje obsługi zastępowanych oraz integrowanych systemów jeśli takowe posiada lub jest w stanie bezpłatnie uzyskać.

Zakres przeniesienia danych zostanie określony przez Zamawiającego na wniosek Oferenta i ma odpowiadać potrzebom Zamawiającego do kontynuacji świadczenia usług dla pacjentów i klientów w sposób niezakłócony, tj. bez koniczności sięgania do danych zawartych w innych, już nie wykorzystywanych systemach (nie pracujących produkcyjnie), jak też pozwalać na niezakłócone raportowanie i rozliczenia Zamawiającego, tak zewnętrzne jak i wewnętrzne.

Jeśli przeniesienie danych i ich konwersja nie będzie możliwa w sposób automatyczny lub półautomatyczny, Zamawiający oczekuje, że Oferent dokona przeniesienia danych w sposób ręczny, tj. przy pomocy swoich zasobów osobowych i technicznych. Koszt takiego przeniesienia Oferent powinien ująć w ofercie.

Oferent ponosi odpowiedzialność za ewentualne szkody, wyrządzone przez jego pracowników, powstałe w wyniku działań prowadzonych przez wykonawcę na bazach danych posiadanych systemów.

Informacje uzyskane przez Wykonawcę w toku wykonania czynności, o których mowa w art.75 ust.2 pkt 3 ustawy z dnia 4 lutego 1994 r. o Prawie autorskim i prawach pokrewnych (Dz.U.2019, poz.1231), stanowią tajemnicę przedsiębiorstwa w rozumieniu Ustawy z dnia 16 kwietnia 1993 r. o zwalczaniu nieuczciwej konkurencji (Dz.U.2019, poz.1010) i podlegają ochronie w niej przewidzianej.


7 Szczegółowy Opis Przedmiotu Zamówienia


7.1 Wymagania szczegółowe

Zamawiający poniżej przedstawia wykaz oczekiwanych funkcji oprogramowania ZSI. Przedstawione wymagania posegregowane są wg grup funkcjonalnych (modułów)tylko na potrzeby redakcyjne i nie stanowią w żaden sposób wymagania samego w sobie (finalny podział na moduły, jeśli zachodzi, może być inny).Przedstawione wymagania należy czytać w sposób ciągły i spójny, nie wskazują gdzie dana funkcjonalność powinna być zlokalizowana, a jedynie w kontekście jakiego obszaru biznesu należy ją rozpatrywać.

Wymagania wypisane w tym rozdziale należy traktować jako WYMAGANE (konieczne do realizacji). Wymagania posiadające różne poziomy realizacji podlegają punktacji i ocenie.


7.1.1 Część biała HIS


7.1.1.1 Wymagania ogólne


Lp.

Opis wymagania / punktacja

1.

Działanie systemu

System działa z poziomu popularnych (Chrome, FireFox, Edge) przeglądarek internetowych i nie wymaga instalowania dodatków/wtyczek do przeglądarek (Funkcjonalność dodatkowa – wg pozacenowego kryterium oceny ofert)

System HIS działa z poziomu popularnych Chrome, FireFox, Edge) przeglądarek internetowych ale wymaga instalowania dodatków/wtyczek do przeglądarek (Funkcjonalność dodatkowa – wg pozacenowego kryterium oceny ofert)



System HIS działa z poziomu popularnych Chrome, FireFox, Edge) przeglądarek internetowych

2.

Monitoring kompletności dokumentacji

System posiada aktywny monitoring kompletności dokumentacji lekarskiej i pielęgniarskiej wraz z możliwością wylistowania brakujących dokumentów z poszczególnych dni z poziomu widoku kontekstu pacjenta(Funkcjonalność dodatkowa – wg pozacenowego kryterium oceny ofert)

System posiada aktywny monitoring kompletności dokumentacji lekarskiej i pielęgniarskiej wraz z możliwością wylistowania brakujących dokumentów z poszczególnych dni (Funkcjonalność dodatkowa – wg pozacenowego kryterium oceny ofert)

System posiada aktywny monitoring kompletności dokumentacji lekarskiej i pielęgniarskiej

3.

System musi prezentować historię zmian dokumentów wraz z informacją o użytkowniku, który dokonał modyfikacji dokumentu.

4.

System musi prezentować podgląd danych pacjenta z różnych perspektyw (stan na dany dzień, podgląd parametrów życiowych, wgląd w badania i wszystkie inne zdefiniowane przez użytkownika) w zakresie wszystkich hospitalizacji pacjenta bez konieczności wychodzenia z kontekstu tego pacjenta.

5.

W systemie musi znajdować się ciągły podgląd najważniejszych informacji z hospitalizacji pacjenta w trakcie uzupełniania innych dokumentów tego pacjenta wraz z możliwością przenoszenia/kopiowania dowolnych informacji do aktualnie wypełnianej dokumentacji i możliwość użycia tych danych w bieżącej pracy.

6.


System musi posiadać wbudowane mechanizmy uzupełnienia dokumentacji w dowolnym momencie.

7.

Uzupełnianie dokumentów

System ma możliwość niezależnego uzupełniania dokumentów przez poszczególne grupy personelu (lekarz, pielęgniarka, sekretarka) bez wzajemnej blokady uzupełniania danego dokumentu oraz z możliwością podglądu wprowadzonej informacji przez inną grupę (Funkcjonalność dodatkowa – wg pozacenowego kryterium oceny ofert)

System nie ma możliwości niezależnego uzupełniania dokumentów przez poszczególne grupy personelu (lekarz, pielęgniarka, sekretarka) bez wzajemnej blokady uzupełniania danego dokumentu oraz z możliwością podglądu wprowadzonej informacji przez inną grupę

8.

System musi posiadać funkcjonalność zarządzania wydrukami (zarządzanie drukarkami, kolejkami, konfiguracja, sprawdzanie poprawności działania drukarek, historia drukowanych dokumentów. W szczególności system musi obsługiwać drukowanie różnych dokumentów na różnych, zdefiniowanych przez użytkownika formatach papieru. Dopuszcza się zarządzanie drukarkami przez domenę Windows (AD)

9.

System musi umożliwiać skanowanie dokumentów wraz z umieszczaniem ich w wybranym kontekście (pacjent, badanie)

10.

Obsługa formularzy

System ma możliwość tworzenia i zapisu przez uprawnionych użytkowników bez zaawansowanych kompetencji informatycznych całych dokumentów w postaci formularzy do ponownego wykorzystania (Funkcjonalność dodatkowa – wg pozacenowego kryterium oceny ofert)



System ma możliwości tworzenia i zapisu przez administratorów bez kompetencji programistycznych systemu formularzy do ponownego wykorzystania (Funkcjonalność dodatkowa – wg pozacenowego kryterium oceny ofert)

11.

Prezentacja wyników laboratoryjnych

System przedstawia interaktywne wykresy wyników laboratoryjnych prezentując zmiany koloru ekranu dla wyników badań laboratoryjnych poza normą (Funkcjonalność dodatkowa – wg pozacenowego kryterium oceny ofert)

System przedstawia wyniki badań laboratoryjnych w normalnej postaci liczbowej

12.

Wizualizacja

System ma możliwość oznaczania kolorami poszczególnych pól ekranu w celu zwrócenia uwagi na dane istotne z punktu widzenia organizacji pracy danej komórki organizacyjnej (Funkcjonalność dodatkowa – wg pozacenowego kryterium oceny ofert)

System nie ma możliwości oznaczania kolorami poszczególnych pól ekranu w celu zwrócenia uwagi na dane istotne z punktu widzenia organizacji pracy danej komórki organizacyjnej

13.

System musi umożliwiać pracę wielu użytkowników jednocześnie w ramach jednej wizyty. Jeden użytkownik może dodawać rozliczenie świadczenia drugi uzupełniać dane medyczne dla tej samej wizyty w jednym czasie

14.

System musi pozwalać wprowadzić na jednej wizycie rozliczenia NFZ jak i komercyjne. Wszystkie operacje dodawania rozliczeń wykonywane muszą być z jednego okna rozliczeniowego. Zaewidencjonowane dane muszą się poprawnie sprawozdać do NFZ z wyłączeniem usług komercyjnych natomiast na dokumentach rozliczeniowych typu paragon, faktura z danej wizyty powinny się podpowiadać tylko usługi komercyjne z wyłączeniem pozycji powiązanych z kontraktem NFZ.

15.

System z poziomu administracji musi umożliwiać definiowanie własnych adnotacji do dokumentów, które będą widoczne dla użytkowników w trakcie ich uzupełniania

16.

Zgłoszenia choroby nowotworowej do Rejestru Nowotworów

System umożliwia importowanie i eksportowania zgłoszenia choroby nowotworowej do Rejestru Nowotworów (Funkcjonalność dodatkowa – wg pozacenowego kryterium oceny ofert)

System nie umożliwia importowania i eksportowania zgłoszenia choroby nowotworowej do Rejestru Xxxxxxxxxx

00.

Wymagana jest zgodność systemu z następującymi ustawami i rozporządzeniami:

- Ustawa o działalności leczniczej ;

- Ustawa o systemie informacji w ochronie zdrowia ;

- Ustawa o świadczeniach opieki zdrowotnej finansowanych ze środków publicznych ;

- Rozporządzenie Ministra Zdrowia w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania ;

- Rozporządzenie Ministra Zdrowia w sprawie zakresu niezbędnych informacji gromadzonych przez świadczeniodawców, szczegółowego sposobu rejestrowania tych informacji oraz ich przekazywania podmiotom zobowiązanym do finansowania świadczeń ze środków publicznych;

- Rozporządzenie Ministra Zdrowia w sprawie szczegółowego zakresu danych objętych wpisem do rejestru podmiotów wykonujących działalność leczniczą oraz szczegółowego trybu postępowania w sprawach dokonywania wpisów, zmian w rejestrze oraz wykreśleń z tego rejestru;

18.

System musi być wyposażony w zabezpieczenia przed nieautoryzowanym dostępem. Zabezpieczenia muszą


funkcjonować na poziomie klienta (aplikacja) i serwera (serwer baz danych ),

19.

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

20.

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


7.1.1.2 Wydajność


Lp.

Opis wymagania / punktacja

1.

System powinien umożliwiać jednoczesną pracę na dowolnej liczbie stanowisk nieograniczonej liczby użytkowników niezależnie od funkcjonalności i modularności aplikacji, na Stacjach Roboczych pracujących pod kontrolą systemu operacyjnego np. Microsoft Windows, w wersjach wspieranych przez producenta systemu operacyjnego. Docelowo zakłada się jednoczesną pracę na maksymalnie 1 000 stanowiskach.

2.

Maksymalny czas odpowiedzi Systemu w warunkach rzeczywistej pracy dla czynności potwierdzenia lub wycofania edycji, wyszukiwania, wprowadzania, usuwania danych, z wyłączeniem zestawień statystycznych i raportów, nie może być dłuższy niż 5 sekund dla 250 równocześnie pracujących użytkowników.

3.

Maksymalny czas odpowiedzi Systemu w warunkach rzeczywistej pracy dla zadania wykonania zestawienia statystycznego lub raportu nie może być dłuższy niż 15 minut przy 250 równocześnie pracujących użytkownikach.

4.

Oferent przedstawi zakres testów akceptacyjnych wydajnościowo - obciążeniowych dla opisanej infrastruktury technicznej i oprogramowania, potwierdzających spełnienie parametrów odnośnie zadanych czasów odpowiedzi Systemu. W przypadku jeśli opisana w specyfikacji infrastruktura jest niewystarczająca do spełnienia zadanych wymagań wydajnościowych, Oferent zobowiązany jest do dostarczenia na własny koszt dodatkowych serwerów i/lub macierzy.

5.

Po skonfigurowaniu pełnej infrastruktury, Oferent przeprowadzi w obecności Zamawiającego testy wydajności Systemu i w przypadku nie spełnienia wymagań powinien rozbudować System (licencyjnie, programowo, sprzętowo) lub zmodyfikować sposób przetwarzania danych, zapewniając tym samym spełnienie wymagań bez dodatkowych kosztów dla Zamawiającego.


7.1.1.3 Uprawnienia


Lp.

Opis wymagania / punktacja

1.

Przed przystąpieniem do wdrożenia Oferent musi przedstawić oświadczenie, o fakcie niewykorzystywania udostępnionych mu danych w celu innym jak tylko do wykonania wdrożenia i działań związanych z utrzymaniem i serwisowaniem Systemu.

2.

System musi posiadać zaimplementowane mechanizmy pozwalające na ograniczenie dostępu do danych i funkcji Systemu dla osób niepowołanych.

3.

System musi zapewniać automatyczne wylogowanie użytkownika i wymuszać ponowną autoryzację po określonym, definiowalnym czasie bezczynności.

4.

System musi zapewniać możliwość określenia maksymalnej ilości nieudanych prób logowania, po których nastąpi automatyczne wyłączenie aplikacji oraz maksymalnej ilości błędnych prób logowania, po których nastąpi blokada konta użytkownika.

5.

System musi zapewniać możliwość określenia uprawnień odnośnie zasad modyfikacji zapisów dotyczących zdarzeń terapeutycznych, dostępu do historii poprzednich zapisów, możliwości chronologicznego wyszukiwania, przeglądania i drukowania tych zapisów (w tym dokumentacji medycznej).

6.

System musi zapewniać dostęp z poziomu interfejsu użytkownika do danych historycznych, wpisów odnośnie indywidualnej dokumentacji medycznej oraz danych personalnych pacjenta, stosownie do nadanych uprawnień.

7.

Podstawowe funkcjonalności lub moduły tj. gabinet, pracownia muszą być dostępne w ramach profilu danego użytkownika w ramach posiadanych przez niego uprawnień po jednokrotnym zalogowaniu (system nie może wymagać oddzielnego logowania do każdej funkcjonalności lub modułu).

8.

System musi zapewniać możliwość tworzenia grup użytkowników charakteryzujących się wybranym zestawem uprawnień. Nadawanie uprawnień użytkownikowi następuje poprzez przypisanie go do grupy.

9.

System musi zapewniać możliwość definiowania, edycji, anulowania przez administratora z poziomu interfejsu użytkownika praw dostępu dla poszczególnych grup użytkowników do określonych: modułów, funkcji, jednostek organizacyjnych, opcji menu, formularzy, przycisków, raportów, wydruków i urządzeń. Funkcje, w tym elementy graficznego interfejsu użytkownika, do których dostęp został zabroniony powinny być niedostępne.

10.

Kopiowanie praw dostępu między użytkownikami.

System zapewnia możliwość kopiowania praw dostępu między użytkownikami (Funkcjonalność dodatkowa – wg pozacenowego kryterium oceny ofert)

System nie zapewnia możliwości kopiowania praw dostępu między użytkownikami

11.

System musi zapewniać możliwość tworzenia wzorców praw dostępu i definiowania na ich podstawie grup uprawnień.

12.

System powinien zapewniać możliwość określania parametrów hasła: długość, czas obowiązywania, wymagana kombinacja znaków

13.

System powinien zapewniać możliwość walidacji nadawanych haseł zgodnie z wymogami prawa, w tym nie powinien dopuszczać możliwości nadania takiego samego w zadanym przedziale czasowym.

14.

System powinien zapewniać czytelną prezentację nadanych użytkownikom uprawnień, przedstawiającą do jakich jednostek, modułów, funkcji, szablonów dokumentów dany użytkownik ma dostęp oraz jakie uprawnienia posiada w tym zakresie.

15.

System powinien zapewniać możliwość zmiany hasła przez zalogowanego użytkownika.

16.

System powinien zapewniać możliwość ograniczenia dostępu do wizyt pacjenta dla komórek z zakresu psychologii/psychiatrii przez personel nie pracujący w tych komórkach, w tym powinien zapewniać możliwość ograniczenia uprawnień do podglądu historii choroby pacjentów tylko przez personel medyczny ich prowadzący.

17.

System powinien być zabezpieczony przed nieautoryzowanym dostępem zarówno na poziomie serwera bazy danych jak i na poziomie oprogramowania aplikacyjnego.

18.

System powinien zapewniać przechowywanie haseł w bazie danych w postaci niejawnej (zaszyfrowanej).

19.

System powinien zapewniać możliwość zabezpieczenia dostępu do aplikacji zgodnie z obowiązującymi przepisami w tym poprzez logowanie użytkowników z wykorzystaniem loginu i hasła.


7.1.1.4 Gromadzenie danych w systemie


Lp.

Opis wymagania / punktacja

1.

Rejestr pacjentów

System ma jeden centralny rejestr pacjentów (Funkcjonalność dodatkowa – wg pozacenowego kryterium oceny ofert)

System opiera się o więcej niż jeden rejestr pacjentów, które są wzajemnie zintegrowane

2.

System musi zapewniać jednokrotne wprowadzenie danych, np. danych osobowych danego pacjenta

3.

System musi zapewniać dostępne dla uprawnionego użytkownika z poziomu interfejsu uprawnionego użytkownika mechanizmy umożliwiające usunięcie lub scalenie podwójnych wpisów np. dotyczących danych osobowych pacjenta, powstałych na skutek błędnego wprowadzenia przez operatora określonych identyfikatorów lub innych danych elementarnych (z uwzględnieniem np. deklaracji POZ, wizyt itp.).

4.

System musi zapewniać możliwość wprowadzenia i ewidencji wszystkich, wymaganych prawem, danych dotyczących pacjenta i opiekuna prawnego, w szczególności: nr PESEL, nr dokumentu ubezpieczenia, danych adresowych i kontaktowych, pokrewieństwa oraz zapewnia wykazanie tych danych w informacjach o sprawozdawanych świadczeniach.

5.

System musi umożliwiać zdefiniowanie zablokowania zarejestrowania więcej niż jednego pacjenta np. o tym samym numerze pesel lub o tym samym imieniu nazwisku i dacie urodzenia.

6.

System musi zapewniać pełne i zgodne z obowiązującymi wymogami i prawem ewidencjonowanie danych w zakresie danych pacjentów i realizowanych świadczeń, w tym odnośnie pacjentów obcokrajowców (w tym pacjentów z Unii Europejskiej, na rzecz których realizowane są świadczenia na podstawie przepisów o koordynacji) i posiadających indywidualne ubezpieczenie zdrowotne, a także musi zapewniać możliwość rozliczenia świadczeń wykonanych na rzecz tych pacjentów z kontrahentami (w szczególności z NFZ).

7.

System musi zapewniać możliwość gromadzenia informacji powiązanych z leczeniem pacjenta w ramach DiLO.

8.

System musi zapewniać możliwość gromadzenia informacji w postaci plików typu PDF, JPEG, TXT dołączanych do wybranych zakresów danych (dane pacjenta, dane wizyty, dane badania), w tym badań diagnostycznych obrazowych wykonanych poza Przychodnią i zeskanowanych wersji papierowej dokumentacji medycznej (np. z innych placówek medycznych).

9.

System musi dopuszczać wprowadzenie rozpoznania według lekarza zlecającego w formie słownikowej i opisowej.

10.

System musi umożliwiać wprowadzenie komentarza odnośnie danych osobowych pacjenta oraz świadczenia, w tym w trakcie rejestracji pacjenta, widocznego zarówno dla pracownika rejestracji po wyszukaniu odpowiednio pacjentów lub świadczeń danego pacjenta, jak również dla pracownika wykonującego świadczenie.

11.

System musi zapewniać możliwość definiowania dla jednostek organizacyjnych i personelu własnych podręcznych (preferowanych) zestawów rozpoznań, realizowanych procedur, zleceń itp. na bazie słowników ogólnych.

12.

System musi zapewniać ewidencjonowanie przyporządkowania do wykonanego świadczenia medycznego informacji o ilości i typie zużytych materiałów i leków

13.

System musi zapewniać możliwość tworzenia oraz wykorzystania szablonów dla wyników opisowych.

14.

System musi zapewniać możliwość wprowadzenia blokady edycji wpisów dotyczących zaewidencjonowanych świadczeń w zadanym przedziale czasowym (od miesiąca do miesiąca) dla określonych opcjonalnie: komórek organizacyjnych, personelu realizującego, umów, świadczeń (produktów kontraktowych).

15.

System musi zapewniać możliwość wyszukiwania danych (np. danych osobowych pacjentów) i przeszukiwania słowników po początkowym ciągu znaków lub opcjonalnie po ciągu znaków wewnątrz wyszukiwanej pozycji.

16.

System musi umożliwiać pracownikom szybkie wprowadzanie danych rozliczeniowych (kod produktu kontraktowego, kod produktu jednostkowego, rozpoznania, zrealizowane procedury medyczne) dotyczących świadczeń wykonanych w gabinetach (wprowadzenie danych z listy dziennej przyjęć danego lekarza poprzez np. wsadowy import wskazanych wartości z arkusza xls lub wprowadzenie tych danych z wykorzystaniem jednej formatki umożliwiającej szybkie uzupełnienie danych dla danego dnia i lekarza).

17.

System musi umożliwiać stosowanie podpisu cyfrowego kwalifikowanego i niekwalifikowanego, zgodnie z obowiązującymi wymogami prawa.


7.1.1.5 Obsługa załączników


Lp.

Opis wymagania / punktacja

1.

System musi posiadać funkcjonalność dołączania załączników do dokumentacji medycznej Pacjenta (do zlecenia, do badania, do opisu, do pobytu pacjenta np. oświadczenia) z poziomu pracy danego użytkownika np. rejestracja, poradnia, oddział.

2.

System musi posiadać funkcjonalność ewidencji i kontroli składanych papierowych oświadczeń przez pacjenta: lista kontrolna, skany oświadczeń, dane identyfikacyjne w tym nadany numer, miejsce archiwizacji.

3.

System musi posiadać funkcjonalność dołączania załączników w kontekście danych Pacjenta.

4.

System musi posiadać funkcjonalność przeglądania załączników dołączonych do dokumentacji medycznej.

5.

Obsługa załączników

System posiada funkcjonalność dołączania załączników do dokumentacji Pacjenta bezpośrednio z urządzenia skanującego oraz ze skazanego zasobu sieciowego (Funkcjonalność dodatkowa – wg pozacenowego kryterium oceny ofert)

System posiada funkcjonalność dołączania załączników do dokumentacji Pacjenta ze skazanego zasobu sieciowego

6.

System musiumożliwiać podgląd z poziomu gabinetów załączników dodanych w historii choroby pacjenta.

7.

System musiumożliwiać zdefiniowanie na poziomie administratora maksymalnej wielkości plików dodawanych jako załączniki w zakresie od 1 do 20 MB.


7.1.1.6 Dokumentacja medyczna


Lp.

Opis wymagania

1.

System musiumożliwiać wyświetlanie pełnej dokumentacji poszczególnych pacjentów

2.

System musi umożliwiać weryfikację podpisu elektronicznego niekwalifikowanego na podpisanych wizytach

3.

System musi umożliwiać weryfikację podpisu elektronicznego kwalifikowanego na podpisanych wizytach

4.

System musi umożliwiać zbiorcze drukowanie historii choroby wybranego pacjenta

5.

System musi umożliwiać podgląd dokumentacji medycznej (pojedyncze wizyty)


7.1.1.7 Izba przyjęć

Wymagania dla modułów obsługi szpitala w zakresie lecznictwa stacjonarnego i otwartego

Lp.

Opis wymagania


1)

Przyjęcie nowego pacjenta i wprowadzenie danych personalnych:

- Imię, Nazwisko, PESEL (system weryfikuje poprawność numeru PESEL, dekoduje datę urodzenia i płeć) automatyczne wypełnienie daty urodzenia i płci, typ i nr dokumentu tożsamości, obywatelstwo, grupa krwi, choroba zakaźna, miejsce urodzenia, możliwość wprowadzenia uwag

- Adres zameldowania: kod pocztowy (po wprowadzeniu kodu pocztowego automatyczne uzupełnienie miejscowości z zawężeniem przypisanych do kodu ulic, automatyczne uzupełnienie województwa i kraju), nr domu, nr lokalu

- Adres zamieszkania i adres korespondencyjny - możliwość skopiowania z adresu zameldowania

- Kontakt telefoniczny i adres email

2)

Dane pacjenta: oddział NFZ, uprawnienia pacjenta, nr pacjenta w kartotece


3)

Opiekunowie - możliwość dodania kilku z odnotowania danych: Imię, Nazwisko, Pesel, Telefon, adres zamieszkania. Możliwość odnotowania, że pacjent jest ubezwłasnowolniony lub niezdolny do świadomego wyrażania zgody, wówczas dane dotyczące opiekunów są wymagane do uzupełnienia


4)

Zarejestrowanie jakie stałe leki przyjmuje pacjent z użyciem słownika leków, a jeśli danego leku nie byłoby w słowników, wówczas w polu notatek


5)

Możliwość ewidencji specyficznych danych dotyczących pacjentów z krajów Unii Europejskiej przyjmowanych w ramach przepisów o koordynacji.

6)

Możliwość rejestracji danych pacjenta przyjmowanego na podstawie decyzji wydanej przez wójta/burmistrza.

7)

Możliwość wprowadzenia informacji o trybie przyjęcia i o wyrażeniu zgody pacjenta na leczenie.

8)

W przypadku braku zgody pacjenta na leczenie możliwość ewidencji podstawy przymusowego przyjęcia.

9)

Rejestracja pobytu pacjenta w Izbie Przyjęć:

10)

Wprowadzenie danych o rozpoznaniu z wykorzystaniem słownikaICD10,

11)

Wprowadzenie danych zeskierowania,

12)

Wprowadzenie danychpłatnika.

13)

Wpisanie wywiadu wstępnego z możliwością użycia słownika,

14)

Wpisanie wywiadu przedporodowego.

15)

Możliwość określenia czy świadczenie jest świadczeniem ratującym zdrowie lub życie pacjenta.

16)

Możliwość ewidencji godziny przyjęcia pacjenta oraz godziny zakończenia obsługi.

17)

Moduł umożliwia blokadę dokonania ponownego przyjęcia pacjenta przebywającego już w szpitalu.


18)

Moduł umożliwia zdefiniowanie czy i dla jakich oddziałów dostępne jest dokonanie ponownego przyjęcia pacjenta przebywającego już w szpitalu.


19)

Prowadzenie rejestru (skorowidza) pacjenta z możliwością przeglądu danych archiwalnych z poszczególnych pobytów w szpitalu (rejestr pobytów)


20)

Możliwość informowania zaraz przy przyjęciu pacjenta w izbie Przyjęć o stwierdzanym wcześniej nosicielstwie patogenu alarmowego/czynnym zakażeniu patogenem alarmowym w celu wprowadzenia wczesnej izolacji

21)

Możliwość wyszukiwania pacjentów wg różnych parametrów

22)

Możliwość przyjęcia pacjenta NN.


23)

Scalenie danych pobytu pacjenta w przypadku braku możliwości pierwotnego zweryfikowania jego danych z poprzednimi pobytami po potwierdzeniu danych osobowych np. pacjenta NN


24)

Rejestracja pobytu pacjenta na Izbie Przyjęć - odnotowanie danych przyjęciowych (dane o rozpoznaniu, danych ze skierowania, płatniku, itp.)


25)

Weryfikacja pacjenta w systemie e-WUŚ i archiwizacja kolejnych wpisów. Możliwość wydruku oświadczeń o ubezpieczeniu

26)

Blokowanie możliwości dokonanie ponownego przyjęcie pacjenta przebywającego już w szpitalu


27)

Możliwość ewidencjonowania i wydruk oświadczeń pacjenta/opiekuna prawnego potwierdzających uprawnienie do świadczeń opieki zdrowotnej finansowanych ze środków publicznych

28)

Odnotowanie wykonanych pacjentowi procedur


29)

Możliwość wystawiania recept elektronicznych oraz wydruku recept z systemu dla chorych nie wymagających hospitalizacji


30)

Wywiad i badanie przedmiotowe (z podpowiedziami), możliwość kopiowania z poprzednich hospitalizacji, poradni, izby przyjęć (i odwrotnie), obserwacje i in.


31)

Opcja wypisywania druków, zaświadczeń, skierowań, zwolnień z pracy; możliwość podglądu druków wypisywanych poprzednio (zarówno z oddziału jak i poradni) z możliwością powielania, kopiowania itd.

32)

Ewidencja produktów zgodnie z NFZ.

33)

Ewidencja zużytych środków farmaceutycznych i innych środków dostępnych w apteczce jednostki.


34)

Blokowanie zamknięcia wizyty pacjenta w przypadku braku Karty Zgłoszenia Choroby Psychicznej/Nowotworowej/ Zakaźnej, jeśli pacjentowi zaewidencjonowano takowe rozpoznanie.


35)

Możliwość definiowania przez administratora minimalnego zbioru danych, który musi być uzupełniony przed zamknięciem wizyty pacjenta.


36)

Rejestracja opuszczenia Izby Przyjęć przez pacjenta w jednym z trybów:

- Odmowa przyjęcia do szpitala – wpis do Księgi Odmów i PoradAmbulatoryjnych;

- Zaplanowanie późniejszego terminu przyjęcia i odnotowanie skierowania pacjentado kolejki oczekujących – wpis do Księgi Oczekujących;

- Skierowanie na oddział (ustalenie trybu przyjęcia, oddziału) – wpis do KsięgiGłównej;

- Odnotowanie zgonu pacjenta w Izbie Przyjęć – wpis do KsięgiZgonów;

- Udzielenie pomocy doraźnej– wpis do Księgi Odmów i PoradAmbulatoryjnych.


37)

Prowadzenie analizy odmów hospitalizacji będzie prowadzona w oparciu o ustalony katalog. Katalog będzie dostępny dla lekarza z poziomu porady/odmowy. Zarejestrowana przyczyna odmowy będzie widoczna w Księdze Porad i Odmów Ambulatoryjnych.

38)

Obsługa kart diagnostyki i leczenia onkologicznego (DiLO)

39)

Możliwość przyjęcia pacjenta na podstawie kartyDiLO,


40)

Weryfikacja zgodności danych oraz kompletu danych niezbędnych do przyjęcia pacjentana podstawie karty DiLO, w tym tryb przyjęcia, numer karty, etap realizacji karty,

41)

Możliwość założenia karty DiLO w trakcie trwaniaświadczenia,


42)

MożliwośćzałożeniakolejnejkartyDiLOpacjentadladrugiejgrupyrozpoznańbez konieczności zamykania aktywnej karty,

43)

Możliwość zablokowania zakładania kilku aktywnych kart DiLO dlapacjenta,


44)

Możliwość wydruku karty DiLO w wybranym trybie: tylko strony dot. Obsługiwanegoetapu karty, wszystkie strony, objaśnienia,

45)

Możliwość realizacji kilku etapów karty DiLO podczas jednegoświadczenia,

46)

Możliwość zamknięcia karty DiLO podczas realizacjiświadczenia,

47)

Możliwość anulowania wprowadzonej kartyDiLO,


48)

MożliwośćusunięciainformacjiorealizacjietapukartyDiLOwramachświadczeniabez konieczności usuwania całej karty,

49)

Podglądlistyświadczeń,wramachktórychnastępujerealizacjakolejnychetapówobsługi karty DiLO.

50)

Odmowa przyjęcia do szpitala - wpis do Księgi Odmów i lub Porad Ambulatoryjnych


51)

Prowadzenie analizy odmów hospitalizacji będzie prowadzona w oparciu o ustalony katalog. Katalog będzie dostępny dla lekarza z poziomu porady/odmowy. Zarejestrowana przyczyna odmowy będzie widoczna w Księdze Porad i Odmów Ambulatoryjnych.

52)

Możliwość wystawienia skierowania do innego Szpitala z Izby Przyjęć


53)

Możliwość wystawienia karty informacyjnej z przyczyną odmowy przyjęcia do szpitala wystawianej w Izbie Przyjęć

54)

Odnotowanie skierowania pacjenta do kolejki oczekujących – wpis do Księgi oczekujących

55)

Generowanie wymaganych przez NFZ raportów z kolejki oczekujących

56)

Możliwość wprowadzenia informacji o rodzaju leczenia, na które pacjent oczekuje


57)

Skierowanie/cofnięcie skierowania na oddział (ustalenie trybu przyjęcia, form płatności, wydruk pierwszej strony historii choroby

58)

Odnotowanie zgonu pacjenta na Izbie Przyjęć, wpis do Księgi Zgonów

59)

Przegląd ksiąg: Księga Główna, Oczekujących, Odmów i Porad Ambulatoryjnych, Xxxxxx

00)

Wydruk danych z poszczególnych ksiąg

61)

Możliwość sprawdzenia stanu wolnych łóżek na poszczególnych oddziałach


62)

Wydruk pierwszej strony historii choroby nowo przyjętego pacjenta wg różnych, zdefiniowanych na etapie wdrożenia wzorów historii choroby


63)

Możliwość wydruku podstawowych dokumentów (np. karta informacyjna izby przyjęć, karta odmowy przyjęcia do szpitala, przyjęcie ambulatoryjne itp.) z zakresu danych gromadzonych w systemie

64)

Możliwość przeglądu danych archiwalnych o pacjentach przebywających w przeszłości na Izbie Przyjęć

65)

Odczyt kodu kreskowego z opaski pacjenta

66)

Możliwość parametryzacji pól obligatoryjnych przy przyjęciu pacjenta do szpitala

67)

Weryfikacji e-WUŚ (weryfikacja indywidualna i zbiorcza)

68)

Wydruk opasek dla pacjenta z kodem kreskowym


69)

Nadruk danych pacjenta na wzór Historii choroby oraz na medyczna kartę pacjenta (wzory dokumentów obowiązujących w Szpitalu)


70)

Współpraca z czytnikami kodów kreskowych, w zakresie co najmniej identyfikacji pacjenta po kodzie zamieszczonym na dokumentacji medycznej oraz pracownika po identyfikatorze osobowym.


71)

Współpraca z czytnikami dowodów osobistych w zakresie co najmniej odczytywania danych pacjenta: nazwisko, imię, PESEL, nr dowodu osobistego


72)

Moduł umożliwia generowanie zestawień:

1. wizytywIzbiePrzyjęć(zestawieniewszystkichwizytwdanymokresiewgdecyzjidot. procesu leczenia),

2. zestawienie wykonania produktów NFZ dotyczących danejwizyty,

3. zestawienie rozpoznańokreślonychupacjentów(zestawienie zarówno konkretnych rozpoznań jak i dla wszystkich wg płatnika, województwa, okresu), zestawienie bieżących przyjęć w IzbiePrzyjęć.


7.1.1.8 SOR


Lp.

Opis wymagania


1)

System musi umożliwiać podział SOR na obszary i przypisania pacjenta do określonego obszaru SOR. Podział SOR na obszary jest opcjonalny.


2)

System musi umożliwiać dla jednostek organizacyjnych typu SOR włączenie obsługi i prezentacji statusu pilności (TRIAGE) pacjentów.


3)

System musi umożliwiać przypisanie lub zmianę statusu pilności (TRIAGE) pacjenta w dowolnym momencie pobytu na SOR.


4)

Oznaczanie statusu pilności (TRIAGE) (jeśli jest włączone) pacjenta powinno być wymagane i status ten powinien być wyraźnie prezentowany na liście pacjentów oraz danych pobytu pacjenta na SOR. Wystarczającym sposobem prezentacji statusu pilności pacjenta jest użycie odpowiadającemu danemu statusowi koloru.


5)

Przypisanie i zmiana statusu pilności pacjenta musi być zapisanie w dzienniku systemu z podaniem przyczyny zmiany.

6)

System musi wymagać autoryzacji zmiany statusu pilności.


7)

Na panelu głównym pulpitu SOR, oraz na liście pacjentów system musiprezentować liczbę pacjentów SOR w podziale na statusy pilności (TRAGE). Przypisanie i zmiana statusu pilności powinna wymusić aktualizację statystyk liczb pacjentów w podziale na statusy.


8)

System musiumożliwiać klasyfikację pacjentów z wykorzystaniem następujących kolorów: czarny, czerwony, pomarańczowy, żółty, zielony, niebieski


9)

Przypisanie i zmiana statusu pilności powinna wymusić aktualizację statystyk liczb pacjentów w podziale na statusy.


10)

Dla jednostki organizacyjnej typu SOR musi być możliwość zdefiniowania standardów czasowych obsługi pacjenta dla poszczególnych kolorów (kolory TRIAGE).


11)

Na panelu głównym pulpitu SOR oraz na liście pacjentów SOR system musi prezentować czas oczekiwania liczony na podstawie czasów obsługi przypisanych do poszczególnych kolorów.


12)

System musi umożliwiać przeniesienie w trybie nagłym na oddział, nie wymagające uprzedniego uzupełnienia danych pobytu na SOR.


13)

System musi udostępnić funkcjonalność szybkiego skierowania pacjenta na oddział nawet w sytuacji, gdy nie wypełniono w systemie wszystkich danych (w tym wymaganych do zakończenia pobytu na SOR), danych i dokumentów dokumentacji medycznej, wymaganej autoryzacji danych.

14)

Pacjenci przeniesieni na oddział w trybie pilnym muszą być oznaczeni na liście pacjentów SOR.


15)

Dane pacjentów przeniesionych w trybie pilnym do innej jednostki organizacyjnej mogą być uzupełnione w dowolnym momencie, ale nie uzupełnienie przez SOR wymaganych danych powinno blokować wypis lub przeniesienie pacjenta z jednostki, do której został w trybie pilnym skierowany.

16)

Xxxx istnieć możliwość wskazania lekarza prowadzącego.

17)

System musi wspierać tworzenie wymaganej dla SOR dokumentacji medycznej.


18)

System musiumożliwiać wyświetlanie listy pacjentów przebywających na SOR w zadanym przedziale czasu, których status potwierdzenia płatnika jest ustawiony na "Oświadczenie".


19)

System musiumożliwiać rozliczenie komercyjne pacjentów nieuprawnionych do świadczeń. Wymaganie będzie realizowane w ramach rozliczeń komercyjnych lecznictwa zamkniętego.

20)

Zaawansowane wyszukiwanie pacjenta.


21)

System musi udostępniać zaawansowane metody wyszukiwania pacjentów z uwzględnieniem przeszukiwania pól opisujących pacjentów NN oraz możliwości wpisania części i/lub wariantów ciągów znaków opisujących nazwisko, imię, nazwisko xxxxxx, miejscowość zamieszkania, opis pacjenta NN. Użytkownik musi móc zdecydować w momencie wyszukiwania czy wybiera zaawansowane metody wyszukiwania.


22)

System musiumożliwiać przeszukiwanie również poprzednich wersji danych osobowych oraz danych pacjentów scalonych z innymi pacjentami.


23)

System powinien umożliwiać śledzenie procesu udzielania świadczeń w przebiegu TRIAGE poprzez przypisanie zadań wykonywanych przez personel za pomocą indywidualnych dla danej grupy kolorów informujących o zleconych, wykonanych i zatwierdzonych zadaniach.


24)

System umożliwia integrację z aparaturą medyczną - analizatorem badań krytycznych, np. ekg, ktg w zakresie możliwości podglądu i rejestracji wyników badań z tych urządzeń np. poprzez wywołanie obrazu z PACS poprzez link.


25)

System w zależności od uzyskanych wyników badań automatycznie będzie przypisywał kolor TRIAGE. Przypisany przez system kolor personel medyczny będzie uprawniony zmodyfikować w zależności od nadanych uprawnień. (lekarz, pielęgniarka, ratownik medyczny).


26)

System zapewni wyświetlanie komunikatów i alertów dot. x.xx. o statusie zleconych badań diagnostycznych, wyników alarmowych.

27)

System zapewni implementację wyników badań diagnostycznych do HIS do dokumentacji medycznej pacjenta.


28)

System zapewni możliwość generowania raportów: liczba przyjętych, ICD, urazy wielonarządowe, przyjęcia w tym obcokrajowcy i obywatele UE, zakres udzielonych świadczeń ze wskazaniem lekarza prowadzącego, pacjentów przyjętych pod wpływem alkoholu i po zażyciu narkotyków, dopalaczy.


29)

System powinien zliczać samodzielnie wybrane skale –SOFA (Sequential Organ failureAssesment), GCS (Glasgow ComaScale) oraz umożliwiać podgląd kategoryzacji pacjentów w systemie rozliczeniowym NFZ


30)

Możliwość przeglądu danych archiwalnych o pacjentach przebywających w przeszłości na Izbie Przyjęć z uwzględnieniem ponownego powrotu pacjentów, którym odmówiono przyjęcia do Szpitala.


31)

System musi umożliwiać podgląd wyników badań laboratoryjnych, obrazowych, histopatologicznych i innych wykonanych w przeszłości w Szpitalu u danego chorego o ile są dostępne w systemie (wg danych chorego, dat hospitalizacji/badań).

32)

W wypadku zatrzymania krążenia i resuscytacji – implementacja danych do modułu zdarzeń niepożądanych

33)

System musi umożliwiać tworzenie i wydruk dokumentacji indywidualnej pacjentów SOR.

34)

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

35)

System musi umożliwiać definiowanie własnych wykazów w oparciu o zgromadzone w systemie dane.


36)

W module funkcjonuje Apteczka Oddziałowa ewidencja zużytych leków i materiałów oraz aktualizacja stanów magazynowych.

37)

Możliwość prowadzenia księgi transfuzji (zgodnie z rozporządzeniem o leczeniu krwią).

38)

Możliwość zamawiania składników krwi (zgodnie z rozporządzeniem o leczeniu krwią).

39)


Obsługa zgłaszania zdarzeń niepożądanych (zgodnie z rozporządzeniem o leczeniu krwią) z poziomu modułu


zdarzeń niepożądanych.


7.1.1.9 Obsługa oddziału


Lp.

Opis wymagania / punktacja


1.

System musi zapewniać możliwość wyszukiwania pacjentów na liście oddziału bez użycia znaków specjalnych co najmniej w zakresie:

1. Imię

2. Nazwisko

3. PESEL

4. Numer księgi głównej

5. Numer księgi oddziałowej

6. Lekarz prowadzący

7. Rozpoznanie

8. ID pacjenta


2

System musi zapewniać możliwość filtrowania listy pacjentów oddziału co najmniej według poniższych kryteriów:

- Pacjenci bieżący, wypisani, zaplanowani

- Pacjenci bez lekarza prowadzącego

- Strefa

- Lekarz prowadzący

- Sala

3

Wyszukiwanie pacjentów

System zapewnia możliwość zapisania szablonów filtrów wyszukiwania listy pacjentów oddziału (Funkcjonalność dodatkowa – wg pozacenowego kryterium oceny ofert)

System zapewnia wyszukiwanie listy pacjentów bez zapisania szablony filtrów wyszukiwania


- 4

System musi zapewniać możliwość wyświetlania istotnych informacji o pacjencie na liście oddziału przypisanych do profilu użytkownika co najmniej w zakresie:

- Data i godzina przyjęcia

- Lekarz prowadzący

- Sala i łóżko

- Rozpoznanie (pełne, kod, opis)


- 5

System ostrzeżeń

System zapewnia możliwość wyświetlania ostrzeżeń na liście pacjentów oddziału co najmniej w zakresie:

- Skala Norton, REAL, XXXXXXXX΄A.

- Ocena stanu odżywienia

- Liczba dni od założenia aktualnego cewnika

- Liczba dni cewnikowania

- Odleżyny

- Liczba dni od zakończenia poprzedniej hospitalizacji na oddziale

- Czas przymusu bezpośredniego

- Czas założonego wkłucia obwodowego przekraczający 72h(Funkcjonalność dodatkowa – wg pozacenowego kryterium oceny ofert)



System nie posiada funkcji wyświetlania ostrzeżeń na liście pacjentów oddziału w zakresie:

- Skala Norton, REAL, XXXXXXXX΄A.

- Ocena stanu odżywienia

- Liczba dni od założenia aktualnego cewnika

- Liczba dni cewnikowania

- Odleżyny

- Liczba dni od zakończenia poprzedniej hospitalizacji na oddziale

- Czas przymusu bezpośredniego

- Czas założonego wkłucia obwodowego przekraczający 72h


-


6

System musi zapewniać możliwość wyświetlania na liście pacjentów oddziału alertu o podejrzeniu zakażenia szpitalnego wygenerowany po wpisaniu w dokumentację wartości przekraczające dopuszczalne normy (np. temperatura powyżej 38°C)


-


7

System musi zapewniać możliwość wyszukiwania pacjenta do przyjęcia na oddział co najmniej według poniższych kryteriów:

- Imię

- Nazwisko

- Pesel lub numer paszportu lub nadane ID pacjenta

-

8

System musi zapewniać możliwość przyjęcia na oddział pacjenta NN


-


9

System musi zapewniać możliwość przy przyjęciu pacjenta na oddział uzupełnienia danych przyjęciowych co najmniej w zakresie:

- Wpis do kolejki

- Jednostka rozliczeniowa

- Tryb przyjęcia Uprawnienia pacjenta

- Opiekun

- Karta DiLO

- Data przyjęcia

- Uzupełnienie skierowania

- Komentarz

-

10

System musi zapewniać możliwość nadania numeru księgi głównej i oddziałowej automatycznie lub ręcznie


-


11

System musi zapewniać możliwość automatycznego zawężania listy dokumentów do przypisanych do konkretnego oddziału


-


12

System musi zapewniać możliwość wyświetlania listy dokumentów dodanych w ramach aktualnej hospitalizacji z informacją o nazwie dokumentu, dacie dodania i osobie dodającej


-


13

System musi zapewniać możliwość podejrzenie historii zmian w dokumencie z wyszczególnieniem danych dodanych, zmodyfikowanych oraz usuniętych


-


14

System musi zapewniać możliwość podejrzenia dokumentacji pacjenta w trakcie uzupełniania dokumentacji bez wychodzenia z kontekstu dokumentu


-


15

System musi zapewniać możliwość przeglądania wystawionych zleceń pacjenta z oznaczeniem statusów co najmniej w zakresie:

- Punkt pobrań


- Oczekuje

- Zrealizowane

- Anulowane


-


16

System musi zapewniać możliwość przeglądania najważniejszych informacji o pacjencie z ostatniego dyżuru w jednym miejscu co najmniej w zakresie:

- Obserwacje lekarskie

- Obserwacje pielęgniarskie

- Parametry życiowe w formie wykresu z możliwością wyboru parametrów jakie na wykresie mają się znaleźć

- Zlecenia leków (po nazwach międzynarodowych)

- Wyniki badań

- Doba pobytu


-


17

System musi zapewniać możliwość przeglądania wyników badań zleconych pacjentowi z możliwością filtrowania co najmniej w zakresie:

- Rodzaj badania

- Zakres dat


-


18

System musi zapewniać możliwość przeglądania wyników badań laboratoryjnych w formie tabelarycznej z oznaczeniem wartości odstających oraz w formie wykresu z możliwością wyboru parametrów znajdujących się na wykresie.

-

19

System musi zapewniać możliwość zlecania leków.


-


20

System musi zapewniać możliwość wystawiania recept z możliwością kontynuacji leczenia na podstawie recept wcześniej wystawionych.

-

21

System musi zapewniać możliwość wystawiania skierowań oraz e-skierowań.


-


22

System musi zapewniać możliwość przeglądania historii choroby pacjenta z możliwością sortowania co najmniej w zakresie:

- Wyboru dokumentu

- Jednostki realizującej

- Wyboru świadczenia


-


23

System musi zapewniać możliwość uzupełnienia dokumentacji związanej z zakażeniami szpitalnymi, wraz z automatycznym rozpoznaniem patogenu alertowego i wygenerowaniem wymaganych przepisami prawa raportów, w tym sprawozdawczości w systemach NFZ.


-


24

System musi zapewniać możliwość wyświetlania listy braków w dokumentacji oraz wyświetlania komunikatu w przypadku zatwierdzania dokumentu wypisu pacjenta


-


25

System musi zapewniać możliwość wystawiania zleceń co najmniej w zakresie:

- Laboratorium /analityka, patomorfologia/ mikrobiologia / toksykologia/

- Radiologia

- Rehabilitacja

- Zabieg operacyjny

- Konsultacja

- Procedura

- Pracownia

- Dializa


-


26

System musi zapewniać możliwość przypisania tożsamości do pobytu po zmianie danych w trakcie hospitalizacji

- 27

System musi zapewniać możliwość kopiowania wpisanego rozpoznania do innych dokumentów


- 28

System musi zapewniać możliwość kopiowania wpisów z wcześniej dodanych tożsamych z wypełnianym dokumentów


- 29

System musi zapewniać możliwość podzielenia oddziału na odcinki, stworzenie SOR oraz (osobno) izby przyjęć

- 30

System musi zapewniać możliwość generowania wszystkich wymaganych prawnie raportów

- 31

System musi zapewniać możliwość ewidencji danych niezbędnych dla sporządzenia karty gorączkowej.


- 32

System musi zapewniać możliwość przeglądu karty gorączkowej, prezentacji interpretacji graficznej wyników.


- 33

System z poziomu administracji musi posiadać możliwość definiowania własnych adnotacji do dokumentów, które będą widoczne dla użytkowników w trakcie ich uzupełniania

- 34

System musi umożliwiać Elektroniczną Weryfikację Uprawnień Świadczeniobiorców.


- 35

System musi umożliwiać ewidencjonowanie i wydruk oświadczeń pacjenta/opiekuna prawnego potwierdzających uprawnienie do świadczeń opieki zdrowotnej finansowanych ze środków publicznych


- 36

System musi umożliwiać wydruk opasek identyfikacyjnych zawierających dane dopuszczone prawem:

- dla pacjentów dorosłych w tym z izby przyjęć,

- dla dzieci.


- 37

System musi umożliwiać wydruk opasek identyfikatora ze zdjęciem dla dziecka, które nie ukończyło 6 r.ż. w przypadku, gdy założenie opaski identyfikacyjnej dziecku jest niemożliwe.


- 38

Potwierdzenie przyjęcia na Oddział:

- nadanie numeru Księgi Oddziałowej – automatycznie z możliwością modyfikacji numeru,

- wprowadzenie daty i godziny przyjęcia

- wprowadzenie danych lekarza prowadzącego.

- przypisanie pacjentowi diety,

- przydzielenie pacjentowi łóżka,

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

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

itp.

- 39

System musi umożliwiać rejestrację przyjęcia pacjenta na Oddział z określeniem trybu przyjęcia.

- 40

System musi umożliwiać przyjmowania pacjentów na turnusy.


- 41

System musi umożliwiać odmowę przyjęcia na oddział – zgłoszenie na Izbę Przyjęć żądania anulowania przyjęcia.

- 42

System musi umożliwiać przegląd i aktualizację danych personalnych.


- 43

System musi umożliwiać monitorowanie stanu obłożenia Oddziału (moduł musi dopuszczać przyjęcie pacjenta nawet, gdy nie ma wolnych łóżek na Oddziale z zaznaczeniem tego faktu np. poprzez adnotację).

- 44

System musi umożliwiać wprowadzenie rozpoznań: wstępnych, końcowych, przyczyny zgonu.

- 45

System musi umożliwiać pobranie rozpoznania z listy wcześniejszych pobytów na oddziale danego pacjenta.


- 46

System musi umożliwiać zablokowanie zamknięcia hospitalizacji w przypadku braku karty zgłoszenia choroby nowotworowej/zakaźnej, jeśli pacjent ma rozpoznanie nowotworowe/zakaźne.


- 47

System musi umożliwiać definiowanie przez administratora minimalnego zbioru danych, który musi być uzupełniony przed zamknięciem hospitalizacji pacjenta.


- 48

System musi umożliwiać przekazanie do wykonania procedur zabiegowych w gabinetach zabiegowych oddziału.

- 49

System musi umożliwiać wpisanie pacjenta do księgi oczekujących na dalsze świadczenia.


- 50

System musi umożliwiać planowanie kolejnych wizyt w ramach kontynuacji leczenia lub wizyt poszpitalnych.

- 51

System musi umożliwiać obsługę kart diagnostyki i leczenia onkologicznego (DiLO).

- 52

System musi umożliwiać przyjęcie pacjenta na podstawie karty DiLO.


- 53

System musi umożliwiać weryfikację zgodności danych oraz kompletu danych niezbędnych do przyjęcia pacjenta na podstawie karty DiLO, w tym tryb przyjęcia, numer karty, etap realizacji karty.

- 54

System musi umożliwiać założenie karty DiLO w trakcie trwania świadczenia.


- 55

System musi umożliwiać założenia kolejnej karty DiLO pacjenta dla drugiej grupy rozpoznań bez konieczności zamykania aktywnej karty.

- 56

System musi umożliwiać zablokowanie zakładania kilku aktywnych kart DiLO dla pacjenta.


- 57

System musi umożliwiać wydruk karty DiLO w wybranym trybie: tylko strony dot. obsługiwanego etapu karty, wszystkie strony, objaśnienia.

- 58

System musi umożliwiać realizację kilku etapów karty DiLO podczas jednego świadczenia.

- 59

System musi umożliwiać zamknięcie karty DiLO podczas realizacji świadczenia.

- 60

System musi umożliwiać anulowanie wprowadzonej karty DiLO.


- 61

System musi umożliwiać usunięcia informacji o realizacji etapu karty DiLO w ramach świadczenia bez konieczności usuwania całej karty.


- 62

System musi umożliwiać podgląd listy świadczeń, w ramach których następuje realizacja kolejnych etapów obsługi karty DiLO.


- 63

System musi umożliwiać wypełnianie i wydruk standardowych druków zewnętrznych:

- Karta Statystyczna,

- Karta Leczenia Żywieniowego,

- Karta Zgłoszenia Choroby Zakaźnej,

- Karta Zgłoszenia Choroby Nowotworowej,

- Karta Zgonu,

- Karta Informacyjna z leczenia szpitalnego,

- Odstąpienie od sekcji zwłok z możliwością złożenia elektronicznego podpisu przez członka rodziny upoważnionego wcześniej bądź przedstawiciela ustawowego.

- 64

System musi umożliwiać obsługę dyżurów lekarskich.


- 65

System musi umożliwiać blokowanie wypisu przy braku potwierdzenia kompletności dokumentacji medycznej pacjenta.


- 66

System musi posiadać mechanizmy weryfikujące daty procedur medycznych oraz rozliczeniowych z datami pobytu pacjenta.


- 67

System musi umożliwiać poinformowanie lekarza prowadzącego za pomocą komunikatu o uzupełnieniu informacji o planowanej dacie wypisu pacjenta z oddziału.


- 68

System musi umożliwiać ewidencję danych do rozliczenia kontraktowanych produktów z płatnikiem, w tym rozliczanie kart TISS28.


- 69

System musi umożliwiać parametryzację kart informacyjnych leczenia szpitalnego – dla każdego oddziału osobno.

- 70

System musi umożliwiać ewidencję wystawionych recept zgodnie z obowiązującymi przepisami.


- 71

System musi umożliwiać tworzenie, obsługę i monitowanie różnych ścieżek postępowania z pacjentem obejmujących zdarzenia medyczne realizowane poprzez usługi ambulatoryjne, hospitalizacyjne i diagnostyczne.


- 72

System musi umożliwiać współpracę z czytnikami kodów kreskowych w zakresie co najmniej identyfikacji pacjenta po kodzie zamieszczonym na dokumentacji medycznej oraz pracownika po identyfikatorze osobowym.


- 73

System musi umożliwiać współpracę z czytnikami dowodów osobistych w zakresie co najmniej odczytywania danych pacjenta: nazwisko, imię, PESEL, nr dowodu osobistego.


- 74

System musi umożliwiać limitowanie dostępu do danych wyłącznie osobom uprawnionym, poprzez konfigurowanie schematów uprawnień.


- 75

System musi umożliwiać generowanie raportów (zakres minimalny):

- obłożenie łóżek Oddziału na określony dzień,

- zestawienie nowoprzyjętych/wypisanych pacjentów do Oddziału dzień/godzina),

- zestawienie pacjentów oczekujących na przyjęcie na Oddział,

- zestawienie pacjentów hospitalizowanych wg czasu pobytu (powyżej X dni),

- zestawienie pacjentów wg jednostki chorobowej (rozpoznanie zasadnicze),

- średni czas pobytu (szpital/Oddział),

- średni czas pobytu wg jednostki chorobowej (rozpoznania zasadniczego),

- miesięczne zestawienie ilości przyczyn zgonów,

- zestawienie przyjęć wg województwa, ubezpieczyciela,

- zestawienie przyjęć do szpitala wg lekarza kierującego i przyjmującego.


- 76

System musi umożliwiać wgląd w dane matki z poziomu danych medycznych noworodka bez konieczności osobnego wyszukiwania matki jako innego pacjenta.


- 77

System musi umożliwiać ewidencję danych porodu, co najmniej w zakresie:

- wywiadu przedporodowego (badania położniczego),

- wpisu do Księgi Porodów,

- odnotowania danych noworodka (medyczne, skala Apgar),

- odnotowania badania przedmiotowego noworodka,

- odnotowania informacji o zabiegach i powikłaniach.

- 78

System musi umożliwiać prowadzenie książki transfuzyjnej zgodnie z rozporządzeniem o leczeniu krwią).

- 79

Możliwość zamawiania składników krwi (zgodnie z rozporządzeniem o leczeniu krwią).


- 80

System musi umożliwiać obsługę zgłaszania zdarzeń niepożądanych (zgodnie z rozporządzeniem o leczeniu krwią) z poziomu modułu zdarzeń niepożądanych.


- 81

System musi umożliwiać automatyczne rozpoznawanie konieczności podpowiadania zakresu umowy dotyczących świadczeń, które nie są wykonywane na podstawie karty DiLO, a dotyczą rozpoznań onkologicznych.


7.1.1.10 Panel lekarski


Lp.

Opis wymagania / punktacja

1.

System musi umożliwiać wybór graficznej lub tabelarycznej prezentacji wyników badań laboratoryjnych.

2.

System musi umożliwiać prezentację przekroczeń norm w graficznej i tabelarycznej formie wyników badań laboratoryjnych.

3.

System musi umożliwiać definiowanie (przypinania do panelu) w panelu aktywnej listy formularzy oraz raportów, a z których użytkownicy najczęściej korzystają.

4.

System musi umożliwiać stosowanie filtrów listy pacjentów obejmujące:

- pacjentów tylko lekarza prowadzącego,

- pacjentów lekarza prowadzącego oraz innych prowadzących,

- pacjentów tylko z aktualnej jednostki organizacyjnej szpitala,

- pacjentów z wszystkich jednostek organizacyjnych szpitala,

- aktualnych pacjentów,

- wypisanych pacjentów,

- pacjentów z zadaniami do wykonania,

- pacjentów z innych oddziałów z leczeniem skojarzonym,

- pacjentów z innych oddziałów oczekujących na konsultacje.

5.

System musi umożliwiać sortowanie pacjentów według:

- daty przyjęcia,

- nazwiska i imienia,

- xxxx i xxxxx.

6.

System musi umożliwiać tekstowe wyszukiwanie pacjentów z listy pacjentów.

7.

System musi umożliwiać tekstowe wyszukiwania elementów historii leczenia.

8.

System musi umożliwiać ograniczanie wyświetlanych w panelu danych dotyczących danego pacjenta z okresu:

- ostatnie 24h,

- ostatnie 72h,

- wybrany dzień,

- zakres dat od do.

9.

System musi umożliwiać konfigurowanie wyświetlanych danych w obszarze dotyczącym danego pacjenta w zakresie min.:

- imię,


- nazwisko,

- płeć,

- data urodzenia,

- PESEL,

- nr w Książce Oddziałowej,

- nr w Księdze Głównej,

- sala/łóżko,

- rodzaj diety,

- lekarz prowadzący.

10.

System musi umożliwiać rejestrację danych o:

- krwi (grupa, Rh, fenotyp, przeciwciała, VDRL, HBS, HCV, HIV) i wszystkich zmian dotyczących grupy krwi pacjenta,

- ewidencja informacji o źródle danych dotyczących grupy krwi,

- możliwość wymuszenia dodatkowego podania hasła przed modyfikacją danych dotyczących grupy krwi,

- podstawowych badaniach,

- informacjach ginekologicznych.

11.

System musi umożliwiać redefiniowanie znaczenia pól opisowych wywiadu w zależności od wymagań poszczególnych oddziałów/poradni.

12.

System musi umożliwiać definiowanie przez użytkownika szablonów dla wywiadu, osobno dla każdego z pól opisowych, z możliwością przypisania szablonu dla jednostki organizacyjnej bądź wszystkich jednostek organizacyjnych.

13.

System musi umożliwiać kopiowanie danych z poprzedniego wywiadu.

14.

System musi umożliwiać kopiowanie do wywiadu dowolnej informacji dostępnej w systemie

15.

System musi umożliwiać rejestrację danych o stosowanych lekach i alergiach. System musi posiadać predefiniowane katalogi międzynarodowych nazw, substancji oraz produktów.

16.

System musi umożliwiać rejestrację danych o badaniach przedmiotowych z opcją definiowania szablonów dla poszczególnych oddziałów osobno. Możliwość podziału badań przedmiotowych na klasy i ich oddzielna obsługa.

17.

System musi umożliwiać skopiowanie poprzedniego wyniku badania do bieżącego z możliwością jego edycji po skopiowaniu.

18.

System musi umożliwiać ustawienie dla każdego badania wartości domyślnej, wstawianej po wczytaniu szablonu, bądź danego badania.

19.

System musi umożliwiać ustawianie wartości domyślnej dla wybranych pól.

20.

System musi umożliwiać domyślne wczytanie poprzedniej wartości badania.

21.

System musi umożliwiać ewidencjonowanie badań przedmiotowych w strukturze hierarchicznej i ich prezentację za pomocą tzw. „drzewa”.

22.

System musi umożliwiać wprowadzenie rozpoznań: wstępnych (z Izby Przyjęć lub SOR), zasadniczych, współistniejących.

23.

System musi umożliwiać wprowadzenie dodatkowych informacji o chorobach: przebytych chorobach, chorobach w rodzinie.

24.

System musi umożliwiać wprowadzenie informacji dotyczących planu opieki, o obserwacjach lekarskich.

25.

System musi umożliwiać definiowanie klasyfikacji i szablonów dla planu opieki i obserwacji lekarskich.

26.

System musi umożliwiać definiowanie dowolnych kategorii obserwacji (innych niż lekarskie) i ich osobna obsługa.

27.

System musi umożliwiać generowanie obserwacji lekarskich na podstawie udzielonych konsultacji.

28.

System musi umożliwiać automatyczne dodawania procedury medycznej na podstawie zrealizowanej konsultacji

29.

System musi umożliwiać pobieranie wyników diagnostycznych oraz laboratoryjnych z danego dnia do obserwacji lekarskich.

30.

System musi umożliwiać ewidencjonowanie obserwacji lekarskich wszystkich pacjentów oddziału na jednym ekranie.

31.

System musi umożliwiać wypełnienie automatycznie karty informacyjnej w oparciu o zgromadzone dane o leczeniu (wyniki laboratoryjne, diagnostyczne, rozpoznania, procedury).), z. Z możliwością ustawienia sposobu ich wyświetlania (sortowanie).

32.

System musi umożliwiać zdefiniowanie sposobu wyświetlania/sortowania wyników laboratoryjnych, diagnostycznych, rozpoznań, procedur medycznych na karcie informacyjnej.

33.

System musi umożliwiać definiowanie przez użytkownika szablonów dla poszczególnych pozycji zawartych w karcie informacyjnej.

34.

System musi umożliwiać przeglądanie epikryz z poszczególnych pobytów danego pacjenta.

35.

System musi umożliwiać kopiowanie informacji z dowolnej poprzedniej epikryzy do bieżącej, z możliwością jej edycji po skopiowaniu.

36.

System musi umożliwiać definiowanie przez użytkownika szablonów dla epikryz.

37.

System musi umożliwiać przeglądanie wywiadów z poszczególnych pobytów.

38.

System musi umożliwiać przypominanie o wypełnieniu dokumentu związanego ze stanem odżywienia, monitorowaniem bólu, zakażeniami, oceną geriatryczną, oceną zagrożenia wystąpienia odleżyn, oceną kategorii pacjenta (wywiad epidemiologiczny).

39.

System musi umożliwiać wprowadzanie informacji związanych z podjętymi resuscytacjami, ich przyczynami, skutecznością – dokonywanie analiz, generowanie raportów.

40.

System musi umożliwiać generowanie informacji o zaistniałych zgonach pacjentów, w tym zgonach okołooperacyjnych, w wypadku gdy zgon zakwalifikowany zostanie jako zdarzenie niepożądane – zdarzenie musi zostać zarejestrowane w module zdarzeń niepożądanych.

41.

System musi umożliwiać wprowadzanie danych i analiz związanych z podjętymi działaniami resuscytacyjnymi prowadzonymi w oddziałach.

42.

System musi umożliwiać rejestrację zdarzeń niepożądanych związanych z udzielaniem świadczeń w oddziałach.

43.

System musi umożliwiać zlecanie pacjentowi konsultacji lekarskich.

44.

System musi umożliwiać przegląd wyników konsultacji lekarskich.

45.

System musi umożliwiać wystawianie różnego rodzaju zaświadczeń np. potwierdzenia przyjęcia do szpitala /


pobytu w szpital, ZUS ZLA. Wymagana możliwość korzystania z gotowych szablonów zaświadczeń

46.

System musi umożliwiać tworzenie przez administratora własnych szablonów zaświadczeń z możliwością pobierania do nich informacji z systemu za pomocą zdefiniowanych w systemie zmiennych, możliwość samodzielnego definiowania takich zmiennych.

47.

System musi umożliwiać wypisywanie recept z wykorzystaniem aktualnej listy leków refundowanych (informacja o poziomach odpłatności wraz z zakresem wskazań refundacyjnych).

48.

System musi umożliwiać administratorowi lub wyznaczonej osobie bezpośrednie zaczytywanie listy leków refundowanych na podstawie pliku .xls publikowanego przez Ministerstwo Zdrowia.

49.

System musi automatycznie nadawać numery recept z puli zaczytanej do systemu dla danego lekarza.

50.

System musi umożliwiać konfigurację informacji wyświetlanej dla lekarza ostrzegającej o przekroczeniu

51.

minimalnej liczby dostępnych numerów recept.

52.

System musi umożliwiać kopiowanie zestawu zapisanych leków z recept wystawionych w przeszłości.

53.

System musi umożliwiać wystawienie recepty dla seniora 75+ dla jednostek POZ.

54.

System musi umożliwiać wystawienie recepty typ: Rp, Rpw, Rpz, recepturowej, transgranicznej

55.

System musi umożliwiać definiowanie przez lekarza szablonów zestawów leków do zapisania na recepcie

56.

System musi umożliwiać generowanie następujących wydruków:

- wywiadu,

- badań przedmiotowych,

- planu opieki

- obserwacji lekarskich,

- epikryz,

- kart informacyjnych,

- skierowań na konsultacje,

- zaświadczeń,

- recept oraz informacji o wystawionej recepcie elektronicznej

- skierowań do jednostek zewnętrznych (poradnia specjalistyczna, szpital, pracownia, szpital psychiatryczny, zabiegi fizjoterapeutyczne),

- historii choroby pacjenta leczonego operacyjnie w trybie jednodniowy,

- karty kwalifikacyjnej do zabiegu operacyjnego w trybie jednodniowym,

- zgody pacjenta na operację w trybie jednodniowym,

- karty żywienia pozajelitowego,

- kart monitorowania i leczenia bólu

- karty oceny geriatrycznej pacjenta

- karty zastosowania przymusu bezpośredniego

- oceny ryzyka związanego ze stanem odżywienia (nutritionalriskscore - NRS),

- subiektywnej globalnej oceny stanu odżywienia, (SGA)

- zlecenia zapotrzebowania na sprzęt ortopedyczny,

- zlecenia zapotrzebowania na sprzęt ortopedyczny comiesięczny,

- skierowania na leczenie uzdrowiskowe,

- wniosku o refundację sprowadzanego z zagranicy środka spożywczego specjalnego przeznaczenia


żywieniowego niezbędnego dla ratowania życia lub zdrowia,

- zapotrzebowania na sprowadzany z zagranicy produkt leczniczy niezbędny dla ratowania życia lub zdrowia,

- zapotrzebowania na sprowadzany z zagranicy środek spożywczy specjalnego przeznaczenia

żywieniowego, niezbędny dla ratowania życia lub zdrowia.

57.

System musi umożliwiać współpracę z czytnikami kodów kreskowych w zakresie identyfikacji pacjenta, pracownika oraz leków.

58.

System musi umożliwiać rejestrację głosu z wykorzystaniem dyktafonów.

59.

System musi umożliwiać dodawanie dowolnych plików powiązanych z danym pacjentem oraz wizytą lub hospitalizacją.

60.

System musi umożliwiać dołączanie do EDM i archiwizowanie zeskanowanych dokumentów z formy papierowej.

61.

System musi posiadać mechanizm konfiguratora formularzy, umożliwiający administratorowi tworzenie formularzy z możliwością zdefiniowania w nich minimum:

- pól opisowych,

- pól opisowych z konfigurowalną przez użytkownika listą podpowiedzi,

- pól wyboru (checkbox),

- pól radiowych,

- pól pobierających dane z systemu,

- przycisków,

62.

System musi umożliwiać skonfigurowanie standardowego wydruku dla konfigurowalnego formularza z opcją drukowania całego formularza lub tylko wypełnionych/zaznaczonych wartości.

63.

System musi posiadać mechanizm blokowania ewidencji danych w historii choroby pacjenta po określonym czasie.

64.

System musi posiadać mechanizm blokujący możliwość edycji lub usunięcia wpisu dla osoby nie będącej jej autorem, ustawiany indywidualnie dla formularza.

65.

System musi umożliwiać wygenerowanie raportu z liczbą dni od zakończenia poprzedniej hospitalizacji na oddziale z możliwością monitorowania readmisji

66.

System musi umożliwiać wyświetlania alertów na liście pacjentów co najmniej w zakresie:

- czasu przymusu bezpośredniego – z możliwością generowania z systemu formularzy do zgłaszania przymusu, przedłużenia stosowania przymusu bezpośredniego oraz jego monitorowania

- podejrzenia zakażenia szpitalnego – alert wygenerowany po wpisaniu w dokumentację wartości przekraczające dopuszczalne normy (np. temperatura powyżej ustalonej, biochemiczne wykładniki stanu zapalnego lub inne zdefiniowane przez użytkownika) z jednoczesnym wpisem w module zakażeń szpitalnych i – jeśli wymagane – następowym automatycznym raportowaniem w wymaganych systemach sprawozdawczych (NFZ)

- pacjentów w oddziale powyżej 60 rż u których dokonano całościowej oceny geriatrycznej – wg obowiązujących skal, które będą wymagane, z możliwością generowania raportów oraz automatycznym przeniesieniem do modułu rozliczeniowego z NFZ

- konieczności zlecenia profilaktyki CHZZ konieczność zlecenia profilaktyki okołooperacyjnej

67.

System musi umożliwiać rejestrowanie zdarzeń niepożądanych – zgodnie z określonym katalogiem

68.

System musi umożliwiać zlecanie czynności wykonywanych przez pielęgniarki, takich jak np:

- zmiana opatrunku

- usunięcie wkłucia centralnego

- profil glikemii z określeniem częstotliwości

- bilans płynów z określeniem częstotliwości (np. 24-, 12- , 6- godzinny lub godzinowy)

- monitorowanie ciśnienia, tętna, saturacji z określeniem częstotliwości (od 24-godzin do stałego)

69.

System musi umożliwiać prowadzenie siatki centylowej

70.

System musi posiadać formularze i raporty dla skal udarowych min. NIHSS

71.

System musi posiadać formularze i raporty dla skal oceny ryzyka Żylnej Choroby Zakrzepowo Zatorowej (ŻChZZ) min. Xxxxxxxxxx, Xxxxxxxx.

72.

System musi posiadać formularze i raporty dla skal pomocnych przy leczeniu zatruć min. PSS, XXXX-X, XXXX- X, XXXX- XX


7.1.1.11 Ordynacja Lekarska


Lp.

Opis wymagania / punktacja

1.

System musi umożliwiać zlecenie leków pacjentowi z rozróżnieniem zlecenia określonego lokalnie i zewnętrznego.


2.

System musi umożliwiać filtrowanie zleceń wg daty wystawienia zlecenia, rodzaju zlecenia.

3.

System musi umożliwiać sortowanie zleceń wg opisu zlecenia oraz daty planowanej realizacji.

4.

System musi umożliwiać prezentację odpowiednich statusów realizacji zlecenia za pomocą różnych znaków graficznych lub opisów tekstowych.

5.

System musi umożliwiać wybór leków z receptariusza oddziałowego poprzez podanie nazwy międzynarodowej lub handlowej.

6.

System musi umożliwiać zlecanie leków recepturowych zdefiniowanych w module Apteka.

7.

System musi umożliwiać zlecanie leków spoza receptariusza.

8.

System musi umożliwiać zlecanie leków poprzez podanie nazwy międzynarodowej (po stronie ordynacji leków).

9.

System musi umożliwiać uszczegółowienie zlecenia na konkretne podanie leku o nazwę handlową. Opcja włączana i wyłączana przez administratora systemu.

10.

System musi umożliwiać zlecanie w trybie zwykłym, doraźnym oraz do decyzji lekarza dyżurnego.

11.

System musi umożliwiać określenie godziny i czasu realizacji zlecenia.

12.

System musi umożliwiać lekarzowi podgląd wykazu alergenów, na które uczulony jest pacjent.

13.

System musi umożliwiać ewidencjonowanie dodatkowych środków i rozpuszczalników w ramach jednego zlecenia lekowego.

14.

System musi umożliwiać lekarzowi podgląd szczegółów dotyczących realizacji zlecenia.

15.

System musi umożliwiać konfigurację przedziału czasu, na jaki można ewidencjonować zlecenia.

16.

System musi umożliwiać szybkie zaewidencjonowanie odstawienia leku.

17.

System musi umożliwiać zbiorcze przyjmowanie zleceń przez pielęgniarkę.

18.

System musi umożliwiać pielęgniarkom wyświetlenie zleceń lekowych z określonego zakresu czasu (dyżuru), dla konkretnego pacjenta i dla konkretnej sali, na której leżą pacjenci.

19.

System musi umożliwiać sortowanie zleceń o określonym statusie realizacji.

20.

System musi umożliwiać ewidencjonowanie uwag dotyczących realizacji zlecenia.

21.

System musi umożliwiać zamknięcie zlecenia lekowego bez jego realizacji. W tej sytuacji powód niemożliwości realizacji zlecenia musi być bezwzględnie określony.

22.

System musi umożliwiać automatyczne przyjmowanie, rozpisanie i realizację leków na podstawie aktualnego stanu magazynowego apteczki oddziałowej.

23.

System musi umożliwiać wydruk zleceń na środki farmaceutyczne zarówno wg pacjentów, jak i wg zleconych leków.

24.

System musi umożliwiać rozdział zleceń dla pielęgniarki lekowej (tabletki, kapsułki, etc.) i zabiegowej (iniekcje).

25.

System musi realizować proces rejestracji podania leków ‘przy łóżku pacjenta’, wraz z rejestracją ew. przebiegu podania (nie przyjęcia).

26.

System musi umożliwiać współpracę z czytnikami kodów kreskowych i kolektorami danych przy ewidencji podania leków pacjentowi.

27.

System musi umożliwiać prowadzenie księgi realizacji zleceń lekarskich.

28.

System musi umożliwiać synchronizację pomiędzy kartą zleceń lekarskich, a księgą zabiegów pielęgniarskich.

29.

System musi posiadać mechanizm definiowania dodatkowych filtrów ograniczających listę zleceń. Użytkownik może zaznaczyć więcej niż jeden filtr w danym momencie.


7.1.1.12 Opieka pielęgniarska


Lp.

Opis wymagania

1.

System musi umożliwiać ewidencję diagnoz pielęgniarskich/problemów pielęgnacyjnych, co najmniej, w zakresie:

- dokumentowania procesu pielęgnowania oraz procedur pielęgniarskich (Karta indywidualnej opieki pielęgniarskiej) w oparciu o schematy definiowane dla danej jednostki za pomocą mechanizmu oznaczania wykonania danej czynności przy pomocy checkboxa.

- wprowadzania diagnoz/problemów pielęgnacyjnych

- wprowadzania procedur wynikających z diagnozy//problemów pielęgnacyjnych

- ustalenia listy diagnoz//problemów pielęgnacyjnych preferowanych dla jednostki

- przegląd diagnoz//problemów pielęgnacyjnych z poprzednich pobytów pacjenta

- realizacji procedur wynikających z diagnoz/problemów pielęgnacyjnych


- dodania lub usuwania wielu procedur jednocześnie

- odnotowania realizacji wielu procedur jednocześnie

- edycji opisu wykonanej procedury

- wydruku indywidualnej karty procesu pielęgnacji

- zbiorczej realizacji procedur wynikających z jednej lub wielu diagnoz//problemów pielęgnacyjnych

2.

System musi umożliwiać powielenie obserwacji

3.

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

4.

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

5.

System musi umożliwiać rejestrację informacji o stanie zdrowia pacjenta

6.

System musi umożliwiać wprowadzanie obserwacji pielęgniarskich (karty realizacji opieki) z możliwością pobierania szablonów z katalogu oraz możliwością samodzielnego definiowania szablonów przez użytkownika.

7.

System musi umożliwiać dokumentowanie procesu pielęgnowania w oparciu o Diagnozę/Problem pielęgniarski, Plan realizacji opieki/Realizację opieki, Ocenę realizacji opieki z możliwością definiowania własnych szablonów diagnoz, z dedykowanymi dla nich czynnościami oraz ocenami wybieranymi z list wielowartościowych.

8.

System musi umożliwiać ewidencjonowanie informacji o odleżynach oraz podjętych czynnościach pielęgnacyjnych dotyczących odleżyn. Definiowanie szablonów przez użytkownika.

9.

System musi umożliwiać prowadzenia bilansu płynów ze zgromadzonych informacji o płynach podanych i płynach wydalonych.

10.

System musi umożliwiać automatyczne obliczanie bilansu płynów zmianowego i dobowego na podstawie wprowadzonych wartości liczbowych.

11.

System musi umożliwiać definiowanie przez administratora w formularzu bilansu płynów dowolnych dodatkowych źródeł płynów wydalonych, z możliwością ewidencji dla nich wartości w ml, które są uwzględniane w bilansie zmianowym i dobowym.

12.

System musi umożliwiać wprowadzanie zaleceń pielęgniarskich w rozbiciu na 3 pola z możliwością zdefiniowania ich nagłówków przez administratora.

13.

System musi umożliwiać definiowanie szablonów zaleceń dla wszystkich pól jednocześnie lub indywidualnie dla każdego pola.

14.

System musi umożliwiać pobrania zatwierdzonych zaleceń do karty informacyjnej.

15.

Ewidencja opieki nad pacjentem w skali TISS:

- wykaz procedur z dnia wraz z punktacją,

- automatyczne sumowanie procedur,

- określenie pracownika wykonującego.

16.

System musi umożliwiać kopiowanie wykonanych procedur w ramach opieki w skali TISS w ramach poszczególnych dni pobytu.

17.

System musi umożliwiać automatyczne generowanie produktów zgodnie z NFZ na podstawie wprowadzonych danych z zakresu TISS.

18.

System musi umożliwiać generowanie następujących wydruków:

- opieka nad pacjentem w skali TISS – na dany dzień,

- zestawienie zbiorcze ilości punktów w ramach pobytu.


- Implementacja kalkulatora przeliczającego na podstawie masy, wzrostu, wyników

- laboratoryjnych - parametry pacjenta:

- powierzchnia,

- BMR (kcal, kJ), BMI,

- Osmol. Surowicy,

- BUN i UUN.

19.

System musi umożliwiać ewidencjonowanie i wydruk karty obserwacji wkłuć: obwodowych, centralnych dializacyjnych, dotętniczych.

20.

System musi umożliwiać ewidencjonowanie w karcie wkłuć minimum danych:

- daty i godziny założenia wkłucia,

- osoby zakładającej,

- rodzaju zestawu,

- miejsca wkłucia,

- obserwacji wkłucia na podstawie 6 stopniowej skali z datą godziną i osobą wykonującą obserwację,

- usunięcia wkłucia,

- uwag.

21.

System musi umożliwiać oznaczanie kolorem wkłuć w zależności od czasu, który upłynął od momentu jego założenia np. czerwonym wkłucie obwodowe powyżej 72h od założenia

22.

System musi umożliwiać dodawanie dowolnych plików powiązanych z danym pacjentem oraz pobytem/wizytą.

23.

System musi umożliwiać dołączanie zeskanowanych dokumentów z formy papierowej.

24.

System musi umożliwiać uzupełnienie wywiadu pielęgniarskiego o ocenę: sprawności pacjenta, stanu emocjonalnego pacjenta, stanu psychicznego pacjenta.

25.

System musi umożliwiać wydruk karty gorączkowej.

26.

System musi umożliwiać ewidencję pomiarów dokonywanych pacjentowi wg ustalonej przez użytkownika kolejności.

27.

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

28.

System musi umożliwiać wydruk siatek centylowych dla pomiaru wzrostu, wagi, obwodu głowy i BMI dla pacjentów w różnych grupach wiekowych.

29.

System musi umożliwiać wprowadzanie opisów czynności pielęgnacyjnych/ zaleceń pielęgniarskich.

30.

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

31.

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

32.

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

33.

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

34.

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

35.

System musi umożliwiać przypisanie każdemu pacjentowi kategorii pielęgnacyjnej na dobę.

36.

System musi posiadać mechanizm automatycznego kopiowania kategorii pielęgniarskiej z poprzedniej doby/zmiany dla pacjenta z możliwością jej zmiany w dniu bieżącym.

37.

System musi umożliwiać kategoryzację wszystkich pacjentów oddziału na jednym formularzu.

38.

System musi umożliwiać kategoryzację pacjentów na podstawie wyboru z listy wartości w formularzach min. Karty Indywidualnej Opieki, Zaleceń pielęgniarskich, Bilansu płynów, Karty realizacji opieki.

39.

System musi umożliwiać wykorzystanie definiowanych formularzy do opisu przebiegu pielęgniarskiego

40.

System musi umożliwiać tworzenie zapotrzebowania żywnościowego dla pacjentów oddziału z możliwością przeliczenia ilości zamawianych posiłków wg przypisanych pacjentom diet

41.

System musi umożliwiać uzupełnienie zapotrzebowania żywnościowego o zamówienia dodatkowych posiłków i materiałów

42.

System musi umożliwiać odnotowanie podania leku należącego do pacjenta

43.

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

44.

Podczas tworzenia dokumentu oceny stanu odżywiania, system musi uzupełnić dokument danymi ostatnich pomiarów

45.

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

46.

System musi umożliwiać listy pacjentów na oddziale do pacjentów posiadających zlecenia z uwagami do podania

47.

System musi umożliwiać podgląd aktualnych zleceń dla oddziału w jednym oknie z możliwością zawężenia listy przynajmniej według statusu zadania, sali, wybranego pacjenta, oraz drogi podania.

48.

System musi umożliwiać oznaczanie na w oknie realizacji kolorami statusu dawki leku co najmniej potwierdzone, zrealizowane, wstrzymane z podaniem przyczyny oraz zaplanowane - do potwierdzenia.

49.

System musi umożliwiać oznaczanie w oknie realizacji wykrzyknikiem leków zleconych w do podania w trybie pilnym.

50.

System musi umożliwiać zgłoszenie nierozliczonych podań leków.

51.

System musi umożliwiać oznaczenie podania leku jako zrealizowane. System automatycznie podpowiada datę i godzinę podania z możliwością jej zmiany. Użytkownik ma możliwość wpisania uwag do realizacji zlecenia z możliwością tworzenia szablonów, odnotowania niepodania oraz ilości podanej i pobranej leku. System automatycznie podpowiada jako zużytą partię, partię z najkrótszą datą ważności w Apteczce oddziałowejz możliwością jej zmiany. Użytkownik ma możliwość wyboru zużytej partii łącznie z zamiennikami. Odnotowana ilość leku pobranego automatycznie jest zdejmowana ze stanu Apteczki oddziałowej.

52.

System musi umożliwiać wycofanie zużycia oraz wycofania realizacji zlecenia. Odnotowana a wycofana ilość leku pobranego automatycznie jest przywracana na stan Apteczki oddziałowej.

53.

System musi umożliwiać wydruk listy zaplanowanych leków do podania.

54.

System musi umożliwiać podejrzenie historii zmian w dokumencie z wyszczególnieniem danych dodanych, zmodyfikowanych oraz usuniętych.

55.

System musi umożliwiać podejrzenie dokumentacji pacjenta w trakcie uzupełniania dokumentacji bez wychodzenia z kontekstu dokumentu.

56.

System musi umożliwiać przeglądanie najważniejszych informacji o pacjencie z ostatniego dyżuru w jednym miejscu co najmniej w zakresie:

- Obserwacje lekarskie

- Obserwacje pielęgniarskie

- Parametry życiowe w formie wykresu z możliwością wyboru parametrów jakie na wykresie mają się znaleźć

- Zlecenia leków (po nazwach międzynarodowych)

- Doba pobytu

57.

System musi umożliwiać podejrzenie historii zmian w dokumencie z wyszczególnieniem danych dodanych, zmodyfikowanych oraz usuniętych.

58.

System musi umożliwiać podejrzenie dokumentacji pacjenta w trakcie uzupełniania dokumentacji bez wychodzenia z kontekstu dokumentu.

59.

System musi umożliwiać wpisanie do raportu danych dotyczących konkretnego pacjenta przebywającego na oddziale w czasie za który sporządzany jest raport.

60.

System musi umożliwiać wydrukowanie raportu pielęgniarskiego za daną zmianę pielęgniarską.

61.

System musi umożliwiać ewidencję Karty Bilansu Płynów w ujęciu godzinowym.

62.

System musi umożliwiać ewidencję Karty Wykonanych Czynności Pielęgniarskich w ujęciu godzinowym.

63.

System musi umożliwiać prowadzenie kart obserwacji w oparciu o wykonaną procedurę np. Karta Obserwacji Cewnika Moczowego.

64.

System musi umożliwiać prowadzenie karty pomiarowej w ujęciu godzinowym.

65.

System musi umożliwiać wprowadzenie do systemu kart obserwacji i monitorowania stanu pacjenta oraz wykonanych czynności pielęgnacyjnych obowiązujących w Szpitalu, wymaganych przepisami prawa i standardami akredytacyjnymi CMJ i generowania raportów.


7.1.1.13 Blok operacyjny


Lp.

Opis wymagania

1

System musi umożliwiać przypisanie zespołów chirurgicznych i anestezjologicznych do wykonania danych operacji z możliwością podglądu na oddziałach.

2

System musi umożliwiać zlecanie pacjentowi zabiegów operacyjnych na konkretny termin. Zlecenie przejmuje elektronicznie moduł Blok Operacyjny.

3

System musi umożliwiać dodanie nowego podzabiegu (zabiegu wykonywanego jednocześnie z innym zabiegiem).

4

System musi umożliwiać przeglądanie kolejki pacjentów oczekujących na operacje.

5

System musi umożliwiać planowanie zabiegów, w szczególności:

• daty i godziny,

• miejsca (sala operacyjna),

• tytułu zabiegu,

• planowanego zużycia materiałów wszczepialnych,

• rodzaju znieczulenia,


• inne uwagi.

6

System musi umożliwiać potwierdzanie przyjęcia pacjenta na wykonanie zabiegu.

7

System musi umożliwiać ewidencję danych dotyczących pacjenta:

• rozpoznanie,

• grupakrwi,

• masaciała,

• wzrost,

• powierzchniaciała.

8

System musi umożliwiać uzupełnienie opisu przedoperacyjnego.

9

System musi umożliwiać podgląd wszystkich zabiegów chirurgicznych dla danego pacjenta.

10

System musi umożliwiać podgląd zrealizowanych procedur podczas poprzednich zabiegów.

11

System musi umożliwiać planowanie zabiegu do wykonania w późniejszym terminie.

12

System musi umożliwiać obsługę znaczników czasowych, w szczególności:

• - wjazd na salę operacyjną,

• rozpoczęcie znieczulenia,

• rozpoczęcie operacji,

• zakończenie operacji,

• zakończenie znieczulenia / wybudzenie,

• wyjazd z sali operacyjnej.

13

System musi umożliwiać prowadzenie ewidencji x.xx.:

• Księgi Bloku Operacyjnego,

• Księgi Znieczuleń,

• wykonanych procedur medycznych,

• dokumentacji operacyjnej, w tym karty zabiegowej pacjenta (podać przykład),

• protokołów pielęgniarskich

• zużytych leków i materiałów wraz z kosztami.

14

System musi umożliwiać generowanie raportów zdefiniowanych przez użytkownika, takich jak x.xx.:

• koszt zabiegu na pacjenta

• wykorzystanie sal (czas),

• statystyka pracownika,

• czas trwania zabiegu operacyjnego

• czas trwania znieczulenia

• wszystkie przekrojowe analizy na podstawie wprowadzonych danych.

• automatyczne przenoszenie danych dotyczących kosztu zabiegu na pacjenta do modułu KKL oraz automatyczne przenoszenie statystyk (w ujęciu miesięcznym ) wszystkich procedur do modułu koszty w celu wyliczenia kluczy podziałowych

15

System musi umożliwiać obsługę elektronicznych zleceń:

• wysłanie zlecenia wykonania elementu leczenia (badania) do jednostki realizującej (np. pracownia diagnostyczna, zakład patomorfologii),

• możliwość śledzenia stanu wykonania zlecenia,


• zwrotne otrzymanie wyniku realizacji zlecenia (np. wyniku badania).

16

System musi umożliwiać wprowadzanie danych związanych z podaniem profilaktyki okołooperacyjnej min. lek, dawka, data, godzina z minutami.

17

System musi umożliwiać generowanie raportów z zastosowanej profilaktyki okołooperacyjnej – min. lek, dawka, rodzaj zabiegu, data i godzina z minutami podania, lekarz zlecający, pielęgniarka realizująca zlecenie.

18

System musi umożliwiać zdefiniowanie listy typowych opisów przedoperacyjnych powiązanych z planowaną główną procedurą.

19

System musi umożliwiać planowane zabiegów bez powiązania z pobytem pacjenta na oddziale lub w izbie przyjęć.

20

System musi umożliwiać podanie planowanej jednostki realizującej leczenie (oddziału, na który zostanie przyjęty pacjent).

21

System musi umożliwiać wprowadzenie personelu biorącego udział w operacji z podziałem na funkcje:

• anestezjolog,

• instrumentariusz,

• lekarz operujący,

• lekarze asystujący,

• pielęgniarka anestezjologiczna,

• pielęgniarka instrumentacyjna,

• obserwatorzy i goście,

• inne funkcje (konfigurowalne).

22

System musi umożliwiać niezależną ewidencji zespołu planowanego i realizującego (domyślnie zespół planowanystajesięrealizującymwmomencieprzyjęciazabiegunablok,zmożliwościąpóźniejszej zmiany).

23

System musi umożliwiać zdefiniowanie i wykorzystanie podczas planowania domyślnych zespołów operacyjnych (globalnie lub dla każdej Sali operacyjnej).

24

System musi umożliwiać skonfigurowanie, czy podanie operatora na etapie planowania zabiegu jest obowiązkowe.

25

System musi umożliwiać wprowadzanie danych o zabiegu operacyjnym z uwzględnieniem ich minimalnego zestawu:

• Rozpoznanieprzedoperacyjne,

• Rodzajzabiegu,

• zgoda pacjenta nazabieg,

• godzina przybycia, rozpoczęcia zabiegu, zakończenia zabiegu (z rozróżnieniemczasu zabiegu wg chirurga i bloku operacyjnego).

• podgląd bezpośrednio w formularzu informacji o grupie krwi, masie i wzrościepacjenta wprowadzonych do historii choroby.

26

Wprowadzanie danych dotyczących chorób zakaźnych:

• HIV,

• HBS,

• Gruźlica,

• Inne.

27

System musi umożliwiać wprowadzanie opisowych danych o przebiegu operacji.

28

System musi umożliwiać wprowadzenie danych o znieczuleniach wykonanych podczas zabiegu:

• ryzyko,

• anestezjolog,

• podaneleki.

29

System musi umożliwiać ewidencjonowanie wielu znieczuleń podczas zabiegu, każde z poniższym zestawem danych:

• godzina rozpoczęcia izakończenia,

• rodzajznieczulenia,

• uwagi (opisznieczulenia).

30

System musi umożliwiać zdefiniowanie typowych opisów dla poszczególnych rodzajów znieczuleń.

31

System musi umożliwiać wprowadzenie danych o materiałach medycznych i narzędziach zastosowanych podczas zabiegu.

32

System musi umożliwiać prowadzenie analizy znieczuleń i zdarzeń niepożądanych ze znieczuleniem wg ustalonego katalogu z jednoczesną rejestracją zdarzeń niepożądanych w module zdarzeń niepożądanych

33

System musi umożliwiać bieżącą i automatyczną aktualizację stanów magazynowych apteczek bloku operacyjnego, sterylizatorni i apteczek anestezjologicznych na podstawie, np. zewidencjonowanego zużycia, a także zużycia sprzętu wszczepialnego będącego na stanie apteki, sterylizacji lub w komisie po wprowadzeniu zmian przez operatora.

34

System musi umożliwiać odnotowywanie zużycia sprzętu jednorazowego oraz narzędzi.

35

System musi umożliwiać obsługę bloku operacyjnego szpitala oraz wszelkich innych sal i gabinetów zabiegowych lecznictwa zamkniętego i otwartego Szpitala.

36

System musi umożliwiać prowadzenie Księgi Zabiegów obejmującej także wszelkie procedury zabiegowe w trybie ambulatoryjnym.

37

System musi umożliwiać generowanie formularza zgody pacjenta na zabieg.

38

Księga Bloku Operacyjnego musi umożliwiać generowanie schematów opisów zabiegu do wyboru.

39

System musi umożliwiać podział kosztów Bloku na poszczególne Oddziały zlecające, w szczególności koszty materiałów medycznych i leków, które zamawia Blok Operacyjny muszą obciążać Oddziały macierzyste pacjenta, który trafia na operację.

40

System musi umożliwiać obsługę pracowni wszystkich specjalności realizowanych przez Zamawiającego.

41

System musi umożliwiać ewidencję i wydruk okołooperacyjnej karty kontrolnej, zgodnej z założeniami wypracowanymi przez Grupę Inicjatywną Okołooperacyjnej Karty Kontrolnej przy wsparciu Ministerstwa Zdrowia.

42

System musi umożliwiać automatyczne tworzenie grafiku zabiegów operacyjnych na podstawie wpisanych danych. Wydruk grafiku zabiegów w różnych formach: lista, szczegółowy opis zabiegu. Możliwość drukowania gotowych planów z różnym zakresem danych w różnych komórkach organizacyjnych.

43

System musi umożliwiać definiowanie Sali operacyjnych (z pełnym planowaniem dnia operacyjnego) i zabiegowych (bez planowania, pozwalających na ewidencję prostych zabiegów).

44

System musi umożliwiać automatyczne rozliczanie personelu uczestniczącego w zabiegu w systemie punktowym.

45

System musi umożliwiać współpracę z czytnikami kodów kreskowych i kolektorami danych w zakresie co najmniej identyfikacji pacjenta po kodzie zamieszczonym na dokumentacji medycznej oraz pracownika po identyfikatorze osobowym.

46

System musi umożliwiać współpracę z czytnikami kodów kreskowych i kolektorami danych w zakresie wprowadzenia danych do systemu HIS – dokumentacji pacjenta i ewidencji o zastopowanych lekach, pakietach, zużytym sprzęcie jednorazowym i materiałach z jednoczesnym połączeniem z modułem apteczki oddziałowej.

47

System musi umożliwiać uzupełnianie opisu zabiegu z poziomu dokumentacji medycznej (oddziału) oraz możliwość zablokowania jej edycji.

78

System musi umożliwiać automatyczną ewidencję zdarzeń (np. przybycia pacjenta na blok operacyjny i jego identyfikacji) na podstawie kodu kreskowego.

49

System musi umożliwiać blokowanie edycji fragmentów opisu zabiegu dokonywanych przez poszczególnych pracowników (np. chirurg, anestezjolog).

50

System musi umożliwiać zdefiniowanie maksymalnego czasu, w którym dozwolony jest opis zabiegu po jego zakończeniu.

51

System musi umożliwiać zdefiniowanie dopuszczalnych różnic czasu wystąpienia zdarzeń związanych z zabiegiem. W przypadku przekroczenia tej różnicy użytkownik powinien być uprzedzany o wystąpieniu takiej sytuacji.

52

System musi umożliwiać definiowaniagruprealizowanychprocedur(np.główne, dodatkowe, anestezjologiczne) i listy procedur w każdej grupie niezależnie dla każdej Sali operacyjnej.

53

System musi umożliwiać wybór spośród personelu związanego za zabiegiem pracowników przypisanych do zrealizowanej procedury jako zlecający i wykonujący.

54

System musi umożliwiać ewidencję procedur wykonanych w ramach zabiegu w kosztach funkcjonowania innych komórek organizacyjnych.

55

System musi umożliwiać zdefiniowanie maksymalnej liczby głównych procedur oraz zablokowania ich edycji.

56

System musi umożliwiać niezależne numerowanie zabiegów:

• w księdze bloku (lub Salioperacyjnej),

• w księdzeoddziału,

• numer kolejny na bloku (lub Salioperacyjnej),

• numer kolejny w oddziale.

57

System musi umożliwiać prowadzenie numeracji w księgach:

• automatycznej (w momencie zaplanowanie lub przyjęciazabiegu),

• automatycznej opóźnionej (zabiegi są wpisywane do księgi po zakończeniu dnia operacyjnego),

• ręcznej.

58

System musi umożliwiać prowadzenie wielu ksiąg zabiegów operacyjnych dla komórki organizacyjnej.

59

System musi umożliwiać wspomaganie planowania dnia operacyjnego:

• formularz umożliwiający podgląd zaplanowanychzabiegów,

• możliwość edycji w tymformularzu:

- kolejnościzabiegów,

- sali, na której będzie wykonywanyzabieg,

- księgi, jeżeli do wybranej Sali jest przypisanych wieleksiąg,

• wykrywaniekonfliktówpodczasplanowaniazabiegów(jednocześniekilkazabiegównatej samej sali lub personel przypisany jednocześnie do kilku zabiegów),

• możliwość przyjmowania zabiegów nieplanowanych(ostrych).

60

System musi umożliwiać ewidencjonowanie zabiegówpołączonych, tzn. osobnych zabiegów chirurgicznych wykonywanychw ramachjednegoznieczuleniainatejsamejsali(aledotyczącychinnychprocedur i potencjalnie wykonywanych przez innezespoły).

61

System musi umożliwiać określenie (globalnie lub dla każdej sali operacyjnej) zakresu danych, których ewidencja jest obowiązkowa przed oznaczeniem zabiegu jako wykonany.

62

System musi umożliwiać automatyczne przenoszenie rozpoznań pooperacyjnych do historii choroby pacjenta wg konfigurowalnych zasad.

63

System musi umożliwiać definiowanie różnych raportów prezentujących opis zabiegu dla różnych sal operacyjnych.

64

System musi umożliwiać wygenerowanie raportów dotyczących powtórnych operacji (reoperacji) wykonanych u tego samego pacjenta dla tego samego pobytu/rozpoznania w ustawionym przez lekarza okresie czasu: dane chorego, data zabiegu, rodzaj zabiegu, opis zabiegu z protokołu, imię i nazwisko operatora, data reoperacji, rodzaj zabiegu, opis zabiegu z protokołu, imię i nazwisko operatora, rodzaj powikłania/zagrożenia, przyczyna wystąpienia, podjęte działania – opis, ocena podjętych działań, miejsce na wprowadzenie wniosków dla konkretnego przypadku.

65

System musi umożliwiać prowadzenie książki transfuzyjnej zgodnie z rozporządzeniem o leczeniu krwią).

66

System musi umożliwiać zamawianie składników krwi (zgodnie z rozporządzeniem o leczeniu krwią).

67

System musi umożliwiać obsługę zgłaszania zdarzeń niepożądanych (zgodnie z rozporządzeniem o leczeniu krwią).

68

System musi umożliwiać rejestrację zdarzeń niepożądanych związanych z procedurami zabiegowymi w module zdarzeń niepożądanych

69

System musi umożliwiać generowanie karty operacyjnej.

70

System musi umożliwiać zamawianie składników krwi bez próby krzyżowej – masywne krwotoki.

71

System musi posiadać pełną integrację z apteczką oddziałową.

7.1.1.14 Blok Porodowy


Lp.

Opis wymagania

1)

System musi umożliwiać rejestrację porodu, poród:

• na bloku porodowym,

• na bloku operacyjnym,

• w izbieprzyjęć,

• w domu (z pomocą lub bezpomocy),

• w innymmiejscu.

2)

System musi umożliwiać obsługę położniczej izby przyjęć, pozwalającej na wypełnienie karty wywiadu położniczego zawierającej odpowiednie dane:

• grupa krwimatki,

• przeszłość położnicza (informacje o wcześniejszych porodach iporonieniach),

• wywiad ogólny (przebyte choroby i operacje, uczulenia, czynniki ryzyka w ciąży, itd.),

• wywiad położniczy (przebieg ciąży z podziałem na konfigurowalne pozycje np.:przybranie masy ciała, data ostatniej miesiączki, tydzień ciąży, pierwsze ruchy płodu, uwagi),

• badanie ogólne (z podziałem na konfigurowalne pozycje np.: układ oddechowy, układ krążenia, narządy jamy brzusznej, układ moczowo-płciowy, budowa ciała i kości, skóra, obrzęki, żylaki, tętno, ciśnienie krwi, gruczołypiersiowe),

• wstępnebadanieginekologiczne(zpodziałemnakonfigurowalnepozycjenp.:krocze,ujście zewnętrzne, ujście wewnętrzne, część pochwowa, pęcherz płodowy, wodypłodowe),

• pomiarmiednicy,

• możliwość zdefiniowania dodatkowych pozycjiwywiadu.

3)

System musi umożliwiać wydruk wypełnionej karty wywiadu położniczego w izbie przyjęć.

4)

System musi umożliwiać ewidencjonowanie godzin pobytu na bloku porodowym, godzin działania znieczulenia.

5)

System musi umożliwiać ewidencjonowanie zespołu porodowego (lekarz, położna, anestezjolog, inne wg konfiguracji).

6)

System musi umożliwiać ewidencjonowanie rozpoznania wstępnego oraz rozpoznania po porodzie.

7)

System musi umożliwiać ewidencjonowanie typu porodu (bez powikłań, z powikłaniami) i rodzaju porodu (prawidłowy, szybki, przedłużony) oraz czasu rozpoczęcia i długość faz porodu

8)

System musi umożliwiać ewidencjonowanie procedur ICD-9 (główna, dodatkowa).

9)

System musi umożliwiać ewidencjonowanie rodzaju znieczulenia zastosowanego podczas porodu.

10)

System musi umożliwiać ewidencjonowanie leków i środków medycznych użytych podczas porodu.

11)

System musi umożliwiać zlecenie cięcia cesarskiego na bloku operacyjnym i dostęp do danych tego zabiegu.

12)

System musi umożliwiać prowadzenie ewidencji porodu – ryzyka porodu:

• PrzedwcześnieP.P.P,

• poród przedwczesny,

• ciąża po terminie - powyżej 42T.C.,

• wewnątrzmaciczne obumarciepłodu,

• ciążamnoga,


• niewydolność łożyska –podejrzenie,

• rzucawka, stanprzedrzucawkowy,

• cukrzyca,

• łożyskoprzodujące,

• przedwczesne oddzieleniełożyska,

• inne krwawieniemaciczne,

• zespół zakażenia błon jaja płodowego -podejrzenie,

• podwyższona ciepłota ciała w czasieporodu,

• RH – niezgodność,konflikt,

• Hypotrofiapłodu,

• nowotwory narządurodnego

• możliwość skonfigurowaniainnych.

13)

System musi umożliwiać prowadzenie ewidencji porodu - wskazania do rozwiązania operacyjnego:

• wady rozwojowe narządurodnego,

• stan poe-konizacji,

• dystocjaszyjkowa

• poprzeczne/skośne położeniepłodu,

• położeniemiednicowe,

• ułożenie potylicowetylne,

• ułożenietwarzyczkowe,

• ułożeniewierzchołkowe,

• przedłużony poród – zatrzymany w Iokresie,

• zatrzymany – przedłużony poród w IIokresie,

• wypadnięcie lub przodowaniepępowiny,

• zagrażające lub dokonane pęknięciemacicy,

• możliwość skonfigurowaniainnych.

14)

System musi umożliwiać prowadzenie ewidencji porodu – poród:

• stymulacja farmakologicznapłodu,

• KTG,

• Wodypłodowe,

• amnioinfuzja,

• pH,

• popłód.

15)

System musi umożliwiać prowadzenie ewidencji porodu – rodząca:

• ilość utraconej krwi wml,

• stopień pęknięciakrocza,

• Błony płodowe pęknięte > 24h.

16)

System musi umożliwiać prowadzenie ewidencji porodu – łożysko: masa[g], nieprawidłowości.

17)

System musi umożliwiać wprowadzenie tekstowych opisów: wstępny, porodu, po porodzie.

18)

System musi umożliwiać automatyczną ewidencję w systemie danych noworodka wprowadzonego w module Blok Porodowy:

• utworzenie karty pacjenta wypełnionej dostępnymidanymi,

• przyjęcie doszpitala,

• w przypadku zgonu noworodka lub urodzenia martwego automatyczne wypełnienie karty zgonu.

19)

System musi umożliwiać prowadzenie ewidencji danych noworodka:

• płeć: męska, xxxxxx,nieznana,


• masa,

• wzrost,

• punktacja apgar: 1 minuta, 3, 5 i 10 minut poporodzie

20)

System musi umożliwiać rejestrację wieku ciążowego w ocenie: położniczej - pole opisowe, pediatrycznej - pole opisowe.

21)

System musi umożliwiać ewidencjonowanie danych dotyczących ciąży: 1-sza,…n-ta; przebieg ciąży: powikłany,prawidłowy.

22)

System musi umożliwiać ewidencjonowanie danych dotyczących porodu:

• 1-szy,….,n-ty,

• pojedynczy, mnogi,

• główkowy: siłami natury, z pomocą ręczną, operacyjny (cięcie cesarskie, kleszcze,Vacuum),

• miednicowy: siłami natury, z pomocą ręczną, operacyjny (cięcie cesarskie,kleszcze, Vacuum),

• poprzeczny: siłami natury, z pomocą ręczną, operacyjny (cięcie cesarskie,kleszcze, Vacuum),

• uwagi – poleopisowe.

23)

System musi umożliwiać zlecanie: zabiegów operacyjnych, badań laboratoryjnych i diagnostycznych.

24)

System musi umożliwiać konfigurację zakresu ewidencjonowanych danych.

25)

System musi umożliwiać identyfikowanie noworodka urodzonego w szpitalupoprzez wydruk dwóch opasek dlanoworodka

26)

System musi umożliwiać bezpośrednie zlecanie cięcia cesarskiego i dostępu do danych odpowiedniego zabiegu na bloku operacyjnym.

27)

System musi umożliwiać tworzenie następujących raportów:

• wykaz porodów,

• wykaz noworodków,

• wykaz poronień,

• wykaz przerwań ciąży i zgonów kobiet,

• wykaz cięć cesarskich.

28)

System musi umożliwiać prowadzenie książki transfuzyjnej zgodnie z rozporządzeniem o leczeniu krwią.

29)

System musi umożliwiać zamawianie składników krwi (zgodnie z rozporządzeniem o leczeniu krwią).

30)

System musi umożliwiać generowanie sprawozdania o ilości porodów, urodzeń i zgonów noworodków.

31)

System musi umożliwiać obsługę zgłaszania zdarzeń niepożądanych (zgodnie z rozporządzeniem o leczeniu krwią).


7.1.1.15 Bank krwi -zlecenia


Lp.

Opis wymagania

1.

System musi umożliwiać zlecanie zapotrzebowań do banku krwi na krew i preparaty krwiopochodne, zlecenie przejmuje elektronicznie moduł Bank Krwi.

2.

System musi umożliwiać podgląd wszystkich zaewidencjonowanych dla pacjenta zapotrzebowani na preparaty krwiopochodne.

3.

System musi umożliwiać podgląd szczegółowych informacji zebranych podczas wywiadu.

4.

System musi umożliwiać ewidencję danych dotyczących preparatu krwiopochodnego:

• Nazwapreparatu,

• czynnik RhD,

• usługi wymagane przy podaniupreparatu,

• ilość i jednostkamiary,

• lekarz zlecający podaniepreparatu,

• wskazanie dotransfuzji.

5.

System musi umożliwiać zlecenie w trybie zwykłym oraz w trybie cito.

6.

System musi umożliwiać wydruk zlecenia.

7.

System musi umożliwiać wydruk skierowania na konsultację do RCKiK.

8.

System musi umożliwiać zaewidencjonowanie informacji o typie biorcy.

9.

System musi umożliwiać zaewidencjonowanie informacji o dacie ostatniego przetaczania krwi.

10.

System musi umożliwiać automatyczną numerację zapotrzebowań na preparaty krwiopochodne.

11.

System musi umożliwiać wydruk skierowania na próbę zgodności.

12.

System musi umożliwiać automatyczne wystawienie skierowania do laboratorium.

13.

System musi umożliwiać prowadzenie książki transfuzjologicznej w wersji elektronicznej

14.


System musi umożliwiać automatyczne przekazanie do modułu KKL danych o wartości zużytej krwi na pacjenta


7.1.1.16 Zakażenia szpitalne


Lp.

Opis wymagania / punktacja

1.

System musi umożliwiać zgłoszenie podejrzenia zakażenia zarówno z poziomu oddziału jak i poradni (Funkcjonalność dodatkowa – wg pozacenowego kryterium oceny ofert)

2.

System musi umożliwiać podgląd wykazu zakażeń dostępny x.xx. z poziomu oddziału.

3.

System musi umożliwiać stworzenie karty zakażenia personelu.

4.

System musi umożliwiać wyświetlanie alertu o możliwości zakażenia w przypadku zmian wybranych parametrów np. przy temperaturze ciała powyżej 38 st. C.

5.

System musi umożliwiać kontrolę tworzenia i akceptacji kart zakażeń oraz kart drobnoustrojów alarmowych przez wykwalifikowany zespół kontroli zakażeń.

6.

System musi umożliwiać monitorowanie przebiegu zakażenia przez cały okres jego utrzymywania się.

7.

System musi umożliwiać ewidencjonowanie ognisk epidemicznych.

8.

System musi umożliwiać tworzenie dokumentów ZLK 1-5 z poziomu oddziału, zgodnie z rozporządzeniem Ministra Zdrowia.

9.

System musi umożliwiać podgląd listy wszystkich podejrzeń zakażeń wraz z odniesieniem do dokumentu źródłowego.

10.

System musi umożliwiać tworzenie zestawień sprawozdawczych oraz analitycznych, np.: rejestr zakażeń, statystyka zakażeń, mapa mikrobiologiczna, rejestr dokumentów ZLK, zestawienia rodzajów i miejsc wystąpienia zakażenia z podziałem na jednostkę i czas.

11.

System musi umożliwiać generowanie własnych raportów dotyczących zakażeń z danych wprowadzonych w systemie.

12.

System musi umożliwiać podgląd danych:

• wszystkich pacjentów

• pacjentów na wybranym oddziale

• pacjentów z karta zakażeń

• pacjentów z drobnoustrojem alarmowym

• pacjentów z dokumentami powiązanymi z zakażeniem.

13.

System musi umożliwiać włączenie automatycznej podpowiedzi o możliwym podejrzeniu zakażenia w następujących przypadkach:

• temperatura pacjenta wyższa niż 38 st.C

• ocena stolca: biegunka, płynny i z krwią

• obserwacja wkłucia obwodowego: ropna wydzielina, zaczerwienienie miejsca wkłucia kaniuli

• obserwacja miejsca operowanego: zaczerwienienie, wysięk ropny

• obserwacja wkłucia centralnego: zaczerwienienie, obrzęk, ból

• możliwość automatycznego utworzenia karty podejrzenia zakażenia podczas tworzenia karty drobnoustroju alarmowego.

14.

System musi umożliwiać realizację karty zakażenia:

• rozpoznanie zakażenia

• czynniki wpływające na zakażenie podczas pobytu w szpitalu

• rodzaj zakażenia

• podjęte czynności lecznicze i prewencyjne

• podania leków

• wykonane operacje

• badanie mikrobiologiczne

• kwalifikacja zakażenia.

15.

System musi umożliwiać uzupełnianie karty zakażenia fragmentami, z możliwością powrotu do wybranych zakładek.

16.

System musi umożliwiać stworzenie ogniska epidemicznego

• raport wstępny

• raport końcowy

• przypisane karty zakażenia do ogniska

• automatyczne wyliczanie liczb ognisk na podstawie zakażeń

• wydruk raportu wstępnego i okresowego.

17.

System musi umożliwiać zarządzanie drobnoustrojami alarmowymi poprzez rejestrację i czynniki prewencyjne

18.

System musi umożliwiać dodanie dokumentów związanych z zakażeniem:

• ZLK1 - choroba zakaźna

• ZLK2 - gruźlica

• ZLK3 - płciowe

• ZLK4 - ADIS/HIV


• ZLK5 - zgon

• ocena ryzyka nabycia zakażenia przy przyjęciu do szpitala.

19.

System musi umożliwiać zbiorczą modyfikacji kart zakażeń i kart drobnoustroju alarmowego.

20.

System musi umożliwiać wygenerowania raportów:

• Czynniki ryzyka analiza

• Mapa mikrobiologiczna

• Monitorowanie czynników ryzyka

• Rejestr dokumentów ZLK

• Rejestr kart patogenów alarmowych

• Rejestr kart zakażeń

• Statystyka zakażeń

• Wykaz biologicznych czynników chorobotwórczych

• Zestawienie kwalifikacji zakażeń

• Zestawienie liczby kart zakażeń

• Zestawienie liczby zakażeń(czas/jednostki)

• Zestawienie miejsc wystąpienia zakażeń (czas/jednostki)

• Zestawienie rodzajów zakażeń (jednostki).

21.

System musi umożliwiać wspieranie identyfikacji pacjentów o wysokim poziomie zagrożenia zakażeniem przez definiowanie dowolnych warunków wyboru pacjentów uwzględniających wpisy w historii choroby pacjenta.

22.

System musi umożliwiać prowadzenie rejestru wszystkich zakażeń wewnątrzszpitalnych.

23.

System musi umożliwiać nanoszenie wszystkich niezbędnych danych do wypełnienia Karty Zakażenia Szpitalnego. Dane ewidencjonowane w innych modułach pojawiają się automatycznie.

24.

System musi umożliwiać ewidencjonowanie zgłoszeń zakażeń na oddziale.

25.

System musi umożliwiać zaewidencjonowania dla jednego pacjenta dowolnej liczby kart w ramach jednego pobytu na oddziale.

26.

System musi umożliwiać odbieranie kart zgłoszenia zakażenia szpitalnego przez zespół kontroli zakażeń zakładowych jako indywidualne karty rejestracji.

27.

System musi umożliwiać odnotowanie kwalifikacji zakażeń z podziałem na szpitalne i pozaszpitalne.

28.

System musi umożliwiać prowadzenie analiz liczbowych i procentowych danych z Kart Zakażeń Szpitalnych z podziałem na szpitalne i pozaszpitalne:

• kwalifikacja zakażenia,

• czas do pierwszych objawów zakażenia,

• przebieg kliniczny,

• czas leczenia,

• powód przyjęcia,

• skąd przyjęty,

• czas poprzedniej hospitalizacji,

• płeć,

• wiek,

• rozpoznanie zakażenia,

• rodzaj zakażenia,

• czynniki ryzyka.

29.

System musi umożliwiać nanoszenie niezbędnych danych w odniesieniu do chorych poddawanych zabiegom operacyjnym (dane ewidencjonowane w module blok operacyjny pojawiają się automatycznie):


• długość pobytu przed operacją,

• czas od zranienia,

• rodzaj operacji (nagła, planowa),

• stopień czystości pola operacyjnego,

• czas trwania operacji,

• rodzaj znieczulenia,

• profilaktyka przeciwbakteryjna,

• miejsce operacji,

• techniki operacyjne,

• drenaż z uwzględnieniem jego rodzaju,

• nr katalogowy operacji,

• rodzaj zakażeń dla operowanego,

• antybiotykoterapia,

• badania mikrobiologiczne i antybiogram.

30.

System musi umożliwiać tworzenie szablonów dokumentów wykorzystywanych w komórce zakażeń szpitalnych.

31.

System musi umożliwiać dostęp do rejestru i wyników badań bakteriologicznych.

32.

System musi umożliwiać zatwierdzanie przez lekarza odpowiedzialnego za rejestr zakażeń szpitalnych kart spływających z poszczególnych oddziałów i uwzględniania ich w raportach.

33.

System musi umożliwiać dwuetapowe zatwierdzania karty: wstępnej weryfikacji przez jedną osobą i ostatecznego zatwierdzenia przez inną.

34.

System musi umożliwiać dostępdodanychzcałegosystemu(mechanizmwartościpoczątkowychpólkartyoraz dowiązywania formularzy należących do innych modułów).

35.

System musi umożliwiać ocenę ryzyka powstawania odleżyn.

36.

System musi umożliwiać generowanie dowolnych raportów z zakresu tematyki zakażeń szpitalnych.

37.

System musi umożliwiać dostęp do wyników antybiogramów.

38.

System musi umożliwiać dostęp do wykazu zużycia antybiotyków na poszczególnych oddziałach w przeliczeniu na jednostki mocy (dawki), DDD, opakowania i inne.

39.

System musi umożliwiać wygenerowane raportu z pacjentami z wybranej grupy ryzyka oraz pacjentów spełniających warunki do pobrania badania przesiewowego (przypadki zostaną opisane w przesłanej ocenie ryzyka).

40.

System musi umożliwiać numerację kart zakażeń oraz kart patogenów alarmowych niezależna dla każdego oddziału: numer/kod oddziału/rok.

41.

System musi umożliwiać - określenie podstawy podania antybiotyków: profilaktyka okołooperacyjna, profilaktyka medyczna, leczenie zakażenia, inne + opis. Na podstawie podań leków analiza przyczyn podawania leków. Terapia empiryczna, celowana, itd.

42.

System musi umożliwiać podgląd w moduł zakażenia przy przyjmowaniu pacjenta do szpitala oraz na oddziale pacjenta, u którego wcześniej wystąpiło zakażenie szpitalne lub wykryto patogen alarmowy.

43.

System musi umożliwiać wyświetlanie alertu o możliwości zakażenia w przypadku zmian wybranych parametrów: w przypadku wystąpienia podejrzenia zakażenia (podwyższona temperatura ciała, obserwacje wkłuć, cewników, miejsc operowanych) przy wypełnianiu dokumentów przez lekarza konieczność weryfikacji podejrzenia zakażenia.

44.

System musi umożliwiać automatyczne uzupełnianie o wyniki z pracowni bakteriologii: W czasie tworzenia karty zakażenia szpitalnego lub patogenu alarmowego wykorzystanie wyników badań mikrobiologicznych z systemu


laboratoryjnego.

45.

System musi umożliwiać wygenerowania zlecenia z tego modułu na badania do pracowni mikrobiologicznej - środowiskowe i powietrza tzn. wymazy, posiewy, które pobierane są przez Zespól zakażeń. System powinien również zapewnić podgląd w tym module uzyskanych wyników badań: Zlecenia badań mikrobiologicznych – określenie podstawy wykonywania badania: badanie epidemiologiczne (dot. Środowiska), badanie kliniczne, badanie przesiewowe.


7.1.1.17 Zlecenia i skierowania


Lp.

Opis wymagania

1.

System musi umożliwiać tworzenie elektronicznych zleceń badań (w tym laboratoryjnych) kierowanych do jednostek wykonujących w ramach struktury organizacyjnej Zamawiającego, śledzenie statusu zleceń i dostęp do wyników powstałych wskutek realizacji zleceń, przy czym do czasu uruchomienia funkcjonalności zleceń elektronicznych system zapewni możliwość ewidencji papierowych wersji zleceń i skierowań oraz możliwość wydruku wszystkich zleceń i skierowań do jednostek wykonujących w ramach struktury organizacyjnej Zamawiającego.

2.

System musi umożliwiać ewidencję i drukowanie skierowań do instytucji zewnętrznych tj. skierowanie na hospitalizację, skierowanie do sanatorium, skierowanie na badania wykonywane poza jednostką Zamawiającego, zgodnie z wymogami prawa.

3.

System musi zapewniać możliwość rejestrację zleceń i skierowań z jednostek organizacyjnych Zamawiającego z dokładnością do osoby zlecającej oraz zleceń z podmiotów zewnętrznych zgodnie z obowiązującymi wymogami.

4.

System musi umożliwiać przygotowanie skierowań na badania złożone, kierowane do zewnętrznych jednostek. Przykładem badania złożonego może być skierowanie na badania laboratoryjne obejmujące kilka parametrów badanych np. morfologia, OB., analiza moczu.

5.

System musi zapewniać automatyczne przekazywanie wersji elektronicznych zleceń do odpowiedniej komórki organizacyjnej realizującej.

6.

System musi informować zlecającego o wszystkich zleconych i wykonanych badaniach zarówno z bieżącej jak i innych jednostek organizacyjnych Zamawiającego, dotyczących sytuacji, gdy w zadanym (opcjonalnie) okresie czasu pacjent miał już zaewidencjonowane takie samo zlecenie.

7.

System musi zapewniać blokowanie edycji zlecenia po jego zatwierdzeniu i wysłaniu.

8.

System musi zapewniać możliwość anulowania zlecenia przed jego realizacją.

9.

System musi rejestrować i prezentować uprawnionym użytkownikom etap wykonania, na jakim znajduje się zlecenie (zlecone, w trakcie realizacji, odwołane, zrealizowane, inne - stosownie do potrzeb).

10.

System musi zapewniać autoryzację wprowadzonych zleceń (automatyczną i wymagającą potwierdzenia ze strony zlecającego) oraz udostępniać narzędzia do przeglądu tych autoryzacji.

11.

System musi zapewniać możliwość wykorzystania danych dotyczących zleceń do rachunku kosztów i wyceny procedur medycznych.

12.

System musi prowadzić ewidencję daty i godziny dokonania operacji: wprowadzenie, zmiany, anulowanie realizacji zlecenia, wprowadzanie zmiany wyniku, udostępnienie (autoryzacji) wyniku oraz danych identyfikacyjnych użytkowników realizujących te operacje.

13.

System musi zapewniać możliwość realizacji zleceń na podstawie listy zleceń (umożliwiającej przegląd zleceń


według daty i rodzaju zlecenia), zawierającej wszystkie niezbędne dane, wykluczając konieczność wyszukiwania pacjenta lub wizyty.

14.

System musi zapewniać możliwość przeglądania i edycji danych zawartych w zarejestrowanym zleceniu, stosownie do posiadanych przez użytkownika uprawnień.

15.

System musi zapewniać możliwość odnotowania realizacji całego zlecenia jak i jego określonej części.

16.

System musi udostępniać wyniki zrealizowanych zleceń (np. wynik badania) zlecającemu i uprawnionym użytkownikom.

17.

System musi zapewniać uprawnionym użytkownikom możliwość podglądu wyników badań pacjenta: z konkretnych zleceń, z konkretnej pracowni, wszystkich wyników pacjenta.

18.

System musi zapewniać możliwość ewidencjonowania i wystawiania zleceń w zakresie zaopatrzenia w przedmioty ortopedyczne i środki pomocnicze zgodnie z obowiązującymi zasadami prawa.

19.

System musi zapewniać możliwość realizacji zleceń co najmniej w Pracowniach, Poradniach, Rejestracjach, Oddziałach, Działach

20.

System musi zapewniać możliwość integracji systemu HIS z systemami typu RIS/PACS w zakresie:

a. elektronicznego wysyłania zleceń do RIS,

b. automatycznego odbioru wyniku (opisu) zleconego badania,

c. automatycznego odbioru statusu badania,

d. automatycznego przypisanie kodu ICD-9 wykonanej procedurze, generowanie usług NFZ w powiązaniu z procedurą ICD-9.

21.

System musi zapewniać możliwość planowania i zlecania badań diagnostycznych i laboratoryjnych, zabiegów, konsultacji w ramach zleceń wewnętrznych (przekazywanych pomiędzy komórkami organizacyjnymi Zamawiającego):

1. z Oddziału do Pracowni i Działów Diagnostycznych

2. z Oddziału do Poradni, Oddziału,

3. z Oddziału do Bloku operacyjnego,

4. z Poradni, Gabinetu do Oddziału, Pracowni i Działów Diagnostycznych oraz Pracowni Rehabilitacji

5. z Bloku operacyjnego do Oddziału, Pracowni, Poradni i Działów Diagnostycznych

6. System powinien zapewniać możliwość planowania i zlecania badań i konsultacji w ramach zleceń zewnętrznych

(z innych podmiotów):

7. w Poradniach,

8. w Pracowniach,

9. w Laboratorium.

22.

System musi zapewniać zlecanie badań do systemów podrzędnych np. RIS/PACS, LIS przy wykorzystaniem standardu HL7.

23.

System musi zapewniać możliwość definiowania zleceń złożonych np. na zestaw badań

24.

System musi zapewniać możliwość przegląd zleceń według ustalonych przez użytkownika kryteriów np.: dla pacjenta, typu zlecenia (np. laboratoryjne, diagnostyczne, podanie leku).

25.

System musi zapewniać możliwość wydruku zleceń.

26.

System musi zapewniać możliwość przeglądanie dzienne zestawienie badań do wykonania.

27.

System musi zapewniać możliwość wydruku wszystkich wyników pacjenta z bieżącej hospitalizacji lub ze wszystkich pobytów w szpitalu.

28.

System musi zapewniać możliwość przeglądu wszystkich zleceń z jednostki zlecającej z możliwością wydruku wyniku.

29.

System musi zapewniać możliwość ewidencji danych niezbędnych dla sporządzenia karty gorączkowej.

30.

System musi zapewniać możliwość przeglądu karty gorączkowej, prezentacji interpretacji graficznej wyników.

31.

System musi zapewniać możliwość zapisania indywidualnych pakietów badań.

32.

System musi zapewniać możliwość zapisania pakietów zleceń z poziomu administracyjnego wszystkim pracownikom danej komórki organizacyjnej.

33.

System musi zapewniać możliwość zapisywania podręcznych pakietów badań pogrupowanych

34.

System musi umożliwiać uzupełnianie uwag/powodu zgłoszenia do zlecenia.

35.

System musi umożliwiać zapisywanie szablonów w polach opisowych w zleceniu badań.

36.

System musi umożliwiać zapisanie jako szablon dokumentu zlecenia ze wszystkimi danymi zapisanymi w zleceniu.

37.

System musi zapewniać możliwość edycji zapisanych wcześniej pakietów badań.

38.

System musi zapewniać możliwość anulowania zlecenia po jego zapisaniu.


7.1.1.18 Apteka szpitalna


Lp.

Opis wymagania

-

Program powinien zabezpieczać bieżącą pracę Apteki Szpitalnej, gwarantować zabezpieczenie wymogów NFZ i obowiązującego Prawa Farmaceutycznego i Ustawy o Wyrobach Medycznych Dyrektywy unijnej 2011/62/EU tzw. dyrektywy fałszywkowej i implementacji jej do polskiego prawa. W szczególności musi gwarantować gospodarkę materiałową. Dodatkowe szczególne wymogi:

- wprowadzanie faktur w tym faktury z recepturą (precyzja do minimum 4 miejsc po przecinku).

- podział asortymentu wprowadzanego z faktury na grupy towarowe np. leki (antybiotyki, płyny), opatrunki i inne wyroby medyczne, możliwość zgrywania z nośników elektronicznych

- identyfikowanie danej grupy towarowej na wydruku PZ.

- na wydruku PZ przypisanie do danej pozycji nr umowy przetargoweji faktury,

- blokowanie wydania danego asortymentu z magazynu na poziomie wprowadzania faktury np. zła cena produktu

- możliwość poprawiania ceny lub ilości przy danej pozycji wprowadzonego produktu, wydruk PZ nie zmienia kolejności wprowadzonych produktów a następnie korygowanych

- możliwości prowadzenia różnorodnych analiz zakupów np. analiza zakupów wg. Umowy przetargowej i jej rozliczenie

- przypisanie do danej pozycji umowy przetargowej (możliwe dwie zazębiające się umowy)

- rozliczanie umów przetargowych

- aktualizacja bazy leków

- baza zamienników danego leku, baza leków z nazwą producenta oraz nazwą międzynarodową substancji czynnie działającej

-

Obrót magazynowy. Wydawania na apteczki oddziałowe leków i innych materiałów. Dodatkowo:

- wykorzystanie słowników produktów leczniczych, grup ATC- (z możliwością dowolnej konfiguracji od poziomu 1 do 7) oraz nazw międzynarodowych


- definiowania własnych grup asortymentu (globalne i lokalne) dot. produktów leczniczych i wyrobów medycznych.

- definiowanie własnych wydzielonych magazynów

- tworzenie lokalnych słowników produktów leczniczych i wyrobów medycznych dla magazynów

- wyszukiwania produktu leczniczego na podstawie kodu EAN, PC, GTIN, nazwy międzynarodowej i handlowej

- rezerwacja stanów magazynowych

- bieżąca korekta jakościowa stanów magazynowych na podstawie dokumentu korygującego

- odnotowanie wstrzymania, wycofania lub dopuszczenia leku wg, komunikatów GIF, skutkujące alertem i wstrzymaniem wycofanego/wstrzymanego leku na poziomie preskrypcji lekarskiej i realizacji zleceń pielęgniarskich

- przegląd stanów magazynowych bieżących oraz na wybrany dzień wraz ze stanami zerowymi, po nazwie międzynarodowej oraz handlowej

- umożliwienie weryfikacji przekroczenia procentowego limitu ustawionego dla magazynu

- kontrola dat ważności oraz możliwość zdejmowania ze stanu leków przeterminowanych (wzór dokumentu zgodny z PF)

- definiowanie własnych dokumentów (np. przyjęcie próbek, )

- numerowanie dokumentów wg własnych definiowanych wzorców

- możliwość blokowania w magazynie wydawania danej pozycji np. lek wstrzymany lub wycofany z obrotu.

- wszystkie możliwe analizy np. rozchodów danej pozycji danej grupy towarowej, lub wg umowy przetargowej, możliwość tworzenia własnych analiz

- remanenty – np. na dzień, miesiąc

- zestawiania kosztów –analizy – różne warianty, możliwość tworzenia własnych analiz

- dostępne analizy magazynowe powinny być możliwe do wykonania „na dzień” (wartości pokazywane na wybrany dzień w przeszłości).

- wyróżnianie kolorami leków i materiałów znajdujących się w Receptariuszu Szpitalnym oraz spoza niego. Możliwość tworzenia widoków na stany po takich samych parametrach.

-

Sporządzanie zamówień:

1. do dostawców na podstawie aktualnych stanów magazynowych, stanów minimalnych i maksymalnych, z tzw. zamówień doraźnych ściśle powiązanych z dokumentem wydania na oddział.

2. blokada zamówienia , kiedy umowa jest całkowicie zrealizowana lub wykorzystana jej wartość lub jest niezatwierdzona

3. dokument zamówienia winien mieć możliwość dopisania ważnych elementów (np. cito) oraz winien pokazywać numer umowy.

-

Ewidencja dostaw:

- dostawa od Kontrahenta wprowadzania jest drogą elektroniczną, z dodatkową funkcjonalnością i możliwością zaciągnięcia e-faktury z platformy

- wprowadzenie faktury poprzez funkcję realizacji zamówienia od dostawcy

- możliwość zaciągnięcia faktury z systemu KOWALA jeśli będzie to możliwe, podczas operacji sprawdzenia

- manualna rejestracja faktury przychodowej z możliwością przypisania zamówienia do faktury

- import docelowy, dokument przychodowy z możliwością uzupełnienia elementów zgodnych z Prawem Farmaceutycznym ( między innymi pozwolenie MZ, kraj pochodzenia produktu itp..)

- dokument przychodu próbek winien mieć możliwość rejestracji danych osoby dostarczającej oraz nazwę podmiotu odpowiedzialnego.

- ewidencja dostaw na podstawie kodu EAN, GTIN, PC. W przypadku braku pozycji o podanym kodzie system powinien bezpośrednio na etapie przyjęcia, ze słownika zewnętrznego zaciągnąć dane z bazy BAZYL lub BLOZA lub innego równoważnego.

- korekta dokumentów ewidencjonująca dostawy produktów leczniczych i wyrobów medycznych

- modyfikacja dokumentów dostawy między innymi w zakresie korekty części dostawy

- dokument przychodowy PZ zawiera ponadto informację dot. realizację umowy:

z jakiej umowy, z jakiego postępowania, wartość umowy, ilość zrealizowana i stan umowy po

zatwierdzeniu zakupu.


- system zintegrowany jest z czytnikami kodu mozaikowego i paskowego (zgodnie z obowiązującymi przepisami)

- dokumenty przychodowy tzw. PZ mają możliwość zmian w stopce dokumentu

-

Ewidencja wydań:

- system umożliwia realizację zleceń z oddziałów, winien uwzględniać zlecenia na pacjenta w dowolnej grupie asortymentowej

- system umożliwia wydanie leku indywidualnemu pacjentowi np. do domu (program lekowy) lub do innej jednostki organizacyjnej (świadczenie usługi dla innego szpitala

- wydanie na oddziały za pomocą dokumentów RW oraz MM na podstawie zamówień elektronicznych lub papierowych (oprócz apteczek oddziałowych inne jednostki szpitala)

- ewidencja wydań na podstawie kodów EAN, GTIN, PC, nazw międzynarodowych i handlowych

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

- możliwość wydania na zewnątrz jednostki szpitala

- możliwość korekty zwrotów do dostawców

- korekta ubytków i strat

- korekta wydań produktów leczniczych i wyrobów medycznych

- kontrola i definiowanie limitów wartościowych produktów leczniczych i wyrobów medycznych wydawanych na oddział

- możliwość prezentacji wartości w postaci ułamkowej lub co najmniej do czterech miejsc po przecinku

- dokumenty RW oraz MM winny mieć możliwość dowolnej konfiguracji stopki

- analiza interakcji pomiędzy składnikami leków wydanych dla pacjenta, informacja na podst. BAZYL, BLOZ lub inne równoważne

- System winien umożliwiać definiowanie zamienników dla wybranych produktów leczniczych

- system winien posiadaćmożliwość przypisania produktu leczniczego do grupy zamienników.

-

Inwentaryzacja

- generowanie arkusza ze spisu z natury

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

- system winien sprawdzać, czy występują różnice remanentowe wraz z informacją o braku różnicy remanentowej

- system winienumożliwiać dopisanie do spisu z natury pozycji dla których nie odnotowano obrotów w danym magazynie.

- dokument inwentaryzacji spisu z natury winien umożliwiać wpisanie Komisji- wielopozycyjny

-

Zamówienia publiczne

- wspieranie obsługi zamówień publicznych

- przekazywanie list asortymentowej- wartościowej do modułu zamówień i przetargów

- kontrola realizacji dostaw i poziomu cen umów najlepszej oferty- umowy) szczególnie na poziomie realizacji (jw.)

- raporty po numerze umowy i postępowaniu przetargowym

- wyszukiwanie z umowy po nazwie międzynarodowej i handlowej i EAN

- widoczne okna z wartościami netto i brutto danej umowy

- generowanie procentowego zużycia dla dowolnej umowy, ilości umów.

- automatyczna blokada lub inna widoczna informacja np. status, kiedy umowa zakończona lub wykorzystana lub niezatwierdzona

-

Receptura

1. system musi posiadać możliwość generowania dokumentów do sporządzania leków recepturowych z danymi zgodnymi z PF oraz FP XI- tj. więcej pól do wypełnienia przy każdym wytwarzaniu leku- producent, warunki przechowywania, opis czynności, itp.

-

Cytostatyki i żywienie pozajelitowe


2. realizacja zamówień z Oddziałów

3. możliwość integracji w przyszłości z poziomu HIS z ew. systemami do przygotowywania żywienia pozajelitowego oraz cytostatyków

-

Raporty i zestawienia

1. na podstawie rozchodów, przychodów, stanów magazynowych po ATC(zakres dla DDD od 1-7), po umowie(numerze umowy i postępowaniu), po grupach analitycznych, po rodzajach dokumentów, po kontrahencie, po jednostce organizacyjnej po dostawcy, po producencie, po grupie analitycznej i po grupie farmaceutycznej,

2. możliwość wydruków do plików PDF oraz XLS

3. możliwość generowania raportów wg własnych definiowanych potrzeb

4. generowanie zamówień wewnętrznych

5. eksport danych do Księgowości: przychody , rozchody, różnice wartościowe, obroty z kontrahentami

-

Integracja z modułem księgowym

1. zapewnienie dostępności funkcji wartościowego, syntetycznego zapisu obrotu materiałowego na odpowiednich kontach

2. możliwość zapisu dokumentów rozchodowych(koszty) na poziomie wydania z apteki

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

4. możliwość eksportu dokumentów rozchodu wewnętrznego w odpowiednim formacie

-

ZSMOPL

- system posiada pełna funkcjonalność wraz z połączeniem odpowiedniej platformy z w ramach systemu ZSMOPL

- karty leków automatycznie posiadają zadane informacje o konieczności przesłania do ZSMOPL

-

KOWAL

- system posiada pełna funkcjonalność połączenia z KOWALem, na etapie przyjęcia towaru (j.w) i wydania na oddział(j.w)

-

Farmakoterapia

- przechowywanie informacji o leku

- decyzje GIF, wstrzymanie , wycofanie i dopuszczenie- przesyłanie na oddziały

- działania niepożądane(NDL, NOP)- ewidencja

- definiowanie receptariusza szpitalnego- możliwość generowania do pliku csv.

-

Depozyty (komis)

- System posiada oddzielny moduł magazynu depozytowego

- przyjmuje depozyt np. wg WZ

- po wszczepie generuje zamówienie do firmy celem uzupełnienia depozytu- generowanie zamówienia. Blokada zamówienia w przypadku przekroczenia wartości umowy

- przyjmuje fakturę depozytową, na dokumencie PZ winna znaleźć się informacja o numerze umowy, numerze postępowania wartości umowy, wartości zrealizowanej umowy oraz po zatwierdzenie ile pozostało z umowy.

- rozchodowuje depozyt na pacjenta - ścisły związek dostępu CBO do listy pacjentów (PESEL lub nazwisko lub numer historii choroby)

- rozchodowuje depozyt bez pacjenta

- koryguje rozchód depozytowy

- tworzenie zamówienia do firmy bez pacjenta

- umożliwia kontrolę zamówień do dostawców

- kontroluje umowy przetargowe depozytowe informując o stopniu realizacji

-

Integracja z systemem szaf lekowych

1. System musi umożliwiać w przyszłości integrację ze szpitalnym systemem w przypadku uruchamiania i wdrażania systemu UNIT DOSE

2. System musi umożliwiać w przyszłości integrację ze szpitalnym systemem w przypadku uruchamiania i wdrażania systemu szaf RFID lub SZAF LEKOWYCH


7.1.1.19 Apteczka oddziałowa


Lp.

Opis wymagania

1.

System musi umożliwiać generowanie zamówień do Apteki Szpitalnej

2.

System musi umożliwiać dołączenie do zamówienia informacji nt. pacjenta, dla którego dany lek jest zamawiany.


3.

System musi umożliwiać wydawania środków farmaceutycznych z apteczki oddziałowej:

1. wydawanie na oddział lub na pacjenta,

2. zwrot do apteki,

3. ubytki i straty nadzwyczajne.


4.

System musi umożliwiać wprowadzanie korekt stanów magazynowych:

1. korekta stanów magazynowych (ilościowa i jakościowa) na podstawie arkusza spisu z natury,

2. generowanie arkusza do spisu z natury.


5.

System musi zapewniać wspomagania decyzji farmakoterapeutycznych:

1. pomoc w zakresie tworzenia i zarządzania receptariuszem szpitalnym,

2. informacja o leku, (postać, dawka, wielkość opakowania, dostępność/brak w receptariuszu szpitalnym, inne leki

dostępne z tej grupy (zamienniki dla danego leku), dostępność na podstawie odrębnej decyzji osób odpowiedzialnych za dystrybucję na terenie szpitala itd. – cena ostatniej dostawy.


6.

System musi umożliwiać wykonywanie czynności analityczno-sprawozdawczych, tworzenie bieżących raportów i zestawień.

7.

System musi umożliwiać podział leków na wydawane na oddział lub na pacjenta.


8.

System musi umożliwiać wykorzystanie słowników (również dla celów wyszukiwania): leków, grup ATC, nazw międzynarodowych, słownik jednostek miar itp. jak też kolory do oznaczania laków z Receptariusza.


9.

System musi umożliwiać kontrolę dat ważności oraz możliwość zwracania leków przeterminowanych do magazynów/apteki.

10.

System musi umożliwiać pełny dostęp do danych archiwalnych.

11.

System musi umożliwiać prowadzenie dziennika akcji wykonanych w systemie (logi).

12.

System musi umożliwiać definiowanie i obsługę wielu apteczek oddziałowych w ramach jednego oddziału.

13.

System musi umożliwiać ewidencjonowanie i obsługę przyjęć leków własnych pacjenta.


14.

System musi umożliwiać ewidencjonowanie zużycia leków i materiałów medycznych na pacjenta z jednej oraz z wielu apteczek i automatyczne przeniesienie danych do modułu KKL.

15.

System musi umożliwiać ewidencjonowanie zużycia na oddział z jednej oraz z wielu apteczek, a dalej automatyczne


przeniesienie danych do modułu kosztów.

16.

System musi umożliwiać przeprowadzenie inwentaryzacji w apteczce.

17.

System musi umożliwiać przegląd i kontrolę stanów magazynowych oraz obrotów w magazynkach oddziałowych.


18.

System musi umożliwiać przygotowanie i wydruk arkuszy spisowych magazynków oddziałowych wg grup i indeksów oraz innych parametrów indeksu (podobnie jak w Aptece)


19.

Moduł powinien posiadać możliwość wykonania zestawień:

1. zużycia środków farmakologicznych z podziałem na płatników,

2. zużycia środków farmakologicznych na pacjenta. Także na wskazany dzień w przeszłości.

20.

System musi umożliwiać przeprowadzenie spisu z natury.

21.

System musi umożliwiać przeprowadzenie inwentaryzacji z poziomu apteczki oraz apteczki dyżurki pielęgniarek.


22.

System musi umożliwiać wypełnienie, wydruk karty zgłoszenia niepożądanego działaniu produktu leczniczego (NDL, NOP) z jednoczesnym wpisaniem zdarzenia do modułu zdarzeń niepożądanych.


23.

System musi umożliwiać wydruk następujących raportów:

• Stanu leków i materiałów po różnych grupach i innych parametrach indeksu,

• Przyjęcieśrodków,

• doniesienie o niepożądanym działaniuśrodka leczniczego,

• książka kontroli przychodów irozchodów,

• zestawienie zużycia środków przez pacjentów naoddziale,

• zestawienie zużycia środków przezpacjenta,

• zapotrzebowanie na środki doapteczki,

• dokument zwrotu środków doapteki,

• kasacja środków naoddziale,

• lista leków ze zbliżającym się końcem daty ważności,


Wszystkie raporty muszą pozwalać na pokazywanie stanu na wybrany dzień także w przeszłości.


24.

System musi umożliwiać generowanie raportu Jednorodnego Pliku Kontrolnego na wezwanie Urzędu Skarbowego dla wskazanego magazynu.


25.

System musi posiadać precyzję cen opakowań rejestrowanych w bazie z dokładnością co najmniej 5 miejsca po przecinku.


26.

System musi umożliwiać blokowanie tworzenia i modyfikowania dokumentów obrotowych w zdefiniowanych okresach rozliczeniowych.

27.

System musi umożliwiać wykonanie raportu z wiekowania stanów magazynowych.


7.1.1.20 Diety


Lp.

Opis wymagania

1)

System musi umożliwiać definiowanie diet żywnościowych.

2)

System musi umożliwiać zdefiniowanie dla każdej z diet informacji o wartościach odżywczych.

3)

System musi umożliwiać definiowanie informacji o składnikach odżywczych dla każdego z produktów.

4)

System musi umożliwiać określenie kilkunastu różnych diet w jednym jadłospisie.

5)

System musi umożliwiać konfigurację minimalnej i maksymalnej wartości odżywczej w danej diecie.

6)

System musi umożliwiać pogląd listy produktów potrzebnych do przygotowania danej diety.

7)

System musi umożliwiać tworzenie oraz modyfikacji definicji posiłków.

8)

System musi umożliwiać tworzenie katalogów i zarządzania danymi:

- produktów,

- diet,

- posiłków,

- potraw,

- wartości odżywczych.

9)

System musi umożliwiać zdefiniowanie dowolnej ilości posiłków dla każdej diety np.:

- śniadanie,

- drugie śniadanie,

- obiad,

- podwieczorek,

- kolacja,

- posiłek nocny.

10)

System musi umożliwiać drukowanie jadłospisu dla każdej diety oddzielnie.

11)

System musi umożliwiać drukowanie surowców (sumarycznie) potrzebnych do realizacji jadłospisu.

12)

System musi umożliwiać zestawienie niezbędnych surowców dla wskazanej diety w wybranym jadłospisie.

13)

System musi umożliwiać drukowanie wartości składników odżywczych dla diet w jadłospisie.

14)

System musi umożliwiać modyfikowanie, dodawanie i usuwanie diet przez uprawnionego użytkownika z poziomu słownika diet.

15)

System musi umożliwiać zlecenie diety w trybie non-stop (od chwili zlecenia – system codziennie ponawia zlecenie diety dla pacjenta, ponadto możliwość zmiany zleconej diety).

16)

System musi umożliwiać zlecanie dodatkowych produktów żywieniowych w ramach diety indywidualnej.

17)

System musi umożliwiać automatyczne rozpoczęcie zlecenia lub zakończenia zlecenia diety w przypadku przyjęcia i wypisu pacjenta z oddziału z uwzględnieniem godziny, przerwy w żywieniu z tytułu zabiegu, wypisu na przepustkę lub zgonu.

18)

System musi umożliwiać wydruk ilości diet z uwzględnieniem lekarza i oddziału zlecającego.

19)

System musi umożliwiać eksport danych w formacie .csv w zakresie diet do zewnętrznego programu.

20)

System musi umożliwiać udostępnienie diet dla potrzeb kuchni w formie raportu i zestawienia (na ekranie monitora) stanu dziennego wg jadłospisów.

21)

System musi umożliwiać przeglądania stanu zbiorczego ilości żywionych pacjentów w tym:

• ilość diet


• nazwa diety

• oddział zamawiający.


7.1.1.21 Leki – Zlecenia i realizacja


Lp.

Opis wymagania

1.

System musi umożliwiać zlecanie leków z jednoczesnym podglądem na aktualną Kartę leków pacjenta w jednym oknie.

2.

System musi umożliwiać zlecanie leków z jednoczesnym dostępem do całej dokumentacji pacjenta w jednym oknie.

3.

System musi umożliwiać potwierdzenie aktualnego zlecenia bez konieczności ponownego wystawiania dzięki automatycznemu przedłużaniu leków w ramach danego zlecenia.

4.

System musi umożliwiać zawężenie listy leków do leków dostępnych w receptariuszu jednostki, tylko dostępnych, leków pacjenta oraz leków infuzyjnych.

5.

System musi umożliwiać dynamiczne wyszukiwanie leku na liście bez konieczności użycia znaków specjalnych.

6.

System musi umożliwiać wyszukiwanie leków po nazwie handlowej oraz międzynarodowej.

7.

System musi umożliwiać wyświetlanie (domyślnie) dostępności leków w Szpitalu już na etapie wyszukiwania leku.

8.

System musi umożliwiać wyszukiwanie zamienników leku.

9.

System musi umożliwiać przeglądanie CHPL leku.

10.

System musi umożliwiać automatyczne podpowiadanie drogi podania leku (po jego wcześniejszym skonfigurowaniu na poziomie Karty leku w Aptece).

11.

System musi umożliwiać tworzenie słownika Uwag dołączanych do zlecenia.

12.

System musi umożliwiać zlecanie leku w trybie do decyzji oraz w trybie pilnym. Wybór podania leku w trybie pilnym skutkuje wyświetleniem wykrzyknika na Karcie leków.

13.

System musi umożliwiać wyświetlanie na Karcie leków godziny, dawki podania, leków do decyzji, ewentualnych uwag zlecającego i realizującego oraz statusu leków. Na Karcie leków musi widnieć również informacja o lekach pacjenta.

14.

System musi umożliwiać oznaczanie na Karcie leków kolorami statusu leku co najmniej potwierdzone, zrealizowane, wstrzymane z podaniem przyczyny oraz zaplanowane - do potwierdzenia.

15.

System musi umożliwiać wstrzymywanie oraz odstawiania zleconych leków z poziomu Karty leków.

16.

System musi umożliwiać wyświetlanie aktualnej informacji o alergiach pacjenta na poziomie Zlecenia oraz Karty leków.

17.

System musi umożliwiać zapisywanie całego Zlecenia jak szablonu.

18.

System musi umożliwiać odfiltrowanie na Karcie leków, leków do decyzji.

19.

System musi umożliwiać przywrócenia leku z leków nieaktywnych z poziomu Karty leków – wyłącznie na poziomie Apteki i odpowiednich uprawnień.

20.

System musi umożliwiać zmianę dawki i godziny podawania leku z poziomu Karty zleceń – przy odpowiednich uprawnieniach.

21.

System musi umożliwiać wycofania potwierdzenia potwierdzonego wcześniej leku – poprzez korektę, przy odpowiednich uprawnieniach.

22.

System musi umożliwiać zlecenie leków podawanych cyklicznie z określeniem długości cyklu, godzin podawania, dawki z podziałem na stałą i zmienną oraz określenia przerwy w podawaniu w ramach tworzonego cyklu.

23.

System musi umożliwiać zlecenie leków podawanych w wybrane dni tygodnia z określeniem godzin podawania oraz dawki z podziałem na stałą i zmienną.

24.

System musi umożliwiać zlecenie leków podawanych doraźnie z określeniem ilości podań oraz dawki z podziałem na stałą i zmienną. Po zatwierdzeniu pierwszego podania system automatycznie wylicza kolejne dawki co X (określane na etapie tworzenia zlecenia) godzin od pierwszego podania.

25.

System musi umożliwiać zlecenie leków infuzyjnych. System po wybraniu opcji Leki infuzyjne automatycznie zawęża listę leków do roztworów do infuzji. Wybór roztworu do infuzji skutkuje zawężeniem listy rozcieńczalników przypisanych do danego produktu. System po zmianie przepływu automatycznie przelicza czas podawania.

26.

System musi umożliwiać zlecenie leków w pompie z automatycznym wyliczaniem jej parametrów z przeliczaniem jednostek właściwych dla danego urządzenia.

27.

System musi umożliwiać modyfikację parametrów pompy w trakcie jej podawania oraz odstawienia pompyz przeliczaniem jednostek właściwych dla danego urządzenia.

28.

System musi umożliwiać dołączanie załączników do Zlecenia.

29.

System musi umożliwiać przywracania ostatnio anulowanej zawartości w sytuacji przypadkowego anulowania wystawianego Zlecenia.

30.

System musi umożliwiać wydruk zlecenia lekarskiego.

31.

System musi umożliwiać zawężenie listy pacjentów na oddziale do pacjentów posiadających leki do decyzji.

32.

System musi umożliwiać szybkie wprowadzanie godzin podań przez dedykowane przyciski 2x, 3x, 4x na dobę wraz z możliwością indywidualnej konfiguracji godzin dla danego oddziału

33.

System dla wyróżnionych grup leków „Antybiotyki”, „P. zakrzepowe” oraz „P. cukrzycowe” musi umożliwiać konfigurację wyników badań laboratoryjnych oraz parametrów życiowych, które będą prezentowane przy datach podania leku

34.

System musi umożliwiać sortowanie kolejności leków wg kodów ATC z możliwością indywidualnego ustalenia porządku kodów ATC dla danego oddziału

35.

System musi umożliwiać podgląd aktualnych zleceń dla oddziału w jednym oknie z możliwością zawężenia listy przynajmniej według statusu zadania, sali, wybranego pacjenta, oraz drogi podania.

36.

System musi umożliwiać oznaczanie w oknie realizacji kolorami statusu dawki leku co najmniej potwierdzone, zrealizowane, wstrzymane z podaniem przyczyny oraz zaplanowane - do potwierdzenia.

37.

System musi umożliwiać oznaczanie w oknie realizacji wykrzyknikiem (lub w inny czytelny sposób) leków zleconych do podania w trybie pilnym.

38.

System musi umożliwiać oznaczenie podania jako zrealizowane. System automatycznie podpowiada datę i godzinę podania z możliwością jej zmiany. Użytkownik ma możliwość wpisania uwag do realizacji zlecenia z możliwością tworzenia szablonów, odnotowania „niepodania” oraz ilości podanej i pobranej leku. System automatycznie podpowiada jaką partię zużyto, partię z najkrótszą datą ważności z możliwością zmiany wyboru. Użytkownik ma możliwość wyboru zużytej partii łącznie z zamiennikami. Odnotowana ilość leku pobranego automatycznie jest zdejmowana ze stanu Apteczki oddziałowej.

39.

System musi umożliwiać korektę transakcji zużycia (wycofanie) oraz wycofania realizacji zlecenia w sposób audytowalny. Odnotowana i wycofana ilość leku pobranego automatycznie jest przywracana na stan Apteczki oddziałowej. Korekty transakcji powinny być autoryzowane przez uprawnione osoby.

40.

System musi umożliwiać prezentowanie informacji na karcie leków o modyfikacji ilości podanego leku (po autoryzacji) przez personel realizujący.

41.

System musi umożliwiać wydruk Listy zleconych leków do podania.

42.

System musi umożliwiać automatyczne przyjmowanie, rozpisanie i realizację leków na podstawie aktualnego stanu magazynowego apteczki oddziałowej.

43.

System musi umożliwiać wydruk zleceń na środki farmaceutyczne zarówno wg pacjentów, jak i wg zleconych leków.

44.

System musi umożliwiać rozdział zleceń dla pielęgniarki lekowej (tabletki, kapsułki, etc.) i zabiegowej (iniekcje).

45.

System musi umożliwiać współpracę z czytnikami kodów kreskowych i kolektorami danych przy ewidencji podania leków pacjentowi.

46.

System musi umożliwiać prowadzenie księgi realizacji zleceń lekarskich.

47.

System musi umożliwiać synchronizację pomiędzy kartą zleceń lekarskich, a księgą zabiegów pielęgniarskich.

48.

System musi umożliwiać prowadzenie książki leków silnie działających i narkotycznych.

49.

System musi umożliwiać sprawdzenie interakcji występujących pomiędzy składnikami ordynowanych pacjentowi leków. Wyświetlanie interakcji lub brak wyświetlania musi być konfigurowane przez każdego użytkownika indywidualnie.


7.1.1.22 Żywienie pozajelitowe


Lp.

Opis wymagania

1.

System umożliwia zlecanie żywienia parenteralnego przez lekarzy w oparciu o następujące algorytmy

− dla dorosłych/wg zapotrzebowania na energię, białko i płyny, możliwość uwzględnienia stanu zdrowia pacjenta ,

− dla dzieci i noworodków /wg podaży w g/kg masy ciała, możliwość uwzględnienia ilości płynów i przyjmowanego pokarmu

− wg płynów bazowych /ilość płynów bazowych w ml, procentowa ilość aminokwasów i ilość dodatkowej wody.

Dodatkowe preparaty dodawane indywidualnie.

2.

System posiada wbudowany kalkulator żywieniowy, który wylicza wszystkie istotne, z punktu widzenia stabilności, pacjenta parametry

3.

System umożliwia wystawianie zleceń przez lekarzy dla noworodków z uwzględnieniem czy noworodek jest wcześniakiem z wagą poniżej 1,5kg oraz uwzględnieniem ilości przyjmowanego przez noworodka pokarmu matki lub sztucznego

4.

System podpowiada lekarzowi składy recept w zależności od stanu zdrowia pacjenta

5.

System posiada możliwość modyfikacji recepty przez farmaceutę

6.

System umożliwia dostęp do historii podań ze składem recept

7.

System umożliwia wystawianie zleceń przez lekarzy z zastosowaniem worków RTU(dodawanie preparatów do RTU zgodnie z charakterystyką produktu) dwu i trzykomorowych

8.

System umożliwia tworzenie mieszaniny od samego początku z wykorzystaniem „worków” RTU, z użyciem kopiowania recept bądź też za pośrednictwem stworzonych wcześniej szablonów

9.

System uwzględnia limity składników narzucone przez producentów „worków” RTU zgodnie z wytycznymi producenta.

10.

System umożliwia wystawianie zleceń przez lekarzy bez stosowania algorytmówna podstawie ilości preparatów

11.

System umożliwia ocenę stabilności mieszaniny w oparciu o wyliczone parametry recepty /mieszaniny podczas jej wypisywania

12.

System posiada ostrzeżenie w przypadkach przekroczeńwartości parametrów zlecanych mieszanek

13.

System pozwala na zasięgnięcie informacji o witaminach i pierwiastkach śladowych podczas zlecania mieszaniny

14.

System pozwala na określenie /ustalenie ilości recept ,dni dla żywienia domowego

15.

System umożliwia planowanie podaży mieszaniny na recepcie na jeden dzień lub na określony czas (w przypadku żywienia domowego)

16.

System umożliwia kopiowanie recept żywieniowych wystawianych dla pacjentów

17.

System pozwala na obsługę wcześniej przygotowanych mieszanek żywieniowych

18.

System określa sposób podania żywienia (dojście centralne lub drogą obwodową)

19.

System umożliwia elektroniczne przesłanie recepty do apteki szpitalnej /pracowni żywieniowej celem wykonania mieszaniny

20.

System umożliwia sprawdzenie i zatwierdzenie przez pracownika apteki recept wystawionych przez lekarzy- z uwzględnieniem parametrów stabilności mieszaniny żywieniowej

21.

System umożliwia wydruk zlecenia żywienia pozajelitowego

22.

System umożliwia przygotowanie listy potrzeb preparatów i sprzętu w sztukach wraz z numerami serii i datą ważności

23.

System umożliwia wykonanie recept dla żywienia na weekend oraz żywienia domowego w systemie tygodniowym

24.

System umożliwia dopisanie wody do worka żywieniowego potrzebnej do rozpuszczenia Soluvitu,Cernevitu

25.

System umożliwia drukowanie etykiet na worki z preparatami żywieniowymi na podstawie wystawionych receptwzór etykiety zgodny ze standardami Towarzystwa Żywienia Do i Pozajelitowego.

26.

System umożliwia drukowanie na etykietach preparatów ,które należy dodać do worka przed podaniem pacjentowi

27.

System umożliwia korzystanie z zestawień zleceń wypisywanych przez lekarzy (możliwość drukowania , imię i Nazwisko lekarza zlecającego i pacjenta, wiek,masa dziecka. Skład mieszaniny żywieniowej, godzina przygotowania mieszaniny, termin przydatności mieszaniny do podania, szybkość wlewu mieszaniny, podpis osoby

wykonującej)

28.

System pozwala rozliczyć preparaty i sprzęt zużyty do żywienia pozajelitowego w programie aptecznym oraz na oddziały szpitalne

29.

System kontroluje numery serii i daty ważności produktów i sprzętu

30.

System rozlicza koszty żywienia pozajelitowego

31.

System automatycznie rozlicza mieszaniny żywieniowe na pacjenta

32.

Możliwość współpracy z maszynami żywieniowymi dostępnymi na rynku


7.1.1.23 Zlecenia laboratorium


Lp.

Opis wymagania

1.

System musi umożliwiać elektroniczne wystawienie skierowania.

2.

System musi umożliwiać automatyczne wysyłanie skierowań na badania do Laboratorium po wybraniu odpowiedniego statusu przez użytkownika.

3.

System musi umożliwiać ewidencjonowanie skierowań do laboratorium zewnętrznego.

4.

System musi umożliwiać zlecanie różnych badań na podstawie wcześniej ustalonych wzorców.

5.

System musi umożliwiać podgląd badań przyjętych przez laboratorium do wykonania.

6.

System musi umożliwiać podgląd badań wykonanych w laboratorium.

7.

System musi umożliwiać podgląd stanu realizacji zlecenia.

8.

System musi umożliwiać skierowanie na badania w trybie zwykłym oraz w trybie cito.

9.

System musi umożliwiać wydruku skierowania.

10.

System musi umożliwiać wydruk wszystkich niezrealizowanych zleceń.

11.

System musi umożliwiać zlecanie wykonania próby zgodności w pracowni serologii.

12.

System musi umożliwiać wprowadzenie wyników laboratoryjnych pacjenta wykonanych poza szpitalem.

13.

System musi umożliwiać pogląd wyników badań.

14.

System musi umożliwiać wydruk wyników badań.

15.

System musi umożliwiać identyfikację materiałów za pomocą kodów kreskowych.

16.

System musi umożliwiać wydruk etykiet na materiały.

17.

System musi umożliwiać zaewidencjonować informacje na temat osoby, która pobierała materiał do badań.

18.

System musi umożliwiać wprowadzenie informacji na temat stanu zdrowia chorego.

19.

System musi umożliwiać przekazania informacji do laboratorium o fakcie, że pacjent jest osobą leżącą.

20.

System musi umożliwiać na ewidencjonowanie informacji o cenach badań.


7.1.1.24 Punkt pobrań


Lp.

Opis wymagania


1.

System musi umożliwiać integrację z wieloma systemami typu LIS.


2.

System musi zapewniać możliwość wysłania elektronicznego zlecenia do wybranej jednostki realizującej (laboratorium).


3.

System musi zapewniać możliwość ustawienia domyślnej jednostki realizującej zlecenie dla każdej komórki organizacyjnej (jednostki zlecającej).


4.

System musi zapewniać możliwość ewidencjonowanie informacji na temat daty, godziny oraz osoby, która pobierała materiał do badań.


5.

System musi zapewniać możliwość wydruku zlecenia w formacie A4 lub A5 lub w formacie recepty zawierającego:

• datę i godzinę pobrania materiału

• kod próbki

• kod zlecenia

• podpis osoby pobierającej próbkę.


6.

System musi zapewniać możliwość wysłania żądania anulowania całości lub części zlecenia do momentu otrzymania potwierdzenia od laboratorium informacji o przyjęciu tam materiału.


7.

System musi zapewniać możliwość modyfikacji niezrealizowanego zlecenia.


8.

System musi zapewniać możliwość podglądu stanu realizacji zlecenia (status zlecenia).


9.

System musi zapewniać możliwość identyfikacji materiałów za pomocą kodów kreskowych.


10.

System musi zapewniać możliwość konfiguracji Punktu Pobrań jako osobnej jednostki dotyczącej pobierania od pacjentów materiału oraz powiązania go za pomocą kodów ze zleceniem.


11.

System musi zapewniać możliwość konfiguracji Punktu Pobrań w ramach jednostki zlecającej dotyczącej pobierania od pacjentów materiału oraz powiązania go za pomocą kodów ze zleceniem z danej jednostki.


12.

System musi zapewniać możliwość konfiguracji zleceń laboratoryjnych z pominięciem Punktu Pobrań w ramach danej jednostki zlecającej - zlecenia trafiają bezpośrednio do systemu LIS.


7.1.1.25 Wyniki pacjenta


Lp.

Opis wymagania

1.

System musi udostępniać wyniki zrealizowanych zleceń (np. wynik badania) zlecającemu i uprawnionym użytkownikom.

2.

System musi zapewniać uprawnionym użytkownikom możliwość podglądu wyników badań pacjenta: z konkretnych zleceń, z konkretnej pracowni, wszystkich wyników pacjenta.

3.

System musi umożliwiać dla wyróżnionych grup leków „Antybiotyki”, „P. zakrzepowe” oraz „P. cukrzycowe” konfigurację wyników badań laboratoryjnych oraz parametrów życiowych, które będą prezentowane przy datach podania leku.

4.

System musi zapewniać integrację z systemami typu RIS/PACS, LIS w zakresie automatycznego odbioru wyniku / opisu zleconego badania.

5.

System musi umożliwiać wydruk wyników laboratoryjnych pacjenta z podaniem zakresu dat.

6.

System musi umożliwiać podgląd wyników badań pacjenta z poziomu Sali zabiegowej Pracowni, Poradni i innych ustalonych przez użytkownika.

7.

System musi umożliwiać podgląd wszystkich wyników badań pacjenta w jednym miejscu z możliwością filtrowania po rodzaju badania co najmniej laboratoryjne, obrazowe.

8.

System musi umożliwiać podgląd wszystkich wyników badań pacjenta w jednym miejscu z możliwością filtrowania po dacie (bądź zakresie dat) badań.

9.

System musi umożliwiać podgląd wyników badań w formie tabelarycznej z kolorystycznym rozróżnieniem wartości poza normą.

10.

System musi umożliwiać podgląd wyników badań w formie wykresów z oznaczeniem wartości poza normą z możliwością wyboru badań jakie na wykresie mają się znaleźć.

11.

System musi posiadać interaktywne wykresy wyników laboratoryjnych prezentując zmiany koloru ekranu dla wyników badań poza normą.

12.

System musi posiadać funkcjonalność informowania lekarza o wynikach do rozliczenia w ramach bieżącej wizyty.

13.

System musi umożliwiać dołączenie do dokumentacji medycznej zewnętrznych wyników badań.

14.

System musi umożliwiać odbieranie i przeglądanie wyników badań Mikrobiologii i histopatologii.


7.1.1.26 Recepty


Lp.

Opis wymagania

1.

System musi umożliwiać wystawianie e-recept, recept i wydruku recept, zgodnie z obowiązującymi przepisami prawa.

2.

System musi umożliwiać definiowanie puli numerów nanoszonych na recepty indywidualnie dla każdego lekarza poprzez import puli z pliku xml lub poprzez ręczne definiowanie puli.

3.

System musi umożliwiać zbiorcze przeglądanie przydzielonych lekarzom pól recept i wyróżnia pozycje, dla których dostępna konfigurowalna minimalna ilość numerów recept została przekroczona.

4.

System musi umożliwiać wydruk pełnej treści recepty (w tym dane pacjenta, leki, ich ilość, dawkowanie, informacje o odpłatności itp.) z możliwością określenia puli numerów recept dla danego lekarza.

5.

System musi umożliwiać wydruk pustych recept, na których personel medyczny będzie mógł ręcznie wpisać nazwy leków, dawkowanie, odpłatność.

6.

System musi umożliwiać prezentowanie informacji o ilości numerów recept pozostałych do wykorzystania.

7.

System musi umożliwiać generowanie ostrzeżenia dla użytkownika w przypadku próby edycji lub ponownego wydruku już wydrukowanej recepty.

8.

System musi umożliwiać posiadanie niezależnych pul recept uwzględniając typ recepty RPW.

9.

System musi umożliwiać tworzenie recept wraz z wpisem o zleconych lekach do dokumentacji medycznej pacjenta, zapewniającym generowanie raportów zawierających informacje o ilości, asortymencie, odpłatnościach itp. Przepisywanych leków przez poszczególnych lekarzy i zbiorczo oraz gromadzi informacje o zażywanych przez pacjenta lekach (okres przyjmowania, dawkowanie itp.).

10.

System musi umożliwiać wprowadzanie adnotacji do wystawianych recept.

11.

System musi umożliwiać automatyczne dodawanie opisu słownego leków psychotropowych i odurzających na receptach realizowanych z puli recept RPW.

12.

System musi umożliwiać tworzenie szablonów recept oraz kopiowanie: wszystkich leków z wybranej recepty, wybranego leku z recept wystawionych wskazanego dnia w tym z poprzedniej wizyty.

13.

System musi umożliwiać wybór leków, które mają być zamieszczone na recepcie w oparciu o zaimportowaną bazę leków.

14.

System musi umożliwiać wydruk numeru dokumentu tożsamości obcokrajowca na recepcie.

15.

System musi umożliwiać wyliczanie wieku pacjenta na podstawie jego daty urodzenia.

16.

System musi umożliwiać ewidencjonowanie wystawionych recept zgodnie z obowiązującymi przepisami.

17.

System musi umożliwiać zaimportowanie jednego z dostępnych słowników leków (np. Pharmindex, BLOZ, BAZYL, LEKSEEK) wykorzystywanego na potrzeby wystawiania recept oraz musi zapewniać jego aktualizację do najnowszej wersji oraz musi współpracować z wieloma bazami produktów leczniczych jednocześnie. Wskazana baza leków musi zostać zaimportowana na etapie wdrażania systemu na koszt Dostawcy.

18.

System musi umożliwiać dodawanie do słownika leków recepturowych z określeniem ich składników oraz zapewnia wydruk składników leku recepturowego.

19.

System musi umożliwiać udostępnianie podręcznej listy leków ordynowanych przez danego lekarza, z możliwością jej edycji.

20.

System musi umożliwiać przeglądanie CHPL leku.

21.

System musi umożliwiać prezentację listy leków udostępniając minimum: nazwę, substancję czynną, postać, dawkę, informację o opakowaniu (dla leków recepturowych System prezentuje nazwę).

22.

System musi umożliwiać automatyczne nanoszenie na receptę informacji, które mogą być naniesione


automatycznie, np.: informacje o świadczeniodawcy, komórce organizacyjnej, lekarzu wystawiającym.

23.

System musi umożliwiać przy wypisywaniu recepty prezentowania informacji o zasadach odpłatności za ordynowany lek, w zależności od: obowiązujących zasad wynikających z zapisów prawa, w tym rozpoznania, uprawnień pacjenta i jego wieku (w tym zasad obowiązujących odnośnie pacjentów POZ, którzy ukończyli 75. Rok życia).

24.

System musi umożliwiać wyszukiwanie odpowiedników ordynowanych leków, x.xx. wg najniższej ceny DDD dla pacjenta lub umożliwiać wystawienie recepty wyłącznie z pozostawieniem nazwy międzynarodowej.

25.

System musi umożliwiać sprawdzenie interakcji występujących pomiędzy składnikami ordynowanych pacjentowi leków w ramach danej wizyty i wizyt wcześniejszych zaewidencjonowanych w Systemie. Wyświetlanie interakcji lub brak wyświetlania musi być konfigurowane przez każdego użytkownika indywidualnie.

26.

System musi umożliwiać generowanie raportów zawierających informacje o ilości, asortymencie, odpłatnościach przepisywanych leków przez poszczególnych lekarzy i zbiorczo dla lekarzy i jednostek organizacyjnych.

27.

System musi umożliwiać dostęp do funkcjonalności drukowania i wypełniania recept stosownie do nadanych uprawnień


7.1.1.27 Rehabilitacja


Lp.

Opis wymagania

1.

System musi umożliwiać obsługę zleceń dla:

- rehabilitacji ambulatoryjnej

- rehabilitacji oddziału dziennego

- rehabilitacji pacjentów hospitalizowanych.

- System musi umożliwiać zlecanie i realizację świadczeń z zakresu fizjoterapii polegających na diagnostyce funkcjonalnej pacjenta, kwalifikowaniu, planowaniu i prowadzeniu fizykoterapii, kinezyterapii lub masażu w zależności od uprawnień personelu;

2.

System musi umożliwiać obsługę zleceń z jednostek wewnętrznych jak i zewnętrznych.

3.

System musi umożliwiać zarządzanie grafikami i terminarzami:

- personelu

- stanowisk i urządzeń rehabilitacyjnych.

4.

System musi umożliwiać generowanie zestawień wykonanych zabiegów przez poszczególnych pracowników.

5.

System musi umożliwiać pełną integrację działu fizjoterapii z poradnią i oddziałem, co niesie za sobą automatyczne wysyłanie zleceń i odbieranie informacji o realizacji zlecenia. System musi umożliwiać integrację w zakresie przesyłania danych o kosztach zabiegów na pacjenta do KKL

6.

System musi umożliwiać automatyczne podpięcie procedur i produktów związanych z zabiegiem w momencie oznaczenia jego realizacji.

7.

System musi umożliwiać wyszukiwanie cyklu co najmniej po kryteriach takich jak:

- status

- płatnik

- zakres dat

- imię pacjenta

- nazwisko pacjenta


- PESEL pacjenta.

8.

System musi umożliwiać sortowanie wyszukanych cykli po co najmniej kryteriach takich jak:

1. nazwisko pacjenta

2. data rozpoczęcia

3. data zakończenia.

9.

System musi umożliwiać przeglądanie wszystkich grafików fizjoterapeutów/zasobów/gabinetów utworzonych w ramach jednostki w jednym oknie.

10.

System musi umożliwiać przeglądanie ilości zaplanowanych / wolnych wizyt dla wszystkich zasobów jednostki w jednym miejscu.

11.

System musi umożliwiać szybkie przejście do dnia dzisiejszego.

12.

System musi umożliwiać zarządzanie słownikami:

- stanowisk i urządzeń rehabilitacyjnych

- gabinetów

- zabiegów.

13.

System musi umożliwiać tworzenie blokad oraz komentarzy dla pojedynczych wizyt oraz dla całego dnia.

14.

System musi umożliwiać określenie standardowych czasów trwania zabiegów.

15.

System musi umożliwiać automatyczne planowanie na bazie dostępności osób i urządzeń.

16.

System musi umożliwiać korzystanie z kalendarza planowania z wizualizacją zajętych slotów na zabiegi przez innych pacjentów, blokady terminów.

17.

System musi umożliwiać drukowanie planu zabiegów.

18.

System musi umożliwiać wyszukanie pierwszego terminu wolnego jak i pozostałe terminy można wyszukać poprzez opcję „wyszukiwanie wolnych terminów”. Wpisując dzisiejszy lub dogodny termin wizyty system wyszukuje czy są wolne miejsca w celu jego rezerwacji dla pacjenta.

19.

System musi umożliwiać automatyczne planowania cykli umożliwiająca planowanie w zależności od potrzeb konkretnej jednostki.

20.

System musi umożliwiać ręczne planowanie zabiegów.

21.

System musi umożliwiać wydruk dziennej listy pacjentów.

22.

System musi umożliwiać wydruk dziennej listy cykli dla cykli rozpoczynających się w danym dniu.

23.

System musi umożliwiać przerwanie planowania na wybranym przez siebie etapie i powrócić do niego w dogodnym momencie.

24.

System musi umożliwiać automatyzację realizacji wizyty poprzez:

• realizację pozycji zlecenia za pomocą kodu kreskowego

• automatyczne dopisywanie do rozliczeń procedur (w tym procedur zależnych od parametrów zlecenia) oraz produktów podczas realizacji zabiegów.

25.

System musi umożliwiać zawężanie listy zabiegów do wykonania po co najmniej:

• zasobie

• zabiegu


• tylko zleceniach wewnętrznych

• odwołanych

• zakresie dat

• zakresie godzin.

26.

System musi umożliwiać odwołanie zabiegu z podaniem przyczyny odwołania.

27.

System musi umożliwiać przeglądanie stanu realizacji cyklu.

28.

System musi umożliwiać anulowanie wykonania.

29.

System musi umożliwiać sprawdzenie statusu eWuś.

30.

System musi umożliwiać automatyzację realizacji zabiegów poprzez co najmniej realizację pozycji zlecenia za pomocą kodu kreskowego bez potrzeby wybierania ręcznego pacjenta, zlecenia.

31.

System musi umożliwiać prowadzenie karty badania i realizacji zabiegów fizjoterapeutycznych wykonywanych u pacjenta.

32.

System musi umożliwiać generowanie elektronicznego zlecenia zabiegów rehabilitacyjnych z gabinetu poradni specjalistycznych oraz przesyłanie informacji zwrotnych z fizjoterapii do osoby wystawiającej zlecenie co do przeprowadzonego badania i kwalifikacji pacjenta do leczenia rehabilitacyjnego.

33.

System musi umożliwiać zlecenie wyrobów medycznych, zgodnie z przepisami wydanymi na podstawie art. 38 ust.

4 ustawy z dnia 12 maja 2011 r. o refundacji leków, środków spożywczych specjalnego przeznaczenia żywieniowego oraz wyrobów medycznych .

34.

System musi umożliwiać generowanie opinii i orzeczeń odnośnie do stanu funkcjonalnego osób poddawanych fizjoterapii oraz przebiegu procesu fizjoterapii;


7.1.1.28 Xxxxxxxxxxx x XXX


Lp.

Opis wymagania / punktacja

1.

System musi zapewniać pełną integrację i wymianę danych z pozostałymi modułami HIS. Automatyczne księgowanie się całej sprzedaży po stronie modułu Księgi Głównej z uwzględnieniem właściwych schematów księgowych oraz cech transakcji (wymiarów, np. MPK/OPK).

2.

System musi umożliwiać nanoszenia podstawowych danych kontrahentów:

1. nazwa i adres

2. NIP

3. REGON.

3.

System musi umożliwiać ewidencjonowanie umów zawartych z oddziałami NFZ.

4.

System musi umożliwiać generowanie dokumentów rozliczeniowych.

5.

System musi umożliwiać weryfikację kompletu danych niezbędnego do rozliczenia wizyt/pobytów pacjentów.

6.

System musi umożliwiać raportowanie braków w danych niezbędnych do rozliczenia świadczeń.

7.

System musi umożliwiać automatyczne przyporządkowywanie wizyt i pobytów pacjentów w szpitalu lub innej jednostce służby zdrowia do pozycji umów z płatnikami oraz przypisywanie im kwot refundacji zgodnie z wprowadzoną umową.

8.

System musi umożliwiać wystawienie faktur dla płatnika na podstawie dokumentów rozliczeniowych.

9.

System musi umożliwiać generowanie szeregu zestawień sprawozdawczych do NFZ, Centrum Zdrowia Publicznego, zgodnie z obowiązującymi przepisami oraz wewnętrznych raportów weryfikujących dane bez konieczności stosowania zewnętrznych programów, między innymi:

• zestawienie świadczeń za wybrany okres z możliwością weryfikacji definiowalnego kompletu danych rozliczeniowych

• zestawienie świadczeń rozliczonych w danym okresie, na podstawie wybranych umów

• zbiorcze zestawienia ilościowo - wartościowe za dany okres rozliczeniowy, na podstawie wybranych umów

• zestawienie wykonanych usług ponadplanowych

• zestawienie pacjentów nie wykazanych na dokumentach rozliczeniowych, wraz z powodem ich nie uwzględniania w rozliczeniach

• zestawienia pobytów pacjentów powtarzających się częściej niż zadany odstęp czasu

• generowanie sprawozdania do NFZ dot. liczby oczekujących i średniego czasu oczekiwania na świadczenia, oraz pierwszego wolnego terminu

• generowanie pełnej sprawozdawczości statystyczno-rozliczeniowej do NFZ.

10.

System musi umożliwiać korygowanie danych rozliczeniowych poprzez podniesienie wersji jednego świadczenia lub zestawu świadczeń oraz wielu w zakresie danych statystycznych i rozliczeniowych.

11.

System musi umożliwiać z poziomu Raport JGP łatwy i szybki wgląd w wyniki jednostki.

12.

System musi umożliwiać zintegrowanie Raportu JGP z Optymalizatorem JGP.

13.

System musi umożliwiać wyróżnienie miejsc, w których można dokonać korekty tak, aby uzyskać lepsze wyniki finansowe i medyczne pracy Szpitala.

14.

System musi umożliwiać zaimplementowanie algorytmu grupera (zgodnie z zapisami Zarządzenia Nr 33/2011/DSOZ Prezesa Narodowego Funduszu Zdrowia z dnia 6 lipca 2011 r. w sprawie określenia warunków zawierania i realizacji umów w rodzaju: leczenie szpitalne), który na etapie kodowania rozpoznań i procedur dotyczących danej hospitalizacji umożliwi:

- określenie grupy JGP z najwyższą taryfą na podstawie wprowadzonych danych wraz z określeniem listy grup alternatywnych JGP;

- określenie listy grup JGP odrzuconych wraz z podpowiedzią warunków kierunkowych koniecznych do spełnienia.

Wersja słownika procedur ICD9 oraz leków w programach lekowych musi być uaktualniana na bieżąco.

15.

System musi umożliwiać określenie grupy JGP bez konieczności komunikacji z NFZ natychmiast po wprowadzeniu niezbędnych danych wraz z prezentacją osobodni pacjenta w odniesieniu do liczby dni finansowanych grupą JGP oraz informacji o dostępnym limicie i o bieżącej realizacji umowy.

16.

System musi umożliwiać wprowadzanie rozliczeń JGP w oparciu o:

• przeglądarkę grup JGP (słownik zawiera wyróżnione grupy JGP, które mogą być rozliczone w poszczególnych produktach zakontraktowanych przez szpital zgodnie z poszczególnymi zakresami świadczeń (zgodnie z zgodnie z zarządzeniami Prezesa NFZ), albo wbudowanego grupera.

• odrębne słowniki katalogów świadczeń wskazane prze NFZ (słownik powinien mieć wyróżnione produkty, które mogą być rozliczone w poszczególnych oddziałach zakontraktowanych przez szpital zgodnie z poszczególnymi zakresami świadczeń (zgodnie z zarządzeniami Prezesa NFZ).

17.

System musi zapewniać zgodność z najnowszymi wytycznymi NFZ w sprawie grupowania (przeprowadzana na bieżąco implementacja zmian ogłaszanych przez NFZ).

18.

System musi umożliwiać dostęp do funkcjonalności optymalizatora i grupera w zakresie:

• wyznaczania grup JGP,

• wyznaczania ambulatoryjnych grup świadczeń specjalistycznych,

• wyznaczania grup w zakresach stacjonarnej rehabilitacji neurologicznej i kardiologicznej,

• obliczania ich wartości punktowych,

• przeprowadzania symulacji grupowania/optymalizacji opłacalności,

• licencji nieograniczonej do liczby stanowisk,

• sugerowania zmian w kodowaniu.

19.

System musi umożliwiać wyznaczanie JGP zgodnie z charakterystyką i algorytmem określonym przez NFZ na dany okres rozliczeniowy.

20.

System musi umożliwiać obsługę wyznaczania JGP dla danych z zakończonych okresów rozliczeniowych zgodnie z obowiązującą wtedy charakterystyką i algorytmem.

21.

System musi umożliwiać automatyczne pobieranie z Ruchu Chorych wszystkich dane niezbędnych do wyznaczenia JGP.

22.

System musi umożliwiać wyznaczanie wszystkich możliwych grup do jakich może zostać zakwalifikowana hospitalizacja zgodnie z zawartą umową z NFZ.

23.

System musi umożliwiać wyznaczanie wszystkich możliwych grup do jakich może zostać zakwalifikowana porada zgodnie z zawartą umową z NFZ.

24.

System musi umożliwiać wyliczanie dla każdej wyznaczonej grupy wartości punktowej niezbędnej do sprawozdawczości (taryfa podstawowa, dodatkowa, całkowita).

25.

System musi umożliwiać automatyczne podpowiadanie grupy do rozliczenia kierując się kryterium optymalizacji przychodu za wykonanie określonego rodzaju świadczenia i spełnienia warunku, że znajduje się w umowie.

26.

System musi umożliwiać zawężenie przeglądania JGP do zakontraktowanych z danym płatnikiem, w danej jednostce organizacyjnej.

27.

System musi umożliwiać automatyczne wyznaczanie także innych potencjalnych grup w przypadku alternatywnej kwalifikacji świadczenia z jawnym oznaczeniem grupy najbardziej intratnej.

28.

System musi umożliwiać wskazywanie dokładnie przyczyny braku możliwości zakwalifikowania świadczenia do bardziej intratnej grupy.

29.

System musi umożliwiać automatyczne porządkowanie (sortowanie) wyznaczone i potencjalne grupy wg kryterium łącznej wartości punktów.

30.

System musi umożliwiać przypisanie na podstawie wyznaczonej JGP produktu jednostkowego do rozliczenia w NFZ.

31.

System musi umożliwiać obsługę zleceń zamówienia na wyroby medyczne.

32.

System musi umożliwiać importowanie i eksportowanie karty udarowej do aplikacji NFZ.

33.

System musi umożliwiać rozliczanie programów lekowych oraz leczniczych.


7.1.1.29 Rozliczenia komercyjne


Lp.

Opis wymagania

1.

W zakresie obsługi pacjentów obsługiwanych poza umową z NFZ systemu powinien umożliwiać :

• wprowadzanie listy usług,

• wprowadzenie danych usługi:

o płatnika,

o wymagalność skierowania, usługa powinna mieć zdefiniowaną wymagalność skierowania lub też nie.

• wprowadzanie cenników:

o okres obowiązywania,

o godziny dostępności,

o możliwość definicji cenników standardowych i specjalnych,

o miejsca realizacji,

• wprowadzanie rabatów:

o rabaty ogólne do wykorzystania bez ograniczeń,

o rabaty prywatne – przyporządkowane do osoby,

2.

W zakresie obsługi pacjentów obsługiwanych poza umową z NFZ systemu powinien umożliwiać :

• obsługę skorowidza pacjentów,

• konstruowanie produktów:

o wprowadzanie danych podstawowych produktu,

o wprowadzanie zakresów usług medycznych w ramach produktu,

o wprowadzanie usług medycznych w ramach zakresu (poradnia, szpitalnictwo, diagnostyka),

3.

W zakresie obsługi pacjentów obsługiwanych poza umową z NFZ systemu powinien umożliwiać :

• wprowadzanie trybów i terminów płatności dla zakresów:

o abonament, (niezależnie od wykonanych usług),

o FFS (Fee For Service czyli za każde wykonanie usługi),

o współpłatność w ramach FFS,

o płatności mieszane,

o usługi nieodpłatne, (w pakiecie)

4.

W zakresie obsługi pacjentów obsługiwanych poza umową z NFZ systemu powinien umożliwiać :

• grupowanie zakresów usług,

• ewidencję i obsługę umów:

• obsługę umów na sprzedaż usług medycznych:

• umowy ubezpieczeniowe,

• umowy abonamentowe,

• umowy z innymi ZOZ-ami, Indywidualnymi Praktykami Lekarskimi, pacjentami zagranicznymi

• wprowadzanie danych podstawowych umowy,

• przypisywanie produktu do umowy,

• definiowanie rabatów dla umowy,

5.

W zakresie obsługi pacjentów obsługiwanych poza umową z NFZ systemu powinien umożliwiać :

• wprowadzanie list uprawnionych do grup zakresów:

• beneficjenci,

• tworzenie produktu dedykowanego dla umowy,

• definiowanie wzorów faktur i załączników do faktur dla umowy,

• mechanizm importu list uprawnionych pacjentów danego kontrahenta wraz z jego danymi, datą obowiązywania uprawnień oraz statusem,

• wydruk usług zawierających się w umowie, na potrzeby informacyjne

6.

W zakresie obsługi pacjentów obsługiwanych poza umową z NFZ systemu powinien umożliwiać :

• rozliczanie umów:

o generowanie harmonogramów płatności umowy w oparciu o dane zakresów umowy,

o generowanie danych do faktur i załączników do faktur płatnych abonamentowo w oparciu o zdefiniowany wzorzec i dane umowy,

o generowanie danych do faktur i załączników do faktur płatnych za wykonanie w oparciu o zdefiniowane wzorce i dane umowy oraz dane o wykonanych usługach.

o automatyczne księgowanie w FK wystawionych faktur.


7.1.1.30 Terminarz


Lp.

Opis wymagania

1.

System musi umożliwiać definiowanie grafików pracy (terminarzy) dla wskazanej osoby (personelu) w komórce, urządzenia, stanowiska, gabinetu, zwanych dalej zasobami.

2.

System musi umożliwiać generowanie grafików na podstawie wcześniej przygotowanych szablonów (np. definiujących dany grafik dla wszystkich dni tygodnia, utworzony ręcznie przez operatora lub określony na podstawie wybranego tygodnia, dla którego grafiki lub szablony określono wcześniej, wraz z definicją zastrzeżeń (rodzaju/treści blokady) godzin przyjęć w dniu) w taki sposób, aby w wyniku pojedynczej operacji możliwe było zdefiniowanie grafiku opcjonalnie na okres: roczny, półroczny, kwartalny, miesięczny, tygodniowy lub na dany dzień dla wybranego (opcjonalnie): personelu, gabinetu, komórki organizacyjnej, obiektu, całej przychodni.

3.

System musi umożliwiać generowanie szablonów tygodniowych, umożliwiających specyfikowanie grafiku pracy w wybrane dni tygodnia (w tym pracę np. w n-ty piątek miesiąca), a następnie umożliwia tworzenie na ich podstawie grafików zgodnie z wymaganiami określonymi wyżej.

4.

System musi umożliwiać generowanie zastrzeżeń (rodzaju/treści blokady) w ramach danego grafiku odnośnie dni i godzin przyjęć z możliwością dowolnego określenia przyczyny zastrzeżenia (np. urlop, zwolnienie lekarskie, termin do dyspozycji lekarza, wizyta komercyjna, cito itp.).

5.

System musi umożliwiać definiowanie lub korygowanie grafiku z pominięciem szablonu.

6.

System musi podczas generowania grafików automatycznie uwzględniać dni świąteczne i ustawowo wolne od pracy (funkcja: nie generuj grafiku na takie dni). Zamawiający dopuszcza konieczność wcześniejszego zdefiniowania

w programie przez administratora dni świątecznych "ruchomych".

7.

System musi umożliwiać prezentację stanu dostępności miejsc w grafiku, prezentując: czy w danym dniu są wolne miejsca, ile jest tych miejsc (z wykorzystaniem zobrazowania symbolicznego, liczbowego, kolorystyki).

8.

System musi umożliwiać prezentację (w postaci skrótów literowych, symboli i wyróżników kolorami) stan wprowadzenia informacji odnośnie wizyt i pacjentów, pokazując zarezerwowane wizyty w grafiku z informacją np. o tym, czy dana wizyta odbyła się, czy pacjent posiada skierowanie, status Ewuś, wpis do kolejki oczekujących.

9.

System musi umożliwiać planowanie i rezerwację terminów wizyt na dowolny okres w przód, w tym telefonicznie zgodnie z wprowadzonym grafikiem. W momencie rozpoczęcia nowej rezerwacji prezentować informację o najbliższym wolnym terminie do danej poradni, pracowni i zasobu oraz umożliwia domyślny wybór tego terminu.

10.

System musi umożliwiać zmianę terminu rezerwacji wizyty z ewidencją przyczyny zmiany na podstawie słownika bez konieczności ponownego rejestrowania pacjenta lub wizyty.

11.

System musi umożliwiać odwołanie terminu rezerwacji wizyty z ewidencją przyczyny odwołania na podstawie słownika z możliwością prezentacji terminów odwołanych.

Document Metadata

Filed: March 23rd, 2020