OPIS PRZEDMIOTU ZAMÓWIENIA

Transkrypt

1 ZAŁĄCZNIK NR 9.8.SSI DO SIWZ SAMODZIELNY SPECJALISTYCZNY ZESPÓŁ ZAKŁADÓW OPIEKI ZDROWOTNEJ IM. DR TEODORA DUNINA W RUDCE OPIS PRZEDMIOTU ZAMÓWIENIA W PROJEKCIE E-ZDROWIE DLA MAZOWSZA NA DOSTAWY I WDROŻENIE EDM, SSI Niniejszy załącznik składa się z 117 ponumerowanych stron Warszawa, dnia r. Strona 1 z 117

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.4 Wymagany stan docelowy:... 7 I.2 ZAKRES: WYMAGANIA OGÓLNE... 7 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: Opieka długoterminowa II.1.2 Moduł/grupa funkcjonalności: Rehabilitacja II.1.3 Moduł/grupa funkcjonalności: symulator JGP II.2 ZAKRES: PRZYCHODNIA II.2.1 Moduł/grupa funkcjonalności: Rehabilitacja Dzienna II.3 ZAKRES: PRACOWNIA DIAGNOSTYCZNA II.3.1 Moduł/grupa funkcjonalności: Pracownia diagnostyczna II.4 ZAKRES: DOKUMENTACJA MEDYCZNA II.4.1 Moduł/grupa funkcjonalności: Dokumentacja medyczna II.5 ZAKRES: WSPÓLNE II.5.1 Moduł/grupa funkcjonalności: Pulpit użytkownika II.5.2 Moduł/grupa funkcjonalności: Wykazy, zestawiania II.5.3 Moduł/grupa funkcjonalności: Zakażenia szpitalne II.5.4 Moduł/grupa funkcjonalności: Obsługa urządzeo mobilnych II.5.5 Moduł/grupa funkcjonalności: Wymiana danych z systemami zewnętrznymi II.5.6 Moduł/grupa funkcjonalności: Szpitalny portal e-usług II.6 ZAKRES: MODUŁY DODATKOWE II.6.1 Moduł/grupa funkcjonalności: Wsparcie zarządzania systemem jakości 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: Rehabilitacja III.1.2 Moduł/grupa funkcjonalności: symulator JGP Strona 2 z 117

3 III.1.3 Moduł/grupa funkcjonalności: JGP III.1.4 Moduł/grupa funkcjonalności: Rozliczenia z NFZ III.1.5 Moduł/grupa funkcjonalności: Sprzedaż usług medycznych III.1.6 Moduł/grupa funkcjonalności: Izba Przyjęd III.1.7 Moduł/grupa funkcjonalności: Opieka długoterminowa III.1.8 Moduł/grupa funkcjonalności: Oddział III.1.9 Moduł/grupa funkcjonalności: Statystyka medyczna III.2 ZAKRES: PRZYCHODNIA III.2.1 Moduł/grupa funkcjonalności: Rehabilitacja Dzienna III.2.2 Moduł/grupa funkcjonalności: Deklaracje POZ III.2.3 Moduł/grupa funkcjonalności: Poradnia specjalistyczna III.3 ZAKRES: LABORATORIUM III.3.1 Moduł/grupa funkcjonalności: Laboratorium analityczne i mikrobiologiczne III.3.2 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 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: Dokumentacja medyczna III.7 ZAKRES: WSPÓLNE III.7.1 Moduł/grupa funkcjonalności: Pulpit użytkownika III.7.2 Moduł/grupa funkcjonalności: Wykazy, zestawiania III.7.3 Moduł/grupa funkcjonalności: Zakażenia szpitalne III.7.4 Moduł/grupa funkcjonalności: Obsługa urządzeo mobilnych III.7.5 Moduł/grupa funkcjonalności: Szpitalny portal e-usług III.7.6 Moduł/grupa funkcjonalności: Wymiana danych z systemami zewnętrznymi III.7.7 Moduł/grupa funkcjonalności: Zlecenia III.7.8 Moduł/grupa funkcjonalności: Identyfikacja pacjenta III.7.9 Moduł/grupa funkcjonalności: Kolejki oczekujących III.7.10 Moduł/grupa funkcjonalności: Administrator III.7.11 Moduł/grupa funkcjonalności: Wymiana danych z systemami zewnętrznymi Strona 3 z 117

4 III.8 ZAKRES: MODUŁY DODATKOWE III.8.1 Moduł/grupa funkcjonalności: Wsparcie zarządzania systemem jakości Strona 4 z 117

5 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 Strona 5 z 117

6 Stan bieżący posiadanych systemów. Obecnie szpital posiada w części medycznej w szerokim zakresie wdrożony Szpitalny System Informatyczny Hipokrates PLUS firmy Asseco Poland SA, który zasięgiem działania obejmuje prawie wszystkie medyczne i administracyjne komórki organizacyjne Szpitala. System szpitalny jest zintegrowany z Radiologicznym Systemem Informatycznym Orion firmy TMS Soft, System Hipokrates obejmuje również obsługę laboratorium szpitalnego. Wykaz posiadanego oprogramowania: Pakiet Finanse księgowość Rachunek Kosztów Moduł Ilość licencji posiadanych i aktywnych Finanse-Księgowość 4 Rejestr Sprzedaży 2 Kasa 1 Wycena Kosztów Normatywnych Świadczeń 1 Koszty 1 Budżetowanie Controlling Budżetowanie 1 Zarządzanie obrotem leków i materiałów Gospodarka Materiałowa 1 Gospodarka majątkiem trwałym Obsługa kadr i wynagrodzeń Środki Trwałe 1 Wyposażenie 1 Kadry 2 Płace 2 Ewidencja Czasu Pracy (Grafik) 2 Lp. Nazwa Funkcjonalność Modułu ilość posiadanych licencji 1 Administrator systemu 1 5 Izba przyjęć 2 6 Oddział 20 7 Statystyka szpitalna 2 8 Moduł Dokumentacji Medycznej 1 OPEN 9 Moduł (RNFZ) - Aplikacja rozliczeniowa dla formatu otwartego 3 Aplikacja rozliczeniowa OF - księgi oczekujących + 11 Rozlicznie kontraktów 2 12 Apteka 2 Wydruk zestawienia obrotu leków grup II-N,III-P,IV-P,I-R + Zawieranie umów na dostawy leków i kontrola realizacji umów + Tworzenie korekt wartościowych + 13 Zamawianie leków/materiałów medycznych 2 14 Apteczka oddziałowa 8 Strona 6 z 117

7 Zlecenia apteczne + 15 Zlecenia oddziałowe Statystyka laboratoryjna 17 Laboratorium: Rejestracja/Pracownia 4 18 Laboratorium: Pracownia Bakteriologii 3 19 Obsługa Aparatu Laboratoryjnego Micros60 1 EOS2300 (POINTE 2000) 1 Easy Electrolytes 1 Clinitec STATUS 1 Koagulometr CC Cobas b121 (chodzi na licencji b221) 1 MiniVidas Blue 1 BC BD Bactek MGIT Przychodnia - Rejestracja główna 2 23 Przychodnia - Statystyka 24 Przychodnia: Gabinet lekarski 6 podstawowy +(6) 30 Rachunek kosztów leczenia 1 31 Wymiana danych finansowych 1 Statystyki dla kluczy podziału + 33 Wymiana danych z zewnętrznym systemem obsługi pracowni diagnostycznych 1 Szpitalny System Informatyczny komunikuje się również z Radiologicznym Systemem Informatycznym Orion firmy TMS Soft. I.1.5 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. 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). Oferowany SSI musi posiadad realizowad wszystkie funkcjonalności przedstawione poniżej. 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. Strona 7 z 117

8 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 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). 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 Strona 8 z 117

9 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 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). Strona 9 z 117

10 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. 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. I System musi posiadad mechanizmy przesyłania i odbierania komunikatów tekstowych do poszczególnych użytkowników i ich grup. Strona 10 z 117

11 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 Strona 11 z 117

12 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 II.1 ZAKRES: RUCH CHORYCH II.1.1 Moduł/grupa funkcjonalności: Opieka długoterminowa II System umożliwia prowadzenie wizyt i pobytów pacjentów objętych opieką długoterminową. II System umożliwia zarejestrowanie rozpoczęcia opieki długoterminowej jak i rejestrację poszczególnych pobytów będących sprawozdaniem do NFZ z wykonanych czynności w postacie procedur ICD-10 i ICD-9 II Wszystkie wizyty oraz pobyty prowadzone w ramach opieki długoterminowej prowadzone są w trybie pobytów ambulatoryjnych, a do ich utworzenia nie jest konieczne tworzenie grafików dla poszczególnych lekarzy przypisanych do danej opieki. II W przypadku wprowadzenia kolejnych wizyt w ramach opieki długoterminowej oprogramowanie przenosi i wiąże z wizyty dane dotyczące rozpoznao ICD-10 i skierowania na opiekę. II W ramach opieki długoterminowej aplikacja umożliwia rejestrowanie poszczególnych pobytów będących sprawozdaniem z danego okresu leczenia. II Informowanie o konfliktach realizacja świadczenia długoterminowego podczas udzielania świadczenia innego typu. II.1.2 Moduł/grupa funkcjonalności: Rehabilitacja II Rejestracja/przyjęcie pacjenta na podstawie skierowania, II Definiowanie listy zdarzeo medycznych / elementów leczenia dla miejsca wykonania, II Prowadzenie klasyfikacji warunków wykonywania rehabilitacji: II rehabilitacja ambulatoryjna, Strona 12 z 117

13 II II rehabilitacja oddziału dziennego, rehabilitacja stacjonarna. II Obsługa skorowidza pacjentów, wspólnego dla pozostałych modułów/grup funkcjonalności medycznej części systemu II Wyszukiwanie pacjentów w skorowidzu wg różnych parametrów, co najmniej: imię i nazwisko, nazwisko rodowe, nazwisko poprzednie, PESEL, data urodzenia, PESEL opiekuna, II Rejestracja i modyfikacja danych osobowych pacjentów, II Ewidencja zmian danych osobowych i daty od kiedy obowiązują nowe dane (np. zmiana miejsca zamieszkania, zmiana nazwiska, itp.), II Możliwośd zastosowania kart identyfikacyjnych do wyszukania pacjenta w systemie, II Zarządzanie słownikami stanowisk i urządzeo rehabilitacyjnych, II Zarządzanie grafikami i terminarzami: II II II personelu, pomieszczeo, stanowisk i urządzeo rehabilitacyjnych, II Możliwośd określenia warunków dostępności świadczeo poprzez przypisanie odpowiednich kategorii zasobów typu: II II II personel, pomieszczenie, stanowisko rehabilitacyjne, II Możliwośd określenia standardowych czasów trwania wizyty/porady pierwszorazowej i kontrolnej, II Możliwośd automatycznego nadawania priorytetu pilności dla wizyty pacjenta na podstawie danych z rozpoznania ze skierowania, II Możliwośd przypisania lekarza prowadzącego i terapeuty prowadzącego II Planowanie elementów programu rehabilitacyjnego w terminarzach terapeutów, pomieszczeo, stanowisk rehabilitacyjnych i w karcie zabiegowej pacjenta z uwzględnieniem preferencji pacjenta, II II Wprowadzenie i obsługa programu rehabilitacji dla pacjenta, Możliwośd drukowania planu zabiegów, Strona 13 z 117

14 II Możliwośd anulowania całego programu lub wybranych jego elementów lub niezrealizowanych zabiegów z jednoczesnym anulowaniem rezerwacji zasobów ( tj. personel, pomieszczenia, stanowiska rehabilitacyjne) II Możliwośd obsługi porady/wizyty uprzednio zaplanowanej lub z pominięciem planowania, II Możliwośd definiowania własnych formularzy dokumentacji medycznej, II Obsługa indywidualnej dokumentacji medycznej dla pacjenta, II Możliwośd stosowania tekstów standardowych do opisu porad/wizyt, II Możliwośd wprowadzanie zleceo (diagnostyka, laboratorium), skierowao, recept, II Prowadzenie ewidencji zrealizowanych świadczeo, czasu trwania porady/wizyty, II Możliwośd przeglądania: II II archiwalnych programów rehabilitacji pacjenta, archiwalnych zleceo i wyników badao, II Możliwośd przeglądania: II II terminarza gabinetu na dany dzieo (tydzieo, miesiąc) terminarza terapeuty na dany dzieo (tydzieo, miesiąc) II terminarza stanowiska rehabilitacyjnego nadany dzieo (tydzieo, miesiąc) II pacjenta, II dziennej, II Potwierdzenie wykonania zabiegu w karcie zabiegowej Automatyczne tworzenie karty informacyjnej rehabilitacji Kwalifikacja rozliczeniowa usługi i świadczenia z NFZ, II Współpraca z modułem/grupą funkcjonalności Finanse- Księgowośd w zakresie obsługi dokumentów sprzedaży. II.1.3 Moduł/grupa funkcjonalności: Symulator JGP II Wstępne zasilenie symulatora danymi z wybranej hospitalizacji Strona 14 z 117

15 II Możliwośd sprawnej modyfikacji danych w symulatorze i obserwacja wpływu zmian na wyznaczane JGP: II modyfikacja danych pacjenta (wiek, płed), II modyfikacja danych hospitalizacji (data przyjęcia, data wypisu, tryb przyjęcia, tryb wypisu, tryb i charakter hospitalizacji), II dodanie lub usuniecie pobytu, II modyfikacja danych pobytu (data przyjęcia, data wypisu, cz. VIII kodu resortowego komórki, kod świadczenia, rozpoznanie zasadnicze, rozpoznania współistniejące, procedury medyczne (daty wykonania) II Wyróżnianie kolorami danych hospitalizacji nieistotnych z punktu widzenia wyznaczenia JGP II Możliwośd określenia wersji grupera za pomocą którego wyznaczone zostaną JGP II Domyślna wersja grupera uwzględniana przez symulator wynika z daty zakooczenia hospitalizacji, II Możliwośd dowolnego wyboru (z zarejestrowanych w systemie) do symulacji wersji grupera II Wskazywanie JGP z podziałem na: II II JGP, dla której hospitalizacja spełnia warunki wyboru, JGP, dla których hospitalizacja nie spełnia warunków, II JGP, które istnieją w planie umowy świadczeniodawcy, II Wyróżnienie kolorem pozycji w celu odzwierciedlenia ważności wyznaczonych JGP z punktu widzenia świadczeniodawcy (np. istniejących w planie umowy a tym samym możliwych do rozliczenia) II W przypadku wskazania JGP do których pacjent mógłby zostad zakwalifikowany jednak nie zostały spełnione wszystkie warunki - wskazanie tych warunków II JGP: Możliwośd przeglądu podstawowych informacji o wybranej II wartości taryf dla poszczególnych trybów hospitalizacji, II Parametry związane z mechanizmem osobodni (liczba dni finansowana grupą, taryfa dla hospitalizacji trwających < 2 dni, wartośd punktowa osobodnia ponad ryczałt finansowany grupą), Strona 15 z 117

16 II Parametry JGP (warunki, które musi spełniad hospitalizacja), II Wykorzystanie planu umowy dla JGP w przypadku, gdy JGP istnieje w umowie, II Prezentacja wykresów ilustrujących zależnośd naliczonych taryf od czasu hospitalizacji pacjenta II.2 ZAKRES: PRZYCHODNIA II.2.1 Moduł/grupa funkcjonalności: Rehabilitacja Dzienna II Rejestracja/przyjęcie pacjenta na podstawie skierowania, II Definiowanie listy zdarzeo medycznych / eleatów leczenia dla miejsca wykonania, II Prowadzenie klasyfikacji warunków wykonywania rehabilitacji: II II rehabilitacja ambulatoryjna rehabilitacja oddziału dziennego II II Obsługa skorowidza pacjentów rehabilitacji, Zarządzanie słownikami: II stanowisk i rządzeo rehabilitacyjnych, II Zarządzanie grafikami i terminarzami: II II II personelu, pomieszczeo, stanowisk i urządzeo rehabilitacyjnych, II Określenie warunków dostępności elementów leczenia poprzez przypisanie odpowiednich kategorii zasobów typu: II II II personel, pomieszczenie, stanowisko rehabilitacyjne II Możliwośd określenia standardowych czasów trwania wizyty/porady; pierwszorazowej i kontrolnej, II Możliwośd automatycznego nadawania priorytetu pilności dla pacjenta na podstawie danych z rozpoznania ze skierowania, II Możliwośd przypisania lekarza prowadzącego, terapeuty prowadzącego, Strona 16 z 117

17 II Planowanie elementów leczenia programu rehabilitacyjnego w terminarzach terapeutów, pomieszczeo, stanowisk rehabilitacyjnych i w karcie zabiegowej pacjenta z uwzględnieniem preferencji pacjenta, II II II pacjenta, Możliwośd drukowania planu zabiegów, Dostęp do bieżącego programu rehabilitacji dla pacjenta, Możliwośd wprowadzenia nowego programu rehabilitacji dla II Możliwośd anulowania całego programu lub wybranych jego elementów oraz/lub niezrealizowanych zabiegów z jednoczesnym anulowaniem rezerwacji zasobów ( tj. personel, pomieszczenia, stanowiska rehabilitacyjne), II Możliwośd obsługi porady/wizyty uprzednio zaplanowanej lub z pominięciem planowania, II II Definiowanie własnych formularzy dokumentacji medycznej, Obsługa indywidualnej dokumentacji medycznej dla pacjenta, II Możliwośd stosowania tekstów standardowych do opisu porad/ wizyt, II Możliwośd bieżącego uzupełniania dokumentacji medycznej przez lekarza i terapeutę, II Wprowadzanie zleceo (diagnostyka, laboratorium) z automatycznym drukowaniem skierowao, II Prowadzenie ewidencji zrealizowanych świadczeo, czasu trwania porady/wizyty, II Możliwośd przeglądania: II II wcześniejszych programów rehabilitacji pacjenta, wcześniejszych zleceo i wyników badao, II Możliwośd wglądu do: II II terminarza gabinetu na dany dzieo (tydzieo, miesiąc), terminarza terapeuty na dany dzieo (tydzieo, miesiąc) II terminarza stanowiska rehabilitacyjnego nadany dzieo (tydzieo, miesiąc), II pacjenta II Potwierdzenie wykonania zabiegu w karcie zabiegowej Obsługa zakooczenia wizyty: Strona 17 z 117

18 II automatyczne tworzenie karty informacyjnej rehabilitacji dziennej, II II kwalifikacja rozliczeniowa usługi i świadczenia z NFZ, wgląd do rozliczeo z NFZ, II.3 ZAKRES: PRACOWNIA DIAGNOSTYCZNA II.3.1 Moduł/grupa funkcjonalności: Pracownia diagnostyczna Rejestracja\recepcja: II Definiowanie szablonu pracy (terminarza) przypisanego do danej pracowni : II II II określenie szablonu dla każdego z dni tygodnia, określenie czasu pracy dla pracowni, określenie zakresu usług realizowanych w pracowni II określanie ograniczeo wg instytucji kierującej (płatnika), jednostki zlecającej Partnera Projektu (Oddziału/Izby Przyjęd), ilości wykonywanych usług II Definiowanie szablonu pracy przypisanego do danego urządzenia diagnostycznego: II II określenie szablonu dla każdego z dni tygodnia, określenie czasu pracy urządzenia diagnostycznego, II określenie zakresu usług realizowanych przez urządzenie diagnostyczne, II blokada grafików (urlopy, remonty). II Planowanie i rezerwacja wizyty pacjenta: II wyszukiwanie wolnych terminów dostępności wymaganych zasobów (pracownia, urządzenie diagnostyczne), II rezerwacja wybranego terminu lub pierwszy wolny, II prezentowanie preferowanych terminów wykonania usługi dla zgłoszeo internetowych na zasadzie określenia godzin przeznaczonych do planowania zgłoszeo internetowych np. od 10:00 do 12:00, II automatyczna rezerwacja terminów dla zgłoszeo internetowych wg preferencji pacjenta, Strona 18 z 117

19 II w przypadku braku wolnych terminów w preferowanych godzinach możliwośd rezerwacji pierwszy wolny lub ręczny wybór terminu, II rezerwacja terminów dla pacjentów przebywających na oddziałach szpitalnych II wstawianie terminu wizyty pomiędzy już istniejące wpisy w grafiku w przypadkach nagłych, II Obsługa skorowidza pacjentów, wspólnego dla pozostałych modułów/grup funkcjonalności medycznej części systemu, II Wyszukiwanie pacjentów w skorowidzu wg różnych parametrów, co najmniej: imię i nazwisko, nazwisko rodowe, nazwisko poprzednie, PESEL, data urodzenia, PESEL opiekuna, II Możliwośd zastosowania kart identyfikacyjnych do wyszukania pacjenta w systemie II Przegląd danych archiwalnych pacjenta w zakresie danych z poszczególnych wizyt w przychodni, pobytów szpitalnych, wizyt w zakładach diagnostycznych i wyników badao. II Rejestracja i modyfikacja danych osobowych pacjentów, II Ewidencja zmian danych osobowych i daty od kiedy obowiązują nowe dane (np. zmiana miejsca zamieszkania, zmiana nazwiska, itp.), II Rejestracja pacjenta w celu wykonania usługi: II określenie miejsca wykonania usługi (wybór pracowni/urządzenia diagnostycznego) 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 możliwośd wykorzystania szablonów zleceo złożonych, II możliwośd obsługi zleceo wewnętrznych zleconych z innych jednostek organizacyjnych Szpitala (w oparciu o utworzone zlecenia w modułach/grupach funkcjonalności części medycznej systemu) II możliwośd obsługi zleceo zewnętrznych (z innych podmiotów) Strona 19 z 117

20 II możliwośd wprowadzenia danych dot. skierowania (co najmniej: data, skierowania, lekarz i instytucja kierująca, przedmiot zlecenia, rozpoznanie) II Przegląd i wydruk listy zarejestrowanych pacjentów (do pracowni, do urządzenia diagnostycznego). II Obsługa kolejek oczekujących zgodnie z obowiązującymi przepisami, II Obsługa wyników: II odnotowanie wydania wyniku, II wpisywanie wyników zewnętrznych (badao, konsultacji, itp.) II Obsługa operacji kasowych dla pacjentów (IKP), II Obsługa operacji kasowych dla kontrahentów (dostęp do kartoteki kontrahentów modułu/grupy funkcjonalności Finanse Księgowośd, II Obsługa operacji kasowych dla pracowników (dostęp do kartoteki pracowników w module/grupie funkcjonalności Finanse Księgowośd ), II Prowadzenie raportu kasowego, II Możliwośd skojarzenia z każdym typem operacji kasowej schematu Księgowania w module/grupie funkcjonalności Finanse Księgowośd Pracownia: II Dostęp do listy pacjentów zarejestrowanych do pracowni, II Rejestracja rozpoczęcia obsługi wizyty pacjenta w pracowni (przyjęcie), II Przegląd danych pacjenta w następujących kategoriach: II dane osobowe, II podstawowe dane medyczne (grupa krwi, uczulenia, stale podawane leki, przebyte choroby, karta szczepieo), II II II II uprawnienia z tytułu umów, Historia choroby (dane ze wszystkich wizyt pacjenta), wyniki badao, przegląd rezerwacji, Strona 20 z 117

21 II Możliwośd zdefiniowania elementów menu (zakładek) w zależności od potrzeb i rodzaju pracowni, II Możliwośd zdefiniowania wzorów dokumentów dedykowanych dla pracowni, II Możliwośd użytkowania zdefiniowanych wcześniej wzorców dokumentacji dedykowanej do wizyty, II Wprowadzanie, modyfikacja, przegląd danych badania w następujących kategoriach: II II informacje ze skierowania, skierowania, zlecenia, II usługi, świadczenia w ramach wizyty, w tym dane dla potrzeb rozliczeo z płatnikiem, II II II podane leki, zużyte materiały medyczne, wystawione podczas wizyty skierowania, II wykonane podczas wizyty procedury drobne (nie będące usługami), 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 ewidencji wykonania usług rozliczanych komercyjnie: II obsługa stanowiska kasowego (jak w Rejestracji/Recepcji). II Obsługa zakooczenia badnia/wizyty: II autoryzacja medyczna badania, II automatyczne tworzenie karty wizyty/wyniku badania II kwalifikacja rozliczeniowa usług i świadczeo, II Automatyczne generowanie i możliwośd przeglądu księgi pracowni, II Obsługa wyników badao: II wprowadzanie opisów wyników badao diagnostycznych, Strona 21 z 117

22 II możliwośd wprowadzania opisów wyników badao na zdefiniowanych formularzach wyników dostosowanych do rodzaju wykonywanego badania, II II autoryzacja wyników badao diagnostycznych, wydruk wyniku wg definiowalnego wzoru, II Integracja z innymi modułami systemu medycznego: II współpraca z modułem/grupą funkcjonalności obsługującym apteczkę/magazynek oddziałowy w zakresie ewidencji zużytych leków i materiałów oraz automatycznej aktualizacji stanów magazynowych II współpraca z pozostałymi systemami/modułami medycznymi w zakresie wzajemnego udostępniania danych zleceo i danych o ich wykonaniu, Statystyka pracowni: II Przegląd i wydruk danych pacjenta w zakresie danych z poszczególnych wizyt w pracowni i wyników wykonanych badao, II Obsługa Ksiąg: II II Księga zakładu diagnostycznego, Księgi pracowni, II II Możliwośd definiowania własnych szablonów wydruków, Czynności analityczno-sprawozdawcze: II raport: lista badao w zadanym okresie w podziale na wykonujących, zlecających, II raport: lista badao w zadanym okresie w podziale na płatników, instytucje kierujące, II definiowanie własnych raportów w oparciu o moduł/grupę funkcjonalności Wykazy i zestawienia II.4 ZAKRES: DOKUMENTACJA MEDYCZNA II.4.1 Moduł/grupa funkcjonalności: Dokumentacja medyczna II Generowanie i możliwośd wydruku historii choroby na podstawie danych zgromadzonych w systemie, Strona 22 z 117

23 II Generowanie i możliwośd wydruku karty Informacyjnej na podstawie danych gromadzonych w systemie, II Generowanie i możliwośd wydruku wyników badao dla zadanych kryteriów: pacjent, nazwa badania, komórka organizacyjna (zlecająca/wykonująca), zadany okres czasu, II Generowanie i możliwośd wydruku kart obserwacji pacjenta, II Generowanie i możliwośd wydruku kart zakażenia, kart drobnoustroju, II Generowanie i możliwośd wydruku raportów z dyżuru lekarskiego na podstawie zarejestrowanych obserwacji pacjenta, II Generowanie i możliwośd wydruku raportów z diagnoz pielęgniarskich, II Generowanie i możliwośd wydruku dokumentów typu: zaświadczenie, skierowanie, orzeczenie, itp. wg definiowanych szablonów, II Elastyczne dopasowanie systemu do potrzeb Partnera Projektu w zakresie dokumentowania procesu leczenia: II definiowanie własnych formularzy przeznaczonych do wpisywania danych w systemie, II wyświetlanie, wprowadzanie i drukowanie informacji w ustalonej przez użytkownika postaci (definiowalne szablony dokumentów oraz edytor wydruków dla badao, konsultacji, itp.). II możliwośd prezentacji serii danych w postaci Histogramów, II możliwośd kojarzenia definiowanych formularzy z poszczególnymi rodzajami zleceo, II możliwośd rejestrowania danych multimedialnych (rysunki, obrazy, dźwięki, itp.). II System powinien przechowywad wszystkie wersje utworzonej i wydrukowanej (lub zarchiwizowanej w archiwum elektronicznym) dokumentacji medycznej, II Wszystkie dokumenty dokumentacji medycznej pacjenta powinny byd dostępne w jednym miejscu w aplikacji, II Podczas drukowania dokumentu wygenerowanego wcześniej system powinien informowad, że nastąpiły zmiany w danych i zaleca się utworzenie nowej wersji dokumentu, Strona 23 z 117

24 II Powinna istnied możliwośd podpisania elektronicznego i zarchiwizowania wszystkich dokumentów dokumentacji medycznej tworzonych przez system zgodnie z obowiązującymi przepisami. II.5 ZAKRES: WSPÓLNE II.5.1 Moduł/grupa funkcjonalności: Pulpit użytkownika II System powinien udostępniad pulpity użytkowników umożliwiające bezpośredni dostęp do wszystkich niezbędnych funkcji, do jakich użytkownik posiada uprawnienia. II Powinny istnied predefiniowane i konfigurowalne pulpity dla użytkowników o określonej roli personelu medycznego, co najmniej pulpit lekarza, II Pulpit lekarza powinien umożliwiad co najmniej bezpośredni dostęp do: II listy pacjentów oddziału/oddziałów szpitalnego/szpitalnych, dla których zalogowany użytkowniklekarz jest lekarzem prowadzącym (z możliwością poszerzenia listy o wszystkich pacjentów przebywających w oddziale/oddziałach w których ten lekarz jest zatrudniony) II listy pacjentów z zaplanowaną w dniu bieżącym wizytą, badaniem lub konsultacją u zalogowanego użytkownikalekarza (z możliwością rozszerzenia listy o wszystkich pacjentów z zaplanowanymi wizytami, badaniami, konsultacjami w medycznych komórkach organizacyjnych szpitala, w których lekarz-użytkownik systemu jest zatrudniony, II wyników badao pacjentów z w/w list z podziałem na laboratoryjne, pracowniane i pozostałe z możliwością wyświetlenia tylko najnowszych wyników (np. z ostatnich 24godzin), II dokumentacji medycznej pacjentów z w/w list, II osobistego terminarza lekarza uwzględniający jego: dyżury, nieobecności, zadania, zaplanowane dla niego lub zrealizowane przez niego: zabiegi, konsultacje, wizyty, II najważniejszych informacji o danym pacjencie (np. na osobnej zakładce) - m.in. dane opiekunów prawnych, alergie, komentarze). Strona 24 z 117

25 II Powinna istnied możliwośd samodzielnego, przez użytkowników lub administratorów, definiowania/modyfikacji układu/zawartości pulpitu, II.5.2 Moduł/grupa funkcjonalności: Wykazy, zestawiania II Projektowanie niestandardowych wykazów na podstawie danych dostępnych w modułach medycznych, z ustaleniem: II II II II zakresu danych do wykazu, kryteriów selekcji danych do wykazu, kolejności danych wykazu (sortowanie), grupowania danych, II Możliwośd zapamiętania definicji wykazu tworzenie własnej biblioteki wykazów, II Możliwośd prezentacji danych w formacie dowolnego arkusza kalkulacyjnego, HTML II.5.3 Moduł/grupa funkcjonalności: Zakażenia szpitalne II Moduł realizuje wspomaganie Zakładu Opieki Zdrowotnej w zakresie kontroli występowania zakażeo zakładowych i zapobiegania tym zakażeniom, zgodnie z odpowiednimi przepisami prawa. II W szczególności musi umożliwid: II prowadzenie Rejestru Kart Rejestracji Zakażenia Zakładowego, II wydruki na podstawie danych Rejestru Kart Rejestracji Zakażenia Zakładowego, II prowadzenie Rejestru Kart Rejestracji Drobnoustroju Alarmowego, II wydruki na podstawie danych Rejestru Kart Rejestracji Drobnoustroju Alarmowego, II prowadzenie Rejestru zgłoszeo zachorowania na chorobę zakaźną, II wydruki na podstawie danych Rejestru zgłoszeo zachorowania na chorobę zakaźną, Strona 25 z 117

26 II prowadzenie Rejestru zgłoszeo zachorowania (podejrzenia zachorowania) na AIDS lub zgłoszenia zakażenia (podejrzenia zakażenia) HIV, II wydruki na podstawie danych Rejestru zgłoszeo zachorowania (podejrzenia zachorowania) na AIDS lub zgłoszenia zakażenia (podejrzenia zakażenia) HIV, II prowadzenie Rejestru zgłoszeo zachorowania (podejrzenia zachorowania) na chorobę przenoszoną drogą płciową, II wydruki na podstawie danych Rejestru zgłoszeo zachorowania (podejrzenia zachorowania) na chorobę przenoszoną drogą płciową, II prowadzenie Rejestru zgłoszeo zachorowania (podejrzenia zachorowania) na gruźlicę, II wydruki na podstawie danych Rejestru zgłoszeo zachorowania (podejrzenia zachorowania) na gruźlicę, II prowadzenie Rejestru zgłoszeo zgonu (podejrzenia zgonu) z powodu choroby zakaźnej, II wydruki na podstawie danych Rejestru zgłoszeo zgonu (podejrzenia zgonu) z powodu choroby zakaźnej, II prowadzenie Rejestru obserwacji potencjalnych źródeł zakażenia (wkłucia obwodowe, wkłucia centralne, cewniki, respiratory, operacje, infekcje), II prowadzenie Rejestru podejrzeo ognisk epidemicznych, II wydruki na podstawie danych Rejestru podejrzeo ognisk epidemicznych, II prowadzenie Rejestru potwierdzonych ognisk epidemicznych, II wydruki na podstawie danych Rejestru potwierdzonych ognisk epidemicznych, II raporty zgodne z odpowiednim Rozporządzeniem Ministra Zdrowia, II analizy ilościowe zakażeo zakładowych, II Analizy kosztów podao antybiotyków i badao mikrobiologicznych związanych z zakażeniami zakładowymi, Strona 26 z 117

27 II Współpraca z modułami/grupami funkcjonalności części medycznej systemu dot. ruchu chorych oraz laboratorium mikrobiologicznego w zakresie podao antybiotyków i zleceo badao do pracowni mikrobiologicznej: II monitorowanie o konieczności założenia Indywidualnej Karty Zakażeo Szpitalnych w przypadku podawania antybiotyku powyżej 3 dni, II monitorowanie o konieczności założenia Indywidualnej Karty Zakażeo Szpitalnych w przypadku wystąpienia patogenu w badaniu mikrobiologicznym, II szybki podgląd listy pacjentów dla nowo założonych: kart obserwacji, kart zakażenia, kart drobnoustroju, alertu patogenów. II.5.4 Moduł/grupa funkcjonalności: Obsługa urządzeo mobilnych II System musi posiadad mechanizm bezpiecznego logowania, II II Możliwośd wyszukiwania i przeglądu miejsca pobytu pacjenta Możliwośd przypisywania pacjentów do sal/łóżek II Możliwośd wyszukiwania pacjenta po kodzie EAN (obsługa kodów kreskowych) lub QR Code II II II II II II Możliwośd przeglądu statystyki pacjentów oddziału Możliwośd zlecania leków Możliwośd odnotowania podania leków Możliwośd prezentacji danych o zleconych i podanych lekach Przegląd wyników badao laboratoryjnych Przegląd wyników badao diagnostycznych II Możliwośd zlecania badao laboratoryjnych i diagnostycznych/prezentacja zleceo II Wprowadzanie wyników pomiarów i przegląd wyników pomiarów w formie wykresów. II II Przegląd dokumentacji pacjenta Prezentowanie danych o alergiach i zakażeniach Strona 27 z 117

28 II.5.5 Moduł/grupa funkcjonalności: Wymiana danych z systemami zewnętrznymi II Wymiana danych z systemami typu RIS: II Integracja musi z opierad się na standardzie HL7 II Przyjmowanie zleceo drogą elektroniczną wraz z importem danych zlecenia i pacjenta (przyjmowane zleceo wystawionych do przodu) II Automatyczne odsyłanie informacji o terminie umówienia badania II Automatyczne odsyłanie do systemu HIS opisu badania zleconego elektronicznie II Udostępnienie dla systemu HIS historii wszystkich badao wykonanych w systemie RIS ( również tych nie zlecanych elektronicznie) II Możliwośd przeglądania historii leczenia szpitalnego w systemie RIS II Odsyłanie linku z systemu RIS do HIS (obraz dostępny w systemie HIS bez konieczności logowania w RIS) II.5.6 Moduł/grupa funkcjonalności: Szpitalny portal e-usług II Funkcjonalności dostępne dla personelu - konfiguracja i administrowanie, bieżąca obsługa II Odzwierciedlenie struktury organizacyjnej jednostki Partnera Projektu w układzie hierarchicznym, w postaci interaktywnego diagramu, II Wprowadzanie i prezentacja formatowanych opisów poszczególnych komórek organizacyjnych, II Wprowadzanie informacji o godzinach pracy komórek organizacyjnych; możliwośd przepisania godzin pracy z informacji zarejestrowanych dla jednostki nadrzędnej. II Wprowadzanie informacji o personelu realizującym usługi medyczne; rejestracja informacji o grupach zawodowych i specjalnościach personelu. II Wprowadzanie informacji o godzinach pracy personelu (harmonogramach pracy personelu). II Integracja rejestru personelu z odpowiadającym rejestrem po stronie pozostałych modułów/grup funkcjonalności systemu, Strona 28 z 117

29 II Wprowadzanie informacji o usługach realizowanych w jednostce Partnera Projektu; wprowadzanie opisów usług w postaci formatowanych tekstów, II Definiowanie rodzajów świadczonych usług, przypisywanie usług do zdefiniowanych grup. II Definiowanie statusu wyboru personelu dla definiowanych usług (wybór personelu możliwy, niemożliwy, wymagany). II Definiowanie wymagalności skierowania do realizacji usługi; określenie możliwości lub konieczności rejestracji danych skierowania w czasie rezerwacji terminu udzielenia usługi. II Wprowadzanie informacji o szczególnych warunkach udzielania usług (zalecenia dla pacjentów odnośnie realizacji usługi) w postaci formatowanych tekstów. II Wprowadzanie informacji o wymaganych dokumentach (załącznikach) związanych z definiowaną usługą. II Możliwośd dołączenia załączników w postaci pliku. II Integracja rejestru usług medycznych z odpowiadającym mu rejestrem prowadzonym po stronie pozostałych modułów/grup funkcjonalności systemu, II Wskazanie usług, dla których możliwa jest rezerwacja terminu ich realizacji, II Wskazanie usług zlecanych stanowiących grupy badao dostępnych dla danego kontrahenta; przypisanie poszczególnych badao do usług zlecanych, II Możliwośd bieżącego wprowadzania informacji o przerwach w dostępności elementów struktury organizacyjnej jednostki Partnera Projektu. II Automatyczne aktualizowanie informacji o dostępności usług w komórkach organizacyjnych na postawie uprzednio wprowadzonych danych o dostępności tych komórek, II Możliwośd definiowania parametrów rezerwacji dla usług dostępnych w komórkach organizacyjnych: II maksymalna liczba jednoczasowych rezerwacji tego samego pacjenta, II minimalny interwał czasu pomiędzy datą rejestracji a datą realizacji usługi, Strona 29 z 117

30 II maksymalny okres czasu względem daty rezerwacji, w którym możliwe jest ustalenie planowanego terminu udzielenia usługi, II Wprowadzanie informacji o dostępności usług w komórkach organizacyjnych na postawie harmonogramu; podpowiadanie definicji harmonogramu na podstawie godzin otwarcia jednostki; Możliwośd wprowadzenia ciągłej dostępności usług w jednostkach organizacyjnych, II Rejestracja informacji o dostępności personelu na podstawie harmonogramu; podpowiadanie harmonogramów personelu na podstawie godzin pracy zdefiniowanych w rejestrze personelu. II Automatyczne aktualizowanie informacji o dostępności usług udzielanych przez określony personel na podstawie uprzednio wprowadzonych danych o dostępności personelu. II Możliwośd dowolnej modyfikacji zdefiniowanych dostępności: usuwanie dostępnych okresów; modyfikacja dat dostępnych okresów; dodawanie nowych okresów dostępności. II Definiowanie klas pacjentów użytkowników portalu. II Definiowanie parametrów rezerwacji dla poszczególnych klas pacjentów: II maksymalna liczba rezerwacji terminów realizacji dostępnych usług dla pacjentów określonej klasy, II usług, II II II II maksymalny okres rezerwacji terminów udzielenia tryb potwierdzenia rezerwacji: bez potwierdzenia, potwierdzenie , potwierdzenie SMS, II Możliwośd określenia sposobu powiadamiania pacjentów określonej klasy o anulowaniu rezerwacji: II II II bez powiadomieo, powiadomienie , powiadomienie SMS, II Możliwośd określenia sposobu powiadamiania pacjentów określonej klasy o zmianie planowanego terminu udzielenia usługi: II II bez powiadomieo, powiadomienie , Strona 30 z 117

31 II powiadomienie SMS, II Możliwośd określenia sposobu powiadamiania pacjentów określonej klasy o zbliżającym się terminie udzielenia usługi: II II II bez powiadomieo, powiadomienie , powiadomienie SMS, II Możliwośd określenia interwału czasu przed zaplanowanym terminem udzielenia usługi, kiedy zostanie wysłane powiadomienie, II Możliwośd definiowania wielu powiadomieo o zbliżającym się terminie udzielenia usługi dla danej rezerwacji, II Możliwośd definiowania uprawnieo dla poszczególnych klas użytkowników-pacjentów; II Integracja uprawnieo dla użytkowników-pacjentów z uprawnieniami zarządzanymi w module/grupie funkcjonalności Administrator, II Przegląd danych pacjentów zarejestrowanych w portalu. II Możliwośd zatwierdzenia przez pracowników szpitala (autoryzacja) zarejestrowanych pacjentów jako użytkowników portalu, II Możliwośd rejestracji pacjentów jako użytkowników portalu przez pracowników szpitala możliwośd udostępnienia funkcjonalności portalu poszczególnym pacjentom bez konieczności rejestrowania się pacjenta na stronie internetowej, II Wprowadzanie kontrahentów obsługiwanych w portalu, II Wprowadzanie pracowników kontrahenta użytkowników portalu; przydzielanie uprawnieo pracownikom kontrahenta, II Wprowadzanie pacjentów powiązanych z danym kontrahentem, II Import danych pacjentów związanych z kontrahentem z pliku zewnętrznego (plik csv), II Wprowadzanie umów zawartych z kontrahentem, II Wprowadzanie usług realizowanych na rzecz danego kontrahenta na podstawie określonej umowy, Możliwośd rejestracji ilościowych limitów usług, II Wprowadzanie dostępności usług w ramach określonych umów zawartych z kontrahentem, Strona 31 z 117