ROZEZNANIE RYNKU DLA USŁUGI:


Warszawa, 08.08.2023


ROZEZNANIE RYNKU DLA USŁUGI:

Zaprojektowanie, wytworzenie i świadczenie usług wsparcia Dedykowanego Oprogramowania pod nazwą:


System Sieci Kardiologicznej


SPECYFIKACJA WARUNKÓW ZAMÓWIENIA


I. PRZEDMIOT ZAMÓWIENIA


Przedmiotem zamówienia jest:

1. wytworzenie, dostarczenie i produkcyjne uruchomienie systemu dedykowanego o roboczej nazwie “System Sieci Kardiologicznej” zgodnie z przedstawioną poniżej specyfikacją

2. przekazanie praw majątkowych do kodu źródłowego, struktur bazodanowych, utworów graficznych, dokumentacji i innych elementów podlegających prawu autorskiemu wytworzonych w ramach realizacji zamówienia

3. świadczenie usług wsparcie technicznego w zakresie dostarczonego rozwiązania przez okres 3 lat

4. świadczenie usług związanych z rozwojem i zmianami w dostarczonym rozwiązaniu przez okres 3 lat

5. świadczenie usług szkoleniowych dla personelu Zamawiającego w zakresie użytkowania systemu oraz jego administracji i rozwoju


UWAGA!

Niniejsze szacowanie wartości zamówienia nie stanowi oferty w rozumieniu art. 66 Kodeksu Cywilnego, jak również nie jest ogłoszeniem ani zapytaniem o cenę w rozumieniu ustawy Prawo Zamówień Publicznych. Informacja ta ma na celu wyłącznie rozpoznanie rynku i uzyskanie wiedzy na temat kosztów realizacji opisanej usługi.

Wykonawca powinien traktować jako materiał pomocniczy definicje, zasady oraz zakresy zadań przypisane poszczególnym aktorom wskazane w rozporządzeniu Ministra Zdrowia z dnia 10 maja 2021 r. w sprawie programu pilotażowego opieki nad świadczeniobiorcą w ramach sieci kardiologicznej



II. CEL REALIZACJI ZAMÓWIENIA ORAZ ROZEZNANIA RYNKU


Narodowy Instytut Kardiologii od listopada 2021 roku prowadzi pilotaż Sieci Kardiologicznej polegający na przetestowaniu modelu opieki koordynowanej pacjentów z niektórymi schorzeniami układu krążenia. Początkowo pilotaż obejmował wyłącznie województwo mazowieckie, obecnie został rozszerzony o kolejne 6 województw.


Na potrzeby pilotażu została stworzony wersja oprogramowania, która jest obecnie wykorzystywana do wspierania procesów koordynacji leczenia pacjentów włączonych do pilotażu (dalej: Prototyp). Na dzień dzisiejszy w systemie zostało obsłużone ponad 10.000 pacjentów, z systemu korzysta obecnie blisko 500 podmiotów, 1 250 zakładów (jednostek organizacyjnych tych podmiotów).


Planuje się, że w 2025 roku opieka koordynowana w zakresie chorób układu krążenia - Sieć Kardiologiczna - zostanie wdrożona systemowo i będzie obejmować wszystkie placówki POZ, poradnie kardiologiczne i SZPITALE z oddziałami kardiologicznymi w Polsce.


Na potrzeby Sieci Kardiologicznej niezbędna będzie budowa skalowalnego środowiska i systemu teleinformatycznego w oparciu o najnowsze rozwiązania techniczne, bezpieczeństwa oraz standardy jakościowe spełniające wymogi Ustawowe dla systemów teleinformatycznych działających w systemie ochrony zdrowia jak i innych regulacji dotyczących usług kluczowych.


Przygotowując się do planowanego przeprowadzenia zakupu - postępowania publicznego - Narodowy Instytut Kardiologii przeprowadza wstępne rozeznanie rynku mające na celu:

- ustalenia wartości zamówienia i kwoty jaką Zamawiający powinien zabezpieczyć na ten cel

- ustalenia kosztów świadczenia usług wsparcia technicznego i rozwojowego i kwoty jaką należy zabezpieczyć na ten cel na najbliższe lata

- ustalenia czasu niezbędnego na bezpieczną realizację zamówienia

- uzupełnienia specyfikacji o istotne elementy, których zamawiający nie przewidział na obecnym etapie przed wszczęciem postępowania publicznego

Poniższe specyfikacja została wytworzona na podstawie zbudowanego przez zespół deweloperski Narodowego Instytutu Kardiologii, funkcjonalnego i działającego obecnie produkcyjnie Prototypu oraz informacji zespołów obsługujących system - zarówno użytkowników końcowych, jak z podmiotów koordynujących w poszczególnych regionach.


W związku z przewidywanym terminem ostatecznego wdrożenia systemu produkcyjnego, zmianom mogą ulec wytyczne leczenia oraz schematy przepływu pacjenta dla poszczególnych ścieżek leczenia co będzie miało wpływ bezpośrednio na funkcjonalności wdrażanego oprogramowania. Zamawiający przyjmuje, że wdrażanie i proces wytwarzania zamawianego oprogramowanie będzie realizowane z wykorzystaniem metodyk zwinnych, które umożliwią modyfikację funkcjonalności w trakcie realizacji zamówienia.


Zamawiający zaznacza, aktualne “Wytyczne postępowania” wykorzystywane w trakcie programu pilotażowego nie obejmują wszystkich rozpoznań kardiologicznych a w ramach docelowa Sieć Kardiologiczna jako rozwiązanie systemowe będzie obejmować całość kardiologii. Zamawiający oczekuje podania wyceny dla rozwiązania analogicznego jak aktualne.


UWAGA!

Zamawiający informuje, że na obecnym etapie nie ma przygotowanych:

- Wzoru Umowy i zapisów odnoszących się do ewentualnych kar umownych

- Warunków związanych z terminem realizacji zamówienia

- Warunków związanych z wymaganą metodologią wdrożenia

- Szczegółowych warunków świadczenia usług dodatkowych jak wsparcie techniczne, czy rozwój systemu


Zamawiający prosi o wskazanie szacunków kwot z uwzględnieniem tych braków i przyjęcie ryzyka i kosztów w tym zakresie na zasadach standardowych praktyk rynkowych.


III. CEL SYSTEMU TELEINFORMATYCZNEGO


Celem wdrożenia wskazanego systemu teleinformatycznego jest:

1. Wsparcie procesu koordynacji leczenia pacjentów ze schorzeniami układu krążenia pomiędzy różnymi zakładami leczniczymi oraz pomiędzy różnymi stopniami referencyjnymi w celu przyśpieszenia procesu diagnostycznego oraz zwiększenia ich satysfakcji z obsługi medycznej

2. Wsparcie procesu sprawozdawczego

3. Wsparcie procesów konsultacji i telekonsultacji pomiędzy ośrodkami o różnym poziomie referencyjnym (o ile jest to konieczne)

4. Uzyskiwanie danych statystycznych związanych z prowadzeniem koordynacji leczenia

5. Przygotowanie i przeprowadzenie ankiet satysfakcji pacjentów

6. Przyszła integracja z systemami NFZ w celu automatyzacji uzyskiwania wskaźników i mierników oraz rozliczania świadczeń Celem wdrożenia wskazanego systemu teleinformatycznego nie jest:

1. Gromadzenie danych medycznych dotyczących pacjentów

2. Prowadzenie dokumentacji medycznej tzw. EDM

3. Wymiany dokumentacji medycznej pomiędzy podmiotami

4. System do prowadzenia telekonsultacji lub konsultacji

5. System obsługującym grafiki przyjęć pacjentów i organizacji wewnętrznej opieki pacjentów w ośrodkach współpracujących


IV. TERMIN PRZEKAZYWANIA OFERTY CENOWEJ


Termin przekazania oferty cenowej oraz ewentualnych uwag i propozycji do specyfikacji: 15 września 2023


V. PLANOWANY TERMIN WSZCZĘCIA POSTĘPOWANIA


Postępowanie zostanie wszczęte wyłącznie w przypadku uzyskania akceptacji i zapewnienia finansowania przez podmiot finansujący - Ministerstwo Zdrowia - oraz w przypadku podjęcia decyzji o zakupie oprogramowania w ramach realizacji projektu.


Zastrzegamy, że możliwe są zmiany w zakresie podmiotu zamawiającego, ze względu na ogólnopolski charakter przedsięwzięcia ostatecznym podmiotem zamawiającym może być jedna z jednostek centralnych odpowiadających za informatyzację lub rozliczenia świadczeń zdrowotnych, bezpośrednio Ministerstwo Zdrowia lub Narodowy Instytut Kardiologii.


Zastrzegamy także, że istnieje ryzyko, że postępowanie na wskazane oprogramowanie nie zostanie opublikowane. Przewidywany wstępny termin publikacji ogłoszenia: styczeń 2024 roku

Wszyscy wykonawcy, którzy odpowiedzą na niniejsze rozeznanie rynku zostaną indywidualnie poinformowani o publikacji takiego ogłoszenia, oraz przed publikacją ogłoszenia zostaną ponownie poproszeni o przekazanie oferty cenowej w celu ostatecznego rozeznania rynku w przypadku, gdy obecna specyfikacji ulegnie znacznej zmianie.


VI. PROTOTYP I PRZEDSTAWIONE INSTRUKCJE


Prototyp to oprogramowanie zrealizowane wewnętrznymi zasobami Narodowego Instytutu Kardiologii, które aktualnie działa w zakresie wspieranie procesów pilotażu. Prototyp spełnia obecnie wszelkie wymagania związane z wymaganiami dotyczącym wytycznych postępowania i przepływów pacjenta. Jako prototyp nie jest zoptymalizowany pod szersze i ogólnopolskie wdrożenie, a jego funkcjonalności są przygotowane w podstawowym zakresie. Pozwala jednak na wskazanie kierunku oraz sposobu realizacji określonych funkcji oraz wymagań, które spełnią oczekiwania Zamawiającego.


Instrukcje przygotowane dla Prototypu są wskazówką dla wykonawcy, jak zamawiający wyobraża sobie funkcjonowanie systemu oraz sposób implementacji poszczególnych jego funkcjonalności. Nie są to jednak wytyczne obligatoryjne i Zamawiający będzie dopuszczał zarówno całkowitą zmianę szaty graficznej, jak i sposobu realizacji poszczególnych funkcji o ile nie będą one utrudniały i wydłużały procesu wprowadzania danych i czasu korzystania z proponowanej aplikacji. Jedną z najistotniejszych dla Zamawiającego kwestii jest prostota, szybkość obsługi oraz intuicyjność systemu, z uwagi na dużą rotację użytkowników końcowych.


VII. WYMAGANIA



Lp.

Funkcjonalność / wymaganie

Opis działania funkcji


PODSTAWOWE WYMAGANIA TECHNICZNE

T.1

Rodzaj zamawianego systemu

Aplikacja webowa / przeglądarkowa - Zamawiający wymaga aby pełna funkcjonalność systemu była dostępna poprzez serwis udostępniony w przeglądarce internetowej (w formie aplikacji webowej), co nie wymaga konfiguracji i instalacji systemu na konkretnych stanowiskach pracy.


System działa prawidłowo we wszystkich wskazanych przeglądarkach: Chrome, Android Chrome, FireFox, Edge, Safari, IOS Safari w wersjach aktualnych na czas składania oferty.


T.2

Środowisko systemu

Środowisko systemu powinno opierać się o rozwiązania umożliwiające wprowadzenie redundancji zasobów i skalowalność projektu w miarę jego rozwoju. Powinno ono obejmować co najmniej:

- Środowisko produkcyjne

- Środowisko zapasowe

- Środowisko testowe (w całym okresie wsparcia projektu)

- Środowisko deweloperskie


Przykładowy schemat proponowanego środowiska: Rysunek 21 - Wizualizacja środowiska systemu

T.3

Środowisko produkcyjne

Serwer

Serwer dedykowany (fizyczny) w centrum danych zlokalizowanym w Polsce.


Minimalne wymagania dotyczące serwera:

Core: min 32

RAM: min 32 GB

Dyski NVME min 2 TB (z możliwością rozbudowy)


Oprogramowanie bazowe (system operacyjny)

Serwerowe oprogramowanie bazowe dowolnego producenta (system operacyjny), którego wsparcie producenta planowane jest przez co najmniej okres następnych 5 lat (LTS)


Serwer www

Dopuszczalnym systemem będącym serwerem www jest dowolny serwer www, którego wsparcie producenta planowane jest przez co najmniej okres 3 lat (LTS)


WARIANT:

Dopuszczamy scenariusz, w którym środowisko bazodanowe będzie zlokalizowane na oddzielnym serwerze - w tym samym centrum danych.

T.4

Środowisko zapasowe

Serwer

Serwer dedykowany (fizyczny) w centrum danych zlokalizowanym w Polsce innym niż Serwer w Środowisku produkcyjnym


Minimalne wymagania dotyczące serwera: Core: min 32

RAM: min 32 GB

Dyski NVME min 2 TB (z możliwością rozbudowy)


Oprogramowanie bazowe (system operacyjny)

Identyczne jak w Środowisku produkcyjnym





Serwer www

Identyczne jak w Środowisku produkcyjnym


WARIANT:

Dopuszczamy scenariusz, w którym środowisko bazodanowe będzie zlokalizowane na oddzielnym serwerze - w tym samym centrum danych.

T.5

Środowisko testowe

Serwer

Serwer dedykowany (fizyczny) w centrum danych zlokalizowanym w Polsce. Centrum danych może być to samo co Środowisko produkcyjne lub zapasowe.


Minimalne wymagania dotyczące serwera:

Core: min 16

RAM: min 16 GB

Dyski NVME min 512 GB (z możliwością rozbudowy)


Oprogramowanie bazowe (system operacyjny)

Identyczne jak w Środowisku produkcyjnym


Serwer www

Identyczne jak w Środowisku produkcyjnym


WARIANT:

Dopuszczamy scenariusz, w którym środowisko bazodanowe będzie zlokalizowane na oddzielnym serwerze - w tym samym centrum danych.

T.6

Szyfrowanie danych podczas komunikacji

System zapewnia szyfrowanie danych podczas komunikacji pomiędzy klientem a serwerem (System działa w trybie szyfrowania połączenia (na protokole https) z użyciem certyfikatu SSL).


Wszelkie zasoby wewnętrzne i zewnętrzne powinny być wczytywane po https (skrypty, utwory graficzne, szablony stylów).

T.7

Silnik bazodanowy

Dopuszczalnym silnikiem bazy danych jest silnik, dla którego możliwe jest wykupienie wsparcia producenta oraz, jeżeli silnik wymaga licencji, licencje te muszą być licencjami bezterminowymi.


Jeżeli określony silnik bazodanowy wymaga licencji dostępowych dla użytkowników lub licencji serwerowych, wykonawca ponosi koszt ich zakupu. Licencje takie są przenoszone na Zamawiającego.

T.8

Baza danych

Wszelkie komponenty systemu, jego moduły, dane importowane, dane wprowadzane przez użytkowników, dane generowane przez system muszą być zapisywane w jednej bazie danych, opartej o model relacyjny.




Niedopuszczalna jest sytuacja, w której określone elementy systemu wymagają innych baz danych, lub dane tekstowe wymagają przechowywania w oddzielnych plikach.

T.9

Miękkie usuwanie

System ma w pełni obsługiwać miękkie usuwanie, to znaczy, że rekordy mają być oznaczane, że są usunięte podczas gdy w rzeczywistości fizycznie nadal będą pozostawać we wpisach w bazie danych.

T.9

RWD

Aplikacja webowa / przeglądarkowa musi być zbudowana w oparciu o technologię RWD (Responsive Website Design)

T.10

WCAG 2.1

System musi być zgodny z wytycznymi WCAG 2.1 w stopniu co najmniej AA.

T.11

Wtyczki, aplety, komponenty

System, jego moduły i poszczególne funkcje, nie są oparte o jakiekolwiek wtyczki (np. JAVA, Silverlight, Flash, itp.), które wymagałyby ich instalacji na stanowiskach pracy lub w przeglądarce internetowej.

T.12

Język polski

Wszystkie elementy systemu: komunikaty, opcje menu, raporty, pomoc kontekstowa, ekrany do wprowadzania danych, podpowiedzi, zapytania, instrukcje użytkownika i inne muszą być zredagowane w języku polskim.

T.13

Szyfrowanie kodu

System nie może posiadać elementów i komponentów, których kod jest zaszyfrowany lub bazuje na prekompilowanych elementach, do których producent nie jest w stanie dostarczyć kodu źródłowego.

T.14

Wymagania prawne

System musi spełniać aktualnie obowiązujące wymogi polskiego prawa w tym w szczególności Ustawy z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowia.


System oraz wszelkie jego moduły funkcjonalne są zgodne i umożliwiają prowadzenie danych zgodnie z RODO.

T.15

Czas odpowiedzi

Średni czas odpowiedzi systemu od momentu wysłania żądania do przesłania do zakończenia wysyłania odpowiedzi przez serwer poniżej 3s przy obciążeniu 500 sesji użytkowników jednocześnie przy założeniu danych 100 000 rekordów z danymi dotyczącymi pacjentów oraz 1 000 000 rekordów logów systemów.

T.16

Bezpieczeństwo

Konfiguracja serwera oraz rozwiązanie teleinformatyczne musi spełniać co najmniej kryteria bezpieczeństwa wskazane w wytycznych OWASP oraz:

- zagwarantować zastosowanie najnowszych aktualizacji i łatek bezpieczeństwa dla wszystkich komponentów systemowych

- wszelkie dane przechowywane na serwerach powinny być zaszyfrowane podczas ich transmisji

- konfiguracja serwera powinna być zaprojektowana w taki sposób, aby minimalizować ryzyko ataków typu "brute force" lub ataków DDoS.

- wymagane jest stosowanie zasady minimalnych uprawnień, gdzie użytkownicy i usługi mają tylko te uprawnienia, które są im absolutnie niezbędne

- system powinien być zaprojektowany zgodnie z zasadą "bezpieczeństwa przez projektowanie" (Security by Design), co oznacza, że bezpieczeństwo jest integralnym elementem projektowania systemu, a nie dodatkiem zaimplementowanym po fakcie.




- dostawca powinien przeprowadzić audyty bezpieczeństwa i testy penetracyjne, aby zapewnić, że system jest wolny od znanych luk bezpieczeństwa.

- system powinien być zgodny z obowiązującymi standardami i przepisami, takimi jak Ogólne Rozporządzenie o Ochronie Danych (RODO), ISO/IEC 27001 (Systemy zarządzania bezpieczeństwem informacji), Ustawy

z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowia.

T.17

System backupowania

Rozwiązanie musi obejmować zbudowanie i uruchomienie środowiska i procedur tworzenia kopii bezpieczeństwa, które muszą obejmować co najmniej:


1. Tworzenie repliki bazy w czasie rzeczywistym ze środowiska produkcyjnego do środowiska zapasowego


2. Tworzenie kopii plików generowanych w systemie i/lub wgrywanych w serwisie w czasie rzeczywistym ze środowiska produkcyjnego do środowiska zapasowego


3. Tworzenie regularnych pełnych kopii bezpieczeństwa bazy danych - wraz z automatycznym odkładaniem ich poza środowisko produkcyjne oraz zapasowe (przechowywanie w co najmniej dwóch różnych lokalizacjach fizycznych)


4. W środowisku zapasowym serwer działa w trybie standby - przejmujący funkcje serwera produkcyjnego w przypadku jego awarii (proces przełączenia może być ręczny, jednak przełączenie musi być proste i ograniczać się np. do przełączenia delegacji domeny pod którą działa system na inny IP serwera)


5. Procedura powrotu działania systemu po usunięciu awarii środowiska produkcyjnego (aktualizacja bazy danych, aktualizacja plików użytkowników)


6. Regularne procedury testów przywracania bazy z pełnej kopii bezpieczeństwa


INFORMACJE, SZACUNKI I WARUNKI WSTĘPNE

I.18

PODMIOT

Podmiot rozumiany jako podmiot leczniczy identyfikowany przez jeden z krajowych numerów identyfikacyjny - NIP lub KRS.

Każdy podmiot może mieć przypisanych wiele placówek zlokalizowanych w różnych lokalizacjach geograficznych lub tych samych lokalizacjach geograficznych.


Każdy podmiot może posiadać nieograniczoną liczbę placówek.

Podmiot może nie posiadać placówek (jednostek organizacyjnych), jeżeli nie bierze czynnego udziału w obsłudze pacjenta w ramach Sieci Kardiologicznej, ale jego pracownicy mają dostęp do niektórych funkcji np. Monitor Globalny z NFZ czy Ministerstwa Zdrowia.


I.19

ZAKŁAD

Zakłady działające w ramach Podmiotów, które reprezentują logiczny podział na typ realizowanych świadczeń np. AOS, POZ, SZPITAL identyfikowanych na podstawie kodów świadczeń zdrowotnych.

I.20

TYPY ZAKŁADÓW

W systemie muszą znajdować się 3 typy placówek:

POZ - Podstawowa Opieka Zdrowotne

AOS - Ambulatoryjna Opieka Stacjonarna SZPITAL - Wybrane oddziały szpitalne


Każdy zakład może mieć tylko jeden typ placówki.


Każda placówka może występować w jednym stopniu referencyjności (poziom).


W ramach jednego podmiotu różne jego jednostki mogą posiadać różne typy zakładów.

I.21

POZIOMY ZAKŁADÓW

W systemie muszą znajdować się 4 główne poziomy referencyjności:

I poziom - Ośrodki Współpracujące I poziomu II poziom - Ośrodki Współpracujące II poziomu

III poziom - Regionalny Ośrodek Koordynujący (ROK) KOK - Krajowy Ośrodek Koordynujący

Każda placówka może mieć tylko jeden poziom referencyjności.


W ramach jednego podmiotu różne jego jednostki organizacyjne mogą mieć różne poziomy referencyjności.

I.22

KOK - Krajowy Ośrodek Koordynujący

Krajowy Ośrodek Koordynujący to specjalny ośrodek, będąc Administratorem Danych zawartych w systemie, którego niektórzy użytkownicy mają dostęp do danych wszystkich podmiotów w systemie. Administratorzy i użytkownicy

wsparcia technicznego mają szersze uprawnienia uprawnienia oraz dodatkowe funkcje - w szczególności związane z ręczną modyfikacją danych pacjentów i poszczególnych wizyt, oraz funkcji raportowych.


Ośrodek ten realizuje wsparcie techniczne dla pozostałych ośrodków koordynujących w ramach Sieci Kardiologicznej.


Role użytkowników:

- Administrator (Globalnie)

- Wsparcie Techniczne (Globalnie)

- Infolinia (Globalnie)

- Operator (Lokalnie do placówki)

- Lekarz (Lokalnie do placówki)

- Monitor Lokalny (Lokalnie do placówki)

- Monitor Globalny (Lokalnie do podmiotu)

- Koordynator Leczenia (Lokalnie do placówki)

- Koordynator Techniczny (Lokalnie do podmiotu)




UWAGA! KOK jest zarazem ROK dla jednego z Województw.

I.23

ROK - Regionalny Ośrodek Koordynujący

Regionalny Ośrodek Koordynujący to ośrodek, którego zadaniem jest koordynacja leczenia pacjentów na określonym obszarze - województwie.

Placówki ROK domyślnie są III poziomu, jednak ROK może posiadać placówki o niższym poziomie referencyjności. Role użytkowników:

- Infolinia (Globalnie)

- Operator (Lokalnie do placówki)

- Lekarz (Lokalnie do placówki)

- Monitor Lokalny (Lokalnie do placówki)

- Monitor Globalny (Lokalnie do podmiotu)

- Koordynator Leczenia (Lokalnie do placówki)

- Koordynator Techniczny (Lokalnie do podmiotu)

I.24

PODMIOTY BEZ ZAKŁADÓW

System musi także obsługiwać podmioty bez placówek (tworzone przez administratora bez konieczności wprowadzania plików KRS, CEIDG czy RPWDL).


Takie podmioty mogą mieć przypisywane różne konta niezwiązane z obsługą pacjentów - np. konta Monitorów Globalnych itp. Do podmiotów bez zakładów mogą zaliczać się np. NFZ, Ministerstwo Zdrowia itp.


Role użytkowników:

- Monitor Globalny (Globalnie)

I.25

OŚRODEK WSPÓŁPRACUJĄCY

Ośrodek współpracujący to każdy podmiot, który uczestniczy w procesie obsługi pacjenta w ramach Sieci Kardiologicznej i nie jest Regionalnym Ośrodkiem Koordynującym.

Placówki takiego podmiotu mogą być POZ lub posiadać I lub II poziom referencyjności w zakresie AOS i SZPITALI. Role użytkowników:

- Operator (Lokalnie do placówki)

- Lekarz (Lokalnie do placówki)

- Monitor Lokalny (Lokalnie do placówki)

- Monitor Globalny (Lokalnie do podmiotu)

- Koordynator Leczenia (Lokalnie do placówki)

- Koordynator Techniczny (Lokalnie do podmiotu)

I.26

AKTUALNA LICZBA REGIONÓW (WOJEWÓDZTW)

7


I.27

SZACOWANA DOCELOWA LICZBA REGIONÓW (WOJEWÓDZTW)

16

I.28

SZACOWANA LICZBA PODMIOTÓW

8 000

I.29

SZACOWANA LICZBA UŻYTKOWNIKÓW

25 000

I.30

SZACOWANA LICZBA

UŻYTKOWNIKÓW PRACUJĄCYCH JEDNOCZEŚNIE

500

I.31

SZACOWANA LICZBA PACJENTÓW

/ ROK

20 000

I.32

SZACOWANA LICZBA PROCEDUR WYZNACZENIA WIZYT W

SYSTEMIE / ROK

Pac x 3,8:

76 000

I.33

SZACOWANA LICZBA REKORDÓW WIZYT OBEJMUJĄCA INFORMACJĘ O ZDARZENIACH I ŚCIEŻCE LECZENIA / ROK

Pac x 3,2:

64 000


FUNKCJONALNOŚCI OGÓLNE SYSTEMU

O.34

Moduł konfiguracyjny systemu

System umożliwia konfigurację oprogramowania przez Administratora KOK co najmniej w zakresie:


1. [liczba] Liczba błędnych prób logowania w ciągu godziny do blokady konta

2. [miesiące] Liczba miesięcy, przez którą przechowywane są logi systemowe.

3. [dni] Częstotliwość wykonywania operacji czyszczenia logów w dniach.

4. [znaki] Klucz API do obsługi zapytań geolokalizacyjnych

5. [znaki] Klucz API do obsługi wysyłki SMS

6. [znaki] Nazwa wysyłającego do obsługi wysyłki SMS

7. [html] Informacje o zakresie pracy Wsparcia Technicznego

8. [znaki] Dane kontaktowe do Wsparcia Technicznego - Telefon

9. [znaki] Dane kontaktowe do Wsparcia Technicznego - Adres e-mail

10. [znaki] Informacje w jakie dni i w jakich godzinach pracuje Wsparcie Techniczne

11. [html] Informacje o zakresie pracy Infolinii




12. [znaki] Dane kontaktowe do Infolinii - Telefon

13. [znaki] Informacje w jakie dni i w jakich godzinach pracuje Infolinia

14. [pliki][wiele] Dokumenty do pobrania w panelu POMOC - plik + ikona + opis

15. [pliki][wiele] Dokumenty do pobrania przed zalogowaniem - plik + ikona + opis

16. [html] Regulamin Świadczenia Usług

17. [html] Polityka Prywatności

18. [html] Informacja RODO

19. [dni] Ważność odnośnika aktywującego konto

20. [minuty] Ważność kodu SMS wysłanego jako drugi składnik autentykacji

21. [znaki][lista] Kody resortowe realizowanych świadczeń dopuszczających zakłady do udziału (kod resortowy

+ typ zakładu do jakiego zostanie on zakwalifikowany: AOS; POZ; SZPITAL; SZPITAL KIERUJĄCY)

22. [dni] Ważność odnośnika umożliwiającego rejestrację podmiotu

23. [html+wersje] Porozumienie z ośrodkami współpracującymi

24. [pliki][wiele] Załączniki do porozumienia (Pliki PDF + kolejność sklejania)

25. [pliki][jeden] Formularz zgody pacjenta (Plik docx lub PDF)

26. [liczba] Minimalna liczba znaków opisu na skierowania do szpitala

27. [dni] Liczba dni po ilu system generuje monit o braku wyznaczonego terminu przez zakłady gdy nie wyznaczono żadnego terminu

28. [dni] Liczba dni po ilu system generuje dodatkowe zakłady gdy nie wyznaczono żadnego terminu

29. [liczba] Liczba zakładów, które zostaną wybrane automatycznie w algorytmie doboru zakładów po raz pierwszy

30. [liczba] Liczba dodatkowych zakładów, które zostaną wybrane automatycznie w algorytmie doboru zakładów po raz drugi

31. [liczba] Promień od miejsca zamieszkania w jakim system ma wyszukiwać najbliższe placówki w algorytmie doboru zakładów

32. [dni] Liczba dni po ilu system generuje zadania "wybrania terminu z pacjentem" jeżeli został zaproponowany co najmniej jeden termin

33. [dni] Liczba dni od włączenia pacjenta do Sieci Kardiologicznej po ilu system ma założyć automatycznie ankietę dla pacjenta

34. [true/false] Automatyczne wysyłanie adresu URL z ankietą do pacjenta

35. [true/false] Wymuszanie zmiany hasła po upływie określonego czasu

36. [dni] Liczba dni po ilu system wymusza zmianę hasła (jeżeli opcja wymuszania jest włączona)

37. [BRAK/DOZWOLONA/WYMAGANA] Dopuszczone dwuskładnikowa autentykacja

38. [true/false] Możliwość samodzielnego resetowania hasła przez użytkownika

39. [liczba] Możliwość konfiguracji liczby placówek, dla których jest generowane zadanie wyznaczenia terminu (P.95)

O.35

Eksportowanie danych tabelarycznych oraz list

Ilekroć w specyfikacji jest mowa o zestawieniu, liście, tabeli system umożliwia wyeksportowanie wskazanych danych zawartych w takim zestawieniu, liście lub tabeli do pliku EXCEL (niezależnie czy wymóg ten został zaakcentowany w danej specyfikacji czy nie).


O.36

Logi systemowe

System rejestruje każdą akcję użytkownika, co najmniej poprzez zapisanie informacji o dacie i czasie zdarzenia, adresu fizycznego użytkownika (IP), identyfikatora użytkownika, podjętej akcji przez użytkownika, obiektu, rodzaju obiektu, którego dotyczyła akcja, identyfikatora obiektu, którego dotyczyła akcja oraz wyniku tej akcji.


System zapewnia dostęp do pełnej historii operacji użytkowników (logów) z możliwością ich przeszukiwania i filtrowania w odniesieniu do każdej jednostki informacyjnej (kolumny). Przeglądanie i przeszukiwanie logów musi być zrealizowane w ramach systemu - nie może być to oddzielne narzędzie do przeglądania logów.


Logi systemowe mogą być zapisywane w oddzielnych plikach tekstowych lub bazie danych. W przypadku tego ostatniego rozwiązania system musi posiadać dodatkowo wbudowane funkcje do czyszczenia logów ręcznie i automatycznie co pewien kwant czasu.


Logi systemowe przechowywane są przez X miesięcy (konfigurowalne). Czyszczenie logów odbywa się co X dni (konfigurowalne).

O.37

Obsługa Interfejsu Geocoding API

Zaimplementowana funkcja interfejsu Geocoding API, która umożliwia na podstawie adresu i ewentualnie nazwy podmiotu ustalanie koordynatów LAT i LONG np. na mapach Google lub innego dostawcy usługi geolokalizacyjnej dla poszczególnych placówek oraz miejsca zamieszkania pacjentów obsługiwanych w systemie.

O.38

Parser RPWDL

Parser wydruków wpisów do RPWDL (xxxxx://xxxxx.xxxxxxxx.xxx.xx/) w zakresie wpisów i ksiąg Podmiotów Leczniczych, wyciągający dane:

Identyfikatory podmiotu, jednostki i placówki podmiotu, kodu realizowanych świadczeń w ramach poszczególnych placówek podmiotu, obsługa błędów związanych z nieprawidłowym wprowadzeniem danych w RPWDL dotyczących ZAKŁADÓW LECZNICZYCH, JEDNOSTEK ORGANIZACYJNYCH oraz KOMÓREK ORGANIZACYJNYCH (np.

wprowadzenie Jednostek Organizacyjnych w dziale Komórek Organizacyjnych, brak powiązań pomiędzy tymi 3 działami, błędne daty działalności, itp.)

O.39

Parser KRS

Parser wydruków PDF wpisów do KRS w zakresie danych teleadresowych, numerów identyfikacyjnych, sposobu reprezentacji oraz osób uprawnionych do reprezentacji podmiotów.

O.40

Parser CEIDG

Parser wydruków PDF wpisów podmiotów w CEIDG zarówno prowadzonych działalności gospodarczych jak i spółek cywilnych. Wyciąganie danych w zakresie danych teleadresowych, numerów identyfikacyjnych oraz osób reprezentujących z możliwością wgrania kilku dokumentów do jednego podmiotu w przypadku spółek cywilnych.

O.41

Obsługa interfejsu SMS API

Zaimplementowana funkcja interfejsu SMS API w celu komunikacji z użytkownikami i pacjentami. Obsługa jednostronna.

Możliwość konfiguracji w systemie:

- klucza (konfigurowalne)

- wykorzystywanej nazwy (profilu) w SMS (konfigurowalne)

O.42

Generator dokumentów PDF

System powinien mieć funkcjonalność generowania plików PDF.




Funkcjonalność ta ma umożliwiać generowanie dokumentów, których treść jest modyfikowana i generowana na podstawie danych (sformatowanych wizualnie treści) umieszczanych w bazie danych (np. z kodu HTML), oraz różnych zmiennych danych umieszczanych w systemie w procesie jego użytkowania.


Funkcjonalność musi także umożliwiać “sklejanie” wielu dokumentów PDF w jeden - funkcja ta jest wymagana przy generowaniu porozumień i podłączaniu do nich stałych załączników w formacie PDF.

O.43

Mechanizm archiwizacyjny (pakowania plików do archiwum)

Mechanizm umożliwiający pakowanie zbiorcze dokumentów i wysyłanie ich do przeglądarki w celu pobrania przez użytkownika zbiorczego archiwum (np. zip).

O.44

Komunikaty w systemie

System umożliwia zarządzanie i wyświetlanie komunikatami wewnątrz systemu.


Komunikaty muszą umożliwiać wprowadzanie sformatowanej treści HTML (w tym linków do zewnętrznych zasobów, plików itp.) metodą WYSIWYG.


Konfiguracja komunikatów musi obejmować co najmniej możliwość określenia grupy docelowej:

- komunikat globalny

- komunikat dla placówek o określonym typie

- komunikat dla placówek o określonym poziomie

- komunikat dla użytkowników o określonej roli

- komunikaty dla określonych regionów (województw)


Konfiguracja komunikatów musi umożliwiać zdefiniowanie zakresu dat w jakich się wyświetla - z możliwością nie podawania daty końcowej - w takim przypadku komunikat wyświetla się w sposób ciągły do momentu jego

wyłączenia.


Konfiguracja musi uwzględniać możliwość zastosowania co najmniej 3 wariantów kolorystycznych:

- domyślny

- żółty

- czerwony

O.45

Informacja POMOC

Wyświetlanie w POP-UP lub na oddzielnej podstronie informacji:

- Informacje o zakresie pracy Wsparcia Technicznego (konfigurowalne)

- Dane kontaktowe do Wsparcia Technicznego (konfigurowalne)

- Informacje w jakie dni i w jakich godzinach pracuje Wsparcie Techniczne (konfigurowalne)


- Informacje o zakresie pracy Infolinii (konfigurowalne)

- Dane kontaktowe do Infolinii (konfigurowalne)

- Informacje w jakie dni i w jakich godzinach pracuje Infolinia (konfigurowalne)


- Dokumenty do pobrania: Instrukcje, Formularze zgody pacjenta, Wytyczne, Inne materiały (konfigurowalne)


O.46

Informacje aplikacji / sesyjne

System wyświetla każdemu zalogowanemu użytkownikowi następujące informacje:

- ID zalogowanego użytkownika

- ID podmiotu

- ID kontekstu placówki (jeżeli wybrany)

- IP

- Login użytkownika

- Czas do wygaśnięcia sesji (automatycznie aktualizowany)

- Wersja oprogramowania


Informacja ta powinna być minimalna, ale widoczna na każdym ekranie. Informacje te ułatwiają zarządzanie i udzielanie wsparcia technicznego - np. przy zrzucie ekranu pracownik wsparcia posiada te niezbędne informacje do wykonywania swoich zadań.

O.47

Strony Informacyjne

System musi umożliwiać opublikowanie i edycję następujących stron informacyjnych:

- Regulamin Świadczenia Usług

- Polityka Prywatności

- Informacja RODO


Każda strona informacyjna jest edytowana w formie tekstu HTML za pomocą mechanizmu WYSIWYG.

Strony muszą być ogólnie dostępne pod konkretnym adresem URL bez konieczności logowania użytkowników. Wstępna treść stron informacyjnych zostanie dostarczona przez Zamawiającego.

Odnośnik do Stron informacyjnych musi być dostępny zarówno dla użytkowników niezalogowanych jak i zalogowanych.


UŻYTKOWNICY, UPRAWNIENIA I ZARZĄDZANIE UPRAWNIENIAMI

U.48

Użytkownik

Użytkownik powinien być określony co najmniej przez następujące dane:

- id

- id podmiotu

- login (opcjonalnie - loginem może być email)

- adres e-mail (unikalny)

- hasło

- imię i nazwisko

- telefon komórkowy

- status aktywności

- id użytkownika tworzącego rekord

- data utworzenia




- id użytkownika modyfikującego

- data ostatniej modyfikacji

- id użytkownika usuwającego

- data usunięcia

- status włączenia powiadomień SMS

- status wskazujący czy musi zmienić hasło po zalogowaniu

- ID globalnej roli w podmiocie


Dodatkowo w informacjach o użytkowniku powinny być dostępne następujące dane (forma realizacji czy wpisywane w rekordzie użytkownika czy też uzyskiwane dane dynamicznie pozostawiamy do wyboru wykonawcy):

- przyczyna blokady konta

- licznik udanych akcji logowania

- data pierwszego udanego logowania

- data ostatniego logowania

- data potwierdzenia konta e-mail

- data potwierdzenia telefonu komórkowego

- data zablokowania


Każdy użytkownik musi być przypisany dokładnie do jednego podmiotu.

Jeżeli użytkownik ma globalną rolę inną niż “Użytkownik”, posiada dostęp do każdego zakładu w podmiocie (może przełączać kontekst)

Każdy użytkownik o roli globalnej “Użytkownik” może być przypisany do dowolnej liczby zakładów w podmiocie w określonej jednej roli lokalnej.

U.49

Logowanie do systemu

Wymagane oświadczenie

Za każdym razem, gdy użytkownik loguje się do systemu musi zaznaczyć opcję, że zapoznał się z aktualnym regulaminem świadczenia usług oraz polityką prywatności.


Blokady

Blokowanie użytkownika po X (konfigurowalne) nieudanych logowań. Możliwość odblokowania w panelu zarządzania użytkownikami na liście użytkowników przez koordynatora technicznego podmiotu, administratora ROK lub administratora KOK.


Walidacja hasła

System zawiera w każdym miejscu, w którym ustawia się hasła, wbudowaną walidację ustawianych haseł, tak aby spełniały następujące warunki:

- w haśle nie może być ciągu znaków składającego się z nazwy użytkownika oraz z adresu e-mail (przed znakiem @)

- hasło musi składać się z co najmniej 8 znaków

- hasło musi składać się z co najmniej jednej małej litery

- hasło musi składać się z co najmniej jednej dużej litery

- hasło musi składać się z co najmniej jednej cyfry




- hasło musi składać się z co najmniej jednego znaku specjalnego


Konfiguracja dwuskładnikowego LOGOWANIA

- użytkownik ma możliwość ustawienia dwuskładnikowego logowania do systemu (KOD SMS)

U.50

Resetowanie hasła przez użytkownika

Użytkownik ma możliwość samodzielnego resetowania hasła poprzez wybranie formy resetu - wysłanie wiadomości na adres e-mail lub wysłanie wiadomości SMS (o ile dostępny jest numer telefonu komórkowego).


W przypadku ustawionego dwuskładnikowego logowania, resetowanie hasła również musi obejmować walidację dostępu do dwóch form walidacji tożsamości (email i SMS) niezależnie od wybranej formy resetu hasła.

U.51

Profil użytkownika

Wyświetlanie informacji i konfiguracja konta użytkownika przez użytkownika:


Informacje:

- data utworzenia konta

- ID użytkownika

- Imię i nazwisko

- Adres e-mail

- Telefon kontaktowy

- Data ostatniego logowania

- Łączna liczba logowań

- Informacja o udzielonych uprawnieniach


Funkcja: Zmiana hasła użytkownika

Funkcja: Wyświetlanie własnych logów akcji z możliwością przeszukiwania

Funkcja: Wyświetlanie własnych logów z podejmowanych prób logowania z możliwością przeszukiwania Funkcja: Włączanie / Wyłączanie powiadomień SMS

U.52

Resetowanie / Zmiana hasła

W systemie muszą znajdować się funkcje: zmiany hasła dla zalogowanych użytkowników oraz resetowania hasła, w przypadku, gdy zostanie ono zapomniane przez użytkownika.


Zmiana hasła:

Zmiana hasła może być dokonana w profilu użytkownika. Należy podać stare hasło oraz dwukrotnie nowe hasło.


Resetowanie hasła:

System powinien umożliwiać zmianę hasła poprzez wybranie jednej z 2 metod:

- zmiana poprzez wysłanie wiadomości na adres e-mail użytkownika.

- zmiana poprzez wysłanie SMS z kodem do zmiany (o ile użytkownik posiada wprowadzony numer telefonu komórkowego).


W systemie powinien być zaimplementowany mechanizm walidacji silnych haseł, spełniający obecne standardy




bezpieczeństwa, uniemożliwiający wprowadzenie słabego hasła.

U.53

Uprawnienia użytkowników

System uprawnień ma być podzielony na 2 warstwy:

- Uprawnienia globalne (w kontekście całego podmiotu)

- Uprawnienia lokalne (w kontekście konkretnego zakładu) Uprawnienia globalne to:

- Użytkownik (Dostępna w każdym podmiocie)

- Koordynator Techniczny (Dostępna w każdym podmiocie)


- Koordynator Pacjenta (Dostępne tylko w podmiotach ROK)

- NFZ (Dostępne tylko w podmiotach ROK)

- Monitor (Dostępne tylko w podmiotach ROK)

- Wsparcie Techniczne (Dostępne tylko w podmiocie KOK)

- Administrator (Dostępne tylko w podmiocie KOK)

- Monitor globalny (Dostępne tylko w podmiocie KOK)


Uprawnienia lokalne w ramach zakładu (Tylko gdy rola globalna to Użytkownik):

- Operator

- Koordynator Leczenia

- Monitor lokalny

U.54

Zarządzanie użytkownikami

Zarządzanie użytkownikami mogą realizować następujący użytkownika z przypisanymi rolami globalnymi:

- Koordynator Techniczny;

- Wsparcie Techniczne;

- Administrator


Poniższe funkcjonalności związane z zarządzaniem użytkowników zarezerwowane są wyłącznie dla wskazanych powyżej ról globalnych z zaznaczeniem, że:


Koordynator Techniczny ma dostęp i zarządza użytkownikami wyłącznie w zakresie przypisanego do niego podmiotu.


Koordynator Techniczny podmiotu ROK ma dostęp i zarządza użytkownikami wszystkich podmiotów w regionie, który obsługuje dany ROK. Taki Koordynator techniczny może zarządzać także rolami w zakładach tego podmiotu zlokalizowanymi w innych Regionach (Każdy podmiot może mieć zawarte porozumienia z kilkoma ROK zależnie od

lokalizacji).


Wsparcie Techniczne oraz Administrator mają dostęp i zarządzają użytkownikami globalnie - w każdym podmiocie.





U.55

Dodawanie użytkownika

System umożliwia dodawanie nowych użytkowników. W trakcie dodawania nowego użytkownika określa się:

- imię i nazwisko

- adres e-mail (jako login jeżeli nie ma oddzielnego)

- login (jeżeli jest inny niż adres e-mail)

- numer telefonu komórkowego (zwalidowany)

- przypisanie do podmiotu

- określenie dla użytkownika roli globalnej lub roli lokalnej (w ramach każdej dostępnej w ramach przypisanego podmiotu placówki)


Po dodaniu użytkownika, do użytkownika wysyłana jest wiadomość z linkiem aktywującym konto oraz z wygenerowanym automatycznie i losowo hasłem - spełniającym kryteria bezpieczeństwa.

Hasło wyświetla się także jeden raz administratorowi.

Użytkownik po zalogowaniu do systemu musi zmienić wskazane hasło.


PRZYKŁADY:

Rysunek 2 - Formularz dodawania użytkownika Rysunek 3 - Formularz zmiany ról użytkownika

U.56

Aktywowanie konta przez użytkownika

Nowo założone konta przed pierwszym zalogowaniem są aktywowane przez użytkownika poprzez użycie linka (odnośnika URL) przesłanego w wiadomości e-mail na wprowadzony adres e-mail podczas dodawania nowego konta użytkownika.


Wygenerowany odnośnik jest ważny X dni (konfigurowalne)

U.57

Lista użytkowników

Uprawnieni użytkownicy mogą wyświetlić listę użytkowników.

System powinien umożliwić Koordynatorowi Technicznemu wyświetlenie listy użytkowników w jego podmiocie,

Koordynatorowi Technicznemu ROK wyświetlenie listy użytkowników wszystkich podmiotów w regionie, który obsługuje ROK, Wsparciu Technicznemu i Administratorowi wyświetlenie listy wszystkich użytkowników w systemie.


Lista użytkowników powinna obejmować co najmniej takie dane jak:

- ID użytkownika

- Imię i nazwisko

- e-mail / login (o ile inny niż e-mail)

- telefon kontaktowy (komórkowy)

- data ostatniego logowania

- status aktywności konta

- przejrzysta informacja o nadanych uprawnieniach (rola globalna / rola lokalna w danym zakładzie - np. jak w przykładzie)


Z poziomu listy powinna być możliwość wykonania następujących akcji:




- blokowanie / odblokowywanie konta

- zmiana hasła użytkownika

- Edycja danych użytkownika

- Edycja uprawnień użytkownika

- Przejście do logów użytkownika

- Statystyki użytkownika (na podstawie logów)

- Usunięcie użytkownika (o ile nigdy się nie zalogował oraz nie potwierdził adresu e-mail lub telefonu komórkowego)


Ograniczenia wyników listy użytkowników:

- KOK - wszyscy użytkownicy

- ROK - użytkownicy przypisani do placówek w danym regionie

- OW - użytkownicy przypisani do danego podmiotu


Filtrowanie co najmniej w zakresie:

- Podmiot

- Rola globalna

- Rola lokalna


Przeszukiwanie:

- możliwość przeszukiwania po każdej wyświetlanej kolumnie


PRZYKŁADY:

Rysunek nr 6 - Lista użytkowników

U.58

Resetowanie hasła użytkownika

System umożliwia zresetowanie hasła dla użytkownika bezpośrednio z listy użytkowników. Przy uruchomieniu

wskazanej funkcji, system automatycznie generuje hasło spełniające kryteria bezpieczeństwa. Po wygenerowaniu hasła system wyświetla hasło administratorowi. Użytkownik po ponownym zalogowaniu musi hasło zresetować.


Użytkownik otrzymuje powiadomienie mailowe, że jego hasło do systemu zostało zmienione.

Hasło nie jest wysyłane mailem do użytkownika i musi być przekazane mu bezpośrednio inną drogą przez osobę resetującą mu hasło.

U.59

Zarządzanie rolami użytkowników

Panel umożliwiający zmianę ról użytkownika w ramach podmiotu oraz poszczególnych jego placówek. Panel ma umożliwiać ustawienie roli globalnej użytkownika w podmiocie.

Panel ma możliwość ustawienia roli lokalnej w ramach placówki przypisanej do podmiotu. Każda zmiana roli przed zapisaniem zmian ma być oznaczona innym kolorem.

U.60

Blokowanie i odblokowywanie użytkowników

System umożliwia bezpośrednio z listy, aktywowanie lub dezaktywowanie konta użytkownika uniemożliwiając lub umożliwiając użytkownikowi logowanie do systemu.


U.61

Przełączanie na użytkownika

System powinien mieć możliwość przełączania się na dowolnego użytkownika (przejmowanie jego roli i kontekstu w podmiocie lub placówce) dla administratorów i wsparcia technicznego KOK.


W trybie przełączenia, wszelkie akcje w logach, muszą być oznaczone jako wykonane przez Administratora lub Wsparcie Techniczne w imieniu użytkownika, na którego się przelogować.


System ma umożliwiać powrót do uprawnień, z których użytkownik przełączył się na inne konto.


ZAWIERANIE POROZUMIEŃ / ZARZĄDZANIE PODMIOTAMI WŁĄCZONYMI

F.62

Dodawanie podmiotu

oraz jego placówek (jednostek organizacyjnych) do Sieci

Kardiologicznej

Dodawanie podmiotu poprzez wprowadzenie plików z bazy RPWDL oraz KRS lub CEIDG. Podczas dodawania podmiotu weryfikacja:

- zgodności numerów identyfikacyjnych zawartych we wprowadzonych plikach

- danych teleadresowych zawartych we wprowadzonych plikach

- nazw wprowadzonych we wprowadzonych plikach

- kodów resortowych i kodów realizowanych świadczeń (konfigurowalne) w zakresie dopuszczonych do sieci jednostek organizacyjnych realizujących określone świadczenia


Administrator ma możliwość ręcznego poprawienia:

Nazwy, Wyboru lub poprawienie numeru identyfikacyjnego np. NIP/KRS/REGON, adresu, sposobu reprezentacji (osób reprezentujących)


Po załadowaniu plików z RPWDL system parsuje dokument i wyświetla administratorowi podgląd JEDNOSTEK ORGANIZACYJNYCH spełniających kryteria włączenia do Sieci Kardiologicznej na podstawie kodów realizowanych świadczeń z podziałem na typ jednostki: POZ, AOS, SZPITAL.


Różne jednostki organizacyjne mogą być zlokalizowane w tych samych lokalizacjach np. pod jednym adresem mogą być POZ, AOS i SZPITAL. W systemie muszą znaleźć się 3 takie jednostki.


Każda placówka (jednostka organizacyjna) podczas dodawania musi mieć wyznaczone koordynaty na mapie Google. Administrator podczas dodawania powinien widzieć mapę ze wskazaną lokalizacją, aby zweryfikować czy koordynaty zostały dodane poprawnie. Administrator musi mieć możliwość poprawienia koordynatów ręcznie.


Administrator ma możliwość wyłączenia (nie dodawania) poszczególnych placówek (jednostek organizacyjnych).


Dodanie podmiotu generuje link rejestracyjny (adres URL), który wyświetla się administratorowi oraz jest dostępny w panelu administracyjnych na liście podmiotów włączonych / włączonych do Sieci Kardiologicznej.


Wygenerowany link musi mieć określony czas aktywności konfigurowalny w systemie (jako zmienna konfiguracyjna




w panelu lub pliku konfiguracyjnym).


Link rejestracyjny jest aktywny przez X dni (konfigurowalne).

Administrator musi mieć możliwość odświeżenia linku lub przedłużenie czasu jego aktywności.


UWAGA! Podczas dodawania podmiotu administrator ma możliwość przełączenia wprowadzania danych w trybie ręcznym.


PRZYKŁADY:

Rysunek 1 - Formularz dodawania podmiotu

F.63

Rejestracja podmiotu (przez użytkownika podmiotu)

Użytkownik (Koordynator Techniczny podmiotu), który posiada link aktywacyjny (po dodaniu podmiotu do systemu przez ROK) może dokonać rejestracji podmiotu w systemie.

Po otworzeniu linku wyświetla mu się panel rejestracyjny z danymi podmiotu oraz danymi zakładów (jednostek organizacyjnych) włączanych do Sieci Kardiologicznej.


Rejestracja przez Użytkownika podmiotu zewnętrznego w systemie powinna odbywać się zgodnie z załączoną Instrukcją Rejestracji stanowiącą Załącznik nr 7.

Obejmuje ona następujące kroki:

- Rejestracja (potwierdzenie / modyfikacja danych rejestracyjnych obejmujących dane podmiotu, reprezentantów, którzy zawrą porozumienie, dane kontaktowe, zakłady objęte porozumieniem)

- wygenerowanie porozumienia (na podstawie edytowalnego w systemie szablonu) - dynamiczne dane w porozumieniu wskazane są w kolorze fioletowym w Załączniku nr 8.

- założenie konta dla Koordynatora Technicznego

- pobranie wygenerowanego porozumienia w celu podpisania przez osoby reprezentujące podmiot

- wgranie na serwer podpisanego porozumienia

- możliwość wgrania pełnomocnictwa o ile jest wymagane (w przypadku podpisania porozumienia przez osoby inne niż wskazane w KRS)

- wysłanie do weryfikacji

- pobranie podpisanego przez ROK i KOK porozumienia

- założenie kont i przypisanie do zakładów Koordynatorów Leczenia


System musi rejestrować wszelkie akcje użytkowników w tym daty pobierania dokumentów jak i wgrywania ich do systemu włącznie z identyfikacją użytkowników dokonujących wskazanych akcji systemowych.

F.64

Lista podmiotów włączonych

Lista podmiotów włączonych i włączanych prezentująca dla użytkownika ROK listę podmiotów z danego regionu a dla użytkownika KOK listę wszystkich podmiotów.


PODMIOTY WŁĄCZONE

Lista powinna zawierać co najmniej następujące dane:

- liczbę porządkową lub informację o liczbie rekordów

- id aktualnego porozumienia




- id podmiotu w bazie

- informację o maksymalnym poziomie w podmiocie

- nazwa podmiotu

- adres podmiotu

- typy placówek (POZ / AOS / SZPITAL)

- liczba placówek

- liczba użytkowników (łączna liczba aktywnych i nieaktywnych)

- liczba pacjentów, którzy byli obsługiwani przez podmiot


Z poziomu tej listy powinny być dostępne akcje dla użytkowników wsparcia:

- przejście do podsumowania (szczegółów podmiotu)

- przejście do listy pacjentów w tym podmiocie

- przejście do listy użytkowników w tym podmiocie

- przejście do listy zgłoszeń Help-Desk tego podmiotu

- podgląd osób wyznaczonych do kontaktu

- podgląd osób reprezentujących podmiot

- podgląd historii zawieranych porozumień

- przejście do statystyk podmiotu

- przejście do zarządzania / edycji danych i ustawień podmiotu

- otworzenie panelu wypowiedzenia porozumienia


PODMIOTY WŁĄCZANE

Lista powinna zawierać co najmniej następujące dane:

- liczbę porządkową lub informację o liczbie rekordów

- id aktualnego porozumienia

- id podmiotu w bazie

- informacja o maksymalnym poziomie w podmiocie

- nazwa podmiotu

- adres podmiotu

- typy placówek (POZ / AOS / SZPITAL)

- STATUS (informujący o statusie aktualnie zawieranego porozumienia)


Z poziomu tej listy powinny być dostępne akcje dla użytkowników wsparcia:

- otworzenie panelu zarządzania porozumieniami

- otworzenie listy pacjentów danego podmiotu


PRZYKŁADY:

Rysunek 4 - Lista podmiotów włączonych

F.65

Panel zawierania porozumienia

System posiada moduł zawierania porozumienia, który składa się z następujących kroków:

- Dodanie podmiotu przez ROK (Funkcja Dodawanie podmiotu), generujące link rejestracyjny (lub inny zaproponowany sposób nie wymagający dalej aktywności ROK w celu rejestracji)




- Rejestracja podmiotu przez Ośrodek Współpracujący z linka rejestracyjnego (lub poprzez inną metodę) (Funkcja

Rejestracja podmiotu)

- Wprowadzenie podpisanego porozumienia przez ROK zgodnie z Weryfikacja dokumentów Porozumienia w instrukcji Włączania podmiotu stanowiącą Załącznik nr 9

- Wprowadzenie podpisanego porozumienia przez KOK zgodnie z Weryfikacja dokumentów Porozumienia w instrukcji Włączania podmiotu stanowiącą Załącznik nr 9

- Pobranie zawartego porozumienia przez ośrodek współpracujący

F.66

Panel anulowania porozumienia

System umożliwia anulowanie porozumienia, które nie przeszło w systemie pełnego procesu zawarcia porozumienia

/ włączenia podmiotu.


W przypadku anulowania porozumienia, system musi usunąć wszelkie dane powiązane z wprowadzonym podmiotem (z pominięciem logów systemowych).

F.67

Panel wypowiedzenie porozumienia

System umożliwia obsługę porozumienia w przypadku jego wypowiedzenia.


W przypadku wypowiedzenia, system musi automatycznie zablokować wszelkie konta użytkowników przypisanych do wskazanego podmiotu i uniemożliwić wybór zakładów (przez użytkownika lub przez system automatyczny) danego podmiotu jako lokalizacji leczenia pacjentów w Sieci Kardiologicznej.


W przypadku wypowiedzenia, system generuje raport otwartych pacjentów, dla których są wyznaczone zadania w ramach tego podmiotu wraz z możliwością przepisania przez operatora ROK tego zadania na inne podmioty.

F.68

Szczegóły podmiotu

System wyświetla szczegółowe informacje dotyczące podmiotu z minimalnym zakresem:

- Maksymalny poziom podmiotu

- typy posiadanych zakładów (AOS, POZ, SZPITAL)

- Dane statystyczne (Liczba zakładów, liczba użytkowników, liczba pacjentów)

- Dane kontaktowe - osoba odpowiedzialna za realizację porozumienia

- Dane kontaktowe - Koordynator techniczny

- Lista wszystkich zawartych porozumień z możliwością ich pobrania wraz z informacją o dacie wygenerowania oraz wersji

- Listę wszystkich włączonych zakładów wraz z informacjami (Typ zakładu, poziom zakładu, nazwa, REGON, adres, kody świadczeń spełniające kryteria włączenia, dane teleadresowe)

- Dla każdego zakładu - listę koordynatorów leczenia wraz z danymi kontaktowymi (telefon, e-mail) i informacją o ostatnim logowaniu


Z poziomu szczegółów administrator lub koordynator techniczny podmiotu powinni mieć możliwość edycji danych kontaktowych do zakładu tj. telefonów kontaktowych i adresu e-mail


PRZYKŁADY:

Rysunek nr 5 - Dane szczegółowe podmiotu włączonego


F.69

Konfiguracja: Osoby wyznaczone do kontaktu

System ma mieć możliwość wyświetlania i edycji osób wskazanych do kontaktu w ramach podmiotu jak i poszczególnych zakładów.

F.70

Konfiguracja: Osoby reprezentujące podmiot

System ma mieć możliwość wyświetlania i edycji osób wskazanych do reprezentowania podmiotu w procesie zawierania porozumienia.

F.71

Historia zawieranych porozumień

System ma mieć możliwość wyświetlenia Historii zawierania porozumień z podmiotami zarówno w ramach danego ośrodka współpracującego jak i zestawienia zawartych porozumień dla ROK i KOK wraz z możliwością ich pobrania.


W przypadku ROK i KOK, system powinien umożliwiać pobieranie wszystkich porozumień zbiorczo po uprzednim spakowaniu ich w archiwum (np. zip).

F.72

Lista podmiotów do zawarcia porozumienia

Lista podmiotów w trakcie zawierania porozumienia, które wymagają podjęcia działania ROK lub KSK (w zależności od tego, kto aktualnie ma wprowadzić podpisany dokument).


Uwaga - funkcjonalność może być zrealizowana poprzez zastosowanie odpowiedniego filtra na liście podmiotów włączonych.


Lista powinna zawierać co najmniej następujące dane:

- liczbę porządkową lub informację o liczbie rekordów

- id aktualnego porozumienia

- id podmiotu w bazie

- informacja o maksymalnym poziomie w podmiocie

- nazwa podmiotu

- adres podmiotu

- typy placówek (POZ / AOS / SZPITAL)

- STATUS (informujący o statusie aktualnie zawieranego porozumienia)


Z poziomu tej listy powinny być dostępne akcje dla użytkowników wsparcia:

- otworzenie panelu zawierania porozumienia

- otworzenie panelu anulowania porozumienia


FUNKCJE ADMINISTRACYJNE I ZARZĄDCZE

A.73

Zarządzanie zakładami współpracującymi

Każdy zakład w systemie może mieć przypisane zakłady współpracujące. Mogą to być zakłady tego samego podmiotu lub dowolnych innych podmiotów włączonych do Sieci Kardiologicznej.


Zakłady współpracujące to zakłady, które podczas dalszego ustalania leczenia pacjenta mogą być wybrane przez




Operatora lub Koordynatora leczenia jako pierwsza pozycja (propozycjach dla pacjenta), przy przekierowaniu do innego zakładu w Sieci.


System umożliwia Koordynatorowi Technicznemu każdego podmiotu skonfigurowanie w ramach każdego zakładu danego podmiotu, dowolnych zakładów współpracujących. Po skonfigurowaniu zakładów współpracujących, pojawiają się one na liście wyboru przy wybieraniu konkretnego zakładu, do którego ma być przekierowany pacjent.


Połączenie takie działa jednostronnie, tzn. oznaczenie zakładów współpracujących w podmiocie A z podmiotu B nie powoduje, że w zakładzie podmiotu B będzie zakład podmiotu A oznaczony jako współpracujący.


Dla wszystkich podmiotów zakłady AOS poziomu III są podmiotami współpracującymi.

A.74

Lista konsultacji

Panel dostępny dla Operatorów ROK.

Na liście konsultacji pojawiają się pacjenci, dla których Zlecono w systemie konsultacje.

Poprzez zlecenie konsultacji rozumie się chęć lub zgłoszenie potrzeby przeprowadzenia takiej konsultacji wobec pacjenta z Konsultantem ośrodka III poziomu.

Lista zawiera zarówno tych pacjentów, którzy nie zostali jeszcze obsłużeni (zadania aktywne) oraz tych już obsłużonych.

Lista powinna zawierać co najmniej:

- ID zlecenia konsultacji

- ID pacjenta (ID zgody)

- Imię i Nazwisko pacjenta

- PESEL pacjenta

- data zlecenia

- data konsultacji

- Status konsultacji (zlecenie, nieodbyta, odbyta)


Z listy jest możliwość otworzenia szczegółów konsultacji, w których oprócz wskazanych powyżej danych będą zawarte takie informacje jak:

- Imię i nazwisko lekarza prowadzącego pacjenta

- dane kontaktowe do lekarza prowadzącego

- preferowany sposób przeprowadzenia konsultacji

- imię i nazwisko konsultanta

- dane kontaktowe do konsultanta

A.75

Zarządzanie komunikatami

Wyświetlanie listy dodanych, aktywnych, zaplanowanych i nieaktywnych komunikatów w systemie. Możliwość dodawania dowolnie skonfigurowanych komunikatów w systemie.

Możliwość edycji komunikatów.


UWAGA! Koordynatorzy Techniczni ROK mogą zarządzać komunikatami w podobny sposób jak Administratorzy, jednak ich komunikaty zawsze są ograniczone do przypisanego Województwa, którym koordynują.


A.76

Wzory dokumentów

System musi umożliwiać edycję szablonów dokumentów generowanych w systemie co najmniej w zakresie:

- porozumienia z ośrodkami współpracującymi (z wersjonowaniem)

- porozumienia z ośrodkami współpracującymi w zakresie określania załączników w formacie PDF, które mają być sklejone z wygenerowanym porozumieniem (możliwość uploadu i zarządzania w poszczególnych wersjach)

- zgody pacjenta 1 (bez wersjonowania)

A.77

Ustawienia - Dane do porozumień

Konfiguracja danych porozumienia

System umożliwia wprowadzenie danych dla każdego Regionalnego Ośrodka Koordynującego przedstawicieli, którzy zawierają porozumienie (osoby reprezentujące podmiot).

Modyfikacji mogą dokonywać operatorzy KOK w zakresie wszystkich ROK.

Modyfikacji mogą dokonywać użytkownicy z uprawnieniem Wsparcie Techniczne w podmiocie ROK w zakresie danych tego ROK.

Konfiguracji podlegają następujące dane:

- Osoba / osoby reprezentujące podmiot (imię i nazwisko, stanowisko)

- Koordynator Xxxxxxxx (imię i nazwisko, telefon, adres e-mail)

- Koordynator Techniczny (imię i nazwisko, telefon, adres e-mail)

A.78

Panel logów systemowych

System umożliwia wyświetlanie wszelkich zapisanych logów systemowych z akcji podejmowanych przez użytkowników.


System zapewnia filtrowanie logów co najmniej po:

- użytkowniku

- pacjencie, którego dotyczyła akcja

- podmiocie, w ramach którego były podejmowane akcje

- zakresie dat

- rodzaju podjętej w systemie akcji


System umożliwia eksport logów do pliku EXCEL uwzględniając ograniczenie danych do wprowadzonych filtrów.


System może uwzględniać konieczność wprowadza co najmniej jednego filtra przed dokonaniem eksportu danych.


PACJENCI I ICH OBSŁUGA W SYSTEMIE

P.79

System zadaniowy

System koordynacji leczenia pacjentów ma opierać się o zadania dotyczące pacjentów przypisywane poszczególnym zakładom. Wszyscy użytkownicy z dostępem do listy pacjentów widzą na liście zadania przypisane do konkretnych pacjentów.


Zadanie zawsze są przypisane w kontekście pacjent - zakład.




Ponieważ na liście pacjentów wyświetlają się wszyscy pacjenci, którzy kiedykolwiek znaleźli się w danym zakładzie lub, dla których pacjentów było wyznaczone jakiekolwiek zadanie w ramach tego zakładu, znaczna część pacjentów może nie mieć aktualnych zadań w tym zakładzie.


Ścieżka pacjenta w systemie zaczyna się w chwili zgłoszenia (dodania) pacjenta do chwili jego “wyjścia” z Sieci Kardiologicznej oznaczonej odpowiednim statusem.


Pomiędzy tymi dwoma punktami odbywają się wizyty w poradni lub pobyty w SZPITALU.

Pomiędzy poszczególnymi wizytami do pacjenta oraz określonego jednego lub więcej zakładów zawsze powinno być przypisane co najmniej jedno zadanie (czasami ukryte w zależności od punktu w czasie).


Wykaz zadań do realizacji przez Ośrodki Współpracujące:

- Wyznaczenie terminu wizyty w AOS / SZPITAL

- Potwierdzenie przybycia pacjenta na wizytę / hospitalizację (pobyt w szpitalu)

- Potwierdzenie zaakceptowanego przez pacjenta terminu wizyty

- Potwierdzenie przyjęcia rezygnacji pacjenta z proponowanego terminu w tym zakładzie

- Kwalifikacja

- Wypełnienie danych wizyty w poradni

- Wypełnienie danych pobytu w szpitalu


Wykaz zadań do realizacji przez ROK

- Wybierz termin z pacjentem

- Brak wyznaczonego terminu przez ośrodki współpracujące

- Uzupełnij dane konsultacji


Wykaz zadań do realizacji przez KOK

- Wypełnij Ankietę Satysfakcji z pacjentem


Większość zadań generowana jest automatycznie w zależności od aktualnego statusu pacjenta. Część zadań jest generowanych po wykonaniu odpowiedniej akcji przez Operatorów lub Koordynatorów Leczenia ROK lub KOK.


Ilekroć w tej specyfikacji mowa o zadaniach, mowa jest o jednym z powyżej wskazanych zadaniach.


Poszczególne zadania opisane są w następnej podkategorii tematycznej “ZADANIA PACJENT - ZAKŁAD”.

P.80

Rekord pacjenta

Rekord pacjenta powinien zawierać co najmniej następujące dane:

- ID pacjenta w systemie (ID pacjenta jest jednocześnie nr świadomej zgody pacjenta)

- Imię

- Nazwisko

- PESEL (unikalny)

- Data urodzenia

- Płeć




- nr tel. kontaktowego

- Województwo

- TERYT

- Miejscowość

- Ulica

- Numer budynku / mieszkania

- Kod pocztowy

- Koordynaty na mapie (np. Google Maps) - uzyskiwane poprzez API Geolokalizacji przy dodawaniu pacjenta

- data utworzenia rekordu

- ID osoby tworzącej rekord

- data usunięcia rekordu

- ID osoby, która usuwała rekord

- ID zakładu, który tworzył rekord

- data zakończenia uczestnictwa w Sieci Kardiologicznej

- ID podmiotu kończącego uczestnictwo pacjenta w Sieci Kardiologicznej

- ID użytkownika kończącego uczestnictwo pacjenta w Sieci Kardiologicznej

- ID przyczyny końca uczestnictwa pacjenta w Sieci Kardiologicznej

- notatki odnośnie koordynacji pacjenta (pole tekstowe)


Dodatkowo powinny być dostępne informacje (do decyzji wykonawcy czy w ramach rekordu pacjenta czy wyliczana dynamicznie lub przechowywane w oddzielnych tabelach).

- ID podmiotu, który aktualnie lub ostatnio obsługiwał pacjenta

- ID zakładu, który aktualnie lub ostatnio obsługiwał pacjenta

- Aktualny lub ostatni poziom, na którym pacjent był obsługiwany (I,II lub III)

- data ostatniej aktualizacji danych pacjenta

- ID użytkownika, który ostatnio dokonywał aktualizacji danych pacjenta

- aktualna ścieżka leczenia, w której znajduje się pacjent

- aktualny status kwalifikacji pacjenta

- aktualny status leczenia pacjenta

- aktualne zadania przypisane do pacjenta

- status udzielenia odpowiedzi do Ankiety Satysfakcji

- data udzielenia odpowiedzi do Ankiety Satysfakcji

- aktualne rozpoznanie icd10

- data następnej najbliższej wizyty w ramach Sieci Kardiologicznej

- ID zakładu, w którym odbędzie się następna najbliższa wizyty w ramach Sieci Kardiologicznej

- ID następnej najbliższej wizyty

- status wymaganego udziału KOK

P.81

Rekord wizyty / pobytu

Rekord wizyty / pobytu pacjenta powinien zawierać co najmniej następujące dane:

- ID rekordu

- ID pacjenta




- ID podmiotu

- ID zakładu

- ID rodzaju wizyty / pobytu

- ID statusu kwalifikacji

- ID statusu odbycia wizyty

- data wizyty

- data końca (tylko w przypadku pobytów w SZPITALU)

- data wprowadzenia danych wizyty wraz ze statusem odbycia wizyty

- ID użytkownika wprowadzającego dane / kończącego wizytę

- ID koordynatora leczenia

- data utworzenia rekordu

- ID użytkownika, który utworzył rekord (0 jeżeli rekord został utworzony automatycznie przez system)

- data usunięcia rekordu

- ID użytkownika, który usunął rekord

- rozpoznanie wejściowe (ICD10)

- rozpoznanie wyjściowe (ICD10)

- ścieżka wejściowa

- ścieżka wyjściowa

- dane zleconych badaniach diagnostycznych (tylko status tak / nie zgodnie z listą badań opisanych w wytycznych w zależności od poziomu zakładu, typu zakładu oraz wybranej ścieżki leczenia)


Dodatkowo powinny być dostępne informacje (do decyzji wykonawcy czy w ramach rekordu pacjenta czy wyliczana dynamicznie lub przechowywane w oddzielnych tabelach).

- data akceptacji wizyty przez pacjenta

- ID użytkownika odnotowującego akceptację pacjenta

- data ostatniej edycji rekordy

- ID użytkownika, który ostatnio edytował rekord

- odległość w km zakładu od miejsca zamieszkania pacjenta

- liczba dni hospitalizacji (jeżeli pobyt w SZPITALU)

- informacje o zmianach terminu

- informacje o przyczynach nieobecności lub rezygnacji

- informacje o skierowaniu PIN

- informacje o skierowaniu Przyczyna lub oczekiwania wobec wizyty (krótki opis tekstowy)


Rodzaje wizyt / pobytów

- Wizyta POZ / SZPITAL KIERUJĄCY

- Wizyta Kwalifikacyjna (Tylko AOS)

- Wizyta AOS

- Pobyt SZPITAL


Statusy kwalifikacji




- Niezakwalifikowany

- Zakwalifikowany

- Do kwalifikacji


Status odbycia wizyty:

- zaproponowana

- zaplanowana (potwierdzona przez pacjenta)

- odbyta (potwierdzenie przybycia pacjenta)

- nieodbyta (pacjent się nie stawił)

- odwołana (pacjent zrezygnował)

P.82

Dodawanie pacjentów

Pacjentów mogą dodawać użytkownicy w lokalnej roli Operator lub Koordynator Leczenia następujących typów zakładów:

- POZ

- AOS

- SZPITAL (Tylko kierujący)


Dodanie pacjenta z POZ lub SZPITALA (zgłoszenie) wymaga późniejszej WIZYTY KWALIFIKACYJNEJ (w wymaganiach jest to opisane w dalszym etapie).


Dodanie pacjenta w AOS jest traktowane jako WIZYTA KWALIFIKACYJNA i wymaga rozszerzonego formularza dodawania pacjenta, lub po dodaniu bezpośrednio przełączenie na formularz wizyty kwalifikacyjnej.


Weryfikacja czy pacjent może być dodany do Sieci Kardiologicznej


System posiada mechanizm weryfikacji, czy pacjent może zostać dodany do sieci. Warunki są następujące

1. PESEL nie istnieje w bazie lub

2.a. PESEL istnieje w bazie oraz

2.b. Pacjent posiada status zakończenie uczestnictwa w Sieci Kardiologicznej (pacjent przeszedł ścieżkę leczenia, zakończył ją i ponownie rozpoczyna kolejną lub tę samą ścieżkę)


W przypadku gdy PESEL istnieje w bazie, a pacjent nadal znajduje się w Sieci Kardiologicznej, podczas próby dodania tego pacjenta wyświetla się komunikat wskazujący, że pacjent już znajduje się w Sieci Kardiologicznej pod opieką wskazanego zakładu oraz z informacją i danymi kontaktowymi do Koordynatora Leczenia w tym zakładzie.


Zgłoszenie pacjenta POZ / SZPITAL KIERUJĄCY




System ma umożliwiać zgłoszenie pacjenta do Sieci w następujących krokach:

- podanie danych identyfikacyjnych oraz oznaczenie odpowiednich zgód na udział w programie

- weryfikacja czy pacjenta może być zgłoszony do Sieci

- wprowadzenie danych osobowych oraz teleadresowych pacjenta

- wprowadzenie danych wizyty oraz wstępnego rozpoznania i ścieżki (wybór kodu ICD-10 i automatyczne przypisanie ścieżki w zależności od kodu ICD-10)


Działanie automatyczne:

- automatyczne dobranie AOS do wizyty kwalifikacyjnej

- utworzenie zadania “Wyznaczenie terminu wizyty” dla wybranych AOS


Formularz zgłoszenia pacjenta musi być maksymalnie prosty w użyciu i prowadzić użytkownika przez cały proces krok po kroku.


Zgłoszenie pacjenta AOS


System ma umożliwiać zgłoszenie pacjenta do Sieci w następujących krokach:

- podanie danych identyfikacyjnych oraz oznaczenie odpowiednich zgód na udział w programie

- weryfikacja czy pacjenta może być zgłoszony do Sieci

- wprowadzenie danych osobowych oraz teleadresowych pacjenta

- wprowadzenie danych wizyty oraz wstępnego rozpoznania i ścieżki (wybór kodu ICD-10 i automatyczne przypisanie ścieżki w zależności od kodu ICD-10)

- wybór dalszego kroku w ścieżce leczenia pacjenta

- (opcja) jeśli w wyborze dalszego kroku następuje zmiana zakładu - możliwość dookreślenia konkretnych zakładów z którymi współpracuje zakład aktualnie obsługujący pacjenta

- oznaczenie wykonanych lub zleconych badań diagnostycznych


Działanie automatyczne (tylko jeśli w wyborze dalszego kroku następuje zmiana zakładu obsługującego):

- automatyczne dobranie AOS do kolejnej wizyty lub pobytu w szpitalu (tylko gdy nie wskazano określonych zakładów)

- utworzenie zadania “Wyznaczenie terminu wizyty” dla wybranych AOS lub SZPITALI


Formularz zgłoszenia pacjenta musi być maksymalnie prosty w użyciu i prowadzić użytkownika przez cały proces krok po kroku.


SZCZEGÓŁOWE WARUNKI:

Formularze i zasady włączania pacjentów opisane są szczegółowo w Załącznik nr 1 - Wytyczne postępowania oraz Załącznik nr 2 - Instrukcja prototypu dla POZ oraz Załącznik nr 3 - Instrukcja prototypu dla AOS.

P.83

Lista pacjentów w AOS / SZPITAL

System powinien umożliwić użytkownikom z dostępem do listy pacjentów tj. Operatora i Koordynatora Leczenia - wyświetlenie listy pacjentów z danego zakładu (w zależności od włączonego kontekstu zakładu).





Lista pacjentów powinna obejmować co najmniej następujące dane:

- Nr zgody (ID), Imię i nazwisko, PESEL, Ścieżka pacjenta w ramach której pacjent jest obsługiwany

- Poziom, na którym pacjent jest obsługiwany

- Data obsługi pacjenta w podmiocie / zakładzie

- Aktualny status leczenia pacjenta

- Data następnej najbliższej wizyty pacjenta w podmiocie / zakładzie

- informacje o ostatniej odbytej konsultacji (w ramach podmiotu / zakładu)

- Informacja o wymaganych działaniach (Zadaniach), o ile są aktualnie przypisane do zakładu


Z poziomu listy użytkownicy powinni mieć możliwość wykonania co najmniej następujących akcji:

- Otworzenie Historii Leczenia w ramach Sieci Kardiologicznej

- Edycję danych osobowych i kontaktowych pacjenta

- Zmianę daty wizyty (po spełnieniu warunków logicznych związanych z terminami)

- Wykonanie wskazanego zadania (w zależności od zadania)

- Wprowadzenie danych zlecenia konsultacji

- Podgląd danych kontaktowych pacjenta


PRZYKŁADY:

Rysunek 7 - Lista pacjentów

P.84

Lista zgłoszonych pacjentów POZ / SZPITAL KIERUJĄCY

Jeżeli użytkownik działa w kontekście zakładu o typie POZ, System wyświetla listę wszystkich zgłoszonych pacjentów przez xxxx XXX. Lista zawiera dane Pacjenta, takie jak:

- Nr zgody (identyfikator służący do rozliczania świadczeniodawcy z NFZ),

- Xxxx i nazwisko,

- PESEL / Nr dok. pot. toż.,

- Ścieżkę zgłoszoną przez POZ (NT, NS, WS, ZR),

- Aktualną ścieżkę leczenia (NT, NS, WS, ZR)

- Datę dodania,

- Status kwalifikacji

- Aktualny status pacjenta w Sieci


System umożliwia filtrowanie listy co najmniej po:

- Pacjencie

- Ścieżce

- Statusie kwalifikacji

- Zakresie dat zgłoszenia


Z poziomu tej listy użytkownicy nie mają możliwości podejmowania żadnych działań wobec rekordu pacjenta z wyłączeniem możliwości pobrania zestawienia w dokumencie EXCEL.

P.85

Historia leczenia

System w przystępny i czytelny sposób umożliwia wyświetlanie historii leczenia pacjenta w ramach Sieci




Kardiologicznej.


Historia leczenia wyświetla i uwzględnia:

- dane pacjenta (ID, PESEL, oraz Imię i Nazwisko)

- Chronologiczną kolejność odbytych wizyt w POZ i AOS oraz pobytów w SZPITALU

- Aktualne zadania przypisane zakładom względem pacjenta (np. zadanie wyznaczenia terminów wizyt)


Każda chronologiczna informacja o wizycie wyświetla co najmniej następujące dane:

- data wizyty lub początku pobytu

- data zakończenia pobytu (o ile dotyczy pobytu szpitalnego)

- rodzaj zakładu (POZ, AOS, SZPITAL)

- poziom zakładu (I, II, III)

- ID wizyty w systemie

- Nazwa podmiotu obsługującego wizytę

- Nazwa zakładu obsługującego wizytę

- Rodzaj wizyty

- Status kwalifikacji po zakończeniu wizyty

- Rozpoznanie wejściowe (ICD10)

- Rozpoznanie wyjściowe (ICD10)

- Ścieżka wejściowa

- Ścieżka wyjściowa

- Listę zleconych lub odbytych badań diagnostycznych

- datę ostatniej edycji lub zmiany

- informacje o osobie dokonującej edycji lub zmiany

- informacje i dane kontaktowe do koordynatora leczenia przypisanego do pacjenta w ramach tego zakładu

- informacje o celu wizyty lub oczekiwaniach wobec wizyty


Wytyczne wizualne:

- preferowany forma wizualna: timeline

- każda wizyta w zakładzie o określonym typie musi być oznaczona innym kolorem (np. wszystkie wizyty w AOS - kolor niebieski, wszystkie wizyty w SZPITALU - kolor czerwony itp.)

- W przypadku zmiany rozpoznania lub ścieżki na danej wizycie, zmiana ta musi być wyróżniona kolorem

- Poszczególne wizyty/epizody muszą być odpowiednio oddzielone od siebie - nie mogą się zlewać wizualnie

- informacje dot. zakwalifikowania lub nie, powinny być oznaczone oddzielnymi widocznymi i łatwo zauważalnymi kolorami, przy czym pozytywna kwalifikacji powinna być zaznaczona odcieniem zieleni, a negatywna kwalifikacja odcieniem czerwieni


Dodatkowe funkcje w Historii Leczenia

Dostępne dla wszystkich:

- Możliwość wydrukowania pełnej historii leczenia poprzez wygenerowanie pliku PDF (Generowanie karty pacjenta)


Dostępne dla operatorów i koordynatorów leczenia w przypadku zaakceptowanej wizyty, która się jeszcze nie odbyła:




- Podejrzenie PIN skierowania


Dostępne dla operatorów i koordynatorów leczenia w zakresie wizyt lub pobytów, które się już zakończyły w ich zakładach:

- edycja zleconych lub zrealizowanych badań

- edycja terminu wizyty (z uwzględnieniem zależności od wizyty poprzedniej i następnej)

- edycja rozpoznania


Dostępne dla Wsparcia Technicznego KOK oraz Administratorów

- edycja wszystkich danych wizyty, włącznie ze zmianą dalszego leczenia

- edycja statusu kwalifikacji wizyty i pobytów

- cofanie o krok (anulowanie statusu zakończenia wizyty dla ostatniej zakończonej wizyty + usunięcie wszelkich zadań)

- edycja danych pacjenta

- możliwość dodania ręcznie wizyty w określonym zakładzie

P.86

Zmiana daty wizyty

System umożliwia wybranie akcji zmiany daty wizyty dla pacjentów, którzy mają zaplanowaną, niezakończoną wizytę w AOS lub pobyt w SZPITALU.


Zmiana daty wizyty odbywa się poprzez podanie nowego terminu i godziny wizyty lub pobytu (może też być data wcześniejsza niż obecna).


Zmiana daty wizyty powoduje (w zależności od decyzji wykonawcy) albo modyfikację daty w zaplanowanej wizycie albo zamknięcie wskazanej wizyty (z odpowiednim statusem umożliwiającym identyfikację, że wizyta się nie odbyła) i wprowadzenie nowej zaplanowanej wizyty.


Zmiany terminu może dokonać operator zakładu, do którego przypisana jest taka wizyta lub dowolny operator ROK lub KOK.


Warunki i sposób realizacji funkcji opisane są szczegółowo w Instrukcji AOS oraz instrukcji dla SZPITALA każdego poziomu stanowiące Załącznik nr 3 oraz Załącznik nr 4.

P.87

Zlecanie konsultacji

Każdy Operator lub Koordynator Leczenia zakładu I oraz II poziomu może poprosić w systemie w ramach aktualnie obsługiwanego pacjenta konsultację z Konsultantem III poziomu.


Zlecenie konsultacji wymaga podania:

- Danych osobowych i kontaktowych do lekarza prowadzącego pacjenta w ramach Sieci Kardiologicznej (Dane te nie są dostępne w systemie)

- Preferowaną formę przeprowadzenia konsultacji Konsultanta z Lekarzem Prowadzącym pacjenta (np. telefon, system do konsultacji, inne narzędzie do komunikacji zdalnej)





Wprowadzenie zlecenia konsultacji powoduje wygenerowania zadania dla ROK względem tego pacjenta “Uzupełnij dane konsultacji”


W systemie może być tylko jedno niezakończone zlecenie konsultacji dla danego pacjenta.

P.88

Podgląd danych kontaktowych pacjenta

System umożliwia podgląd danych kontaktowych poprzez wyświetlenie pop-up lub dialog box z następującymi informacjami:

- nr tel. kontaktowego do pacjenta

- aktualny zakład obsługujący

- aktualny koordynator leczenia w zakładzie obsługującym (imię i nazwisko)

- numer tel. komórkowego i adres e-mail do koordynatora leczenia


W przypadku, gdy zaplanowana jest wizyta, zaakceptowana przez pacjenta w innym zakładzie:

- zakład obsługujący w następnej wizycie

- koordynator leczenia w zakładzie obsługującym podczas kolejnej wizyty (imię i nazwisko)

- numer tel. komórkowego i adres e-mail do tego koordynatora leczenia

P.89

Rezygnacja pacjenta z uczestnictwa w Sieci Kardiologicznej

System umożliwia na każdym etapie wprowadzenie informacji o rezygnacji pacjenta z uczestnictwa w Sieci Kardiologicznej. Informację taką może wprowadzić:

- Koordynator Leczenia (w dowolnym podmiocie o ile pacjent jest aktualnie obsługiwany w tym podmiocie, lub następna wizyta jest zaakceptowana i zaplanowana w tym podmiocie)

- Operator ROK lub KOK, Wsparcie Techniczne, Administrator (w dowolnym momencie).


Na liście pacjentów przypisanych do podmiotu, system umożliwia bezpośrednio z listy wykonanie polecenia “Potwierdzenie rezygnacji pacjenta z Sieci” stosując okienko typu pop-up lub dialog box poprzez potwierdzenie tej opcji oraz wprowadzenie opisu wskazującego na powód rezygnacji.


Warunki i sposób realizacji funkcji opisane są szczegółowo w Instrukcji AOS oraz instrukcji dla SZPITALA każdego poziomu stanowiące Załącznik nr 3 oraz Załącznik nr 4.


Rezygnacja pacjenta usuwa wszelkie zadania przypisane względem tego pacjenta. Rezygnacja pacjenta dodaje zadanie dla KOK “Wypełnij Ankietę Satysfakcji”

P.90

Rezygnacja pacjenta z Hospitalizacji

W przypadku, gdy pacjent posiada zaakceptowany i zaplanowany pobyt w SZPITALU i pobyt ten nie został rozpoczęty, system ma umożliwiać Operatorowi lub Koordynatorowi Leczenia w tym zakładzie wprowadzenie informacji o rezygnacji pacjenta z Hospitalizacji (pobytu w szpitalu).


Przy wprowadzaniu rezygnacji, użytkownik musi wprowadzić przyczynę rezygnacji.


Xxxxxxxxxx z pobytu w szpitalu usuwa wszelkie inne zadania dotyczące tego pacjenta.

Rezygnacja dodaje dla AOS kierującego do SZPITALA zadanie wyznaczenia terminu wizyty w AOS.



ZADANIA PACJENT - ZAKŁAD

P.91

Wyznaczenie terminu wizyty w AOS / SZPITAL

Na liście pacjentów przypisanych do podmiotu, system umożliwia bezpośrednio z listy wykonanie zadania “Zaproponowanie terminu wizyty” stosując okienko typu pop-up lub dialog box poprzez umożliwienie wprowadzenie 2 różnych terminów wizyty z dwoma różnymi godzinami w tych dniach.


Zadanie “Proponowania terminu wizyty” jest generowane w systemie podczas zgłoszenia pacjenta przez POZ do kwalifikacji lub gdy w procesie leczenia pacjent jest kierowany do innego zakładu lub typu zakładu np. z AOS do SZPITALA w tym samym podmiocie.


Zadanie może być także ręcznie przypisane przez operatora lub administratora ROK danemu podmiotowi.


Warunki i sposób realizacji zadania opisane są szczegółowo w Instrukcji AOS oraz instrukcji dla SZPITALA każdego poziomu stanowiące Załącznik nr 3 oraz Załącznik nr 4.

P.92

Potwierdzenie przybycia pacjenta na wizytę / hospitalizację (pobyt w szpitalu)

System umożliwia oznaczenie na liście pacjentów, że pacjent przybył na wizytę lub pobyt w szpitalu.

Funkcja ta jest istotna przede wszystkim ze względu na dłuższe pobyty w szpitalach i wprowadzanie informacji o pobycie z opóźnieniem kilkudniowym względem planowanej daty przyjęcia pacjenta, gdzie w celach koordynacji Koordynator ROK musi mieć informację czy należy kontaktować się z pacjentem w celu ustalenia dalszego postępowania.


System umożliwia to poprzez oznaczenie za pomocą okna pop-up lub dialog box informacji, że pacjent przybył. W przypadku nieprzybycia pacjenta, informację tę wprowadza się w formularzu wypełnienia danych wizyty.


Wprowadzenie danych wizyty automatycznie potwierdza lub nie potwierdza przybycie pacjenta na daną wizytę lub pobyt (i usuwa zadanie) w zależności od wybranych w tym formularzu opcji.

P.93

Potwierdzenie zaakceptowanego przez pacjenta terminu wizyty

Na liście pacjentów przypisanych do podmiotu, system umożliwia bezpośrednio z listy wykonanie zadania “Potwierdzenie terminu wizyty” stosując okienko typu pop-up lub dialog box poprzez umożliwienie odznaczenia, że podmiot oferujący wizytę potwierdza, że się ona odbędzie po uprzednim wyborze tej wizyty przez pacjenta wspólnie z operatorem ROK.


Zadanie “Potwierdzenia terminu wizyty” jest generowane w systemie w momencie “Wyboru terminu wizyty” z pacjentem i wyzwalane jest przez ręczną akcję operatora ROK..


Warunki i sposób realizacji zadania opisane są szczegółowo w Instrukcji AOS oraz instrukcji dla SZPITALA każdego poziomu stanowiące Załącznik nr 3 oraz Załącznik nr 4.

P.94

Potwierdzenie przyjęcia rezygnacji

W przypadku, gdy w ramach zadania “Wybierz termin z pacjentem” pacjent dokona wyboru danego zakładu,



pacjenta z proponowanego terminu w tym zakładzie

pozostałe zakłady otrzymują zadanie potwierdzenia przyjęcia rezygnacji pacjenta z proponowanego terminu. Istotą zadania jest potwierdzenie, że dany zakład odnotował informację dotyczącą rezygnacji pacjenta z wizyty w ich zakładzie. W takiej sytuacji rezerwowany termin wizyty powinien przez operatora lub koordynatora leczenia zostać zwolniony dla innych pacjentów w funkcjonującym w danym zakładzie systemie grafików przyjęć i wizyt.


System umożliwia potwierdzenie przyjęcia rezygnacji poprzez oznaczenie za pomocą okna pop-up lub dialog box informacji, że informacja o rezygnacji została przyjęta.

P.95

Dokonaj Kwalifikacji

Po uruchomieniu zadania, użytkownikowi pojawia się panel kwalifikacji Pacjenta, w którym ma dostęp do informacji:

- danych osobowych pacjenta

- danych teleadresowych pacjenta

- informacji o wstępnym rozpoznaniu ICD10

- informacji o ścieżce wejściowej


PRZYKŁADY:

Rysunek 16 - Formularz kwalifikacji pacjenta


W ramach wizyty kwalifikacyjnej użytkownik może:

- wprowadzić inne wyjściowe rozpoznanie ICD10

- zmienić wyjściową ścieżkę leczenia

- wybrać jedną z dalszych 4 opcji:

- Zakwalifikować pacjenta i zdecydować o dalszym leczeniu

- Wskazać, że wymaga kolejnej wizyty kwalifikacyjnej przed dokonaniem kwalifikacji

- Zdyskwalifikować

- Wskazać, że pacjent wymaga natychmiastowej hospitalizacji


Zakwalifikowanie pacjenta

Po wybraniu tej opcji, użytkownikowi pojawia się panel decyzji o leczeniu.


PRZYKŁADY:

Rysunek 18 - Wybór dalsze leczenia


Z tego Panelu może wybrać:

- kolejną wizytę w tym samym zakładzie

- skierować pacjenta do szpitala lub innego AOS (określone warunki i możliwe przejścia opisane są w Wytycznych)


W przypadku zakwalifikowania Pacjenta i skierowania go do AOS niższego, wyższego poziomu lub szpitala tego samego, niższego lub wyższego poziomu należy wystawić nowe skierowanie. Skierowanie wystawia się poprzez swój system dziedzinowy a informacje ze skierowania (PIN lub numer) należy wprowadzić do systemu obsługującego sieć kardiologiczną.


W przypadku skierowania Pacjenta do AOS niższego, wyższego poziomu lub szpitala tego samego, niższego i




wyższego poziomu, po zatwierdzeniu formularza, system wysyła zapytanie odnośnie wyznaczenia terminu wizyty kwalifikacyjnej do wybranych placówek.


W przypadku, gdy operator wybrał skierowanie do AOS niższego lub wyższego poziomu, system zaproponuje najbliższe placówki AOS względem miejsca zamieszkania pacjenta o wskazanym poziomie.


W przypadku skierowania pacjenta z AOS do SZPITALA - jeśli taki szpital funkcjonuje w ramach tego samego podmiotu i jest zgodny z wybranym poziomem - system wybierze jako pierwszą rekomendowaną propozycję

SZPITAL działający w ramach tego ośrodka niezależnie od odległości miejsca zamieszkania pacjenta i następnie dobierze dwa kolejne szpitale wybranego poziomu najbliższe względem miejsca zamieszkania pacjenta.


W przypadku, gdy pacjent kierowany jest do SZPITALA o poziomie, którego nie ma w strukturze organizacyjnej podmiotu kierującego, system zaproponuje do wyboru X placówek (konfigurowalne) najbliższe geograficznie miejscu zamieszkania pacjenta.


Do zaproponowanych zakładów zostanie wysłane zadanie „Wyznaczenie 2 terminów wizyty”.

Operatorzy zakładów do których wysłano zadania powinni w ciągu X dni (konfigurowalne) zaproponować terminy wizyt ze wskazaniem dnia i godziny wizyty.

Po wyznaczeniu terminów lub upływie zdefiniowanego czasu, Operator Regionalnego Ośrodka Koordynującego kontaktuje się z Pacjentem i proponuje mu terminy określone przez zakłady, po czym zależnie od decyzji pacjenta oznacza je odpowiednio w systemie (wybrany / odrzucony). Operatorzy zakładów otrzymują powiadomienie o zatwierdzeniu lub odrzuceniu terminu.

Uwaga! Podczas rozmowy z konsultantem ROK, pacjent może zechcieć wybrać inny podmiot niż wskazane przez system. System powinien umożliwić skierowanie zapytania do innego podmiotu niż proponowany pierwotnie.


Po wybraniu przez użytkownika opcji dalszego leczenia w innym zakładzie, użytkownikowi pojawia się propozycja tych zakładów - zgodnie z algorytmem dobierania zakładów. Jeśli wśród tych zakładów znajduje się zakład, należący do tego samego podmiotu, użytkownik może go oznaczyć jako “Wybrany”. W takim przypadku system przy

wyznaczaniu zadań ma zignorować pozostałe zaproponowane zakłady.


Użytkownik może także wybrać zakład współpracujący, jeżeli uprzednio zostały one skonfigurowane przez Koordynatora Technicznego tego podmiotu lub pacjent kierowany jest do AOS III poziomu (w tym przypadku wszystkie AOS III poziomu traktowane są jako współpracujące z każdym zakładem).


W przypadku wyboru dowolnego SZPITALA, użytkownik musi także wprowadzić krótki opis (min. X znaków (konfigurowalne)) wskazując przyczynę skierowania do szpitala i oczekiwania wobec hospitalizacji lub diagnostyki klinicznej.


Użytkownik powinien mieć możliwość oznaczenia poszczególnych zleconych lub wykonanych badań diagnostycznych podczas danej wizyty. Realizuje to poprzez zaznaczenie pola checkbox przy zdefiniowanej w zależności od poziomu i typu zakładu liście badań, które powinny być zlecone zgodnie z wytycznymi.





PRZYKŁADY:

Rysunek 17 - Oznaczanie zleconych lub wykonanych badań diagnostycznych


Kolejna wizyta kwalifikacyjna

Użytkownik ma możliwość wyznaczenia kolejnej wizyty kwalifikacyjnej na poziomie AOS. Akcja taka jest dopuszczalna w sytuacji, w której pacjent musi być dodatkowo zdiagnozowany, lub przed kwalifikacją wymagana jest jego stabilizacja (nie jest to walidowane w systemie - decyzja lekarza).

W przypadku tej opcji system umożliwia użytkownikowi wprowadzenie kolejnej daty wizyty w tym samym zakładzie.

Po zatwierdzeniu, system dodaje nową wizytę, która już jest potwierdzona przez pacjenta i nie wymaga zadania wyznaczenia terminu.


PRZYKŁADY:

Rysunek 19 - Dalsza wizyta kwalifikacyjna


Dyskwalifikacja

W przypadku dyskwalifikacji (np. gdy dane diagnostyczne wskazują na brak spełnienia kryteriów włączenia pacjenta do sieci), należy zmodyfikować status pacjenta zaznaczając opcję ZDYSKWALIFIKOWANO.

Po zmianie statusu kwalifikacji pacjenta na zdyskwalifikowany pacjent nie jest dalej obsługiwany w obiegu systemu.


Natychmiastowa hospitalizacja

Gdy lekarz stwierdzi w czasie kwalifikacji, że pacjent wymaga natychmiastowej hospitalizacji (np. w terminie pomiędzy skierowaniem a pojawieniem na wizycie jego stan się pogorszył), fakt ten powinien być odnotowany w systemie poprzez zaznaczenie opcji „NATYCHMIASTOWA HOSPITALIZACJA”.


Pacjent w takim stanie ma zawieszoną kwalifikację do czasu stabilizacji jego stanu. Po zakończeniu hospitalizacji leczenie pacjenta (kwalifikacja) może być kontynuowana w AOS. System powinien kontynuować zawieszony poprzedni wątek i umożliwić wpisy dotyczące kontynuacji leczenia (kwalifikacji do sieci).

P.96

Wypełnij dane wizyty

Każda wizyta w ramach Sieci Kardiologicznej musi być wprowadzona do systemu a następnie po jej odbyciu sparametryzowana (muszą zostać wprowadzone dane odnośnie danych wizyty, decyzji dotyczących dalszego leczenia oraz wprowadzone informacje odnośnie zleconych badań).


Zadanie “Wypełnij dane wizyty” dostępne jest na liście pacjentów, od dnia, w którym wyznaczony został termin wizyty.

Po kliknięciu w przycisk zadania, zostanie wyświetlony formularz wraz z informacją o dacie i godzinie wizyty. W formularzu użytkownik ma dostęp do informacji:

- danych osobowych pacjenta

- danych teleadresowych pacjenta

- informacji o wstępnym rozpoznaniu ICD10




- informacji o ścieżce wejściowej


W ramach wypełniania danych wizyty użytkownik może:

- zmienić wyjściowe rozpoznanie ICD10

- zmienić wyjściową ścieżkę leczenia

- wybrać jedną z dalszych 2 opcji:

- Wskazać dalsze leczenie

- Wskazać, że pacjent wymaga natychmiastowej hospitalizacji


Dalsze leczenie

Po wybraniu tej opcji, użytkownikowi pojawia się panel decyzji o leczeniu.

Procedura wyboru dalszego leczenia jest tożsama jak procedura wyboru dalszego leczenia podczas kwalifikacji. UWAGA! Formularze oraz listy dostępnych badań diagnostycznych różnią się od siebie w zależności od poziomu oraz typu jednostek.


Dodatkowo, użytkownik ma jedną więcej opcję wyboru, która kończy udział pacjenta w Sieci Kardiologicznej:

- Dalsze leczenie w POZ


PRZYKŁADY:

Rysunek 20 - Formularz wypełniania wizyty pacjenta w AOS


Natychmiastowa hospitalizacja

Gdy lekarz stwierdzi, że pacjent wymaga natychmiastowej hospitalizacji (np. w trakcie leczenia jego stan się pogorszył), fakt ten powinien być odnotowany w systemie poprzez zaznaczenie opcji „NATYCHMIASTOWA HOSPITALIZACJA”.


Pacjent w takim stanie ma zawieszoną kwalifikację do czasu stabilizacji jego stanu. Po zakończeniu hospitalizacji leczenie pacjenta (kwalifikacja) może być kontynuowana w AOS. System powinien kontynuować zawieszony poprzedni wątek i umożliwić wpisy dotyczące kontynuacji leczenia.

P.97

Wypełnij dane pobytu w szpitalu

Każda wizyta w ramach Sieci Kardiologicznej musi być wprowadzona do systemu a następnie po jej odbyciu sparametryzowana (muszą zostać wprowadzone dane odnośnie danych wizyty, decyzji dotyczących dalszego leczenia oraz wprowadzenie informacji odnośnie zleconych badań).


Zadanie “Wypełnij dane pobytu w szpitalu” dostępne jest na liście pacjentów, od dnia, w którym wyznaczony został termin wizyty.

Po kliknięciu w przycisk zadania, zostanie wyświetlony formularz wraz z informacją o dacie i godzinie wizyty. W formularzu użytkownik ma dostęp do informacji:

- danych osobowych pacjenta

- danych teleadresowych pacjenta




- informacji o wstępnym rozpoznaniu ICD10

- informacji o ścieżce wejściowej


W ramach wypełniania danych wizyty użytkownik może:

- zmienić wyjściowe rozpoznanie ICD10

- zmienić wyjściową ścieżkę leczenia

- dokonać wyboru dalszego leczenia


Dalsze leczenie

Po wybraniu tej opcji, użytkownikowi pojawia się panel decyzji o leczeniu.


Użytkownik w porównaniu do Wypełniania danych AOS musi dodatkowo podać datę zakończenia hospitalizacji.


Procedura wyboru dalszego leczenia jest tożsama jak procedura wyboru dalszego leczenia podczas kwalifikacji. UWAGA! Formularze oraz listy dostępnych badań diagnostycznych różnią się od siebie w zależności od poziomu oraz typu jednostek.


Dodatkowo, użytkownik ma dwie dodatkowe opcję wyboru, która kończy udział pacjenta w Sieci Kardiologicznej:

- Dalsze leczenie w POZ

- Długoterminowa opieka w AOS

P.98

Wybierz termin z pacjentem

Operatorzy ROK wykonując zadanie “Wybierz termin z pacjentem” dokonują wyboru jednego z terminów wizyty zaproponowanych przez zakłady podczas rozmowy z pacjentem. Wybranie danego terminu powoduje wysłanie do wybranego zakładu zadania “Potwierdzenie zaakceptowanego przez pacjenta terminu wizyty” oraz “Potwierdzenie przybycia pacjenta na wizytę / hospitalizację (pobyt w szpitalu)” (które staje się widoczna dla użytkownika dopiero w dniu wizyty).


Do pozostałych zakładów, których propozycje terminów nie zostały wybrane, wysyłane jest zadanie “Potwierdzenie przyjęcia rezygnacji pacjenta z proponowanego terminu w tym zakładzie”.

P.99

Brak wyznaczonego terminu przez ośrodki współpracujące

Zadanie dynamiczne (można uznać za dynamiczny status / alert) Zadanie wyświetla się Operatorom ROK na liście pacjentów Warunkiem wyświetlenia się zadania jest:

- brak wyznaczenia terminu dla pacjenta zadaniach “Wyznaczenie terminu wizyty w AOS / SZPITAL” przez co najmniej X dni (konfigurowalne).


Kliknięcie w zadanie / status umożliwia Operatorowi dodanie kolejnych zadań “Wyznaczenie terminu wizyty w AOS / SZPITAL” dla dodatkowych zakładów dla tego pacjenta.


P.100

Uzupełnij dane konsultacji

Operator ROK uzupełnia dane konsultacji poprzez wprowadzenie informacji:

- czy odbyła się

- jeżeli nie - zamknięcie zadania i oznaczenie zlecenia konsultacji jako nieodbytego

- jeżeli tak - wprowadza:

- Imię i nazwisko Konsultanta

- Data przeprowadzenia konsultacji

P.101

Wypełnij Ankietę Satysfakcji z pacjentem

Po uruchomieniu realizacji zadania system ma postępować zgodnie z wskazanym niżej modułem ANKIETY PACJENTÓW -> Ankiety pacjentów - wypełnianie / podgląd danych

P.102

Wysyłka SMS

System, korzystając z SMS API umożliwia Wsparciu Technicznemu, Koordynatorom Pacjenta KOK oraz

Administratorom KOK na wysyłanie powiadomień SMS na dowolny wskazany numer telefonu komórkowego bezpośrednio z systemu.


Funkcjonalność powinna umożliwiać wprowadzenie numeru telefonu i treści wiadomości i przesłanie jej na wskazany numer.


System powinien prowadzić logi wysyłek SMS - tj. zapisywać który użytkownik, kiedy, na jaki numer i jaką treść wysłał poprzez wskazany moduł.


DZIAŁANIA AUTOMATYCZNE

C.103

Automatyczny wybór AOS do kwalifikacji podczas zgłaszania pacjenta POZ

System, podczas zgłaszania pacjenta przez POZ, automatycznie wyznacza X zakładów (konfigurowalne) AOS I poziomu, które otrzymają zadanie wyznaczenia terminu wizyty kwalifikacyjnej dla zgłaszanego pacjenta.


Wybór odbywa się na podstawie najmniejszej odległości od adresu zamieszkania podanego przez pacjenta do lokalizacji danego zakładu AOS.


Szczegółowy opis algorytmu zawarty jest Załącznik nr 2 - Instrukcja prototypu dla POZ.

C.104

Rozszerzenie automatyczne o kolejne zakłady (dodanie zadania

wyznaczenia terminów)

W przypadku, gdy zostały wyznaczone zadania “Wyznacz termin wizyty” a po upłynięciu X dni (konfigurowalne) żaden z zakładów, który miał wyznaczone zadanie nie wprowadził terminu wizyty, system automatycznie, zgodnie z algorytmem automatycznego doboru zakładów, dobiera Y kolejnych zakładów (konfigurowalne) i wyznacza im zadania “Wyznaczenia terminu wizyty”.

C.105

Wyznaczanie zadania “Brak wyznaczonych terminów”

Po upływie X dni (konfigurowalne) oraz jeżeli żaden z zakładów, które miał wyznaczone zadanie “Wyznaczenia terminu wizyty” nie wyznaczył tego terminu, system dodaje zadanie dla ROK “Brak wyznaczonych terminów”


C.106

Wyznaczenie zadania “Wybierz termin wizyty z pacjentem”

Po upływie X dni (konfigurowalne) oraz jeżeli co najmniej jeden zakład, który miał zadanie “Wyznaczenia terminu wizyty” wyznaczył termin, system dodaje zadanie dla ROK “Wybierz termin wizyty z pacjentem”.

C.107

Wyznaczenie zadania “Wypełnij Ankietę Satysfakcji z pacjentem”

Po spełnieniu określonych warunków:

- minęło X dni (konfigurowalne) od daty pierwszego włączenia pacjenta do Sieci Kardiologicznej a pacjent nadal pozostaje w Sieci, lub

- pacjent zakończył swój udział w sieci (np. rezygnacja z Sieci, Skierowanie do długoterminowej opieki, z wyłączeniem warunku śmierci)


system:

- zakłada ankietę dla wskazanego pacjenta

- dodaje dla KOK zadanie “Wypełnij Ankietę Satysfakcji z pacjentem”

- jeżeli podany jest numer komórkowy tel. kontaktowego - wysłanie zaproszenia do wypełnienia ankiety przez pacjenta wraz z przekazaniem mu indywidualnego adres URL, pod którym może tę ankietę wypełnić samodzielnie (konfigurowalne - w systemie Administrator KOK może zmienić czy ta akcja ma być wykonywana czy nie)

C.108

Automatyczne wymuszanie zmiany hasła

Jeżeli konfiguracja systemu ma ustawioną opcję wymuszenia zmiany hasła (konfigurowalne), to system po upływie X dni (konfigurowalne) oznacza automatycznie konto danego użytkownika, z wymuszeniem zmiany hasła po następnym udanym logowaniu.


ANKIETY PACJENTÓW

Q.109

Lista ankiet pacjentów

Lista ankiet zawiera co najmniej następujące dane:

- id ankiety

- status (oczekuje, oczekuje min. 3 dni, zakończona, przesłana, odmowa, kontakt systemowy, kontakt 1, kontakt 2, kontakt 3)

- Typ jednostki (AOS, POZ, SZPITAL)

- Imię i nazwisko pacjenta (przed anonimizacją)

- Telefon do pacjenta (przed anonimizacją)

- Wymagane działanie (zadanie - np. wypełnij ankietę)

- Data dodania ankiety


Z poziomu tej listy powinny być dostępne akcje dla użytkowników wsparcia:

- szybkie oznaczenie ankiety, że pacjent odmawia jej udzielenia

- przejście do wypełniania ankiety - jeżeli nie wypełniona

- przejście do podglądu danych i odpowiedzi pacjenta - jeżeli wypełniona

Q.110

Wypełnianie ankiety przez KOK

Zawartość formularza ankiety oraz odpowiedzi - zgodnie z Załącznikiem nr 9 . Załącznik określa także zasady i




warunki wyświetlania poszczególnych części ankiety. Formularz musi umożliwiać wypełnienie wszystkich danych zgodnie z danymi wskazanymi w załączniku.


Widok podglądu wypełnionej ankiety oraz formularza powinien zawierać co najmniej wskazane informacje:

- Dane dotyczące kontaktów z pacjentem (automatyczny, kontakt pierwszy, drugi i trzeci) - w przypadku kontaktu 1,2,3 powinien zawierać informacje o tym kiedy nastąpił kontakt, kto go przeprowadził i przez jakie kanały kontaktu (osobiście, e-mail, SMS).


Po wypełnieniu ankiety jest ona anonimizowana tzn. dane takie jak imię i nazwisko oraz telefon są usuwane z kontekstu ankiety i nie są dostępne.

Q.111

Wypełnianie ankiety przez PACJENTA

Pacjent po uzyskaniu linka (odnośnika URL) może samodzielnie wypełnić ankietę satysfakcji. Po uruchomieniu linka otwiera się formularz ankiety.

Ze względu na fakt, że odnośnik jest wysyłany poprzez SMS, formularz musi być dostosowany przede wszystkim do obsługi na urządzeniach mobilnych.


Na podstawie linka przypisanego do pacjenta, system automatycznie zapisuje takie dane jak:

- wiek

- płeć

- województwo

- data wypełnienia ankiety


Pozostałe dane wypełnia pacjent zgodnie z Załącznikiem nr 10 - Ankieta Satysfakcji Pacjenta

Ankieta musi także uwzględniać pola warunkowe i wyświetlać lub ukrywać poszczególne pytania zgodnie z instrukcjami we wskazanym załączniku.


Po zapisaniu i przesłaniu ankiety, system musi usunąć wszelkie powiązania ankiety z danym pacjentem - ankieta musi być w pełni anonimowa.

System ustawia oznaczenie / status na rekordzie pacjenta, że ankieta została wypełniona.

Q.112

Podgląd wypełnionych ankiet

System ma umożliwiać przeglądanie wypełnionych, przesłanych oraz zanonimizowanych ankiet z możliwością filtrowania listy ankiet do przeglądania po województwie oraz po typie świadczeń, które zadeklarował pacjent przy udzielaniu odpowiedzi na ankiety tj. czy korzystał z Podstawowej Opieki Zdrowotnej (POZ), poradni kardiologicznej (AOS), czy był na oddziale szpitalnym (SZPITAL).


RAPORTY, SPRAWOZDANIA I DANE STATYSTYCZNE

R.113

Raporty - statystyka danych

System powinien udostępniać statystyki zarówno w formie danych liczbowych jak i graficznym przedstawieniu wykresów, z możliwością filtrowania od wszystkich regionów, poprzez określone województwo, cały podmiot do




konkretnego zakładu.


Statystyki te powinny obejmować co najmniej następujące dane:

- Liczba pacjentów

- Średni miesięczny przyrost pacjentów

- Średni wiek pacjentów

- Liczba pacjentów do kwalifikacji

- Liczba pacjentów zdyskwalifikowanych

- Liczba pacjentów niewłączonych ze względu na konieczność pilnej hospitalizacji

- Liczba pacjentów, których stan zdrowia po kwalifikacji uległ zaostrzeniu i wymagają pilnej hospitalizacji

- Liczba pacjentów zgłoszonych do ścieżki NT (ujęcie liczbowe i procentowe)

- Liczba pacjentów zgłoszonych do ścieżki ZR(ujęcie liczbowe i procentowe)

- Liczba pacjentów zgłoszonych do ścieżki NS(ujęcie liczbowe i procentowe)

- Liczba pacjentów zgłoszonych do ścieżki WS(ujęcie liczbowe i procentowe)


- wykres przepływów kwalifikacji - od miejsca zgłoszenia i rodzaju rozpoznania wstępnego (ścieżki) do aktualnego statusu i ścieżki, w której się znajdują - przykład: Rysunek 8


- liczba pacjentów zgłoszonych do Sieci w ujęciu miesięcznym narastająco (wszyscy oraz w podziale na ścieżki NT, ZR, NS, WS)


- liczba pacjentów zgłoszonych do Sieci w ujęciu miesięcznym (w danym miesiącu) (wszyscy, oraz w podziale na ścieżki NT, ZR, NS, WS)


- liczba kobiet zgłoszonych do Sieci (w ujęciu liczbowym i procentowym)

- liczba mężczyzn zgłoszonych do Sieci (w ujęciu liczbowym i procentowym)

- wiek pacjentów zgłoszonych do Sieci w podziale co 5 lat począwszy od 18 lat


- liczba pacjentów zakwalifikowanych do Sieci w ujęciu miesięcznym narastająco (wszyscy, oraz w podziale na ścieżki NT, ZR, NS, WS)


- liczba pacjentów zakwalifikowanych do Sieci w ujęciu miesięcznym (w danym miesiącu) (wszyscy, oraz w podziale na ścieżki NT, ZR, NS, WS)


- liczba kobiet zakwalifikowanych do Sieci (w ujęciu liczbowym i procentowym)

- liczba mężczyzn zakwalifikowanych do Sieci (w ujęciu liczbowym i procentowym)

- wiek pacjentów zakwalifikowanych do Sieci w podziale co 5 lat począwszy od 18 lat


- Średni czas od skierowania z POZ w danym miesiącu do pierwszej wizyty w AOS I poziomu, które się odbyła (niezależnie od tego czy wizyta ta zakończyła się kwalifikacją) (miesięcznie z uwzględnieniem danych tylko z danego miesiąca - oraz dana łączna za cały okres statystyczny)





- Średni czas od skierowania z POZ w danym miesiącu do pierwszej wizyty w AOS I poziomu, która się odbyła i zakończyła kwalifikacją, dyskwalifikacją lub pilną hospitalizacją (miesięcznie z uwzględnieniem danych tylko z danego miesiąca - oraz dana łączna za cały okres statystyczny)


- Średni czas od skierowania z POZ w danym miesiącu do pierwszej wizyty w AOS I poziomu, która się odbyła i wykazano w niej skierowanie na procedury diagnostyczne (miesięcznie z uwzględnieniem danych tylko z danego miesiąca - oraz dana łączna za cały okres statystyczny)


- Procent (%) pacjentów, którzy od skierowania z POZ w okresie do wskazanego miesiąca do pierwszej wizyty w AOS I poziomu, która się odbyła i wykazano w niej skierowanie na procedury diagnostyczne, której czas nie

przekraczał 30 dni (miesięcznie z uwzględnieniem danych tylko z danego miesiąca - oraz dana łączna za cały okres statystyczny)


- Procent (%) pacjentów, którzy od skierowania z POZ w okresie do wskazanego miesiąca do pierwszej wizyty w AOS I poziomu, która się odbyła i zakończyła kwalifikacją, dyskwalifikacją lub pilną hospitalizacją, której czas nie

przekraczał 45 dni (miesięcznie z uwzględnieniem danych tylko z danego miesiąca - oraz dana łączna za cały okres statystyczny)


Koordynatorzy Leczenia, Koordynatorzy Techniczni, Administratorzy KOK i ROK muszą mieć możliwość drążenia danych, co najmniej w zakresie wskazania listy pacjentów, z których składa się przedstawiona statystyka.


Raporty mają być dostępne dla wszystkich użytkowników. Drążenie danych - wyświetlanie inf. o pacjenta dostępne wyłącznie dla wybranych uprawnień.

Raporty całościowe i dla konkretnych województw dostępne dla każdego użytkownika.

Raporty podmiotów i zakładów dostępne tylko dla użytkowników przypisanych do danych podmiotów lub zakładów oraz administratorów ROK i KOK.


PRZYKŁADY:

Rysunek 15 - Przykład raportu statystycznego z danych

R.114

Raporty - Zestawienia sprawozdań kwartalnych AOS / SZPITAL

System wyświetla raport (listę) ze sprawozdań kwartalnych wszystkich podmiotów włączonych do Sieci Kardiologicznej w danym województwie (przypisanych do danego ROK), zawierający co najmniej:

- Nazwę podmiotu

- Adres podmiotu

- Sprawozdane wskaźniki: (A1, A2a, A2b, A3, A4a, A4b, B1, B2, B3, B4, B5)

- Wyliczone dynamiczne wskaźniki dla podmiotu (A1, A2a, A2b, A3, A4a, B1, B2, B3)

- Datę przesłania sprawozdania


System musi wyświetlać raport w ujęciu kwartalnego okresu sprawozdawczego.




Dane wyliczone dynamiczne muszą obejmować drążenia - tj. wyświetlenie listy pacjentów z których składa się informacja.

Raport dostępny jest dla administratorów ROK.

Jeden podmiot może być przypisany do kilku ROK - w takim przypadku w raporcie danego ROK dane dynamiczne muszą uwzględniać wyłącznie zakłady działające w określonym województwie a dane sprawozdania powinny być przypisane do danego województwa.


System wyświetla także te podmioty i dane dynamicznie wyliczone dla tych podmiotów, które nie złożyły jeszcze sprawozdania za dany okres rozliczeniowy (kwartalny).


PRZYKŁADY:

Rysunek 11 - Zestawienia sprawozdań kwartalnych

Rysunek 12 - Zestawienie sprawozdań kwartalnych w danym województwie

R.115

Raporty - Zestawienia kwartalne POZ

System wyświetla dla administratorów ROK zestawienie pacjentów skierowanych z POZ w danym województwie w danym okresie sprawozdawczym (kwartalnym) obejmujące co najmniej następujące dane:

- ID pacjenta

- PESEL

- Imię i Nazwisko

- ID zakładu kierującego

- Nazwę zakładu kierującego

- Adres zakładu kierującego

- Datę skierowania

- ICD-10 wejściowe

- ICD-10 aktualne (ostatnie)

- Ścieżka wejścia

- Ścieżka aktualna (ostatnia)

- Status kwalifikacji

- Status aktualny w Sieci Kardiologicznej


PRZYKŁADY:

Rysunek 9 - Zestawienia kwartalne POZ Rysunek 10 - Zestawienie kwartalne POZ

R.116

SPRAWOZDANIA

System umożliwia generowanie, składanie oraz późniejszy podgląd sprawozdań kwartalnych każdego podmiotu w odniesieniu do każdego województwa, w którym zakłady podmiotu są włączone do Sieci Kardiologicznej.


Sprawozdanie zawiera następujące dane:

- Nazwa Podmiotu

- Najwyższy poziom podmiotu




- Numery Umów z NFZ

- Data sporządzenia

- Informacja za jaki okres sprawozdanie jest składane

- Miernik A1 - Liczba stwierdzonych przypadków nadciśnienia wtórnego i opornego (wyliczany automatycznie na podstawie danych z systemu)

- Miernik A2a - Liczba ablacji w zaburzeniach rytmu serca (wyliczany automatycznie na podstawie danych z systemu)

- Miernik A2b - Liczba ablacji w zaburzeniach rytmu serca bez nawrotu arytmii począwszy od 6 miesiąca od dnia wykonania procedury (Możliwość uzupełnienia ręcznie przez pracownika ROK - dana dostarczana w późniejszym terminie przez NFZ)

- Miernik A3 - Liczba pacjentów z ciężka wadą serca skierowanych do leczenia zabiegowego (wyliczany automatycznie na podstawie danych z systemu)

- Miernik A4a - Liczba pacjentów z niewydolnością serca (wyliczany automatycznie na podstawie danych z systemu)

- Miernik A4b - Liczba pacjentów z niewydolnością serca, którzy nie byli hospitalizowani z powodu zaostrzenia objawów niewydolności w ciągu 6 miesięcy od dnia przyjęcia w ramach programu pilotażowego (Możliwość uzupełnienia ręcznie przez pracownika ROK - dana dostarczana w późniejszym terminie przez NFZ)

- Wskaźnik B1 - Liczba świadczeniobiorców zakwalifikowanych do programu pilotażowego (wyliczany automatycznie na podstawie danych z systemu)

- Wskaźnik B2 - Liczba porad i konsultacji przeprowadzonych przez regionalny ośrodek koordynujący na zlecenie ośrodków współpracujących I i II poziomu (wyliczany automatycznie na podstawie danych z systemu)

- Wskaźnik B3 - Ocena satysfakcji świadczeniobiorców ze sprawowanej opieki, na podstawie ankiet, o których mowa w § 10 ust.2 pkt 2 (Możliwość uzupełnienia ręcznie przez pracownika ROK - dana dostarczana w późniejszym terminie przez KOK)

- Wskaźnik B4 - Wartość środków finansowych poniesionych na realizację programu pilotażowego. (Możliwość uzupełnienia ręcznie przez pracownika ROK - dana dostarczana w późniejszym terminie przez NFZ)

- Wskaźnik B5 - Średni czas oczekiwania przez świadczeniobiorców na hospitalizację planową, w ramach programu pilotażowego (wyliczany automatycznie na podstawie danych z systemu)


Każdy Miernik lub wskaźnik wyliczany automatyczne musi mieć możliwość drążenia (wyświetlenia listy pacjentów z których składa się wyliczona wartość).


W przypadku zaakceptowania i złożenia sprawozdania, system zapisuje także listę pacjentów w chwili złożenia sprawozdania. Ze względu na możliwość zmian dane te dynamicznie mogą ulec zmianom - stąd konieczność zapisania pełnej listy wraz ze sprawozdaniem.

System generuje plik PDF ze sprawozdaniem i umożliwia jego pobranie po zapisaniu i przesłaniu sprawozdania. PRZYKŁADY:

Rysunek 13 - Sprawozdania kwartalne podmiotu Rysunek 14 - Formularz sprawozdania

R.117

Sprawozdania niezakończone

System powinien umożliwiać wyświetlanie powyższego formularza oraz wyliczonych danych dynamicznych za




aktualny, niezakończony okres sprawozdawczy, bez możliwości złożenia sprawozdania.

Użytkownicy mający uprawnienie do Sprawozdań mogą przeglądać sprawozdanie niezakończone w zakresie aktualnych danych wyłącznie w trybie do odczytu.

R.118

Raporty - zdarzenia

System wyświetla listę zdarzeń w odniesieniu do “Wizyt” pacjenta w danym zakładzie / podmiocie (w zależności od uprawnień).


Minimalny poziom danych na liście:

- ID zdarzenia (wizyty)

- ID zgody (ID pacjenta)

- PESEL

- Imię i nazwisko

- ID ośrodka

- Nazwa ośrodka

- Typ i poziom ośrodka

- Data zdarzenia / wizyty / rozpoczęcia

- Data wypisu (jeżeli dotyczy pobytu w szpitalu)

- Lista wykonanych procedur

- ICD-10 wejściowe

- ICD-10 wyjściowe

- Ścieżka wejścia

- Ścieżka wyjścia

R.119

Raporty - stan systemu

System wyświetla dane związane ze stanem całego systemu. Raport dostępny wyłącznie dla Administratora KOK.

Raport obejmuje co najmniej dane:

- Wolna przestrzeń na serwerze

- Przestrzeń zajmowana przez pliki systemowe

- Przestrzeń zajmowana przez pliki użytkowników

- Przestrzeń zajmowana przez bazę danych systemu

- Przybliżona liczba użytkowników on-line

- Liczba użytkowników zarejestrowana w systemie

- Liczba rekordów wprowadzonych w bazie danych

- Czas pracy serwera (od ostatniego restartu)

R.120

Koordynacja - raport - bez

wyznaczonego terminu wizyty

Lista zadań dla OW bez wprowadzonych propozycji terminów wyznaczonej wizyty od X dni (X konfigurowalne w ustawieniach systemu)


Lista ma obejmować informacje:

- nr zgody (id pacjenta)

- imię i nazwisko pacjenta

- Typ jednostki - placówki (POZ / AOS / SZPITAL)




- Poziom jednostki - placówki

- Nazwa jednostki - placówki

- Nazwa podmiotu - do którego należy placówka

- Dane kontaktowe do koordynatora leczenia w placówce


Przeszukiwanie:

- możliwość przeszukiwania listy po każdej kolumnie


Eksport danych:

- możliwość eksportowania wyników (także po przeszukaniu) do pliku excel w formacie .xlsx

R.121

STATYSTYKI ANKIET

Statystyki muszą wyświetlać co najmniej:

- statystyczne dane ilościowe i procentowe poszczególnych odpowiedzi udzielonych przez pacjentów

- statystyki udzielenia odpowiedzi / odmowy udzielenia odpowiedzi

- statystyki braku możliwości kontaktu z pacjentem

- liczbę i % wszystkich ankiet w regionie/kraju

- liczbę i % kobiety do mężczyzn

- liczbę i % miejsce zamieszkania (województwo)


Ponadto powyższe statystyki ankiet muszą być ujęte w podziale :

na poszczególne regiony wg kryterium miejsca kwalifikacji (jeśli pacjent był zakwalifikowany w województwie X to ankieta idzie do województwa X) oraz statystyki całościowe dla kraju.


PRZENIESIENIE PRAW MAJĄTKOWYCH (OPCJA)

M.122

Przeniesienie praw majątkowych

(w przypadku opcji z przeniesieniem praw majątkowych)

Wykonawca przeniesie na Zamawiającego wyłączne prawa majątkowe do przedmiotu zamówienia, włącznie z prawami do kodu źródłowego (z wyłączeniem komponentów open source lub innych zewnętrznych), opracowanej struktury bazodanowej, dokumentacji technicznej, dokumentacji użytkownika i wszelkich pozostałych utworów

wytworzonych w celu realizacji zamówienia.

M.123

Wykorzystanie komponentów komercyjnych

(w przypadku opcji z przeniesieniem praw majątkowych)

Z wyłączeniem kodów opensource (otwartego oprogramowania) oraz komponentów oferowanych na licencji darmowej (kodów, frameworków, skryptów, bibliotek, utworów graficznych itp.) system nie może być zbudowany w oparciu o jakiekolwiek komponenty, które nie zostały wyprodukowane przez wykonawcę, co do których Wykonawca nie może w pełni przenieść wyłącznych praw majątkowych na Zamawiającego.

M.124

Pola eksploatacji

(w przypadku opcji z przeniesieniem praw majątkowych)

Zamawiający uzyskuje wyłączne, nieograniczone terytorialnie i czasowo prawa do wszelkich utworów wytworzonych w ramach zamówienia, w tym prawa do:


- Użycia utworu w dowolnym celu, w tym zarówno komercyjnym, jak i niekomercyjnym;




- Wykorzystania utworu jako części innego dzieła lub połączenia go z innymi utworami;

- Modyfikacji utworu, w tym dodawania, usuwania lub zmieniania jego części;

- Dystrybucji utworu, w tym sprzedaży, wynajmu, dzierżawy, udostępniania utworu w Internecie lub poprzez jakiekolwiek inne środki dystrybucji;

- Wyświetlania, prezentacji lub wykonania utworu publicznie;

- Przekazania praw do utworu innej osobie lub organizacji, w całości lub części;

- Wykonywania wszelkich innych praw związanych z utworem, które są zgodne z obowiązującym prawem.


Zamawiający ma prawo do korzystania z utworu bez konieczności informowania o tym Wykonawcy lub uzyskania jego zgody, i bez konieczności płacenia Wykonawcy dodatkowych opłat poza ustaloną ceną zamówienia.


DOKUMENTACJA

D.125

Dokumentacja użytkownika

Wykonawca dostarczy zestaw dokumentacji użytkownika w postaci plików w formacie elektronicznym PDF i wersji edytowalnej DOCX, zawierający aktualne instrukcje obsługi w zakresie funkcjonalnym dla poszczególnych grup użytkowników:

- użytkownicy POZ z poszczególnymi rolami

- użytkownicy AOS z poszczególnymi rolami

- użytkownicy SZPITALA z poszczególnymi rolami

- operatorzy Regionalnego Ośrodka Koordynującego

- operatorzy Krajowego Ośrodka Koordynującego

- administratorzy

- koordynatorzy techniczni

- pełna dokumentacja użytkowa systemu dla wszystkich typów placówek i ról w systemie łącząca wszystkie powyższe dokumentacje


Wszystkie instrukcje są dostarczane Zamawiającemu w języku polskim.

D.126

Dokumentacja techniczna

Wykonawca dostarczy pełną dokumentację techniczną systemu, obejmującą co najmniej:

- opis konfiguracji środowiska pracy,

- opis instalacji systemu, komponentów i programów zależnych

- opis konfiguracji systemu

- opis uruchomienia produkcyjnego systemu

- opis konfiguracji środowiska zapasowego

- opis konfiguracji systemu backupowania

- opis procedury odzyskiwania systemu z backupu

- opis instalacji systemu bazodanowego

- opis konfiguracji systemu bazodanowego




- wykaz i opis konfiguracji skryptów automatycznych (np. CRON)


Dokumentacja musi być dostarczona w języku polskim

D.127

Dokumentacja bazy danych

Opis struktury bazodanowej w tym tabel, widoków, relacji (bazodanowych lub logicznych zrealizowanych w systemie), funkcji oraz wyzwalaczy w formie opisowej oraz notacji UML.


Załączniki:

Załącznik nr 1 - Wytyczne postępowania Załącznik nr 2 - Instrukcja dla POZ Załącznik nr 3 - Instrukcja dla AOS Załącznik nr 4 - Instrukcja dla SZPITAL

Załącznik nr 5 - Instrukcja dla Koordynatorów Technicznych - zarządzanie użytkownikami Załącznik nr 6 - Instrukcja włączania nowego podmiotu do systemu KSK

Załącznik nr 7 - Instrukcja rejestracji podmiotu w prototypie systemu KSK Załącznik nr 8 - Wzór aktualnego porozumienia z ośrodkami współpracującymi Załącznik nr 9 - Ankieta Satysfakcji Pacjenta

Załącznik nr 10 - Rozporządzenie Ministra Zdrowia z dnia 10 maja 2021 r. w sprawie programu pilotażowego opieki nad świadczeniobiorcą w ramach sieci kardiologicznej (ttps://xxxx.xxxx.xxx.xx/xxxx.xxx/xxxxxxxx.xxx/XXX00000000000/X/X00000000.xxx)


Signature Not Verified

Dokument podpisany przez Xxxxx Xxxxxx Data: 2023.08.08 07:59:00 CEST

Rysunki


Rysunek 1 - Formularz dodawania podmiotu

Rysunek 2 - Formularz dodawania użytkownika


Rysunek 3 - Formularz zmiany ról użytkownika


Rysunek 4 - Lista podmiotów włączonych


Rysunek 5 - Szczegóły podmiotu włączonego


Rysunek 6 - Lista użytkowników


Rysunek 7 - Lista pacjentów


Rysunek 8 - Wykres przepływu pacjentów


Rysunek 9 - Zestawienia kwartalne POZ

Rysunek 10 - Zestawienie kwartalne POZ


Rysunek 11 - Zestawienia sprawozdań kwartalnych


Rysunek 12 - Zestawienie sprawozdań kwartalnych w danym województwie


Rysunek 13 - Sprawozdania kwartalne podmiotu


Rysunek 14 - Formularz sprawozdania


Rysunek 15 - Przykład raportu statystycznego z danych


Rysunek 16 - Formularz kwalifikacji pacjenta


Rysunek 17 - Oznaczanie zleconych lub wykonanych badań diagnostycznych


Rysunek 18 - Wybór dalsze leczenia



Rysunek 19 - Dalsza wizyta kwalifikacyjna


Rysunek 20 - Formularz wypełniania wizyty pacjenta w AOS


Rysunek 21 - Wizualizacja środowiska systemu


Document Metadata

Filed: October 4th, 2024