Zapytanie o informację (RFI) na wykonanie systemu AXIONET wspierającego proces diagnostyki i leczenia padaczki

24 września 2018

TYP DOKUMENTU

Zapytanie o informację

NAZWA PROJKETU

Projekt pt.” Utworzenie Centrum Badawczo-Rozwojowego Neurosphera – Narodowe Centrum Badań Klinicznych Diagnostyki i Terapii Padaczki” realizowany w działaniu 2.1 Wsparcie inwestycji w infrastrukturę B+R przedsiębiorstw Programu Operacyjnego Inteligentny Rozwój 2014 – 2020 współfinansowanego ze środków Europejskiego Funduszu Rozwoju Regionalnego.

NUMER ZAMÓWIENIA

RFI-2018-002-Axionet_1.5

DANE KONTAKTOWE

mail: biuro@neuphoria.pl

DATA UTWORZENIA

24.09.2018

DATA WAŻNOŚCI

3.10.2018

ZAMAWIAJĄCY

Neuphoria Sp. z o.o. ul. Włocławska 161; 87-100 Toruń, KRS 0000581451, Regon 362787241, NIP 9562313855

OSOBA UPOWAŻNIONA

Marek Krystoforski– Prezes Zarządu

Strona 2/20

Spis treści1. Opis przedmiotu zamówienia......................................................................................................................................................... 4

1.1. Podstawowe informacje o projekcie Centrum Badawczo Rozwojowe (CBR) Neurosphera...............41.1.1. EPISTEMIC ........................................................................................................................................................................ 41.1.2. IM-EAX ................................................................................................................................................................................ 41.1.3. AXIONET ............................................................................................................................................................................ 4

2. Szczegółowa specyfikacja planowanego zamówienia........................................................................................................ 62.1. Wykaz elementów i prac objętych planowanym zamówieniem na wykonanie systemu AXIONET.9

2.1.1. Szczegółowa analiza wymagań................................................................................................................................. 92.1.2. Wysokopoziomowa architektura systemu (high level design HLD)...................................................... 92.1.3. Baza biomedyczna ......................................................................................................................................................... 92.1.4. Systemu wspierania decyzji (moduł DSS):....................................................................................................... 10

2.1.4.1. Baza wiedzy.......................................................................................................................................................... 102.1.4.2. Baza danych medycznych.............................................................................................................................. 102.1.4.3. Baza algorytmów i modeli.............................................................................................................................. 102.1.4.4. Moduł zarządzania modelami...................................................................................................................... 112.1.4.5. Moduł symulacji.................................................................................................................................................. 112.1.4.6. Moduł raportów................................................................................................................................................. 122.1.4.7. Moduł rozwoju algorytmów i modeli ...................................................................................................... 122.1.4.8. Moduł testowania algorytmów i modeli................................................................................................. 122.1.4.9. Moduł zarządzania systemem..................................................................................................................... 132.1.4.10. Moduł danych wejściowych....................................................................................................................... 142.1.4.11. Moduł decyzyjny............................................................................................................................................. 142.1.4.12. Interfejs użytkownika systemu................................................................................................................ 152.1.4.13. Edytor bazy wiedzy........................................................................................................................................ 16

2.1.5. Moduł konsultacji zdalnej......................................................................................................................................... 162.1.6. Moduł zarządzania użytkownikami..................................................................................................................... 16

3. Warunki udzielenie odpowiedzi na RFI.................................................................................................................................. 174. Termin składania odpowiedzi...................................................................................................................................................... 185. Spis załączników................................................................................................................................................................................. 19

Strona 3/20

1. Opis przedmiotu zamówienia

Przedmiotem zapytania o informację jest opracowanie systemu Axionet, teleinformatycznego rozwiązania pozwalającego na spersonalizowaną medycznie ocenę ilościową szans poprawy klinicznej i ryzyka niepowodzeń przy zastosowaniu różnych terapii niekonwencjonalnych. System dostarczy model i algorytmy pozwalające na ocenę szans wyjściowych pacjenta na poprawę i określi szanse skuteczności klinicznej oraz ryzyka niebezpiecznych zdarzeń medycznych w zależności od zastosowanej metody. Będzie to zatem narzędzie wspomagające umożliwiające wygenerowanie rekomendacji leczenia bazując na ocenie ilościowej proponowanych rozwiązań. System ma dostarczyć więc funkcje swoistej „wagi” elektronicznej, której szale wychylą się na jedną stronę postępowania klinicznego.

W celu przybliżenia wizji projektowej poniżej przedstawiamy krótki opis tematyki związanej z realizowanym przedsięwzięciem.

1.1. Podstawowe informacje o projekcie Centrum Badawczo Rozwojowe (CBR) Neurosphera

Realizowany przez spółkę Neuphoria projekt obejmuje wybudowanie specjalistycznego centrum, w którym będą prowadzone prace badawcze nad nieuleczalną chorobą jaką jest epilepsja. Interdyscyplinarny zespół ekspertów poprowadzi badania kliniczne w oparciu o najnowocześniejszą aparaturę medyczną i środowisko informatyczne wpierające proces diagnostyki i terapii padaczki.

W ramach realizacji Agendy badawczej prowadzone będą trzy linie badawcze:

1.1.1. EPISTEMIC

Celem projektu jest opracowanie innowacyjnej metody wykorzystania komórek macierzystych w terapii padaczki. Umożliwi to wprowadzenie na rynek leczniczy, niestosowanego do tej pory, sposobu operacyjnego leczenia padaczki lekoopornej.Badanie obejmuje III fazy badawcze: fazę badań podstawowych, przedklinicznych i klinicznych. Faza kliniczna zakłada wszczepienie autogenicznych komórek macierzystych pacjenta w zniszczone ognisko chorobowe zaklasyfikowane do resekcji. Obserwacje pacjenta pozwolą zweryfikować, czy komórki macierzyste mogą dokonać regeneracji zniszczonego płata skroniowego, poprawę stanu pacjenta i skutkować brakiem konieczności resekcji ogniska chorobowego. Potwierdzenie skuteczności metody terapii padaczki z zastosowaniem komórek macierzystych pozwoli na wdrożeniem nowego algorytmu postępowania klinicznego w terapii padaczki. Będzie istotnym osiągnięciem w medycynie regeneracyjnym i skuteczną terapią w leczeniu padaczki lekoopornej.

1.1.2. IM-EAX

W ramach prowadzonych prac badacze określą skuteczność terapii padaczki lekoopornej przy zastosowaniu preparatu antyoksydacyjnego . Po przeprowadzeniu badań w grupie 1000 chorych przez okres 12 miesięcy możliwe będzie opracowanie rekomendacji terapeutycznej oraz nowej technologii terapii padaczki lekoopornej.

1.1.3. AXIONET

Zaawansowane rozwiązanie teleinformatyczne i cybernetyczne pozwalające na spersonalizowaną medycznie ocenę ilościową szans poprawy klinicznej i ryzyka niepowodzeń przy zastosowaniu różnych

Strona 4/20

terapii niekonwencjonalnych. Do tej pory nie istnieje skuteczny algorytm postępowania na tym etapie.

System powinien proponować metodę ilościową oceny szans wyjściowych pacjenta na poprawę i wyznaczy (obliczy lub estymuje) szansę skuteczności klinicznej i ryzyka niebezpiecznych zdarzeń medycznych w zależności od zastosowanej metody. System zaproponuje zbiór metod i algorytmów służących za rodzaj narzędzia decyzyjnego wskazującego optymalne lub zbliżone do optymalnego rozwiązanie - postępowanie kliniczne. Proponowane rozwiązanie będzie dodatkowo prezentowało szczegóły wyznaczonych oceny dla poszczególnych postępowań klinicznych.

Problem padaczki w Polsce

W Polsce jest ponad 400 tys. osób chorych na padaczkę. Neurologów zrzeszonych w Polskim Towarzystwie Epileptologii jest około 300, zaledwie 10 proc. z nich posiada certyfikat specjalisty w zakresie epileptologii. Standardowa diagnostyka i terapia pozwala na opanowanie choroby u 75% chorych, co oznacza ok 100.000 osób w Polsce – nie można znaleźć szybko i skutecznie dobrego rozwiązania terapeutycznego, a choroba przyjmuje postać lekooporną i nie ustępuje mimo kolejnych etapów terapii. Następuje wówczas najtrudniejszy moment terapii i decyzji klinicznych. Ten etap rozpoczyna tzw. terapię alternatywną, a więc zastosowanie metod niekonwencjonalnych równolegle z kolejnymi próbami terapii konwencjonalnej. Na tym etapie podejmowana jest również tzw. diagnostyka przedoperacyjna mająca na celu sprecyzowanie czy potencjalne leczenie chirurgiczne jest możliwe, czy zabieg może być bezpieczny i skuteczny. Nie istnieją obecnie skuteczne algorytmy postępowania na tym etapie, co zmieni się po realizacji tej części Agendy badawczej.Naukowcy poszukują nowych, skutecznych metod leczenia padaczki opornej na terapię farmakologiczną. Nowe rozwiązania uwzględniają m.in. wykorzystanie komórek macierzystych oraz preparatów antyoksydacyjnych. Centrum Badawczo-Rozwojowe Neurosphera będzie pierwszym w Polsce ośrodkiem badawczym, którego celem jest opracowanie nowych metod diagnozy i terapii epilepsji, w szczególności lekoopornej.

Strona 5/20

2. Szczegółowa specyfikacja planowanego zamówienia

Prawidłowa realizacja systemu AXIONET będzie obejmowała opracowanie autorskich metod i narzędzi analizy danych obrazujących symptomy i terapie. W ramach tych prac wykonana zostanie grupa zadań, która będzie miała na celu opracowanie zestawu klasyfikatorów regułowych i probabilistycznych, których zadaniem będzie rozwiązywanie problemów decyzyjnych związanych z doborem najbardziej trafnej (statystycznie najczęściej stosowanej przez ekspertów) metody terapeutycznej. Dostarczane metody mają zapewnić odwzorowanie działania eksperckiego zarówno w trakcie oceny przydatności danej terapii, jak również statystycznej oceny stosowalności terapii w zależności od rozpoznanych symptomów. Analiza korelacyjna będzie jednym z ważniejszych etapów przetwarzania danych w systemie. Pozwoli ona na skonstruowanie mechanizmów rekomendacyjnych, które na podstawie symptomów, wyników badań diagnostycznych oraz decyzji ekspertów dziedzinowych (lekarzy), będą oceniały statystyczne preferencje doboru terapii.

Zakłada się, że zbiór proponowanych metod i algorytmów analitycznych będzie proponował ilościowe i jakościowe narzędzia oceny decyzji, dostarczając tym samym wielokryterialne metody oceny terapii dostosowujące się do parametryzowalnego modelu preferencji lekarza i pacjenta. Model ten będzie odwzorowywał specyfikę pacjenta, jego choroby wraz z etiologią i innym uwarunkowaniami.

Konstrukcja tego typu narzędzi oparta może być o klasyfikatory: sieci bajesowskie, klasyfikatory regułowe, drzewa decyzyjne i regresji oraz inne metody ilościowe pozwalające na przeprowadzenie procesu klasyfikacji danej jednostki chorobowej w kontekście pacjenta i umożliwiających automatyzację doboru terapii.

Bazując na doświadczeniach związanych z budową mechanizmów klasyfikacyjnych wykorzystywanych do identyfikacji jednostek chorobowych, zaproponowane metody wykorzystają wiedzę ekspercką umożliwiającą wskazanie konkretnych decyzji diagnostycznych, ale również uwzględnią statystyczne dane dotyczące rekomendowanych terapii i ich skuteczności. Zbudowany aparat będzie więc składał się z zestawu narzędzi oferujących wielokryterialne wspomaganie decyzji. Decydenci otrzymają narzędzia, które umożliwią im skonstruowanie subiektywnego modelu preferencji określającego istotność poszczególnych kryteriów, skojarzonych bezpośrednio z rekomendacjami algorytmów klasyfikacyjnych. Proces przetwarzania danych będących przedmiotem decyzji, uwzględniać będzie zatem kilka sekwencyjnie wykonywanych czynności związanych z przygotowaniem zestawów danych diagnostycznych, rekomendacji leczenia i jego skuteczności, ich wstępnym przetworzeniem pod kątem stosowanych technik klasyfikacji, zbudowaniem modelu preferencji decydenta, wyznaczeniu parametrów wielokryterialnego modelu decyzji, a następnie jego wizualizacji (dostosowanej do zaproponowanych metod analitycznych).

System AXIONET umożliwi zbudowanie w pełni funkcjonalnej, innowacyjnej bazy wiedzy opisującej symptomy, techniki diagnostyczne i terapie. Inżynier wiedzy wraz z ekspertami odwzoruje reguły pozwalające na klasyfikacje jednostki chorobowej i zaproponowanie konkretnej terapii. Uzupe łnieniem takiej konstrukcji będzie możliwość wprowadzania do bazy wiedzy danych o stosowanych terapiach i ich skuteczności w odniesieniu do konkretnych jednostek chorobowych opisywanych symptomami i danymi diagnostycznymi. Skonstruowana baza wiedzy (sieciowa reprezentacja wiedzy) dostarczy więc niezbędnych elementów informacyjnych (wiedzy domenowej) metodom wnioskowania regułowego oraz wnioskowania wykorzystując w tym celu sieci bayesowskie.

Zamawiający zakłada, że dostarczone narzędzie będzie wyposażone w komplet mechanizmów i aplikacji umożliwiających projektowanie, modyfikację i przegląd budowanej bazy wiedzy uwzględniającej zakładane języki opisu bazy wiedzy.

Strona 6/20

Zamawiający zakłada, że jednym z głównych narzędzi analitycznych wykorzystywanych w przetwarzaniu bazy wiedzy może stać się środowisko Protege OWL 5.X przygotowane do wykorzystania różnych mechanizmów wnioskowania. Aby zapewnić zaawansowane metody estymacji parametrów dla sieci bayesowskich zakłada się wykorzystanie narzędzi analitycznych pozwalających na konstrukcje i wizualizacje samych sieci wiedzy oraz wspomagających estymację parametrów modelu. Zakładamy, że wśród narzędzi analitycznych znaleźć się mogą znane i powszechnie stosowane rozwiązania Bayes Net Toolbox for Matlab, Microsoft Bayesian Network Editor oraz dedykowane narzędzia Open Source wspierające parametryzacje i projektowanie dedykowanych metod drążenia danych (ang. Data mining) np. WEKA 3 (http://www.cs.waikato.ac.nz/ml/weka/) lub Java Data Mining Package (JDMP) zawierające rozbudowane mechanizmy analityczne wspierające rozszerzalna architekturę integracyjną do innych pakietów i bibliotek analitycznych (LibLinear, Elasticsearch, Mallet, Lucene, Octave, LibSVM). Zostaną one odpowiednio dopasowane do wymagań Zamawiającego na etapie ich tworzenia lub dostosowania przez wybranego dostawcę.

Zamawiający zakłada, że system będzie wyposażony w mechanizmy uczenia maszynowego, które pozwolą na wybudowanie odpowiedniej bazy wzorców pozwalającej na uzupełnienie wiedzy eksperckiej kodowanej w bazie wiedzy o elementy wynikające z pozytywnie ocenionych przypadków klinicznych. Baza wzorców reprezentowała będzie więc przetwarzane w Centrum przypadki kliniczne wraz z ich ilościową reprezentacją, proponując tym samym metody badania podobieństwa nowo wprowadzanych przypadków do tych które były już rozpatrywane i Centrum zaproponowało skuteczną terapię. Zbudowanie takiej bazy, a następnie jest rozbudowa i modyfikacje będą przedmiotem prac zespołu pracowników nowo utworzonego centrum badawczo-rozwojowego. W wyniku tych prac będą powstawały wzorce, które zostaną umieszczone w bazie i będą służyły jako statystyczny punkt odniesienia dla wykonywanych porównań. Jeśli w trakcie wykonywanego porównania przetwarzane dane zostaną sklasyfikowane jako zgodne z wzorcem, to zostaną do niego przypisane. Jeśli zostaną znalezione odstępstwa, to te dane zostaną pokazane jako nie pasujące do danego wzorca i zespół pracowników podejmie decyzję jak należy je klasyfikować. Odstępstwa od wzorca mogą być nieznaczne lub mogą powodować że określony dane zostaną sklasyfikowane jako nowy wzorzec.

Gdy w systemie zostanie wytworzona odpowiednio duża liczba wzorców, system sam powinien zacząć rozpoznawać i klasyfikować napływające dane. W ten sposób system osiągnie poziom samouczenia się. Proces uczenia się systemu jest jednym z elementów prawidłowego działania analizy statystycznej, a w konsekwencji prawidłowego klasyfikowania wzorców. Uczenie maszynowe pozwoli uzyskać pewien poziom autonomii zakupionego systemu, a także powinno doprowadzić do sytuacji, w której prace analityczne wykonywane przez system, dzięki możliwości jednoczesnej analizy wielu strumieni danych, będą w znacznym stopniu bardziej wydajne niż praca zespołu ludzkiego (oczywiście dla określonej grupy sygnałów). Klasyfikatory wytworzone w trakcie uczenia maszynowego mogą oceniać prawdopodobieństwo wystąpienia danego typu sygnału w strumieniu danych z dużą skutecznością. Uzupełnienie tych informacji o wyniki analizy statystycznej pozwalają na zwiększenie tego stopnia dokładności, a w konsekwencji powinny przyspieszyć procesy identyfikacji i klasyfikacji informacji.

Ze względu na fakt, że system AXIONET będzie pracował na bardzo dużej ilości danych, niezbędne jest zastosowanie rozwiązań zapewniających odpowiednią wydajność (szybkość działania), skalowalność oraz odporność na ewentualne awarie. Aby sprostać tym trzem wymaganiom, Zamawiający zakłada wykorzystanie mechanizmu rozproszonego przechowywania i zarządzania danymi, które znajdować się będą w systemie. Ze względu na to, że ilość danych w systemie i ich przyrost będzie znaczący, bardzo istotne znaczenie ma wydajność zastosowanych w systemie rozwiązań, tak aby zapewnić maksymalne wykorzystanie infrastruktury sprzętowej i jednocześnie dostarczyć odpowiedni poziom efektywność pracy. Dodatkowo istotne znaczenie ma fakt, aby rozwiązanie nie wpływało na logikę działania aplikacji, czyli przykładowo aby proces skalowania nie wpływał na działającą aplikację obliczeniową. Aby spełnić

Strona 7/20

to oczekiwanie planowane jest zastosowanie mechanizmu równouprawnienia wszystkich węzłów, a więc rezygnacja z klasycznego modelu master-slave, czyli tym samym rezygnacja z jednego centralnego punktu zarządzającego. Zastosowanie takiego rozwiązania zapewni z jednej strony stosunkowo prostą skalowalność, a z drugiej uniezależni system od pojedynczych punktów awarii (brak pojedynczego węzła zarządzającego, którego awaria mogłaby spowodować przerwę w działaniu całego systemu). Dodatkowo, ze względu na planowane użycie mechanizmu rozproszenia, uproszczeniu ulegnie procedura autoryzacji, gdyż nie będzie trzeba czekać na autoryzację centralnego węzła (jak to ma miejsce w przypadku struktury master-slave), a będzie można odwoływać się do każdego węzła niezależnie. Zakłada się, że wykorzystana zostanie metoda polegająca na sprawdzaniu obciążenia poszczególnych węzłów, a następnie oszacowaniu potencjalnego obciążenia danych węzłów przez zadania czekające do wykonania i na podstawie tej analizy zadania będą kierowane do odpowiednich (mniej obciążonych) węzłów. Pozwoli to zapewnić optymalny czas wykonania danego zadania, a jednocześnie optymalnie wykorzystać posiadane zasoby.

Wspomniana powyżej skalowalność rozwiązań wykorzystujących architekturę rozproszoną ma istotne znaczenie z punktu widzenia bezpieczeństwa i wydajności rozwiązań. Zwiększenie dostępności zasobów może być realizowane bez przerywania pracy systemu, a więc bez konieczności zamknięcia trwających zadań. Odpowiednie węzły, jeśli zajdzie taka potrzeba, mogą być powołane „w locie”, a następnie włączone do działania systemu z wykorzystaniem mechanizmu replikacji. Możliwe jest również skalowanie systemu „w dół”, czyli odłączenie zbędnych w danej chwili węzłów. Taki mechanizm pozwoli optymalnie wykorzystywać infrastrukturę sprzętową pracującą w systemie i w zależności od potrzeb obliczeniowych używać określonej liczby maszyn.

Jak zostało wspomniane powyżej, zaletą oparcia rozwiązania o rozproszoną architekturę jest zapewnienie wyższej odporności na mogące się pojawić awarie. Dzięki równouprawnieniu poszczególnych węzłów pracujących w strukturze oraz zastosowaniu mechanizmu replikacji, rozwiązania wykorzystujące rozproszoną architekturą mają zapewniony odpowiedni poziom redundancji. Dzięki temu uszkodzenie jednego lub nawet kilku węzłów nie powinno spowodować utraty danych oraz nie powinno ograniczać ich dostępności dla warstwy aplikacyjnej. Ewentualne uszkodzenie może jedynie mieć wpływ na wydajność systemu. Jest to bardzo ważna zaleta systemów wykorzystujących rozproszone architektury, gdyż poprzez minimalizację ryzyka utraty danych pozwala zwiększyć poziom bezpieczeństwa przechowywanych danych. Dzięki zastosowaniu replikacji uzyskamy więc nie tylko zwiększenie dostępności danych, jak również zwiększenie ich bezpieczeństwa. Dodatkowo, jeśli zajdzie taka potrzeba, mechanizm replikacji pozwala rozproszyć system na innych węzłach niż pierwotnie przydzielony zestaw maszyn (fizycznych lub wirtualnych) co z kolei ma bardzo istotny wpływ w sytuacji, gdy awaria jest duża i aby zapewnić odpowiednią wydajność pracującego środowiska należy rozproszyć rozwiązanie również na inne maszyny.

Opracowywane środowisko będzie konstruowane w oparciu o architekturę SOA (Serive Oriented Architecture), w którym poszczególne algorytmy będą zaimplementowane w postaci separowanych usług webowych, sterowanych (ang. Choreographed) mechanizmami procesowymi. Procesy te będą odwzorowywały dostosowywane przez eksperta (neurologa, neurochirurga, epileptologa) ścieżki analityczne, definiowane w graficznym środowisku modelowania. Proponowane narzędzia mają umożliwić uzupełnienie własności analitycznych o dodatkowe elementy analizy danych wprowadzając elementy analizy ilościowej bazy wiedzy zapisanej w języku logiki opisowej i logiki pierwszego rzędu.

Strona 8/20

2.1. Wykaz elementów i prac objętych planowanym zamówieniem na wykonanie systemu AXIONET

2.1.1. Szczegółowa analiza wymagań

Prace wykonywane w ramach tego zadania są bardzo istotne z punktu widzenia całego projektu, gdyż bezpośrednio przekładają się na kolejne etapy prac i prowadzone w nich prace rozwojowe mające na celu wytworzenie końcowego produktu projektu. Prace rozwojowe zostaną podzielone na kolejne podetapy mające na celu zebranie wymagań biznesowych oraz systemowych, które pozwolą stworzyć obraz docelowego systemu. Na podstawie tych wymagań zostanie opracowana lista wymagań funkcjonalnych, które zostaną ujęte w dokumencie specyfikacji wymagań. Wytworzone dokumenty zostaną przedstawione do akceptacji dla wszystkich stron uczestniczących w analizie i dopiero ich zatwierdzenie będzie podstawą do dalszych prac rozwojowych mających na celu wypracowanie szczegółowych funkcjonalności. Na tym etapie prac zostaną również wydzielone wymagania niefunkcjonalne projektu. Taki dokument zaakceptowany przez wszystkie strony uczestniczące w analizie jest podstawą do dalszych prac nad szczegółowymi funkcjonalnościami.

2.1.2. Wysokopoziomowa architektura systemu (high level design HLD)

Odwzorowanie zdefiniowanych w ramach wcześniejszych prac wymagań i przełożenie ich na podstawową, logiczną organizację systemu wraz z jego poszczególnymi komponentami, ich wzajemnymi powiązaniami, zależnościami i relacjami, uwzględniającą także relacje i interakcje z systemami zewnętrznymi oraz zdefiniowanymi regułami rozwoju wytworzonej architektury i budowania architektury szczegółowej poszczególnych komponentów. W HLD zostanie przygotowana wysokopoziomowa specyfikacja funkcjonalna odzwierciedlająca kluczowe przypadki użycia zidentyfikowane w analizie wymagań. Dokument HLD będzie zawierał specyfikację modułów aplikacyjnych składających się na końcowy produkt projektu, włączając w to przygotowanie projektów graficznych aplikacji uwzględniających wymagania rynku docelowego i aktualnie obowiązujące standardy. W procesie tworzenia architektury HLD uwzględnione zostaną również takie aspekty jak dostępność poszczególnych elementów rozwiązania i całego systemu, oczekiwana niezawodność w stosunku do poszczególnych składowych i końcowego produktu, oczekiwania w stosunku do skalowalności i elastyczności tworzonego rozwiązania, wydajności poszczególnych komponentów i całego systemu. Podobnie jak prace prowadzone w etapie analizy wymagań, również prace rozwojowe realizowane w etapie opracowania architektury HLD zostaną podzielone na kilka mniejszych podetapów mających na celu stworzenie końcowego produktu w postaci dokumentacji opisującej architekturę tworzonego rozwiązania. Wśród planowanych do zrealizowania podetapów będzie m.in: stworzenie pierwszej wersji wysokopoziomowej architektury systemu; kolejne iteracje, w ramach których powstanie dokładny projekt techniczny; iteracje uszczegóławiające funkcjonalności poszczególnych modułów; iteracje służące implementacji projektu technicznego; konsultacje z zespołem deweloperskim i biznesem oraz zespołem R&D mające na celu uszczegółowienie poszczególnych funkcjonalności i przełożenie ich na architekturę HLD oraz wytworzenie finalnego na tym etapie prac dokumentu architektury HLD.

2.1.3. Baza biomedyczna

Baza biomedyczna stanowiąca zewnętrzne źródło danych. Baza będzie zawierała część informacyjną agregującą dane (w tym dane sensytywne) każdego pacjenta wprowadzanego do systemu AXIONET i składała się z następujących elementów logicznych:

o część informacyjna: będzie zawierała dane demograficzne i urzędowe, ew. też pliki

Strona 9/20

foto/audio/wideoo cześć medyczna: będzie zawierała dane biomedyczne stałe (grupa krwi, uczulenia,

choroby itp.)o część interwencyjna: moduł informacji ICE, telefony, dane kontaktowe i moduł

identyfikacji chorego dla osób spoza systemu – tzw. część EMERGENCYInterfejs bazy biomedycznej do współpracy z systemem AXIONET. Włączenie systemu AXIONET w każdej chwili ma być dostępne dla lekarza w trakcie korzystania z rozwiązania. Można będzie skorzystać z systemu AXIONET przy diagnostyce/terapii pacjenta z bazy i spoza bazy. W przypadku pacjenta z bazy – jego dane niezbędne dla drzewa decyzyjnego będą automatycznie wpisywane w system.

2.1.4. Systemu wspierania decyzji (moduł DSS):

2.1.4.1. Baza wiedzy

Będzie to część systemu wspierania decyzji zawierająca odpowiednią wiedzę naukową, tj.: informacje naukowe i kliniczne na temat schorzeń neurologicznych, a w szczególności padaczki. Baza wiedzy będzie zatem stanowiła element modułu DSS, który zgromadzi i będzie przechowywał fakty i reguły, z których będą korzystały pozostałe elementy tego modułu. Elementy te będą wykorzystywane do uzyskiwania rozwiązań oraz będą stanowiły jeden z podstawowych elementów wnioskowania, na podstawie którego system DSS będzie w oparciu o przygotowane algorytmy prowadził wnioskowanie i na ich bazie będzie sugerował odpowiednie dla danego przypadku rozwiązania. Drugim elementem tego modułu są reguły pozwalające zapisać i stanowić związki pomiędzy poszczególnymi obiektami. Z wykorzystaniem zapisanych w bazie wiedzy faktów, reguły po uruchomieniu wykonują zdefiniowane akcje prowadzące do osiągnięcia rezultatu. Odpowiednie skonstruowanie bazy wiedzy jest niezwykle istotnym elementem budowy całego systemu AXIONET i przekłada się jednoznacznie na poprawność działania całego rozwiązania.

2.1.4.2. Baza danych medycznych

Baza danych zmiennych, które będą zawierały niektóre informacje i fakty wprowadzone do bazy w trakcie dialogu z użytkownikiem. Baza ta będzie umożliwiała przechowywanie między innymi wyników pomiarów, hipotez charakterystycznych dla danego, zadanego przypadku. Dane zawarte w tej bazie zostaną uwzględnione do przeprowadzenia procedury wnioskowania, a także do przeprowadzenia procedury objaśnienia. Podobnie jak dane zapisane w bazie wiedzy, tak również elementy znajdujące się w bazie danych medycznych stanowią podstawę do analizy i wnioskowania.

2.1.4.3. Baza algorytmów i modeli

Baza zawierająca poszczególne wersje algorytmów i modeli matematycznych wykorzystywanych w systemie AXIONET. W wyniku tworzenia nowych modeli lub modyfikacji istniejących powstają kolejne lub nowe wersje algorytmów, które będą wykorzystywane w procesie wnioskowania. Wynika to ze wzbogacania wiedzy o modelowanym procesie (wzbogacanie będzie naturalnym procesem jaki będzie zachodził w środowisku pracy centrum badawczo-rozwojowego – w miarę samouczenia się systemu, a także uczenia się lub poszerzania wiedzy przez pracowników centrum oraz w miarę uzyskiwania kolejnych wyników prac własnych wiedza będzie ulegała znaczącemu wzbogaceniu), a więc w miarę jak wzrasta wiedza dotycząca danego algorytmu, jego zachowania, wartości i wpływu poszczególnych parametrów na zachowanie algorytmu, powstają kolejne wersje algorytmów, które będą wykorzystywane w systemie. Niezbędne jest więc zapewnienie narzędzi do budowy, sprawdzania

Strona 10/20

poprawności oraz przechowywania wytworzonych algorytmów, a więc bazy algorytmów i modeli, w której trzymane będą poszczególne wersje wytworzonych algorytmów wraz z ich historią budowy, zmian itd. Baza ta będzie stanowiła źródło gotowych pełnych lub fragmentów algorytmów i modeli, z którego pracownicy centrum będą mogli pobierać fragmenty lub całość kodu wytworzonych przez siebie lub inne osoby algorytmów. Dzięki temu znacznemu przyspieszeniu powinny ulec procesy budowania nowych algorytmów (unikamy wielokrotnego pisania tych samych fragmentów kodu przez różnych pracowników). Do re-użycia będą dostępne jedynie przetestowane i sprawdzone wersje algorytmów, a więc takie które nie będą zawierały błędów. W przeciwnym razie system AXIONET narażony byłby na uruchomienie lub wykorzystanie fragmentu kodu lub algorytmu działającego nieprawidłowo, co z kolei mogłoby skutkować nieprawidłowym działaniem części lub nawet całości systemu. Prawidłowe działanie algorytmów ma kluczowe znaczenie dla realizacji projektu.

2.1.4.4. Moduł zarządzania modelami

Jest środowiskiem do zarządzania wykonywaniem poszczególnych modeli. Zadaniem tego elementu będzie zapewnienie możliwości wyboru wytworzonych algorytmów lub modeli oraz ich optymalizacji pod kątem parametryzacji w celu zapewnienia poprawności działania, tak aby zapewnić możliwość weryfikacji działania algorytmów przy zasileniu ich odpowiednimi danymi z poszczególnych baz danych. Będzie on również decydował jakie parametry i reguły powinny być zastosowane aby proces obliczeniowy trwał jak najkrócej. Jednocześnie należy tu zauważyć, że dla niektórych obliczeń czas uzyskania rezultatu może być znacząco dłuższy niż dla innych algorytmów, ale jednocześnie nie należy dyskryminować takich modeli, a więc jednym z zadań modułu zarządzania modelami będzie odpowiednia optymalizacja czasu wykonania wszystkich modeli pod kątem jak najszybszego uzyskania wyniku rozumianego jako osiągnięcie założonego celu. Ponadto moduł będzie wykrywać i ponawiać wykonanie zadań, które z jakiegoś powodu nie zostały wykonane. Odpowiednie skonstruowanie tego modułu będzie bardzo wymagającym zadaniem, ale jednocześnie jest niezbędna w celu zapewnienia prawidłowego działania całego systemu i uzyskiwania wiarygodnych wyników prac badawczych.

2.1.4.5. Moduł symulacji

Moduł symulacji będzie pozwalał na testowanie działania modeli, algorytmów i metod obliczeniowych zaprojektowanych w systemie w środowisku odpowiadającym środowisku produkcyjnemu. Moduł będzie odpowiedzialny za przeprowadzenie symulacji działania zarówno poszczególnych algorytmów jak i modeli. Generowanie dane będą przechowywane w odpowiednim repozytorium danych, a sam moduł będzie miał dostęp do danych historycznych aby umożliwić przeprowadzenie symulacji również na tego typu danych. Również w ramach jego zadań będzie możliwe sprawdzenie poprawności działania systemu z elementami zewnętrznymi (na danych testowych), a także ogólnego działania całego systemu (w uproszczonej postaci). Moduł symulacji powinien pozwolić na dostosowanie poszczególnych funkcji do specyficznych badanych przypadków, tak aby najpierw w trakcie symulacji określić najbardziej optymalne parametry wykonania i obliczeń a następnie wykorzystać je w produkcyjnym systemie. Jeśli w trakcie symulacji zostaną wykryte niepokojące zjawiska lub zaobserwowane zostaną nieprawidłowości działania części bądź całości systemu, odpowiedni pracownicy Centrum będą w stanie skorygować ustawienia lub wprowadzić odpowiednie poprawki, tak aby zapewnić optymalne warunki działania w przypadku przeniesienia sprawdzanego algorytmu lub modelu do systemu produkcyjnego. Brak możliwości uruchomienia algorytmów czy poszczególnych elementów systemu w trybie symulacji z wykorzystaniem tego modułu naraziłby system produkcyjny na niepotrzebne ryzyko awarii lub błędów.

Strona 11/20

2.1.4.6. Moduł raportów

Moduł raportów będzie pobierał informacje o przebiegu procesów zachodzących w trakcie pracy systemu i na ich podstawie umożliwi tworzenie zdefiniowanych przez użytkownika lub administratora raportów. Moduł raportów będzie umożliwiał definiowanie, generowanie i publikację raportów dla poszczególnych odbiorców produktów systemu AXIONET. Dane raportowe będą zbierane, a następnie prezentowane za pomocą odpowiednich paneli, które będą mogły być dostępne przez sieć internetową (oczywiście dostępna dla użytkownika po uprzednim zalogowaniu i weryfikacji prawidłowości podanych danych). Prawidłowe przedstawienie raportów agregujących dane, ich interpretację czy odpowiednio obrazujących wyniki będące rezultatem pracy systemu AXIONET mają bardzo istotne znaczenie dla końcowej interpretacji działania algorytmów.

2.1.4.7. Moduł rozwoju algorytmów i modeli

Moduł ten będzie wytworzony i udostępniony członkom zespołu R&D w celu tworzenia i ewaluowania algorytmów, modeli i metod obliczeniowych. W przypadku stworzenia złożonej instrukcji (lub innego złożonego obiektu sterującego), może ona zostać później przekształcona (przez zespół R&D) w metodę środowiska obliczeniowego (i zoptymalizowana pod względem wydajności), a następnie udostępniona za pomocą nowej usługi. Narzędzia udostępnione użytkownikom modułu rozwoju algorytmów i modeli będą służyć do oprogramowywania i rozwijania metod. Będzie on zaawansowanym środowiskiem pozwalającym na oprogramowywanie danego algorytmu lub modelu. Metody będą mogły wykorzystywać w swoim działaniu inne metody, a także składać się z bardziej podstawowych, prostszych metod. Metody będą opracowywane i oprogramowywane przez doświadczony zespół R&B. Zakłada się, że środowisko będzie zapewniało dostęp do funkcji i bibliotek zoptymalizowanych pod kątem funkcjonalności systemu AXIONET, a także że będzie można w łatwy sposób integrować i wdrażać nowe funkcje czy biblioteki.

2.1.4.8. Moduł testowania algorytmów i modeli

Środowisko testowania algorytmów i modeli będzie zintegrowane z modułem rozwoju algorytmów i modeli, dzięki czemu pracownicy centrum uzyskają dostęp do środowiska, w którym będą mieli możliwość przetestowania każdego nowego lub zmodyfikowanego algorytmu, tak aby zarówno sprawdzić skuteczność jego działania i wiarygodność uzyskiwanych wyników, ale także dzięki możliwości wykrywania błędów w zbudowanych algorytmach mieć możliwość weryfikacji wytworzonego kodu i sprawdzenie jego wydajności czy jakości. Moduł testowania pozwoli na prowadzenie kampanii testowych wytworzonych algorytmów i modeli co z kolei pozwoli na szybkie „wyłapanie” błędów logicznych, funkcjonalnych czy tak zwanych wąskich gardeł, które mogą uniemożliwić skuteczną klasyfikację danych. Jednocześnie dzięki wykorzystaniu narzędzi wspierających testowanie i wykrywanie błędów, zapewniona zostanie możliwość osiągnięcia wysokiej wydajności i jakości tworzonych algorytmów, tak aby efektywnie wykorzystywać zasoby projektu (zarówno sprzętowe, programowe jak i ludzkie) a w konsekwencji zapewnić wysoką sprawność całego systemu AXIONET. Planuje się, że wszystkie algorytmy i metody, które będą wytwarzane najpierw będą testowane w środowisku testowym, a po pomyślnym przejściu zestawu prób powtarzanych przez zdefiniowany okres czasu (wielokrotne potwierdzenie skuteczności) będą optymalizowane i implementowane w środowisku produkcyjnym.

Strona 12/20

2.1.4.9. Moduł zarządzania systemem

Moduł będzie udostępniony dla ściśle określonego grona użytkowników systemu DSS, pełniących funkcje administracyjne i zarządzające systemem, a także jego poszczególnymi modułami. Zależnie od roli i przypisanych uprawnień użytkownika, moduł będzie udostępniał odpowiednie funkcje w następujących zakresach:

! administracja systemem – ustawienia poszczególnych modułów, parametry działania, ewentualnie ustawieniami warstwy wirtualizacji, ustawienia warstwy sprzętowej. Jak każdy zaawansowany system informatyczny, również system AXIONET będzie wymagał odpowiedniego poziomu nadzoru i możliwości parametryzacji.

! zarządzanie wejściem i wyjściem danych – interfejsy skryptowe do zarządzania wchodzącymi i wychodzącymi strumieniami danych, parametry połączeń z systemami zewnętrznymi, ustawienia protokołów i zabezpieczeń. Ten element będzie udostępniał uprawnionym użytkownikom systemu AXIONET możliwość konfiguracji i zmiany parametrów poszczególnych interfejsów komunikacyjnych. Ze względu na fakt, że do prawidłowego działania systemu AXIONET niezbędne są dane pochodzące z różnych źródeł, w tym również źródeł zewnętrznych, niezbędne jest tym samym zarządzanie tą komunikacją i interfejsami, po których ta komunikacja się odbywa.

! zarządzanie bazami danych – ustawienia poszczególnych silników bazodanowych oraz dispatcher’a, zarządzanie strukturami przechowywanych i przetwarzanych danych, zarządzanie replikacją, zabezpieczeniami i wszystkimi innymi dostępnymi parametrami związanymi z wykorzystanymi silnikami bazodanowymi. Ponieważ zakładamy wykorzystanie w rozwiązaniu architektury rozproszonej, w ramach tego elementu zostanie zakupiona możliwość prawidłowej konfiguracji zasobów sprzętowych, ilości węzłów wykorzystywanych w rozproszonej architekturze, użytkowników itd.. Ustawienia poszczególnych baz danych powinny zapewnić utrzymanie wymaganej elastyczności i wydajności pracy, a także ich niezawodności.

! zarządzanie modułem decyzyjnym – ustawienia poszczególnych składowych modułu decyzyjnego, bibliotek, funkcji, definicje metod obliczeniowych, optymalizacja metod pod kątem procesorów, parametryzacja nowych metod, parametryzacja metod pochodnych z wykorzystaniem metod już istniejących w środowisku, instalacja nowych narzędzi obliczeniowych (modułów, bibliotek itp.), podpięcie środowiska obliczeniowego do modułu logiki systemu.

! zarządzanie wykonaniem modeli – ustawienia poszczególnych algorytmów i modeli, zarządzanie ich uruchamianiem, ustawianie metod mierzenia wydajności poszczególnych metod, a także części stosowanych modeli, ustawienia środowiska do graficznego definiowania modeli. Podobnie jak pozostałe elementy wchodzące w zakres modułu zarządzania, tak również wykonywanie algorytmów i modeli zależy od ich ustawień i parametryzacji lub środowiska.

! administracja serwisem i kontami użytkowników – ustawienia kont użytkowników, ich uprawnień, odzyskiwania haseł, konfiguracji wyglądu graficznego, dostępnych plug-inów (wtyczek) do pobrania i instalacji. Osoby pełniące funkcje administracyjne w systemie będą posiadały uprawnienia do zakładania i autoryzacji kont użytkowników systemu AXIONET. Każdy z użytkowników otrzyma login i hasło, za pomocą których będzie mógł logować się do systemu w przypisanej do niego roli. Każde zarejestrowane konto zostanie

Strona 13/20

zamieszczone na liście kont aktywnych do momentu jego zawieszenia lub usunięcia przez uprawnione osoby. Dzięki temu będzie istniała możliwość weryfikacji danego użytkownika, jego aktywności czy historii działania dzięki czemu możliwa będzie weryfikacja zachowań i śledzenie ewentualnych nadużyć.

Ustawienia i konfigurację poszczególnych elementów będą modyfikowane jedynie przez kompetentnych i posiadających odpowiednie kwalifikacje pracowników Centrum badawczo-rozwojowego. Wymóg ten podyktowany jest faktem, że nawet niewielkie błędy w parametryzacji poszczególnych elementów mogą nieść za sobą poważne problemy, takie jak obniżona wydajność działania systemu, błędy interpretacyjne czy nawet błędna konfiguracja rozwiązania. Dostęp do modułu zarządzania systemem AXIONET będzie wymagał odpowiedniego poziomu zabezpieczeń, które powinny działać w sposób redundantny (przykładowo logowanie z wykorzystaniem identyfikatora i hasła oraz weryfikacja sms lub zbliżenie karty identyfikacyjnej).

2.1.4.10. Moduł danych wejściowych

Moduł będzie odpowiedzialny za bardzo szybki import i preagregację danych pochodzących od zewnętrznych dostawców i zewnętrznych systemów a dostarczanych w różnych formatach (dane mogą pochodzić z różnych źródeł i tym samym mieć różną postać). Przykładowo źródłem danych będą sygnały pochodzące z zewnętrznych aparatów rejestrujących sygnały EEG, zewnętrznych aparatów rejestrujących obrazy z wykorzystaniem rezonansu magnetycznego, ale także inne źródła wiedzy, takie jak karty zdrowia pacjentów, ich dane biometryczne czy ogólna wiedza dotycząca padaczki. Tego typu dane mają różną postać, a często mogą mieć również różną interpretację i być obarczone szumem, błędami lub mogą być uszkodzone. Dlatego bardzo ważne jest aby zapewnić ich wstępną obróbkę, preagregację czy analizę i następnie przygotować do dalszej obróbki i interpretacji przez pozostałe elementy systemu AXIONET. Coraz częściej na rynku mamy do czynienia z sytuacją, w której producenci poszczególnych urządzeń udostępniają interfejsy API, za pomocą których inne podmioty mogą pobierać dane obrabiane w ich urządzeniach. Zakładamy, więc, że w ramach wytworzenia tego elementu systemu AXIONET zostanie zapewniona integracja z najbardziej popularnymi urządzeniami do zbierania i analizy sygnałów EEG oraz rezonansu magnetycznego, tak aby dane pochodzące w najbardziej powszechnych urządzeń mogły być w stosunkowo prosty sposób importowane do systemu AXIONET. Moduł danych wejściowych będzie przekształcał je do formatu używanego w bazach danych i całym systemie, tak aby zapewnić jednoznaczną interpretację sygnałów pochodzących z różnych systemów zewnętrznych (przykładowo stacjonarne EEG pochodzące od różnych producentów, które udostępniają dane w różnych formatach i należy je ujednolicić). Zapewni również odpowiedni poziom bezpieczeństwa przesyłanych danych oraz ich jednorodności, jednocześnie będzie odpowiedzialny za to, aby w przypadku zbyt dużej liczby błędów transmisji możliwe było powtórne przesłanie danych uszkodzonych lub aby transmisja została powtórzona w całości. Z drugiej strony należy zabezpieczyć się przed sytuacją gdy do systemu nagle zacznie napływać zbyt duża ilość danych, których interpretacja nie będzie możliwa lub które mogą znacząco obniżyć wydajność systemu.

2.1.4.11. Moduł decyzyjny

Zaprojektowanie i implementacja warstwy logiki systemu AXIONET, czyli odpowiednio zaprojektowanego szeregu elementów wnioskujących odpowiedzialnych za prawidłowe wykorzystanie wiedzy zgromadzonej w bazie wiedzy. Będzie to główna część systemu

Strona 14/20

odpowiedzialna za rozwiązanie zadanego problemu. W jego skład będą wchodziły element wnioskujący (element modułu odpowiedzialny za wykonanie pełnego procesu rozumowania, które będzie podejmowane w celu rozwiązania konkretnego problemu przedstawionego przez użytkownika systemu) oraz element objaśniający (element modułu stanowiący pewnego rodzaju warstwę wywodu lub tłumaczenia pomiędzy użytkownikiem a systemem odpowiedzialną za przedstawienie użytkownikowi systemu strategii wnioskowania jaka została zastosowana dla zadanego zagadnienia). Tak jak nieodpowiednia reprezentacja wiedzy uniemożliwia prawidłowe działanie systemu AXIONET, tak również nieprawidłowa ich interpretacja i wnioskowanie wpływają negatywnie na skuteczność działania całego systemu. Ponieważ system będzie bardzo złożonym mechanizmem obsługującym ogromną ilość danych, a także umożliwiającym przeprowadzenie wnioskowania, interpretacji i klasyfikacji poszczególnych sygnałów, mogą pojawiać się naturalne konflikty w zakresie podejmowania decyzji w przedmiotowych zakresach. Zbyt wiele kategorii reprezentowanych przez poszczególne wzorce może powodować powstawanie zbyt małych odległości znaczeniowych, a więc skutkować będą tym, że dane mogą być sklasyfikowane jako należące do kilku klas jednocześnie. W przypadku, gdy te klasy będą bliskie znaczeniowo, taka interpretacja nie będzie stanowiła zbyt dużego problemu i nie spowoduje dużego odchylenia w działaniu systemu. Natomiast w sytuacji gdyby dana interpretacja została sklasyfikowana jako dane należące do odległych klas, to wnioskowanie systemu może być nieprawidłowe. Oczywiście w ramach jego działania przewidujemy również autonomiczne uczenie systemu, które od pewnego momentu powinno znacząco poprawić wydajność prac (interpretacja wyników, analiza, wnioskowanie) w stosunku do wydajności systemu, gdzie każda decyzja jest wspierana decyzją lub akceptacją człowieka. Taki tryb pracy systemu nie będzie wymagał zwrotnej informacji od człowieka, a więc to system sam będzie gromadził odpowiednio dużą ilość danych, które powinny pomóc w przeprowadzeniu mu procesów interpretacji i klasyfikowania właśnie analizowanych danych. Dodatkowo moduł decyzyjny będzie musiał umieć obsłużyć sytuacje awaryjne i krytyczne, czyli sytuacje, w których interpretacja danych nie jest możliwa lub rodzi zbyt duże problemy. Przyczyn zaistnienia tego typu sytuacji może być kilka, jak chociażby błędy transmisji danych do modułu, błędy interpretacji, które nie zostały wykryte na etapie ich tworzenia i testowania czy problemy z wydajnością pracy algorytmów mające wpływ na pracę systemu. Odpowiednia interpretacja sytuacji i wynikająca z niej reakcja modułu będzie również zaimplementowana i skonfigurowana aby prawidłowo obsłużyć tego typu sytuacje wyjątkowe i w jak największym stopniu zminimalizować mogące pojawić się ryzyka.

2.1.4.12. Interfejs użytkownika systemu

Jest to element rozwiązania, który będzie stanowił warstwę interfejsu systemu AXIONET pracującego pomiędzy ekspertem zatrudnionym w utworzonym Centrum badawczo-rozwojowym a systemem, czyli będzie pewnego rodzaju pośrednikiem pomiędzy systemem a użytkownikiem z jednej strony udostępniającym zasoby systemu a z drugiej otwartym na działania użytkowników. Zbudowany interfejs będzie pozwalał na zadawanie pytań przez użytkowników systemu, udzielanie dodatkowych informacji systemowi oraz odbieranie od systemu odpowiedzi i wyjaśnień dla zadanego przypadku. Na podstawie udzielonej przez system informacji końcowy odbiorca (lekarz) uzyska informacje, które mogą okazać się pomocne przy podejmowaniu decyzji dotyczących diagnostyki lub leczenia danego pacjenta. Prawidłowa konstrukcja interfejsu użytkownika, a w szczególności jego funkcjonalności i ergonomia zapewnią przyjemną i efektywną współpracę pomiędzy ekspertami a systemem, a jednocześnie umożliwią prowadzenie zasadniczych prac badawczych skoncentrowanych na konkretnych

Strona 15/20

badanych pacjentach.

2.1.4.13. Edytor bazy wiedzy

Zaprojektowanie i implementacja edytora bazy wiedzy, czyli pewnego rodzaju interfejsów pozwalających na poszerzenie zakresu wiedzy oraz jej modyfikację ma kluczowe znaczenie dla wzbogacania wiedzy zapisanej w systemie. Edytor będzie pozwalał na modyfikację wiedzy zawartej w systemie AXIONET, umożliwiając tym samym jego rozbudowę oraz utrzymanie aktualnej bazy wiedzy. Jednocześnie z wykorzystaniem edytora bazy wiedzy będzie możliwe wprowadzanie wyników własnych badań jakie będą realizowane w utworzonym centrum badawczo-rozwojowym. Ponadto możliwa będzie rozbudowa istniejącej bazy wiedzy, pracownicy centrum zyskają narzędzie, które umożliwi nie tylko wzbogacenie sklasyfikowanej wiedzy o nowinki techniczne, farmakologiczne czy terapeutyczne, ale przede wszystkim umożliwi wprowadzenie do bazy wyników badań z wykorzystaniem komórek macierzystych, nowych leków oraz terapii z wykorzystaniem antyoksydacji, a więc trzech zasadniczych elementów, które są przedmiotem prac Centrum badawczo-rozwojowego.

2.1.5. Moduł konsultacji zdalnej

Jednym z istotnych elementów pracy oraz bardzo ważną z punktu widzenia pacjenta funkcjonalnością jest możliwość zapewnienia komunikacji z lekarzem, który prowadzi prace badawcze z wykorzystaniem systemu AXIONET. W tym celu Zamawiający zakłada zakupienie modułu konsultacji zdalnej. Zadaniem tego modułu będzie zapewnienie prawidłowej komunikacji na styku jednostka zlecająca badania – lekarz, lekarz – lekarz, lekarz – placówka medyczna itp.. Za pomocą tego elementu dla osób, co do których zlecone zostało wykonanie prac badawczych, zostanie udostępniona między innymi możliwość przesyłania wyników badań, dostaną udostępnioną historię przebiegu badań prowadzonych w ramach pracy Centrum, uzyskają dostęp do wyników i zaleceń generowanych z wykorzystaniem systemu AXIONET. Będzie on również odpowiedzialny za odpowiednie agregowanie zleconych prac badawczych, przypisywanie ich do podmiotów współpracujących oraz zapewni możliwość zlecania i przypisywania poszczególnych prac pracownikom Centrum badawczo-rozwojowego.

2.1.6. Moduł zarządzania użytkownikami

System będzie posiadał odpowiedni interfejs umożliwiający zrządzanie kontami użytkowników nie będących pracownikami Centrum. Każda jednostka zlecająca wykonanie w Centrum prac badawczych, będzie posiadała możliwość założenia konta w systemie, za pomocą którego będzie miała możliwość śledzenia postępów i wyników prac, zlecania kolejnych zadań. Dostęp będzie możliwy po uprzedniej rejestracji i podaniu loginu oraz hasła użytkownika, który jednoznacznie będzie określał podmiot współpracujący. Moduł będzie pozwalał na tworzenie, modyfikację, usuwanie kont użytkowników, zmianę haseł w przypadku gdy zostanie ono zgubione lub skradzione, tworzenie grup kont o takich samych uprawnieniach, wysyłanie powiadomień. Dodatkowo moduł będzie udostępniał administratorowi systemu AXIONET informacje o aktywności użytkowników zewnętrznych dotyczących logowania (przykładowo próby nieudanego logowania), zajętość konta, historię konta.

Strona 16/20

3. Warunki udzielenie odpowiedzi na RFI

Odpowiedź na RFI powinna zawierać:

(a) pełną nazwę Oferenta, NIP, adres lub siedzibę, numer telefonu do osoby kontaktowej;

(b) datę sporządzenia odpowiedzi na RFI;

(c) szacowaną kwotę niezbędną do realizacji przedmiotu zapytania tj.: wycena prac opisanych w pkt 2, zgodnie z Tabelą nr 1 poniżej;

(d) czas realizacji prac. Prosimy o przedstawienie harmonogramu czasu realizacji poszczególnych prac zgodnie z tabelą przedstawioną poniżej:

Tabela nr 1

Lp Etap Czas wykonania prac należy określić w pełnych tygodniach

Cena netto PLN

1 Analiza wymagań

2 Architektura systemu

3 Implementacja systemu

4 Dokumentacja systemu

5 Testy systemu Axionet

SUMA

(e) deklarację o przekazaniu pełnej dokumentacji technicznej, kodów źródłowych oraz praw własności do opracowanych elementów systemu Axionet (wzór oświadczenia stanowi Załącznik nr 1 do niniejszego RFI;

opcjonalnie:

(f) Ogólny opis propozycji wykonania elementów systemu Axionet – proponowana technologia, narzędzia analityczne oraz pozostałe elementy/sugestie, które Oferent uzna za niezbędne do prawidłowej realizacji prac

(g) Opis głównych czynników ryzyka związanych z realizacją zamówienia

(h) Sposób zarządzania pracami (metodyka prac)

(i) Dodatkowe informacje od Oferenta

Strona 17/20

4. Termin składania odpowiedzi

Termin składania odpowiedzi na RFI upływa w dniu: 3.10.2018 r.

Oferta może być przesłana za pośrednictwem poczty elektronicznej na adres: biuro@neuphoria.pl (w tytule maila prosimy umieścić informację: Odpowiedź na RFI – System Axionet)

lub pocztą tradycyjną na adres Neuphoria Sp. z o.o. ul. Włocławska 161, 87-100 Toruń. Na kopercie prosimy umieścić dopisek: Odpowiedź na RFI – System Axionet.

Termin, w jakim można zadawać pytania upływa w dniu 27 września 2018 r. Czas udzielenia odpowiedzi do dnia 1 października 2018 r.

Strona 18/20

5. Spis załączników• Załącznik nr 1 – Deklaracja o przekazaniu kodów źródłowych oraz praw własności

Strona 19/20

Załącznik nr 1 do RFI OF-2018-002-Axionet_1.5z dnia 24.09.2018r.

DEKLARACJA O PRZEKAZANIU KODÓW ŹRÓDŁOWYCH ORAZ PRAW WŁASNOŚCI

dotyczy: zapytania o informację na wykonanie systemu AXIONET wspierającego proces diagnostyki i leczenia padaczki w ramach projektu pt.” Utworzenie Centrum Badawczo-Rozwojowego Neurosphera – Narodowe Centrum Badań Klinicznych Diagnostyki i Terapii Padaczki” realizowanego w działaniu 2.1 Wsparcie inwestycji w infrastrukturę B+R przedsiębiorstw Programu Operacyjnego Inteligentny Rozwój 2014 – 2020 współfinansowanego ze środków Europejskiego Funduszu Rozwoju Regionalnego.

ZAMAWIAJĄCY: Neuphoria Sp. z o.o. ul. Włocławska 161; 87-100 Toruń, KRS 0000581451, Regon 362787241, NIP 9562313855

OFERENTNazwa Oferenta Adres Dane firmowe

Niniejszym oświadczam, że jako Oferent w ramach składanej odpowiedzi na RFI OF-2018-002-Axionet_1.5 z dnia 5.03.2018 r. deklaruję, iż w przypadku nawiązania współpracy z Zamawiającym i tym samym otrzymania zamówienia na wykonanie przedmiotowych prac, dostarczę pełną dokumentację techniczną, kody źródłowe oraz prawa własności do opracowanego systemu AXIONET.

Podpis(y):Lp. Data Nazwisko i imię osoby (osób)

uprawnionej(ych)Podpis(y) osoby(osób)

uprawnionej(ych)

Strona 20/20