opis przedmiotu zamówienia ( OPZ )

Transkrypt

Załącznik 1.1 do SIWZ znak sprawy : ZZP – 126 / 14
OPIS PRZEDMIOTU ZAMÓWIENIA (OPZ)
dla systemu o nazwie HURTOWNIE do obsługi Departamentu Nadzoru
I.
Przedmiot zamówienia
Przedmiotem zamówienia jest wykonanie i wdrożenia systemu HURTOWNIE, którego głównym
zadaniem będzie wsparcie Departamentu Nadzoru w takich obszarach jak: gromadzenie informacji nt.
podmiotów gospodarczych, które związane są przede wszystkim z obrotem hurtowym produktami
leczniczymi oraz planowanie i przeprowadzanych inspekcji tych podmiotów.
W ramach realizacji Wdrożenia i jego poszczególnych, ujętych przedmiotowo części, Wykonawca
wykona wszystkie prace przewidziane dla danego Etapu, określone w OPZ a potem w przedłożonej
Ofercie i sprecyzowane w Projekcie Systemu, a w szczególności:
1. Wykonanie i dostarczenie Projektu Wdrożenia dla systemu HURTOWNIE wraz z
weryfikacją wymagań. Wykonawca, w celu weryfikacji procesów zachodzących w organizacji i
systemach Zamawiającego, przed rozpoczęciem procesu implementacji, przeprowadzi wywiady
analityczne z przyszłymi użytkownikami systemu. Na podstawie powyższego Wykonawca
przygotuje Projekt Wdrożenia dla systemu HURTOWNIE.
2. Dostarczenie licencji dostępowych User CAL SharePoint Server Standard 2013 w liczbie 11 szt.,
instalacja i konfiguracja środowiska dla systemu.
3. Implementacja i testy – wdrożenie Systemu HURTOWNIE. Testy powinny obejmować testy
wewnętrzne przeprowadzone tylko przez Wykonawcę oraz zewnętrzne przeprowadzane w
obecności Wykonawcy i Zamawiającego. Przed rozpoczęciem testów zewnętrznych Wykonawca
dostarczy scenariusze testów co najmniej na 2 tyg. przed planowanym rozpoczęciem testów i
przystąpi do ich wykonywania tylko w przypadku, gdy Zamawiający zaakceptuje scenariusze
testów.
4. Przeprowadzenie Szkoleń dla użytkowników Systemu HURTOWNIE, wskazanych przez
Zamawiającego. Na każde szkolenie Wykonawca zobowiązany jest do zapewnienia i
dostarczenia materiałów szkoleniowych (w wersji papierowej i elektronicznej) dla każdej
szkolonej
osoby.
Wykonawca
przeprowadzi
szkolenia
w
terminach
uzgodnionych
z
Zamawiającym (wynikających z harmonogramu) i w pomieszczeniach zapewnionych przez
Zamawiającego, wyposażonych w szczególności w stanowiska komputerowe, z dostępem do
sieci Zamawiającego i projektor.
5. Przeniesienie autorskich praw majątkowych - udzielenie licencji na oprogramowanie
wytworzone przez Wykonawcę oraz przeniesienie licencji dla oprogramowania firm trzecich, wraz
1
z przekazaniem Zamawiającemu nośników, a także kodów źródłowych do programów
komputerowych, na zasadach wskazanych we Wzorze Umowy, a w tym dostarczenie kompletu
licencji.
II.
Harmonogram realizacji zamówienia
Zamawiający określa 4 etapy realizacji zamówienia. Termin realizacji zamówienia określony został na 1
grudnia 2014r. Każdy z 4 etapów musi zakończyć się odbiorem wraz ze sporządzeniem odpowiedniego
protokołu odbioru zawierającym listę wykonanych czynności w trakcie danego etapu.
1. ETAP 1 - Wykonanie i dostarczenie Projektu Wdrożenia dla systemu HURTOWNIE.
2. ETAP 2 - Dostawa licencji dostępowych User CAL SharePoint Server Standard 2013, instalacja i
konfiguracja.
3. ETAP 3 - Implementacja i testy
4. ETAP 4 – Szkolenia
Wykonawca przedstawi haromonogram uwzględniający termin zakończenia realizacji zamówienia tj.
1 grudnia 2014r. Na odbiór etapów 1, 3 oraz obiór końcowy należy przewidzieć co najmniej 2
tygodnie. Przystąpienie do odbioru danego etapu może następować tylko wtedy, gdy zostały
wykonane wszystkie prace przewidziane w danym etapie. Wykonawca przedstawi harmonogram do
akceptacji Zamawiającemu przed podpisaniem umowy. Po zaakceptowaniu harmonogramu przez
Zamawiającego stanie się on załącznikiem do umowy. Zamawiający proponuje poniższy
harmonogram realizacji zamówienia:
tygodnie
Etap projektu
HURTOWNIE
Etap1: Projekt systemu i
weryfikacja wymagań
Odbiór etapu 1
1
2 3
4
5 6
7 8
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
Etap 2: Dostawa licencji,
instalacja i konfiguracja.
Odbiór etapu 2
Etap 3: Implementacja i
testy
Odbiór etapu 3
Etap 4: Szkolenia
Odbiór etapu 5
Odbiór końcowy
III.
Harmonogram płatności w ramach Zamówienia
2
Lp.
Etap
Ostateczny termin wykonania
Procent ceny całości wyłączając
etapu wraz z odbiorem
koszt licencji za oprogramowanie
wynikający z harmonogramu
firm trzecich
1.
Etap 1
10
2.
Etap 2
10
3.
Etap 3
20
4.
Etap 4
10
5.
Odbiór końcowy
50
Zapłata za każdy etap będzie następowała po zakończeniu danego etapu potwierdzonego protokołem
odbioru.
IV.
Warunki ogólne
1. Wdrażany System musi być zgodny z wymogami obowiązującymi przepisami prawa.
2. Rozwiązania wchodzące w skład Systemu powinny być zgodne z aktami prawnymi ogólnymi
stosowanymi w administracji rządowej oraz specyficznymi regulującymi pracę Głównego
Inspektoratu Farmaceutycznego a w szczególności z następującymi wymogami prawnymi:
a.
Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących
zadania publiczne (Dz. U. z 2013 poz. 235);
b.
Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram
Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w
postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz. U.
z 2012 poz. 526);
c.
Rozporządzenie Prezesa Rady Ministrów z dnia 14 września 2011 r. w sprawie
sporządzania pism w formie dokumentów elektronicznych, doręczania dokumentów
elektronicznych oraz udostępniania formularzy, wzorów i kopii dokumentów elektronicznych
(Dz. U. z 2011 nr 206, poz. 1216);
d.
Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 21 kwietnia 2011 r. w
sprawie szczegółowych warunków organizacyjnych i technicznych, które powinien spełniać
system teleinformatyczny służący do identyfikacji użytkowników (Dz. U. z 2011 nr 93, poz. 545);
e.
Ustawa z dnia 29 sierpnia 1997 o ochronie danych osobowych (Dz. U. z 2002 nr 101, poz.
926 ze zm.);
3
f.
Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w
sprawie 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 (Dz. U. nr 100, poz. 1024);
g.
Ustawa z dnia 6 września 2001r. Prawo farmaceutyczne (Dz.U. z 2008 nr 45 poz. 271 ze zm.);
3. Zamawiający posiada i dedykuje do wdrożenia systemu objętego niniejszym postępowaniem co
najmniej 2 serwery z infrastruktury wirtualnej VMWare o poniższych (nie gorszych niż wskazane
parametrach):
a.
Serwer Dell PowerEdge R420 1 procesor, 6 rdzeni 2,40 GHz, RAM: 48 GB, przestrzeń
dyskowa 1,6 TB z możliwością rozbudowy przez dołączenie macierzy iSCSI 2 TB, system
operacyjny Windows 2008 Standard.
b.
Serwer Dell PowerEdge R510 1 procesor, 6 rdzeni 2,67 GHz, RAM: 24 GB, przestrzeń
dyskowa 1,3 TB (wolne 500 GB) z możliwością rozbudowy przez dołączenie macierzy iSCSI
2 TB, system operacyjny Windows 2008 Standard.
4. Zamawiający posiada i dedykuje do tego rozwiązania instancję SQL Server 2008 Standard
zainstalowaną na maszynie wirtualnej osadzonej na serwerze o następujących parametrach: Dell
PowerEdge R510 1 procesor, 6 rdzeni 2,67 GHz, RAM: 24 GB, przestrzeń dyskowa 1,3 TB
(wolne 500 GB) z możliwością rozbudowy przez dołączenie macierzy iSCSI.
5. Zamawiający posiada i dedykuje do tego rozwiązania oprogramowanie SharePoint Server
Standard 2013.
6. System HURTOWNIE powinien posiadać możliwość integracji z elektroniczną Platformą Usług
Administracji Publicznej.
7. System musi być dostarczony wraz z kompletną i aktualną dokumentacją powdrożeniową
odpowiednią dla każdego założonego przez Zamawiającego Etapu. Struktura dokumentacji do
Systemu musi zostać przedstawiona w ramach Etapu 1.
8. System musi być dostarczony wraz z kompletną i aktualną dokumentacją procedur instalacji,
konfiguracji i parametryzacji, procedur tworzenia kopii bezpieczeństwa, procedur odzyskiwania
danych (w tym z kopii) i przywracania ich spójności, a także przywracania pełnej funkcjonalności
systemu
9. System musi posiadać pełną polskojęzyczną dokumentację w wersji elektronicznej pozwalającą
na samodzielną naukę obsługi każdego modułu.
10. Dopuszczalne jest by dokumentacja do systemu oraz bazy danych dla administratora była w
języku angielskim.
4
V.
Wymagania funkcjonalne
1. Wymagane jest aby System komunikował się z użytkownikiem w języku polskim i był
wyposażony w system podpowiedzi. W
przypadku oprogramowania narzędziowego i
administracyjnego dopuszczalna jest częściowa komunikacja w języku angielskim.
2. System musi być oparty o platformę Sharepoint Server Standard 2013, na którą Zamawiający
posiada licencję.
3. System
musi
posiadać
mechanizmy
skutecznie
ograniczające
ryzyko
wprowadzenia
nieprawidłowych danych.
4. System musi zapewniać wiele trybów obsługi wydruków wszystkie wydruki systemu mogą być
drukowane bezpośrednio lub mogą zostać zapisane do pliku w celu ewentualnego późniejszego
wydruku lub przesłania pocztą elektroniczną.
5. System musi zapewniać eksport każdego zestawienia do formatu MS Excel lub txt.
6. System musi być udostępniany w architekturze co najmniej trójwarstwowej: klient - serwer
aplikacji - serwer bazy
7. System powinien automatycznie umożliwiać pobranie danych nt. hurtowni farmaceutycznych,
składów konsygnacyjnych i składów celnych, ich komór przeładunkowych, zezwoleń i zmian
zezwoleń, podmiotów gospodarczych będących ich właścicielami oraz osób odpowiedzialnych z
systemu prowadzącego Rejestr Zezwoleń na Prowadzenie Hurtowni Farmaceutycznej zwanego
w skrócie Rejestrem Hurtowni Farmaceutycznych utrzymywanego przez Centrum Systemów
Informacyjnych Ochrony Zdrowia (rozwiązanie oparte o SharePoint). Część publiczna rejestru
dostępna pod adresem: http://rhf.rejestrymedyczne.csioz.gov.pl/_layouts/15/rhf/glowna.aspx.
Pobranie danych będzie następować co najmniej raz dziennie. Rozwiązanie to musi być oparte o
usługi webservices. Rejestr Hurtowni Farmaceutycznych będzie wywoływał webserwis, który
musi być wystawiony przez system HURTOWNIE. Webserwis będzie musiał obsługiwać co
najmniej 4 metody:
a. przyjęcie całej zawartości rejestru
b. modyfikacja hurtowni (zmiana atrybutów istniejącej hurtowni)
c. dodanie hurtowni
d. usuniecie hurtowni.
Dane pobierane z Rejestru Hurtowni Farmaceutycznych będą zawierały inicjalnie oraz w
przypadku awarii dane wszystkich dostępnych obiektów (hurtowni wraz z obiektami
powiązanymi). W kolejnych pobraniach będą znajdowały się dane tylko tych obiektów, które
5
uległy
zmianie
od
ostatniego
pobrania
(dodanie/zmiana/usunięcie
hurtowni).
System
HURTOWNIE powinien móc porównać dane przekazane z Rejestru Hurtowni Farmaceutycznych
z danymi istniejącymi w systemie HURTOWNIE i na ich podstawie zarejestrować historię zmian.
Ponieważ na poziomie Rejestru Hurtowni Farmaceutycznych nie jest planowane przekazywanie
dokładnej daty i godziny zmiany danych, system HURTOWNIE będzie musiał zarejestrować
informację o dacie i godzinie przekazania pełnego importu lub przekazania informacji o zmianie.
Historia zmian powinna uchwycić wartości każdego pola (atrybutu obiektu) oraz datę i godzinę
zmiany w opisany powyżej sposób. Historia zmian atrybutów powinna być łatwo dostępna do
przeglądania np. po kliknięciu przycisku przy danym polu formularza prezentującego określony
atrybut powinno pojawiać się dodatkowe okno prezentujące historię zmian. Dodatkowo powinno
być możliwe obejrzenie danych hurtowni wraz z obiektami powiązanymi z wartościami ich
atrybutów na dany dzień. Atrybuty obiektów pobranych z Rejestru Hurtowni Farmaceutycznych
nie powinny mieć możliwości ich edycji w systemie HURTOWNIE (dostęp tylko do odczytu).
8. We wdrażanym systemie należy utworzyć odpowiednie formularze w 2 wersjach językowych –
polskiej i angielskiej dla dokumentów takich jak Zezwolenie na prowadzenie hurtowni
farmaceutycznej / składu celnego / składu konsygnacyjnego (wzór w załączniku A do OPZ),
Certyfikat GDP(wzór w załączniku B do OPZ), raport z inspekcji GDP (wzór w załączniku C do
OPZ). Formularze powinny umożliwiać przechowywanie i modyfikację danych w nich zawartych.
Na podstawie danych zawartych w formularzach dot. Zezwolenia na prowadzenie hurtowni
farmaceutycznej / składu celnego / składu konsygnacyjnego, Certyfikacie GDP i Raporcie z
inspekcji GDP następować będzie wymiana z systemem zewnętrznym EudraGMDP. Narzędzie
dot. wymiany opisane zostało w rozdziale XI. Wymagania odnośnie aplikacji webowej – Obiekty
klasy <strona>” punkt 12. Strefa Narzędzi. Wzory ww. dokumentów znajdujące się w
załącznikach A, B, C do OPZ są obecnie w wersji angielskiej, tym nie mniej po rozpoczęciu
realizacji umowy przez Wykonawcę Zamawiający dostarczy niezwłocznie wersje polskojęzyczne.
Na podstawie danych zawartych w formularzach dot. Zezwolenia na prowadzenie hurtowni
farmaceutycznej / składu celnego / składu konsygnacyjnego, Certyfikacie GDP i Raporcie z
inspekcji GDP włączając części stałe tych dokumentów powinien być generowany podgląd
(widok) dokumentu, który zgodny jest z szablonami stosowanymi przez Zamawiającego. Podgląd
ten Zamawiający powinien móc wydrukować i podpisać ręcznie. Zawartość dokumentu powinna
być dobrze sformatowana i przygotowana do wydruku na papierze w formacie A4.
VI.
Wymagania dotyczące interfejsu, ergonomii i obsługi
1. System musi posiadać interfejs przeglądarkowy i być wspierany przez trzy najpopularniejsze
przeglądarki wg serwisu krajowego gemiusRanking (na dzień podpisania umowy).
2. System musi umożliwiać elastyczne filtrowanie informacji w widokach.
6
3. System musi posiadać możliwość wyszukiwania danych po różnych kryteriach i kluczach
wyszukiwania.
4. System musi umożliwiać dostęp do funkcji za pomocą klienta opartego o przeglądarkę
Internetową.
5. Interfejs użytkownika musi być ergonomiczny oraz intuicyjny z możliwością zarządzania polami
(dodawanie, modyfikowanie, usuwanie) i widokami przez użytkownika.
6. W przypadku istotnych operacji na danych (np. usuwanie danych) wymagana jest możliwość
potwierdzania zamiaru wykonania operacji ryzykownej.
7. System musi umożliwiać personalizację środowiska pracy z poziomu użytkownika
8. System musi umożliwiać podpowiedzi do wszystkich pól wskazanych przez Zamawiającego jako
pola wymagające podpowiedzi. Zamawiający powinien mieć możliwość zarządzania treścią
podpowiedzi i przypisywania podpowiedzi do pól.
9. System musi umożliwiać podpowiadania wartości domyślnych podczas wprowadzania danych we
wszystkich polach, gdzie Zamawiający uzna to za potrzebne.
10. System musi posiadać jednolitą warstwę graficzną, uporządkowane pola wraz z przyciskami,
opisami pól w ustalonej konwencji złożonej w ramach Projekcie Wdrożenia.
11. System musi posiadać jednolite działanie typowych funkcji takich jak: wyszukiwanie, filtrowanie,
przeglądanie, drukowanie, sortowanie itp.
12. System musi posiadać funkcjonalności/moduły administracyjne obejmujące:
a. analizę błędów i stanu konfiguracji systemu w obszarach: zabezpieczeń, wydajności,
konfiguracji i dostępności Systemu
b. Wykonywanie kopi zapasowych i przywracanie ich z poziomu Systemu wraz z
możliwością sprawdzania stanu zadań wykonywania i przywracania kopii zapasowych
VII.
Wymagania bazodanowe
1. Obiekty – Poniższy model danych opisuje kluczowe obiekty, które mają podlegać rejestracji
w Systemie. W trakcie przygotowywania założeń do przedmiotu Zamawiający zidentyfikował
następujące obiekty niezbędnych do zawarcia w ramach Systemu:
a. Certyfikat GDP
b. Decyzja
c. Dokument
d. Inspekcja (połączona z raportem z inspekcji oraz HDN)
7
e. Zabezpieczenie
f.
Inspektor
g. Komora przeładunkowa
h. Hurtownia
i.
Okres Zgłoszenia
j.
Osoba Odpowiedzialna
k. Podmiot
l.
Raport z inspekcji GDP
m. SMF Część Główna (SMF – Site Master File czyli Dokumentacja Główna Hurtowni)
n. SMF Podczęść
o. SMF Załącznik
p. Uwaga
q. Zezwolenie
2. Relacje
W trakcie przygotowywania założeń do przedmiotu zamówienia zostały zidentyfikowane
następujące relacje typu jeden do wielu:
Relacja_001
typ: jeden do kilka
Certyfikat GDP
dotyczy jednej
Hurtowni
Hurtownia
może mieć wiele
Certyfikatów GDP
Relacja_002
typ: jeden do wielu
dotyczy pojedynczej
Hurtowni
Hurtownia
może mieć wiele
Raportów z inspekcji GDP
Relacja_003
typ: jeden do wiele
Komora przeładunkowa
jest przypisana do jednej
Hurtowni
Hurtownia
może posiadać wiele
Komór przeładunkowych
Relacja_004
typ: jeden do wielu
Okres Zgłoszenia
dotyczy jednej
Osoby Odpowiedzialnej
może mieć wiele
Okresów Zgłoszeń
Relacja_005
typ: jeden do wiele
Okres Zgłoszenia
dotyczy jednej
Hurtowni
Z Hurtownią
może być związanych wiele
Okresów zgłoszeń
8
Relacja_006
typ: jeden do wielu
Decyzja
dotyczy jednej
Inspekcji
Z Inspekcją
może być związanych wiele
Decyzji
Relacja_007
typ: jeden do wiele
Hurtownia
jest przypisana do jednego
Podmiotu
Podmiot
Hurtowni
Relacja_009
typ: jeden do jeden
Hurtownia
może mieć jedną
SMF Części Głównej
dotyczy jednej
Hurtowni
Relacja_010
typ: jeden do jeden
SMF Załącznik
dotyczy jednej
SMF Podczęści
SMF Podczęści
ma wiele
SMF Załączników
Relacja_011
typ: jeden do wiele
SMF Podczęść
dotyczy jednego
ma wiele
SMF Podczęści
W trakcie przygotowywania założeń do przedmiotu zamówienia zostały zidentyfikowane również
inne zależności, w szczególności relacje jeden do jednego oraz relacje pośrednie (nazwane w
dalszej części konektorami lub kolekcjami):
HDN
dotyczy jednej
Inspekcji
Raport z Inspekcji
dotyczy jednej
Inspekcji
Dokument
dotyczy jednego
Podmiotu
dotyczy jednego
Podmiotu
Inspekcja
dotyczy jednego
Podmiotu
Zezwolenie
dotyczy jednego
Podmiotu
Certyfikat GDP
dotyczy jednego
Podmiotu
dotyczy jednego
Podmiotu
Decyzja
dotyczy jednego
Podmiotu
SMF Część Główna
dotyczy jednego
Podmiotu
Inspekcja
Ma jednego
Inspektora Wiodącego
9
Decyzja
dotyczy jednej
Hurtowni
Decyzja
dotyczy jednej
Komory przeładunkowej
SMF Załącznik
dotyczy jednego
Inspekcja
dotyczy jednej
Hurtowni
Hurtownia
Może mieć wiele
Inspekcji
Inspekcja
może dotyczyć wielu
Komór przeładunkowych
Może mieć wiele
Inspekcji
Inspekcja
może mieć wielu
Inspektorów Uczestniczących
Inspektorzy
Mogą uczestniczyć w wielu
Inspekcjach
Hurtownia
Dokumentów
Dokument
może dotyczyć wielu
Hurtowni
Hurtownia
Zezwoleń
Zezwolenie
dotyczy jednej
Hurtowni
może współpracować w różnym Podmiotami
Uczestniczący
czasie z wieloma
Podmiot
może w różnym czasie mieć Osób Odpowiedzialnych
wiele
Zabezpieczenie
dotyczy jednej
Hurtowni
Hurtownia
może mieć wiele
Zabezpieczeń
Powyższe założenia mogą się różnić od końcowych ustaleń w zależności od wyboru rozwiązania
projektowego. Dlatego należy wykonać szczegółową analizę na Etapie 1, która ustali finalnie
powyższe relacje.
3. Klasy
W trakcie przygotowywania założeń do przedmiotu zamówienia, dla poszczególnych klas
obiektów, zidentyfikowane zostały atrybuty.
Atrybuty oznaczone zostały:
- nazwą atrybutu,
- typem danych lub enumeracją
- jednym ze stereotypów (opcjonalnie)
a. typy danych
W trakcie przygotowywania założeń do przedmiotu zamówienia zidentyfikowanych zostało
siedem typów danych:
10
i.
typ logiczny:
boolean
ii.
typ daty:
date
iii.
typ liczbowy:
integer
iv.
typ stringowy:
string
v.
typ stringowy:
string_multiline
vi.
typ linkowy
hyperlink
vii.
typ plikowy
file
b. stereotypy
W trakcie przygotowywania założeń do przedmiotu zamówienia zidentyfikowane zostały cztery
stereotypy:
i. klucze główne, oznaczone w modelu stereotypem <<PrimaryKey>>
ii. klucze obce, oznaczone w modelu stereotypem <<ForeignKey>>
iii. wymagane przez Zamawiającego, na potrzeby widoków, połączenia oznaczone
stereotypem <<Konektor>> odwołujące się do pojedynczych, prostych do pozyskania
wartości, wynikających z relacji pośrednich
iv. kolejne wymagane przez Zamawiającego, na potrzeby widoków, połączenia umożliwiają
dokonywanie wyboru wielu elementów z listy; połączenia te zostały w modelu
oznaczone stereotypem <<Kolekcja>>. Część kolekcji związana jest relacjami typu
wiele do wielu i ich realizacja jest prosta. Część kolekcji odwołuje się do wyników innych
kolekcji lub do wartości konektorów co może prowadzić do komplikacji przy
wprowadzaniu danych do poszczególnych obiektów. Dokładniejsze wyjaśnienia na ten
temat znajdują się w części dokumentacji dotyczącej projektu aplikacji
c. enumeracje
W trakcie przygotowywania założeń zidentyfikowane zostały następujące enumeracje:
status_podmiotu
aktywny
z_cofnietym_zezwoleniem
wygaszony
status_hurtowni
oczekująca
aktywna
nieaktywna
unieruchomiona dec. GIF
delegatura_WIF
11
brak
Delegatura w Białej Podlaskiej
Delegatura w Chełmie
Delegatura w Ciechanowie
Delegatura w Elblągu
Delegatura w Ełku
Delegatura w Jeleniej Górze
Delegatura w Kaliszu
Delegatura w Koninie
Delegatura w Koszalinie
Delegatura w Krośnie
Delegatura w Legnicy
Delegatura w Lesznie
Delegatura w Łomży
Delegatura w Nowym Sączu
Delegatura w Ostrołęce
Delegatura w Piotrkowie Trybunalskim
Delegatura w Płocku
Delegatura w Przemyślu
Delegatura w Radomiu
Delegatura w Siedlcach
Delegatura w Sieradzu
Delegatura w Skierniewicach
Delegatura w Słupsku
Delegatura w Suwałkach
Delegatura w Tarnobrzegu
Delegatura w Tarnowie
Delegatura w Toruniu
Delegatura w Wałbrzychu
Delegatura w Zamościu
Delegatura w Zielonej Górze
Delegatura w Zielonej Górze
Delegatura we Włocławku
rodzaj_hurtowni
hurtownia
skład konsygnacyjny
skład_celny
12
rodzaj_inspekcji
Planowa inspekcja_ogólna_GDP
inspekcja_dorazna
inspekcja_wnioskowa_o_zmiane_zezwolenia /
inspekcja_wnioskowa_o_udzielenie_zezwolenia
inspekcja_wnioskowa_o_ udzielenie zezwolenia na obrót substancjami odurzającymi lub
psychotropowymi lub prekursorami kategorii pierwszej
inspekcja_wnioskowa_o_zmianę zezwolenia na obrót substancjami odurzającymi lub
psychotropowymi lub prekursorami kategorii pierwszej
inspekcja_wnioskowa_o_udzielenie_certyfikatu_GDP
wynik_inspekcji
wydanie_certyfikatu_GDP
udzielenie zezwolenia
zmiana zezwolenia
decyzja_o_usunieciu_uchybien
decyzja_o_unieruchomieniu
decyzja_o_cofnięciu_zezwolenia
inne
rodzaj_zezwolenia
zezwolenie_na_prowadzenie_obrotu_hurtowego
koncesja_na_prowadzenie_obrotu_hurtowego
Zezwolenie na prowadzenie obrotu hurtowego środkami odurzającymi oraz substancjami
psychotropowymi
Licencja na prowadzenie obrotu hurtowego prekursorem narkotycznym kategorii 1
rodzaj_decyzji
decyzja_o_usunieciu_uchybien
decyzja_o_unieruchomieniu
decyzja_o_cofnieciu_zezwolenia
decyzja_o_wydaniu_zezwolenia
decyzja_o_zmianie zezwolenia
decyzja o odmowie wydania zezwolenia
decyzja o odmowie zmiany zezwolenia
forma_prawna
13
Osoba fizyczna prowadząca działalność gospodarczą
Spółka cywilna
Spółka jawna
Spółka partnerska
Spółka komandytowa
Spółka komandytowo-akcyjna
Spółka z ograniczoną odpowiedzialnością
Spółka z ograniczoną odpowiedzialnością z udziałem jednostek samorządu terytorialnego
Spółka z ograniczoną odpowiedzialnością Spółka komandytowo-akcyjna
Spółka z ograniczoną odpowiedzialnością Spółka komandytowa
Spółka akcyjna
Spółka akcyjna z udziałem jednostek samorządu terytorialnego albo państwowej osoby prawnej
Spółdzielnia
SPZOZ
Inna instytucja lub osoba
Jednostka budżetowa
Instytut badawczy
Fundacja, stowarzyszenie
Inna krajowa lub zagraniczna osoba prawna lub osoba fizyczna oraz spółka prawa handlowego
nie mająca osobowości prawnej
Kościół lub związek wyznaniowy
organ_wydajacy
Główny Inspektor Farmaceutyczny
Minister Zdrowia
Minister Zdrowia i Opieki Społecznej
Naczelny Inspektor Farmaceutyczny
rodzaj_wyksztalcenia
Farmaceuta
lekarz weterynarii
inne wykształcenie
wyksztalcenie_inspektor
Farmaceuta
Informatyk
zakres_obrotu1
14
Produkty lecznicze
Gazy medyczne
zakres_obrotu2
Pełny
Ograniczony
zakres_obrotu_ograniczenia
wymagające przechowywania w temp. 2-8°C
o kategorii dostępności OTC
dopuszczone do sprzedaży w punktach aptecznych (zał. 1)
dopuszczone do sprzedaży w placówkach obrotu pozaaptecznego (zał. 2)
zawierające substancje bardzo silnie działające
ozpoczęcia cytostatyki
ozpoczęcia substancje wonne
ozpoczęcia substancje łatwopalne
ozpoczęcia substancje żrące
substancje farmaceutyczne
status_zezwolenia
Aktywne
Wygaszone
Cofnięte
Zawieszone
Powyższe listy enumeracji prezentują wstępnie ustalone przez Zamawiającego wartości. Listy
enumeracji muszą być łatwo edytowalne (dodawanie, usuwanie, modyfikowanie, zmienianie
kolejności
poszczególnych
pozycji
na
listach)
przez
upoważnionych
pracowników
Zamawiającego. Pracownicy Zamawiającego posiadający właściwe uprawnienia muszą mieć też
możliwość łatwego definiowania czy konkretna enumeracja dopuszcza wybór tylko jednej pozycji
z listy, czy umożliwia wybór wielu pozycji z listy oraz czy dopuszcza wprowadzanie wartości
innych niż wartości z listy.
d. atrybuty klas
Niżej zaprezentowane atrybuty klas należy zweryfikować podczas przygotowywania Projektu
Wdrożenia dla systemu HURTOWNIE.
Klasa Podmiot – obiekty pobierane z Rejestru Hurtowni Farmaceutycznych
15
<<PrimaryKey>>identyfikator_podmiotu:string
nazwa_ podmiotu:string
Imie_imiona:string
Nazwisko:string
forma_prawna:forma_prawna
numer_KRS:string
numer_NIP:string
numer_REGON:string
numer_PESEL:string
adres_ulica:string
adres_rodzj_ulicy:string
adres_nr_budynku:string
adres_nr_lokalu:string
adres_miejscowosc:string
adres_kod_pocztowy:string
adres_poczta:string
adres_wojewodztwo:string
kontakt_telefon:string
kontakt_strona_www:hyperlink
kontakt_email:string
kontakt_fax:string
uwagi:string_multiline
Klasa Dokument
<<PrimaryKey>>numer_dokumentu:string
<<Kolekcja>>kolekcja_identyfikatorow_hurtowni:string
<<Konektor>>identyfikator_podmiotu:string
<<Konektor>>nazwa_ podmiotu:string
data_powstania:date
tytul:string
znak:string
opis:string
plik_ze_skanem:file
rodzaj_dokumentu:string
Klasa Hurtownia – obiekty pobierane z Rejestru Hurtowni Farmaceutycznych
16
<<PrimaryKey>>identyfikator_hurtowni:string
<<ForeignKey>>identyfikator_podmiotu:string
<<Konektor>>nazwa_pelna_podmiotu:string
nazwa_hurtowni:string
adres_ulica:string
adres_poczta:string
adres_powiat:string
adres_gmina:string
dodatkowe informacje nt. lokalizacji pomieszczen:string_multiline
kontakt_strona_www:hyperlink
kontakt_fax:string
delegatura_WIF:delegatura_WIF
rodzaj_hurtowni:rodzaj_hurtowni
status_hurtowni:status_hurtowni
data_rozpoczecia_działalnosci_przez_hurtownie:date
data_unieruchomienia:date
data_ponownego_podjecia_dzialalnosci_po_unieruchomieniu:date
zakres_obrotu1:zakres_obrotu1
zakres_obrotu_ogranczenia: zakres_obrotu_ogranczenia
zakres_obrotu_ograniczenia_wpis_reczny:string_multiline
Klasa Komora Przeładunkowa – obiekty pobierane z Rejestru Hurtowni
Farmaceutycznych
<<PrimaryKey>>identyfikator_komory:string
<<ForeignKey>>identyfikator_hurtowni:string
17
nazwa_komory:string
adres_ulica:string
adres_poczta:string
adres_powiat:string
adres_gmina:string
dodatkowe informacje nt. lokalizacji pomieszczen:string_multiline
zakres_obrotu_ogranczenia: zakres_obrotu_ogranczenia
zakres_obrotu_ograniczenia_wpis_reczny:string_multiline
Klasa Inspekcja
<<PrimaryKey>>numer_inspekcji:string
<<Konektor>> identyfikator_hurtowni:string
<<Konektor>> identyfikator_komory_przeladunkowej:string
<<Kolekcja>>kolekcja_identyfikatorow_inspektorow_uczestniczacych:string
<<ForeignKey>>identyfikator_inspektora_wiodacego:string
rodzaj_inspekcji:rodzaj_inspekcj
data_rozpoczecia:date
data_zakonczenia:date
opis_inpekcji:string
substancje_kontrolowane:string
raport_numer_raportu:string
raport_wynik_inspekcji:wynik_inspekcji
raport_opis_wyniku_inspekcji:string
raport_pliki_ze_skanem:file
hdn_numer_harmonogramu:string
hdn_data_usuniecia_ostatniej_niezgodnosci:date
18
hdn_uwagi:string_multiline
hdn_plik_ze_skanem:file
Klasa Inspektor
<<PrimaryKey>>identyfikator_inspektora:string
imie:string
nazwisko:string
numer_legitymacji:string
wyksztalcenie_inspektor:wyksztalcenie_inspektor
Klasa osoba_odpowiedzialna – obiekty pobierane z Rejestru Hurtowni Farmaceutycznych
<<PrimaryKey>>identyfikator_osoby_odpowiedzialnej:string
Imie_imiona:string
nazwisko:string
rodzaj_wyksztalcenia:rodzaj_wyksztalcenia
uprawnienia_do_wziecia_odpowiedzialnosci_za_prowadzenie_hurtowni:boolean
numer_prawa_do_wykonywania_zawodu:string
uwagi:string
Klasa Okres_Zgloszenia – obiekty pobierane z Rejestru Hurtowni Farmaceutycznych
<<PrimaryKey>>numer_okresu:integer
<<ForeignKey>>identyfikator_osoby_wykwalifikowanej:string
<<ForeignKey>>identyfikator_podmiotu:string
<<Konektor>>nazwa_podmiotu:string
data_rozpoczecia_pelnienia_funkcji_od:date
data_rozpoczecia_pelnienia_funkcji_do:date
czy_jest_kierownikiem_hurtowni:boolean
kontakt_telefon_komorkowy:string
kontakt_fax:string
Klasa Zezwolenie – obiekty pobierane z Rejestru Hurtowni Farmaceutycznych
19
<<PrimaryKey>>numer_zezwolenia:string
<<Kolekcja>>kolekcja_identyfikatorow_miejsc:string
<<Konektor>>nazwapodmiotu:string
rodzaj_zezwolenia:rodzaj_zezwolenia
Sygnatura_sprawy:string
organ_wydający:organ_wydający
data_uprawomocnienia:date
data_wydania_decyzji:date
termin_waznosci:date
nr_dokumentu_cofnięcia_wygaszenia_zezwolenia:string
sygnatura_sprawy_dla_cofniecia_wygaszenia_zezwolenia:string
data_ cofniecia_zezwolenia:date
data_ wygaszenia_zezwolenia:date
data_uprawomocnienia_cofniecia_wygaszenia_zezwolenia:date
data_nadania_rygoru_natychmiastowej_wykonalności_dla_cofniecia_zezwolenia:date
status_zezwolenia:staus_zezwolenia
Komentarz_do_satusu:string
pliki_ze_skanami_zezwolenia:file
Klasa Zezwolenia musi, oprócz ww. przechowywać także
wszystkie informacje zawarte w zezwoleniu
Wzór zezwolenia znajduje się w załączniku A do OPZ
Klasa Certyfikat
<<PrimaryKey>>numer_certyfikatu:string
<<Konektor>>nazwa_hurtowni:string
ograniczenia_certyfikatu:string
organ_wydający: organ_wydajacy
data_wydania:date
plik ze skanem_certyfikatu:file
Klasa Certyfikat musi, oprócz ww. przechowywać także
wszystkie informacje zawarte w Certyfikacie GDP.
Wzór certyfikatu znajduje się w załączniku B do OPZ.
20
Klasa Raport_z_Inspekcji_GDP
<<PrimaryKey>>numer_raportu_z_inspekcji_GDP:string
<<Konektor>>nazwa_ odmiotu:string
organ_wydajacy:organ_wydajacy
data_wydania:date
Klasa Raport_ z_inspekcji_GDP musi, oprócz ww. przechowywać także
wszystkie informacje zawarte w raporcie
Wzór raportu znajduje się w załączniku C do OPZ.
Klasa Decyzja
<<PrimaryKey>>numer_decyzji:string
<<ForeignKey>>numer_inspekcji:string
<<Konektor>>identyfikator_hurtowni:string
<<Konektor>>nazwa_hurtowni:string
rodzaj_decyzji:rodzaj_decyzji
opis:string
data_wydania:date
data_realizacji:date
plik_ze_skanem:file
Klasa SMF_Czesc_Glowna
<<PrimaryKey>>identyfikator_SMF_czesci_glownej:string
<<Kolekcja>>kolekcja_identyfikatow_SMF_podczesci
<<Kolekcja>>kolekcja_identyfikatorow_SMF_zalacznikow
<<ForeinKey>> identyfikator_hurtowni
<<Kolekcja>>kolekcja_nazw_hurtowni
data_aktualizacji:date
numer_wydania:integer
21
data_wydania:date
data_wplywu:date
numer_polki_w_archiwum:string
data_przekazania_do_archiwum_glownego_GIF:date
data_utylizacji:date
opis:string
czy_aktualna:boolean
czy_caly_dokument:boolean
rodzaj_SMF:rodzaj_smf
plik_z_SMF_czesc_glowna:file
Klasa SMF_Podczesc
<<PrimaryKey>>identyfikator_SMF_podczesci:string
<<ForeignKey>>identyfikator_SMF_czesci_glownej:string
data_wydania:date
data_wplywu:date
data_przekazania_do_archiwum_GIF:date
opis:string
plik_z_SMF_poczesc:file
Klasa SMF_Zalacznik
<<PrimaryKey>>identyfikator_SMF_zalacznika:string
<<ForeignKey>>identyfikator_SMF_podczesci:string
<<Konektor>>identyfikator_SMF_czesci_glownej:string
data_wydania:date
data_wplywu:date
opis:string
plik_z_SMF_zalacznik:file
22
VIII.
Wymagania odnośnie aplikacji webowej – obiekty webowe
1. W trakcie przygotowywania założeń do przedmiotu zamówienia zidentyfikowane zostały
następujące klasy obiektów webowych niezbędnych do zawarcia w ramach Systemu:
a. <lista>
b. <element_listy>
c. <strona>
d. <filtr_strony>
e. <lista_glowna_strony>
f.
<link>
g. <widok>
h. <filtr_widoku>
2. <strona> to obiekt prezentujący użytkownikom aplikacji webowej informacje zgromadzone
w Systemie. Przegląd informacji udostępnionych na <stronie> musi odbywać się przy użyciu
przeglądarki internetowej. Podstawowym sposobem udostępniania informacji na <stronie>
musi być wykorzystanie obiektów webowych typu <lista>.
3. <lista> to obiekt graficzny prezentujący informacje w uporządkowanej, najczęściej
tabelarycznej, postaci (atrybuty rozmieszczane są w kolumnach: jeden obok drugiego lub w
wierszach: jeden pod drugim). <lista> może być osadzana na <stronie> lub przeglądana w
osobnym, niezwiązanym z żadną <stroną> oknie.
4. Każda <lista> osadzona na <stronie> musi umożliwiać:
a. przeglądanie <elementów listy>
b. wybieranie pojedynczego <elementu listy>
c. otwieranie wybranego <elementu listy> w trybie przeglądania minimalizowanie <listy>
d. otwieranie <listy> w osobnym, niezwiązanym ze <stroną> oknie
Dodatkowo <lista> powinna "współpracować" z <filtrami_strony> oraz umożliwiać
kopiowanie/powielanie danych z istniejącego <elementu_listy> do nowego.
5. Każda osadzona na <stronie> <lista> z atrybutami rozmieszczonymi w kolumnach musi
dodatkowo umożliwiać:
23
a. sortowanie <elementow_listy> według każdej prezentowanej kolumny
b. filtrowanie <elementow_listy> według każdej wartości w każdej prezentowanej
kolumnie
6. Każda <lista> musi umożliwiać użytkownikom, w zależności od posiadanych uprawnień
dotyczących konkretnej <listy>:
a. edytowanie widocznych w <widoku> kolumn
b. edytowanie poszczególnych <elementow_listy> (tryb edytowania)
c. dodawanie dowolnej liczby załączników w postaci plików do poszczególnych
<elementow_listy>
d. dodawanie nowych <elementów listy> (tryb dodawania)
e. usuwanie wybranych <elementow_listy>
7. Każda <lista> musi pozwalać na jej otworzenie, w osobnym, niezwiązanym ze <stroną>
oknie, umożliwiając przeglądanie <listy> w dostępnych dla konkretnego użytkownika
<widokach>, zależnie od posiadanych przez niego uprawnień dotyczących konkretnego
<widoku>.
8. Każda <lista> otwarta w osobnym, niezwiązanym ze <stroną> oknie musi umożliwiać
użytkownikom, w zależności od posiadanych uprawnień dotyczących konkretnego <widoku>
edytowanie i definiowanie nowych <widoków> <listy>, w szczególności:
a. nazwy <widoku>
b. wybieranie <widoku> domyślnego dla <listy>
c. wybieranie zestawu widocznych w <widoku> atrybutów
d. określanie źródła dla każdego z atrybutów, na przykład:
i. czy będzie to pole tekstowe ustalonego typu (date, integer, string, ...)
ii. czy będzie to pole związane z listą rozwijaną (enumeracja)
iii. czy będzie to pole przechowujące kolekcję identyfikatorów z innych list
iv. czy będzie to pole prezentujące pojedyncze dane z innych list (konektor)
v. czy będzie to pole prezentujące zbiór danych z innych list (kolekcja)
vi. ustalanie kolejności prezentacji atrybutów w <widoku>
24
vii. sposobów prezentacji (możliwość zarządzania stylami, w tym tworzenia
stylów)
viii. definiowanie <filtru_widoku> ograniczającego liczbę <elementow_listy>
9. Na pojedynczej <stronie> może być osadzonych wiele <list>. Dla zwiększenia czytelności
<stron> zawierających wiele <list>, wszystkie listy muszą posiadać mechanizm umożliwiający
ich minimalizowanie. <listy> muszą też posiadać mechanizm umożliwiający przeglądanie
<listy> w osobnym oknie, gdzie dostępne są różne widoki zdefiniowane dla <listy>.
10. Na pojedynczej <stronie> musi być możliwość umieszczania <filtru_strony> ograniczającej
liczbę <elementow_listy> na <liście_glownej_strony> umieszczanej domyślnie na początku
strony.
IX.
Wymagania odnośnie aplikacji webowej – obiekty klasy <lista> i <widok>
1. W trakcie przygotowywania założeń do przedmiotu zamówienia zidentyfikowane zostały (w
projekcie bazodanowym) następujące klasy obiektów:
a. Podmiot
b. Hurtownia
c. Dokument
d. Komora przeładunkowa
e. Zezwolenie
f. Certyfikat GDP
g. Raport z inspekcji GDP
h. SMF Cześć Główna
i. SMF Podczęść
j. SMF Załącznik
k. Inspektor
l. Inspekcja (połączona z raportem z inspekcji)
m. Zabezpieczenie
n. Decyzja
25
o. HDN – Harmonogram Działań Naprawczych
p. Osoba Odpowiedzialna
q. Okres Zgłoszenia
W projekcie webowym każdy z wyżej wymienionych obiektów, wraz ze wszystkimi przypisanymi
do tego obiektu atrybutami, prezentowany będzie w postaci <listy>.
2. Każda <lista> musi być prezentowana w trzech, nie ograniczających liczby atrybutów, trybach:
a. w trybie przeglądania wybranego <elementu listy>
b. w trybie edytowania wybranego <elementu listy>
c. w trybie dodawania nowego <elementu listy>
3. Każda lista musi być prezentowana co najmniej przez widoki opisane w niniejszym dokumencie
w tym przez <widok> Widok_Podstawowy, które będą reprezentowały <listę> po jej osadzeniu na
<stronach>. <widok> Widok_Podstawowy dla każdej <listy>, podobnie jak i wszystkie inne
<widoki> będą mogły być edytowane przez uprawnionych użytkowników Zamawiającego. Ze
względów praktycznych <widoki> Widok_Podstawowy nie powinny prezentować więcej niż sześć
atrybutów. Przykładowo <widok> Widok_Podstawowy dla <listy> Lista_Podmiotow może
prezentować:
kolumnę
identyfikator_podmiotu,
kolumnę
nazwa_podmiotu,
kolumnę
adres_miejscowosci w połączeniu z możliwością przeglądania pełnego zbioru atrybutów w trybie
przeglądania, w połączeniu z możliwością edytowania pełnego zbioru atrybutów w trybie
edytowania oraz w połączeniu z możliwością edytowania widoku, np. poprzez ograniczenie,
zwiększenie liczby kolumn.
X.
Wymagania odnośnie aplikacji webowej – Widoki
W trakcie przygotowywania założeń do przedmiotu zamówienia zidentyfikowane zostały następujące
składniki aplikacji webowej niezbędne do zawarcia ich w ramach Systemu:
1. Widoki Podstawowe - Poniżej przedstawione zostały przykładowe zestawy kolumn <widoków>
Widoki Podstawowe dla poszczególnych klas:
a. <widok> Widok_Podstawowy dla <listy> Lista_Podmiotow
identyfikator_podmiotu
nazwa_ podmiotu
adres_ulica
adres_miejscowosc
adres_kod_pocztowy
adres_wojewodztwo
26
status_podmiotu
b. <widok> Widok_Podstawowy dla <listy> Lista_Hurtowni
identyfikator_hurtowni
nazwa_podmiotu
adres_ulica
adres_miejscowosc
adres_kod_pocztowy
adres_wojewodztwo
status_hurtowni
c. <widok> Widok_Podstawowy dla <listy> Lista_Dokumentow
numer_dokumentu
nazwa_podmiotu
data_powstania
rodzaj_dokumentu
d. <widok> Widok_Podstawowy dla <listy> Lista_Komor_Przeladukowych
identyfikator_komory
identyfikator_podmiotu_
nazwa_podmiotu
adres_ulica
adres_miejscowosc
adres_kod_pocztowy
adres_wojewodztwo
e. <widok> Widok_Podstawowy dla <listy> Lista_Zezwolen
numer_zezwolenia
27
nazwa_ podmiotu
rodzaj_zezwolenia
status_zezwolenia
f. <widok> Widok_Podstawowy dla <listy> Lista_Certyfikatow
numer_certyfikatu
nazwa_ podmiotu
data_certyfikatu
g. <widok> Widok_Podstawowy dla <listy> Lista_Raportow_z_Inspekcji_GDP
numer_raportu_z_inspekcji_GDP
nazwa_ podmiotu
data_wydania
h. <widok> Widok_Podstawowy dla <listy> Lista_SMF_Czesci_Glownej
identyfikator_SMF_czesci_glownej
data_wydania
czy_aktualna
i. <widok> Widok_Podstawowy dla <listy> Lista_SMF_Podczesci
identyfikator_SMF_podczesci
data_ wydania
czy_aktualna
j. <widok> Widok_Podstawowy dla <listy> Lista_SMF_Załacznika
28
identyfikator_SMF_zalacznika
identyfikator_SMF_podczesci
data_wydania
czy_aktualna
k. <widok> Widok_Podstawowy dla <listy> Lista_Inspektora
identyfikator_inspektora
imie
nazwisko
l. <widok> Widok_Podstawowy dla <listy> Lista_Inspekcji
identyfikator_inspekcji
identyfikator_inspektora_wiodacego
nazwa_podmiotu
data_rozpoczecia
numer_inspekcji
numer_raportu
m. Widok_Podstawowy dla <listy> Lista_Harmonogramow_Działan_Naprawczych
numer_harmonogramu
identyfikator_inspekcji
nazwa_podmiotu
data_usuniecia_ostatniej_niezgodnosci
n. Widok_Podstawowy dla <listy> Lista_Osob_Odpowiedzialnych
identyfikator_osoby_odpowiedzialnej
imie
29
nazwisko
o. <widok> Widok_Podstawowy dla <listy> Lista_Okresow_Zgloszenia
numer_okresu
identyfikator_osoby_odpowiedzialnej
data_zgloszenia_nadzoru
data_zakonczenia_nadzoru
2. Widoki Pełne – dla każdej listy powinien powstać widok pełny pokazujący jak najwięcej atrybutów
danej listy. Atrybuty widoku pełnego zostaną ustalone w ramach prac etapu I.
XI.
Wymagania odnośnie aplikacji webowej – Obiekty klasy <strona>
W trakcie przygotowywania założeń do przedmiotu zamówienia zidentyfikowane zostały następujące
obiekty klasy <strona> niezbędne do zawarcia ich w ramach Systemu:
<strona> Strona Główna
<strona> Strona Podmiotów
<strona> Strona Hurtowni
<strona> Strona Zezwoleń
<strona> Strona Certyfikatów
<strona> Strona SMF
<strona> Strona Inspekcji
<strona> Strona Osób Wykwalifikowanych
<strona> Strona Inspektorów
<strony> Strony administracyjne
1. <strona> Strona Główna
Na stronie główne umieszczone zostaną dowolne informacje powitalne. Informacje te tak jak i
informacje umieszczone na pozostałych stronach muszą być w pełni zarządzane przez
upoważnionych pracowników Zamawiającego (CMS). Strona główna, podobnie jak i wszystkie
pozostałe strony muszą umożliwiać upoważnionym pracownikom Zamawiającego ostęp do
menu, które pozwoli na przejście do innych stron zdefiniowanych w aplikacji.
30
2. <strona> Strona Podmiotów
a. Strona Wszystkich Podmiotów zawiera następujące listy:
<listę> Lista_Podmiotow w <widoku> Widok_pełny
<listę> Lista_Hurtowni
(powiązanie typu ForeignKey)
<listę> Lista_Komor_przeładunkowych (powiązanie typu Konektor)
<listę> Lista_Dokumentow
(powiązanie typu Konektor)
<listę> Lista_SMF
<listę> Lista_Certyfikatow
<listę> Lista_Zezwolen
<listę> Lista_Raportow_z_inspekcji_GDP (powiązanie typu Konektor)
<listę> Lista_Harmonogramow
<listę> Lista_Decyzji
<listę> Lista_Inspekcji
<listę> Lista_Okresow_Zgloszen
(powiązanie typu Kolekcja)
Po wyborze Podmiotu z <listy> Lista_Podmiotow pozostałe listy osadzone na stronie
(domyślnie w <widokach> Widok_Podstawowy dostosują swoją zawartość poprzez
powiązanie z wybranym Podmiotem (wybór Podmiotu musi automatycznie wymusić
odfiltrowanie pozostałych <list>).
3. <strona> Strona Hurtowni
Strona Hurtowni zawiera następujące listy:
<listę> Lista_Hurtowni w <widoku> Widok_pełny
<listę> Lista_Składow_konsygnacyjnych
<listę> Lista_Certyfikatow
<listę> Lista_Inspekcji
<listę> Lista_Zabezpieczen
<listę> Lista_Raportow_z_inspekcji_GDP
<listę> Lista_Zezwolen
31
<listę> Lista_Okresow_Zgloszen
<listę> Lista_SMF_Czesci_Glownej
<listę> Lista_Dokumentow
4. <strona> Strona Zezwoleń
Strona Zezwoleń zawiera następujące listy:
<listę> Lista_Zezwolen w <widoku> Widok_pełny
<listę> Lista_Podmiotow
5. <strona> Strona Certyfikatów
Strona Certyfikatów zawiera następujące listy:
<listę> Lista_Certyfikatow w <widoku> Widok_pełny
6. <strony> Strony SMF
Strona Wszystkich SMF zawiera następujące listy:
<listę> Lista_SMF_Czesci_Glownej w <widoku> Widok_pełny
<listę> Lista_SMF_Podczęści
(powiązanie typu ForeinKey)
<listę> Lista_SMF_Załączników
Pozostałe strony zostać zrealizowana co najmniej na dwa sposoby (oba sposoby analogiczne do
stron certyfikatów
7. <strony> Strony Inspekcji
Strona Wszystkich Inspekcji zawiera następujące listy:
<listę> Lista_Inspekcji w <widoku> Widok_pełny
<listę> Lista_Decyzji
32
<listę> Lista_Harmonogramow
<listę> Lista_Komor_przeladunkowych
<listę> Lista_Inspektorow_Uczestniczacych
<listę> Lista_Inspektorow_Wiodacych
Pozostałe strony zostać zrealizowana co najmniej na dwa sposoby (oba sposoby analogiczne do
stron certyfikatów
8. <strona> Strona Osób Odpowiedzialnych
Strona Osoby Wykwalifikowane zawiera następujące listy:
<listę> Lista_Osob_Wykwalifikowanych w <widoku> Widok_pełny
9. <strona> Strona Inspektorów
Strona Inspektorów zawiera następujące listy:
<listę> Lista_Inspektorow w <widoku> Inspektorzy
<listę> Lista Inspekcji prowadzonych jako Inspektor wiodący
<listę> Listę Inspekcji przeprowadzonych przez Inspektora
10. <strony> Strony administracyjne
Na stronie/stronach administracyjnych, do których dostęp będą posiadali jedynie upoważnieni
pracownicy Zamawiającego udostępniony będzie dostęp do narzędzi/mechanizmów wymaganych do
pracy w Systemie w tym do raportów kontrolujących stabilność/poprawność danych czy logi
bezpieczeństwa.
11. Strefa Pomocy
W strefie pomocy musi zostać udostępniona pełna wytworzona przez Dostawcę dokumentacja
pomocowa z podziałem na dokumentację użytkownika, dokumentację administratora i pozostałe.
Dokumenty w formatach pdf, doc, rtf, html (itp.) mogą być udostępnione w postaci linków.
Elementy pomocy wbudowane w System wymagają co najmniej opisania tematyki pomocy, sposobu
dotarcia do nich i ewentualnej możliwości ich edycji.
33
Strefa Pomocy musi również umożliwiać dodawanie dowolnych plików pomocowych przez
administratorów systemu, na przykład dokumentacje systemu EudraGMDP, z możliwością opisania
co dany plik zawiera.
12. Strefa Narzędzi
EudraGMDP
i.
W strefie narzędzi wymagane jest udostępnienie wytworzonego w ramach Przedmiotu
Zamówienia narzędzia dwukierunkowej wymiany danych z systemem zewnętrznym o
nazwie EudraGMDP. Wszystkie dane zawarte w zezwoleniach na prowadzenie hurtowni
farmaceutycznej, certyfikatach GDP oraz w raportach z inspekcji GDP muszą być
przechowywane w Systemie i są przedmiotem wymiany danych. Narzędzie musi umożliwić
administratorowi przeglądanie Zezwoleń, Certyfikatów i Raportów z inspekcji GDP pod
kątem informacji czy już zostały wysłane do EudraGMDP. Prezentacja powinna obejmować
co najmniej: informacje o numerach (certyfikatów DGP, zezwoleń, raportów z inspekcji
GDP), informacje o datach przekazania, możliwość połączenia z listami (odpowiednio
zezwoleń, certyfikatów GDP, raportów z inspekcji GDP). Dokładna lista atrybutów i kryteria
dotyczące wyświetlania obiektów zostaną ustalone podczas testów narzędzia.
ii.
Narzędzie musi umożliwić administratorowi dokonanie wyboru Zezwolenia, Certyfikatu DGP
lub Raportu z Inspekcji GDP, który powinien zostać wysłany do EudraGMDP.
iii.
Narzędzie musi automatycznie przygotować, dla wybranego obiektu, w oparciu o dostępne
dane, plik wymiany w postaci xml.
iv.
Administrator musi mieć możliwość oglądania przygotowanych plików xml.
v.
Administrator musi mieć także możliwość oglądania plików xml wysłanych wcześniej.
vi.
Narzędzie musi umożliwiać wysłanie plików dla wybranych obiektów. Wysyłka odbywa się z
wykorzystaniem oprogramowania Synchrony Activator, na które Zamawiający posiada
licencję. Synchrony Activator działa w ten sposób, że pobiera z odpowiedniego lokalnego
katalogu pliki i wysyła je na odpowiedni adres (serwer EudraGMDP) oraz odbiera z
odpowiedniego adresu (serwera EudraGMDP) pliki i umieszcza je w odpowiednim lokalnym
katalogu. Narzędzie musi rejestrować każde wysłanie. Lista atrybutów do wysłania w
postaci pliku w formacie XML zostanie ustalone podczas prac nad przygotowaniem
narzędzia. Potwierdzenia z systemu EudraGMDP przekazywane są w postaci plików xml.
Narzędzie musi rejestrować każde potwierdzenie dostarczenia. (data potwierdzenia, plik
xml potwierdzenia). Dokładna lista atrybutów i kryteria dotyczące przechowywania
odpowiedzi zostanie ustalona podczas testów narzędzia.
vii.
Narzędzie musi umożliwić administratorowi przeglądanie Potwierdzeń w połączeniu z
właściwymi Zezwoleniami, Certyfikatami czy Raportami z Inspekcji GDP. Na potrzeby
obsługi tego Narzędzia nie została przewidziana żadna konkretna struktura danych. Musi
ona zostać wypracowana na etapie tworzenia i testowania Narzędzia i opierać się na
34
danych zawartych w formularzach opracowanych na podstawie wzorów dokumentów,
których wzory znajdują się w załącznikach A, B, C do OPZ.
Dokumentacja do systemu EudraGMDP znajduje się w następujących załącznikach do
viii.
OPZ:

Załączniki D1 – D6 do OPZ – schemat XML ver 3.0

Załącznik E do OPZ - Instrukcja wymiany XML z EudraGMDP

Załącznik F do OPZ - scenariusz testowania automatycznej wymiany z EudraGMDP

Załącznik G do OPZ - Instrukcje testowania automatycznej wymiany danych z EudraGMDP
13. Strefa Bezpieczeństwa
a. System
musi
przechowywać
log
modyfikacji
danych
wykonywanych
przez
poszczególnych użytkowników.
b. System musi przechowywać log modyfikacji ustawień systemu wykonanych przez
poszczególnych użytkowników.
c. System musi umożliwiać przeglądanie logów.
d. System musi umożliwiać filtrowanie logów po nazwie użytkownika, który dokonał zmiany
oraz wybór okresu za jaki log ma pokazywać wpisy.
XII.
Wymagania dotyczące bezpieczeństwa Systemu
1. Wykonawca musi zapewnić utworzenie kilku równolegle używanych środowisk Systemu, w tym
co najmniej: testowego, produkcyjnego
2. Wykonawca musi zapewnić, że we wdrożonym Systemie będą spełniane wymagania Ustawy o
ochronie danych osobowych (z 29 sierpnia 1997 r. Dz.U. z 2002 r. Nr 101, poz. 926, z późn.
zm.).
3. System musi zapewniać mechanizmy kontroli integralności i monitorowania poprawnego
funkcjonowania wszystkich komponentów.
4. System musi być dostarczony wraz z prawidłowo wdrożoną kontrolą dostępu, która musi
zabezpieczać
przed
możliwością
nieuprawnionego
odczytu
lub
modyfikacji
danych
przetwarzanych przez aplikację.
5. Kontrola dostępu do systemu i jego infrastruktury musi obejmować co najmniej funkcje
zarządzania kontami i uprawnieniami użytkowników, zawierające mechanizmy umożliwiające
definiowanie profili uprawnień ograniczających zakres możliwych do wykonania operacji oraz
zakres danych, na których te operacje mogą być wykonane. Profile uprawnień muszą grupować
role powiązane ze stanowiskiem użytkownika.
35
6. Kontrola dostępu do systemu i jego infrastruktury musi obejmować co najmniej możliwość
jednoznacznej identyfikacji użytkownika przez wykorzystanie unikalnego identyfikatora konta
(login) przypisanego do pracownika.
synchronizacji zmiany hasła użytkownika z hasłem w systemie operacyjnym.
8. Kontrola dostępu do systemu i jego infrastruktury musi obejmować przejmowanie autentykacji
użytkownika zalogowanego do systemu operacyjnego stacji roboczej klienta.
czasowej blokady konta przy wielokrotnej próbie zalogowania niewłaściwym hasłem. Liczba prób
musi być możliwa do ustalenia przez administratora.
10. Kontrola dostępu do systemu i jego infrastruktury musi co najmniej umożliwić definiowanie
dopuszczalnego czasu nieaktywności użytkownika,
po którym
zostanie automatycznie
"wylogowany" z Systemu.
11. Czynności wykonywane w systemie przez użytkowników w tym administratorów, powinny być
zapisywane w dzienniku zdarzeń, umożliwiając monitorowanie pracy aplikacji.
12. System musi być zbudowany w sposób zapewniający jego pełną odtwarzalność. W przypadku
awarii systemu, rozwiązanie powinno zapewniać możliwość odtwarzania go z kopii zapasowych.
XIII.
Wymagania w zakresie gwarancji do Systemu
Na wykonane usługi w ramach realizacji przedmiotu umowy Wykonawca udzieli Zamawiającemu
gwarancji na okres 24 miesięcy, liczony od dnia podpisania protokołu odbioru końcowego.
1. Gwarancja przedmiotu zamówienia świadczona będzie w miejscu jej wykonania i dotyczyć
będzie Systemu wraz z listą usług opisanych w dokumentacji powykonawczej
2. Wykonawca zobowiązuje się do przyjmowania zgłoszeń o awarii przez 7 dni w tygodniu, 24
godziny na dobę.
3. Czas reakcji serwisowej wynosi 2 godziny od otrzymania zgłoszenia od Zamawiającego i
liczony jest tylko w godzinach pracy Zamawiającego czyli od poniedziałku do piątku w
godzinach 8:15 do 16:15.
4. Wykonawca zobowiązuje się usunąć awarię w następującym czasie od momentu zgłoszenia
przez Zamawiającego:
i. dla priorytetu I – 48 godzin,
ii. dla priorytetu II – 96 godzin,
iii. dla priorytetu III – 6 dni.
5. Priorytet awarii ustala Zamawiający w swoim zgłoszeniu, zgodnie z poniższymi definicjami:
i. Stan krytyczny (priorytet I) - obejmuje całkowite zatrzymanie pracy Systemu lub bardzo
poważne uszkodzenie, mające krytyczny wpływ na jego funkcjonalność,
36
ii. Stan ważny (priorytet II) – awaria powodująca poważne niedogodności w pracy
Systemu i/lub powtarzające się zakłócenia, które mogą mieć znaczący wpływ na
funkcjonalność Systemu,
iii. Stan zwykły (priorytet III) – problem nie powodujący bezpośredniego wpływu na
obniżenie funkcjonalności systemu. Ta klasa problemów obejmuje nieznaczne
rozbieżności dotyczące funkcjonalności w porównaniu z opisami w dokumentacji oraz
sporadyczne problemy i niedogodności.
6. Wykonawca rejestruje każde zgłoszenie w celu zgromadzenia i zachowania wstępnych
informacji o zgłoszonej awarii. Zebrane informacje posłużą do ustalenia statusu, dnia
rozpoczęcia i zakończenia pracy, metod pracy u Zamawiającego lub zdalnie.
7. Zaplanowane przerwy w działaniu systemu (okna serwisowe) mogą mieć miejsce w dni wolne
oraz w dni robocze od 16:30 do 08:00. Każda zaplanowana przerwa musi zostać zgłoszona
Zamawiającemu z wyprzedzeniem 3 dni roboczych.
8. Dokumentem potwierdzającym wykonanie prac jest Raport powykonawczy sporządzany
przez
Wykonawcę,
każdorazowo
po
realizacji
zgłoszenia,
potwierdzony
przez
Zamawiającego oraz sprawozdanie miesięczne i kwartalne z przebiegu świadczenia usług,
obejmujące wszystkie zgłoszenia w danym miesiącu.
9. Zamawiający wymaga, aby Gwarancji podlegały:
i. Wszystkie moduły aplikacji wchodzące w skąd systemu oraz mechanizmy integracji
między nimi oraz innymi systemami Zamawiającego.
ii. Skrypty oraz konfiguracje systemu stworzone w ramach systemu.
iii. Wszelkie modyfikacje systemu tworzone za zgodą i wiedzą Wykonawcy.
10. Wykonawca będzie udostępniał wszystkie informacje dotyczące wykonanych zmian/napraw
na życzenie zamawiającego. W przypadku powstałych zmian w Systemie, Wykonawca
przekaże uaktualnioną dokumentację do obszaru, w którym wykonana zmiana/naprawa
została przeprowadzona oraz jeśli w wyniku jej powstał nowy kod źródłowy, przekaże również
jego uaktualnioną wersję .
37

opis przedmiotu zamówienia ( OPZ )

Transkrypt

Podobne dokumenty

Q Fire Rozłącznik paneli PV

José González with The String Theory

Zadanie 1 (zupełnie proste) H1 H2 O1 O2 O3 OF D1 18 13 X X X X x

Konsultant BI

Laboratorium 1 Zadanie 1. Skompiluj i uruchom program HelloWorld

Sklepy

projektant_hurtowni_danych_3.11.2010 03/11/2010, 12:35