Opis Przedmiotu Zamówienia System Elektronicznej Dokumentacji Medycznej

Zadanie I Opis Przedmiotu Zamówienia System Elektronicznej Dokumentacji Medycznej Zamawiający poniżej przedstawił oczekiwaną funkcjonalność i usług Systemu Elektronicznej Dokumentacji Medycznej wraz z oprogramowaniem dodatkowym. Należy parafować wszystkie strony oraz podpisać na końcu załącznika. Podpisanie załącznika jest jednoznaczne z deklaracją dostarczenia wszystkich wymaganych funkcjonalności. Przedstawione poniżej wymagania posegregowane są wg grup funkcjonalnych (modułów). Zamawiający dopuszcza, aby poszczególne funkcjonalności były realizowane w innych modułach niż przypisano poniżej. Zawartość Zawartość...1 Wymagania ogólne do zakresu...2 Posiadany przez Zamawiającego Zintegrowany System Informatyczny...2 Wymagany stan docelowy w zakresie ZSI szpitala...3 Wymagania ogólne Systemu Elektronicznej Dokumentacji Medycznej...4 Szczegółowe wymagania Systemu EDM...5 Wymagania ogólne...5 Wymagania prawne...7 Dokumentacja Medyczna Formularzowa...8 Elektroniczna Dokumentacja Medyczna i Archiwum EDM...9 Aplikacja mobilna...10 Medyczny portal informacyjny...10 Wymagania dla oprogramowania uzupełniającego...14 Żywienie szpitalne...14 Integracja HIS, EDM i systemu radiologicznego...16 Wymagania dotyczące szkoleń...18 Wymagania ogólne...18 Wymagania szczegółowe...19 Personel szkolący...19 Wymagania dotyczące wdrożenia...20

Wymagania ogólne...20 Standardy wdrożeniowe...20 Odbiór końcowy...21 Termin uruchomienia...21 Wymagania dotyczące serwisu i nadzoru autorskiego...21 Wymagania ogólne...21 Wymagania ogólne do zakresu Posiadany przez Zamawiającego Zintegrowany System Informatyczny Zamawiający posiada Zintegrowany Szpitalny System Informatyczny w części medycznej i ekonomicznej. Poniższe zestawienie przedstawia obecnie funkcjonujące rozwiązanie. Lp. Moduł i rodzaj licencji Ilość 1. Finansowo-Księgowy - nieograniczona 1 2. Rachunek Kosztów nieograniczona 1 3. Rejestr Sprzedaży- nieograniczona 1 4. Kadry nieograniczona 1 5. Płace nieograniczona 1 6. Grafiki nieograniczona 1 7. Gospodarka Magazynowo-Materiałowa nieograniczona 1 8.Środki Trwałe - nieograniczona 1 9. Wyposażenie nieograniczona 1 10.Kasa nazwany użytkownik 3 11.Wycena Procedur Medycznych nieograniczona 1 12.Apteka Szpitalna nieograniczona 1 13.ADT Ruch Chorych (Izba Przyjęć, Oddział, Statystyka, Kontraktowanie) nieograniczona 1 14.Pracownia Diagnostyczna nieograniczona 1 15.Zlecenia nieograniczona 1 16.Przychodnia Standard (Rejestracja, Gabinet, Statystyka, Kontraktowanie) - nieograniczona 1 17.Laboratorium nieograniczona 1 18.Punkt Pobrań nieograniczona 1 19.Blok Operacyjny nieograniczona 1 20.Apteczka Oddziałowa nieograniczona 1 21.Dializy 1 22.Rehabilitacja nieograniczona 1 23.Patomorfologia nieograniczona 1 24.Kalkulacja Kosztów Leczenia nieograniczona 1

Posiadane oprogramowanie to system szpitalny Infomedica firmy Asseco Poland, zarówno w części medycznej HIS, jak i ekonomicznej ERP. System działa w oparciu o posiadany przez Zamawiającego motor bazy danych ORACLE. System szpitalny komunikuje się również z systemem laboratoryjnym LIS o nazwie Centrum firmy Marcel. Komunikacja jest zrealizowana za pomocą protokołu HL7. Wymagany stan docelowy w zakresie ZSI szpitala Zamawiający oczekuje utrzymania obecnie posiadanego Zintegrowanego Systemu Informatycznego szpitala oraz dostarczenia dodatkowych modułów wyszczególnionych w dalszej części opisu przedmiotu zamówienia. Dostarczone oprogramowanie Elektronicznej Dokumentacji Medycznej musi działać w oparciu o posiadany przez Zamawiającego motor bazy danych ORACLE i zapewnić pełną zgodność z eksploatowanym modelem bazy danych posiadanego oprogramowania Infomedica. Stan docelowy licencji i modułów przedstawia poniższe zestawienie. Lp. Moduł i rodzaj licencji Ilość Uwagi 1. Finansowo-Księgowy nieograniczona 1-2. Rachunek Kosztów nieograniczona 1-3. Rejestr Sprzedaży- nieograniczona 1-4. Kadry nieograniczona 1-5. Płace nieograniczona 1-6. Grafiki nieograniczona 1-7. Gospodarka Magazynowo-Materiałowa nieograniczona 1-8. Środki Trwałe - nieograniczona 1-9. Wyposażenie nieograniczona 1-10. Kasa nazwany użytkownik 3-11. Wycena Procedur Medycznych nieograniczona 1-12. Apteka Szpitalna nieograniczona 1 13. ADT Ruch (Izba Przyjęć, Oddział, Statystyka, Kontraktowanie, SOR) nieograniczona 14. Ruch Chorych Szpitalny Oddział ratunkowy - nieograniczona 1-15. Pracownia Diagnostyczna nieograniczona 1 16. Zlecenia nieograniczona 1 17. Przychodnia Standard (Rejestracja, Gabinet, Statystyka, Kontraktowanie) nieograniczona 18. Statystyka Zakażeń Szpitalnych - nieograniczona 1-19. Laboratorium nieograniczona 1-20. Punkt Pobrań nieograniczona 1 21. Blok Operacyjny nieograniczona 1-22. Dokumentacja Medyczna - nieograniczona 1 1 1 Wymagane dostarczenie klienta WWW Wymagane dostarczenie klienta WWW Wymagane dostarczenie klienta WWW Wymagane dostarczenie klienta WWW Wymagane dostarczenie klienta WWW Wymagane dostarczenie klienta WWW Wymagane dostarczenie klienta WWW

23. Apteczka Oddziałowa nieograniczona 1 24. Dializy 1-25. Rehabilitacja nieograniczona 1-26. Patomorfologia nieograniczona 1-27. Kalkulacja Kosztów Leczenia nieograniczona 1-28. 29. 30. Archiwum dokumentacji medycznej (repozytorium dokumentacji elektronicznej) - nieograniczona Medyczny Portal Informatyczny - nieograniczona - e-pacjent - e-kontrahent [brak opisu od DP, potencjalnie do wyrzucenia, koszt modułu 60k] Aplikacja mobilna (Tablet oddziałowy) minimum 80 stanowisk mobilnych 31. Żywienie szpitalne - nieograniczona na liczbę obsługiwanych oddziałów 1 1 1 1? 1 Wymagane dostarczenie klienta WWW Wymagane dostarczenie klienta WWW - Wymagane dostarczenie klienta działającego na ios i Android Wykonawca dostarczy możliwość używania obecnego HIS poprzez przeglądarkę WWW co najmniej w zakresie Lecznictwa Zamkniętego (Izba Przyjęć, Szpitalny Oddział Ratunkowy, Oddział, Statystyka), Lecznictwa Otwartego (Rejestracja, Gabinety Lekarskie i Zabiegowe, Pracownie Diagnostyczne). Wymagania ogólne Systemu Elektronicznej Dokumentacji Medycznej Zamawiający w ramach zamówienia oczekuje dostarczenia współpracującego z obecnie posiadanym zintegrowanym systemem szpitalnym oprogramowania Elektronicznej Dokumentacji Medycznej. Wykonawca musi w dostawie oprogramowania uwzględnić wszelkie możliwe niedostatki licencyjne istniejącego oprogramowania Zamawiającego w świetle przepisów dotyczących wdrożenia w placówkach ochrony zdrowia Elektronicznej Dokumentacji Medycznej i bierze na siebie pełną odpowiedzialność w tym zakresie. Dostarczone oprogramowanie zostanie wdrożone z zapewnieniem ciągłości pracy obecnie użytkowanego systemu informatycznego. Ewentualne przerwy w działaniu systemu muszą zostać uzgodnione z producentem obecnie użytkowanego systemu szpitalnego i zatwierdzone przez Zamawiającego. Dostarczone oprogramowanie wykorzystywać będzie posiadany przez Zamawiającego motor bazy danych ORACLE. W czasie prac wdrożeniowych Wykonawca zapewni stały nadzór przynajmniej 1 osoby upoważnionej przez producenta obecnie użytkowanego systemu Infomedica firmy Asseco do zapewnienia prawidłowej pracy obecnego systemu. Upoważnienia muszą być dostarczone do Zamawiającego w formie pisemnej i potwierdzone przez producenta. Wraz z ofertą Wykonawca złoży próbkę oprogramowania jako wzór oferowanego oprogramowania na laptopie i tablecie. Próbka zostanie zdeponowana u Zamawiającego do czasu prezentacji. Zamawiający w trakcie oceny ofert wezwie Wykonawców do prezentacji z wykorzystaniem wyłącznie oprogramowania na zdeponowanym laptopie i tablecie bez

możliwości wykonywania aktualizacji i modyfikacji przed dokonaniem prezentacji. W szczególności Wykonawca zaprezentuje prawidłowość współdziałania z udostępnionym przez Zamawiającego testowym środowiskiem obecnie użytkowanego systemu HIS. Szczegółowy harmonogram scenariusza próbki zostanie przedstawiony w wezwaniu przynajmniej 3 dni robocze przed dniem prezentacji. Zamawiający zastrzega możliwość rejestrowania prezentacji wyłącznie przez Zamawiającego. Szczegółowe wymagania Systemu EDM Wymagania ogólne L.p. Wymagania Dostęp do funkcji systemu jest realizowany ze stanowiska roboczego bez konieczności instalacji dodatkowych aplikacji lub modułów oprogramowania 1. obsługującego komunikację pośrednią między interfejsem użytkownika na stanowiska roboczym, a systemem na serwerze. 2. System ma interfejs graficzny dla wszystkich modułów. System posiada graficzny interfejs i pracuje w graficznym środowisku systemu 3. operacyjnego na stanowiskach użytkowników. System komunikuje się z użytkownikiem w języku polskim. Jest wyposażony w system podpowiedzi (help). W przypadku oprogramowania narzędziowego i 4. administracyjnego serwera bazy danych dopuszcza się częściową komunikację w języku angielskim. W funkcjach związanych z wprowadzaniem danych system udostępnia 5. podpowiedzi, automatyczne wypełnianie pól, słowniki grup danych (katalogi leków, procedur medycznych, danych osobowych, terytorialnych). Kontrola/parametryzacja Wielkich/małych liter. Możliwość ustawienia w 6. wybranych polach wymuszonego formatowania wpisu. System posiada wbudowane mechanizmy zapewniające odporność struktur 7. danych (baza danych) na uszkodzenia oraz umożliwiające przyspieszone odtworzenie ich wartości i stanu oraz integralności. System posiada wbudowane mechanizmy umożliwiające przyspieszone 8. wykonywanie bieżących kopii danych oraz ich odtwarzanie z wykonanych kopii. Dane systemu są gromadzone, przechowywane i udostępniane w relacyjnej bazie 9. danych z wykorzystaniem aktywnego serwera baz danych. System musi umożliwiać nadawanie użytkownikom uprawnień do pracy wyłącznie 10. w kontekście wybranej/ wybranych jednostek organizacyjnych. System musi umożliwić zmianę jednostki organizacyjnej, na której pracuje 11. użytkownik bez konieczności wylogowywania się z systemu System musi być wyposażony w zabezpieczenia przed nieautoryzowanym 12. dostępem. Zabezpieczenia muszą funkcjonować na poziomie klienta (aplikacja) i serwera (serwer baz danych), System musi posiadać mechanizmy umożliwiające zapis i przeglądanie danych o 13. logowaniu użytkowników do systemu 14. System musi umożliwiać podgląd aktualnie zalogowanych do systemu

15. 16. 17. 18. 19. 20. 21. użytkowników. System musi gromadzić dane opisujące jego funkcjonowanie (zdarzenia) w postaci systemowego dziennika pracy, dotyczące wszystkich użytkowników systemu i wykonanych przez nich modyfikacjach danych osobowych oraz medycznych z możliwością wykonania analizy historii zmian wartości tych danych. Administrator musi posiadać możliwość z poziomu aplikacji z modułu administratora nadawania danemu użytkownikowi unikalnego loginu oraz hasła oraz wymuszenia zmiany hasła przez użytkownika podczas pierwszego logowania do systemu. Administrator musi posiadać możliwość ustawienia parametrów hasła: długość, czas żywotności, czas przed wygaśnięciem. Hasła muszą spełniać wymagania określone w Rozporządzeniu MSWiA z 29.04.2004. Administrator musi posiadać z poziomu aplikacji możliwość wylogowania wszystkich użytkowników aplikacji oraz zablokowania im dostępu do niej przez określony czas. W przypadku przechowywania haseł w bazie danych, hasła muszą być zapamiętane w postaci niejawnej (zaszyfrowanej). Dane powinny być chronione przed niepowołanym dostępem przy pomocy mechanizmu uprawnień użytkowników. Każdy użytkownik systemu powinien mieć odrębny login i hasło. Jakakolwiek funkcjonalność systemu (niezależnie od ilości modułów) będzie dostępna dla użytkownika dopiero po jego zalogowaniu. System uprawnień powinien być tak skonstruowany, aby można było użytkownikowi nadać uprawnienia z dokładnością do rodzaju wykonywanej operacji tj. osobne uprawnienie na odczyt danych i osobne na wprowadzanie/modyfikację danych. System uprawnień powinien umożliwiać definiowanie grup uprawnień, które to mogłyby być przydzielane poszczególnym użytkownikom. Równolegle musi istnieć możliwość nadawania użytkownikowi pojedynczych uprawnień z listy dostępnych. System musi umożliwiać definiowanie grup użytkowników i przydzielanie użytkowników do tych grup. System powinien umożliwiać nadawanie uprawnień użytkownikom do jednostek organizacyjnych, w których pracują, np. lekarz pracujący na izbie przyjęć i oddziale wewnętrznym powinien w swoich aplikacjach widzieć tylko pacjentów izby przyjęć i tego jednego oddziału. System umożliwia administratorowi z poziomu aplikacji definiowanie i zmianę 22. praw dostępu dla poszczególnych użytkowników i grup użytkowników z dokładnością do poszczególnych modułów oraz funkcji systemu. 23. Wyróżnienie pól: 24. - których wypełnienie jest wymagane, 25. - przeznaczonych do edycji, 26. - wypełnionych niepoprawnie. 27. 28. System musi umożliwiać obsługę kodów kreskowych 1D i 2D (znakowanie, wczytywanie, wybór danych do zakodowania) do rejestracji skierowań pochodzących z innych zakładów opieki zdrowotnej oraz w dystrybucji leków na oddziały. System umożliwia wykonanie nowej operacji w systemie bez konieczności przerywania czynności dotychczas wykonywanej (np. obsługa zdarzenie w trybie

29. 30. 31. 32. 33. nagłym) i powrót do zawieszonej czynności bez utraty już wprowadzonych danych i kontekstu. Błędy procedury wprowadzania danych polegające na niewypełnieniu lub wprowadzeniu błędnych danych w obligatoryjnych polach formularzy powinny być prezentowane użytkownikowi z możliwością szybkiego przejścia do miejsc gdzie te błędy zostały wykryte. System powinien automatycznie blokować sesję użytkownika po zadanym czasie braku jego aktywności i wymusić zakończenie zablokowanej tej sesji w trybie administracyjnym po upływie ustalonego okresu braku aktywności tego użytkownika z zachowaniem w tym samym trybie wartości wprowadzonych i zapisanych danych. W każdym oknie, gdzie możliwa jest edycja (wprowadzanie, modyfikacja, usuwanie) danych, system musi udostępniać funkcje, wycofania wszystkich czynności z powrotem do poprzedniego okna (ANULUJ) bez zapisu wprowadzonych już danych. W każdym polu opisowym formularzy wprowadzania danych (np. treść wywiadu) system musi zapewniać możliwość skorzystania z funkcji ułatwiających wprowadzanie treści np. kopiuj/wklej. System zapewni niezakłóconą pracę minimum 400 użytkowników równolegle zalogowanych do systemu. Wymagania prawne L.p. Wymaganie 1. Zgodność z następującymi aktami prawnymi z późniejszymi zmianami: 2. Ustawa z dnia 6 listopada 2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta (Dz. U. z 2009 r. Nr 52, poz. 417 i Nr 76, poz. 641 oraz z 2010 r. Nr 96, poz. 620) 3. Ustawa o systemie informacji w ochronie zdrowia z 28 kwietnia 2011 r. (Dz. U. z 2011 nr 113 poz.657) 4. Rozporządzenie Ministra Zdrowia z dnia 21 grudnia 2010 r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania (Dz. U. 2010 nr 252 poz. 1697) 5. Rozporządzenie Ministra Zdrowia z dnia 28 marca 2013 r. w sprawie wymagań dla Systemu Informacji Medycznej (Dz. U. 2013 poz 463) 6. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz.U. z 2004 nr 100, poz.1024) 7. Ustawa z dnia 17 lutego 2005 o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U z 2005 nr 64) z późniejszymi zmianami 8. Rozporządzenie Rady Ministrów z dnia 11 października 2005 w sprawie minimalnych wymagań dla systemów teleinformatycznych (Dz.U. 2005 Nr 212, poz. 1766). 9. Rozporządzenie Ministra Zdrowia z dnia 14 grudnia 2006 r zmieniające rozporządzenie 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 (z dnia 29 lipca 2005) 10. System musi spełniać wymogi wynikające z ustawy o Ochronie Danych Osobowych z 29 czerwca 1997 roku oraz z Rozporządzenia MSWiA z 29 kwietnia 2004 roku, w szczególności system musi przechowywać informacje o: dacie wprowadzenia danych osobowych identyfikator użytkownika wprowadzającego dane osobowe

źródło danych (o ile dane nie pochodzą od osoby, której te dane dotyczą) informacje o odbiorcach danych którym dane osobowe zostały udostępnione, dacie i zakresie tego udostępnienia data modyfikacji danych osobowych identyfikator operatora modyfikującego dane Dokumentacja Medyczna Formularzowa L.p. Wymaganie 1. Moduł działa za pośrednictwem przeglądarki WWW 2. Moduł umożliwia definiowanie aktywnych formularzy 3. Generowanie Historii Choroby z danych zgromadzonych w systemie 4. Generowanie Karty Informacyjnej z danych gromadzonych w systemie 5. Generowanie wyników badań dla zadanych kryteriów: pacjent, nazwa badania, jednostka organizacyjna, zadany czasu, 6. Generowanie wydruków kart obserwacji pacjenta 7. Generowanie wydruków kart zakażenia, kart drobnoustroju 8. Generowanie raportów z dyżuru lekarskiego na podstawie zarejestrowanych obserwacji pacjenta 9. Generowanie raportów z diagnoz pielęgniarskich 10. elastyczne dopasowanie systemu do potrzeb Zamawiającego w zakresie dokumentowania procesu leczenia : 11. - definiowania własnych formularzy przeznaczonych do wpisywania danych w systemie. 12. - wyświetlanie, wprowadzanie i drukowanie informacji w ustalonej przez użytkownika postaci (definiowalne formularze oraz edytor wydruków dla badań, konsultacji, itp.). 13. - histogramy 14. - możliwość kojarzenia formularzy ze zleceniami i elementami leczenia 15. - rejestrowanie danych multimedialnych (rysunki, obrazy, dźwięki, itp.). 16. - dostęp do danych dla potrzeb analityczno-sprawozdawczych. 17. System powinien przechowywać wszystkie wersje utworzonej i wydrukowanej (lub zarchiwizowanej w archiwum elektronicznym) dokumentacji medycznej. 18. Wszystkie dokumenty dokumentacji medycznej pacjenta powinny być dostępne z jednego miejsca 19. Musi istnieć możliwość zdefiniowania drukarki dla każdego rodzaju dokumentu tak aby dokument mógł być drukowany na odpowiedniej dla niego drukarce 20. Powinna istnieć możliwość podpisania elektronicznego i zarchiwizowania wszystkich dokumentów dokumentacji medycznej tworzonych przez system zgodnie z obowiązującymi przepisami. 21. Możliwość zablokowania modyfikacji wpisów w historii choroby dokonanych przez innego lekarza niż lekarz aktualnie zalogowany/ autoryzujący wpis 22. Możliwość autoryzacji przez lekarza dokonującego wpis, fragmentu historii choroby, epikryzy lub rozpoznania 23. Automatyczna weryfikacja zgodności dokumentów z danymi źródłowymi. Musi istnieć możliwość wskazania dokumentów wymagających ponownej generacji w związku z modyfikacją danych źródłowych. 24. Możliwość utworzenia i wydruku historii zmian dokumentu obejmującą historię autoryzowanych danych źródłowych (wpisów) 25. System musi być wyposażony w mechanizmy umożliwiające weryfikację, czy na określonym etapie procesu obsługi pacjenta zostały utworzone wszystkie wymagane dokumenty 26. Musi istnieć możliwość utworzenia dokumentu roboczego, umożliwiającego podgląd danych źródłowych w postaci dokumentu 27. System umożliwia obsługę dokumentów o zmiennej treści, o ile nie stoi to w sprzeczności z wymaganiami zewnętrznymi dotyczącymi tych dokumentów (np. ściśle określony format lub zawartość informacyjna dla dokumentów skierowań, zleceń, recept)

Elektroniczna Dokumentacja Medyczna i Archiwum EDM L.p. Wymaganie 1. Elektroniczna Dokumentacja Medyczna 2. Moduł działa za pośrednictwem przeglądarki WWW 3. Możliwość archiwizacji dokumentacji medycznej w postaci elektronicznej. 4. Możliwość archiwizacji dokumentów złożonych, wieloczęściowych i przyrostowych tj księgi 5. Możliwość obsługi załączników do dokumentów 6. Możliwość automatycznej rejestracji dokumentów elektronicznych generowanych przez system medyczny w repozytorium dokumentacji elektronicznej 7. Możliwość rejestracji dokumentów elektronicznych utworzonych poza systemem HIS, manualna rejestracja dokumentów zewnętrznych 8. Cyfryzacja dokumentu papierowego i dołączanie go do dokumentacji elektronicznej 9. Dostęp do całości dokumentacji przechowywanej w EDM: 10. - z poziomu wbudowanych w systemy medyczne mechanizmów 11. - z poziomu dedykowanego interfejsu 12. Możliwość exportu/importu dokumentu elektronicznego do/z pliku w formacie XML 13. Możliwość złożenia podpisu elektronicznego na dokumencie oraz na zbiorze dokumentów 14. Możliwość złożenia podpisu elektronicznego na zbiorze dokumentów 15. Możliwość znakowania czasem dokumentu 16. Możliwość wykonania kontrasygnaty 17. Możliwość weryfikacji podpisu 18. Możliwość weryfikacji integralności dokumentu 19. Możliwość wydruku dokumentu 20. Możliwość wyszukiwania dokumentów za pomocą zaawansowanych kryteriów oraz meta danych. 21. Możliwość wersjonowania przechowywanych dokumentów z dostępem do pełnej historii poprzednich wersji. 22. Repozytorium EDM musi umożliwiać: - rejestrację dokumentu - pobieranie dokumentów w formacie XML - pobieranie dokumentów w formacie PDF - wyszukiwanie materializacji dokumentów 23. Repozytorium EDM musi współdzielić z HIS: - słownik jednostek organizacyjnych - rejestr użytkowników - rejestr pacjentów 24. System uprawnień pozwalający na precyzyjne definiowanie obszarów dostępnych dla danego użytkownika pełniącego określoną rolę. 25. Możliwość zarządzania uprawnieniami dostępu do określonych operacji w repozytorium. Przykłady uprawnień systemowych: uruchomienie systemu, zarządzanie uprawnieniami użytkowników, zarządzanie parametrami konfiguracyjnymi, zarządzanie typami dokumentów. 26. Możliwość zarządzania uprawnieniami do wykonywania operacji na poszczególnych typach dokumentów w ramach całej placówki lub poszczególnych jednostek organizacyjnych. Przykłady uprawnień do dokumentów: dodawanie dokumentów do repozytorium, odczyt dokumentu, podpisywanie dokumentu, znakowanie czasem dokumentu, import i eksport dokumentu, anulowanie dokumentu, wydruk dokumentu itd. 27. Możliwość definiowania nowych typów dokumentów obsługiwanych przez repozytorium dokumentów elektronicznych. 28. Zakłada się także możliwość indeksowania dokumentów, których elektroniczna postać nie jest przechowywana w systemie HIS - np. indeksowanie dokumentów papierowych, obrazów radiologicznych przechowywanych w PACS. 29. Indeksowane powinny być wszystkie wersje dokumentu

30. Indeks powinien uwzględniać rozdzielenie danych osobowych od danych medycznych 31. Możliwość indeksowania dokumentów w celu łatwego jej wyszukiwania wg zadanych kryteriów 32. Indeks dokumentacji powinien być zorientowany na informacje o dokumencie: autor, data powstania, rozmiar, typ, data powstania itp., oraz na informacje o zdarzeniach 33. System musi umożliwić udostępnianie dokumentacji: - w celu realizacji procesów diagnostyczno-terapeutycznych w ZOZ - pacjentom i ich opiekunom - podmiotom upoważnionym np. prokurator 34. System powinien umożliwiać wymianę dokumentacji medycznej w ramach Systemu Informacji Medycznej: - bezpośrednio pomiędzy jednostkami ochrony zdrowia - za pośrednictwem systemów regionalnych - z wykorzystaniem platformy P1. Aplikacja mobilna L.p. Wymaganie 1. Aplikacja dla urządzeń mobilnych musi umożliwiać: 2. Graficzny przegląd miejsca pobytu pacjenta z zachowaniem hierarchii: sala, łózko, pacjent 3. Przypisywanie pacjentów do sal 4. Wyszukiwanie i identyfikację pacjentów po kodzie kreskowym z opaski 5. Zlecanie badań 6. Zlecanie leków 7. Przegląd wystawionych zleceń 8. Przegląd wyników badań 9. Wprowadzanie wyników pomiarów 10. Pracę na urządzeniach przenośnych (tabletach) wykorzystujących system operacyjny ios. Zamawiający wymaga również możliwości pracy w systemie Android. Medyczny portal informacyjny L.p. I Wymaganie Konfiguracja 1. Rejestracja struktury organizacyjnej Jednostki Ochrony Zdrowia w układzie hierarchicznym, w postaci interaktywnego diagramu. 2. Możliwość rejestracji i prezentacji formatowanych opisów jednostek organizacyjnych. 3. Możliwość rejestracji godzin pracy jednostek organizacyjnych; możliwość przepisania godzin pracy z informacji zarejestrowanych dla jednostki nadrzędnej. 4. Integracja rejestru struktury organizacyjnej z odpowiadającym rejestrem HIS (ang. Hospital Information System). 5. Publikacja informacji o elementach struktury organizacyjnej szpitala na Medycznym Portalu Informacyjnym. 6. Publikacja informacji o obsługach medycznych realizowanych w jednostkach organizacyjnych szpitala na Medycznym Portalu Informacyjnym. 7. Rejestracja informacji o personelu realizującym usługi medyczne; rejestracja informacji o grupach zawodowych i specjalnościach personelu. 8. Rejestracja informacji o godzinach pracy personelu (harmonogramach pracy personelu). 9. Integracja rejestru personelu z odpowiadającym rejestrem HIS. 10. Rejestracja informacji o usługach realizowanych w Jednostce Ochrony Zdrowia; rejestracja opisów usługi w postaci formatowanych tekstów; rejestracja informacji o wymagalności skierowania.

11. Definiowanie wymagalności istnienia w systemie aktywnej deklaracji POZ określonego typu w czasie rejestracji terminu realizacji wskazanej usługi. 12. Definiowanie rodzajów świadczonych usług, przypisywanie usług do zdefiniowanych rodzajów 13. Definiowanie statusu wyboru personelu dla definiowanych usług (wybór personelu dopuszczalny, niemożliwy, wymagany). 14. 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. 15. Rejestracja informacji o szczególnych warunkach udzielania usług (zalecenia dla pacjentów odnośnie realizacji usługi) w postaci formatowanych tekstów. 16. Rejestracja informacji o dokumentach (załącznikach) związanych z definiowaną usługą. 17. Definiowanie kwestionariuszy umożliwiających pozyskanie dodatkowych informacji od pacjenta w procesie rezerwacji terminu udzielenia usługi/wizyty; możliwość zdefiniowania pytań dla których podanie odpowiedzi jest wymagane, możliwość zdefiniowania pytań zamkniętych, dla których odpowiedź udzielana jest poprzez wybór pozycji na liście dostępnych wartości. 18. Integracja rejestru usług medycznych z odpowiadającym rejestrem w HIS; powiązanie usług zdefiniowanych w portalu z usługami w HIS; przepisywanie wybranych usług z HIS do rejestru portalu. 19. Publikacja informacji o wskazanej usłudze w module e-pacjent. 20. Wskazanie usług, dla których możliwa jest rezerwacja terminu udzielania usług w module e- Pacjent. 21. Rejestracja usług zlecanych stanowiących grupy badań dostępnych dla kontrahenta; przypisanie badań do usług zlecanych. 22. Rejestracja informacji o dokumentach (załącznikach) wymaganych do udzielenia usług; możliwość dołączenia pliku załącznika. 23. Przypisanie zarejestrowanych załączników do wskazanych usług. 24. Definiowanie postaci skierowań drukowanych podczas rezerwacji terminów wizyt przez jednostki współpracujące (kontrahentów) - obsługa szablonów skierowań. 25. Definiowanie dni wolnych od pracy 26. Rejestracja informacji o dostępności elementów struktury organizacyjnej Jednostek Ochrony Zdrowia; podpowiadanie definicji harmonogramów pracy jednostki na podstawie godzin otwarcia jednostki; możliwość uwzględnienia zdefiniowanych dni wolnych od pracy 27. Rejestracja przerw w dostępności elementów struktury organizacyjnej Jednostek Ochrony Zdrowia. 28. Rejestracja informacji o dostępności usług w jednostkach organizacyjnych szpitala na postawie zdefiniowanej wcześniej dostępności jednostek organizacyjnych. 29. Możliwość definiowania parametrów rezerwacji dla usług dostępnych w jednostkach organizacyjnych: maksymalna liczba jednoczasowych rezerwacji tego samego pacjenta; minimalny interwał czasu pomiędzy datą rejestracji a datą realizacji usługi; maksymalny okres czasu względem daty rezerwacji, w którym możliwe jest określenie planowanego terminu udzielenia usługi. 30. Możliwość zdefiniowania wymagalności potwierdzenia rezerwacji terminu wskazanej usługi realizowanej w danej jednostce organizacyjnej w określonym przedziale czasu przed realizacją wizyty; 31. Rejestracja informacji o dostępności usług w jednostkach organizacyjnych szpitala na postawie harmonogramu; podpowiadanie definicji harmonogramu na podstawie godzin otwarcia jednostki; możliwość rejestracji ciągłej dostępności usług w jednostkach organizacyjnych; możliwość uwzględnienia zdefiniowanych dni wolnych od pracy 32. Rejestracja informacji o dostępności personelu na podstawie harmonogramu; podpowiadanie harmonogramów dla personelu na podstawie godzin pracy zdefiniowanych w rejestrze personelu. 33. Rejestracja informacji o dostępności usług udzielanych przez określony personel na podstawie zdefiniowanej wcześniej dostępności personelu. 34. Rejestracja informacji o dostępności usług udzielanych przez określony personel na podstawie harmonogramów; podpowiadanie harmonogramów na podstawie godzin pracy personelu. 35. Możliwość dowolnej modyfikacji definiowanych dostępności: usuwanie dostępnych okresów; modyfikacja dat dostępnych okresów; dodawanie nowych okresów dostępności.

36. Możliwość zdefiniowania długości przedziału czasowego dla rezerwacji terminów udzielenia usługi przez wskazany personel; możliwość określenia maksymalnej liczby równoczesnych rezerwacji w zdefiniowanym przedziale czasowym 37. Definiowanie klas pacjentów użytkowników modułu e-pacjent 38. Definiowanie parametrów rezerwacji dla poszczególnych klas pacjentów: maksymalnej liczby rezerwacji terminów udzielenia usługi dostępnych dla pacjentów określonej klasy; maksymalny okres rezerwacji terminów udzielenia usług; tryb potwierdzenia rezerwacji (bez potwierdzenia/potwierdzenie e-mail/potwierdzenie SMS). 39. Możliwość określenia sposobu powiadamiania pacjentów określonej klasy o anulowaniu rezerwacji w jednostce ochrony zdrowia (brak powiadomień, powiadomienie SMS, powiadomienie e-mail). 40. Możliwość określenia sposobu powiadamiania pacjentów określonej klasy o zmianie planowanego terminu udzielenia usługi w jednostce ochrony zdrowia (brak powiadomień, powiadomienie SMS, powiadomienie e-mail). 41. Możliwość określenia sposobu powiadamiania pacjentów określonej klasy o potwierdzeniu planowanego terminu udzielenia usług w zintegrowanym systemie HIS (brak powiadomień, powiadomienie SMS, powiadomienie e-mail). 42. Możliwość określenia sposobu powiadamiania pacjentów określonej klasy o potwierdzeniu planowanego terminu udzielenia usług w zintegrowanym systemie HIS (brak powiadomień, powiadomienie SMS, powiadomienie e-mail). 43. Możliwość określenia sposobu powiadamiania pacjentów określonej klasy o zbliżającym się terminie udzielenia usługi (brak powiadomień, powiadomienie SMS, powiadomienie e-mail), możliwość określenia interwału czasu przed planowanym terminem udzielenia usługi, kiedy zostanie wysłane powiadomienie; możliwość definiowania wielu powiadomień o zbliżającym się terminie udzielenia usługi dla danej rezerwacji. 44. Możliwość definiowania uprawnień do modułu e-pacjent dla pacjentów określonej klasy; integracja uprawnień do modułu e-pacjent z uprawnieniami zarządzanymi w administratorze systemu. 45. Przegląd pacjentów zarejestrowanych w Medycznym Portalu Informacyjnym. 46. Zatwierdzenie zarejestrowanych pacjentów jako użytkowników Szpitalnego Portalu Informacyjnego przez pracowników szpitala (autoryzacja przez pracowników szpitala). 47. Rejestracja pacjentów jak użytkownika Medycznego Portalu Informacyjnego przez pracowników szpitala możliwość udostępnienia funkcjonalności e-pacjent bez konieczności rejestrowania się pacjenta na stronie internetowej. 48. Przypisanie pacjentom - użytkownikom MPI podopiecznych; możliwość rejestracji danych podopiecznych nie zarejestrowanych wcześniej w systemie. 49. Możliwość zablokowania konta pacjenta - zablokowania dostępu wybranym pacjentom do e- Pacjenta 50. Możliwość wygenerowania raportów zawierających: - wykaz pacjentów z liczbą dokonanych rezerwacji internetowych (wyszukanie pacjentów, którzy wykonali najwięcej rezerwacji internetowych), - wykaz pacjentów z liczbą niewykorzystanych rezerwacji tj. nieoznaczonych jako zrealizowane z przekroczonym planowanym terminem wizyty. 51. Integracja rejestru pacjentów z odpowiadającym rejestrem w HIS; możliwość wyszukiwania pacjentów zarejestrowanych wg identyfikatora w systemie HIS. 52. Możliwość definiowania postaci wiadomości automatycznie generowanych przez system - definiowanie szablonów wiadomości; 53. Możliwość przypisania zdefiniowanych szablonów wiadomości związanych z zaplanowanymi/realizowanymi usługami do rodzaju usług - możliwość zdefiniowania różnych szablonów wiadomości dla różnych typów usług 54. Wysyłanie wiadomości do pacjentów zarejestrowanych w MPI (wiadomości powinny być prezentowane w module e-pacjent); wysyłanie wiadomości do wszystkich pacjentów; wysyłanie wiadomości do wybranych pacjentów; wysyłanie komunikatów wiadomości, na które nie można odpowiadać; możliwość formatowania treści wiadomości (czcionka, kolor, justowanie, odnośniki do innych stron). 55. Możliwość wysyłania wiadomości e-mail do pacjentów użytkowników portalu. 56. Możliwość wysyłania wiadomości SMS do pacjentów użytkowników portalu. 57. Przegląd wysłanych wiadomość; wyróżnienie wiadomości nieprzeczytanych; wyszukiwanie

wiadomości wg tematu, daty wysłania i odbiorcy. 58. Edycja nieprzeczytanych, wysłanych wiadomości. 59. Logiczne usunięcie wiadomości oznaczenie wiadomości jako usuniętej niewidocznej dla adresatów. 60. Przegląd wiadomości odebranych od pacjentów; wyszukiwanie wiadomości wg tematu, daty wysłania, nadawcy; wyróżnienie wiadomości nieprzeczytanych. II e-pacjent 1. Rejestracja nowego pacjenta użytkownika systemu 2. Potwierdzenie rejestracji pacjenta poprzez wprowadzenie kodu udostępnionego przez SMS. 3. Potwierdzenie rejestracji pacjenta poprzez wprowadzenie kodu udostępnionego przez e-mail. 4. Możliwość samodzielnej autoryzacji (określenie danych dostępowych login/hasło) użytkownika pacjenta po poprawnym potwierdzeniu rejestracji; możliwość wyłączenia trybu samodzielnej autoryzacji pacjentów. 5. Możliwość ograniczenia samodzielnej autoryzacji użytkowników pacjentów do osób zarejestrowanych w zintegrowanym systemie HIS (na podstawie zgodności numeru PESEL i nazwiska); możliwość wyłączenia trybu autoryzacji pacjentów w oparciu o rejestr zintegrowanego systemu HIS. 6. Logowanie pacjenta/użytkownika autentykacja użytkownika systemu. 7. Aktualizacja profilu pacjenta/użytkownika MPI; możliwość aktualizacji danych kontaktowych: adresu e-mail, nr-telefonu; adresu zamieszkania. 8. Możliwość zablokowania zmiany danych osobowych pacjenta (imię, nazwisko, PESEL) w profilu pacjenta. 9. Możliwość rejestracji podopiecznych pacjenta; dla podopiecznych, którzy są użytkownikami MPI konieczność akceptacji objęcia opieką przez innego pacjenta; możliwość odrzucenia wniosku o objęcie opieką przez innego pacjenta - użytkownika e-pacjent lub możliwość trwałego zablokowania wnioskowania o objęcie opieką przez danego użytkownika. 10. Możliwość przeglądu opiekunów; możliwość usunięcia opiekuna; możliwość zablokowania opiekuna - opiekun nie będzie miał możliwości ponownego wnioskowania o objęcie opieką. 11. Możliwość określenia przez pacjenta parametrów powiadomień o zbliżającym się terminie udzielenia usługi (interwał czasu przed planowanym terminem, tryb powiadamiania) zdefiniowanych w systemie jako możliwe do ustawienia przez użytkownika/pacjenta. 12. Możliwość zmiany hasła pacjenta użytkownika MPI. 13. Możliwość ustawienia nowego hasła, po poprawnej weryfikacji adresu e-mail lub numeru telefonu poprzez wprowadzenie przesłanego kodu potwierdzenia. 14. Rezerwacja terminu udzielenia usługi wskazanie daty i czasu planowanej realizacji wizyty, miejsca realizacji (element struktury organizacyjnej) i personelu realizującego (opcjonalnie; w zależności od statusu wyboru personelu zdefiniowanego dla usługi). 15. Możliwość/konieczność rejestracji danych skierowania w czasie rezerwacji terminu udzielenia dla usług o odpowiednim statusie wymagalności danych skierowania. 16. Grupowanie usług do rezerwacji wg zdefiniowanych rodzajów usług. 17. Grupowanie usług wg zawodu personelu realizującego (np. lekarze, lekarze-dentyści, fizjoterapeuci). 18. Przegląd rejestru rezerwacji wizyt pacjenta z wyróżnieniem stanu usługi (planowana, zrealizowana, anulowana). 19. Możliwość anulowania przez pacjenta rezerwacji wizyty. 20. Możliwość zmiany terminu wizyty przez pacjenta. 21. Możliwość rezerwacji terminu wizyty dla podopiecznych; możliwość zmiany terminu wizyt dla podopiecznych; możliwość anulowania rezerwacji podopiecznych 22. Wydruk potwierdzenia rezerwacji wizyty zawierający informacje o usłudze, miejscu realizacji oraz planowaną datę udzielenia usługi. 23. Możliwość wysyłania przez SMS, e-mail lub wiadomości na portalu pacjenta przypomnień o zbliżających się terminach wizyt. 24. Możliwość wysyłania przez SMS, e-mail lub wiadomości na portalu pacjenta powiadomień o anulowaniu rezerwacji przez pracowników jednostki ochrony zdrowia.

25. Możliwość wysyłania przez SMS, e-mail lub wiadomości na portalu pacjenta powiadomień o zmianie terminu realizacji usługi dokonanej przez pracowników jednostki ochrony zdrowia. 26. Wysyłanie wiadomości do jednostki ochrony zdrowia; możliwość formatowania treści wiadomości (czcionka, kolor, justowanie, odnośniki do innych stron). 27. Wysyłanie wiadomości SMS, e-mail lub wiadomości na portalu pacjenta o konieczności potwierdzenia rezerwacji terminu wizyty 28. Potwierdzenie rezerwacji wizyty w określonym czasie przed realizacją dla rezerwacji wymagających takich potwierdzeń 29. Przegląd wysłanych wiadomość; wyróżnienie wiadomości nieprzeczytanych; wyszukiwanie wiadomości wg tematu, daty wysłania i odbiorcy. 30. Edycja wysłanych i jeszcze nieprzeczytanych przez pracowników jednostki ochrony zdrowia wiadomości. 31. Przegląd wiadomości odebranych od pacjentów; wyszukiwanie wiadomości wg tematu, daty wysłania, nadawcy; wyróżnienie wiadomości nieprzeczytanych. III Administrator MPI 1. Zgodność koncepcji mechanizmu kontroli dostępu do funkcji systemu z RBAC (ang. Rolebased Access Control). 2. Definiowanie nowego użytkownika. 3. Przegląd i modyfikacja danych użytkowników. 4. Tworzenie grup użytkowników; przyporządkowanie użytkowników do grup. 5. Przydzielanie uprawnień i ról użytkownikom i grupom użytkowników. 6. Przegląd efektywnych uprawnień użytkownika wynikających z przynależności do grup użytkowników, przypisanych ról i praw. 7. Możliwość przydzielania uprawnień do zmieniających się w czasie zasobów. 8. Definiowanie polityk poziomu bezpieczeństwa hasła użytkownika, możliwość przypisania wskazanych polityk do użytkowników. 9. Kontrola złożoności hasła użytkownika zgodnie z przypisaną polityką poziomu bezpieczeństwa. 10. Dostępność interfejsu umożliwiającego integrację użytkowników z dotychczas użytkowanym systemem (interfejsy na poziomie bazy danych i języków wysokiego poziomu). 11. Dostępność interfejsu do kontroli praw przyznanych użytkownikom (interfejsy na poziomie bazy danych i języków wysokiego poziomu). 12. Dostępność interfejsu do zarządzania prawami przyznanych użytkownikom (interfejsy na poziomie bazy danych i języków wysokiego poziomu). 13. Użytkownicy systemu nie odpowiadają bezpośrednio użytkownikom systemu zarządzania bazą danych. 14. Możliwość delegowania uprawnień do administrowania uprawnieniami w poszczególnych podsystemach. Wymagania dla oprogramowania uzupełniającego Żywienie szpitalne Lp. Wymagania 1. Możliwość tworzenia jadłospisów na wskazany dzień. 2. Możliwość określenia dowolnej liczby różnych diet w jednym jadłospisie oraz ich bieżącej modyfikacji. 3. Możliwość zdefiniowania co najmniej następujących posiłków dla każdej diety: 3.1. - śniadanie, 3.2. - drugie śniadanie, 3.3. - obiad, 3.4. - podwieczorek,

3.5. - kolacja, 3.6. - posiłek nocny 4. Tworzenie meldunku z zamówieniem na posiłki dla pacjentów i pracowników z oddziałów. Liczba zamawianych posiłków w ramach nomenklatury diet może być różna (różna ilość zamawianych posiłków na dany dzień w ramach diety). System musi umożliwiać ręczne wprowadzenie zamówień na posiłki dla pacjentów i pracowników z poszczególnych jednostek szpitala wraz ze wskazaniem jakiej diety i jakiej grupy osób one dotyczą. 5. Ewidencja korekt meldunków z konfigurowanym ograniczeniem czasowym ich składania. 6. Ewidencja zamówień specjalnych dla pracowników szpitala. 7. Możliwość elektronicznego składania meldunków i ich korekt z jednostek zamawiających. 8. Tworzenie meldunków w jednostkach zamawiających wykorzystuje dane z ruchu chorych. 9. Możliwość drukowania jadłospisu dla każdej diety oddzielnie. 10. Możliwość drukowania surowców (sumarycznie) potrzebnych do realizacji jadłospisu. 11. Tworzenie zamówienia do modułu gospodarki magazynowej na produkty niezbędne do realizacji jadłospisu przez jednostki odpowiedzialne za realizację poszczególnych diet. Możliwość ręcznej modyfikacji ilości produktów do wydania z magazynu żywności. 12. Generowanie rozdzielnika kosztów żywienia w rozbiciu na jednostki zamawiające. 13. Możliwość drukowania wartości składników odżywczych dla posiłków jadłospisu i dla diet w jadłospisie. 14. Możliwość drukowania wyceny posiłków w jadłospisie w odniesieniu do stanów magazynowych na podstawie średniej ceny z ostatnich dostaw. 15. Możliwość zestawienia niezbędnych surowców dla wskazanej diety w wybranym jadłospisie. 16. Możliwość określania wartości składników odżywczych jadłospisu dla poszczególnych diet. 17. Możliwość generowania zapotrzebowania dla surowców będących na aktualnym stanie magazynu. 18. Możliwość usunięcia potrawy pozwalająca na zmianę ilości potraw przydzielonych do danego posiłku jadłospisie. 19. Możliwość definiowania informacji o składnikach odżywczych dla każdego z produktów. 20. Przychody i rozchody codzienne w magazynie żywnościowym. 21. Współpraca z systemem księgowym w zakresie obsługi magazynu żywnościowego oraz dokumentów właściwych dla księgowości materiałowej. 22. Możliwość zlecenia wystawiania dowodów RW. 23. Możliwość składania zamówień na towary niezbędne do obsługi działu żywienia. 24. Dostępność dokumentacji użytkownika w języku polskim. 25. Możliwość wydruku utworzonych jadłospisów/diet wraz z gramaturą posiłku oraz opcjonalną możliwością wydruku informacji o wybranych lub wszystkich parametrach wartości odżywczych dla każdej z potraw. Możliwość zdefiniowania, które parametry wartości odżywczych są istotne dla każdej z diet i są wymagane na

zestawieniu. 26. System umożliwia zdefiniowanie granicy czasowej do której możliwe jest składanie elektronicznych meldunków z zamówieniami oraz zdefiniowanie granicy czasowej do której możliwe jest składanie elektronicznej informacji o korekcie złożonych wcześniej meldunków z zamówieniem na posiłki w ramach diet. Granica czasowego składania korekt meldunków jest definiowana oddzielnie dla każdego z posiłków. Integracja HIS, EDM i systemu radiologicznego Wymagania ogólne Lp. Wymagania 1. W ramach równoległego postępowania Zamawiający zakupi Szpitalny System Radiologiczny 2. W ramach zamówienia Wykonawca wykona dwukierunkową integrację Systemu Elektronicznej Dokumentacji Medycznej oraz HIS ze Szpitalnym Systemem Radiologicznym oraz z wykorzystaniem standardu wymiany informacji w systemach medycznych HL7, dopuszczalnie uzupełniając w oparciu o inne mechanizmy integracji (np. na poziomie bazy danych )ponosząc koszty wyłącznie po swojej stronie. 3. Wykonawca w ramach zamówienia przygotuje i udostępni dokumentację oraz interfejs HL7 w wersji 2.x (oraz dokumentację w przypadku wykorzystywania innych dodatkowych technologii) służący do integracji z systemem radiologicznym zgodnie z opisem przedmiotu zamówienia. 4. Wszelkie dostarczane moduły muszą umożliwiać pełną wymianę automatyczną informacji z obecnym HIS 5. Integracja pozwoli na wymianę danych w czasie rzeczywistym. Wymagania szczegółowe - badania radiologiczne 1. 2. Minimalne wymagania dla integracji systemu radiologicznego z systemem HIS oraz EDM Uruchomienie integracji pomiędzy EDM oraz HIS i systemem radiologicznym w zakresie niezbędnym do obsługi aparatów i wykonywania opisów oraz prowadzenia dokumentacji medycznej w formie elektronicznej zgodnie z przepisami prawa w tym zakresie. Umożliwienie rejestracji przyjęcia pacjenta w jednym systemie, system HIS jest systemem nadrzędnym. Jeśli pacjentowi np. zarejestrowanemu w systemie HIS zostanie zlecone badanie diagnostyczne to niezbędne dane zostaną przekazane do systemu radiologicznego i będą dostępne w systemie EDM. 3. Warstwa transportowa oparta jest o protokół TCP/IP z potwierdzeniami transportowymi ACK 4. System HIS wysyła komunikaty HL7 informujące system radiologiczny o dopisaniu (ADT^A28), modyfikacja (ADT^A31), skasowaniu (ADT^A29) danych pacjenta. Dodatkowo wysyłany jest komunikat połączenia dwóch rekordów pacjenta w jeden wpis (ADT^A30). System szpitalny może również wysyłać komunikat zmiany identyfikatora pacjenta (ADT^47).

5. System HIS wysyła komunikaty dotyczące zleceń: Nowe zlecenie, Anulowanie: ORM^O01 6. System radiologiczny odsyłała komunikat ORM^O01 zmiany stanu zlecenia (np. wykonane badanie, anulowanie / odrzucenie badania z podaniem powodu). Scenariusz podstawowy realizacji System HIS: 1. Wprowadzenie zlecenia na badanie, skierowanie do rejestracji pracowni diagnostycznej. 2. Rejestracja: Przyjęcie pacjenta do realizacji. Następuje wygenerowanie komunikatu HL7: ORM^O01 do systemu radiologicznego System Radiologiczny: 7. 3. Przyjęcie zlecenia, przygotowanie worklisty na aparacie. 4. Realizacja zleconego badania na aparacie. Po realizacji system radiologiczny generuje komunikat ORM^O01 do HIS informujący o wykonaniu badania. Pola komunikatu HL7: ORC.1=SC, ORC.5=CM (zmienią status zlecenia w HIS na NWYK (wykonane nieautoryzowane). System HIS: 5. Po przyjęciu komunikatu zmiany stanu z systemu radiologicznego, zmiana stanu zlecenia na Wykonane nieautoryzowane. Automatyczne dodanie informacji, która umożliwi wywołanie przeglądarki obrazów z PACS. 6. Pracownia: Realizacja opisu badania, wprowadzenie danych rozliczeniowych, autoryzacja wyniku. Po autoryzacji wynik widoczny u zleceniodawcy. Pkt 6. scenariusza może być wykonany z pominięciem pkt 4-5. Scenariusz dodatkowy realizacji 8. 9. 10. 11. Zamawiający oczekuje również możliwości działania funkcjonalności wykonywania opisów badań w systemie radiologicznym (punkt 6 scenariusza podstawowego), z zastrzeżeniem że opisany wynik badania zostanie wysłany komunikatem HL7 ORU^R01 do systemu HIS. Scenariusz musi być możliwy do realizacji w przypadku awarii komunikacji HL7 z systemem HIS. System HIS umożliwi wywołanie dowolnej aplikacji (plik wykonywalne exe) z parametrami: identyfikator pacjenta z HIS lub identyfikator zlecenia HIS. Wykonawca systemu radiologicznego przygotuję stosowne wywołanie do konfiguracji systemu HIS i udostępni możliwość uruchamiania przeglądarki. W oknie związanym z realizacją z zlecenia w systemie HIS, gdzie wprowadzany jest opis badania można bezpośrednio wywołać przeglądarkę obrazów systemu radiologicznego. Scalanie kart pacjenta wywoływane w systemie HIS, scala karty pacjenta w systemie radiologicznym.

12. 13. 14. 15. 16. 17. Zmiana danych lub uzupełnienie danych zlecenia, np. lekarza zlecającego, jednostki zlecającej w HIS modyfikuje dane w systemie radiologicznym. Godzina rzeczywistego wykonania badania na aparacie wysyłana jest do programu HIS nawet jeśli wg harmonogramu/planu była inna godzina. Możliwość odrzucenia w systemie radiologicznym zlecenia (np. badania niezarejestrowanego w słowniku). Przekazywanie przez system radiologiczny do systemu HIS informacji o stanie realizacji badania automatycznie zmieniające się statusy w systemie HIS. Testy akceptacyjne integracji wykonane zostaną po dostarczeniu i konfiguracji systemu na infrastrukturze Zamawiającego. Zamawiający jest w posiadaniu dokumentacji technicznej na integrację systemów zewnętrznych HIS z wykorzystaniem protokołu HL7 w wersji 2.x posiadanego oprogramowania Infomedica firmy Asseco. Wymagania dotyczące szkoleń Wymagania ogólne Zamawiający, w ramach szkolenia użytkowników, przewiduje szkolenia grupowe, indywidualne i poprzez system platformy e-learning. Wykonawca przeprowadzi szkolenia niezbędne w zakresie uruchomienia dostarczanego oprogramowania do prawidłowego posługiwania się wszystkich użytkowników dostarczonym oprogramowaniem w celu prowadzenia Elektronicznej Dokumentacji Medycznej oraz wykorzystywania wszystkich nowych funkcji dostarczonego oprogramowania. Szczegółowy harmonogram prac i liczba osób do przeszkolenia zostaną ustalone w trakcie analizy przedwdrożeniowej. Szkolenia obejmować będą: administrowanie wszystkimi wymienionymi modułami oprogramowania aplikacyjnego, eksploatacja modułów oprogramowania aplikacyjnego. W ramach szkolenia (podczas wdrożenia) Wykonawca przekaże użytkownikom pełną wiedzę niezbędną do poprawnego użytkowania modułów, potrzebną do wykonywania obowiązków służbowych na zajmowanym stanowisku pracy.

Wymagania szczegółowe Przed rozpoczęciem szkoleń, Wykonawca przeszkoli wszystkich administratorów Zamawiającego w pełnym zakresie oferowanego oprogramowania. Szkolenia nie mogą odbywać się w grupach większych niż 10 osób. Przed przystąpieniem do szkoleń Wykonawca uruchomi bazy testowe systemu, tak by umożliwić użytkownikom testowanie funkcjonalności modułów. Wykonawca jest zobowiązany do przeszkolenia osób wskazanych przez Zamawiającego. 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ących w szkoleniu. Wykonawca w celu wspomożenia procesu szkolenia udostępni szkolenia poprzez platformę e-learningową. Wykonawca po zawarciu umowy dostarczy harmonogram proponowanych szkoleń wraz z ich metodologią do akceptacji Zamawiającego. Personel szkolący Zamawiający wymaga, by szkolenia grupowe i indywidualne personelu Zamawiającego przeprowadzały osoby posiadające doświadczenie w zakresie produktów, których dotyczyć będzie szkolenie. Osoby szkolące winny być dyspozycyjne w trakcie trwania szkoleń. Wymagany jest stały kontakt roboczy z Zamawiającym. Wykonawca przekaże Zamawiającemu wykaz numerów telefonów kontaktowych do osób wykonujących szkolenia. Zamawiający wymaga, by wszelkie zastępstwa lub trwała zmiana w osobach szkolących zgłaszana była niezwłocznie przez Wykonawcę, z zastrzeżeniem, że osoba zastępująca musi posiadać nie mniejsze 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 szkolącej. Wymagania dotyczące wdrożenia Wymagania ogólne Zamawiający wymaga od Wykonawcy przeprowadzenia następujących czynności rodzajowych dla każdego z dostarczanych programów:

analiza przedwdrożeniowa zarządzanie projektem po stronie Wykonawcy bieżąca komunikacja z kierownikiem projektu po stronie Zamawiającego instalacja oprogramowania weryfikacja instalacji przygotowanie bazy szkoleniowej, materiałów szkoleniowych konfiguracja stacji roboczych Zamawiającego szkolenie personelu na sali szkoleniowej konfiguracja modułów nadzór nad wdrożeniem konsultacje uruchomieniowe, asysta wdrożeniowa stanowiskowa przygotowanie przedmiotu zamówienia do odbiorów Instalacja i wdrożenie winny odbywać się w godzinach pracy pracowników Zamawiającego tj. w dni robocze (od poniedziałku do piątku), w godz. 7.30-14:30. Zamawiający dopuszcza wykonywanie prac w innym czasie niż wskazany, po odpowiednim uzgodnieniu i jego akceptacji. Po dokonaniu instalacji i wdrożenia docelowo system powinien: spełniać wymagania określone niniejszą SIWZ, uwzględniać charakter prowadzonej przez Zamawiającego działalności oraz spełniać wymagania obowiązujących przepisów prawa Zamawiający przeprowadził analizę czasochłonności przeprowadzenia wdrożenia obejmującego swoim zakresem także przeprowadzenie szkoleń tradycyjnych w zakresie wykonania całości zamówienia na co najmniej 250 osobodni. Standardy wdrożeniowe Wykonawca zobowiązany jest przedłożyć w ofercie opis Standardów Wdrożeniowych zawierający w minimalnym zakresie informacje, do których odwołuje się wzór Umowy oraz: obligatoryjne czynności administratora w trakcie wdrożenia i eksploatacji systemu, zasady komunikacji pomiędzy stronami, zasady dokumentowania prac, wykaz elementów mogących stanowić ewentualne problemy przy realizacji wdrożenia, wykaz zaniechań Zamawiającego powodujących dla niego skutki finansowe, szczegółowe procedury odbiorów, procedury przeprowadzenia testów weryfikacyjnych, zasady realizacji wdrożenia personelu wraz z określeniem zakresu w podziale na poszczególne grupy zawodowe,