OPIS PRZEDMIOTU ZAMÓWIENIA

Transkrypt

1 ZAŁĄCZNIK NR 9.20.SSI DO SIWZ MAZOWIECKI SZPITAL WOJEWÓDZKI W SIEDLCACH SP. Z O.O. OPIS PRZEDMIOTU ZAMÓWIENIA W PROJEKCIE E-ZDROWIE DLA MAZOWSZA NA DOSTAWY I WDROŻENIE EDM, SSI Niniejszy załącznik składa się z 200 ponumerowanych stron Warszawa, dnia r. Strona 1 z 200

2 Spis treści Spis treści... 1 Rozdział I. Założenia początkowe oraz wymagania ogólne I.1 Wymogi dotyczące interoperacyjności lub migracji dla oferowanego SSI I.1.2 Wymagany stan docelowy:... 8 I.2 ZAKRES: WYMAGANIA OGÓLNE... 9 Rozdział II. Wymagana, dodatkowa funkcjonalnośd w przypadku rozbudowy istniejącego SSI o dodatkowe moduły II.1 ZAKRES: RUCH CHORYCH II.1.1 Moduł/grupa funkcjonalności: SOR Szpitalny Oddział Ratunkowy II.1.2 Moduł/grupa funkcjonalności: Blok operacyjny II.2 ZAKRES: PRZYCHODNIA II.2.1 Moduł/grupa funkcjonalności: Gabinet Medycyny Pracy II.3 ZAKRES: DOKUMENTACJA MEDYCZNA II.3.1 Moduł/grupa funkcjonalności: Archiwum papierowej dokumentacji medycznej II.4 ZAKRES: WSPÓLNE II.4.1 Moduł/grupa funkcjonalności: Pulpit użytkownika II.4.2 Moduł/grupa funkcjonalności: Wymiana danych z systemami zewnętrznymi II.4.3 Moduł/grupa funkcjonalności: Obsługa urządzeo mobilnych II.5 ZAKRES: SYSTEM INFORMACJI ZARZĄDCZEJ II.5.1 Moduł/grupa funkcjonalności: System informacji zarządczej II.6 ZAKRES: KLINICZNY SYSTEM INFORMATYCZNY II.6.1 Moduł/grupa funkcjonalności: Kliniczny System Informatyczny II.7 ZAKRES: MODUŁY DODATKOWE II.7.1 Moduł/grupa funkcjonalności: Wsparcie zarządzania systemem jakości II.7.2 Moduł/grupa funkcjonalności: Bank Krwi II.7.3 Moduł/grupa funkcjonalności: BHP ochrona radiologiczna II.7.4 Moduł/grupa funkcjonalności: BHP II.8 Oprogramowanie do zarządzania infrastrukturą Strona 2 z 200

3 II.8.1 Wymagania ogólne: II.8.2 Wymagana funkcjonalnośd systemu inwentaryzacji II.8.3 Z modułem inwentaryzacji sprzętu program musi umożliwiad prowadzenie bazy ewidencji majątku IT w zakresie: II.8.4 Inwentaryzacja oprogramowania musi zapewnid funkcjonalnośd w zakresie pozyskiwania informacji o oprogramowaniu i audycie licencji poprzez: II.8.5 W zakresie obsługi użytkowników system musi umożliwiad monitorowanie aktywności użytkowników pracujących na komputerach z systemem Windows poprzez analizę: II.8.6 W zakresie zarządzania prawami dostępu do urządzeo system musi umożliwiad: II.8.7 Audyt operacji na urządzeniach przenośnych wymagania: II.9 Oprogramowanie do zarządzania dokumentami (EOD) Rozdział III. Wymagana funkcjonalnośd SSI konieczna do zachowania w przypadku wymiany istniejącego oprogramowania na oprogramowanie równoważne o podanych kryteriach równoważności III.1 ZAKRES: RUCH CHORYCH III.1.1 Moduł/grupa funkcjonalności: SOR Szpitalny Oddział Ratunkowy III.1.2 Moduł/grupa funkcjonalności: Blok operacyjny III.1.3 Moduł/grupa funkcjonalności: Izba Przyjęd III.1.4 Moduł/grupa funkcjonalności: JGP III.1.5 Moduł/grupa funkcjonalności: Rozliczenia z NFZ III.1.6 Moduł/grupa funkcjonalności: Sprzedaż usług medycznych III.1.7 Moduł/grupa funkcjonalności: symulator JGP III.1.8 Moduł/grupa funkcjonalności: Oddział III.1.9 Moduł/grupa funkcjonalności: Rehabilitacja III.1.10 Moduł/grupa funkcjonalności: Statystyka medyczna III.2 ZAKRES: PRZYCHODNIA III.2.1 Moduł/grupa funkcjonalności: Gabinet Medycyny Pracy III.2.2 Moduł/grupa funkcjonalności: Deklaracje POZ III.2.3 Moduł/grupa funkcjonalności: Poradnia specjalistyczna III.2.4 Moduł/grupa funkcjonalności: Rehabilitacja Dzienna III.3 ZAKRES: LABORATORIUM III.3.1 Moduł/grupa funkcjonalności: Obsługa pobierania materiałów do badao III.4 ZAKRES: APTEKA III.4.1 Moduł/grupa funkcjonalności: Apteczka oddziałowa Strona 3 z 200

4 III.4.2 Moduł/grupa funkcjonalności: Apteka III.5 ZAKRES: PRACOWNIA DIAGNOSTYCZNA III.5.1 Moduł/grupa funkcjonalności: Pracownia diagnostyczna III.6 ZAKRES: DOKUMENTACJA MEDYCZNA III.6.1 Moduł/grupa funkcjonalności: Archiwum papierowej dokumentacji medycznej III.6.2 Moduł/grupa funkcjonalności: Dokumentacja medyczna III.7 ZAKRES: WSPÓLNE III.7.1 Moduł/grupa funkcjonalności: Pulpit użytkownika III.7.2 Moduł/grupa funkcjonalności: Wymiana danych z systemami zewnętrznymi III.7.3 Moduł/grupa funkcjonalności: Obsługa urządzeo mobilnych III.7.4 Moduł/grupa funkcjonalności: Wykazy, zestawiania III.7.5 Moduł/grupa funkcjonalności: Zakażenia szpitalne III.7.6 Moduł/grupa funkcjonalności: Zlecenia III.7.7 Moduł/grupa funkcjonalności: Kolejki oczekujących III.7.8 Moduł/grupa funkcjonalności: Szpitalny portal e-usług III.7.9 Moduł/grupa funkcjonalności: Administrator III.8 ZAKRES: KLINICZNY SYSTEM INFORMATYCZNY III.8.1 Moduł/grupa funkcjonalności: Kliniczny System Informatyczny III.9 ZAKRES: SYSTEM INFORMACJI ZARZĄDCZEJ III.9.1 Moduł/grupa funkcjonalności: System informacji zarządczej III.10 ZAKRES: MODUŁY DODATKOWE III.10.1 Moduł/grupa funkcjonalności: Wsparcie zarządzania systemem jakości III.10.2 Moduł/grupa funkcjonalności: Bank Krwi III.10.3 Moduł/grupa funkcjonalności: BHP ochrona radiologiczna III.10.4 Moduł/grupa funkcjonalności: BHP III.10.5 Moduł/grupa funkcjonalności: Transport Medyczny III.11 Oprogramowanie do zarządzania infrastrukturą III.11.1 Wymagania ogólne: III.11.2 Wymagana funkcjonalnośd systemu inwentaryzacji III.11.3 Z modułem inwentaryzacji sprzętu program musi umożliwiad prowadzenie bazy ewidencji majątku IT w zakresie: III.11.4 Inwentaryzacja oprogramowania musi zapewnid funkcjonalnośd w zakresie pozyskiwania informacji o oprogramowaniu i audycie licencji poprzez: Strona 4 z 200

5 III.11.5 W zakresie obsługi użytkowników system musi umożliwiad monitorowanie aktywności użytkowników pracujących na komputerach z systemem Windows poprzez analizę: 181 III.11.6 W zakresie zarządzania prawami dostępu do urządzeo system musi umożliwiad: III.11.7 Audyt operacji na urządzeniach przenośnych wymagania: III.12 Oprogramowanie do zarządzania dokumentami (EOD) Strona 5 z 200

6 Rozdział I. Założenia początkowe oraz wymagania ogólne. I.1 Wymogi dotyczące interoperacyjności lub migracji dla oferowanego SSI. I.1.1 Wykonawca zobowiązuje się dostarczyd Partnerowi Projektu wymagane funkcjonalności SSI, poprzez dostawę nowego rozwiązania lub zmodernizowanie i rozbudowanie istniejącego w taki sposób, aby w jak najszerszym zakresie zostały zaspokojone obecne i przyszłe potrzeby PP. 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 PP I.1.2 W przypadku dostarczenia nowego lub rozbudowy i zmodernizowania istniejącego systemu, Wykonawca zobowiązuje się zachowad (utrzymad status quo, odtworzyd) funkcjonalnie pełną, istniejącą obecnie integrację z systemami zewnętrznymi wskazanymi przez Partnera Projektu na etapie Analizy przedwdrożeniowej, które nie są przedmiotem wymiany lub rozbudowy w ramach Projektu. I.1.3 W przypadku, gdy wykonawca dokonuje rozbudowy systemu posiadanego przez Partnera przy użyciu produktu z innej linii produktowej (rozumianej jako produkt o innej nazwie handlowej lub innym zarejestrowanym znaku towarowym) wykonawca zobowiązany jest zaktualizowad wszystkie posiadane przez Partnera moduły systemu do ich najnowszej wersji z linii produktowej wdrażanej jako rozbudowa. I.1.4 Szpitalny System Informatyczny, stanowiący źródło Elektronicznej Dokumentacji Medycznej musi mied zaimplementowane i uruchomione mechanizmy integracji oraz zapewnid prawidłową integrację z lokalnym systemem EDM (REDM) będącym integralną częścią zamówienia, co najmniej poprzez zastosowanie interfejsu zgodnego ze standardem HL7 CDA Clinical Document Architecture, w wersji v.1 oraz v.2 I.1.5 Partner Projektu posiada zakupione licencje na moduły BHP, Blok Operacyjny, oraz Pulpit użytkownika, które nie są w chwili obecnej wdrożone. Wykonawca w przypadku wyboru opcji, rozbudowy SSI o dodatkowe moduły, zobowiązany jest wdrożyd wskazane wyżej oprogramowanie w ramach zadao wynikających z realizacji niniejszego Projektu. Strona 6 z 200

7 Stan bieżący posiadanych systemów. Partner Projektu posiada Zintegrowany Szpitalny System Informatyczny w części medycznej i administracyjnej Infomedica/AMMS firmy Asseco Poland S.A. System działa obecnie w oparciu o motor bazy danych Oracle. System szpitalny jest zintegrowany z Radiologicznym Systemem Informatycznym firmy Alteris, Laboratoryjnym Systemem Informatycznym firmy Marcel, Laboratoryjnym Systemem Informacyjnym e-lab firmy Diagnostyka oraz 2 analizatorami firmy Radiometer: ABL800 FLEX i AQT90 FLEX. Wykaz posiadanego oprogramowania: Lp. 1.1 Moduł 1.2 Typ licencji / ilośd 1. Finansowo-Księgowy Nieograniczona / 1 2. Rachunek Kosztów Nieograniczona / 1 3. Wycena Kosztów Normatywnych Świadczeo Nazwany Użytkownik / 4 4. Rejestr Sprzedaży Nieograniczona / 1 5. Kadry Nieograniczona / 1 6. Płace Nieograniczona / 1 7. Grafiki (Rejestracja Czasu Pracy) Nieograniczona / 1 8. Gospodarka Magazynowo-Materiałowa Nieograniczona / 1 9. Środki Trwałe z Elektroniczna Inwentaryzacją Nieograniczona / Wyposażenie z Elektroniczna Inwentaryzacją Nieograniczona / Zamówienia Publiczne Nazwany Użytkownik / Kasa Nazwany Użytkownik / Sprzedaż Usług Medycznych Nieograniczona / Apteka Szpitalna Nieograniczona / ADT Ruch Chorych (Izba Przyjęd, Oddział, Statystyka, Kontraktowanie) Lecznictwo Otwarte (Rejestracja, Gabinet Lekarski, Gabinet Zabiegowy, Pracownia Diagnostyczna, Rehabilitacja, Statystyka, Medycyna Pracy) Nieograniczona / 1 Nieograniczona / 1 Strona 7 z 200

8 17. Zlecenia Nieograniczona / Statystyka Zakażeo Szpitalnych Nazwany Użytkownik / Transport Sanitarny Nazwany Użytkownik / BHP Nazwany Użytkownik / Blok Operacyjny Nieograniczona / Pulpit użytkownika Nieograniczona / Punkt pobrao Nieograniczona / Apteczka Oddziałowa Nieograniczona / Dokumentacja Medyczna Nieograniczona / Gruper JGP Nieograniczona / Medyczny Portal Informacyjny (e-pacjent, e-kontrahent) Nieograniczona / 1 Szpitalny System Informatyczny komunikuje się również z Radiologicznym Systemem Informatycznym firmy Alteris, oraz Laboratoryjnym Systemem Informatycznym firmy e-lab firmy (Diagnostyka) oraz Bankiem Krwi wraz z Serologią firmy Marcel. I.1.6 Wymagany stan docelowy: Partner Projektu oczekuje rozbudowy obecnie użytkowanego Zintegrowanego Szpitalnego Systemu Informatycznego szpitala poprzez dostarczenie dodatkowych elementów wyszczególnionych w opisie przedmiotu zamówienia. Posiadane przez Partnera Projektu moduły systemu SSI należy dostosowad do możliwości prowadzenia EDM zgodnie z obowiązującymi przepisami. Jeśli dostosowanie będzie polegało na wymianie systemu HIS SSI to zakres funkcjonalny nowych modułów nie może byd mniejszy niż zakres funkcjonalny obecnie posiadanych modułów. Dostarczone oprogramowanie musi działad w oparciu o motor bazy danych Oracle i zapewnid pełną zgodnośd z eksploatowanym obecnie modelem bazy danych posiadanego oprogramowania SSI (HIS). Wykonawca ponosi wszelką odpowiedzialnośd za uwzględnienie obowiązujących przepisów prawnych i rozporządzeo na dzieo składania ofert, dotyczących wdrożenia w placówkach ochrony zdrowia Elektronicznej Dokumentacji Medycznej. Oferowany SSI musi posiadad realizowad wszystkie funkcjonalności przedstawione poniżej. Strona 8 z 200

9 I.2 ZAKRES: WYMAGANIA OGÓLNE I System jest zintegrowany, przez co rozumie się zintegrowaną pracę wszystkich jego podsystemów/modułów w oparciu o swobodną, automatyczną wymienialnośd danych pomiędzy nimi. I System ma interfejs graficzny dla wszystkich swoich podsystemów/modułów. I System, co najmniej w zakresie swoich podsystemów/modułów obejmujących: ruch chorych, aptekę centralną, apteczki oddziałowe, lecznictwo otwarte i rozliczenia NFZ powinien pracowad w oparciu o tę samą bazę danych, przez co należy rozumied tę samą instancję bazy danych i te same tabele bazy danych. Niedopuszczalne jest przekazywanie i dublowanie danych w zakresie w/w podsystemów/modułów. I W systemie musi zostad zachowana zasada jednokrotnego wprowadzania danych. Wymiana danych pomiędzy modułami musi odbywad się na poziomie bazy danych I Interfejs użytkownika jest dostępny z poziomu przeglądarki internetowej (co najmniej MS Internet Explorer, Mozilla Firefox, Google Chrome i Opera) i nie wymaga instalowania żadnego oprogramowania na stacjach klienckich. Dostęp do aplikacji przez WWW dotyczy co najmniej następujących podsystemów/modułów/grup funkcjonalności: izba przyjęd, oddział szpitalny, zlecenia, poradnia specjalistyczna I Aplikacja WWW musi posiadad zaufany certyfikat SSL wystawiony przez zaufany urząd certyfikacji. Dopuszcza się zastosowanie lokalnego urzędu certyfikacji. I Dane systemu przechowywane są w modelu relacyjnym baz danych z wykorzystaniem aktywnego serwera baz danych. I W podsystemach/modułach części medycznej systemu musi byd zapewniona praca w pełnej funkcjonalności na tabletach lub komputerach wyposażonych w monitory dotykowe. I System komunikuje się z użytkownikiem w języku polskim. Jest wyposażony w system podpowiedzi (help). W przypadku oprogramowania narzędziowego i administracyjnego serwera bazy danych dopuszcza się komunikację w języku angielskim. I W funkcjach związanych z wprowadzaniem danych system udostępnia podpowiedzi, automatyczne wypełnianie pól (np. automatyczne wprowadzenie kodu TERYT na podstawie nazwy miejscowości i/lub kodu pocztowego), szablony, słowniki grup danych (np. katalogi leków, procedur medycznych, jednostek chorobowych, danych osobowych czy danych terytorialnych). Strona 9 z 200

10 I W funkcjach związanych z wprowadzaniem danych w polach opisowych system SSI musi zapewniad funkcję sprawdzania pisowni. I System zapewnia odpornośd struktur danych (baz danych) na uszkodzenia oraz pozwala na szybkie odtworzenie ich zawartości i właściwego stanu, jak również łatwośd wykonania ich kopii bieżących. I Musi istnied możliwośd obsługi aplikacji wyłącznie przy użyciu klawiatury, bez konieczności używania myszki I W każdym oknie, gdzie możliwa jest edycja powinien znajdowad się klawisz <cofnij> lub <anuluj> powodujący powrót do poprzedniego okna bez zapisu danych I W każdym polu edycyjnym(opisowym) tj. np. treśd wywiadu powinna istnied możliwośd wybrania i skorzystania z dowolnego zdefiniowanego formularza, tekstu standardowego lub wczytania tekstu zapisanego w pliku zewnętrznym. Powinna również w tych miejscach istnied możliwośd zapisu wprowadzonego tekstu do zewnętrznego pliku oraz powinny byd udostępnione podstawowe narzędzia ułatwiające edycję np. kopiuj/wklej. I Wszystkie błędy niewypełnienia pól obligatoryjnych oraz niewłaściwego wypełnienia pól powinny byd prezentowane w jednym komunikacie z możliwością szybkiego przejścia do miejsc na formularzach w aplikacji, gdzie błędy te wystąpiły. I System umożliwia wykonanie nowej operacji wprowadzenia/edycji danych bez konieczności przerywania czynności dotychczas wykonywanej (np. obsługa zdarzenie w trybie nagłym) i powrót do zawieszonej czynności bez utraty danych, kontekstu itp. I System posiada mechanizm wyróżnienia wyświetlanych pól formularzy danych: I I I których wypełnienie jest obligatoryjne, przeznaczonych do edycji, wypełnionych niepoprawnie. I System jest wyposażony w zabezpieczenia przed nieautoryzowanym dostępem. Zabezpieczenia funkcjonują na poziomie klienta (aplikacja) i serwera (serwer baz danych). I Dane powinny byd chronione przed niepowołanym dostępem przy pomocy mechanizmu uprawnieo użytkowników. Każdy użytkownik systemu powinien mied odrębny login i hasło. Jakakolwiek funkcjonalnośd systemu (niezależnie od ilości funkcjonujących podsystemów/modułów) musi byd dostępna dla użytkownika dopiero po jego zalogowaniu. System uprawnieo powinien byd tak skonstruowany, aby można było użytkownikowi nadad uprawnienia z dokładnością do rodzaju wykonywanej operacji tj. osobne uprawnienie na odczyt danych Strona 10 z 200

11 i osobne na wprowadzanie/modyfikację danych. System uprawnieo powinien umożliwiad definiowanie grup uprawnieo, które mogłyby byd przydzielane poszczególnym użytkownikom. I W przypadku przechowywania haseł w bazie danych, hasła muszą byd zapamiętane w postaci niejawnej (zaszyfrowanej). I Musi istnied możliwośd nadawania użytkownikowi pojedynczych uprawnieo z listy dostępnych. System musi umożliwiad definiowanie grup użytkowników i przydzielanie użytkowników do tych grup. I Musi istnied możliwośd nadania użytkownikowi uprawnieo do pracy wyłącznie w kontekście wybranej/wybranych jednostek organizacyjnych. Np. tylko oddział wewnętrzny lub gabinet POZ i izba przyjęd. I System musi umożliwid zmianę jednostki organizacyjnej, w kontekście której pracuje użytkownik bez konieczności wylogowywania się z systemu. I System powinien umożliwiad nadawanie uprawnieo użytkownikom do jednostek organizacyjnych w których pracują, np. lekarz pracujący na izbie przyjęd i oddziale wewnętrznym powinien w swoich aplikacjach widzied tylko pacjentów izby przyjęd i tego jednego oddziału. I System musi tworzyd i utrzymywad log systemowy, w którym rejestrowane są wykonane przez wszystkich użytkowników systemu najważniejsze czynności (zalogowanie do systemu, wylogowanie z systemu, modyfikacja zawartości pól rekordów z możliwością analizy historii zmienianych wartości danych). I System powinien automatycznie wylogowywad lub blokowad sesję użytkownika po zadanym czasie braku aktywności, który definiowany jest w konfiguracji systemu. I Co najmniej w części medycznej systemu użytkownik po zalogowaniu powinien widzied pulpit zawierający tylko te funkcje i moduły, które są dostępne dla tego użytkownika. I System powinien umożliwiad obsługę procesów biznesowych realizowanych w szpitalu tzn. powinien: I pokazywad tylko to, co w danym momencie jest najważniejsze, I udostępniad tylko te zadania, które na danym etapie powinny zostad wykonane, I niezbędne, I umożliwid wprowadzenie tylko tych danych, które są podpowiadad kolejne kroki procesu. Strona 11 z 200

12 I System musi posiadad mechanizmy przesyłania i odbierania komunikatów tekstowych do poszczególnych użytkowników i ich grup. I System musi posiadad mechanizm powiadomieo generowanych automatycznie w związku ze śledzeniem stanów określonych obiektów (np. zlecenie, pacjent), zmianą lub brakiem zmiany stanu w czasie. I System musi umożliwiad automatyczne wprowadzenie danych pacjenta co najmniej z dowodu osobistego przy wykorzystaniu czytnika (skanera) dokumentów (funkcjonalnośd wykorzystywana podczas obsługi przyjęcia pacjenta w izbie przyjęd, rejestracji poradni, rejestracji pracowni, itp.) I System musi umożliwiad przekazywanie wyników sprawozdao i analiz w postaci elektronicznej. System przygotowuje wyniki sprawozdao i analiz w postaci plików co najmniej w formatach CSV lub HTML lub XML. I System musi korzystad z zewnętrznych słowników, które są zaimplementowane w wersji instalacyjnej systemu i aktualizowane (w przypadku zmiany ich zawartości) w ramach dostarczania nowych wersji systemu (m.in. Słownik Kodów Resortowych, Klasyfikacja Zawodów, Słownik Kodów Tytułów Ubezpieczenia ZUS, Klasyfikacja Środków Trwałych) oraz daje możliwośd korzystania ze słowników wewnętrznych (np. słownik ośrodków powstawania kosztów) porządkujących powtarzalne dane w ramach systemu. I Musi istnied możliwośd zarządzania słownikami (wprowadzanie/modyfikacja/usuwanie) z poziomu administratora SSI. I System posiada możliwośd dynamicznego definiowania widoków słowników z użyciem mechanizmów filtrowania i sortowania danych. I System posiada możliwośd definiowania szablonów dokumentów wykorzystywanych w jednostce Rozdział II. Wymagana, dodatkowa funkcjonalnośd w przypadku rozbudowy istniejącego SSI o dodatkowe moduły. SSI Wymagania funkcjonalne w podziale moduły/grupy funkcjonalności związane z gromadzeniem danych Medycznych Strona 12 z 200

13 II.1 ZAKRES: RUCH CHORYCH II.1.1 Moduł/grupa funkcjonalności: SOR Szpitalny Oddział Ratunkowy II Współpraca z modułem/grupą funkcjonalności: Izba Przyjęd w zakresie możliwości rejestracji pacjentów. II Obsługa skorowidza pacjentów, wspólnego dla pozostałych modułów/grup funkcjonalności medycznej części systemu. II Podział SOR na obszary jest opcjonalny. II Dla jednostek organizacyjnych typu SOR włączenie obsługi i prezentacji statusu pilności pacjentów wg obowiązujących przepisów. II Przypisanie lub zmianę statusu pilności pacjenta w dowolnym momencie pobytu na SOR. II Oznaczanie statusu pilności (jeśli jest włączone) pacjenta powinno byd wymagane i status ten powinien byd 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. II Przypisanie i zmiana statusu pilności pacjenta musi byd zapisane w dzienniku systemu, przy czym nie jest wymagane zapisanie powodu zamiany, ani autoryzacja zmiany. II Na panelu głównym pulpitu SOR oraz na liście pacjentów system powinien prezentowad liczbę pacjentów SOR w podziale na statusy pilności. Przypisanie i zmiana statusu pilności powinna wymusid aktualizację statystyk liczb pacjentów w podziale na statusy. II Przypisanie i zmiana statusu pilności powinna wymusid aktualizację statystyk liczb pacjentów w podziale na statusy. II Zdefiniowanie standardów czasowych obsługi pacjenta "czerwonego", "żółtego", pomaraoczowego, niebieskiego i zielonego. II Prezentowanie na panelu głównym pulpitu SOR oraz na liście pacjentów SOR czas oczekiwania liczony wg wzoru: czas_oczekiwania = liczba_czerwonych * czas_czerwonych + liczba_żółtych * czas_żółtych. II Przeniesienie awaryjne na oddział: system musi udostępnid funkcjonalnośd szybkiego skierowania pacjenta na oddział nawet w sytuacji, gdy nie wypełniono w systemie wszystkich danych (w tym wymaganych do zakooczenia pobytu na SOR), danych i dokumentów dokumentacji medycznej, wymaganej autoryzacji danych, pacjenci przeniesieni na oddział w trybie awaryjnym powinni byd oznaczeni na liście pacjentów SOR, dane pacjentów przeniesionych awaryjnie do innej jednostki organizacyjnej mogą byd uzupełnione w dowolnym momencie, ale nie uzupełnienie przez SOR wymaganych danych powinno blokowad Strona 13 z 200

14 wypis lub przeniesienie pacjenta z jednostki do której został w trybie awaryjnym skierowany. System musi wspierad tworzenie wymaganej dla SOR dokumentacji medycznej. II Wyświetlanie listy pacjentów przebywających na SOR w zadanym przedziale czasu, których status potwierdzenia płatnika jest ustawiony na "Oświadczenie". II System powinien umożliwiad rozliczenie komercyjne pacjentów nieuprawnionych do świadczeo. Wymaganie będzie realizowane w ramach rozliczeo komercyjnych lecznictwa zamkniętego. II Zaawansowane wyszukiwanie pacjenta: system powinien udostępniad 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 rodowe, miejscowośd zamieszkania, opis pacjenta NN, system powinien umożliwiad przeszukiwanie również poprzednich wersji danych osobowych oraz danych pacjentów scalonych z innymi pacjentami, wyszukiwanie zaawansowane musi się dad przerwad, złożone kryteria wyszukiwania - wypełnione więcej niż jedno pole ze złożonymi kryteriami, powinno wyświetlad ostrzeżenie, że operacja może byd długotrwała, wyszukiwanie zaawansowane powinno byd opcją (odrębny przycisk) wyszukiwania pacjentów w rejestrze pacjentów. II.1.2 Moduł/grupa funkcjonalności: Blok operacyjny II Dostęp do listy pacjentów skierowanych do Bloku operacyjnego przez oddział lub izbę przyjęd: II II II wyszukiwanie pacjentów w skorowidzu wg różnych parametrów, II II modyfikacja danych pacjentów, Przegląd danych archiwalnych pacjenta: w zakresie danych osobowych, II w zakresie danych z poszczególnych pobytów szpitalnych, a systemie zintegrowanym także w zakresie wizyt w Zakładzie diagnostycznym i wyników badao i wizyt w przychodni. II Planowanie zabiegów operacyjnych: rezerwacja sali operacyjnej, II określenie personelu uczestniczącego w zabiegu (chirurgicznego i anestezjologicznego) z wykorzystaniem słownika personelu, Strona 14 z 200

15 II II planowanie wykonania procedur, wykorzystania materiałów i leków w czasie zabiegu, II planowanie zabiegów wielonarządowych (wielourazowych) II dniu, przegląd listy zabiegów zaplanowanych w danym II podpowiadanie przez system, po wybraniu zabiegu do wykonania, niezbędnych: materiałów, procedur uzupełniających, zestawów narzędzi, II zabiegów, możliwośd wykorzystania terminarza do ustalania dat Kwalifikowanie pacjenta do wykonania zabiegu, II Planowanie zabiegów w oparciu o terminarze sal operacyjnych, II II II II II II II II Ewidencja elementów zabiegu operacyjnego: wykonane procedury, podane leki, zużyte materiały, personel wykonujący II możliwośd kopiowania danych z planu zabiegu do wykonania z możliwością wprowadzenia modyfikacji II automatyczne tworzenie opisów zabiegu na podstawie zarejestrowanych danych temat: wykonanych procedur, wykorzystanych materiałów, składu zespołu operacyjnego, incydentów itp. II II II II II II II II II Prowadzenie Księgi Bloku Operacyjnego, Opis wykonanych czynności anestezjologicznych: zastosowane znieczulenie, w tym sedacja, czas anestezjologiczny, czas znieczulenia, stan pooperacyjny, podane leki, wykonane procedury Prowadzenie dokumentacji zabiegu operacyjnego, w tym: karty zabiegowej pacjenta, protokołów pielęgniarskich, protokołów anestezjologicznych, karty bilansu płynów, Strona 15 z 200

16 II II II II możliwośd uzupełniania dokumentacji o materiały elektroniczne. Zapisywanie w systemie plików zawierających zapisy z urządzeo, skanów dokumentów, zdjęd cyfrowych itp. Integracja z innymi modułami systemu medycznego: II współpraca z modułem/grupą funkcjonalności apteczka oddziałowa w zakresie ewidencji zużytych leków i materiałów oraz automatycznej aktualizacji stanów magazynowych, II współpraca z pozostałymi podsystemami medycznymi w zakresie wzajemnego udostępniania danych o zlecenia i jego wykonaniu, II współpraca z modułem/grupą funkcjonalności Dokumentacji medycznej w zakresie wykorzystania formularzy zaprojektowanych przez użytkownika, II współpraca z modułem/grupą funkcjonalności Zleceo, Zakażeo Szpitalnych, II eksport danych statystycznych oraz ilościowych o wykonanych świadczeniach do pliku tekstowego II Możliwośd definiowania własnych szablonów wydruków, Możliwośd wykorzystania standardowych raportów, np.: rozchody materiałowe wg rodzaju kosztów, II czas personelu uczestniczącego w operacji z podziałem na operacje, II czas operacji wg jednostek zlecających. II Możliwośd definiowania własnych wykazów. II Definiowanie listy zdarzeo medycznych / elementów leczenia dla miejsca wykonania, II.2 ZAKRES: PRZYCHODNIA II.2.1 Moduł/grupa funkcjonalności: Gabinet Medycyny Pracy II definiowanie dostępności usług placówki medycznej Partnera Projektu: II wprowadzanie cenników: II określanie dat obowiązywania cennika, II określanie zakresu usług dla cennika, II określanie cen usług, II możliwośd określenia cen widełkowych dla usługi, Strona 16 z 200

17 II II II możliwośd powiązania cennika z kategorią osobową wykonującego, II z dołu ), określenie sposobu płatności (zezwolenie na płatnośd II możliwośd określenia zaliczki wymaganej przed wykonaniem usługi. określanie dostępności zasobów w placówce (grafiki): II definiowanie szablonu pracy zasobu typu gabinet : II II II określenie dni tygodnia, określenie czasu pracy gabinetu, określenie zakresu usług realizowanych w gabinecie II określanie ograniczeo grafika dla instytucji kierującej (płatnika), jednostki zlecającej Partnera Projektu (Oddziału/Izby Przyjęd), ilości wykonywanych usług II II II definiowanie szablonu pracy zasobu typu lekarz: określenie dni tygodnia, określenie czasu pracy, II określenie zakresu usług realizowanych przez lekarza w ramach umów, II określenie gabinetu, w którym wykonywane są usługi (miejsce wykonania). II generacja grafików dla lekarzy w powiązaniu z gabinetami w zadanym okresie czasu, II blokada grafików (urlopy, remonty). obsługa skorowidza pacjentów II możliwośd zastosowania kart identyfikacyjnych do wyszukania pacjenta II generowanie zleceo wymaganych badao i konsultacji na podstawie karty narażeo stanowiska pracy dla umów Medycyny Pracy II planowanie i rezerwacja wizyty pacjenta: II wyszukiwanie wolnych terminów jednoczesnej dostępności wymaganych zasobów: II rezerwacja wybranego terminu lub pierwszy wolny. II prezentowanie preferowanych terminów wykonania usługi dla zgłoszeo internetowych np. pacjenci rejestrowani przez Internet od II automatyczna rezerwacja terminów dla zgłoszeo internetowych wg preferencji pacjenta Strona 17 z 200

18 II II II w przypadku braku wolnych terminów w preferowanych godzinach możliwośd rezerwacji pierwszy wolny lub ręczny wybór terminu II wstawianie terminu pomiędzy już istniejące wpisy w grafiku w przypadkach nagłych przegląd rezerwacji rejestracja pacjenta do wykonania usługi: II weryfikacja uprawnieo z tytułu umów zarejestrowanych w module Sprzedaż usług medycznych: II przegląd udostępnionych danych umowy, II informacje o powodzie niedostępności usługi i ograniczeniach dostępności, II informacje o dostępności usług poza strukturami jednostki (podwykonawcy). II określenie miejsca wykonania usługi (wybór gabinetu) dla usług nie podlegających planowaniu i rezerwacji. II zlecenie wykonania usługi pacjentowi we wskazanym (lub wynikającym z rezerwacji) miejscu wykonania, II II II II II możliwośd wykorzystania szablonów zleceo złożonych, obsługa wyników: odnotowanie wydania wyniku, wpisywanie wyników zewnętrznych. obsługa Indywidualnego Konta Pacjenta (IKP): II prowadzenie kont rozrachunkowych pacjentów z tytułu usług medycznych, II wystawienie faktur i faktur korygujących, II możliwośd skojarzenia faktury ze schematem księgowania w module Finanse Księgowośd, II II na IKP), II II II eksport faktury do modułu Rejestr Sprzedaży, przyjęcie płatności (gotówka, karta płatnicza, środki pacjenta wypłata gotówki z tytułu nadpłat i korekt. obsługa stanowiska kasowego: obsługa operacji kasowych dla pacjentów (IKP), II obsługa operacji kasowych dla kontrahentów (dostęp do kartoteki kontrahentów modułu Finanse - księgowośd), II obsługa operacji kasowych dla pracowników (dostęp do kartoteki pracowników modułu Finanse Księgowośd), Strona 18 z 200

19 II prowadzenie raportu kasowego, II możliwośd skojarzenia z każdym typem operacji kasowej schematu księgowania w module Finanse-Księgowośd, II wprowadzanie umowy indywidualnej (polisy) na świadczenie usług medycznych wg szablonu. II II raporty i wykazy Rejestracji. dostęp do listy pacjentów zarejestrowanych do gabinetu II rejestracja rozpoczęcia obsługi wizyty pacjenta w gabinecie (przyjęcie) II Pracy II II II II dokumentacja badao profilaktycznych z zakresu Medycyny orzecznictwo Medycyny Pracy wspomaganie obsługi pacjenta w gabinecie: przegląd danych pacjenta w następujących kategoriach: dane osobowe, II podstawowe dane medyczne (grupa krwi, uczulenia, stale podawane leki, przebyte choroby, karta szczepieo), II uprawnienia z tytułu umów, II Historia Choroby (dane ze wszystkich wizyt pacjenta), II II II z umowy), wyniki badao, przegląd rezerwacji. wykluczenia (rozpoznania ograniczające uprawnienia II możliwośd użytkowania zdefiniowanych wcześniej wzorców dokumentacji dedykowanej do wizyty (w zależności od kategorii medycznej wizyty), II przegląd, wprowadzanie i modyfikacja danych wizyty w następujących kategoriach: II II wizyty), II II II wywiad (na formularzu zdefiniowanym dla wizyty), opis badania (na formularzu zdefiniowanym dla informacje ze skierowania, skierowania, zlecenia, planowanie i rezerwacja zleceo z wizyty, II możliwośd wykorzystania szablonów zleceo złożonych, II II usługi, świadczenia w ramach wizyty, zalecenia z wizyty (w tym zwolnienia lekarskie), Strona 19 z 200

20 II II wystawione skierowania, zlecenia szczepieo, II inne dokumenty (zaświadczenia, druki, na formularzach zdefiniowanych dla wizyty). II możliwośd stosowania słownika tekstów standardowych do opis danych wizyt II możliwośd stosowania pozycji preferowanych dla użytkowników, jednostek organizacyjnych (wyróżnienie najczęściej wykorzystywanych pozycji słowników). II II II II II II II II II II recepcji, możliwośd wykonywania usług dodatkowych podczas wizyty: weryfikacja uprawnieo pacjenta, obsługa Indywidualnego Konta Pacjenta (IKP) jak w II obsługa stanowiska kasowego (jak w Rejestracji/Recepcji). definiowanie własnych formularzy dokumentacji medycznej obsługa zakooczenia wizyty: autoryzacja medyczna wizyty, automatyczne tworzenie karty wizyty. kwalifikacja rozliczeniowa usług i świadczeo. automatyczna generacja i przegląd Księgi Gabinetu raporty i wykazy Gabinetu II.3 ZAKRES: DOKUMENTACJA MEDYCZNA II.3.1 Moduł/grupa funkcjonalności: Archiwum papierowej dokumentacji medycznej II Moduł przygotowany z wykorzystaniem technologii trójwarstwowej. II Podstawowe funkcje dostępne w ramach modułu/grupy funkcjonalności to: II rejestrowanie kartotek pacjentów lub kartotek zbiorczej dokumentacji medycznej. II wydruk nalepek na woluminy i dokumenty źródłowe zawierających kod paskowy pozwalający na jednoznaczną identyfikację dokumentu. II rejestracja informacji o zagubieniu, zniszczeniu i odzyskaniu zagubionej dokumentacji Strona 20 z 200