Koncepcja Architektury - csioz.gov.pl · Koncepcja architektoniczna zawiera wszelkie wymagania dotyczące architektury systemu dla wytwarzanego oprogramowania. Dokument jest aktualizowany

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



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,



3


Mozilla Firefox w wersji aktualnej na moment rozpoczęcia

wytwarzania projektu wykonawczego i wyższych,

Google Chrome w wersji aktualnej na moment rozpoczęcia


Opera w wersji w wersji aktualnej na moment rozpoczęcia


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,



4


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.



5

2. Bezpieczeństwo


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



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.



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



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).



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.



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ść


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:



11


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.



12

4. Skalowalność


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




13


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

http://www.w3.org/TR/soap/



14


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



15

6. Wydajność


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


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.



16


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



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



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.



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:



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



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.



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.



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



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 .. ]

Documents

Koncepcja Architektury - csioz.gov.pl · Koncepcja architektoniczna zawiera wszelkie wymagania dotyczące architektury systemu dla wytwarzanego oprogramowania. Dokument jest aktualizowany