Kleszczowska Przychodnia Salus Sp z o o. ul. Osiedlowa 2, 97-410 Kleszczów



Pobieranie 0,94 Mb.
Strona4/14
Data15.02.2018
Rozmiar0,94 Mb.
1   2   3   4   5   6   7   8   9   ...   14

Wymagania architektury systemu – wymagania ogólne systemu i wdrożenia


L.p.

WYMAGANIA

WYMAGANIA OGÓLNE WDROŻENIA:

1.

Wdrożenie obejmie usługi niezbędne do uruchomienia i późniejszej eksploatacji.

2.

Analizą przedwdrożeniową objęte zostanie oprogramowanie dotychczas funkcjonujące u Zamawiającego oraz będące w posiadaniu Zamawiającego informacje i dane niezbędne do wdrożenia Systemu.

3.

System zostanie dostarczony w postaci zainstalowanej i skonfigurowanej na serwerach klienta oraz instrukcji instalacji i konfiguracji systemu na stacjach roboczych wraz z niezbędnym oprogramowaniem instalacyjnym

4.

System zostanie dostarczony wraz z dokładnymi pisemnymi procedurami i instalacjami tworzenia i odtwarzania kopii zapasowych każdego z elementów systemu tak, aby przeprowadzenie tych czynności mogło zostać wykonane wyłącznie przez administratorów systemu Zamawiającego

5.

Zamawiający przeprowadzi pod nadzorem Wykonawcy testy wykonania pełnej kopii bezpieczeństwa i odzyskania pełnego Systemu z tych kopii według dostarczonych pisemnych procedur

6.

Wykonawca dostarczy dokumentację elementów Systemu w wersji elektronicznej. Wykonawca przeszkoli wskazanych przez Zamawiającego użytkowników – liderów w zakresie odpowiednim dla danego użytkownika – lidera

7.

Wykonawca przeszkoli w zakresie czynności administracyjnych/utrzymaniowych Systemu wskazanych przez Zamawiającego administratorów.

8.

Wykonawca przekaże wszystkie konta i hasła administracyjne do każdego z elementów dostarczonego Systemu.

9.

Wykonawca zapewni wsparcie techniczne, helpdesk oraz ewentualne szkolenie nowych administratorów w zakresie czynności administracyjnych / utrzymaniowych przez cały okres trwania umowy

ADMINISTRATOR I OGÓLNE WYMAGANIA

WYMAGANIA OGÓLNE

10.

Wszystkie moduły systemu zaopatrzone są w graficzny interfejs użytkownika. Zapewniona praca w środowisku graficznym na wszystkich stanowiskach użytkowników.

11.

System komunikuje się z użytkownikiem w języku polskim.

12.

Dostępność polskich znaków diakrytycznych wymagana jest w każdym miejscu i dla każdej funkcji w systemie - dotyczy także wyszukiwania, sortowania (według kolejności liter w polskim alfabecie), drukowania i wyświetlania na ekranie.

13.

Do wybranych funkcji programu przypisane są skróty klawiszowe.

14.

Opcja podglądu wydruku jest dostępna dla wszystkich drukowalnych dokumentów, za wyjątkiem dokumentów drukowanych rutynowo, dla których podgląd wydruku mógłby niepotrzebnie wydłużać nakład pracy użytkownika.

15.

Funkcje ogólne związane z obsługą pacjenta, z wyłączeniem modułów integrujących się bezpośrednio z urządzeniami medycznymi:

  • system w zakresie wszystkich funkcji obsługi pacjenta z wyłączeniem modułów bezpośrednio integrujących się z urządzeniami medycznymi działa jako aplikacja systemu Windows w architekturze klient – serwer, bez konieczności użycia przeglądarki

  • system nie wymaga dodatkowej instalacji oprogramowania klienckiego na stacji roboczej (np. klienta bazy danych) Cała instalacja powinna być zawarta w ramach jednego instalatora. Z wymogu tego jest wyłączone przygotowanie stacji roboczej do pracy w domenie sieciowej.

  • system nie może wymagać korzystania ze specjalnych programów klienckich emulujących przeglądarkę WWW w celu uruchomienie lokalnego aplikacji

  • system powinien być zrealizowany jako desktopowa aplikacja typu klient – serwer

  • aplikacja zainstalowana lokalnie nie może w zakresie funkcjonalności HIS korzystać z aplikacji wywoływanych w oknie przeglądarki. Z wymogu tego są wyłączone elementy systemu korzystające z rozwiązań w zakresie pokazywania wyników zleceń oraz integracji urządzeniami medycznymi

  • praca w środowisku desktopowym systemu Windows w wersjach od 7 do 10

  • centralna aktualizacja aplikacji na serwerze aplikacji w taki sposób, aby każda stacja robocza po aktualizacji mogła działać pod kontrolą najnowszej wersji aplikacji bez konieczności aktualizacji modułów na każdej stacji z osobna.

  • centralny mechanizm zarządzania wydrukami. Definiowanie i konfiguracja wydruków odbywa się z jednego miejsca w systemie bez konieczności instalacji wydruków na stacjach użytkowników

  • system komunikuje się z użytkownikiem w języku polskim.

  • komunikacja pomiędzy klientem końcowym aplikacji a serwerem aplikacji może odbywać się poprzez szyfrowane połączenie

  • system zaopatrzony jest w funkcję walidacji wprowadzanych danych. Walidacja odbywa się z wykorzystaniem predefiniowanych reguł. Alert walidacji co najmniej w formie wyróżnienia kolorem, dla danych wprowadzanych w pojedynczym polu jest pokazywany użytkownikowi natychmiast po wprowadzeniu tych danych.

  • system zaopatrzony jest w funkcję walidacji danych pod kątem rozliczenia z NFZ. Błędy w danych rozliczeniowych nie blokują możliwości wykonywania innych funkcji dokumentacji medycznej i zleceń oraz związanych z ruchem chorych (np. przyjęcie, wypis, przeniesienie)

  • błędy walidacji danych istotnych dla rozliczenia z NFZ są prezentowane w wyraźny sposób podczas przeglądania danych hospitalizacji

  • system walidacji na danych istotnych dla rozliczenia z NFZ jest konfigurowalny w zakresie co najmniej dodawania nowych walidacji przez informatyków zamawiającego po uprzednim przeszkoleniu przez dostawcę.

  • oferowany jest wybór spośród minimum dwóch trybów pracy ("kompozycji"). Tryb pracy powinien charakteryzować się takimi cechami jak szata kolorystyczna (np. jasna czcionka i ciemne tło w przypadku, kiedy użytkownik korzysta z komputera w zaciemnionym pomieszczeniu)

  • definiowanie dla każdej jednostki organizacyjnej niezależnych zestawów podręcznych procedur ICD9, zleceń, leków

  • w polach opisowych i tekstowych formularzy medycznych system automatycznie weryfikuje wprowadzany tekst z wykorzystaniem słownika ortografii języka polskiego

  • możliwe jest działanie aplikacji w tzw. trybie pilnym, pozwalający szybkie wykonanie czynności z minimalną ilością włączonych walidacji tak, aby wykonać obsługę pacjenta z minimalną ilością danych

16.

System prowadzi bazę użytkowników wraz informacjami odnośnie ich uprawnień

17.

System obsługuje słownik płci zgodnie z normą PN-ISO 5218: płeć nieokreślona, mężczyzna, kobieta, nieznana

18.

Możliwość ręcznego uruchomienia weryfikacji ubezpieczenia z wykorzystaniem systemu eWUŚ dla dowolnego pacjenta oraz automatycznego dla hospitalizacji, planowanych wizyt i wizyt odbytych w danym dniu

19.

System weryfikacji ubezpieczenia w eWUŚ wysyła na adres e-mail codzienne raporty zawierające podsumowanie automatycznego sprawdzania oraz ewentualnych błędów, które wystąpiły. Istnieje możliwość definiowania listy obiorców takich raportów

20.

System nie wymaga instalowania aplikacji na każdej ze stacji roboczych. Dotyczy to również instalowania innych elementów wymaganych do działania aplikacji (np. klient bazodanowy)

21.

Instalacja i aktualizacja systemu odbywa się na serwerze

22.

Jeśli konieczna jest przerwa serwisowa to proces aktualizacji powinien wyglądać następująco:

  • Ustawienie przerwy serwisowej w aplikacji

  • Aplikacja automatycznie, w widocznym miejscu, powiadamia użytkowników o zbliżającej się przerwie serwisowej

  • 10 minut przed przerwą serwisową aplikacja wyświetla niedający się zamknąć monit o zbliżającej się przerwie i konieczności przerwania pracy.

  • W przypadku niezamknięcia aplikacji w pkt 3 przez użytkownika, jest ona zamykana automatycznie na minutę przed przerwą serwisową

  • W przypadku próby uruchomienia aplikacji po rozpoczęciu przerwy serwisowej użytkownik otrzymuje informacji o niemożności uruchomienia ze względu na przerwę.

  • Administrator systemu inicjuje aktualizację. Istnieje również opcja aktualizacji w pełni automatycznej o zadanej dacie godzinie.

  • Podczas aktualizacji aplikacji następują operacje:

  • Podmiany plików aplikacji

  • Uruchomienie skryptu aktualizującego bazę danych

  • Zapisywany jest log aktualizacji z informacjami technicznymi (np. informacje, ew. błędy w uruchomieniu skryptu aktualizacyjnego)

  • Administrator ustawia koniec przerwy serwisowej. Użytkownicy mogą się logować do systemu. Istnieje opcja automatycznego końca przerwy serwisowej po automatycznej aktualizacji.

23.

System umożliwia zarządzanie użytkownikami wraz z przypisaniem im uprawnień w ramach jednostki organizacyjnej. Oznacza to, że dany użytkownik może pełnić różne role w różnych jednostkach organizacyjnych

24.

System powinien umożliwiać bezpieczny zdalny dostęp dla administratora z możliwością zdalnego uruchomienia aplikacji

25.

System powinien umożliwiać bezpieczne zdalne uruchomienie aplikacji w trybie debugowania w celu analizy trudnych do rozwiązania problemów

26.

System umożliwia codzienne sprawdzanie statusu ubezpieczenia eWUŚ dla:

27.

Godziny sprawdzenia mogą być dowolnie ustawione przez administratora (z zastrzeżeniem wytycznych NFZ). Możliwa jest dowolna ilość uruchomień automatycznego sprawdzania w ciągu doby.

28.

Po automatycznym sprawdzaniu eWUŚ administrator otrzymuje mailem raport ze sprawdzenia zawierający status operacji, status logowania, liczbę ubezpieczonych, liczbę nieubezpieczonych i listę błędów podczas sprawdzania

29.

W przypadku wystąpienia błędów logowania mail z raportem jest oznaczony jako „pilny”

30.

System umożliwia przypisanie uprawnień do pozycji słownikowych

31.

System umożliwia przypisanie uprawnień użytkowników do formularzy dokumentacji

32.

System umożliwia przypisanie uprawnień do raportów

33.

System umożliwia przypisanie uprawnień do słowników czynności

34.

Uprawnienia wyżej wymienione mogą być przypisywane zarówno dla jednostki jak i użytkownika jak i kombinacji użytkownika i jednostki

35.

System umożliwia oznaczenie formularzy jako poufnych, co oznacza ograniczenie ich widoczności dla personelu spoza zespołu terapeutycznego

36.

System umożliwia definicję struktury organizacyjnej jednostki do poziomu łóżka

37.

System umożliwia zdefiniowanie powiadomień dla użytkowników systemu

38.

System umożliwia przegląd aktualnie zalogowanych użytkowników wraz IP stacji roboczej

39.

System umożliwia tworzenie i edycję grafików przez administratora systemu

40.

System zapisuje i śledzi historię zmian danych w dokumentacji medycznej

41.

System zapisuje i śledzi fakt i zakres dostępu użytkowników do danych osobowych i medycznych

42.

System zapisuje i śledzi fakt dostępu do określonych danych pobranych w raportach

43.

System śledzi i zapisuje w repozytorium dokumentów każdą materializację danych z systemu, dotyczy to w szczególności :

  • Wydruków dokumentacji

  • Wydruków raportów

  • Pliki wyeksportowane w postaci zewnętrznych formatów (PDF, RTF,arkusze kalkulacyjne)

44.

System umożliwia administratorowi przeglądanie logów pracy

45.

System umożliwia zrekonstruowanie przebiegu pracy danego użytkownika na podstawie logów

46.

System zapisuje i śledzi komunikację z zewnętrznymi systemami poprzez protokół HL7

INTEGRACJA HL7

47.

Zgodność z wersją 2.x standardu HL7

48.

Możliwość umieszczenia zleceń oczekujących w kolejce zleceń oczekujących do wysłania.

49.

Minimalny zestaw transakcji HL7 obsługiwanych przez system HIS:

  • Transakcje HIS -> Moduł dziedzinowy

  • Nowe zlecenie – ORM^O01

  • Anulowanie zlecenia – ORM^O01

  • Transakcje Moduł dziedzinowy -> HIS

  • Nowe zlecenie – ORM^O01

  • Zmiana danych zlecenia – ORM^O01

  • Anulowanie zlecenia – ORM^O01

  • Zmiana statusu zlecenia – ORM^O01

  • Wyniki – ORU^R01

50.

Możliwość przeglądania podsumowania przetwarzanych transakcji HL7 z zadanego okresu. Możliwość przefiltrowania podsumowania w celu identyfikacji transakcji błędnych

51.

Możliwość ponownego wygenerowania transakcji HL7 w przypadku awarii komunikacji z systemami zewnętrznymi.

52.

W ramach przedmiotu zamówienia, musi zostać dostarczona funkcja Serwera Terminali zgodna z pozostałymi elementami zamówienia w zakresie architektury dla oprogramowania systemowego.

53.

Zamawiający wykorzystuje obecnie stacji roboczych w oparciu o system Windows i zamierza je wykorzystać do pracy z systemem będącym przedmiotem zamówienia.

54.

System wspomaga ochronę danych osobowych - w przypadku utraty lub uszkodzenia stacji roboczej dane osobowe pozostają bezpieczne na serwerze

W przypadku awarii stacji roboczej wystarczy zmienić ją na stanowisku, a konfiguracja systemu dla użytkowników pozostaje niezmieniona



55.

Na stacjach roboczych dostępne funkcje dla modułów obsługi pacjenta z wyjątkiem bezpośrednio integrujących się z urządzeniami medycznymi, a także do modułów rozliczeń z płatnikami.

56.

System współpracuje z drukarkami sieciowymi

57.

Możliwość szyfrowania transmisji pomiędzy serwerem a klientem

58.

Możliwość zablokowania na stacji roboczej dostępu do przeglądarki WWW nie wpływa na funkcjonowanie aplikacji w zakresie systemu HIS (z wymogu są wyłączone stacje pokazujące wyniki zleceń oraz integrujące się urządzeniami medycznymi)

59.

System umożliwia pracę w środowisku domeny sieciowej Microsoft

60.

Możliwość uruchomienia aplikacji z dysku sieciowego

61.

Aplikacja uruchamia się lokalnie na stacji roboczej wykorzystując zasoby tej stacji

62.

Możliwość ograniczania modyfikacji środowiska graficznego (tzw. look & feel) dla użytkowników.

63.

System musi umożliwiać uruchamianie aplikacji na stacji roboczej tak, aby stacja robocza w możliwie dużym stopniu redukowała obciążenie zasobów serwera

64.

System musi umożliwiać pracę na podstawowym zakresie funkcji z wyłączeniem modułów wymagających instalacji dodatkowego oprogramowania specjalistycznego lub dostarczanego na inne systemy operacyjne (system ma być jednak kompatybilny z dostarczanymi peryferiami przynajmniej pod względem sterowników drukarek sieciowych, czytników kodów).

65.

Wspomaganie pracy helpdesk dla administratorów przez możliwość uruchomienia aplikacji na zdalnym pulpicie

ZARZĄDZANIE UŻYTKOWNIKAMI I SŁOWNIKAMI

66.

Wyszukiwanie użytkowników według następujących kryteriów: nazwisko, login, typ pracownika, aktywny lub nie, typ pracownika, PESEL, numer Prawa Wykonywania Zawodu.

67.

Sortowanie użytkowników według jednego z kryteriów : nazwisko, login, typ personelu, typ użytkownika

68.

Możliwość dodawania nowych użytkowników z wymuszeniem podania co najmniej imienia i nazwiska i loginu

69.

Dostęp do listy użytkowników z możliwością zmiany danych wybranego użytkownika.

70.

Prezentacja daty ostatniej zmiany hasła przez użytkownika, daty ostatniego udanego logowania

71.

Możliwość dezaktywacji konta użytkownika

72.

Dostęp do listy uprawnień z poziomu użytkownika uprawnionego do administrowania systemem.

73.

Możliwość wprowadzenia informacji o specjalizacji pracownika (co najmniej specjalizacji lekarskich)

74.

Możliwość zdefiniowana wielu grup zawodowych pracownika wraz ze wskazaniem, dla których jednostek organizacyjnych są one dedykowane (np. w sytuacji kiedy jeden pracownik pełni funkcję psychologa i psychoterapeuty).

75.

Możliwość dodawania / odbierania uprawnień wybranemu użytkownikowi, a także zaznaczonym użytkownikom.

76.

Wyszukanie typów/grup użytkowników według następujących kryteriów: nazwa, aktywny/nieaktywny

77.

Możliwość dodawania oraz edytowania nowych typów/grup użytkowników.

78.

Export / import danych użytkowników do / z pliku

79.

System pozwala na zdefiniowanie struktury jednostki organizacyjnej w układzie hierarchicznym oraz określenie odpowiednich parametrów elementu każdego poziomu (stosownie do typu elementu).

System prezentuje strukturę jednostek organizacyjnych.



80.

System umożliwia graficzne wyświetlenie struktury organizacyjnej w postaci graficznej drzewa zależności z możliwością wyboru poszczególnych jego elementów i natychmiastowego przejścia do edycji wybranego elementu

81.

Możliwość dodawania nowego pracownika z wprowadzeniem podstawowego zakresu danych:

  • dane osobowe,

  • dane o zatrudnieniu,

  • przynależność do grupy zawodowej,

  • numer prawa wykonywania zawodu (dla lekarzy).


1   2   3   4   5   6   7   8   9   ...   14


©operacji.org 2017
wyślij wiadomość

    Strona główna