AKADEMIA GÓRNICZO-HUTNICZA Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki KATEDRA INFORMATYKI. Health Care Manager

AKADEMIA GÓRNICZO-HUTNICZA Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki KATEDRA INFORMATYKI System obsługi niewielkiej przychodni specjalistycznej Kierunek, rok studiów: Informatyka Wersja 1.0 z dnia 15.01.2010 Przedmiot: Projektowanie Systemów Informatycznych Prowadzący przedmiot: dr inż. Małgorzata Żabińska-Rakoczy rok akademicki: semestr: 2009/2010 zimowy Zespół autorski: Grzegorz Gunia Aleksandra Magura-Witkowska Paweł Jastrzębski Agnieszka Zagórska sawtyss@student.agh.edu.pl amw@student.agh.edu.pl pjastrz@ gmail.com zagorska@ student.agh.edu.pl Koordynator Sekretarz Pracownik Pracownik Kraków, styczeń 2010

Niniejsze opracowanie powstało w trakcie i jako rezultat zajęć dydaktycznych z przedmiotu wymienionego na stronie tytułowej, prowadzonych w Akademii Górniczo-Hutniczej w Krakowie (AGH) przez osobę (osoby) wymienioną (wymienione) po słowach Prowadzący zajęcia i nie może być wykorzystywane w jakikolwiek sposób i do jakichkolwiek celów, w całości lub części, w szczególności publikowane w jakikolwiek sposób i w jakiejkolwiek formie, bez uzyskania uprzedniej, pisemnej zgody tej osoby (tych osób) lub odpowiednich władz AGH. Copyright 2006 Akademia Górniczo-Hutnicza (AGH) w Krakowie Spis treści 1 Sformułowanie zadania projektowego... 5 1.1 Obszar i przedmiot modelowania... 5 1.1.1 Dziedzina problemu... 5 1.1.2 Obszar modelowania... 6 1.1.3 Zakres odpowiedzialności systemu... 9 1.2 Zwięzła nazwa problemu... 9 1.3 Cele do osiągnięcia... 10 1.3.1 Cele produktu... 10 1.3.2 Cele przedsięwzięcia... 10 2 Opis wymagań przyszłych użytkowników... 11 2.1 Funkcje systemu z punktu widzenia użytkownika... 11 2.1.1 Rejestracja i pacjenci... 11 2.1.2 Leczenie... 11 2.1.3 Pracownicy... 11 2.2 Dokumenty wprowadzane do i wyprowadzane z systemu... 12 2.2.1 Wprowadzane... 12 2.2.2 Wyprowadzane... 12 2.3 Dane przechowywane w systemie... 14 2.4 Sygnalizowane specjalne wymagania i ograniczenia... 14 2.5 Podsumowanie wymagań... 15 2.5.1 Przypadki użycia:... 15 3 Analiza funkcjonalna systemu diagramy DFD... 26 3.1 Diagram Kontekstowy:... 26 3.2 DFD 1... 27 3.2.1 DFD 1.2... 28 3.3 DFD 1.3... 30 3.4 DFD 1.4... 31 3.5 DFD 1.5... 32 3.5.1 DFD 1.5.1... 33 Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 2 z 93

4 Roboczy słownik danych... 34 5 Analiza struktur danych przechowywanych w systemie... 36 5.1 Tabela krzyżowa... 36 5.2 Tabela relacji między obiektami... 37 5.3 Opis struktur danych... 38 5.4 Pełny diagram relacji... 42 6 Obraz zachowania systemu w czasie... 43 6.1 Diagramy STD... 43 6.1.1 Diagram STD ogólny... 43 6.1.2 Diagram STD osoba odpowiedzialna za rejestrację (dyspozytor)... 44 6.1.3 Diagram STD lekarz... 46 6.1.4 Diagram STD pacjent (serwis WWW)... 47 6.2 Diagramy Entity Life History (ELH)... 48 6.2.1 Diagram ELH związany z pacjentem... 48 6.2.2 Diagram ELH związany ze skierowaniami... 48 6.2.3 Diagram ELH związany z dyżurami... 49 6.2.4 Diagram ELH związany z wizytami... 49 6.2.5 Diagram ELH związany z badaniami... 49 7 Uzupełnienie wymagań funkcjonalnych i niefunkcjonalnych... 50 7.1 Wymagania funkcjonalne dla każdej ze zdefiniowanych funkcji systemu... 50 1. Rejestracja i pacjenci... 50 2. Leczenie... 52 3. Pracownicy... 53 4. Administracja... 54 7.2 Wymagania niefunkcjonalne... 56 8 Specyfikacje funkcji (procesów)... 57 1. Rejestracja i pacjenci... 57 2. Leczenie... 65 9 Architektura systemu... 74 10 Projekt interfejsu użytkownika... 76 10.1 Założenia ogólne... 76 10.2 Wspólne elementy interfejsu graficznego (standardy, konwencje)... 76 10.3 Lista okien dialogowych... 77 10.3.1 Dialogi :: osoba odpowiedzialna za rejestrację pacjentów... 77 10.3.2 Dialogi :: lekarz... 83 10.3.3 Dialogi :: pacjent... 84 10.4 Szkice GUI... 84 10.4.1 Okno interfejsu osoby odpowiedzialnej za rejestrację... 84 10.4.2 Przykładowe formularze dodania nowego pacjenta oraz edycji danych osobowych pacjenta... 85 10.5 System pomocy... 86 11 Podsumowanie... 87 11.1 Założenia co do implementacji systemu... 87 Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 3 z 93

11.2 Weryfikacja projektu systemu... 87 11.2.1 Wykryte błędy i stwierdzone niedoskonałości... 87 11.2.2 Propozycje zmian i ulepszeń... 87 11.2.3 Kierunki rozwoju... 87 11.3 Uwagi i wnioski końcowe... 88 12 Załączniki... 90 Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 4 z 93

1 Sformułowanie zadania projektowego 1.1 Obszar i przedmiot modelowania 1.1.1 Dziedzina problemu Zakres rozważanego problemu obejmuje kompleksową obsługę niewielkiej przychodni specjalistycznej rozumianej jako zbiór kilku gabinetów lekarskich wielu niezależnych lekarzy różnych specjalizacji. Zakres działania jednostki obejmuje świadczenie prywatnych usług medycznych. Rozpatrywany przypadek dotyczy gabinetów prywatnych lekarzy różnych specjalizacji z naciskiem na ogólność, bez uzależniania modelu systemu od możliwych specjalizacji zatrudnionych lekarzy. Struktura organizacyjna przychodni pozwala wyodrębnić (w uproszczeniu) następujące grupy, m.in. zespół lekarzy specjalistów, wykwalifikowany personel pomocniczy, zarząd spółki, pracownicy administracji, zróżnicowane pod kątem uprawnień i możliwości korzystania z systemu. Ze względu zakres działalności odbiorcy systemu, kluczowym aspektem działania jest ochrona przechowywanych danych pacjentów przed nieupoważnionym dostępem i rygorystyczne kontrolowanie uprawnień poszczególnych użytkowników. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 5 z 93

1.1.2 Obszar modelowania 1.1.2.1 Opis obszarów aktywności Głównym zadaniem systemu jest obsługa poprzez różnorodne podsystemy większości sfer działania przychodni, z wykluczeniem księgowości prowadzonej przez zewnętrzne biuro rachunkowe, obsługi laboratorium i obsługi magazynu. 1. Kompleksowa obsługa pacjentów, w szczególności: 1.1 Rejestracja rozszerzanie i modyfikacja bazy pacjentów; mimo rozwiniętego serwisu internetowego rejestracja możliwa jest wyłącznie osobiście. 1.2 Wizyty zarządzanie terminarzem wizyt, w szczególności umożliwienie połączenia tradycyjnej obsługi pacjentów oraz udogodnienia w postaci umożliwienia pacjentom wyznaczania terminów wizyt przez Internet, bez konieczności telefonicznego kontaktu z pracownikiem rejestracji; ponadto istnieje możliwość automatycznego wyszukiwania wolnych terminów wizyt po określeniu warunków wyszukiwania. Obszar ten obejmuje możliwość dogodnego, prostego modyfikowania wpisów w historii leczenia przez lekarza, a także wystawianie i wydruk recept oraz innych dokumentów (jak na przykład skierowań, zwolnień lekarskich). Ponadto system umożliwia automatyczne generowanie przypomnień o wizytach, zindywidualizowane zarówno pod kątem momentu czasowego jak i środka przekazu (informacja telefoniczna, wiadomość przesyłana pocztą internetową). 1.3 Serwis WWW udostępnienie przejrzystego serwisu internetowego oferującego funkcjonalności istotne z punktu widzenia wygody pacjentów, jak na przykład wymieniona powyżej możliwość ustalania terminów wizyt po zalogowaniu się w serwisie. Oprócz samodzielnego zarządzania wizytami, pacjent w przystępny sposób może także przeglądać historię wizyt lub sprawdzać ogólnodostępny grafik pracy personelu. 1.4 Przebieg leczenia przechowywanie i aktualizacja historii choroby, wyników badań, skierowań, przepisanych leków pacjenta. 1.5 Generowanie skierowań możliwość drukowania automatycznie wygenerowanych według przechowywanego szablonu 2. Administracja zasobami - ustalanie dyżurów dla poszczególnych lekarzy i sporządzanie grafiku wykorzystania gabinetów, obejmujące sytuacje gdy z jednego gabinetu specjalistycznego wchodzącego w skład przychodni korzysta kilku zatrudnionych lekarzy tej samej specjalności. System wspomaga wyszukiwanie optymalnego rozwiązania po określeniu niezbędnych warunków, jak na przykład możliwych przedziałów czasowych oraz dni w których lekarz może odbyć dyżur. System umożliwia także tworzenie zestawień różnego rodzaju, zarówno w formie graficznej jak i tekstowej z możliwością wydruku i eksportu do Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 6 z 93

pliku wybranego formatu. Aspekt ten pozwala na uzyskanie informacji o wybranych polach działania jednostki medycznej. 3. Administracja systemem w tym obszarze aktywności mieszczą się wszystkie zadania związane z zarządzaniem systemem (np. kopia zapasowa, przydzielanie kont, określanie dostępu) 4. Komunikacja z innymi podsystemami przychodni: 1. Laboratorium zautomatyzowane pobieranie wyników od podsystemu zarządzania laboratorium 2. Księgowość przesyłanie okresowych raportów z działania przychodni do systemu księgowości. 5. Archiwum przechowywanie przez 5 lat danych dotyczących osób, które zrezygnowały z usług przychodni, zmarły, lub w inny sposób zakończyły swój kontakt z systemem. 6. Tworzenie raportów i statystyk automatyczna generacja raportów z funkcjonowania przychodni według przechowywanych szablonów, które następnie mogą zostać przesłane do biura rachunkowego, lub innego organu kontrolującego działanie przychodni. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 7 z 93

1.1.2.2 Opis procedur biznesowych 1. Rejestracja a) Dodanie nowego pacjenta Pacjent pojawia się w przychodni, podaje dane osobowe (imiona, nazwisko, nazwisko rodowe, imię ojca, data i miejsce urodzenia, PESEL, płeć, adres zamieszkania, numer dokumentu tożsamości, telefon), pracownik rejestracji zakłada kartę (załącznik 3) i umieszcza ją w kartotece. b) Zmiana danych pacjenta Pacjent pojawia się w przychodni, wypełnia wniosek o zmianę danych, przekazuje go pracownikowi rejestracji, pracownik po odszukaniu karty pacjenta (załącznik 3) niszczy starą wersję karty z danymi osobowymi i w jej miejsce umieszcza nową, poprawioną. c) Przeniesienie danych pacjenta do archiwum W wypadku przeniesienia się pacjenta do innej przychodni lub śmierci pacjenta jego karta (załącznik 3) zostaje przeniesiona do archiwum, gdzie jest przechowywana przez 5 lat. 2. Wizyty a) Dodanie terminu wizyty Po podaniu danych przez pacjenta (telefonicznie lub osobiście) pracownik rejestracji uzgadnia z pacjentem dogodny termin i zapisuje go w terminarzu oraz przygotowuje kartotekę, jeżeli jest potrzebna. b) Przesunięcie terminu wizyty Po otrzymaniu prośby pacjenta o zmianę terminu, pracownik rejestracji uzgadnia z nim nowy termin, wykreśla stary z terminarza i wpisuje nowy. c) Usunięcie terminu wizyty Po otrzymaniu prośby pacjenta o anulowanie wizyty, pracownik rejestracji wykreśla ją z terminarza. 3. Przebieg leczenia a) Pobranie wyników badań z laboratorium Pacjent odbiera wyniki z laboratorium i przynosi je do lekarza lub zostawia w rejestracji. Wyniki zostają dołączone do jego kartoteki. b) Dodanie wpisu do historii choroby Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 8 z 93

Lekarz w czasie wizyty wpisuje informacje o objawach, diagnozie i leczeniu chorego do jego kartoteki na odpowiedni dokument. c) Wydanie skierowania 4. Administracja Lekarz w czasie wizyty, jeśli uzna za stosowne, wypisuje pacjentowi skierowanie (załączniki 1 i 2), z którym pacjent zgłasza się do odpowiedniej jednostki. a) Ustalanie dyżurów dla poszczególnych lekarzy Grafik sporządzony przez pracowników rejestracji razem z lekarzami zostaje przedstawiony kierownictwu przychodni, które zatwierdza lub odrzuca propozycję. 1.1.3 Zakres odpowiedzialności systemu W zakres odpowiedzialności realizowanego systemu wchodzą w całości następujące obszary aktywności: Rejestracja Wizyty Przebieg leczenia Administracja zasobami Administracja systemem Dodatkowo, system ma udostępniać funkcjonalności: Generowania przypomnień o wizytach Modyfikacji danych i terminów wizyt przez serwis WWW Komunikacji z laboratorium W zakres odpowiedzialności systemu nie wchodzą: Obsługa laboratorium Księgowość Obsługa magazynu Komunikacja z innymi przychodniami 1.2 Zwięzła nazwa problemu Projekt systemu wspomagającego zarządzanie niewielką przychodnią. Nazwa kodowa projektu: Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 9 z 93

1.3 Cele do osiągnięcia 1.3.1 Cele produktu Celem projektu jest stworzenie systemu wspomagającego funkcjonowanie przychodni specjalistycznej. Podstawową cechą systemu będzie dostarczenie przyjaznego i prostego interfejsu dla pracowników przychodni chcących w możliwie najefektywniejszy sposób wykonywać swoje obowiązki. Istotnym punktem jest także umożliwienie wykonywania niektórych czynności (rejestracja, umówienie wizyty) bez niepotrzebnego angażowania pracownika przychodni. Ponadto produkt ma za zadanie ułatwić kontrolę grafiku dyżurów i jego ewentualne zmiany, zarówno dla zainteresowanych pracowników, jak i dla kierownictwa. 1.3.2 Cele przedsięwzięcia Głównym celem, jaki przed sobą postawiliśmy, jest zaznajomienie się z projektowaniem systemów informatycznych przy zastosowaniu metodyki strukturalnej. Liczymy, że praca nad projektem da nam możliwość rozwinięcia naszych umiejętności w zakresie przeprowadzania wywiadów, zbierania wymagań i konstruowania odpowiedniej dokumentacji do przeprowadzonego projektu. Będzie też sprawdzianem naszych umiejętności w dziedzinie pracy zespołowej i terminowego wykonywania zadań. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 10 z 93

2 Opis wymagań przyszłych użytkowników 2.1 Funkcje systemu z punktu widzenia użytkownika 2.1.1 Rejestracja i pacjenci 1. Dostępność terminów 2. Anulowanie wizyty 3. Modyfikacja terminu wizyty 4. Modyfikacja danych osobowych 5. Dostępność terminów (WWW) 6. Anulowanie wizyty (WWW) 7. Modyfikacja terminu wizyty (WWW) 8. Modyfikacja danych osobowych (WWW) 9. Usługi dodatkowe dla pacjentów: Przypomnienia o wizycie (telefonicznie/sms/e-mail) 10. Usługi dodatkowe dla pracowników rejestracji: 2.1.2 Leczenie 1. Wpis do historii choroby 2. Wydruk skierowania Możliwość zatwierdzenia terminów/danych osobowych podanych przez pacjentów 3. Usługi dodatkowe dla lekarzy: Pobranie historii choroby 2.1.3 Pracownicy 1. Propozycja modyfikacji terminarza dużurów. 2. Usługi dodatkowe dla kierownictwa: Możliwość odrzucenia zmian wprowadzonych przez pracowników Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 11 z 93

2.2 Dokumenty wprowadzane do i wyprowadzane z systemu 2.2.1 Wprowadzane 2.2.1.1 Wyniki badań 2.2.2 Wyprowadzane 2.2.2.1 Potwierdzenie rejestracji (patrz załącznik 3) Imię Drugie imię Nazwisko Nazwisko rodowe Imię ojca PESEL Data i miejsce urodzenia Płeć Nr dokumentu tożsamości Numer legitymacji (opcjonalnie) Adres zamieszkania Telefon E-mail Login w systemie 2.2.2.2 Potwierdzenie zarezerwowania terminu Imię i nazwisko pacjenta Numer karty pacjenta Imię i nazwisko lekarza Dzień i godzina Data przypomnienia Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 12 z 93

2.2.2.3 Grafik wizyt Data Nazwisko i imię lekarza Godzina Imię i nazwisko pacjenta Adres pacjenta 2.2.2.4 Grafik dyżurów Data Godziny (od-do) Imię i nazwisko pracownika 2.2.2.5 Wydruk karty pacjenta (patrz załącznik 3) Imię Drugie imię Nazwisko Nazwisko rodowe Imię ojca PESEL Data i miejsce urodzenia Płeć Nr dokumentu tożsamości Numer legitymacji (opcjonalnie) Adres zamieszkania Telefon Historia choroby (wyniki badań, skierowania, wpisy lekarza) Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 13 z 93

2.3 Dane przechowywane w systemie 1. Dane pacjenta (login, numer karty pacjenta, e-mail, imiona, nazwisko, nazwisko rodowe, imię ojca, data i miejsce urodzenia, PESEL, płeć, adres zamieszkania, numer dokumentu tożsamości, telefon patrz załącznik 3) 2. Dane medyczne (choroby, ciąża, przyjmowane leki, zaburzenia krzepnięcia krwi, alergie, grupa krwi) 3. Historia wizyt (data, potwierdzenie, numer karty pacjenta) 4. Historia choroby (numer karty pacjenta, wydane skierowania, wyniki badań, wpisy lekarza dot. przebytych chorób i sposobu leczenia) 5. Terminarz dyżurów (data, godzina od-do, imię i nazwisko lekarza) 6. Pracownicy (imię, nazwisko, adres zamieszkania, telefon, data zatrudnienia) 2.4 Sygnalizowane specjalne wymagania i ograniczenia Przyjazność systemu W tym momencie wszystkie dane trzeba zapisywać ręcznie. Sugestia usprawnienia poprzez np. generowanie daty urodzenia z numeru PESEL. Ograniczenie dostępu do historii choroby tylko dla uprawnionych osób (np. lekarzy) Możliwość wydrukowania papierowej kopii karty pacjenta Recepty muszą być wypisywane ręcznie. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 14 z 93

2.5 Podsumowanie wymagań 2.5.1 Przypadki użycia: Nazwa Opis Standardowy przepływ Alternatywny przepływ Dodanie nowego pacjenta (Serwis WWW) Procedura dodawania nowego pacjenta poprzez serwis WWW 1) Pacjent przez Internet korzystając z serwisu WWW wypełnia formularz z danymi osobowymi: imię nazwisko PESEL Adres dokument tożsamości telefon wybrany (lub przydzielony automatycznie przez system) login oraz hasło opcjonalnie także e-mail 2) Pacjent klika wyślij i wysyła wypełniony formularz. 3) Pacjent pojawia się osobiście w przychodni i okazuje ważny dokument tożsamości celem aktywacji konta 4) Osoba odpowiedzialna za rejestrację aktywuje konto 5) Pacjent otrzymuje wydruk z potwierdzeniem podanych danych i hasłem 6) Konto pacjenta zostaje aktywowane 7) System generuje komunikat o poprawnym zakończeniu operacji 1a) Nie zostały wypełnione wymagane pola: wróć do punktu 1 z komunikatem, że należy wypełnić wymagane pola 1b) Wybrany przez pacjenta login już istnieje: wróć do punktu 1 z komunikatem, że podany login już istnieje 1c) Login nie został podany: wygeneruj login i przejdź do punktu 3 1d) Pacjent nie okazał ważnego dokumentu tożsamości: pracownik klika Anuluj dodawanie i operacja kończy się niepowodzeniem. Trigger Pacjent klika Zarejestruj się w serwisie WWW Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 15 z 93

Nazwa Opis Standardowy przepływ Alternatywny przepływ Dodanie nowego pacjenta (osobiście) Procedura dodawania nowego pacjenta przez pracownika rejestracji 1) Osoba odpowiedzialna za rejestrację, na podstawie danych podanych przez pacjenta, wypełnia formularz danych osobowych: imię nazwisko PESEL Adres dokument tożsamości telefon wybrany (lub przydzielony automatycznie przez system) login oraz hasło opcjonalnie także e-mail 2) Pracownik rejestracji aktywuje konto po okazaniu przez pacjenta poprawnego dowodu tożsamości. 3) Pacjent otrzymuje wydruk z potwierdzeniem podanych danych i hasłem 4) System generuje komunikat o poprawnym zakończeniu operacji 1a) Nie zostały wypełnione wymagane pola: wróć do punktu 1 z komunikatem, że należy wypełnić wymagane pola 1b) Wybrany przez pacjenta login już istnieje: wróć do punktu 1 z komunikatem, że podany login już istnieje 1c) Login nie został podany: wygeneruj login i przejdź do punktu 2 1d) Pacjent nie okazał ważnego dokumentu tożsamości: pracownik klika Anuluj dodawanie i operacja kończy się niepowodzeniem. Trigger Pracownik rejestracji klika Utwórz konto Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 16 z 93

Nazwa Opis Standardowy przepływ Alternatywny przepływ Dodanie nowej wizyty (serwis WWW) Procedura dodawania j wizyty przez pacjenta z serwisu WWW 1) Z wyświetlonej listy pacjent wybiera rodzaj wizyty oraz opcjonalnie lekarza. 2) Pacjent zatwierdza wybór. 3) Na podstawie danych z punktu 1 zostaje wyświetlony grafik dostępnych terminów. 4) Pacjent zaznacza wybrany termin, lub opcję wybierz najbliższy wolny i klika wyślij. 5) Termin zostaje wprowadzony do bazy danych. 6) Zostaje wygenerowany komunikat o poprawnym utworzeniu nowej wizyty. 2a) Pacjent rezygnuje z ustalania wizyty: zakończenie z komunikatem o pomyślnym anulowaniu procesu. 4a) Wybrany termin jest już zajęty: powrót do punktu 3 z komunikatem, że wybrany termin jest zajęty. 4b) Ilość wizyt ustalonych przez danego pacjenta przekracza wcześniej ustalony limit: 4b.1) Wyświetlenie komunikatu o potrzebie potwierdzenia danej wizyty przez pracownika rejestracji 4b.2) Dodanie terminu do listy oczekujących 4b.3) Termin zostaje aktywowany przez pracownika rejestracji 4b.4) Przejdz do punktu 5. 4b.3a) Pracownik rejestracji odrzuca podany termin: zakończenie procesu dodawania wizyty niepowodzeniem. Trigger Nazwa Opis Standardowy przepływ Alternatywny przepływ Pacjent klika opcję Umów wizytę Dodanie nowej wizyty (osobiście, lub telefonicznie) Procedura dodawania wizyty przez pracownika rejestracji 1) Pracownik rejestracji wybiera rodzaj wizyty i opcjonalnie lekarza z wyświetlonej listy. 2) Pracownik zatwierdza wybór. 3) Na podstawie danych z punktu 1 zostaje wyświetlony grafik dostępnych terminów. 4) Pracownik rejestracji zaznacza ustalony z pacjentem termin, lub opcję wybierz najbliższy wolny i klika dalej. 5) Termin zostaje wprowadzony do bazy danych. 6) Zostaje wygenerowany komunikat o poprawnym utworzeniu nowej wizyty. 2a) Pacjent rezygnuje z ustalania wizyty: zakończenie z komunikatem o pomyślnym anulowaniu procesu. 4a) Wybrany termin jest już zajęty: powrót do punktu 3 z komunikatem, że wybrany termin jest zajęty. 4b) Ilość wizyt ustalonych przez danego pacjenta przekracza wcześniej ustalony limit: 4b.1) Wyświetlenie komunikatu o potrzebie potwierdzenia danej wizyty przez pracownika rejestracji 4b.2) Dodanie terminu do listy oczekujących 4b.3) Termin zostaje aktywowany przez pracownika rejestracji 4b.4) Przejdz do punktu 5. 4b.3a) Pracownik rejestracji odrzuca podany termin: zakończenie procesu dodawania wizyty niepowodzeniem. Trigger Pacjent osobiście, lub telefonicznie prosi pracownika rejestracji o ustalenie terminu wizyty. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 17 z 93

Nazwa Opis Standardowy przepływ Alternatywny przepływ Anulowanie wizyty (serwis WWW) Procedura anulowania wizyty przez pacjenta z serwisu WWW 1) Z wyświetlonej listy pacjent wybierawizytę do anulowania. 2) Pacjent wpisuje powód anulowania wizyty. 3) Pacjent klika wyślij. 4) Wizyta zostaje usunięta z bazy. 5) Pojawia się komunikat o poprawnym anulowaniu wizyty. 3a) Pacjent rezygnuje z anulowania wizyty: zakończenie z komunikatem o pomyślnym przerwaniu procesu. 3b) Nie podano powodu anulowania: powrót do punktu 2 z komunikatem o braku powodu anulacji. 3c) Nie wybrano wizyty do anulowania: powrót do punktu 1 z komunikatem o braku wybranej wizyty. 4a) Wizyta została dodana dłużej niż 2 godziny temu: 4a.1) Wyświetlenie komunikatu o potrzebie zatwierdzenia anulacji pracownika rejestracji. 4a.2) Dodanie zlecenia do listy oczekujących. 4a.3) Zatwierdzenie usunięcia przez pracownika rejestracji. 4a.4) Przejście do punktu 4. 4a.3a) Pracownik nie zezwolił na anulowanie wizyty: wyświetlenie komunikatu o przerwaniu zatwierdzania i usunięcie zlecenia z listy oczekujących. przez Trigger Nazwa Opis Standardowy przepływ Alternatywny przepływ Pacjent klika opcję Anuluj wizytę Anulowanie wizyty (osobiście, lub telefonicznie) Procedura anulowania wizyty przez pracownika rejestracji. 1) Z wyświetlonej listy pracownik wybiera pacjenta. 2) Z wyświetlonej listy ustalonych wizyt danego pacjenta pracownik wybiera wizytę do anulowania. 3) Pracownik klika Zatwierdź. 4) Wizyta zostaje usunięta z bazy. 5) Pojawia się komunikat o poprawnym anulowaniu wizyty. 3a) Pracownik rezygnuje z anulowania wizyty: zakończenie z komunikatem o pomyślnym przerwaniu procesu. 3b) Nie wybrano wizyty do anulowania: powrót do punktu 1 z komunikatem o braku wybranej wizyty. Trigger Pacjent prosi pracownika rejestracji o usunięcie wizyty i podaje akceptowalny powód. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 18 z 93

Nazwa Opis Standardowy przepływ Alternatywny przepływ Przesunięcie wizyty (osobiście, lub telefonicznie) Procedura przesunięcia wizyty przez pracownika rejestracji. 1) Z wyświetlonej listy pracownik wybiera pacjenta. 2) Z wyświetlonej listy ustalonych wizyt danego pacjenta pracownik wybiera wizytę do przesunięcia. 3) Pracownik klika Dalej. 4) Na podstawie danych z punktu 2 zostaje wyświetlony grafik dostępnych terminów. 5) Pracownik wybiera ustalony z pacjentem termin, lub zaznacza opcję wybierz najbliższy wolny. 6) Pracownik klika Zatwierdź. 7) Wizyta zostaje przesunięta. 8) Pojawia się komunikat o poprawnym przesunięciu wizyty. 3b) Nie wybrano wizyty do przesunięcia: powrót do punktu 2 z komunikatem o braku wybranej wizyty. 6a) Pracownik rezygnuje z przesunięcia wizyty: zakończenie z komunikatem o pomyślnym przerwaniu procesu. 6b) Wybrany termin jest już zajęty: powrót do punktu 5 z komunikatem, że wybrany termin jest zajęty. Trigger Pacjent prosi pracownika rejestracji o przesunięcie wizyty. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 19 z 93

Nazwa Opis Standardowy przepływ Alternatywny przepływ Przesunięcie wizyty (serwis WWW) Procedura przesuwania wizyty przez pacjenta z serwisu WWW 1) Z wyświetlonej listy pacjent wybiera wizytę do przesunięcia. 2) Pacjent wpisuje powód przesunięcia wizyty. 3) Pacjent klika dalej. 4) Na podstawie danych z punktu 1 zostaje wyświetlony grafik dostępnych terminów wizyt. 5) Pacjent wybiera interesujący go termin, lub zaznacza opcję wybierz najbliższy dostępny. 6) Pacjent zatwierdza wybór. 7) Wizyta zostaje przesunięta. 8) Pojawia się komunikat o poprawnym przesunięciu wizyty. 3a) Pacjent rezygnuje z przesunięcia wizyty: zakończenie z komunikatem o pomyślnym przerwaniu procesu. 3b) Nie podano powodu przesunięcia: powrót do punktu 2 z komunikatem o braku powodu przesunięcia. 3c) Nie wybrano wizyty do przesunięcia: powrót do punktu 1 z komunikatem o braku wybranej wizyty. 6a) Wizyta została dodana dłużej niż 2 godziny temu: 6a.1) Wyświetlenie komunikatu o potrzebie zatwierdzenia przesunięcia przez pracownika rejestracji. 6a.2) Dodanie zlecenia do listy oczekujących. 6a.3) Zatwierdzenie przesunięcia przez pracownika rejestracji. 6a.4) Przejście do punktu 4. 6a.3a) Pracownik nie zezwolił na przesunięcie wizyty: wyświetlenie komunikatu o przerwaniu zatwierdzania i usunięcie zlecenia z listy oczekujących. 6a) Wybrany termin jest już zajęty: powrót do punktu 5 z komunikatem, że wybrany termin jest zajęty. Trigger Pacjent klika opcję Przesuń wizytę Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 20 z 93

Nazwa Opis Standardowy przepływ Alternatywny przepływ Trigger Dodawanie wpisu do historii choroby pacjenta. Procedura dodawania nowego wpisu do historii choroby pacjenta. 1) Pojawia się formularz opisu objawów, diagnozy, zaleceń i przepisanych leków. 2) Lekarz wypełnia wybrane pola. 3) Lekarz klika Zatwierdź wpis. 4) System dodaje wpis do bazy danych razem z automatycznie wygenerowaną datą dodania. 5) Pojawia się komunikat o pomyślnym dodaniu wpisu. 3a) Nie zostały wypełnione żadne pola: powrót do punktu 2 z komunikatem, że wszystkie pola są puste. Lekarz klika opcję Dodaj wpis w zakładce historii choroby pacjenta. Nazwa Opis Standardowy przepływ Alternatywny przepływ Trigger Pobieranie wyników badań z laboratorium (elektronicznie) Procedura pobierania wyników badań z laboratorium przez system. 1) W logach systemu zostaje oznaczony moment rozpoczęcia pobierania wyników badań z laboratoriów. 2) System wybiera nieoznaczony serwer laboratorium z listy serwerów i nawiązuje z nim połączenie. 3) System wybiera pacjenta z listy pacjentów oczekujących na wyniki badań. 4) System przesyła dane pacjenta do serwera laboratorium. 5) Serwer laboratorium przesyła wyniki badań systemowi. 6) Odebrane wyniki zostają dołączone do historii choroby pacjenta. 7) Jeżeli istnieje nieoznaczony serwer laboratorium to system przechodzi do punktu 1. 8) W logach systemu zostaje zapisana informacja o zakończeniu pobierania wyników z laboratoriów. 1a) Nie udało się nawiązać połączenia z serwerem: 1a.1) W logach systemu zostaje zapisana informacja o błędzie łączenia z laboratorium. 1a.2) Serwer zostaje oznaczony jak sprawdzony. 1a.3) System przechodzi do punktu 1. Mija 6 godzin od ostatniego pobrania wyników z laboratoriów. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 21 z 93

Nazwa Opis Standardowy przepływ Alternatywny przepływ Dodanie wyników badań z laboratorium (osobiście) Procedura dodawania wyników badań z laboratorium przez pracownika rejestracji. 1) Pracownik wybiera opcję dodaj wyniki badań w menu systemu. 2) Pracownik wpisuje dane pacjenta w formularzu. 3) Pracownik klika opcję Szukaj 4) Na podstawie podanych danych zostaje wygenerowana lista pacjentów spełniających kryteria. 5) Pracownik wybiera odpowiedniego pacjenta z listy. 6) Pracownik klika Dodaj wyniki. 7) Pojawia się lista, z której pracownik wybiera odpowiedni typ badań. 8) Pojawia się formularz dla danego typu badań, gdzie pracownik wpisuje wyniki. 9) Pracownik klika Dalej. 10) Wyniki zostają dodane do historii choroby pacjenta. 5a) Szukanego pacjenta nie ma na liście: 5a.1) Pracownik wprowadza nowe dane pacjenta. 5a.2) Pracownik klika Szukaj ponownie. 5a.3) Przejdź do punktu 3. 7a) Pracownik anuluje wprowadzanie wyników badań: okno dodawania wyników zostaje zamknięte. 9a) Wprowadzone dane nie są poprawne: 9a.1) Pojawia się komunikat o błędnych danych. 9a.2) Przejdź do punktu 6. 9b) Wprowadzone dane nie są kompletne: 9b.1) Pojawia się komunikat o niekompletnych danych. 9b.2) Przejdź do punktu 6. Trigger Pacjent przekazuje pracownikowi rejestracji wyniki badań z laboratorium. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 22 z 93

Nazwa Opis Standardowy przepływ Alternatywny przepływ Wygenerowanie skierowania na badania. Procedure generowania skierowania na badania. 1) Lekarz wybiera rodzaj badania, lub badań z listy i wpisuje pod nią powód skierowania. 2) Lekarz klika Dalej. 3) Zostaje wyświetlony podgląd wygenerowanego skierowania. 4) Lekarz klika Zatwierdź i drukuj. 5) Zostaje wydrukowane poprawne skierowanie do opieczętowania i podpisania przez lekarza. 6) Informacja o skierowaniu zostaje zapisana w historii choroby pacjenta. 2a) Nie zostały wybrane żadne badania: 2a.1) Wyświetl komunikat o braku wybranych badań. 2a.2) Idź do punktu 1. 4a) Skierowanie nie odpowiada wymaganiom lekarza: 4a.1) Lekarz klika Wróc do edycji. 4a.2) Zamknij okno podglądu wydruku. 4a.3) Idź do punktu 1. Trigger Nazwa Opis Standardowy przepływ Alternatywny przepływ Lekarz wybiera opcję Generuj skierowanie na badania. Wygenerowanie skierowania do lekarza specjalisty. Procedure generowania skierowania na badania. 1) Lekarz wybiera rodzaj specjalisty z listy i wpisuje pod nią powód skierowania. 2) Lekarz klika Dalej. 3) Zostaje wyświetlony podgląd wygenerowanego skierowania. 4) Lekarz klika Zatwierdź i drukuj. 5) Zostaje wydrukowane poprawne skierowanie do opieczętowania i podpisania przez lekarza. 6) Informacja o skierowaniu zostaje zapisana w historii choroby pacjenta. 2a) Nie została wybrana specjalizacja: 2a.1) Wyświetl komunikat o braku wybranej specjalizacji. 2a.2) Idź do punktu 1. 4a) Skierowanie nie odpowiada wymaganiom lekarza: 4a.1) Lekarz klika Wróc do edycji. 4a.2) Zamknij okno podglądu wydruku. 4a.3) Idź do punktu 1. Trigger Nazwa Opis Standardowy przepływ Alternatywny przepływ Trigger Lekarz wybiera opcję Generuj skierowanie do specjalisty. Podanie przez pracownika proponowanych godzin pracy Próba zdefiniowania ram czasowych, w których mają mieścić się godziny pracy danego pracownika 8) Pracownik podaje w odpowiednim formularzu możliwe godziny pracy 9) Po wysłaniu propozycji przez pracownika, godziny zostają zapisane w systemie i czekają na decyzję zarządu. 1a) Podane godziny pracy są niepoprawne: wyświetla się komunikat i następuje powrót do punktu 1 Pracownik wybiera opcję Zaproponuj godziny pracy Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 23 z 93

Nazwa Opis Standardowy przepływ Alternatywny przepływ Weryfikacja terminarza dyżurów przez zarząd przychodni Wgląd, a następnie akceptacja lub odrzucenie terminarza dyżurów przez pracownika działu kadr, przejrzenie ewentualnych propozycji 1) Osoba zarządzająca zasobami sprawdza proponowany terminarz 2) Osoba zarządzająca zasobami podaje datę, od której nowy terminarz będzie obowiązywał 3) Osoba zarządzająca zasobami zatwierdza nowy terminarz 4) Nowy terminarz zostaje zapisany, a informacja o nim rozesłana do wszystkich pracowników, których zmiana dotyczy. 1a) Proponowany terminarz jest nieakceptowany przez sprawdzającego: 1a.1) Sprawdzający wybiera inną opcję proponowaną przez system 1a.2) Przejście do punktu 2 1a.1a) Żaden z proponowanych terminarzy nie jest odpowiedni: 1a.1a.1) Sprawdzający wybiera opcję ułożenia terminarza ręcznie 1a.1a.2) Po wprowadzeniu proponowanego terminarza następuje sprawdzenie jego poprawności 1a.1a.3) Przejście do punktu 2 1a.1a.2a) Proponowany terminarz nie jest poprawny: 1a.1a.2a.1) Pojawia się komunikat odnośnie błędów w proponowanym terminarzu 1a.1a.2a.2) Powrót do punktu 1a1a2 2a) Podana data jest błędna 2a.1) Wyświetla się komunikat o błędnej dacie 2a.2) Powrót do punktu 2 Trigger Nazwa Opis Standardowy przepływ Alternatywny przepływ Pracownik działu kadr wybiera opcję Edytuj terminarz dyżurów Utwórz zestawienie dyżurów Wyświetlenie, wydruk lub zapis do pliku grafiku dyżurów 1) Osoba zarządzająca zasobami wybiera z menu, czego dotyczy zestawienie 2) Osoba zarządzająca zasobami wybiera z listy rodzaj zestawienia (graficzne, tekstowe) 3) Osoba zarządzająca zasobami decyduje o formacie i miejscu zapisania pliku, w którym zapisuje powstałe zestawienie 4) Plik zostaje zapisany 5) Osoba zarządzająca zasobami drukuje grafik, ustawiając ewentualnie opcje wydruku 6) Grafik zostaje wydrukowany 3a) Tworzący zestawienie może anulować zapisanie pliku: przejście do punktu 5 4a) Tworzący grafik podał niepoprawne opcje (np. nieprawidłową nazwę pliku) 4a) 1) Pokazuje się komunikat o błędnych parametrach pliku 4a) 2) Powrót do punktu 3 5a) Tworzący zestawienie może anulować drukowanie: procedura się kończy Trigger Pracownik działu kadr wybiera opcję Utwórz zestawienie dyżurów Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 24 z 93

Nazwa Opis Standardowy przepływ Alternatywny przepływ Powiadomienie o wizycie (SMS) Procedura powiadamiania o wizycie przez SMS. 1) Zapisz w logach systemu moment rozpoczęcia przesyłania powiadomień SMS. 2) Wybierz kolejną wizytę z listy. 3) Jeżeli pacjent zażyczył sobie wysyłanie powiadomień poprzez SMS i do wizyty pozostało nie więcej niż 24 godziny to przejdź do punktu 4, jeżeli nie to przejdź do punktu 6. 4) Wygeneruj treść wiadomości na podstawie standardowego szablonu. 5) Prześlij wiadomość pod numer telefonu pobrany z danych pacjenta. 6) Oznacz daną wizytę jako powiadomioną. 7) Jeżeli istnieją następne wizyty przejdź do punktu 2. 8) Zapisz w logach moment zakończenia przesyłania powiadomień SMS. 4a) Nie istnieje szablon wiadomości SMS: 4a.1) Zapisz w logach systemu brak szablonu wiadomości. 4a.2) Przejdź do punktu 8. 5a) Przesyłanie wiadomości nie powiodło się. 5a.1) Zapisz w logach błąd przesyłania wiadomości razem z identyfikatorem wizyty. 5a.2) Przejdź do punktu 6. Trigger Mija godzina od ostatniego wysyłania powiadomień SMS i jest pomiędzy godziną 8 a 20. Nazwa Opis Standardowy przepływ Alternatywny przepływ Trigger Powiadomienie o wizycie (e-mail) Procedura powiadamiania o wizycie przez e-mail. 1) Zapisz w logach systemu moment rozpoczęcia przesyłania powiadomień e-mail. 2) Wybierz kolejną wizytę z listy. 3) Jeżeli pacjent zażyczył sobie wysyłanie powiadomień poprzez e-mail i do wizyty pozostało nie więcej niż 24 godziny to przejdź do punktu 4, jeżeli nie to przejdź do punktu 6. 4) Wygeneruj treść wiadomości na podstawie standardowego szablonu. 5) Prześlij wiadomość pod numer telefonu pobrany z danych pacjenta. 6) Oznacz daną wizytę jako powiadomioną. 7) Jeżeli istnieją następne wizyty przejdź do punktu 2. 8) Zapisz w logach moment zakończenia przesyłania powiadomień e-mail. 4a) Nie istnieje szablon wiadomości e-mail: 4a.1) Zapisz w logach systemu brak szablonu wiadomości. 4a.2) Przejdź do punktu 8. 5a) Przesyłanie wiadomości nie powiodło się. 5a.1) Zapisz w logach błąd przesyłania wiadomości razem z identyfikatorem wizyty. 5a.2) Przejdź do punktu 6. Mija godzina od ostatniego wysyłania powiadomień e-mail. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 25 z 93

3 Analiza funkcjonalna systemu diagramy DFD 3.1 Diagram Kontekstowy: Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 26 z 93

3.2 DFD 1 Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 27 z 93

3.2.1 DFD 1.2 Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 28 z 93

3.2.1.1 DFD 1.2.1 Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 29 z 93

3.3 DFD 1.3 Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 30 z 93

3.4 DFD 1.4 Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 31 z 93

3.5 DFD 1.5 Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 32 z 93

3.5.1 DFD 1.5.1 Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 33 z 93

4 Roboczy słownik danych Nazwa dane osobowe (do rejestracji) dane do rejestracji pacjenta zlecenie aktywacji konta utworzenie lub modyfikacja wizyty żądanie ustalenia lub modyfikacji wizyty lista wolnych terminów; dostępne terminy zapytanie o dostępne terminy powiadomienie o wizycie wydruk skierowania (na badania lub do specjalisty) Skąd pochodzi DFD0 DFD1 DFD1 DFD0 DFD1 DFD0 DFD1 DFD1 DFD0 DFD1 DFD0 DFD1 Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 34 z 93 Opis pacjent dostarcza za pośrednictwem Internetu potrzebne dane (zał. 3) celem dokonania elektronicznej rejestracji dane potrzebne do dokonania rejestracji (zał. 3) podane przez pacjenta w serwisie WWW (jak powyżej), który przekazuje je do rejestracji albo wprowadzone bezpośrednio do rejestracji przez pracownika rejestracji potwierdzenie przez pracownika rejestracji utworzenia kartoteki dla pacjenta, który dokonał elektronicznej rejestracji przesłanie drogą internetową przez pacjenta danych celem ustalenia, przesunięcia lub anulowania terminu wizyty lekarskiej wysłane przez pacjenta żądanie zapisania nowego lub zmiany albo usunięcia istniejącego terminu wizyty zbiór wszystkich możliwych wolnych terminów wizyty spełniających podane kryteria wysyłane w celu otrzymania listy wolnych terminów; zawiera ewentualne kryteria dotyczące terminu (np. wybranych lekarzy, ograniczenia czasowe) informacje o wizycie lekarskiej wysyłane pacjentowi z odpowiednim wyprzedzeniem wybraną drogą celem przypomnienia wydruk dokumentu dla pacjenta, generowanego na żądanie lekarza na podstawie danych przez niego (zał. 1 i 2) podanych skierowanie DFD1 informacja o rodzaju i zależne od niej dane wprowadzane przez lekarza celem wygenerowania i wydrukowania (zał. 1 i 2) skierowania dla pacjenta ustalenie wizyty DFD0 dane dotyczące terminu nowej lub istniejącej wizyty lekarskiej w wypadku, gdy podaje je pracownik rejestracji zapytanie o wyniki badań DFD0 DFD1 wysłana do systemu obsługującego laboratorium prośba o podanie wyników badań dla danych pacjentów wyniki badań DFD0 DFD1 wyniki badań laboratoryjnych pacjenta(ów) przysłane przez system obsługujący laboratorium wprowadzenie wyników z zewnętrznego laboratorium DFD1 wyniki badań laboratoryjnych wprowadzone przez pracownika na podstawie dokumentu przyniesionego przez pacjenta historia choroby DFD0 DFD1 informacje o przebiegu leczenia pacjenta, muszą być dostępne dla lekarza nowy wpis (w historii choroby) DFD0 DFD1 dane o przebiegu wizyty i leczeniu pacjenta, wprowadzane każdorazowo przez lekarza grafik pracy; DFD0 zestawienie miejsca i godzin pracy lekarzy i

grafik dyżurów pracowników dane do modyfikacji własnego grafiku pracy modyfikacje (grafiku pracy) zatwierdzenie lub odrzucenie zmian (w grafiku pracy) DFD1 pracowników rejestracji, używany w systemie do ustalania terminów wizyt; tworzony przez dział kadr DFD1 dane o zmianie godzin lub pomieszczenia pracy, podawane przez lekarza lub pracownika rejestracji, przekazywane przez system w postaci propozycji zmian do działu kadr DFD1.4 proponowane przez system nowe grafiki dyżurów pracowników, utworzone na podstawie danych wysłanych przez lekarzy i pracowników rejestracji, wysyłane do akceptacji do działu kadr DFD0 akceptacja lub odrzucenie proponowanych przez system DFD1 modyfikacji grafiku pracy (patrz powyżej) przez pracownika działu kadr Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 35 z 93

Pacjenci Lekarze Dyzury Specjalizacje_lekarza Specjalizacje Wizyty Przeprowadzone_zabiegi Propozycje zmian Odbyte_badania Choroby Zabiegi Historia_choroby Badania Zlecone_badania Diagnozy Zlecone_zabiegi Skierowania Przepisane_leki Leki Gunia, Magura-Witkowska, Jastrzębski, Zagórska 5 Analiza struktur danych przechowywanych w systemie 5.1 Tabela krzyżowa Pacjenci X X Lekarze X X X X Dyzury X Specjalizacje_lekarza Specjalizacje X X Wizyty X X X X Przeprowadzone_zabiegi Propozycje zmian X Odbyte_badania Choroby X Zabiegi X X Historia_choroby X Badania X X Zlecone_badania Diagnozy X X X X Zlecone_zabiegi Skierowania Przepisane_leki Leki X Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 36 z 93

5.2 Tabela relacji między obiektami Nr Relacja Tabele Krotność 1 zrobił Pacjenci Odbyte badania 1 0..N 2 odbył Pacjenci Wizyty 1 0..N 3 jest lekarzem Lekarze Pacjenci 1 0..N 4 ma zaplanowany Lekarze Dyzury 1 0..N 5 posiada Lekarze Specjalizacje lekarza 1 1..N 6 przeprowadził Lekarze Wizyty 1 0..N 7 jest typu Specjalizacje Specjalizacje lekarza 1 0..N 8 jest do Specjalizacje Skierowania 1 0..N 9 przeprowadzono podczas Wizyty Przeprowadzone zabiegi 1 0..N 10 stwierdzono podczas Wizyty Diagnozy 1 0..N 11 dotyczy Propozycje zmian Dyzury 0..1 1 12 stwierdzono Choroby Historia choroby 1 0..N 13 jest typu Zabiegi Przeprowadzone zabiegi 1 0..N 14 jest typu Zabiegi Zlecone zabiegi 1 0..N 15 dotyczy Historia choroby Diagnozy 1 0..N 16 jest typu Badania Odbyte badania 1 0..N 17 jest typu Badania Zlecone badania 1 0..N 18 dotyczy Diagnozy Zlecone badania 1 0..N 19 dotyczy Diagnozy Zlecone zabiegi 1 0..N 20 dotyczy Diagnozy Skierowania 1 0..N 21 dotyczy Diagnozy Przepisane leki 1 0..N 22 jest typu Leki Przepisane leki 1 0..N Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 37 z 93

5.3 Opis struktur danych 5.3.1 Pacjenci zawiera dane osobowe pacjenta, oraz jego dane kontaktowe, wykorzystywane np. w module powiadomień o wizytach. Pacjenci Nazwa pola typ pola wymagane idpacjenta CHAR x haslo CHAR x numer_karty INT x email VARCHAR imiona VARCHAR x nazwisko VARCHAR x imie_ojca VARCHAR x imie_matki VARCHAR x data_urodzenia DATE x miejsce_urodzenia VARCHAR x pesel INT plec VARCHAR x miasto VARCHAR x ulica VARCHAR x numer INT x telefon VARCHAR idlekarza VARCHAR 5.3.2 Lekarze zawiera dane osobowe lekarzy zatrudnionych w placówce. Lekarze Nazwa pola typ pola wymagane idlekarza CHAR x haslo CHAR x imiona VARCHAR x nazwisko VARCHAR x nip CHAR x miasto VARCHAR x ulica VARCHAR x numer INT x telefon VARCHAR x data_zatrudnienia DATE x 5.3.3 Dyżury przechowuje informacje o dyżurach, czyli jakiego lekarza dany dyżur dotyczy, oraz datę i czas tego dyżuru. Dyzury Nazwa pola typ pola wymagane iddyzury INT x idlekarza CHAR x data DATE x godzina_rozpoczecia TIME x godzina_zakonczenia TIME x Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 38 z 93

5.3.4 Propozycja zmian propozycje zmian w grafiku lekarzy. Umożliwiają one zaproponowanie przeniesienia danego dyżuru na inny termin. Propozycja_zmiany Nazwa pola typ pola wymagane idpropozycja_zmiany INT x iddyzury INT x data DATE x godzina_rozpoczecia TIME x 5.3.5 Specjalizacje lekarza zawiera informacje o specjalizacjach danego lekarza Specjalizacje_lekarza Nazwa pola typ pola wymagane idlekarza CHAR x idspecjalizacji INT x 5.3.6 Specjalizacje tabela słownikowa, przechowuje możliwe specjalizacje Specjalizacje Nazwa pola typ pola wymagane idspecjalizacji INT x nazwa VARCHAR x 5.3.7 Wizyty zawiera podstawowe informacje o wizytach pacjentów w placówce. Wizyty Nazwa pola typ pola wymagane idwizyty INT x data DATE x idpacjenta CHAR x idlekarza CHAR x 5.3.8 Przeprowadzone zabiegi łączy informacje o przeprowadzonym zabiegu z informacją o wizycie na której został on przeprowadzony. Przeprowadzone_zabiegi Nazwa pola typ pola wymagane idprzeprowadzone_zabiegiint x idwizyty INT x idzabiegu INT x uwagi TEXT x 5.3.9 Choroby zawiera informacje chorobach możliwych do zdiagnozowania. Choroby Nazwa pola typ pola wymagane idchoroby INT x nazwa VARCHAR x Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 39 z 93

5.3.10 Historia choroby tabela pozwala zidentyfikować chorobę danego pacjenta, oraz powiązać ją z podjętymi działaniami, badaniami oraz zabiegami jakie zlecono w związku z daną choroba. Historia_chorob Nazwa pola typ pola wymagane idhistoria_chorob INT x idchoroby INT x 5.3.11 Odbyte badania zawiera informacje o badaniach które przeszedł dany pacjent, łącznie z data danego badania oraz jego wynikami, jeśli już są one dostępne. Odbyte_badania Nazwa pola typ pola wymagane idbadania INT x idpacjenta CHAR x data DATE x wyniki TEXT 5.3.12 Badania tabela grupuje badania które mogą być zlecone przez lekarzy. Badania Nazwa pola typ pola wymagane idbadania INT x nazwa VARCHAR x 5.3.13 Zlecone badania tabela łączy zlecone badanie, z diagnozą w związku z którą zostało ono zlecone. Zlecone_badania Nazwa pola typ pola wymagane idbadania INT x iddiagnozy INT x 5.3.14 Diagnozy zawiera informacje o diagnozie, którą postawiono na danej wizycie. Jeśli na kilku kolejnych wizytach stwierdzono tą samą chorobę, to powstanie kilka rekordów w tej tabeli, lecz będą się odnosiły do tego samego rekordu z tabeli Historia_choroby. Diagnozy Nazwa pola typ pola wymagane iddiagnozy INT x idwizyty INT x idpacjenta VARCHAR x idlekarza VARCHAR x uwagi TEXT idhistoria_chorob INT x Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 40 z 93

5.3.15 Zlecone zabiegi łączy zlecone zabiegi z diagnozą, w związku z którą zostały one zlecone. Zlecone_zabiegi Nazwa pola typ pola wymagane idzabiegu INT x iddiagnozy INT x 5.3.16 Skierowania zawiera informacje o skierowaniach do specjalistów, wystawionych w związku z konkretną diagnozą Skierowania Nazwa pola typ pola wymagane idskierowania INT x iddiagnozy INT x idspecjalizacji INT x 5.3.17 Przepisane leki zawiera informacje o przepisanych lekach i przypisuje je konkretnym diagnozą, ze względu na które zostały one przepisane. Tabela zawiera także informacje o zaleconym dawkowaniu, oraz dodatkowe uwagi. Przepisane_leki Nazwa pola typ pola wymagane iddiagnozy INT x idleku INT x dawkowanie TEXT x uwagi TEXT x 5.3.18 Leki tabela słownikowa, grupująca wszystkie leki. W tym przypadku idleku to numer dopuszczenia do obiegu, które powinien posiadać każdy lek. Leki Nazwa pola typ pola wymagane idleku INT x nazwa VARCHAR x opis TEXT x Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 41 z 93

5.4 Pełny diagram relacji Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 42 z 93

6 Obraz zachowania systemu w czasie 6.1 Diagramy STD 6.1.1 Diagram STD ogólny Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 43 z 93

6.1.2 Diagram STD osoba odpowiedzialna za rejestrację (dyspozytor) 6.1.2.1 Diagram STD ogólny Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 44 z 93

6.1.2.2 Diagram STD związany z obsługą terminarza wizyt pacjentów Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 45 z 93

6.1.3 Diagram STD lekarz Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 46 z 93

6.1.4 Diagram STD pacjent (serwis WWW) Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 47 z 93

6.2 Diagramy Entity Life History (ELH) 6.2.1 Diagram ELH związany z pacjentem 6.2.2 Diagram ELH związany ze skierowaniami Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 48 z 93

6.2.3 Diagram ELH związany z dyżurami 6.2.4 Diagram ELH związany z wizytami 6.2.5 Diagram ELH związany z badaniami Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 49 z 93

7 Uzupełnienie wymagań funkcjonalnych i niefunkcjonalnych 7.1 Wymagania funkcjonalne dla każdej ze zdefiniowanych funkcji systemu 1. Rejestracja i pacjenci 1. Dostępność terminów (WWW) Wyświetlenie listy dostępnych terminów do danego lekarza. Dane wejściowe: Identyfikator lekarza w systemie, data Źródła danych wejściowych: pacjent, baza pracowników Wyniki: Zwrócenie listy wolnych terminów u danego lekarza jak najbliższych podanej dacie. Warunek wstępny: Pacjent jest zalogowany w systemie. Warunek końcowy: Dany lekarz istnieje w systemie. Powód: w celu ustalenia nowej wizyty pacjent musi dostać listę dostępnych terminów. 2. Anulowanie wizyty Anulowanie wcześniej ustalonej wizyty przez pracownika rejestracji. Dane wejściowe: Identyfikator wizyty w systemie. Źródła danych wejściowych: pracownik rejestracji, baza terminów. Wyniki: Usunięcie wizyty z bazy terminów. Warunek wstępny: Pracownik rejestracji jest zalogowany Warunek końcowy: Dana wizyta istnieje w systemie. Powód: Czasem z powodów losowych pacjent może chcieć anulować umówioną wizytę. 3. Anulowanie wizyty (WWW) Anulowanie wcześniej ustalonej wizyty. Dane wejściowe: Identyfikator wizyty w systemie, identyfikator pacjenta. Źródła danych wejściowych: pacjent, baza terminów. Wyniki: Usunięcie wizyty z bazy terminów. Warunek wstępny: Pacjent jest zalogowany w systemie. Warunek końcowy: Dana wizyta istnieje w systemie. Powód: Czasem z powodów losowych pacjent może chcieć anulować umówioną wizytę. 4. Modyfikacja terminu wizyty (WWW) Wykonanie przesunięcia terminu wcześniej ustalonej wizyty. Dane wejściowe: Identyfikator wizyty w systemie, identyfikator pacjenta, proponowana data Źródła danych wejściowych: pacjent, baza terminów. Wyniki: Przesunięcie wizyty na wybrany przez pacjenta termin. Warunek wstępny: Pacjent jest zalogowany w systemie. Warunek końcowy: Dana wizyta istnieje w systemie. Powód: Czasem z powodów losowych pacjent może mieć potrzebę zmiany terminu ustalonej wizyty. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 50 z 93

5. Modyfikacja terminu wizyty Wykonanie przesunięcia terminu wcześniej ustalonej wizyty przez pracownika rejestracji. Dane wejściowe: Identyfikator wizyty w systemie, proponowana data Źródła danych wejściowych: pracownik rejestracji, baza terminów. Wyniki: Przesunięcie wizyty na wybrany przez pacjenta termin. Warunek wstępny: Pracownik rejestracji jest zalogowany Warunek końcowy: Dana wizyta istnieje w systemie. Powód: Czasem z powodów losowych pacjent może mieć potrzebę zmiany terminu ustalonej wizyty. 6. Modyfikacja danych osobowych (WWW) Zmiana danych osobowych pacjenta. Dane wejściowe: Dane pacjenta. Źródła danych wejściowych: Pacjent. Wyniki: Wprowadzenie zlecenia modyfikacji do bazy pacjentów. Warunek wstępny: Pacjent jest zalogowany w systemie. Warunek końcowy: Podane dane są poprawne i kompletne. Powód: W wielu przypadkach dane pacjenta mogły ulec zmianie jak chociażby np. podczas przeprowadzki, przy zgubieniu dowodu itp. 7. Modyfikacja danych osobowych Zmiana danych osobowych pacjenta przez pracownika rejestracji. Dane wejściowe: Dane pacjenta. Źródła danych wejściowych: Pracownik rejestracji. Wyniki: Modyfikacja danych pacjenta w bazie. Warunek wstępny: Pracownik rejestracji jest zalogowany w systemie Warunek końcowy: Podane dane są poprawne i kompletne. Powód: W wielu przypadkach dane pacjenta mogły ulec zmianie jak chociażby np. podczas przeprowadzki, przy zgubieniu dowodu itp. 8. Rejestracja nowego pacjenta (WWW) Utworzenie konta dla nowego pacjenta i nadanie mu unikalnego identyfikatora w systemie. Dane wejściowe: Dane osobowe osoby chcącej się zarejestrować. Źródła danych wejściowych: Formularz na stronie WWW. Wyniki: Wprowadzenie zlecenia dodania do bazy pacjentów nowej osoby. Warunek wstępny: Rejestracja nie jest wyłączona. Warunek końcowy: Wprowadzone dane osobowe są poprawne. Powód: Jeżeli pacjent chce rozpocząć swój kontakt z systemem musi się najpierw zarejestrować. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 51 z 93

9. Rejestracja nowego pacjenta Utworzenie konta dla nowego pacjenta i nadanie mu unikalnego identyfikatora w systemie przez pracownika rejestracji. Dane wejściowe: Dane osobowe osoby chcącej się zarejestrować. Źródła danych wejściowych: Formularz w interfejsie systemu. Wyniki: Dodanie do bazy pacjentów nowej osoby. Warunek wstępny: Rejestracja nie jest wyłączona. Warunek końcowy: Wprowadzone dane osobowe są poprawne. Powód: Jeżeli pacjent chce rozpocząć swój kontakt z systemem musi się najpierw zarejestrować. 10. Powiadomienie o wizycie (Dostępne tylko dla pacjentów) Wysłanie powiadomienia o nadchodzącym terminie wizyty. Dane wejściowe: Data i cel umówionej wizyty. Źródła danych wejściowych: Baza wizyt. Wyniki: Przesłanie powiadomienia o nadchodzącym terminie wizyty do pacjenta wybranym przez niego kanałem (SMS, E-Mail) Warunek wstępny: Pacjent wybrał opcję powiadamiania o wizycie. Warunek końcowy: Istnieją nadchodzące wizyty w ustalonym przez pacjenta czasie. Powód: Pacjent powinien mieć możliwość otrzymywania automatycznego powiadomienia o nadchodzącej wizycie. 11. Zatwierdzenie rejestracji pacjenta (Dostępne tylko dla personelu) Aktywowanie utworzonego wcześniej kotna przez pracownika rejestracji. Dane wejściowe: Identyfikator pacjenta do aktywacji w systemie. Źródła danych wejściowych: pracownik rejestracji. Wyniki: Aktywowanie obecnego już w bazie konta. Warunek wstępny: Konto istnieje w bazie pacjentów, pracownik rejestracji jest zalogowany. Warunek końcowy: Pacjent przedstawił ważny dowód tożsamości. Powód: Jeżeli pacjent chce rozpocząć swój kontakt z systemem musi się najpierw zarejestrować, a jego konto musi zostać aktywowane w celu uniknięcia oszustów. 2. Leczenie 1. Wpis do historii choroby Dopisanie nowych danych do historii choroby pacjenta. Dane wejściowe: Identyfikator pacjenta, dane do wprowadzenia, identyfikator lekarza. Źródła danych wejściowych: lekarz Wyniki: Dodanie nowego wpisu do historii choroby zgodnie z danymi podanymi przez lekarza. Warunek wstępny: Lekarz jest zalogowany, został wybrany pacjent dla którego dodawany zostaje wpis do historii choroby. Warunek końcowy: Podane dane są kompletne. Powód: Nawet w wypadku infantylnych wizyt obowiązkiem lekarza jest zapisać swoje obserwacje w karcie historii choroby pacjenta. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 52 z 93

2. Wydruk skierowania Dopisanie skierowania do historii choroby i wydrukowanie jego papierowej wersji dla pacjenta. Dane wejściowe: Dane do skierowania. Źródła danych wejściowych: lekarz Wyniki: Dodanie nowego wpisu do historii choroby zawierającego opis wystawionego skierowania i wydruk wersji papierowej. Warunek wstępny: Został wybrany istniejący pacjent. Warunek końcowy: Podane dane są kompletne. Powód: Każdy fakt wypisania skierowania do lekarza specjalisty, lub laboratorium powinien zostać udokumentowany w historii choroby. 3. Pobranie historii choroby Pobranie z serwera pełnej wersji historii choroby wybranego pacjenta. Dane wejściowe: Identyfikator pacjenta. Źródła danych wejściowych: lekarz Wyniki: Wygenerowanie i wyświetlenie na ekranie komputera lekarza dokumentu zawierającego kompletną historię choroby wybranego pacjenta. Warunek wstępny: Został wybrany istniejący pacjent, lekarz jest zalogowany. Warunek końcowy: Historia choroby pacjenta istnieje. Powód: Nawet w wypadku infantylnych wizyt obowiązkiem lekarza jest zapisać swoje obserwacje w karcie historii choroby pacjenta. 3. Pracownicy 1. Propozycja zmiany terminarza dyżurów. Pobranie z serwera pełnej wersji dyżurów pracowników i próba jej modyfikacji. Dane wejściowe: Identyfikator pracownika chcącego wykonać zmianę, lista zmian. Źródła danych wejściowych: pracownik, lub lekarz Wyniki: Wygenerowanie i wyświetlenie na ekranie komputera grafiku dyżurów pracowników, zapisanie sugestii pracownika do akceptacji przez dział kadr. Warunek wstępny: pracownik jest zalogowany Warunek końcowy: Wybrany pracownik ma prawo modyfikować swój grafik. Powód: Pracownicy powinni mieć, ze względu na dostępność danych w systemie, możliwość zażądania modyfikacji własnego grafiku dyżurów. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 53 z 93

2. Zatwierdzenie zmian w dyżurach. Pobranie z serwera pełnej wersji dyżurów pracowników i zatwierdzenie jej do wprowadzenia w życie. Dane wejściowe: brak Źródła danych wejściowych: brak Wyniki: Po zatwierdzeniu dyżurów zostają one natychmiast wprowadzone do głównej bazy danych. Warunek wstępny: Istnieją dyżury w wybranym terminie. Warunek końcowy: Nowy rozkład dyżurów jest akceptowalny. Powód: Pracownicy powinni mieć, ze względu na dostępność danych w systemie, możliwość zażądania modyfikacji własnego grafiku dyżurów. 4. Administracja 1. Utworzenie kopii zapasowej bazy Utworzenie kopii zapasowej wybranej bazy danych. Dane wejściowe: Nazwa bazy, której kopię należy wykonać, katalog docelowy Źródła danych wejściowych: administrator Wyniki: Wygenerowanie i zapisanie w katalogu docelowym kopii zapasowej wybranej bazy. Warunek wstępny: Wybrana baza istnieje na serwerze. Warunek końcowy: Wybrana lokalizacja posiada wystarczająco dużo miejsca. Powód: Na wypadek awarii powinna istnieć opcja tworzenia kopii zapasowej baz danych używanych w systemie. 2. Przywrócenie kopii zapasowej Przywrócenie kopii zapasowej wybranej bazy danych. Dane wejściowe: Lokalizacja pliku z kopią zapasową, nazwa bazy Źródła danych wejściowych: administrator Wyniki: Przywrócenie zawartej w pliku wersji bazy danych. Warunek wstępny: Baza zawarta w pliku istnieje w innej wersji w systemie. Warunek końcowy: brak Powód: W wypadku awarii powinna istnieć opcja przywrócenia kopii zapasowej baz danych używanych w systemie. 3. Dodanie pracownika Utworzenie nowego konta pracownika w systemie. Dane wejściowe: Dane osobowe pracownika, posada, uprawnienia. Źródła danych wejściowych: administrator Wyniki: Utworzenie identyfikatora i konta dla pracownika o wybranych uprawnieniach. Warunek wstępny: Pracownik nie istnieje jeszcze w systemie. Warunek końcowy: Podane dane są poprawne Powód: Ze względu na zwiększone uprawnienia pracowników przychodni tworzenie ich kont musi przebiegać ręcznie, żeby uniknąć problemów z bezpieczeństwem. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 54 z 93

4. Edycja użytkownika Zmiana danych osobowych, lub posady pracownika. Dane wejściowe: Identyfikator pracownika, nowe dane osobowe/posada Źródła danych wejściowych: administrator Wyniki: Zmiana danych dotyczących wybranego pracownika Warunek wstępny: Wybrany użytkownik istnieje w systemie Warunek końcowy: Podane dane są poprawne. Powód: Pracownik może w każdej chwili zażądać zmiany swoich danych osobowych. 5. Ustawienie uprawnień użytkownika Zmiana praw dostępu pracownika. Dane wejściowe: Identyfikator pracownika, nowe uprawnienia Źródła danych wejściowych: administrator Wyniki: Zmiana uprawnień wybranego pracownika Warunek wstępny: Wybrany użytkownik istnieje w systemie Warunek końcowy: Podane uprawnienia są poprawne. Powód: Każdy pracownik musi mieć przypisane uprawnienia. 6. Usunięcie użytkownika Uniemożliwienie użytkownikowi dostępu do systemu. Dane wejściowe: Identyfikator pracownika Źródła danych wejściowych: administrator Wyniki: Oznaczenie konta pracownika jako nieaktywne. Warunek wstępny: Wybrany użytkownik istnieje w systemie Warunek końcowy: brak Powód: Jeżeli pracownik zostanie zwolniony system musi udostępniać możliwość odcięcia mu możliwości korzystania z systemu bez utraty danych o ni m. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 55 z 93

7.2 Wymagania niefunkcjonalne 1. Bezpieczeństwo System musi zapewniać bezwzględne bezpieczeństwo przechowywanych w nim danych, a w szczególności historii choroby pacjentów. Jest to powiązane z częstym wykonywaniem kopii zapasowych baz danych używanych w systemie i brakiem dostępu do historii choroby dla osób niepowołanych. 2. Współpraca z urządzeniami peryferyjnymi (w szczególności z drukarką) Zadaniem systemu jest między innymi drukowanie skierowań i innych formularzy dla pacjentów dlatego musi on zawierać możliwość wydrukowania każdego dokumentu przechowywanego w bazach danych. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 56 z 93

8 Specyfikacje funkcji (procesów) 1. Rejestracja i pacjenci 1. Dostępność terminów (WWW) Wyświetlenie listy dostępnych terminów do danego lekarza. Procesy wykorzystujące funkcję: 5.1.2 Dane wejściowe: Identyfikator lekarza w systemie, data Warunek wstępny: Pacjent jest zalogowany w systemie. Opis działania: dostepnosc_terminow(id_lekarza, data) { JEŻELI istnieje lekarz o ID=ID_lekarza { DLA KAŻDEGO terminu wizyty lekarza określonego przez ID_lekarza { JEŻELI termin wolny { JEŻELI NIE (podano datę && termin oddalony o więcej niż 12h) { Dodaj termin do zwracanej listy ZWRÓĆ listę terminów INACZEJ { błąd Dane wyjściowe: Lista wolnych terminów u danego lekarza jak najbliższych podanej dacie. Warunek końcowy: Dany lekarz istnieje w systemie. Efekty uboczne: Brak. 2. Anulowanie wizyty Anulowanie wcześniej ustalonej wizyty przez pracownika rejestracji. Procesy wykorzystujące funkcję: 2.1.2, 5.1.1 Dane wejściowe: Identyfikator wizyty w systemie. Warunek wstępny: Pracownik rejestracji jest zalogowany w systemie Opis działania: anulowanie_wizyty(id_wizyty) { JEŻELI istnieje zaplanowana wizyta o ID=ID_wizyty { Usuń wizytę ID_wizyty z bazy wizyt ZWRÓĆ potwierdzenie usunięcia INACZEJ { błąd Dane wyjściowe: informacja o usunięciu wizyty. Warunek końcowy: Dana wizyta istnieje w systemie. Efekty uboczne: Usunięcie wizyty z bazy terminów. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 57 z 93

3. Anulowanie wizyty (WWW) Anulowanie wcześniej ustalonej wizyty. Procesy wykorzystujące funkcję: 5.1.1 Dane wejściowe: Identyfikator wizyty w systemie, identyfikator pacjenta Warunek wstępny: Pacjent jest zalogowany w systemie. Opis działania: anulowanie_wizyty_www(id_wizyty, ID_pacjenta) { JEŻELI wizyta o ID=ID_wizyty należy do pacjenta ID_pacjenta { JEŻELI anulowanie_wizyty(id_wizyty) bezbłędne { ZWRÓĆ potwierdzenie usunięcia INACZEJ { błąd INACZEJ { błąd Dane wyjściowe: informacja o usunięciu wizyty. Warunek końcowy: Dana wizyta istnieje w systemie. Efekty uboczne: Usunięcie wizyty z bazy terminów. 4. Modyfikacja terminu wizyty (WWW) Wykonanie przesunięcia terminu wcześniej ustalonej wizyty. Procesy wykorzystujące funkcję: 5.1.3 Dane wejściowe: Identyfikator wizyty w systemie, identyfikator pacjenta, proponowana data Warunek wstępny: Pacjent jest zalogowany w systemie. Opis działania: modyfikacja_wizyty_www(id_wizyty, ID_pacjenta, nowy_termin) { JEŻELI wizyta o ID=ID_wizyty należy do pacjenta ID_pacjenta { JEŻELI modyfikacja_wizyty(id_wizyty, nowy_termin) bezbłędna { ZWRÓĆ potwierdzenie INACZEJ { błąd INACZEJ { błąd Dane wyjściowe: informacja o przesunięciu wizyty. Warunek końcowy: Dana wizyta istnieje w systemie. Efekty uboczne: Zmiana terminu wizyty na wybrany przez pacjenta. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 58 z 93

5. Modyfikacja terminu wizyty Wykonanie przesunięcia terminu wcześniej ustalonej wizyty przez pracownika rejestracji. Procesy wykorzystujące funkcję: 2.1.2, 5.1.3 Dane wejściowe: Identyfikator wizyty w systemie, proponowana data Warunek wstępny: Pracownik rejestracji jest zalogowany Opis działania: modyfikacja_wizyty(id_wizyty, nowy_termin) { JEŻELI istnieje zaplanowana wizyta o ID=ID_wizyty { JEŻELI nowy_termin jest dostępny { Zmień termin wizyty ID_wizyty na nowy_termin w bazie wizyt ZWRÓĆ potwierdzenie INACZEJ { błąd INACZEJ { błąd Dane wyjściowe: informacja o przesunięciu wizyty. Warunek końcowy: Dana wizyta istnieje w systemie. Efekty uboczne: Zmiana terminu wizyty na wybrany przez pacjenta. 6. Modyfikacja danych osobowych (WWW) Zmiana danych osobowych pacjenta. Procesy wykorzystujące funkcję: 5.2 Dane wejściowe: Dane pacjenta. Warunek wstępny: Pacjent jest zalogowany w systemie. Opis działania: Dla każdego pola danych istnieje funkcja typu modyfikacja_danych_www(id_pacjenta, ktore_pole, nowa_wartosc) { Zapisz żądanie pacjenta w kolejce do akceptacji. ZWRÓĆ potwierdzenie zgłoszenia żądania Dane wyjściowe: potwierdzenie wysłania danych do modyfikacji Warunek końcowy: Podane dane są poprawne i kompletne. Efekty uboczne: Zapisanie zlecenia modyfikacji do bazy pacjentów. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 59 z 93

7. Modyfikacja danych osobowych Zmiana danych osobowych pacjenta przez pracownika rejestracji. Procesy wykorzystujące funkcję: 1.1, 5.2 Dane wejściowe: Dane pacjenta. Warunek wstępny: Pracownik rejestracji jest zalogowany w systemie Opis działania: Dla każdego pola danych istnieje funkcja typu modyfikacja_danych(id_pacjenta, ktore_pole, nowa_wartosc) { JEŻELI istnieje pacjent o ID=ID_pacjenta && ktore_pole poprawnie identyfikuje daną do zmiany { JEŻELI nowa_wartosc jest poprawna wartoscia danej ktore_pole { Nadpisz w bazie pacjentów pacjentowi ID_pacjenta dotychczasową wartość ktore_pole przy pomocy nowa_wartosc. ZWRÓĆ potwierdzenie INACZEJ { błąd INACZEJ { błąd Dane wyjściowe: potwierdzenie modyfikacji Warunek końcowy: Podane dane są poprawne i kompletne. Efekty uboczne: Modyfikacja danych pacjenta w bazie. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 60 z 93

8. Rejestracja nowego pacjenta (WWW) Utworzenie konta dla nowego pacjenta i nadanie mu unikalnego identyfikatora w systemie. Procesy wykorzystujące funkcję: 5.2 Dane wejściowe: Dane osobowe osoby chcącej się zarejestrować. Warunek wstępny: Rejestracja nie jest wyłączona. Opis działania: rejestracja_www(imie, nazwisko, pesel, adres_zam, nr_tel, login_id, e_mail) { JEŻELI istnieje pacjent o loginie login_id { ZWRÓĆ błąd INACZEJ { JEŻELI wszystkie podane dane poprawne { JEŻELI nie podano login_id { POWTARZAJ { login_id := wygeneruj nowy login (imie, nazwisko) AŻ nie ma pacjenta z loginem login_id Dodaj do kolejki do potwierdzenia dane pacjenta{ Imię: imie Nazwisko: nazwisko PESEL: pesel Adres: adres_zam Telefon: nr_tel (opcjonalnie) E-mail: e_mail Login: login_id Wyświetl potwierdzenie elektronicznej rejestracji dla pacjenta { /* dane jak powyżej */ ZWRÓĆ potwierdzenie INACZEJ { ZWRÓĆ błąd Dane wyjściowe: potwierdzenie rejestracji elektronicznej Warunek końcowy: Wprowadzone dane osobowe są poprawne. Efekty uboczne: Wprowadzenie zlecenia dodania do bazy pacjentów nowej osoby. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 61 z 93

9. Rejestracja nowego pacjenta Utworzenie konta dla nowego pacjenta i nadanie mu unikalnego identyfikatora w systemie przez pracownika rejestracji. Procesy wykorzystujące funkcję: 1.1 Dane wejściowe: Dane osobowe osoby chcącej się zarejestrować. Warunek wstępny: Rejestracja nie jest wyłączona. Opis działania: rejestracja(imie, nazwisko, pesel, adres_zam, rodz_dok, nr_dok, nr_tel, login_id, e_mail) { JEŻELI istnieje pacjent o loginie login_id { ZWRÓĆ błąd INACZEJ { JEŻELI wszystkie podane dane poprawne { JEŻELI nie podano login_id { POWTARZAJ { login_id := wygeneruj nowy login (imie, nazwisko) AŻ nie ma pacjenta z loginem login_id tymczasowe_haslo := wygeneruj losowe hasło Dodaj do bazy nowego pacjenta { Imię: imie Nazwisko: nazwisko PESEL: pesel Adres: adres_zam Rodzaj dokumentu tożsamości: rodz_dok Numer dokumentu tożsamości: nr_dok Telefon: nr_tel (opcjonalnie) E-mail: e_mail Login: login_id Hasło: hash(tymczasowe_haslo) Wydrukuj potwierdzenie rejestracji dla pacjenta{ /* dane jak powyżej, z tą różnicą, że hasło podane w sposób jawny */ ZWRÓĆ potwierdzenie INACZEJ { ZWRÓĆ błąd Dane wyjściowe: potwierdzenie rejestracji Warunek końcowy: Wprowadzone dane osobowe są poprawne. Efekty uboczne: Dodanie do bazy pacjentów danych nowej osoby, wydruk potwierdzenia rejestracji. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 62 z 93

10. Powiadomienie o wizycie (Dostępne tylko dla pacjentów) Wysłanie powiadomienia o nadchodzącym terminie wizyty. Procesy wykorzystujące funkcję: 2.2 Dane wejściowe: ID wizyty, ID pacjenta, rodzaj powiadomienia, czas powiadomienia Warunek wstępny: Pacjent wybrał opcję powiadamiania o wizycie i jest zalogowany do systemu. Opis działania: powiadomienie(id_wiz, ID_pac, rodz_powiad, czas_przed) { JEŻELI istnieje pacjent ID_pac i wizyta ID_wiz && wizyta należy do tego pacjenta { JEŻELI rodz_powiad jest poprawnym rodzajem powiadomienia /* SMS, e-mail,... */ && czas_przed ma poprawną wartość { JEŻELI pacjent ID_pac nie ma danych dla powiadomienia rodz_powiad /* np. brak numeru telefonu dla opcji SMS */ { ZWRÓĆ błąd INACZEJ JEŻELI (czas wizyty ID_wiz - czas_przed) jest w przeszłości { ZWRÓĆ błąd INACZEJ { Zapisz powiadomienie w bazie danych do wysłania. ZWRÓĆ potwierdzenie INACZEJ { ZWRÓĆ błąd INACZEJ { ZWRÓĆ błąd Dane wyjściowe: status powiadomienia (zapisane do wysłania lub odpowiedni komunikat błędu) Warunek końcowy: Istnieją nadchodzące wizyty w ustalonym przez pacjenta czasie. Efekty uboczne: Przesłanie powiadomienia o nadchodzącym terminie wizyty do pacjenta wybranym przez niego kanałem (SMS, E-Mail) Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 63 z 93

11. Zatwierdzenie rejestracji pacjenta (Dostępne tylko dla personelu) Aktywowanie utworzonego wcześniej kotna przez pracownika rejestracji. Procesy wykorzystujące funkcję: 1.1 Dane wejściowe: Identyfikator pacjenta do aktywacji w systemie. Warunek wstępny: Konto istnieje w bazie pacjentów, pracownik rejestracji jest zalogowany. Opis działania: akceptacja_www(id_konta_nieaktywnego, rodz_dok, nr_dok) { JEŻELI istnieje nieaktywne konto o ID ID_konta_nieaktywnego{ JEŻELI wszystkie podane dane poprawne { tymczasowe_haslo := wygeneruj losowe hasło Dodaj do bazy nowego pacjenta { Imię: ID_konta_nieaktywnego.imie Nazwisko: ID_konta_nieaktywnego.nazwisko PESEL: ID_konta_nieaktywnego.pesel Adres: ID_konta_nieaktywnego.adres_zam Rodzaj dokumentu tożsamości: rodz_dok Numer dokumentu tożsamości: nr_dok Telefon: ID_konta_nieaktywnego.nr_tel (o.) E-mail: ID_konta_nieaktywnego.e_mail Login: ID_konta_nieaktywnego.login_id Hasło: hash(tymczasowe_haslo) Wydrukuj potwierdzenie rejestracji dla pacjenta{ /* dane jak powyżej, z tą różnicą, że hasło podane w sposób jawny */ ZWRÓĆ potwierdzenie INACZEJ { ZWRÓĆ blad INACZEJ { ZWRÓĆ błąd Dane wyjściowe: potwierdzenie aktywacji konta Warunek końcowy: Pacjent przedstawił ważny dowód tożsamości. Efekty uboczne: Aktywowanie obecnego już w bazie konta, wydruk potwierdzenia. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 64 z 93

2. Leczenie 1. Wpis do historii choroby Dopisanie nowych danych do historii choroby pacjenta. Procesy wykorzystujące funkcję: 3.2 Dane wejściowe: Identyfikator pacjenta, dane do wprowadzenia, identyfikator lekarza. Warunek wstępny: Lekarz jest zalogowany, został wybrany pacjent dla którego dodawany zostaje wpis do historii choroby. Opis działania: wpis_leczenie(id_pacjenta, ID_lekarza, data_wizyty, objawy, diag, leki, recepty, zwoln, uwagi) { JEŻELI wszystkie dane poprawne { JEŻELI data_wizyty nie podana { data_wizyty := dzisiejsza data Dopisz do bazy danych medycznych { Pacjent: ID_pacjenta Data: data_wizyty Objawy: objawy Rozpoznanie: diag Leczenie: leki Recepta: recepty Niezdolność do pracy: zwoln Uwagi: uwagi Lekarz: ID_lekarza ZWRÓĆ potwierdzenie INACZEJ { ZWRÓĆ błąd Dane wyjściowe: potwierdzenie dodania wpisu Warunek końcowy: Podane dane są kompletne. Efekty uboczne: Dodanie nowego wpisu do historii choroby zgodnie z danymi podanymi przez lekarza. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 65 z 93

2. Wydruk skierowania Dopisanie skierowania do historii choroby i wydrukowanie jego papierowej wersji dla pacjenta. Procesy wykorzystujące funkcję: 3.3 Dane wejściowe: Dane do skierowania. Warunek wstępny: Został wybrany istniejący pacjent. Opis działania: skierowanie(id_pacjenta, ID_lekarza, data_skier, rodz_skier, specjal, rozp, powod, lista_badan, uwagi) { JEŻELI wszystkie dane poprawne { JEŻELI data_skier nie podana { data_skier := dzisiejsza data Dopisz do bazy danych skierowanie { Pacjent: ID_pacjenta Data: data_skier Rodzaj: rodz_skier JEŻELI NIE rodz_skier = NA_BADANIA { Skierowanie do: specjal Rozpoznanie: rozp Uzasadnienie: powod Badania: lista_badan Uwagi: uwagi Lekarz: ID_lekarza wydrukuj skierowanie (ID_pacjenta, data_skier, rodz_skier, specjal, rozp, powod, lista_badan); /* na skierowaniu znajdują się dane pacjenta (jak w załącznikach 1 i 2) Pozyskiwane z bazy danych osobowych */ ZWRÓĆ potwierdzenie INACZEJ { ZWRÓĆ błąd Dane wyjściowe: potwierdzenie Warunek końcowy: Podane dane są kompletne. Efekty uboczne: Dodanie nowego wpisu do historii choroby zawierającego opis wystawionego skierowania; wydruk wersji papierowej. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 66 z 93

3. Pobranie historii choroby Pobranie z serwera pełnej wersji historii choroby wybranego pacjenta. Procesy wykorzystujące funkcję: 3.2 Dane wejściowe: Identyfikator pacjenta, identyfikator lekarza. Warunek wstępny: Został wybrany istniejący pacjent, lekarz jest zalogowany. Opis działania: historia_choroby(id_pacj, ID_lek) { JEŻELI istnieje pacjent ID_pacj i lekarz ID_lek { Wybierz z bazy wszystkie wpisy dotyczące pacjenta ID_pacj Sporządzone zestawienie wyślij lekarzowi ID_lek INACZEJ { ZWRÓĆ błąd Dane wyjściowe: historia choroby pacjenta Warunek końcowy: Historia choroby pacjenta istnieje. Efekty uboczne: Wygenerowanie i wyświetlenie na ekranie komputera lekarza dokumentu zawierającego kompletną historię choroby wybranego pacjenta. 3. Pracownicy 1. Propozycja zmiany terminarza dyżurów. Pobranie z serwera pełnej wersji dyżurów pracowników i próba jej modyfikacji. Procesy wykorzystujące funkcję: 4.1 Dane wejściowe: Identyfikator pracownika chcącego wykonać zmianę, lista zmian Warunek wstępny: pracownik jest zalogowany Opis działania: zmien_godziny_pracy(id_pracownika, lista_zmian) { JEŻELI istnieje pracownik o ID=ID_pracownika { JEŻELI lista_zmian jest poprawna { Wygeneruj akualny terminarz Wygeneruj proponowany terminarz Dopisz poprawki z lista_zmian do bazy celem zatwierdzenia przez dział kadr ZWRÓĆ potwierdzenie INACZEJ { ZWRÓĆ błąd INACZEJ { ZWRÓĆ błąd Dane wyjściowe: potwierdzenie Warunek końcowy: Wybrany pracownik ma prawo modyfikować swój grafik. Efekty uboczne: Wygenerowanie i wyświetlenie na ekranie komputera grafiku dyżurów pracowników, zapisanie sugestii pracownika do akceptacji przez dział kadr. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 67 z 93

2. Zatwierdzenie zmian w dyżurach. Pobranie z serwera pełnej wersji dyżurów pracowników i zatwierdzenie jej do wprowadzenia w życie. Procesy wykorzystujące funkcję: 4.2 Dane wejściowe: ID pracownika, zgoda na zmianę dyżurów, ID proponowanego grafiku Warunek wstępny: Istnieją dyżury w wybranym terminie, pracownik zalogował się do systemu Opis działania: zmien_dyzury(id_pracownika, czy_akceptuje, ID_tmp_grafiku) { JEŻELI istnieje pracownik ID_pracownika && ma uprawnienia do zmiany dyżurów { JEŻELI istnieje proponowany terminarz ID_tmp_grafiku JEŻELI czy_akceptuje { Wygeneruj proponowany terminarz Zapisz nowy terminarz do bazy danych DLA KAŻDEGO pracownika przychodni { JEŻELI grafik pracownika zmieniony{ Powiadom o zmianie grafiku. ZWRÓĆ potwierdzenie zmiany INACZEJ { Usuń z bazy terminarz ID_tmp_grafiku Wygeneruj aktualny terminarz ZWRÓĆ potwierdzenie usunięcia INACZEJ { ZWRÓĆ błąd INACZEJ { ZWRÓĆ błąd Dane wyjściowe: potwierdzenie Warunek końcowy: Nowy rozkład dyżurów jest akceptowalny. Efekty uboczne: Po zatwierdzeniu dyżurów zostają one wprowadzone do głównej bazy danych, rozesłanie informacji o zmianach Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 68 z 93

4. Administracja 1. Utworzenie kopii zapasowej bazy Utworzenie kopii zapasowej wybranej bazy danych. Procesy wykorzystujące funkcję: 6 Dane wejściowe: Nazwa bazy, której kopię należy wykonać, katalog docelowy Warunek wstępny: Wybrana baza istnieje na serwerze. Opis działania: tworz_backup(nazwa_bazy, sciezka_plik) { JEŻELI jest dostęp do bazy nazwa_bazy { JEŻELI istnieje plik sciezka_plik { ZWRÓĆ błąd INACZEJ { Twórz kopię zapasową bazy nazwa_bazy do pliku sciezka_plik JEŻELI tworzenie kopii nieudane { Usuń plik sciezka_plik. Wyswietl szczegoly bledu. ZWRÓĆ błąd kopiowania INACZEJ { Wypisz informacje o utworzonej kopii. ZWRÓĆ potwierdzenie INACZEJ { ZWRÓĆ błąd Dane wyjściowe:? Warunek końcowy: Wybrana lokalizacja posiada wystarczająco dużo miejsca, istnieje dostęp do podanej ścieżki Efekty uboczne: Wygenerowanie i zapisanie w katalogu docelowym kopii zapasowej wybranej bazy. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 69 z 93

2. Przywrócenie kopii zapasowej Przywrócenie kopii zapasowej wybranej bazy danych. Procesy wykorzystujące funkcję: 6 Dane wejściowe: Lokalizacja pliku z kopią zapasową, nazwa bazy Warunek wstępny: Baza zawarta w pliku istnieje w innej wersji w systemie. Opis działania: przywroc_backup(nazwa_bazy, sciezka_plik) { JEŻELI jest dostęp do bazy nazwa_bazy { JEŻELI NIE istnieje plik sciezka_plik { ZWRÓĆ błąd INACZEJ { JEŻELI NIE sciezka_plik = AUTO_KOPIA_BAZY(nazwa_bazy) { JEŻELI istnieje plik AUTO_KOPIA_BAZY(nazwa_bazy) { Usuń plik AUTO_KOPIA_BAZY(nazwa_bazy). tworz_backup(nazwa_bazy, AUTO_KOPIA_BAZY(nazwa_bazy)) Przywróć zawartość bazy danych nazwa_bazy z pliku sciezka_plik JEŻELI przywracanie nieudane { przywroc_backup(nazwa_bazy, AUTO_KOPIA_BAZY(nazwa_bazy)) Wyswietl szczegoly bledu. ZWRÓĆ błąd INACZEJ { ZWRÓĆ potwierdzenie INACZEJ { ZWRÓĆ błąd Dane wyjściowe: potwierdzenie Warunek końcowy: brak Efekty uboczne: Przywrócenie zawartej w pliku wersji bazy danych, utworzenie (jeśli możliwe) kopii usuwanej bazy. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 70 z 93

3. Dodanie pracownika Utworzenie nowego konta pracownika w systemie. Procesy wykorzystujące funkcję: 6 Dane wejściowe: Dane osobowe pracownika, posada, uprawnienia. Warunek wstępny: Pracownik nie istnieje jeszcze w systemie. Opis działania: dodaj_uzytkownika(imie, nazwisko, nr_tel, login_id, e_mail, stanow, upraw) { JEŻELI zalogowany jako administrator { JEŻELI istnieje osoba o loginie login_id { ZWRÓĆ błąd INACZEJ { JEŻELI wszystkie podane dane poprawne { JEŻELI nie podano login_id { POWTARZAJ { login_id := wygeneruj nowy login (imie, nazwisko) AŻ nie ma pracownika z loginem login_id tymczasowe_haslo := wygeneruj losowe hasło Dodaj do bazy nowego użytkownika { Imię: imie Nazwisko: nazwisko Telefon: nr_tel E-mail: e_mail Stanowisko: stanow Uprawnienia: upraw Konto aktywne: TAK Login: login_id Hasło: hash(tymczasowe_haslo) Prześlij pracownikowi dane logowania. ZWRÓĆ potwierdzenie INACZEJ { ZWRÓĆ błąd INACZEJ { ZWRÓĆ błąd Dane wyjściowe: potwierdzenie Warunek końcowy: Podane dane są poprawne Efekty uboczne: Utworzenie identyfikatora i konta dla pracownika o wybranych uprawnieniach. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 71 z 93

4. Edycja użytkownika Zmiana danych osobowych, lub posady pracownika. Procesy wykorzystujące funkcję: 6 Dane wejściowe: Identyfikator pracownika, nowe dane osobowe/posada Warunek wstępny: Wybrany użytkownik istnieje w systemie Opis działania: edycja_uzytkownika(id_uzytk, ktore_pole, nowa_wartosc) { JEŻELI zalogowany jako administrator { JEŻELI istnieje użytkownik o ID=ID_uzytk && ktore_pole poprawnie identyfikuje daną do zmiany { JEŻELI nowa_wartosc jest poprawną wartością danej ktore_pole { Nadpisz w bazie użytkownikowi ID_uzytk dotychczasową wartość ktore_pole przy pomocy nowa_wartosc. ZWRÓĆ potwierdzenie INACZEJ { ZWRÓĆ błąd INACZEJ { ZWRÓĆ błąd INACZEJ { ZWRÓĆ błąd Dane wyjściowe: potwierdzenie Warunek końcowy: Podane dane są poprawne. Efekty uboczne: Zmiana danych dotyczących wybranego pracownika 5. Ustawienie uprawnień użytkownika Zmiana praw dostępu pracownika. Procesy wykorzystujące funkcję: 6 Dane wejściowe: Identyfikator pracownika, nowe uprawnienia Warunek wstępny: Wybrany użytkownik istnieje w systemie Opis działania: Ustaw_uprawnienia(ID, nowe_upr) { JEŻELI zalogowany jako administrator { JEŻELI użytkownik określony przez ID istnieje i jest pracownikiem { JEŻELI nowe_upr to poprawne uprawnienia { Nadaj użytkownikowi opisanemu danym ID przywileje nowe_upr. ZWRÓĆ potwierdzenie INACZEJ { ZWRÓĆ błąd INACZEJ { ZWRÓĆ błąd INACZEJ { ZWRÓĆ błąd Dane wyjściowe: potwierdzenie Warunek końcowy: Podane uprawnienia są poprawne. Efekty uboczne: Zmiana uprawnień wybranego pracownika Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 72 z 93

6. Usunięcie użytkownika Uniemożliwienie użytkownikowi dostępu do systemu. Procesy wykorzystujące funkcję: 6 Dane wejściowe: Identyfikator pracownika Warunek wstępny: Wybrany użytkownik istnieje w systemie Opis działania: usuniecie_uzytkownika(id) { JEŻELI zalogowany jako administrator { JEŻELI użytkownik określony przez ID istnieje { Oznacz konto użytkownika o identyfikatorze ID jako nieaktywne. ZWRÓĆ potwierdzenie INACZEJ { ZWRÓĆ błąd INACZEJ { ZWRÓĆ błąd Dane wyjściowe: potwierdzenie Warunek końcowy: brak Efekty uboczne: Oznaczenie konta pracownika jako nieaktywne. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 73 z 93

9 Architektura systemu Proponowany system jest oparty na architekturze typu klient-serwer. Poniekąd zastosowanie tej architektury narzuca się samo, biorąc pod uwagę iż dostęp do funkcjonalności systemu musi być możliwy z wielu niezależnych stanowisk roboczych i są to nie tylko lokalnie podłączone stanowiska w gabinetach lekarskich i salach zabiegowych, bądź terminale pracowników rejestracji i administracji, ale także musi być możliwy dostęp dla pacjentów poprzez sieć Internet. Dodatkowym argumentem przemawiającym za zastosowaniem architektury typu klient serwer jest fakt iż podstawową funkcjonalnością naszego systemu jest przechowywanie oraz udostępnianie danych. Wynika z tego iż potrzeba tylko jednego specjalnie wydzielonego komputera o znacznie większych zasobach systemowych, który będzie odpowiadał głównie za przechowywanie bazy danych, a także wykonywanie na niej wszelkich operacji zleconych przez użytkowników. Z kolei do obsługi użytkowników i przekazywaniu ich żądań do serwera nie potrzeba mocnych maszyn, wystarczą tanie, podstawowe konfiguracje, umożliwiające uruchomienie prostych aplikacji. Do obsługi użytkowników, zarówno pacjentów jak i lekarzy, w zupełności wystarczą przeglądarki internetowe, które dają bardzo duże możliwości jeśli chodzi o stworzenie interface użytkownika, a także dają możliwość zapewnienia bezpieczeństwa przesyłanym danym, poprzez zaimplementowane w nich, sprawdzone mechanizmy szyfrowania przesyłanych danych. Co więcej, dzięki temu nie ma konieczności obciążania maszyn użytkowników dodatkowymi aplikacjami, gdyż przeglądarka internetowa jest obecna praktycznie w każdym komputerze. Dzięki temu zarówno pacjenci jak i lekarze mają możliwość skorzystania z funkcjonalności systemu z dowolnej maszyny, również takiej na której nie ma możliwości instalowania dodatkowego oprogramowania (np. pacjent uległ wypadkowi na wakacjach i chciałby się umówić na wizytę i musi skorzystać z kafejki internetowej, bądź lekarz będący na wizycie domowej, korzysta z komputera pacjenta). Do tworzenia tej części systemu zdecydowaliśmy się wykorzystać technologię PHP ze względu na jej duże możliwości oraz względną prostotę, adekwatną do złożoności całego systemu. Całość systemu zostanie napisana w języku wysokopoziomowym, wspierającym paradygmat programowania obiektowego. Wybraliśmy język Java, ze względu na jego dobry stosunek łatwości pisania w nim do wydajności napisanych programów oraz pokaźną liczbę otwartych bibliotek, których wykorzystanie zdecydowanie zmniejszy złożoność projektu. Dodatkowo do tego języka istnieją bardzo dobre systemy obsługi relacyjnych baz danych ORM. Jako system obsługi bazy danych wybraliśmy MySQL, gdyż jest on darmowy, a jego wydajność w zupełność wystarczy do obsługi placówki medycznej. Jako serwer WWW użyjemy Apache ze względu na jego dostępność, stabilność oraz popularność, co gwarantuje dobre wsparcie. System operacyjny który będzie użyty na serwerze, to dowolny system przeznaczony do celów serwerowych. Może to być zarówno Windows Server, jak i któryś z systemów z rodziny Linux. Preferowalibyśmy których z darmowych systemów, gdyż jest on wystarczający do naszych celów i umożliwia uruchomienie wszystkich wcześniej wymienionych technologii. Jeśli chodzi o system operacyjny po stronie użytkownika to jest on dowolny, gdyż najnowsze przeglądarki internetowe są dostępne na każdym współczesnym systemie operacyjnym, przeznaczonym dla komputerów osobistych. Dodatkowo w celu umożliwienia powiadamiania poprzez SMS, serwer musi dysponować modemem GSM. W celu obsługi tej funkcjonalności skorzystamy z biblioteki Kannel, która daje możliwość prostego wysyłania SMS poprzez moduł GSM. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 74 z 93

Model architektury systemu: Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 75 z 93

10 Projekt interfejsu użytkownika 10.1 Założenia ogólne Graficzny interfejs użytkownika powinien być przede wszystkim nastawiony na łatwość, intuicyjność obsługi i estetykę oraz oferować przejrzysty układ; ponadto, ma być zgodny z przyjętym systemem operacyjnym, Microsoft Windows. Struktura organizacyjna przychodni określa wyodrębnione grupy użytkowników. Grupy różnią się między sobą uprawnieniami dostępu do systemu. Wyróżnia się następujące grupy użytkowników: (a) osoby odpowiedzialne za rejestrację, pracownicy rejestracji (b) lekarze (c) zarząd spółki (d) inny personel medyczny Należy zaznaczyć w szczególności, że grupy (a) oraz (c) nie mają żadnego dostępu do danych medycznych i historii choroby. Grupa trzecia, zarząd spółki, ma ponadto ograniczony dostęp do (pozamedycznych) danych osobowych pacjentów. Grupa ostatnia, pozostały personel medyczny, także dysponuje dostępem do danych pacjentów wyłącznie w ograniczonym stopniu, należy zaznaczyć jednak, że przy jednoczesnym braku dostępu do danych osobowych, posiada (ewentualnie) w bardzo ograniczonym stopniu dostęp do danych medycznych, bez możliwości wprowadzania jakichkolwiek zmian. Wynika to m.in. z konieczności umożliwienia np. personelowi pielęgniarskiemu sprawdzania grafiku pracy lekarzy lub swojego grafiku pracy bez konieczności zwracania się z tym problemem bezpośrednio do osoby odpowiedzialnej za rejestrację pacjentów. Pierwszym krokiem rozpoczęcia korzystania z systemu jest zalogowanie się. Użytkownik loguje się do systemu poprzez podanie pary: login oraz hasło; okno dialogowe logowania umożliwia także rezygnację z uruchomienia systemu - zakończ. Interfejs logowania jest wspólny dla wszystkich wymienionych grup. Następnie, po zalogowaniu się, każda grupa posiada własny interfejs udostępniający odpowiednią funkcjonalność w zależności od posiadanych w systemie uprawnień. Użytkownik uzyskuje dostęp do odpowiadającego swojej grupie panelu głównego. Interfejsy wszystkich grup są zbliżone, w bardzo ograniczonym zakresie może istnieć możliwość personalizacji interfejsu danego użytkownika. Interfejs klienta będzie udostępniony jako serwis WWW, wśród klientów nie będzie oczywiście żadnego dodatkowego podział na grupy użytkowników. 10.2 Wspólne elementy interfejsu graficznego (standardy, konwencje) W celu usprawnienia pracy użytkowników interfejs powinien być przede wszystkim przejrzysty i łatwy w obsłudze. Dla ułatwienia pracy ilość jednocześnie otwartych okien systemu powinna minimalizowana, nie pozwalając użytkownikowi na jednoczesne otwarcie zbyt wielu okien, co może prowadzić do dezorientacji i chaosu. Jeżeli nie będzie to określone inaczej każde okno dialogowe posiada przyciski zapisz zmiany oraz anuluj, które powodują powrót do poprzedniego okna. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 76 z 93

10.3 Lista okien dialogowych W szczególności opisane są elementy interfejsu osoby odpowiedzialnej za rejestrację i lekarza. Interfejs zarządu pominięto jako stosunkowo najprostszy i stanowiący połączenie interfejsów innych grup w ograniczonym zakresie. Szczegółowy opis okien dialogowych zaprezentowany jest za przykładzie osoby odpowiedzialnej za rejestracje (dyspozytora). 10.3.1 Dialogi :: osoba odpowiedzialna za rejestrację pacjentów 10.3.1.1 Panel główny dyspozytora Ekran główny (strona główna) widoczny po zalogowaniu, zawiera wszystkie niezbędne dla osoby odpowiedzialnej za rejestracje pacjentów dalej nazywanej dyspozytorem zakładki umożliwiające przejście do poszczególnych aktywności: (1) obsługi terminarza, zakładka terminarz, oraz przede wszystkim (2) obszaru aktywności związanego z obsługą pacjentów przychodni - zakładka recepcja Część interfejsu służąca obsłudze pacjentów - recepcja - umożliwia dodanie nowego pacjenta lub wybór pacjenta przychodni (poprzez dokonanie wyboru z rozwijanej listy wszystkich pacjentów lub wyszukiwanie pacjenta po nazwisku). Po wybraniu pacjenta dyspozytor uzyskuje dostęp do zakładek: dane pacjenta, terminy pacjenta oraz wizyty pacjenta (historia wizyt zawierająca daty oraz podstawowe informacje bez pełnego opisu medycznego wizyty). Panel główny zawiera także przyciski wyloguj z systemu przenoszący użytkownika do panelu logowania, zakończ pracę kończący pracę całego systemu oraz zablokuj powodujący blokadę dostępu do systemu aż do odblokowania (po odblokowaniu następuje powrót do poprzedniego stanu pracy systemu). Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 77 z 93

Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 78 z 93

10.3.1.2 Dodawanie pacjenta Na ekranie pojawia się formularz zawierający pola do podania danych nowego pacjenta. Po zapisaniu (wybraniu przycisku zapisz ) nowy pacjent jest dodawany. Po zakończeniu następuje powrót do ekranu głównego dyspozytora. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 79 z 93

10.3.1.3 Modyfikacja danych osobowych pacjenta Na ekranie pojawia się wypełniony formularz z danymi klienta odczytanymi z bazy danych. Po przyciśnięciu przycisku zapisz dane są zapisywane do bazy danych. Po zapisaniu (wybraniu przycisku zapisz ) nowy pacjent jest dodawany. W przypadku poprawnego zakończenia operacji następuje wygenerowanie okna z komunikatem informującym o zakończeniu dodania nowego pacjenta oraz loginem i hasłem dodanego pacjenta. Po zakończeniu następuje powrót do poprzedniego okna. 10.3.1.4 Modyfikacja historii wizyt pacjenta Do wprowadzania zmian służy przycisk dodaj nowy wpis. Rejestrator nie może modyfikować zapisanej historii wizyt. Przy dodawaniu nowego wpisu na ekranie pojawia się formularz zawierający pola do uzupełnienia (data wizyty, godzina, lekarz). Po zapisaniu (wybraniu przycisku zapisz ) nowy wpis jest dodawany. Po zakończeniu następuje powrót do ekranu głównego dyspozytora. Modyfikacja historii wizyt pacjenta obejmuje także zapisywanie wszystkich odbytych rozmów telefonicznych z pacjentem, stąd po wybraniu przycisku dodaj nowy wpis formularz zawiera także pole zawierające informację, czy modyfikacja dotyczy wizyty w przychodni, czy wyłącznie rozmowy telefonicznej (np. dotyczącej ustalania wizyt). W przypadku zaznaczenia opcji rozmowa telefoniczna część pół formularza (jak np. imię i nazwisko lekarza) staje się nieaktywna. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 80 z 93

10.3.1.5 Wyszukanie terminu wizyty w terminarzu Na ekranie pojawia się formularz w którym określa się datę wizyty oraz/lub lekarza. Formularz zawiera rozwijane tabele z (1) nazwiskami lekarzy oraz (2) wyborem specjalizacji oraz pole wyboru daty wizyty. Przy wyszukiwaniu opcjonalne jest podanie nazwiska lekarza i/lub specjalnosci. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 81 z 93

10.3.1.6 Dodanie terminu wizyty do terminarza Formularz umożliwiający dodanie nowego terminu wizyty. Po wybraniu w poprzednim oknie (10.3.1.5) warunków wyszukiwania pojawia się lista dostępnych terminów (w zakresie obejmującym bieżący tydzień). Po zapisaniu (wybraniu przycisku zapisz ) nowy wpis jest dodawany. Po zakończeniu następuje powrót do poprzedniego ekranu. 10.3.1.7 Modyfikacja terminu wizyty w terminarzu Formularz umożliwiający zmianę ustalonego terminu wizyty. Po zapisaniu (wybraniu przycisku zapisz ) nowy wpis jest dodawany. Po zakończeniu następuje powrót do poprzedniego ekranu. 10.3.1.8 Usunięcie terminu wizyty Formularz umożliwiający usunięcie ustalonego terminu wizyty. Po zapisaniu (wybraniu przycisku zapisz ) nowy wpis jest dodawany. Po zakończeniu następuje powrót do poprzedniego ekranu. 10.3.1.9 Aktualny grafik terminów Wyświetla w formie kalendarza wszystkie aktualne terminy wizyt. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 82 z 93

10.3.2 Dialogi :: lekarz Podobnie jak dyspozytor lekarz, po zalogowaniu, ma dostęp do (1) obsługi terminarza, oraz (2) obszaru aktywności związanego z obsługą pacjentów przychodni. Ekran główny (strona główna) widoczny po zalogowaniu, zawiera zakładki umożliwiające przejście do poszczególnych aktywności: (1) obsługi terminarza, zakładka terminarz (2) obszaru aktywności związanego z obsługą pacjentów przychodni - zakładka gabinet Obsługa pacjenta - gabinet - obejmuje zakładki umożliwiające dostęp do danych pacjenta w najszerszym zakresie: lekarz ma dostęp zarówno do części danych osobowych pacjenta (potrzebne do wystawiania recept, skierowań oraz zwolnień) :: dane pacjenta danych medycznych :: historia choroby terminarza pacjenta :: terminy pacjenta Lekarz nie ma upewnień do edytowania danych osobowych pacjenta, stąd pojawiające się okna dialogowe dotyczą edycji historii choroby oraz zmian w terminarzu wizyt. Panel główny zawiera także przyciski wyloguj z systemu przenoszący użytkownika do panelu logowania, zakończ pracę kończący pracę całego systemu oraz zablokuj powodujący blokadę dostępu do systemu aż do odblokowania (po odblokowaniu następuje powrót do poprzedniego stanu pracy systemu). Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 83 z 93

10.3.3 Dialogi :: pacjent Serwis WWW umożliwia pacjentowi, oprócz samodzielnego zarządzania wizytami, także przeglądanie historii wizyt i sprawdzanie ogólnodostępnego grafiku pracy personelu. Pacjent korzysta z okien dialogowych do wyboru lekarza oraz terminu przy sprawdzaniu dostępności terminów wizyt. 10.4 Szkice GUI 10.4.1 Okno interfejsu osoby odpowiedzialnej za rejestrację Ogólną ideę wyglądu interfejsu użytkownika pokazuje przykładowy ekran główny dyspozytora stan: wybrane dane osobowe pacjenta. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 84 z 93

10.4.2 Przykładowe formularze dodania nowego pacjenta oraz edycji danych osobowych pacjenta Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 85 z 93

10.5 System pomocy System pomocy ma zawierać listę alfabetycznie uporządkowanych haseł kluczowych oraz logicznie uporządkowaną listę w zagadnień w postaci krótkich opisów czynności przeprowadzającą użytkownika przez najczęściej wykonywane zadania. Lista ta ma odsyłać użytkownika do krótkich opisów czynności ilustrowanych krok po kroku zrzutami (print screen) okien systemu. Ta część pomocy ma stanowić przede wszystkim pewnego rodzaju tutorial dla początkujących użytkowników systemu. Ograniczony zbiór opisów kilkunastu podstawowych czynności w ich najbardziej ograniczonym zakresie ma stanowić przyjazne wprowadzenie do korzystania z systemu oraz umożliwić w przystępny sposób korzystanie z podstawowych funkcji początkującym użytkownikom. Przykładem zadań opisanych w postaci wypunktowanej listy ilustrowanej przykładowymi oknami systemu będzie na przykład dodanie nowego pacjenta, czy też dodanie nowego wpisu do historii choroby. System pomocy powinien umożliwiać także korzystanie z pomocy w sposób kontekstowy, tj. prezentować informacje dotyczące aktualnie wykorzystywanego modułu i uzyskanie wiedzy dotyczącej obsługi danej części systemu. Plik: Wersja 1.0 z dnia 15.01.2010 Stron: 93, Długość: 3,24 MiB Strona 86 z 93