Polska Platforma Medyczna: portal zarządzania wiedzą i potencjałem badawczym POPC.02.03.01-00-0008/17-00

Polska Platforma Medyczna: portal zarządzania wiedzą i potencjałem badawczym

POPC.02.03.01-00-0008/17-00

OPIS PRZEDMIOTU ZAMÓWIENIA załącznik nr 2 do SIWZ

1. Wprowadzenie

1. Przedmiotem zamówienia jest dostawa licencji i wdrożenie przez Wykonawcę zintegrowanego systemu informatycznego prezentującego i promującego osiągnięcia naukowe i potencjał badawczy uczestników Projektu:

- Lidera, którym jest Uniwersytet Medyczny im. Piastów Śląskich we Wrocławiu (Lider)

oraz 7 jednostek partnerskich, tj.:

- Uniwersytetu Medycznego w Białymstoku (Partner nr 2),

- Gdańskiego Uniwersytetu Medycznego (Partner nr 3),

- Śląskiego Uniwersytetu Medycznego w Katowicach (Partner nr 4),

- Uniwersytetu Medycznego w Lublinie (Partner nr 5),

- Pomorskiego Uniwersytetu Medycznego w Szczecinie (Partner nr 6),

- Warszawskiego Uniwersytetu Medycznego (Partner nr 7),

- Instytutu Medycyny Pracy im. prof. dra med. Xxxxxxx Xxxxxx w Łodzi (Partner nr 8).

2. System będący przedmiotem zamówienia ma zawierać w sobie strukturę systemu CRIS* i repozytorium**, tzn. ma być platformą/bazą semantyczną o elastycznym oprogramowaniu umożliwiającym definiowanie struktur danych, relacji i obiektów dotyczących różnych aspektów działalności badawczej i ma stanowić centralne źródło informacji na temat naukowców i ich działalności służące do raportowania oraz upowszechniania potencjału badawczego.

*CRIS (Current Research Information System) - system bazodanowy obudowany funkcjonalnościami, zorientowany na gromadzenie rozbudowanych metadanych dotyczących wszystkich aspektów działalności badawczej instytucji, takich jak x.xx.: publikacje, dane badawcze, projekty naukowe, naukowcy, aparatura badawcza, współpraca między ośrodkami naukowymi. Pozwala na zarządzanie i maszynową analizę tej działalności dzięki logicznej strukturze danych. Pozwala na szerokie, otwarte udostępnianie gromadzonych informacji poprzez interfejsy wyszukiwawcze. Rekomendowanym standardem metadanych jest Common European Research Information Format (CERIF).

**Repozytorium – narzędzie informatyczne/baza danych/platforma służące do gromadzenia (w tym na zasadzie samoarchiwizacji), długoterminowego przechowywania, udostępniania i ochrony dorobku naukowego, takiego jak artykuły naukowe i zbiory danych badawczych, patenty i inne dokumenty.

3. System musi umożliwiać każdemu z partnerów projektu gromadzenie i prezentowanie osiągnięć naukowych i potencjału badawczego na poziomie lokalnym oraz wybranych danych na poziomie centralnym za pośrednictwem Polskiej Platformy Medycznej (PPM).

4. Przedmiot zamówienia obejmuje:

1. Dostawę, instalację i uruchomienie Systemu, systemu operacyjnego, oprogramowania bazodanowego oraz wszelkiego innego oprogramowania niezbędnego do prawidłowego działania dostarczonego rozwiązania, u każdego z Partnerów oraz w ramach Polskiej Platformy Medycznej. Zamawiający udostępni Wykonawcy infrastrukturę informatyczną w postaci rozwiązania sprzętowego i wirtualizacyjnego zgodnie z pkt. C Opisu Przedmiotu Zamówienia. Zamawiający nie posiada żadnego oprogramowania, w tym systemowego i bazodanowego, które zostanie wykorzystane do realizacji niniejszego zamówienia.

2. Wykonanie analizy i dokumentacji przedwdrożeniowej mającej na celu uzyskanie wiedzy niezbędnej do pełnego wdrożenia Systemu wykonanego według metody projektowania zorientowanego na użytkownika, zgodnie z potrzebami i oczekiwaniami Zamawiającego oraz określenie szczegółowej koncepcji wdrożenia Systemu.

3. Opracowanie szczegółowego harmonogramu prac związanych z realizacją Umowy, z podziałem na etapy, które będą stanowiły również etapy rozliczeń z Zamawiającym fakturami częściowymi.

4. Opracowanie, dostawę i instalację funkcjonalności Systemu zgodnie z harmonogramem i wynikami analizy przedwdrożeniowej.

5. Zapewnienie możliwości generowania przez System zestawień i raportów z możliwością zapisu i wydruku, obejmujących wszystkie treści Systemu.

6. Integrację Systemu ze wskazanymi systemami informatycznymi i programami komputerowymi, których funkcje nie zostaną zastąpione przez System,

7. Migrację danych z wykorzystywanych aktualnie przez Zamawiającego systemów informatycznych i programów wymienionych w p. 7 (zakres, sposób migracji i format wymiany danych zostanie uzgodniony przez Zamawiającego podczas analizy przedwdrożeniowej).

8. Opracowanie pełnej dokumentacji dotyczącej wdrożenia Systemu i przekazanie jej Zamawiającemu nie później niż do dnia:

- dla instalacji lokalnych 30.10.2019 r.,

- dla Polskiej Platformy Medycznej 31.05.2020 r.

9. Przeszkolenie pracowników i administratorów Systemu Zamawiającego do poprawnej i efektywnej pracy w nowym Systemie, a administratorów dodatkowo do skutecznego zarządzania Systemem zgodnie z harmonogramem ustalonym z Zamawiającym.

10. Udzielenie bezterminowej licencji na korzystanie z całego Systemu oraz wszelkiego innego oprogramowania niezbędnego do prawidłowego działania dostarczonego rozwiązania.

11. Udzielenie gwarancji na wykonany przedmiot Umowy, o którym mowa na okres co najmniej 72 miesięcy od dnia podpisania końcowego protokołu odbioru bez uwag.

5. Zamawiający oświadcza, że w momencie udostępnienia Polskiej Platformy Medycznej z serwera Lidera dostępne będą co najmniej:

- 5.293 profile pracowników naukowych,

- 229.243 metadane opisujące dorobek naukowy i potencjał badawczy,

- 20.364 dokumenty piśmiennicze i dane badawcze wraz z metadanymi,

w następującym udziale poszczególnych Partnerów Projektu:

1. Lider:

- 993 profili pracowników naukowych,

- 23.827 metadanych opisujących dorobek i potencjał badawczy,

- 1.490 dokumentów piśmienniczych i danych badawczych wraz z metadanymi,

2. Partner nr 2:

- 600 profili pracowników naukowych,

- 25.600 metadanych opisujących dorobek i potencjał badawczy,

- 1.500 dokumentów piśmienniczych i danych badawczych wraz z metadanymi,

3. Partner nr 3:

- 799 profili pracowników naukowych,

- 18.735 metadanych opisujących dorobek i potencjał badawczy,

- 4.116 dokumentów piśmienniczych i danych badawczych wraz z metadanymi,

4. Partner nr 4:

- 1.300 profili pracowników naukowych,

- 100.656 metadanych opisujących dorobek i potencjał badawczy,

- 2.800 dokumentów piśmienniczych i danych badawczych wraz z metadanymi,

5. Partner nr 5:

- 400 profili pracowników naukowych,

- 24.570 metadanych opisujących dorobek i potencjał badawczy,

- 1.650 dokumentów piśmienniczych i danych badawczych wraz z metadanymi,

6. Partner nr 6:

- 450 profili pracowników naukowych,

- 10.314 metadanych opisujących dorobek i potencjał badawczy,

- 1.416 dokumentów piśmienniczych i danych badawczych wraz z metadanymi,

7. Partner nr 7:

- 700 profili pracowników naukowych,

- 23.280 metadanych opisujących dorobek i potencjał badawczy,

- 6.549 dokumentów piśmienniczych i danych badawczych wraz z metadanymi,

8. Partner nr 8:

- 150 profili pracowników naukowych,

- 2.261 metadanych opisujących dorobek i potencjał badawczy,

- 843 dokumentów piśmienniczych i danych badawczych wraz z metadanymi.

6. Zamawiający przewiduje docelowo założenie profili wszystkim pracownikom naukowym, tj.:

- Lider – 1.025 naukowcom,

- Partner nr 2 – 800 naukowcom,

- Partner nr 3 – 999 naukowcom,

- Partner nr 4 – 1.300 naukowcom,

- Partner nr 5 – 1.000 naukowcom,

- Partner nr 6 – 624 naukowcom,

- Partner nr 7 – 1.340 naukowcom,

- Partner nr 8 – 249 naukowcom.

7. Systemy aktualnie wykorzystywane przez Zamawiającego:

- System Aleph; firma ExLibris i Aleph Polska Sp. z o. o.,

- Ankieta Naukowa Jednostki; Warszawski Uniwersytet Medyczny,

- Baza publikacji pracowników Uniwersytetu Medycznego w Lublinie; firma IPL Xxxxxx Xxxxxxxxx,

- eNaukowiec; Gdański Uniwersytet Medyczny,

- Program Expertus®; firma Splendor Systemy Informacyjne,

- Program Journal System dla czasopisma Medycyna Pracy; firma Bentus,

- Program Journal System dla czasopisma International Journal of Occupational Medicine and Environmental Health; firma Bentus,

- System Primo®; firma: Aleph Polska Sp. z o. o.,

- Repozytorium ECNIS-NIOM; hostingowane przez firmę Atmire, Oddział w Europie,

- WUM.Publikacje; Warszawski Uniwersytet Medyczny.

8. Po zakończeniu realizacji projektu Zamawiający przewiduje możliwość prezentowania na platformie PPM zasobów nauki innych jednostek naukowych niż wymienione w pkt. A.1.

B. Definicje pojęć

Pojęcia użyte w Opisie Przedmiotu Zamówienia oznaczają:

1. System zintegrowany (zwany dalej Systemem) – oprogramowanie składające się z instalacji lokalnych oraz instalacji centralnej, prezentujące i promujące osiągnięcia naukowe i potencjał badawczy o parametrach i funkcjonalnościach opisanych w niniejszym dokumencie, którego wdrożenie Wykonawca przeprowadzi w terminach określonych w SIWZ i harmonogramie stanowiącym załącznik do Umowy.

2. System rozproszony – system, którego poszczególne elementy (serwery) znajdują się w lokalizacjach fizycznie od siebie oddalonych. Serwery są wyposażone w oprogramowanie umożliwiające współdzielenie zasobów, komunikują się przy wykorzystaniu sieci komputerowej, są postrzegane przez użytkowników jako pojedynczy i zintegrowany system.

3. Repozytorium - narzędzie informatyczne służące do deponowania, przechowywania i udostępniania w Internecie materiałów stanowiących dorobek naukowy instytucji lub określonych dziedzin nauki.

4. Deduplikacja – automatyczne eliminowanie powtarzających się danych przechowywanych w obrębie instalacji lokalnych oraz udostępnianych w ramach Polskiej Platformy Medycznej.

5. Inne dokumenty piśmiennicze - plakaty, abstrakty, referaty zjazdowe, komentarze, raporty, publikacje popularno-naukowe, itp.

6. Metadane publikacji – zbiór uporządkowanych informacji, który dostarcza szczegółowych danych dotyczących atrybutów jednostek informacji lub zasobów, w szczególności opisy bibliograficzne dokumentów, takich jak: artykuły w czasopismach, książki, fragmenty książek.

7. Istotne dane instytucji - dane przekazywane przez instytucje do Zintegrowanego Systemu Informacji o Nauce i Szkolnictwie Wyższym POL-on, o których mowa w Rozporządzeniu MNiSW z dnia 6 marca 2019 r. w sprawie danych przetwarzanych w Zintegrowanym Systemie Informacji o Szkolnictwie Wyższym i Nauce POL-on (tj. Dz. U. 2019 poz. 496).

8. PPM – projekt realizowany przez Zamawiającego w ramach umowy z dnia 13.11.2017 roku nr POPC.02.03.01-00-0008/17-00 o dofinansowanie projektu pod nazwą: „Polska Platforma Medyczna: portal zarządzania wiedzą i potencjałem badawczym” w ramach Programu Operacyjnego Polska Cyfrowa na lata 2014-2020.

9. Administrator PPM - osoba odpowiadająca za utrzymanie i prawidłowe działanie platformy agregującej dane z platform partnerów projektu, wygląd i funkcjonalność poszczególnych elementów platformy, współpracę z administratorami lokalnymi.

10. Administrator lokalny - osoba odpowiadającą za utrzymanie i prawidłowe działanie platformy lokalnej u partnera. Przygotowuje środowisko pracy dla redaktorów, użytkowników zarejestrowanych i użytkowników zewnętrznych. Jest odpowiedzialny za wygląd i funkcjonalność poszczególnych elementów platformy. Odpowiada za działanie API do wymiany danych między systemami oraz, przy współpracy redaktorów, za prawidłowy import danych. Współpracuje z administratorem PPM oraz redaktorami.

11. Redaktor - osoba odpowiadająca za poprawność i spójność danych na platformie i w zależności od poziomu uprawnień mająca możliwość dodawania, edytowania, usuwania oraz importu danych. Prowadzi dwustronną komunikację z użytkownikami. Ściśle współpracuje z administratorem lokalnym.

12. Użytkownik wewnętrzny – zalogowany użytkownik, pracownik naukowy lub doktorant Partnera.

13. Użytkownik zewnętrzny – niezalogowany użytkownik, pracownik naukowy lub doktorant innych uczelni wyższych i jednostek naukowych oraz przedstawiciel otoczenia społeczno-gospodarczego.

14. Spójność danych - dbałość o prawidłowe zależności między poszczególnymi rodzajami wprowadzanych danych, np. profilem pracownika naukowego i publikacją.

15. API (Application Programming Interface) - interfejs programowania aplikacji, pozwalający na komunikowanie się aplikacji między sobą.

C. Infrastruktura techniczna i informatyczna

1. Na potrzeby obsługi instalacji centralnej PPM Zamawiający dysponuje serwerem o następującej konfiguracji: 2 procesory Intel Xeon E5-2643 v4, 64 GB pamięci RAM, twarde dyski o łącznej pojemności 4TB.

2. Do obsługi instalacji lokalnych Lider i Partnerzy Projektu będą dysponować sprzętem o konfiguracji nie gorszej niż: 2 procesory Intel Westmere X5670 (2x6 rdzeni + HT = 24 CPU na system operacyjny) oraz 8 GB pamięci RAM.

3. Wszyscy uczestnicy Projektu są bezpośrednio wpięci do ogólnopolskiej sieci światłowodowej PIONIER z prędkością co najmniej 1Gb/s.

4. Wykonawca musi uwzględnić posiadaną przez Zamawiającego infrastrukturę informatyczną wymienioną powyżej i zrealizować wdrożenie tak, aby dostarczony system wykorzystywał rozwiązania sprzętowe i infrastrukturę informatyczną Zamawiającego i Partnerów.

5. System powinien posiadać architekturę rozproszoną, to znaczy składać się z:

a) warstwy lokalnej dla każdego z Partnerów Projektu,

b) warstwy centralnej, zapewniającej odpowiednią komunikację z lokalnymi wdrożeniami.

c) wykorzystywać usługi sieciowe do wymiany danych miedzy warstwami oraz stałego aktualizowania danych.

6. Zamawiający wymaga, aby wdrożenie lokalne było:

a) skonfigurowane według potrzeb poszczególnych Partnerów Projektu,

b) oferowało funkcje pozyskiwania, porządkowania, wykorzystywania i prezentowania wszystkich istotnych danych Partnera Projektu.

7. Zamawiający wymaga, aby wdrożenie centralne:

a) umożliwiało automatyczny import danych z systemów lokalnych Partnerów Projektu,

b) posiadało automatyczną deduplikację danych importowanych z systemów lokalnych bez utraty ich jakości oraz narzędzia manualne umożliwiające redaktorom podjęcie decyzji o wyborze rekordu w przypadku potencjalnych duplikatów.

c) było konfigurowalne w celu spełnienia potrzeb użytkowników wewnętrznych i zewnętrznych.

8. Wykonawca powinien zapewnić wysoki standard bezpieczeństwa realizowany wielopłaszczyznowo, w szczególności w następujących aspektach:

- zabezpieczenia systemowe,

- bezpieczeństwo danych,

- bezpieczeństwo aplikacji,

- testy bezpieczeństwa systemu,

- określenie zasobów niezbędnych do zapewnienia wymaganego poziomu bezpieczeństwa,

- wdrożenie szkoleń bezpieczeństwa danych wśród pracowników związanych z administracją systemem na różnych poziomach.

D. Obszary funkcjonalne systemu zarządzania wiedzą i potencjałem badawczym

I. Wymagania ogólne

Niniejszy rozdział opisuje wymagania Zamawiającego względem Systemu. Wszystkie opisane poniżej wymagania ogólne są wymaganiami koniecznymi do spełnienia przez System, z wyjątkiem tych wskazanych w AIT jako wymagania dodatkowe realizowane w zakresie zgodnym z ofertą. Muszą zostać przez Wykonawcę dostarczone i być realizowane przez oferowany System w ramach wbudowanej funkcjonalności bezpośrednio po instalacji Systemu lub muszą zostać wykonane podczas realizacji wdrożenia, lecz nie później niż przed startem czynności związanych z testami umożliwiającymi końcowy odbiór Systemu.

Ilekroć w niniejszym opisie wymagań używane są słowa „powinien” lub „możliwość”, niezależnie od formy i konstrukcji gramatycznej, w której występują, należy je rozumieć jako wyrażające obowiązek przyszłego Wykonawcy przedmiotu zamówienia do wykonania określonych działań, zastosowania się do wskazanego obowiązku lub wypełnienia kryterium.

1. System musi co najmniej:

1. Umożliwiać pozyskiwanie, kontrolowanie, wykorzystywanie i prezentowanie danych, w tym dokumentów pełnotekstowych, metadanych i danych badawczych na poziomie lokalnym przy założeniu dostosowywania ich do lokalnych potrzeb Partnerów oraz na poziomie Polskiej Platformy Medycznej przy założeniu dostosowywania ich do centralnych potrzeb Projektu Partnerskiego.

2. Posiadać interfejs WWW co najmniej w języku polskim i angielskim z możliwością przełączania wersji językowej bez utraty kontekstu. System musi posiadać możliwość ustawienia domyślnego języka interfejsu WWW zarówno niezależnie dla każdej z instalacji lokalnych, jak i dla platformy centralnej. System musi posiadać możliwość tworzenia kilku wersji językowych dla poszczególnych metadanych, a w szczególności dla metadanych profilu naukowca. Przełączenie języka interfejsu powinno wiązać się z wyświetlaniem metadanych w tym samym języku lub w przypadku ich braku w języku domyślnym.

3. Posiadać pełną skalowalność. Objętość systemu powinna być możliwa do rozszerzenia w dowolnym momencie ze względu na masowy przyrost danych bez obniżenia wydajności systemu.

4. Być dostępny z dowolnego systemu operacyjnego i dowolnej przeglądarki internetowej, co najmniej: Google Chrome, Mozilla Firefox, Internet Explorer, Safari oraz na urządzeniach mobilnych z iOS i Android w wersjach nie starszych niż 2 lata od dnia ogłoszenia postępowania.

5. Posiadać model danych zgodny z uznanymi międzynarodowymi standardami dla systemów CRIS, tj. CERIF lub równoważny, identyczny dla wszystkich instalacji lokalnych i platformy PPM.

6. Umożliwiać współpracę z innymi systemami wykorzystanymi przez Partnerów Projektu za pomocą interfejsu programistycznego aplikacji.

7. Umożliwiać przeszukiwanie zawartości Systemu przez wyszukiwarki typu Google Scholar.

8. Posiadać możliwość deponowania, przeglądania i wyszukiwania dokumentów pełnotekstowych i danych badawczych opatrzonych metadanymi.

9. Umożliwiać archiwizację bieżącą i długoterminową zgromadzonych danych.

10. Posiadać standardową funkcjonalność CRUD (tzn. create, read, update and delete – twórz, odczytaj, aktualizuj i usuń), w połączeniu z wieloma innymi funkcjami, takimi jak: raportowanie, transformacja z/do formatów (CERIF, DC, itd.), kontrola dostępu, workflow, model multitenant (korzystanie z zasobu przez wielu użytkowników) lub równoważne.

11. Umożliwiać rejestrację historii operacji oraz możliwość wyszukiwania i filtrowania co najmniej takich atrybutów, jak: nazwa użytkownika, data i czas operacji, rodzaj operacji, adres komputera z którego została wykonana, nazwa zasobu na którym wykonano operację. Powinny być rejestrowane operacje wykonywane przez użytkowników oraz operacje automatycznie wykonywane przez system.

12. Zapewnić interoperacyjność poprzez API lub poprzez format wymiany danych json lub poprzez wykorzystanie predefiniowanego formatu xml opisanego w plikach .xsd. W przypadku plików xml system musi zapewnić narzędzie dla administratorów umożliwiające konfigurację i projektowanie integracji danych niezależnie od dostawcy. System musi umożliwiać ustawienie harmonogramu automatycznego uruchamiania integracji danych, umożliwiać taką konfigurację, aby wszystkie pola i relacje poszczególnych jednostek organizacyjnych i osób były synchronizowane, synchronizowane tylko raz, niesynchronizowane lub zablokowane oraz aby każde uruchomienie synchronizacji musiało generować wpis do logu na temat przebiegu procesu wymiany danych. Powyższe wymagania dotyczą także wymiany danych w oparciu o format json.

13. Umożliwiać wymianę danych między systemami wg standardu OAI-PMH (ang. Open Access Initiative - Protocol for Metadate Harvesting) lub równoważnych.

14. Umożliwiać automatyczne importowanie danych bibliograficznych oraz innych metadanych na podstawie nr DOI.

15. Umożliwiać pozyskiwanie metadanych z zewnętrznych baz i systemów, w tym w szczególności z zasobów wiedzy The National Library of Medicine.

16. Umożliwiać automatyczne importowanie i przypisywanie metadanych patentów ze źródeł internetowych za pośrednictwem gotowych interfejsów programistycznych aplikacji.

17. Wspierać różne metody uwierzytelniania, w tym przynajmniej takie jak: LDAP, Active Directory, Radius, CAS. Mechanizmy uwierzytelniania muszą być konfigurowalne przez administratorów systemu niezależnie od dostawcy poprzez interfejs nie wymagający umiejętności programistycznych. System musi pozwalać na ręczne lub automatyczne (na podstawie jednoznacznego numeru – klucza, np., ORCID, PESEL) powiązanie konta logowania z profilem naukowca oraz kontem redaktora.

18. Umożliwiać użytkownikowi filtrowanie danych za pomocą faset wg różnych kategorii.

19. Zapewniać rozbudowane mechanizmy wyszukiwania i filtrowania z użyciem słowników kontrolowanych i operatorów logicznych.

20. Umożliwiać założenie alertów, co najmniej o nowo dodanych publikacjach, w tym według autora, słów kluczowych, haseł MeSH.

21. System powinien pozwalać na wyszukiwanie kontekstowe, w tym na podstawie informacji o polu badawczym zamieszczonej w profilu naukowca, słowach kluczowych i hasłach MeSH publikacji powiązanych z profilem naukowca – w przypadku wyszukiwania przez użytkowników wewnętrznych.

22. Umożliwiać zarządzanie wynikami wyszukiwania, tj. sortowanie, w tym sortowanie zgodnie z kryterium relewantności, i zapisywanie.

23. Zapewniać możliwość kontaktu z redaktorem poprzez interfejs WWW.

24. Zapewniać możliwość autoryzowanego dostępu dla wybranych grup użytkowników zdefiniowanych w słowniku.

25. Umożliwiać użytkownikowi wewnętrznemu dodawanie, edycję i usuwanie danych powiązanych z własnym profilem naukowca. Opisane wyżej zmiany powinny być widoczne w interfejsie WWW po zatwierdzeniu przez redaktora. System powinien posiadać mechanizm informujący odpowiedniego redaktora o konieczności zatwierdzenia zmian.

26. Umożliwiać automatyczne wykrywanie błędów, możliwych do zweryfikowania maszynowo we wprowadzonych danych.

27. Umożliwiać stosowanie list słownikowych do pól wprowadzanych danych w tym z list słownikowych opartych na KHW (autor, jednostka, czasopismo, wydawca, MeSH) oraz automatycznie podpowiadać wszystkie możliwe propozycje w oparciu o już zgromadzone dane.

28. Umożliwiać redakcję zamieszczanych w nim danych zgodnie z zakresem uprawnień redaktorów, a także umożliwiać tworzenie procesów redakcji danej pozycji, definiowanie statusów obiektów w systemie podlegających redakcji, dodawanie komentarzy do procesu redakcyjnego.

29. Pozwalać na posadowienie na dowolnej stronie WWW pola wyszukiwawczego. Pole wyszukiwawcze powinno pozwolić na wpisanie zapytania wyszukiwawczego, a po zatwierdzeniu powinno przenosić do wyników wyszukiwania w interfejsie systemu. Posadowienie pola powinno się odbywać poprzez zamieszczenie w kodzie strony WWW dodatkowego kodu.

30. Umożliwiać modyfikację utworzonych list słownikowych.

31. Umożliwiać zabezpieczenie pól przed wprowadzeniem błędnych danych i komunikowanie użytkownikowi o takim błędzie, np. w miejscach gdzie jest możliwe wpisanie nr ISSN, nr zeszytu, tomu, roku, skróconej nazwy czasopisma.

32. Umożliwiać jednoczesną pracę wielu użytkowników w tym samym czasie bez ograniczania ich liczby.

33. Umożliwiać personalizację Systemu u Partnerów Projektu i platformy PPM, w tym prezentację logo POPC i UE.

34. Udostępniać narzędzia bilinkujące pomiędzy danymi w repozytorium a dokumentami pełnotekstowymi na co najmniej jednej innej platformie z zasobami nauki.

35. Posiadać funkcjonalność pozwalającą na obsługę kartoteki wzorcowej MeSH (w wersji U.S. National Library of Medicine), w tym przechowywanie i aktualizację rekordów haseł wzorcowych, umożliwienie powiązania haseł wzorcowych z opisami publikacji, stosowanie odsyłaczy, synonimów, terminów o szerszym i węższym znaczeniu (w przypadku kartotek hierarchicznych), z możliwością implementacji kartotek z innych wersji językowych.

36. Umożliwiać użytkownikom wewnętrznym samodzielną rejestrację w systemie i powiadamiać redaktora o założeniu nowego konta w celu jego weryfikacji.

37. Wykonawca zapewni w systemie API, wraz ze specyfikacją i dokumentacją techniczną, dla co najmniej:

- części systemu gromadzącego dorobek naukowy dla wdrożeń lokalnych i wdrożenia centralnego,

- części systemu gromadzącego potencjał badawczy dla wdrożeń lokalnych i wdrożenia centralnego,

- repozytorium dokumentów piśmienniczych dla wdrożeń lokalnych i wdrożenia centralnego,

- repozytorium surowych danych badawczych dla wdrożeń lokalnych i wdrożenia centralnego.

ii) Zawierać odnośnik do strony informacyjnej o projekcie: xxx.xxx.xxx.xx.

1.2. System będzie składał się co najmniej z następujących funkcjonalności:

1. profil naukowca,

2. dorobek naukowy,

3. repozytorium, w tym:

- publikacje i dokumenty piśmiennicze,

- dane badawcze,

4. potencjał badawczy,

5. interfejs import/eksport,

6. raportowanie i statystyki.

Wszystkie moduły zamawianego oprogramowania muszą tworzyć system zintegrowany, tzn. zapewnić jednokrotne wprowadzanie danych, dostęp do niezbędnych dla danej funkcjonalności danych bez konieczności ich replikowania, kopiowania czy też ponownego wprowadzania, a także natychmiastową widoczność wprowadzonych zmian w danych we wszystkich miejscach, w których dane są wykorzystywane. Jednocześnie System powinien posiadać opcję deduplikacji na poziomie PPM.

3. System powinien umożliwiać pełny dostęp użytkownikom z zaburzeniami słuchu lub wzroku, zgodnie ze standardem WCAG 2.0.

Zgodność systemu z WCAG 2.0 powinna zostać zapewniona poprzez spełnienie minimalnych wymagań dla systemów teleinformatycznych zawartych w załączniku nr 4 do Rozporządzenia RM w sprawie krajowych ram interoperacyjności 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. 2017 poz. 2247):

a) Wszystkie elementy graficzne, jeżeli wystąpią, będą miały zwięzły tekst alternatywny (alt), który opisuje co znajduje się na grafice lub, jeśli grafika jest odnośnikiem - dokąd prowadzi ten odnośnik. Jeśli grafiki są czysto dekoracyjne, będą mieć pusty atrybut alt.

b) Unikać się będzie animowanych elementów, poruszających się tekstów, ponieważ rozpraszają one wszystkich użytkowników nie tylko z niepełnosprawnościami (w szczególności agresywnych i szybko animowanych grafik, gdyż mogą stanowić zagrożenie dla osób cierpiących na padaczkę fotogenną).

c) Wszystkie pliki dźwiękowe (audycje, wywiady, wykłady) będą uzupełnione o transkrypcję tekstową. Odtwarzacze tych plików zamieszczone na stronie pozwolą się obsłużyć za pomocą klawiatury i będą dostępne dla osób niewidomych.

d) Wszystkie pliki wideo zostaną uzupełnione o napisy dla osób niesłyszących. Odtwarzacze będą dostępne dla osób niewidomych i osób korzystających wyłącznie z klawiatury.

e) Wszelkie pliki multimedialne będą dostępne lub udostępnione w postaci alternatywnej.

f) Pliki PDF, Word i inne popularne pliki do ściągnięcia będą przygotowane jako dostępne (np. pliki PDF będą miały strukturę, która pomaga osobom niewidomym przeglądanie takich dokumentów).

g) Teksty będą  opublikowane w czytelny sposób - podzielone na paragrafy, listy i inne sekcje; nie justowane do prawej strony; skróty literowe powinny być rozwinięte w pierwszym wystąpieniu na każdej stronie. Tekst będzie uzupełniony o nagłówki (h1-h6) aby osoby niewidome mogły sprawnie przejść do interesującej ich sekcji.

h) Nawigacja (menu) w obrębie całego serwisu będzie spójna, logiczna i niezmienna oraz dostępna z poziomu klawiatury.

i) Wszystkie elementy aktywne, takie jak odnośniki, banery czy pola formularza, będą mieć wyraźny wizualny fokus (zwykle w postaci ramki widocznej w trakcie nawigacji po stronie klawiszem TAB). Planuje się  wzmocnienie domyślnego fokusa tak, aby był dobrze widoczny także dla osób niedowidzących.

j) Wszystkie odnośniki będą unikalne i zrozumiałe, także poza kontekstem. Nie planuje się używać linków w postaci: „>>” czy „więcej” albo „kliknij tutaj”. Odnośniki nie mogą otwierać się w nowym oknie lub zakładce przeglądarki bez ostrzeżenia.

k) Planuje się zastosowanie usprawnienia w postaci „skip links”, czyli możliwości przejścia bezpośrednio do treści pojedynczej strony. Jest to szczególnie ważne w serwisach, które mają kilkadziesiąt linków w nawigacji/menu głównym.

l) Kontrast kolorystyczny wszystkich elementów przekazujących treść (tekstów, linków, banerów) lub funkcjonalnych będzie miał stosunek jasności tekstu do tła co najmniej 4,5 do 1.

ł) Stronę da się znacząco (co najmniej 200%) powiększyć narzędziami przeglądarki (strona cały czas mieści się poziomo w oknie przeglądarki i nie pokazuje się poziomy pasek przewijania ekranu. Powiększona strona nie może „gubić” treści).

m) Wszystkie tytuły (title) stron będą unikalne i będą informować o treści podstrony na jakiej znajduje się użytkownik. Układ treści w tytule będzie zbudowany wg schematu: [Tytuł podstrony] – [Nazwa Instytucji].

n) Wszystkie podstrony będą oparte o nagłówki. Nagłówki (h1-h6) są podstawowym sposobem porządkowania treści na stronie. Nagłówek h1 powinien być tytułem tekstu głównego na stronie.

o) Do porządkowania treści w tekstach, czy elementów nawigacji będą wykorzystywane listy nieuporządkowane i uporządkowane.

p) Język strony oraz język fragmentów obcojęzycznych będzie określony atrybutem lang.

r) Cytaty będą odpowiednio wyróżnione – co najmniej cudzysłowami.

s) Kod serwisu będzie zgodny ze standardami i nie będzie korzystać z tabel jako elementu konstrukcyjnego strony.

t) Tabele służące do przekazania danych powinny być zbudowane w możliwie prosty sposób i posiadać nagłówki.

u) Wszystkie ramki powinny być odpowiednio zatytułowane.

w) Wszystkie skrypty i aplety będą dostępne dla osób niewidomych i osób korzystających wyłącznie z klawiatury.

y) Formularze, w tym formularz wyszukiwarki, będą zbudowane zgodnie ze standardem (X)HTML. Wszystkie pola formularzy i przyciski powinny być właściwie opisane.

z) Serwis będzie dostępny w przeglądarkach i urządzeniach z wyłączoną obsługą CSS.

Kontroli w zakresie zgodności z WCAG 2.0 będzie poddana szczególnie dostępność wszystkich elementów sterujących portalu z poziomu klawiatury. Będzie również sprawdzana obecność elementów tła pod kątem występowania dynamicznych obrazów tła oraz migających elementów w zakresie 2 Hz do 55 Hz. Sposób zaprojektowania systemu umożliwi odczytywanie zawartości poprzez urządzenia czytające, takie jak JAWS oraz przez wyświetlacze Braille’a. Pomoże to osobom niedowidzącym i niewidomym na skorzystanie z publikacji zawartych w zasobach systemu. Jeżeli gromadzone w systemie zasoby (pliki i dokumenty) będą wymagały dostosowania w celu spełnienia tego wymagania to Wykonawca zapewni instrukcję ich przygotowywania pod kątem zgodności ze standardem WCAG 2.0. Aby poinformować społeczeństwo o szerokiej dostępności systemu i uwiarygodnić jego jakość w tym zakresie, cały audyt zgodności z WCAG 2.0 odbędzie się przy współpracy jednostki certyfikującej, a raport z audytu będzie udostępniony publicznie. Dostępność dla różnych grup użytkowników rozpatruje się nie tylko w zależności od cech indywidualnych osoby, ale również technologii za pomocą której korzystają z zasobów. Prezentowane treści powinny dostosować się do urządzenia wykorzystywanego przez użytkownika. Aby to osiągnąć zastosowana będzie technika Responsive Web Design, czyli sposób projektowania serwisu zapewniający to, aby jego wygląd i układ dostosowywał się automatycznie do rozmiaru okna urządzenia, na którym jest wyświetlany, np. przeglądarki, smartfonów czy tabletów.

1.5. System musi umożliwiać udostępnienie zasobów w sieci Internet na 3, 4 i 5 poziomie otwartości zgodnie z pięciostopniową skalą „5 Star Open Data”.

Przez zgodność z poziomami otwartości wg skali „5 Star Open Data” zamawiający rozumie:

- dla 3 poziomu - udostępnianie zasobów w ustrukturyzowanej postaci i z wykorzystaniem otwartego formatu danych,

- dla 4 poziomu - publikowanie zasobów wraz z odnośnikami do poszczególnych elementów (np. za pomocą metody opisu RDF), co pozwala na bezpośrednie linkowanie do nich w sieci,

- dla 5 poziomu - publikowanie zasobów wraz z odnośnikami do innych zbiorów, stanowiących dla tych informacji kontekst (tzw. linked open data).

1.6. Zamawiający oczekuje, że Wykonawca potwierdzi zgodność Systemu na wymaganych przez Zamawiającego poziomach otwartości i dostarczy opis sposobu ich realizacji. Zamawiający dokona oceny zgodności udostępnionych zasobów na podstawie wytycznych opracowanych przez Open Data Institute.

1.7. Zamawiający ocenia, że treści publikowane w systemie będą charakteryzować się następującym poziomem otwartości danych:

	Rodzaj zasobu	Liczba zasobów nauki [szt.]	Poziom otwartości (5 Star Open Data)	Liczba zasobów nauki spełniająca dany poziom otwartości [szt.]
Zasoby nauki	Pełne teksty	19.988	***	100%
			****	75%
			*****	50%
	Inne dokumenty	18.771	***	100%
			****	60%
			*****	30%
	Dane badawcze	376	***	100%
			****	100%
			*****	90%
	Metadane (opisy bibliograficzne)	210.472	***	100%
			****	100%
			*****	90%

1.8. System musi spełniać wymogi przepisów prawa w zakresie ochrony danych osobowych oraz wymiany danych z innymi systemami teleinformatycznymi, w szczególności System musi spełniać co najmniej wymogi bezpieczeństwa zawarte w:

- Rozporządzeniu Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne rozporządzenie o ochronie danych),

- Rozporządzeniu Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r., poz. 1024, 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,

- Ustawie z dnia 17 lutego 2005 r., poz. 570, o informatyzacji działalności podmiotów realizujących zadania publiczne,

- Obwieszczeniu Prezesa Rady Ministrów z dnia 9 listopada 2017 r., poz. 2247, w sprawie ogłoszenia jednolitego tekstu rozporządzenia Rady Ministrów 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.

1.9. System powinien mieć możliwość rozróżniania czterech grup użytkowników i gwarantować, że każda z tych grup będzie miała dostęp jedynie do tych rodzajów treści lub funkcji do korzystania z których jest upoważniona.

System powinien umożliwiać administratorom nadawanie poszczególnym użytkownikom właściwych im uprawnień.

1.10. Grupy użytkowników:

1. administratorzy,

2. redaktorzy,

3. użytkownicy wewnętrzni,

4. użytkownicy zewnętrzni.

1.11. System powinien umożliwiać administratorowi lokalnemu oraz administratorowi platformy PPM korzystanie z co najmniej wymienionych niżej funkcjonalności:

1. Ustalanie pól obowiązkowych.

2. Zarządzanie wymianą danych między platformą PPM a bazami Partnerów Projektu.

3. Zarządzanie wyglądem interface’u WWW, np. poprzez modyfikację css.

4. Zarządzanie funkcjonalnościami związanymi z wyszukiwaniem, w szczególności wybór preferowanych faset, pól wyszukiwawczych, zawartości indeksów.

5. Możliwość przeglądania i analizowania logów systemowych oraz informacji o historii operacji.

6. Otrzymywanie alertów o nieprawidłowościach w działaniu systemu (np. bazy danych, serwera www, parametry pracy i zajętości dysku, itp.).

7. Przeprowadzanie testów zabezpieczeń systemów odpowiednio na poziomie lokalnym i centralnym. Testy zabezpieczeń będą polegały na sprawdzeniu poprawności funkcjonowania mechanizmów wymiany danych pomiędzy instalacją lokalną a platformą PPM uwzględniających uwierzytelnienie oraz sposób mapowania i zakres pól z baz zewnętrznych do systemu macierzystego w zależności od nadanych uprawnień.

8. Projektowanie szablonów statystyk i raportów.

9. Generowanie i drukowanie statystyk i raportów na podstawie szablonów.

1.12. Ponadto System powinien umożliwiać administratorowi lokalnemu co najmniej:

1. Zakładanie i zarządzanie kontami w Systemie (co najmniej: usuwanie, blokowanie, zarządzanie danymi uwierzytelniającymi), zarządzanie uprawnieniami: redaktorów, użytkowników wewnętrznych, użytkowników zewnętrznych. Prawa dostępu powinny być przydzielane na poziomie operacji (co najmniej: przeglądanie, drukowanie, dodawanie, usuwanie, edycja danych) oraz na poziomie rodzaju danych (co najmniej dane profilu naukowca i dorobku naukowego).

2. Zarządzanie wymianą danych między serwerem lokalnym a platformą PPM, w tym ustalanie sposobu mapowania i zakresu pól z baz zewnętrznych do systemu macierzystego.

3. Ustalanie katalogu pól widocznych dla użytkownika wewnętrznego oraz dla użytkownika zewnętrznego.

4. Konfiguracja tworzenia kopii zapasowych danych poprzez ustawienie zakresu i czasu tworzenia kopii zapasowych zgodnie z przyjętą polityką bezpieczeństwa.

5. Konfiguracja zasad komunikacji automatycznej redaktora z użytkownikiem zarejestrowanym.

6. Przeprowadzanie, w porozumieniu z centralnym administratorem systemu, lokalnych testów zabezpieczeń systemu. Testy zabezpieczeń będą polegały na sprawdzeniu poprawności funkcjonowania mechanizmów wymiany danych pomiędzy instalacją lokalną a platformą PPM uwzględniających uwierzytelnienie oraz sposób mapowania i zakres pól z baz zewnętrznych do systemu macierzystego w zależności od nadanych uprawnień.

1.13. System powinien umożliwić na poziomie instalacji centralnej co najmniej:

1. zachowanie funkcji instalacji lokalnych,

2. konfigurację w celu spełnienia potrzeb Partnerów Projektu ustaloną w trakcie analizy przedwdrożeniowej,

3. regularne importowanie danych z systemów lokalnych,

4. deduplikację danych pozyskanych z systemów lokalnych,

5. wyodrębnianie w wyszukiwarce indywidualnych materiałów każdego z Partnerów.

1.14. System powinien spełniać następujące normy związane z projektowaniem zorientowanym na użytkownika ISO/TR 16982:2002, ISO-9241 lub równoważne. System będzie zawierał kanały komunikacji z użytkownikami w postaci:

1. specjalnego formularza ułatwiającego kontakt 24/7/365 z administratorem platformy,
   z ułatwieniem polegającym na wylistowaniu listy tematów, których dotyczy zapytanie lub zgłaszany problem,

2. stworzenia możliwości kontaktu telefonicznego z lokalnym (instytucjonalnym) help deskiem w określonych godzinach,

3. cyklicznego przeprowadzania ankiet satysfakcji badających opinie na temat platformy, stanowiących punkt wyjścia dla działań podnoszących jakość świadczonej usługi,

4. list FAQ dostosowanych do pytań pojawiających się ze strony użytkowników; itp.

II. Wskaźniki altmetryczne i bibliometryczne

2.1. System powinien umożliwiać prezentację wskaźników bibliometrycznych dla rekordu metadanowego publikacji i dla publikacji zdeponowanych w repozytorium, pozyskiwanych poprzez interfejs programowania aplikacji lub wprowadzanych ręcznie, co najmniej:

• Impact Factor,

• CiteScore,

• Liczba cytowań publikacji na podstawie co najmniej jednego ze źródeł, tj. WoS CC lub Scopus, z podaniem źródła, z którego zostały zaczerpnięte,

• Punktacja MNiSW.

2.2. System powinien umożliwiać prezentację wskaźników bibliometrycznych odnoszących się do publikacji właściciela profilu, których metadane znajdują się na platformie, co najmniej:

• Sumaryczny IF,

• Sumaryczny CiteScore,

• Liczba cytowań publikacji pracownika na podstawie co najmniej jednego ze źródeł, tj. WoS CC lub Scopus, z podaniem źródła, z którego zostały zaczerpnięte,

• Indeks Hirscha wyliczony na podstawie cytowań publikacji indeksowanych przez co najmniej jedno ze źródeł, tj. WoS CC lub Scopus, z podaniem źródła, z którego zostały zaczerpnięte,

• Łączna punktacja MNiSW.

2.3. System powinien umożliwiać implementację wartości punktowych na podstawie wykazów czasopism naukowych MNiSW lub pobieranie tych wartości za pomocą API w przypadku, gdy Ministerstwo Nauki i Szkolnictwa Wyższego zapewni taką możliwość.

2.4. System powinien umożliwiać analizę publikacji zdeponowanych w repozytorium za pomocą wskaźników altmetrycznych, odnoszących się do:

• użytkowania,

• rejestrowania,

• wzmianek,

• obecności w mediach społecznościowych,

• cytowani z innych źródeł niż WoS CC lub Scopus.

III. Profile naukowców

3.1. System powinien umożliwiać:

1. tworzenie dla każdego pracownika naukowego Zamawiającego profilu naukowca oraz opatrzenie go co najmniej wymaganymi danymi,

2. wyszukiwanie oraz przeglądanie profili naukowców,

3. prezentowanie wskaźników bibliometrycznych i altmetrycznych zgodnie z ust. II OPZ,

4. indywidualny wybór przez pracowników naukowych ustawień widoczności profilu.

3.2. Wymagane dane:

Nazwa pola	Grupy danych	Indeksowalne	Sposób pobierania danych	Powiązania	Tłumaczenie danych na język angielski dla angielskiej wersji interfejsu	Pole wielokrotne	Opis/uwagi
Nazwisko	Informacje ogólne	TAK	API/RĘCZNIE	BRAK	NIE	NIE	Lista rozwijana po zaciągnięciu danych przez API/RĘCZNIE
Imiona	Informacje ogólne	TAK	API/RĘCZNIE	BRAK	NIE	NIE	Lista rozwijana po zaciągnięciu danych przez API/RĘCZNIE
Zdjęcie	Informacje ogólne	NIE	RĘCZNIE	BRAK	NIE	NIE
Stopień naukowy/tytuł (aktualny)	Informacje ogólne	TAK	API/RĘCZNIE	BRAK	TAK	NIE
Nazwa uczelni/instytutu	Informacje ogólne	TAK	LISTA	Do wydziałów	TAK	NIE	Linkowanie do strony instytucji poprzez nazwę
Wydział	Informacje ogólne	TAK	LISTA	Do jednostek	TAK	NIE
Jednostka	Informacje ogólne	TAK	LISTA	Do nazwisk	TAK	NIE	Linkowanie do strony jednostki poprzez nazwę
Stanowisko	Informacje ogólne	TAK	LISTA	BRAK	TAK	NIE
Funkcja	Informacje ogólne	NIE	LISTA	BRAK	TAK	TAK
E-mail	Informacje ogólne	NIE	API/RĘCZNIE	BRAK	NIE	TAK
Telefon	Informacje ogólne	NIE	RĘCZNIE	BRAK	NIE	TAK
Adres jednostki	Informacje ogólne	NIE	LISTA/RĘCZNIE	BRAK	NIE	NIE
Przebieg kariery	Działalność naukowa	NIE	LISTA/RĘCZNIE	BRAK	NIE	TAK	Data dla stopnia i tytułu oraz lista stopni i tytułów
Dyscyplina	Działalność naukowa	TAK	LISTA	Do dorobku naukowego	TAK	TAK	Lista zamknięta określona w Rozporządzeniu MNiSW w sprawie klasyfikacji dziedzin i dyscyplin.
Pole badawcze	Działalność naukowa	TAK	LISTA/RĘCZNIE	Do dorobku naukowego i potencjału badawczego	TAK	TAK
Zespoły badawcze	Działalność naukowa	TAK	RĘCZNIE lub LISTA	Do strony zespołu	NIE	TAK	Nazwa zespołu po wpisaniu ręcznym dodawana jest do indeksu
Identyfikator naukowca: ORCID	Działalność naukowa	NIE	API/RĘCZNIE	LINK	NIE	NIE
Inne identyfikatory naukowca	Działalność naukowa	NIE	API/RĘCZNIE	LINK	NIE	TAK	Co najmniej: Researcher ID, Scopus Author ID.
Granty	Działalność naukowa	NIE	API/RĘCZNIE	LINK	NIE	TAK	Linkowanie do potencjału badawczego
Publikacje	Działalność naukowa	NIE	API/RĘCZNIE	XXXX	NIE	TAK	Linkowanie do dorobku naukowego i repozytorium
Dane badawcze	Działalność naukowa	NIE	API/RĘCZNIE	XXXX	NIE	TAK	Linkowanie do repozytorium
Patenty	Działalność naukowa	NIE	API/RĘCZNIE	LINK	NIE	TAK	Linkowanie do potencjału badawczego
Osiągnięcia naukowe	Działalność naukowa	NIE	RĘCZNIE	BRAK	TAK/NIE	TAK	Pole tekstowe
Nagrody i wyróżnienia	Działalność naukowa	NIE	API/RĘCZNIE	BRAK	TAK/NIE	TAK	Linkowanie do potencjału badawczego, dorobku naukowego i repozytorium
Promotorstwo	Działalność naukowa	NIE	RĘCZNIE	Do profilu doktoranta i do pracy doktors-kiej w repozytorium	NIE	TAK	Pole zawiera nazwisko i imię doktoranta oraz tytuł pracy doktorskiej
Profile na portalach społecznościowych	Inne	NIE	RĘCZNIE	LINK	NIE	TAK	Co najmniej: Facebook, GoldenLine, Google+, Linkedln, Mendeley, Research Gate, Twitter.
Specjalność	Inne	TAK	LISTA	BRAK	TAK	TAK	Lista zamknięta z możliwością dodawania przez administratora systemu.
Członkostwo w organizacjach	Inne	TAK	RĘCZNIE	BRAK	NIE	TAK	Nazwa organizacji po wpisaniu ręcznym dodawana jest do indeksu
Funkcje pełnione w organizacjach	Inne	NIE	RĘCZNIE	BRAK	TAK/NIE	TAK
Redaktor naczelny, członek redakcji	Inne	NIE	RĘCZNIE	BRAK	TAK/NIE	TAK	Pole tekstowe
Osobista strona WWW	Inne	NIE	RĘCZNIE	LINK	NIE	TAK
O mnie	Inne	NIE	RĘCZNIE	BRAK	TAK/NIE	NIE	Pole tekstowe
Wskaźniki altmetryczne i bibliometryczne	Inne		AUTOMAT				Zaczytywane z zewnętrznych systemów, wyświetlane także przy publikacji

IV. Dorobek naukowy

1. System powinien:

1. umożliwiać automatyczne pozyskiwanie, przechowywanie i prezentowanie dorobku naukowego oraz raportowanie otrzymanych wyników wyszukiwania,

2. zawierać pola metadanych: publikacji, dysertacji i innych dokumentów piśmienniczych oraz danych badawczych,

3. umożliwiać automatyczne prezentowanie i aktualizowanie z częstotliwością ustalona przez Zamawiającego co najmniej następujących wskaźników:

- cytowania z bazy WoS CC lub Scopus,

- Impact Factor,

- CiteScore,

4. posiadać funkcjonalność umożliwiającą eksportowanie danych do innych serwisów, co najmniej do: EndNote, Mendeley, BibTex, RefWorks,

5. umożliwiać stosowanie indeksów,

6. umożliwiać modyfikację indeksów,

7. wyświetlać podpowiedzi dotyczące dodawanych bądź edytowanych danych po najechaniu kursorem na pole lub przycisk,

8. uniemożliwiać wprowadzenie błędnych danych i komunikować użytkownikowi o błędzie,

9. umożliwiać prezentację wyników w postaci pełnego i skróconego opisu bibliograficznego,

10. umożliwiać sortowanie wyników wyszukiwania co najmniej alfabetycznie, chronologicznie i wg typu dokumentu,

11. umożliwiać eksportowanie danych o publikacjach pracownika naukowego do ORCID tak, aby stanowiły integralną część profilu ORCID pracownika.

1. System powinien umożliwiać wprowadzanie co najmniej następujących metadanych opisujących dorobek naukowy:

1. Autor/Autorzy,

2. Afiliacja,

3. Współtwórcy,

4. Tytuł,

5. Wariant tytułu,

6. Tytuł źródła,

7. Numer wydania,

8. Rok powstania,

9. Rok wydania/emisji,

10. Miejsce wydania/powstania,

11. Tom/Numer/Suplement,

12. Numer artykułu elektronicznego,

13. Ilość/zakres stron/slajdów,

14. Język dokumentu,

15. Seria,

16. ISBN/ISSN,

17. Promotor,

18. Wydawca,

19. Format/rodzaj pliku,

20. Hasła MeSH polsko- i anglojęzyczne,

21. Dyscyplina,

22. Abstrakt,

23. Typ dokumentu,

24. Prawa/licencja,

25. Powiązania z innymi obiektami,

26. DOI,

27. Identyfikator pozycji,

28. Uwagi.

V. Repozytorium dokumentów pełnotekstowych i danych badawczych

1. System powinien umożliwiać co najmniej:

1. rejestrowanie i gromadzenie różnego typu danych, w tym dokumentów pełnotekstowych i danych badawczych,

2. opisanie dokumentów zamieszczonych w repozytorium za pomocą metadanych wymienionych w ust. D pkt. 4.2.,

3. automatyczne importowanie metadanych ze źródeł zewnętrznych, w tym własnych systemów bibliograficznych, baz WoS, Scopus, menedżerów bibliografii,

4. pobieranie metadanych bezpośrednio z innych repozytoriów, co najmniej OpenDOAR, Re3Data i ROAR,

5. ręczne wprowadzanie metadanych,

6. deponowanie plików zarówno przez redaktorów repozytorium, jak i przez uprawnionych użytkowników wewnętrznych po uprzednim zalogowaniu się do Systemu,

7. deponowanie kilku plików w różnych formatach przy jednym opisie metadanych i przechowywania w systemie informacji o typie zdeponowanych danych,

8. pobieranie/odtwarzanie dokumentów zgodnie z uprawnieniami poszczególnych grup użytkowników nadanymi przez administratora,

9. redaktorom: edytowanie odpowiednich pól z danymi w celu zatwierdzenia lub modyfikowania poprawności ich zawartości,

10. zalogowanym użytkownikom wewnętrznym: wysyłanie z poziomu wyświetlonego rekordu formularza z sugestią korekty zamieszczonych w tym rekordzie danych; System powinien umożliwiać zdefiniowanie adresu, na jaki mają być kierowane te wiadomości,

11. wyświetlanie kolekcji nowo dodanych dokumentów,

12. nadawanie każdemu dokumentowi unikalnego identyfikatora rekordu w repozytorium,

13. wskazywanie licencji Creative Commons lub innej licencji, na jakiej nastąpi udostępnienie dokumentów pełnotekstowych lub danych badawczych oraz pobranie tej informacji do wyświetlenia w danych szczegółowych rekordu,

14. zabezpieczenie przed kopiowaniem przez użytkowników dokumentów udostępnianych na innych licencjach niż otwarte,

15. gromadzenie plików bez kompresji, nie wymagających komercyjnego oprogramowania, w formatach otwartych z dostępną dokumentacją, z wykorzystaniem standardowego kodowania (ASCII, Unicode),

16. spełnianie kryteriów rejestracji repozytorium co najmniej w: Xx0xxxx.xxx, OpenDOAR, ROAR i połączenie z globalną siecią repozytoriów w celu lepszego wykrywania i popularyzacji dorobku Partnerów Projektu.

2. W zakresie repozytorium dokumentów pełnotekstowych System powinien umożliwiać co najmniej:

a) gromadzenie dokumentów pełnotekstowych, w tym: artykułów w czasopismach, książek, fragmentów książek, rozpraw doktorskich, innych dokumentów piśmienniczych, w różnych formatach, co najmniej: pdf, doc i innych zgodnych ze standardem 5 Star Open Data,

b) wprowadzanie dodatkowych pól opisu metadanowego, co najmniej takich jak:

- data udostępnienia w repozytorium,

- wersja publikacji (wersja wydawcy, postprint, preprint),

- data ostatniej modyfikacji rekordu,

- instytucja finansująca badania,

- numer grantu,

- wzór cytowania,

c) deponowanie i przechowywanie tej samej publikacji w różnych jej wersjach, co najmniej: preprint, postprint, wersja wydawcy z informacją o wersji publikacji.

d) przechowywanie plików zdeponowanych w systemie lub zaimportowanych do systemu w dwóch buforach:

- dla rekordów przed zatwierdzeniem przez redaktorów,

- dla rekordów z embargiem,

e) automatyczne kontrolowanie upływu okresu embarga dla tego typu prac oraz po jego upłynięciu uwidocznienie pełnego tekstu pracy w odpowiedniej wersji,

f) automatyczne tworzenie i dołączanie – jako pierwszej strony – do zdeponowanego pełnego tekstu publikacji, specjalnych informacyjnych metryk, zawierających następujące informacje:

- logo repozytorium/PPM z nazwą i adresem internetowym,

- logo uczelni/instytutu z nazwą i adresem,

- opis bibliograficzny publikacji oraz DOI,

- DOI rekordu w repozytorium,

- otwarty dostęp / rodzaj licencji,

g) wyświetlanie na każdej kolejnej stronie zdeponowanych prac logo PPM z komunikatem, że praca pochodzi ze zbiorów repozytorium jednostki deponującej publikację,

h) wyświetlanie informacji (preferowana forma graficzna) o otwartym dostępie do zdeponowanej pracy na wszystkich ekranach prezentujących informację o danej pracy; w przypadku gdy dostęp do pełnej wersji publikacji będzie możliwy po okresie embarga, informacja o tym okresie powinna być również wyświetlona użytkownikowi,

i) prezentowanie informacji o wskaźnikach oddziaływania dotyczących cytowań, tj. bibliometrycznych (WoS, Scopus) oraz altmetrycznych (Facebook, Twitter, ResearchGate, Mendeley itp.),

j) automatyczne sprawdzanie w serwisie SHERPA/RoMEO polityki wydawców wobec archiwizacji prac w czasopismach i prezentowanie na podstawie tego źródła informacji o rodzaju licencji Creative Commons, na jakiej możliwe jest udostępnienie publikacji oraz jej pobranie,

k) tworzenie linków do słów kluczowych w tytułach i abstraktach zdeponowanych plików, zgodnie z modelem 5 Star Open Data w celu powiązania danych z innymi danymi w sieci,

l) sygnalizowanie po rozpoczęciu wyszukiwania przez użytkownika lub redaktora, że w bazie znajduje się opis bibliograficzny pracy,

ł) wyświetlenie danych podstawowych, tj.: tytuł i wariant tytułu, autorstwo (nazwisko i imię lub inicjał imienia) artykułu, rozdziału, książki, dysertacji, nazwiska współtwórców (np. promotor, redaktor), źródło (tytuł czasopisma, rok wydania/emisji, volumen, zeszyt, numer artykułu elektronicznego, zakres stron/liczba stron), seria, wydawca, miejsce wydania, wydanie, DOI, format pliku, dziedzina, hasła przedmiotowe MeSH, powiązania z innymi obiektami (w tym tytuł książki, której rozdział jest fragmentem, nazwa konferencji), afiliacja, informacja o otwartym dostępie do publikacji) z możliwością przejścia do danych szczegółowych, wyświetlanych sumarycznie z danymi podstawowymi, tj.: uwagi, abstrakt, język publikacji, typ publikacji (wg słownika), ISSN, ISBN, data udostępnienia w repozytorium, data ostatniej modyfikacji rekordu, identyfikator pozycji, instytucja finansująca, numer grantu, wskaźniki altmetryczne i cytowania, licencje, rozmiar pliku/plików wraz z możliwością wyszukiwania po tych polach,

m) pobieranie plików co najmniej w formacie pdf i innych zgodnych ze standardem 5 Star Open Data,

n) obserwowanie przez autora informacji o swoim artykule w mediach społecznościowych i blogach naukowych.

5.3. W zakresie repozytorium danych badawczych System powinien umożliwiać:

a) gromadzenie danych badawczych co najmniej typu: nagrania audio, nagrania video, dokumenty tekstowe, oprogramowanie, pliki graficzne,

b) gromadzenie danych badawczych w różnych formatach, np.:

Typ	Format rekomendowany	Format niepreferowany
Tabulardata	CSV, TSV, SPSS portable	Excel
Tekst	Plain text, HTML, RTF PDF/A only if layout matters	Word
Media	Container: MP4, Ogg Codec: Theora, Dirac, FLAC	Quicktime H264
Obrazy	TIFF, JPEG2000, PNG	GIF, JPG
Dane ustrukturyzowane	XML, RDF	RDBMS

c) deponowanie kilku plików w różnych formatach przy jednym opisie metadanych i przechowywanie w systemie informacji o typie zdeponowanych danych badawczych,

d) wyświetlanie danych podstawowych, tj.: tytułu, nazwiska autorów, opisu, identyfikatora, hasła przedmiotowego MeSH, daty powstania danych, linku dostępu do źródła, powiązanej publikacji, afiliacji, z możliwością przejścia do danych szczegółowych, tj.: daty udostępnienia w repozytorium, języka danych, obszaru badań, typu zasobu, instytucji finansującej, numeru grantu, cytowania, licencji, rozmiaru pliku, wyświetlanych sumarycznie z danymi podstawowymi wraz z możliwością wyszukiwania po tych polach.

e) wprowadzenie dodatkowych pól opisu metadanowego, co najmniej takich jak:

- data udostępnienia w repozytorium,

- opis,

- typ zasobu,

- numer projektu/grantu,

- nazwa instytucji finansującej,

- dostęp do zbioru danych,

- wzór cytowania.

VI. Potencjał badawczy

6.1. System powinien zapewnić automatyczne i manualne pozyskiwanie, gromadzenie, kontrolowanie i prezentowanie co najmniej następujących informacji o potencjale badawczym Partnerów Projektu:

a) patenty,

b) projekty naukowe,

c) finansowanie grantów,

d) aparatura badawcza,

e) laboratoria,

f) konferencje/wydarzenia,

g) nagrody i wyróżnienia.

6.2. Patenty – wymagane dane:

• nazwa,

• opis,

• dyscyplina,

• numer Międzynarodowej Klasyfikacji Patentowej,

• jednostka powiązana,

• status (przyznany, zgłoszony),

• nazwisko twórcy/twórców,

• data zgłoszenia,

• data przyznania,

• numer,

• obszar obowiązywania/kraj.

6.3. Projekty naukowe - wymagane dane:

• tytuł projektu,

• numer projektu,

• rodzaj projektu,

• kierownik projektu,

• skład zespołu projektowego,

• słowa kluczowe,

• dyscyplina/dziedzina,

• rola jednostki w zarządzaniu projektem,

• informacja o wysokości środków finansowych ogółem przyznanych na realizację projektu (w podziale na lata),

• nazwy instytucji lub jednostek współrealizujących projekt,

• nazwa instytucji finansującej,

• nazwa programu albo przedsięwzięcia, w ramach którego projekt jest finansowany,

• czas realizacji projektu,

• status,

• opis projektu,

• opis efektów (publikacje, patenty, wdrożenia i inne).

6.4. Finansowanie – wymagane dane:

• System powinien automatycznie wskazywać użytkownikom wewnętrznym informacje o ogłoszonych grantach i dostępnych dla nich programach finansujących, proponując poszczególne programy grantowe w oparciu o pola badawcze, dotychczasowe publikacje bądź wcześniej uzyskane granty oraz umożliwiać tworzenie i konfigurację indywidualnych filtrów tak, aby zagwarantować, że będą oni informowani jedynie o odpowiadających im możliwościach finansowania.

• System powinien prezentować dane przynajmniej jednego uznanego polskiego grantodawcy, tj. NCBiR, NCN, FNP lub MNiSW,

• System powinien prezentować dane przynajmniej jednego uznanego zagranicznego grantodawcy, tj. NIH, NSF lub ERC,

• System powinien zawierać kompletne rozwiązanie wspomagające zarządzanie przepływem dokumentów, zgodnie z przyjętą polityką postępowania w sprawie aplikacji grantowych u każdego z Partnerów Projektu,

• System powinien udostępniać w postaci raportów pełną informację na temat przygotowywanych, złożonych oraz zaakceptowanych wniosków grantowych oraz grantów.

6.5. Aparatura badawcza – wymagane dane:

• nazwa,

• jednostka naukowa odpowiedzialna za infrastrukturę,

• użytkownik infrastruktury,

• charakterystyka zastosowania infrastruktury,

• stan urządzenia,

• rok produkcji.

6.6. Laboratoria – wymagane dane:

• dane adresowe,

• profil działalności,

• zakres przyznanych uprawnień,

• okres obowiązywania przyznanych uprawnień,

• wdrożone systemy jakości – nazwa systemu i okres ważności.

6.7. Konferencje / wydarzenia – wymagane dane:

• nazwa i temat,

• rok, data rozpoczęcia i data zakończenia konferencji,

• miejsce,

• rodzaj (krajowa, międzynarodowa),

• liczba prelegentów,

• liczba uczestników,

• liczba jednostek naukowych, których przedstawiciele brali udział w konferencji.

6.8. Nagrody i wyróżnienia – wymagane dane:

• nazwa nagrody/wyróżnienia,

• nazwa laureata,

• rodzaj uhonorowanej działalności,

• organ lub instytucja przyznająca,

• rok przyznania.

VII. Analizy i raporty

7.1. System musi umożliwiać:

1. tworzenie dowolnych raportów w oparciu o dane przechowywane w Systemie według dowolnych kryteriów w szczególności według typu publikacji, autora, jednostki, roku itd.

2. przygotowywanie szablonów raportów do późniejszego wykorzystania,

3. przypisanie szablonów raportów do poszczególnych użytkowników posiadających konto w Systemie,

4. automatyczne generowanie raportu w zadanym okresie na podstawie przygotowanego wcześniej szablonu,

5. eksportowanie raportów do otwartych formatów oraz formatów takich jak: pdf, doc, arkusz kalkulacyjny,

6. prezentowanie danych w raportach w postaci graficznej, np. wykresy liniowe, kołowe, słupkowe itp.,

7. pozyskiwanie treści przez Google Analytics lub usługę równoważną w celu śledzenia ruchu w witrynie platformy PPM.

7.2. Na etapie wdrożenia Wykonawca przygotuje gotowe szablony raportów umożliwiające uzyskanie informacji o:

1. historii wejść z podziałem na wejścia bezpośrednie, wejścia z wyszukiwarek, wejścia z linków odsyłających oraz lokalizację odwiedzjących,

2. liczbie unikalnych użytkowników odwiedzających platformę,

3. najczęściej odwiedzanych stronach na platformie,

4. średnim czasie trwania odwiedzin użytkownika platformy,

5. rodzaju przeglądarek używanych przez użytkowników,

6. liczbie pobrań/odtworzeń publikacji z podziałem na unikatowych użytkowników,

7. historii aktywności użytkowników posiadających konto w Systemie z uwzględnieniem rodzaju wykonywanych operacji (logowanie, tworzenie, edycja, usuwanie danych),

8. historii zdeponowanych prac w repozytorium.

E. WDROŻENIE

I. Wdrożenie

1.1. Zamawiający wymaga, aby proces wdrożenia systemu był prowadzony zgodnie z zaplanowanym Harmonogramem stanowiącym załącznik do Umowy i w ramach zaplanowanego budżetu. Zamawiający wymaga, aby Wykonawca na etapie wdrożenia wykonał wszystkie prace opisane w niniejszym dokumencie, chyba że jawnie zostały oznaczone jako dodatkowe, a Wykonawca nie zobowiązał się ich dostarczyć, jak również inne niezbędne prace wynikające z przeprowadzonej analizy przedwdrożeniowej i harmonogramu wdrożenia.

1.2. Wykonawca powinien przed rozpoczęciem procesu wdrożenia przekazać Zamawiającemu:

1. szczegółowe informacje dotyczące prognozowanych czynności wdrożeniowych,

2. szczegółowe informacje dotyczące etapów wdrożenia,

3. szczegółowe informacje dotyczące harmonogramu wdrożenia,

4. skład i CV członków zespołu wdrożeniowego,

5. metodę zapewnienia sprawnej i skutecznej komunikacji i współpracy w czasie procesu wdrożenia,

6. analizę ryzyk i problemów mogących wystąpić na etapie wdrożenia wraz ze sposobem łagodzenia ich skutków i ewentualnych działań naprawczych.

II. Metodyka Wdrożenia

2.1. Zamawiający wymaga, aby Wykonawca posiadał doświadczenie w zakresie wdrażania podobnych systemów oraz dysponował zespołem specjalistów, w celu sprawnego przygotowania wdrożenia i zagwarantowania bezproblemowego uruchomienia Systemu.

2.2. Wykonanie prac przez Wykonawcę musi odbywać się zgodnie z jedną z uznanych metodyk zarządzania projektami, np. PRINCE 2, PMI. Osoba odpowiedzialna za projekt ze strony Wykonawcy realizująca przedmiot zamówienia musi legitymować się certyfikatem kierownika projektu (Project Manager) z metodyki zarządzania projektami.

2.3. Xxxxxxxxx projektu winien posiadać doświadczenie w prowadzeniu projektów informatycznych. Zaleca się by projekt był prowadzony przez tego samego kierownika przez cały okres.

2.4. Przez cały okres trwania projektu minimalny skład zespołu projektowego Wykonawcy, oprócz kierownika projektu, to minimum 3 osoby. Skład zespołu musi być przedstawiony Zamawiającemu, a w razie zmian niezwłocznie uaktualniany. Osoba zastępująca musi spełniać co najmniej wymagania określone dla osoby zastępowanej.

2.5. Zamawiający realizuje projekt, o którym mowa w punkcie E.IV.4.2. Opisu Przedmiotu Zamówienia w oparciu o metodykę zarządzania projektami zgodną z kryterium oceny merytorycznej projektów nr 20 w konkursie nr POPC.02.03.01-IP.00-00-000/16.

III. Zespół projektowy

3.1. Zamawiający powoła zespół projektowy odpowiedzialny za przebieg wdrożenia Systemu. Zespół wdrożeniowy po stronie Zamawiającego:

• kierownik projektu - odpowiadający za organizację i koordynację działań, zapewnienie odpowiedniego przepływu informacji pomiędzy Zamawiającym a Wykonawcą, terminowe odbiory częściowe i końcowe etapów wdrożenia oraz rozwiązywanie bieżących problemów z procesem wdrożenia po stronie Zamawiającego,

• koordynatorzy projektu - odpowiadający za realizację wdrożeń na poziomie lokalnym, zapewnienie odpowiedniego przepływu informacji pomiędzy Zamawiającym a Wykonawcą, terminowe odbiory częściowe oraz rozwiązywanie bieżących problemów z procesem wdrożenia na poziomie lokalnym,

• członkowie zespołu wdrożeniowego - osoby posiadające wiedzę merytoryczną z zakresu objętego wdrożeniem u każdego z uczestników Projektu.

3.2. Zespół projektowy po stronie Wykonawcy:

• Kierownik Projektu – ze strony Wykonawcy. Odpowiedzialny za koordynowanie działań podczas przygotowania projektu, zaplanowanie projektu, zapewnienie odpowiedniej komunikacji po stronie Wykonawcy. Nadzoruje opracowanie szczegółowego harmonogramu projektu. Odpowiedzialny za prowadzenie dokumentacji projektu, nadzorowanie prac zespołu wdrożeniowego, realizacji celów projektu, przestrzegania harmonogramu, za zarządzanie zmianami w projekcie. Osoba odpowiedzialna za rozwiązywanie ewentualnych problemów z realizacją projektu po stronie Wykonawcy.

• Konsultanci – ze strony Wykonawcy (min. 8 osób). Osoby merytorycznie przygotowane, posiadające kompetencje do wdrożenia poszczególnych elementów systemu zatrudnione nie krócej niż 6 miesięcy u Wykonawcy.

IV. Analiza przedwdrożeniowa

4.1. W celu przygotowania do wdrożenia Systemu Wykonawca musi przeprowadzić analizę przedwdrożeniową.

Analiza przedwdrożeniowa musi obejmować prace polegające na rozpoznaniu warunków panujących u Lidera i Partnerów Projektu oraz zdefiniowaniu sposobu i zakresu ich implementacji do wdrażanego Systemu. Wykonawca powinien zapoznać się z systemami wykorzystywanymi przez Partnerów Projektu i określić możliwość i sposób ich integracji z Systemem.

Analiza przedwdrożeniowa będzie miała na celu:

• uszczegółowienie koncepcji wdrożenia,

• zmniejszenie ryzyka niepowodzenia projektu,

• ustrukturyzowane prac i osób za nie odpowiedzialnych,

• zaplanowanie projektu i daty końca prac wdrożeniowych,

• sporządzenie szczegółowego harmonogramu wdrożenia, obejmującego tzw. kamienie milowe.

Wynikiem analizy przedwdrożeniowej musi być zaakceptowany przez Xxxxxxxxxxxxx projekt wdrożenia zawierający co najmniej:

• cele projektu ułożone w sposób uwzględniający ich priorytety i wzajemne relacje pomiędzy celami głównymi i cząstkowymi,

• charakterystykę działalności Zamawiającego i Partnerów Projektu w obszarach objętych przedmiotem wdrożenia,

• wykaz używanych raportów i wydruków,

• schemat procesów do implementacji Systemu,

• zakres i sposób implementacji procesów biznesowych we wdrażanym Systemie,

• harmonogram wdrożenia,

• skład zespołu wdrożeniowego Zamawiającego i Wykonawcy,

• zakres odpowiedzialności stron za poszczególne zadania projektu,

• analizę ryzyka i uzgodnione pomiędzy stronami sposoby radzenia sobie z nim,

• określenie zasad komunikacji i dokumentacji prowadzonej w trakcie wdrożenia.

4.2. Zamawiający wymaga, aby planowanie etapów i harmonogramu wdrożenia Systemu Wykonawca dostosował do Harmonogramu prac, stanowiącego załącznik nr 4 do Umowy, wynikającego z planu realizacji projektu pn. „Polska Platforma Medyczna: portal zarządzania wiedzą i potencjałem badawczym” i przyjął podane tam terminy za nieprzekraczalne i nie ulegające prolongacie.

Harmonogram prac wynikający z planu realizacji projektu:

a) Przygotowanie infrastruktury informatycznej i wdrożenie Systemu u Partnerów Projektu (wdrożenia na poziomie lokalnym):

• Analiza wstępna i dokumentacja przedwdrożeniowa u Lidera i Partnerów w terminie do 15.06.2019 r.,

• Uruchomienie instalacji lokalnych Systemu u Lidera i Partnerów w terminie do 15.10.2019 r.,

• Odbiór końcowy instalacji lokalnych Systemu u Lidera i Partnerów w terminie do 30.10.2019 r.

b) Uruchomienie Polskiej Platformy Medycznej PPM (wdrożenie na poziomie centralnym):

• Uruchomienie instalacji centralnej Systemu u Lidera w terminie do 15.05.2020 r.,

• Odbiór instalacji centralnej Systemu (PPM) u Lidera w terminie do 31.05.2020 r.

V. Odbiór prac

Z uwagi na wielkość projektu, harmonogram oraz budżet, odbiorowi podlegają poszczególne etapy wdrożenia zgodnie ze szczegółowym harmonogramem prac.

Każdy z wykonanych etapów kończy się odbiorem częściowym na podstawie protokołu odbioru częściowego.

Wykonanie całości przedmiotu umowy kończy się podpisaniem przez Xxxxxxxxxxxxx protokołu odbioru końcowego.

Podpisany przez obie strony protokół odbioru końcowego bez uwag stanowi potwierdzenie prawidłowego wykonania prac i zamknięcie realizacji przedmiotu umowy.

Szczegółowe zasady odbiorów określa Umowa.

VI. Opieka eksploatacyjna

6.1. Wykonawca musi zaoferować świadczenie usług umożliwiających utrzymanie sprawnego i efektywnego funkcjonowania Systemu. Oferta Wykonawcy musi obejmować opiekę eksploatacyjną nad oprogramowaniem przez okres 72 miesięcy, stanowiącą pakiet usług zapewniający użytkownikom możliwość szybkiego i sprawnego rozwiązywania problemów związanych z wykorzystaniem Systemu.

6.2. Opieka eksploatacyjna musi obejmować co najmniej:

• Opracowywanie i wydawanie aktualizacji oprogramowania polegających na ich dostosowaniu do zmian w powszechnie obowiązujących przepisach prawa nie później niż w dniu wejścia w życie zmiany. W uzasadnionych przypadkach Zamawiający dopuści 14-dniowy termin wprowadzenia odpowiednich zmian.

• Wprowadzanie nowości w funkcjonalnościach oraz merytorycznej zawartości oprogramowania w ramach jego rozwoju rynkowego.

• Aktualizację oprogramowania systemowego i bazodanowego wymaganego do działania Systemu.

• Eliminację błędów Systemu i naprawianie zgłaszanych usterek. Zamawiający musi mieć możliwość zgłaszania problemów na specjalnym, określonym w warunkach świadczenia gwarancji, formularzu, za pośrednictwem poczty elektronicznej, faksu lub wypełniając formularz umieszczony na stronie internetowej systemu rozwiązywania problemów.

• Zapewnienie wsparcia telefonicznego i e-mailowego od poniedziałku do piątku w godzinach 09:00 - 17:00.

• Możliwość bezpłatnego doszkolenia administratorów systemu z konfiguracji i eksploatacji systemu wspomagającego zarządzanie procesami dydaktycznymi w funkcjonalności, o którą zostanie rozszerzony podczas wykonywania prac wdrożeniowych (maksymalnie 2 osoby rocznie) w trakcie trwania opieki eksploatacyjnej.

VII. Szkolenia

7.1. Wykonawca zaplanuje i przeprowadzi szkolenia w zakresie wdrażanych obszarów funkcjonalnych Systemu dla osób wyznaczonych przez Zamawiającego, w tym dla Redaktorów i Administratorów Systemu. Szkolenia powinny być przeprowadzone w siedzibach Partnerów Projektu i odbywać się w godzinach pracy instytucji, tj. między g. 8:00 a 15:00. Terminy szkoleń powinny być uzgodnione z Zamawiającym, a ich przyjęcie wymaga potwierdzenia w formie pisemnej. Zamawiający dopuszcza możliwość częściowej realizacji szkoleń w formie webinariów.

7.2. Szkolenie z wdrażanych obszarów funkcjonalnych Systemu powinno obejmować:

- dla Administratorów - jedno szkolenie minimum 2-dniowe na etapie wdrożenia oraz jedno szkolenie 1-dniowe po etapie wdrożenia lokalnego u Lidera i każdego z Partnerów Projektu, trwające nie mniej niż 6 godzin dziennie, dla minimum 2 osób z każdej instytucji wraz z przekazaniem instrukcji obsługi w języku polskim, w wersji drukowanej oraz elektronicznej, każdemu z Partnerów Projektu.

- dla Redaktorów - jedno szkolenie minimum 2-dniowe na etapie wdrożenia oraz jedno szkolenie 1-dniowe po etapie wdrożenia lokalnego u Lidera i każdego z Partnerów Projektu, trwające nie mniej niż 6 godzin dziennie, dla minimum 4 osób z każdej instytucji wraz z przekazaniem instrukcji obsługi w języku polskim, w wersji drukowanej oraz elektronicznej, każdemu z Partnerów Projektu.

7.3. Ponadto Xxxxxxxxxxx wymaga, aby Wykonawca przygotował szkolenia w postaci interaktywnej prezentacji elektronicznej w formie nadającej się do umieszczenia na serwerze WWW oraz do nagrania na nośnik elektroniczny. Szkolenie w postaci elektronicznej powinno być podzielone na obszary funkcjonalne objęte wdrożeniem. Prezentacja powinna zawierać opis wykonania najczęściej wykorzystywanych funkcji systemu wraz z filmami instruktażowymi demonstrującymi użycie tych funkcji. Wykonawca jest zobowiązany do udzielenia licencji na korzystanie z w/w materiałów szkoleniowych przez Lidera i partnerów projektu na potrzeby szkoleń użytkowników, realizowanych przez Lidera i partnerów projektu. Wykonawca jest zobowiązany do udzielenia licencji na korzystanie z w/w materiałów szkoleniowych przez Lidera i Partnerów Projektu na potrzeby realizowanych szkoleń użytkowników.

40