CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
1
Załącznik nr 3
Koncepcja Architektury
Spis Treści
Załącznik nr ................................................................................................................................................... 1
Koncepcja Architektury .............................................................................................................................. 1
1 Wprowadzenie .............................................................................................................................................. 2
1.1 Cel dokumentu .................................................................................................................................... 2
1.2 Zakres ................................................................................................................................................. 2
1.3 Definicje .............................................................................................................................................. 2
1.4 Założenia niefunkcjonalne .................................................................................................................. 2
2 Architektura Aplikacji ................................................................................................................................ 18
2.1 Technologie ....................................................................................................................................... 21
2.2 Podsystemy i komponenty ............................................................ Błąd! Nie zdefiniowano zakładki.
2.3 Perspektywy systemu ....................................................................................................................... 23
2.3.1 Perspektywa danych ......................................................................................................................... 23
2.3.2 Perspektywa dokumentów ................................................................................................................ 24
2.3.3 Perspektywa bezpieczeństwa – dostępy, protokoły ......................................................................... 24
3 Specyficzne warunki i ograniczenia ........................................................................................................ 24
3.1 Problemy i ograniczenia technologiczne w oprogramowaniu standardowym .................................. 24
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
2
1 Wprowadzenie Koncepcja architektoniczna przedstawia całość systemu e-Krew i jego powiązanie z innymi systemami. Dokument opisuje założenia niefunkcjonalne oraz podstawowe standardy techniczne wykonania systemu. Przedstawione są w szczególności podsystemy i komponenty systemu oraz sposób komunikacji z innymi systemami.
1.1 Cel dokumentu
Celem dokumentu jest przedstawienie technicznych aspektów systemu. Dokument stanowi element OPZ (Opis Przedmiotu Zamówienia).
1.2 Zakres
Koncepcja architektoniczna zawiera wszelkie wymagania dotyczące architektury systemu dla wytwarzanego oprogramowania. Dokument jest aktualizowany wraz z rozwojem systemu. Utworzenie systemu rozpoczyna cykl życia tego dokumentu. Kolejne zmiany w systemie powodują aktualizację dokumentu. Wszelkie zmiany śledzone są w historii zmian dokumentu. [Zapis w historii zmian może mieć postać: „uzględniono zmiany dla Propozycji XXX”.] Szczegółowe opisy dotyczące sposobu implementacji znajdą się w Projekcie Technicznym.
1.3 Definicje
Definicje występujących w dokumencie – techniczne jak i analityczne.
PWDL Podmiot Wykonujący Działalność Leczniczą
CKiK Centrum Krwiodawstwa i Krwiolecznictwa
IHiT Instytut Hematologii i Transfuzjologii
OT Oddział Terenowy
1.4 Założenia niefunkcjonalne
1. Interfejs Użytkownika
Wymaganie Opis wymagania
WYM.OPZ.GUI.NFN.01
Interfejs przeglądarkowy
Interfejs graficzny przeznaczony dla użytkownika końcowego zrealizowany
zostanie jako zestaw aplikacji serwerowych prezentujących dane w
przeglądarce po stronie klienta. Zamawiający może wyrazić zgodę na
odstępstwo od tej reguły.
WYM.OPZ.GUI.NFN.02
Wersje przeglądarek
System umożliwiać będzie pracę z następującymi przeglądarkami:
Microsoft Internet Explorer w wersji 11.0 i wyższych,
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
3
Wymaganie Opis wymagania
Mozilla Firefox w wersji aktualnej na moment rozpoczęcia
wytwarzania projektu wykonawczego i wyższych,
Google Chrome w wersji aktualnej na moment rozpoczęcia
wytwarzania projektu wykonawczego i wyższych,
Opera w wersji w wersji aktualnej na moment rozpoczęcia
wytwarzania projektu wykonawczego i wyższych,
Safari w wersji 10.0 i wyższych.
WYM.OPZ.GUI.NFN.04
Dostęp dla osób
niepełnosprawnych
Dokumenty jak i cała treść prezentowana przez interfejs powinna być czytelna,
również dla użytkowników niedowidzących. Interfejs ogólnodostępnej części
serwisu (w tym przeznaczona dla zarejestrowanych użytkowników –
przedstawicieli podmiotów i osób fizycznych), z wyłączeniem konsol
administracyjnych, w zakresie dostępności dla ludzi niepełnosprawnych
powinien być zgodny z wytycznymi organizacji W3C [“Web Content
Accessibility Guidelines 2.0”, W3C Recommendation 5-May-1999] na poziomie
„AA". Wykonawca dostarczy deklarację zgodności wytworzonych interfejsów
graficznych z wymienionymi wytycznymi.
WYM.OPZ.GUI.NFN.05
Standard rozdzielczości
Interfejs użytkownika będzie dostosowany do ekranów o rozdzielczości
przynajmniej 1024x768. Wyjątkiem będą moduły wspierające urządzenia
mobilne, które będą korzystać z rozdzielczości natywnej dla danego
rozwiązania.
WYM.OPZ.GUI.NFN.06
Standard kodowania
znaków
System będzie w warstwie prezentacyjnej posługiwać się standardem
kodowania znaków UTF-8.
WYM.OPZ.GUI.NFN.07
Praca w wielu okienkach
System musi umożliwiać użytkownikowi pracę w kilku oknach aplikacji
równocześnie, przy czym wystarczające jest wtedy jednokrotne zalogowanie do
systemu.
WYM.OPZ.GUI.NFN.08
Urządzenia mobilne
Wykonawca zobowiązany będzie do dostarczenia interfejsów graficznych
opartych o strony internetowe, przeznaczonych dla użytkowników końcowych,
w wersjach przeznaczonych dla urządzeń mobilnych. Interfejs powinien być
czytelny i funkcjonalny zarówno w perspektywie poziomej i pionowej.
Wymagane jest wsparcie dla urządzeń pracujących pod kontrolą, co najmniej,
następujących systemów operacyjnych:
Android,
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
4
Wymaganie Opis wymagania
iOS.
WYM.OPZ.GUI.NFN.10
Pomoc kontekstowa
System musi zapewnić pomoc kontekstową dla Użytkowników. Treść pomocy
kontekstowej ma być łatwo modyfikowalna przez administratorów systemu
poprzez edytor WYSIWYG.
WYM.OPZ.GUI.NFN.11
Komunikaty systemowe
Wszystkie komunikaty o błędach i nieprawidłowościach pracy generowane przez system e-Krew muszą być wyświetlane w języku polskim i sformułowane w sposób zrozumiały dla użytkownika.
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
5
2. Bezpieczeństwo
Wymaganie Opis wymagania
WYM.OPZ.BEZ.01
Ochrona dostępu
System musi zapewnić pełną ochronę przed nieuprawnionym dostępem
osób i systemów do danych. W szczególności wszystkie Podsystemy
muszą spełniać wymogi przepisów w zakresie dokumentacji
przetwarzania danych osobowych oraz warunków technicznych
i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy
informatyczne służące do przetwarzania danych osobowych.
WYM.OPZ.BEZ.02
Ochrona dostępu
System nie może udostępniać uwierzytelnionemu użytkownikowi żadnej
funkcjonalności do której nie posiada on uprawnień i która nie wchodzi w
zakres przyznanego dostępu.
WYM.OPZ.BEZ.03
Ochrona danych
osobowych
Wszystkie podsystemy muszą spełniać wymogi krajowych i unijnych
przepisów prawa dotyczących ochrony danych osobowych.
WYM.OPZ.BEZ.04
Komunikacja z
systemami
zewnętrznymi
Komunikacja z systemami zewnętrznymi musi być szyfrowana.
Szyfrowanie komunikacji zrealizowane musi być w oparciu o rozwiązania
zapewniające poziom bezpieczeństwa co najmniej równy temu jaki
zapewniają protokoły TLS w wersji co najmniej 1.1 lub VPN.
WYM.OZP.BEZ.05
Kryptografia
System MUSI wykorzystywać szyfrowanie przy komunikacji pomiędzy
wszystkimi komponentami. Szyfrowanie MUSI być zrealizowane w
oparciu o rozwiązania zapewniające poziom bezpieczeństwa co najmniej
równy temu jaki zapewniają protokoły SSL/TLS lub VPN
WYM.OPZ.BEZ.06
Normy
System w zakresie bezpieczeństwa przetwarzanych danych spełniać
będzie wymogi wynikające z obowiązujących i projektowanych aktów
prawnych oraz norm z nich wynikających.
WYM.OPZ.BEZ.07
Ograniczenie dostępu
administracyjnego
Administracyjny dostęp do elementów systemu nieobjęty funkcjami
kontroli dostępu zapewnianymi przez mechanizmy uwierzytelniania
i autoryzacji samego systemu (np. bezpośredni dostęp do tabel bazy
danych) możliwy będzie wyłącznie z wybranych, wskazanych przez
Zamawiającego lokalizacji i maszyn.
WYM.OPZ.BEZ.08 DMZ Serwery służące komunikacji z systemami oraz użytkownikami
zewnętrznymi muszą się znajdować w strefach DMZ wynikających
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
6
z charakteru generowanego ruchu sieciowego. Poszczególne strefy DMZ
muszą być od siebie odseparowane przynajmniej na poziomie logicznym.
WYM.OPZ.BEZ.09
Dostęp do danych
osobowych
Dostęp użytkownika do danych osobowych lub wrażliwych będzie
wymagał uwierzytelnienia.
WYM.OPZ.BEZ.10
Separacja danych
Baza danych powinna zapewniać separację danych – podział danych na
dwie części – odseparowanie danych wrażliwych (niosących w sobie
informacje identyfikujące) od pozostałych danych. Dane identyfikacyjne
nie niosły ze sobą żadnej dodatkowej informacji, a jedynie informację
identyfikacyjną. I etap do realizacji wymagania WYM.OPZ.BEZ.11
Szyfrowanie danych zastrzeżonych
WYM.OPZ.BEZ.11
Szyfrowanie danych
zastrzeżonych
Wszystkie dane prawnie chronione (dane osobowe, dane osobowe
wrażliwe, dane medyczne) przed zapisem w bazach danych zostaną
zdepersonalizowane bądź zanonimizowane w zależności od ich
przeznaczenia.
WYM.OPZ.BEZ.12
Poziom kontroli dostępu
do danych
Serwery systemu muszą podlegać ochronie przed nieuprawnionym
dostępem do danych na poziomie uprawnień systemu operacyjnego.
WYM.OPZ.BEZ.13
Zabezpieczenie typu IPS
System będzie chroniony przez zabezpieczenia typu IPS.
WYM.OPZ.BEZ.14
Zabezpieczenie
antywirusowe
Zarówno serwery jak i pozostałe komputery podłączone do sieci systemu
e-Krew (np. końcówki administratorskie) muszą być zabezpieczone
aktualizowanym na bieżąco oprogramowaniem antywirusowym o ile
takowe oprogramowanie jest dostępne na daną platformę. Serwery
musza być zabezpieczonymi antywirusami dedykowanymi dla środowiska
wirtualnego.
WYM.OPZ.BEZ.15
Kopia zapasowa
Podsystem musi umożliwiać odtworzenie danych na podstawie kopii
zapasowej, w szczególności musi umożliwiać:
wykonywanie kopii zapasowych danych w trakcie pracy systemu,
wykonywania automatycznego testowania kopii zapasowych,
odtworzenie danych.
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
7
WYM.OPZ.BEZ.16 Kopie
zapasowe
System musi umożliwiać planowe wykonywanie kopii zapasowych
danych, w postaci pełnej lub przyrostowej
WYM.OPZ.BEZ.17
Kopie zapasowe
System musi umożliwiać swobodne ustalanie harmonogramu
automatycznego tworzenia kopii zapasowych danych. Poza
mechanizmem automatycznym, musi umożliwiać wykonanie kopii
zapasowej w dowolnej chwili na żądanie administratora
WYM.OPZ.BEZ.18
Redundancja systemu
System, w ramach jednego ośrodka, musi być zbudowany z elementów
redundantnych zapewniających automatyczne przejęcie funkcji elementu,
który uległ awarii. Takie przejęcie musi być niewidoczne dla aktorów
korzystających z systemu. Elementy redundantne muszą być
wykorzystywane przy normalnym działaniu systemu do obsługiwania
części obciążenia.
WYM.OPZ.BEZ.19
Dostępność
i integralność
System musi umożliwiać wielu użytkownikom równoległy dostęp do tych
samych danych lub obszarów funkcjonalnych bez utraty integralności
danych
WYM.OPZ.BEZ.20
Bezpieczne usuwanie
danych
Podsystemy muszą zapewnić mechanizmy bezpiecznego usuwania
danych wrażliwych.
WYM.OPZ.BEZ.21
Zgodność systemu
Zgodność systemu e-Krew z normą ISO 27001 w zakresie systemowego zabezpieczenia dostępu do danych przetwarzanych w systemie e-Krew.
WYM.OPZ.BEZ.22
Audyt systemowy
System powinien umożliwiać audyt systemowy - udokumentowanie historii czynności związanych z zasobami i dostępów do zasobów – tj. monitorowanie nieautoryzowanego dostępu. Włączona klasa ochrony C2 [TCSEC] (śledzenie dostępu, identyfikacja użytkownika, kontrola dystrybucji uprawnień).
WYM.OPZ.BEZ.23
Monitorowanie i
detekcja ataków
sieciowych
System powinien umożliwiać monitorowanie i detekcję ataków sieciowych - monitorowanie zdarzeń bezpieczeństwa i powiadamianie – minimum analiza logów systemowych, aplikacji, poprzez skrypty opracowane przez administratorów.
WYM.OPZ.BEZ.24 Logi
systemowe
System e-Krew musi tworzyć i utrzymywać log systemu, rejestrujący historię logowania do systemu wszystkich użytkowników oraz wykonane przez nich czynności wprowadzania, modyfikacji i usuwania danych.
WYM.OPZ.BEZ.25
Logi systemowe
W przypadku każdej (zarówno udanej, jak i nieudanej) próby uwierzytelnienia i wylogowania z Systemu, musi on rejestrować następujące informacje: czas wykonania próby uwierzytelnienia z
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
8
dokładnością do 1 sekundy, wprowadzony identyfikator użytkownika, adres IP komputera z którego wykonano próbę uwierzytelniania, rezultat procedury uwierzytelniania oraz autoryzacji (przyznanie lub odmowa dostępu z informacją o przyczynie odrzucenia)
WYM.OPZ.BEZ.26
Zarządzanie
uprawnieniami
W systemie e-Krew musi istnieć możliwość utworzenia kont administratorów regionalnych dla RCKIK, odpowiedzialnych za tworzenie kont i zarządzanie uprawnieniami operatorów pracujących tylko w jednostkach CKIK, OT, PWDL, PCK w danym regionie. Konta i role użytkowników będą obsługiwane przez platformę e-Krew.
WYM.OPZ.BEZ.27
Nieudane próby
logowania i dostępu
System e-Krew musi umożliwiać rejestrację nieudanych prób logowania oraz prób nieautoryzowanego dostępu.
WYM.OPZ.BEZ.28
Konsola administracyjna
System e-Krew musi posiadać konsolę administratora umożliwiającą z jednego miejsca zarządzanie użytkownikami, uprawnieniami i konfiguracją systemu.
WYM.OPZ.BEZ.29
Logi administracyjne
System musi posiadać log dla użytkowników z uprawnieniami administracyjnymi
WYM.OPZ.BEZ.30
Protokoły
komunikacyjne
System e-Krew zapewnia realizację usług przez umieszczanie i odbieranie dokumentów elektronicznych w formacie XML w strukturach i formatach umożliwiających komunikację pomiędzy systemami teleinformatycznymi, z wykorzystaniem protokołów komunikacyjnych i szyfrujących, o których mowa w art. 13 ust. 2 pkt 2 lit. a ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz. U. z 2013 r. poz. 235). System eKrew musi umożliwiać przesyłanie pomiędzy nim i systemami LSI dokumentacji medycznej (np. wyniki badań) zgodnie ze standardem HL7 CDA.
WYM.OPZ.BEZ.31 Podpis
dokumentów w
systemie
Dokumenty elektroniczne ewidencjonowane w systemie e-Krew (np. wyniki badań), podpisane powinny być bezpiecznym podpisem elektronicznym w rozumieniu art. 3 pkt 2 ustawy z dnia 18 września 2001 r. o podpisie elektronicznym (Dz. U. z 2013 r. poz. 262) albo potwierdzonym profilem zaufanym ePUAP w rozumieniu art. 3 pkt 15 ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne.
WYM.OPZ.BEZ.32
Zarządzanie
uprawnieniami
Wymagane jest aby dokumentacja zawierała dokładny wykaz uprawnień z opisaniem czynności, zadań lub transakcji jakie mogą być wykonane. W przypadku ról kompleksowych należy jednoznacznie opisać uprawnienia osobno dla każdej roli.
WYM.OPZ.BEZ.33
Zarządzanie
System powinien posiadać mechanizm uprawnień oparty na rolach (tzw. Role Base Acccess Control – RBAC).
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
9
uprawnieniami
WYM.OPZ.BEZ.34
Zarządzanie
uprawnieniami
Role nie powinny być przypisywane bezpośrednio konkretnym osobom lecz uprawnienia powinny być grupowane w zbiory przypisane do ról w systemie.
WYM.OPZ.BEZ.35
Zarządzanie
uprawnieniami
W systemie nie mogą istnieć nieudokumentowane w dokumentacji konta techniczne. Jeśli usunięcie zbędnych kont nie jest możliwe, muszą one zostać zablokowane. Konieczne do poprawnego działania systemu konta techniczne powinny mieć przyznany minimalny wymagany zakres uprawnień (np. konto w bazie danych wykorzystywane jedynie do wyświetlania informacji powinno mieć wyłącznie uprawnienia do odczytu, wyłącznie do niezbędnych tabel).
WYM.OPZ.BEZ.36
Zarządzanie
uprawnieniami
Wszystkie domyślne hasła kont technicznych muszą zostać zmienione.
WYM.OPZ.BEZ.37
Zarządzanie
uprawnieniami
Do systemu musi zostać dołączona procedura zmiany haseł wszystkich kont technicznych.
WYM.OPZ.BEZ.38
Zarządzanie
uprawnieniami
System musi umożliwiać zdefiniowanie daty wygaśnięcia ważności konta użytkownika. Po przekroczeniu daty wygaśnięcia, konto musi być przez system automatycznie blokowane
WYM.OPZ.BEZ.39
Zarządzanie
uprawnieniami
System nie powinien umożliwiać usuwania kont z którymi powiązane są jakiekolwiek dane. Jeżeli w systemie jest taka funkcjonalność, powinna ona być zablokowana.
WYM.OPZ.BEZ.40
Zarządzanie
uprawnieniami
W systemie musi istnieć możliwość trwałego zablokowania konta. Funkcja ta powinna być używana zamiast funkcji usuwania kont.
WYM.OPZ.BEZ.41
W systemie powinien funkcjonować mechanizm powodujący zakończenie lub zablokowanie sesji w przypadku nieaktywności użytkownika przekraczającej 15 minut (parametr konfigurowalny). W przypadku sesji Administratora, zamykanie lub blokowanie sesji musi następować po 5 minutach nieaktywności (parametr konfigurowalny).
WYM.OPZ.BEZ.42 System nie może wyświetlać w sposób czytelny (np. na ekranie monitora itp.) wprowadzanych haseł lub numerów PIN.
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
10
WYM.OPZ.BEZ.43 W przypadku nieudanej próby uwierzytelnienia system nie może informować użytkownika o tym, które wprowadzone przez niego dane są niepoprawne (powinien jedynie wyświetlić ogólny komunikat mówiący o nieudanym logowaniu, bez podawania przyczyny).
WYM.OPZ.BEZ.44 W przypadku, gdy wymagane jest uwierzytelnianie na poziomie integracji WebServices powinno być ono realizowane zgodnie z WS Basic Security Profile Version 1.0
WYM.OPZ.BEZ.45 W przypadku przetwarzania danych osobowych System, musi rejestrować następujące informacje: czas przetwarzania (odczytu/modyfikacji/usuniecia/wydruku) z dokładnością do 1 sekundy, identyfikator użytkownika dokonującego przetwarzania, identyfikator przetwarzanego rekordu.
WYM.OPZ.BEZ.46 W przypadku gdy System umożliwia masowy eksport, możliwość ta powinna być ograniczona do jak najmniejszej ilości pracowników. Jeżeli to możliwe i rozsądne, powinna istnieć osobna rola związana z masowym eksportem danych
WYM.OPZ.BEZ.47
Zgodność
System musi być zgodny ze standardem bezpieczeństwa aplikacji OWASP TOP 10 (aktualne wydanie).
WYM.OPZ.BEZ.48
W przypadku serwisu WWW WYMAGANA jest obsługa dedykowanych ekranów dla kodów http 4xx i 5xx
WYM.OPZ.BEZ.49
Dokumentacja
Wykonawca zobowiązany jest do dostarczenia dokumentacji dla administratora wraz z opisem procedur instalacji, aktualizacji bądź przywrócenia Systemu
3. Dostępność
Wymaganie Opis wymagania
WYM.OPZ.DOS.NFN.01
Ciągłość pracy
System musi pracować w trybie 24x7 w obszarze dystrybucji krwi oraz w
obszarze rejestrowania się Dawcy przez Internet. W pozostałych
obszarach system powinien zachować ciągłość pracy w godzinach pracy
użytkowników systemu.
WYM.OPZ.DOS.NFN.09
Dostępność Systemu
System e-Krew może być niedostępny, w każdym roku świadczenia
Usług Gwarancyjnych, maksymalnie: 17 godzin 31 minut 53 sekundy, a
w miesiącu nie więcej niż 2 godziny.
WYM.OPZ.DOS.NFN.02
Lokalizacje
Architektura Systemu musi umożliwiać instalację Systemu w dwóch
lokalizacjach:
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
11
Wymaganie Opis wymagania
Centralnym Ośrodku Przetwarzania Danych (COPD),
Zapasowym Ośrodku Przetwarzania Danych (ZOPD).
WYM.OPZ.DOS.NFN.03
Przełączenie między
lokalizacjami
Przełączenie przetwarzania z COPD na ZOPD i odwrotnie musi być
możliwe bez utraty integralności danych oraz bez konieczności
dokonywania migracji.
WYM.OPZ.DOS.NFN.04
Czas przełączenia między
lokalizacjami
Konfiguracja systemu musi umożliwiać przełączenie ośrodków w czasie
nie dłuższym niż 60 minut. Procedura przełączania musi ograniczać do
minimum konieczność wpisywania danych przez Administratora
Systemu. Dopuszcza się jedynie podawanie danych uwierzytelniających
i wykonywanie wcześniej przygotowanych skryptów.
WYM.OPZ.DOS.NFN.05
Redundancja
System, w ramach jednego ośrodka, musi być zbudowany z elementów
redundantnych zapewniających automatyczne przejęcie funkcji
elementu, który uległ awarii. Takie przejęcie musi być niewidoczne dla
użytkowników korzystających z systemu.
Elementy redundantne muszą być wykorzystywane przy normalnym
działaniu systemu do obsługiwania części obciążenia.
WYM.OPZ.DOS.NFN.06
Wielodostęp
System musi umożliwiać wielu użytkownikom równoległy dostęp do
tych samych danych lub obszarów funkcjonalnych bez utraty
integralności danych.
WYM.OPZ.DOS.NFN.07
Wznawianie pracy po
awarii
System musi udostępniać mechanizmy wznawiające pracę systemu po
awarii. W szczególności musi być możliwe selektywne uruchamianie
usług biznesowych.
WYM.OPZ.DOS.NFN.08
Wpływ awarii
System musi zapewniać, w ramach jednego ośrodka, że awaria jednego
elementu nie powoduje niedostępności usługi, a jedynie spadek
wydajności. Warunek ten nie musi zostać spełniony, jeżeli awarii ulega
ostatni element danego typu.
WYM.OPZ.DOS.NFN.09
Ciągłość działania
Dla procesów realizowanych przez system e-Krew Wykonawca powinien opracować Plan Ciągłości Działania oraz Disaster Recovery.
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
12
4. Skalowalność
Wymaganie Opis wymagania
WYM.OPZ.SKA.NFN.01
Liniowość skalowania
System musi zapewnić możliwość zbliżonego do liniowego skalowania
poziomego, względem:
maksymalnego wolumenu obsługiwanych operacji w jednostce
czasu,
ilości przetwarzanych i zgromadzonych danych,
liczby jednocześnie pracujących użytkowników.
Powyższe może zostać zrealizowane przy pomocy klastrowania, bądź
innych mechanizmów.
WYM.OPZ.SKA.NFN.02
Skalowalność bez zmian
w kodzie
System musi zapewniać możliwość skalowalności poprzez dodawanie
kolejnych węzłów w poszczególnych warstwach (scale out) wymagającą
co najwyżej instalacji oprogramowania i zmiany parametrów
konfiguracyjnych, bez konieczności zmian kodu oprogramowania.
WYM.OPZ.SKA.NFN.03
Skalowalność zasobów
sprzętowych
Zasoby sprzętowe dostarczone w ramach systemu muszą umożliwiać
rozbudowę poprzez dodawanie kolejnych elementów, np. dodatkowej
pamięci, dodatkowych dysków, procesorów itp.
WYM.OPZ.SKA.NFN.04
Skalowalność bez
wpływu na
użytkowników
Operacje rozszerzania systemu o kolejne serwery lub inne elementy nie
mogą wymagać zatrzymania systemu lub spadku jego wydajności
zauważalnego przez użytkowników systemu.
WYM.OPZ.SKA.NFN.05
Load-balancing
Architektura rozwiązania musi umożliwiać wykorzystanie mechanizmu
równoważenia obciążenia (load balancing) przy zastosowaniu więcej niż
1 serwera.
WYM.OPZ.SKA.NFN.06
Skalowalność
bezpieczeństwa
Mechanizmy bezpieczeństwa muszą zapewniać możliwość rozwoju
i skalowania w przyszłości, wraz z rozwojem usług realizowanych przez
System e-Krew.
5. Standardy
Wymaganie Opis wymagania
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
13
Wymaganie Opis wymagania
WYM.OPZ.STA.NFN.01
Neutralność
technologiczna
System e-Krew będzie wykonany przy zachowaniu zasady neutralności
technologicznej, bazującej na stosowaniu otwartych standardów (w ich
aktualnej wersji) wszędzie tam, gdzie są one dostępne, a ich
zastosowanie jest uzasadnione ekonomicznie. Warunki, jakie powinien
spełniać standard otwarty, określają zalecenia zawarte w European
Interoperability Framework (EIF) w wersji 2.0.
WYM.OPZ.STA.NFN.02
SOAP
System musi zapewnić wsparcie dla standardu przesyłania komunikatów
SOAP z załącznikami (z kodowaniem komunikatów: "document/literal")
w wersji 1.1 lub wyższej (http://www.w3.org/TR/soap/)
WYM.OPZ.STA.NFN.03
WSDL
Do opisu struktury i semantyki serwisu sieciowego (web service) musi
zostać wykorzystany standard WSDL w wersji 1.X lub wyższej
(http://www.w3.org/TR/wsdl20/)
WYM.OPZ.STA.NFN.04
MTOM
W sytuacji, w której jest to uzasadnione (w szczególności podczas
przesyłania załączników binarnych) do optymalizacji transportu danych
w oparciu o protokół SOAP i technologię usług sieciowych będzie
zastosowany standard MTOM (www.w3.org/TR/soap12-mtom)
WYM.OPZ.STA.NFN.05
Standardy web service
System musi być zgodny z następującymi standardami w zakresie
udostępnianych przez niego usług (web service):
WS-I Basic Profile w wersji 1.2 lub wyższej,
WS-Policy w wersji 1.5 lub wyższej,
WS-Security w wersji 1.1 lub wyższej,
WS-Addressing.
WYM.OPZ.STA.NFN.06
XML Schema
Do opisu struktur danych składowanych w formacie XML należy
stosować standard XML Schema (http://www.w3.org/XML/Schema)
WYM.OPZ.STA.NFN.07
PKI
Wykorzystanie certyfikatów klucza publicznego musi uwzględniać:
PKCS#1 - RSA Encryption Standard Version 2.1
PKCS#7 - Cryptographic Message Syntax Version 1.5
PKCS#10 – Certification Request Syntax Standard, version 1.7.
PKCS#11 - Cryptographic Token Interface Standard, version
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
14
Wymaganie Opis wymagania
2.20
PKCS#12 - Personal Information Exchange Syntax Standard,
version 1.0
RFC 3280 - Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
15
6. Wydajność
Wymaganie Opis wymagania
WYM.OPZ.WYD.NFN.01
Wymagana wolumetria
Wykonawca zobowiązany jest do wytworzenia i wdrożenia Systemu e-
Krew w sposób pozwalający na obsługę ruchu o wolumetrii opisanej
w sekcji 8.
WYM.OPZ.WYD.NFN.02
Optymalizacja
algorytmów
Dostawca dołoży wszelkich starań, by zastosowane przez niego
algorytmy były optymalne z punktu widzenia wydajności, zajętości
pamięci, zajętości przestrzeni dyskowej oraz ilości informacji przesyłanej
przez sieć.
WYM.OPZ.WYD.NFN.03
Optymalizacja w wyniku
testów
Wykonawca zobowiązuje się dokonać niezbędnej optymalizacji systemu
w przypadku wykrycia i wskazania przez Zamawiającego na etapie
testów funkcjonalności realizowanej z niewystarczającą wydajnością.
7. Wymagania dot. architektury
Wymaganie Opis wymagania
WYM.OPZ.ARC.NFN.01
Zmiany architektury
Architektura Systemu e-Krew musi zapewniać elastyczność i możliwość
łatwego dostosowania w przypadku zmian w organizacji systemu
ochrony zdrowia oraz innych zmian (legislacyjnych, zmian w otoczeniu
projektu, w systemach interesariuszy).
Założenia te muszą zostać odzwierciedlone w rozbudowanych
możliwościach konfiguracyjnych rozwiązania.
WYM.OPZ.ARC.NFN.02
Organizacja informacji
System e-Krew musi pozwalać na taką organizację informacji, która
pozwoli na ograniczenie redundancji danych oraz umożliwi
wykorzystanie danych dostępnych w ramach usług biznesowych,
ograniczając konieczność ich powtórnego ich wprowadzania.
WYM.OPZ.ARC.NFN.03
SOA
Architektura Systemu e-Krew musi zostać zaprojektowana
i zrealizowana z paradygmatem architektury zorientowanej na usługi
(SOA). Podstawowym założeniem architektury musi być udostępnienie
funkcjonalności Systemu w postaci usług dostarczanych do wszystkich
interesariuszy projektu.
WYM.OPZ.ARC.NFN.04
Udostępnianie usług
Wszystkie usługi Systemu e-Krew udostępniane na zewnątrz muszą być
udostępniane za pomocą API.
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
16
Wymaganie Opis wymagania
WYM.OPZ.ARC.NFN.05
Ograniczenie zmian w
rejestrach źródłowych
Architektura Systemu e-Krew musi zostać zaprojektowana w sposób,
który ograniczy do minimum konieczność zmian w rejestrach
źródłowych.
WYM.OPZ.ARC.NFN.06
Buforowanie danych
Architektura Systemu e-Krew musi zapewnić możliwość buforowania
danych do czasu zapisania i wysłanie ich po powtórnym nawiązaniu
łączności w przypadku problemów z połączeniem.
WYM.OPZ.ARC.NFN.07
Synchroniczny tryb
komunikacji
Architektura rozwiązania musi umożliwić komunikację z systemami
zewnętrznymi w trybie synchronicznym.
WYM.OPZ.ARC.NFN.08
Zarządzanie fizycznym
rozłożeniem danych
Podsystem powinien posiadać mechanizmy zarządzające optymalnym
rozłożeniem danych na dyskach, w celu uzyskania lepszej wydajności
rozwiązania.
WYM.OPZ.ARC.NFN.09
Replikacja między
ośrodkami przetwarzania
Architektura musi uwzględniać replikację danych pomiędzy COPD
a ZOPD, tak aby dane, przekazywane do Systemu e-Krew były
zapisywane w dwóch ośrodkach przetwarzania danych.
WYM.OPZ.ARC.NFN.10 Weryfikacja podpisu złożonego przy pomocy Profilu Zaufanego musi
zostać zrealizowana z wykorzystaniem funkcjonalności Profilu
Zaufanego.
8. Założenia wydajnościowe
W poniższym rozdziale zawarto opis założeń wydajnościowych i wolumetrycznych jaki należy przyjąć dla wymiarowania Systemu e-Krew.
Usługa Liczba
WYM.WYD.ARC.NFN.001 – Potencjalna liczba użytkowników systemu e-Krew (wg.
Danych z 2015roku).
630 000
WYM.WYD.ARC.NFN.002 – Liczba potencjalnych jednostek w których pracownicy
powinni posiadać dostęp do systemu
Około 1000
WYM.WYD.ARC.NFN.003 – Liczba potencjalnych pracowników pracujących w około 5000
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
17
Usługa Liczba
jednostkach które powinny posiadać dostęp do procesów obsługowych
WYM.WYD.ARC.NFN.004 – średnia roczna liczba donacji obsługiwanych przez
system e-Krew (liczba może rosnąć w czasie)
1 300 000
WYM.WYD.ARC.NFN.005 – średnia liczba jednostek krwi i jej składników
wydawanych do lecznictwa w ciągu roku
1 600 000
WYM.WYD.ARC.NFN.006 – średnia liczba jednostek PWDL przetaczających krew Około 900
WYM.WYD.ARC.NFN.007 – Szacowania minimalna liczba operatorów PWDL
wykorzystujących system e-Krew do obsługi zamówień na krew i jej składniki
Około 3000
WYM.WYD.ARC.NFN.008 – Liczba dawców zarejestrowanych w aktualnym Rejestrze
Dawców
Około 3 300 000
WYM.WYD.ARC.NFN.009 – Szacunkowa minimalna liczba operatorów w
regionalnych i resortowych CKiK
4000
WYM.WYD.ARC.NFN.010 – Liczba wyjazdów ekip wyjazdowych (dane za 2015rok) 13 694
WYM.WYD.ARC.NFN.011 – Sumaryczna maksymalna liczba pobranych w ciągu
jednego dnia donacji (dane z ostatnich 12-miesięcy) we wszystkich CKiK, OT i
ekipach wyjazdowych
9 300
WYM.WYD.ARC.NFN.012 – Sumaryczna maksymalna liczba zamówień w ciągu
jednego dnia (dane z ostatnich 12-miesięcy) we wszystkich CKiK
3 100
WYM.WYD.ARC.NFN.013 – Brak ograniczeń technologicznych na ilość gromadzonych
danych, zarejestrowanych użytkowników systemu (z ramienia CKiK i PWDL),
Dawców, czy liczbę użytkowników systemu będących jednocześnie online
Skalowalność systemu
WYM.WYD.ARC.NFN.014 – Średni czas odpowiedzi systemu na operację wyzwoloną
przez użytkownika (zapis formularza, wyświetlenie rekordów itp.). Wyłączenie
stanowią raporty generowane przez system cyklicznie i na żądanie użytkownika.
Maksymalnie 1 sekunda
9. Założenia technologiczne
W poniższym rozdziale zawarto opis założeń technologicznych jaki należy przyjąć dla wymiarowania Systemu e-Krew.
Opis Technologia
WYM.TECH.ARC.NFN.001 - Baza danych PostgreSQL lub EDB
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
18
WYM.TECH.ARC.NFN.002 – System operacyjny dla serwerów aplikacyjnych
CentOS min w wersji 7
WYM.TECH.ARC.NFN.003 – System Operacyjny dla serwerów bazodanowych
CentOS min w wersji 7
WYM.TECH.ARC.NFN.004 – Serwer aplikacyjny WildFly w wersji co najmniej 11
WYM.TECH.ARC.NFN.005 – Język programowania dla backendu Java EE w wersji co najmniej 8
WYM.TECH.ARC.NFN.006 – narzędzie automatyzujące budowanie oprogramowania
Maven
WYM.TECH.ARC.NFN.007 – Technologie frontendowe HTML5/CSS3/JS
WYM.TECH.ARC.NFN.008 – platforma do tworzenia, wdrażania i uruchamiania aplikacji
Docker CE, HAProxy, Kubernates
WYM.TECH.ARC.NFN.009 – Integracja z następującymi narzędziami monitorującymi
Zabbix, ELK
WYM.TECH.ARC.NFN.010 – Środowisko wirtualizacyjna Vmware vSphere Standard
2 Architektura Aplikacji Platforma E-krew zostanie zrealizowana w architekturze centralnej, klient-serwer. Dostęp użytkowników do Platformy odbywać się będzie przy pomocy cienkiego klienta oraz poprzez Web Service’y. Poniższy obraz obrazuje główne elementy i otoczenie Platformy.
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
19
Platfromę możemy podzielić na 3 klasy oprogramowania:
Oprogramowanie pozwalające na udostępnianie e-usług dla dawców, kandydatów na dawców, CKiK
oraz podmiotów wykonujących działalność leczniczą (kolor pomarańczowy);
Wartstwę integracyjną z innymi e-usługami oraz systemami (kolor zielony);
Hurtownię danych(kolor czerwony).
Dodatkowo na powyższym obrazie umiejscowione zostały e-usługi i systemy zewnętrzne z którymi platforma będzie wymieniać dane. Część pomarańczowa została podzielona na mniejsze moduły, których głównymi zadaniami będą:
a) Portal e-Krew: moduł będzie odpowiedzialny za udostępnienie graficznego interfejsu użytkownika GUI
dla:
a. Dawców oraz kandydatów dla dawców w celu umówienia się na wizytę w wybranym oddziale
RCKiK, uzyskania zaświadczenia do Urzędu Skarbowego, uzyskanie informacji o
przeprowadzonych badaniach oraz złożeniu deklaracji o wycofaniu donacji.
b. Podmiotów wykonujących działalność leczniczą w celu uruchomienia procedury zamówienia
krwi oraz jej składników.
b) Moduł wsparcia procesów biznesowych, który będzie miał zaimplementowane wszelkie procesy
funkcjonalne niezbędne do obsługi funkcjonalności Portalu e-Krew.
c) Rejestry:
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
20
a. Kartoteka dawców opisująca:
i. Historę donacji;
ii. Kwestionariusze przekazane przez dawców i kandydatów na dawców;
iii. Dane o reakcjach niepożądanych w trakcie i po donacji;
iv. Wyniki badań immunohematologicznych i wirusoligicznych;
v. Oznaczenie dawców o rzadkich grupach krwi;
vi. Dane o dyskwalifikacjach dawców i kandydatów na dawców.
b. Kartoteka donacji posiadająca dane o:
i. Informacje o stanach magazynowych krwi i jej składników w poszczególnych centrach;
ii. Zamówienia na krew i jej składniki od podmiotów wykonujących działalność leczniczą;
iii. Elementy książki transfuzyjnej;
iv. Informacje związane z karencjonowaniem osocza.
Połączenie systemu e-Krew z innymi systemami wykonywane będzie przez warstwę integracyjną.. Integracja systemów zewnętrznych odbywać się będzie poprzez API/WebService. W ramach projektu zostanie zbudowana integracja z systemami Centrów Krwiodawstwa i Krwiolecznictwa oraz Insytytutu Hematologii i Transfuzjologii. W ramach prac projektowych należy wybrać i wdrożyć odpowiednie mechanizmy cache’ujące – wybór mechanizmu należy ustalić z Zamawiającym. W trakcie analizy wstępnej oszacowano następujące parametry mające wpływ na wydajność powstającego systemu:
Usługa Liczba
Potencjalna liczba użytkowników systemu e-Krew (wg. Danych z 2015roku). 630 000
Liczba potencjalnych jednostek w których pracownicy powinni posiadać
dostęp do systemu
Około 1000
Średnia roczna liczba donacji obsługiwanych przez system e-Krew (liczba
może rosnąć w czasie)
1 300 000
Średnia liczba jednostek krwi i jej składników wydawanych do lecznictwa w
ciągu roku
1 600 000
Średnia liczba jednostek PWDL przetaczających krew Około 900
Szacowania minimalna liczba operatorów PWDL wykorzystujących system e-
Krew do obsługi zamówień na krew i jej składniki
Około 3000
Liczba dawców zarejestrowanych w aktualnym Rejestrze Dawców Około 3 300 000
Szacunkowa minimalna liczba operatorów w regionalnych i resortowych CKiK 4000
Liczba wyjazdów ekip wyjazdowych (dane za 2015rok) 13 694
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
21
Usługa Liczba
Sumaryczna maksymalna liczba pobranych w ciągu jednego dnia donacji
(dane z ostatnich 12-miesięcy) we wszystkich CKiK, OT i ekipach
wyjazdowych
9 300
Sumaryczna maksymalna liczba zamówień w ciągu jednego dnia (dane z
ostatnich 12-miesięcy) we wszystkich CKiK
3 100
Brak ograniczeń technologicznych na ilość gromadzonych danych,
zarejestrowanych użytkowników systemu (z ramienia CKiK i PWDL),
Dawców, czy liczbę użytkowników systemu będących jednocześnie online
Skalowalność systemu
Średni czas odpowiedzi systemu na operację wyzwoloną przez użytkownika
(zapis formularza, wyświetlenie rekordów itp.). Wyłączenie stanowią raporty
generowane przez system cyklicznie i na żądanie użytkownika.
Maksymalnie 1
sekunda
Dodatkowo na etapie projektowania i wytwarzania oprogramowania (w szczególności projektowania bazy danych) należy uwzględnić następujące szacunki dotyczące wolumetrii danych:
Baza danych Liczba
rekordów
rocznie
Skumulowana
liczba
rekordów do
roku 2021
Wielkość
rekordu
Szacowany
wolumen
danych w roku
2021
Kartoteka dawców 2,8 mln 2,8 mln1 10 KB 27 GB
Kartoteka biorców 0,9 mln 2,7 mln 10 KB 27 GB
Kartoteka donacji – baza donacji 1,3 mln 3,9 mln 10 KB 37 GB
Kartoteka donacji – baza
wytworzonych jednostek krwi
2,5 mln 7,5 mln 10 KB 72 GB
2.1 Technologie
W trakcie uzgodnień projektowych założono że aplikacja będzie wykorzystywała następujące technologie wykonania aplikacji.
Standard Zakres użycia
1 Przyjęto założenie, iż zarejestrowanymi dawcami są te same osoby, podczas gdy biorcami są różne osoby z całego
społeczeństwa. Dlatego liczba rekordów kartoteki dawców nie zmienia się w czasie, podczas gdy liczba rekordów
kartoteki biorców rośnie z upływem lat.
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
22
PostgreSQL Baza danych
CentOS w wersji min 7 System Operacyjny dla serwerów aplikacyjnych i bazodanowych
WildFly w wersji co najmniej 11 Serwer aplikacyjny
Java EE w wersji co najmniej 8 Język programowania dla backendu
Maven Narzędzie automatyzujące budowanie oprogramowania
HTML5/CSS3/JS Technologie służące do budowy frontendu.
Docker CE Platforma do tworzenia, wdrażania i uruchamiania aplikacji
HAProxy Reverse proxy
Kubernetes Platforma do zarządzania i skalowania kontenerami
Zabbix, ELK Możliwość integracji z wymienionymi narzędziami monitorującymi
Vmware vSphere Standard System Operacyjny przeznaczony do wirtualizacji
2.2 Systemy zewnętrzne
Opis systemu w podziale na systemy zewnętrzne/współdzielone.
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
23
Opis każdego komponentu na diagramie i zakres jego wykorzystania:
Nazwa Rola w systemie Zakres wykorzystania
ePuap Uwierzytelnianie użytkowników
Uwierzytelnianie użytkowników w systemie e-Krew
Systemy CKiK Wsparcie realizacji e-usług
Obsługa procesów biznesowych po stronie CKiK
Systemy IHiT Wsparcie realizacji e-usług
Obsługa procesów biznesowych po stronie IHiT
System Monitorowania Zagrożeń
Wymiana danych o zarażonych chorych
Informowanie Systemu e-Krew i SMZ o osobach, które sa zarażone między innymi HIV, WZW
Systemy PWDL Wsparcia pracy PWDL Wystawienie jednolitego API dla wszystkich systemów PWDL, dzięki czemu PWDL będą mogły zamawiać krew, powiadamiać o niepożądanych zdarzeniach/reakcjach oraz uzyskać informacje w ramach procedury „look back”
Hurtownia danych P1 Gromadzenie danych raportowych, tworzenie raportów
Gromadzenie danych z systemu oraz tworzenie raportów określonych przez Partnerów.
2.3 Perspektywy systemu
[Zawiera odwołanie do komponentów z punktów powyżej oraz opis słowny do każdej perspektywy. Dodatkowo dla każdej perspektywy przedstawiamy tabelę lub diagram. Tabela zawiera opis danego aspektu dla komponentów systemu. Tabela może nie być kompletna – w tym znaczeniu, że niektóre zagadnienia są rozstrzygane na poziomie Projektu Technicznego.] Szczegółowy opis systemu w podziale na perspektywy znajdzie się w Projekcie Technicznym.
2.3.1 Perspektywa danych
[Specyficzne formaty pośrednie i sposób składowania danych, które nie wynikają wprost z wymagań funkcjonalnych stosowane w systemie, np. pliki Excel, JPG, ZIP, XML, BLOB, plik tymczasowy, cache. [Rozdział powien opisywać przepływy danych, z otoczenia do aplikacji oraz wewnątrz aplikacji.] Jeśli cały system przechowuje tylko atomowe dane alfanumeryczne w relacyjnej bazie danych punkt może zostać pominięty.]
System / komponent Format/ struktura danych
Komentarz
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected] • www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP
24
2.3.2 Perspektywa dokumentów
[Zawartość analogiczna jak w punkcie „Perspektywa Danych” odnoszące się do dokumentów ]
System / komponent Format/ struktura danych
Komentarz
2.3.3 Perspektywa bezpieczeństwa – dostępy, protokoły
[Założenia ogólne w punktach]
np. oddzielenie ruchu z internetu od ruchu wewnętrznego
Stosowany model autoryzacji do funkcji użytkownika]
[Diagram obrazujący podane założenia ogólne lub alternatywnie opis w tabeli.]
System / komponent Aspekt bezpieczeństwa Komentarz
3 Specyficzne warunki i ograniczenia Specyficzne warunki i ograniczenia założeń architektonicznych.
3.1 Problemy i ograniczenia technologiczne w oprogramowaniu standardowym
[Tutaj należy wymienić znane ograniczenia i błędy związane z oprogramowaniem, które wpływają na wybór architektury. W przypadku gdy używane są nowe elementy stosu technologicznego należy określić ryzyko użycia.]
Opis problemu Alternatywa Szczegóły / Opis ryzyka
[Np Problem został zgłoszony do RedHat .. ]