Opis stretnutia

=========================================

Stretnutie k projektu Normativne data EMG (20.12.2000)

=========================================

Niekolko postrehov:

Dospeli sme k poziadavke vytvorenia "velkej" poziadavky merania, ktora sa rozposle vsetkym zucastnenym v zbere normativnych dat, lekari budu merat "vsetko" na jednotlivych dobrovolnikoch

vyhodnocovanie sa predpoklada na urovni jednotlivych testov (struktura - technika - segment).

Dalej budeme pouzivat tieto pojmy:

poziadavka - mnozina testov (v predchadzajucom texte oznacena ako "velka" poziadavka)

test - trojica (struktura, technika, segment)

Riesenie mozno rozdelit do troch casti, ktore by mohli fungovat ako samostatne aplikacie s podmienkou, ze pracuju s dohodnutymi strukturami udajov:

A. VYTVORENIE POZIADAVKY

========================

na to, aby sa dala poziadavka vytvorit treba

A1.definovat skupiny struktur (zrejme bude stacit, ak sa budeme zaoberat iba nervami), pre ktore

su techniky a parametre rovnake

A2.analyzovat parametre jednotlivych technik (nutne a volitelne) - pre prislusne skupiny struktur

A3.vytvorit testy

(trojice "struktura - technika - segment"), ktore budu sucastou poziadavky (mozno vo forme

stromu, kedze pre jednu strukturu muoze existovat viac testov - meria sa viacerymi

technikami a na viacerych segmentoch)

A4.zabezpecit export poziadavky (zrejme XML)

treba zvazit "priatelskost" rozhrania

- mozno vytvorit aplikaciu, kde to lekar bude muoct zadavat bez pomoci

- kombinacia vyssie uvedenych moznosti

(prvu moznost velmi neodporucam, lebo pri kazdej zmene - a tie urcite budu - by bolo treba

asistenciu programatora; treba zvazit - mozno poziadavky A1. a A2. by sa mohli urobit v ramci

niekolkych sedeni priamo do databazy a poziadavka A3. by sa riesila okienkovym rozhranim; aj

v takomto pripade odporucam co najviac pripravit materialy tak, aby MUDr. Kucera iba nieco

pozaskrtaval...)

("Velkych") poziadaviek muoze byt viac (casom) a preto by bolo rozumne uz

teraz na to mysliet a identifikovat vytvorenu poziadavku menom.

Vytvorenu poziadavku treba rozposlat. Kedze sa vsak zatial nepredpoklada velky pocet zucastnenych v zbere EMG dat, staci export poziadavky do tvaru, ktoremu "rozumie" aplikacia zberu nameranych hodnuot a poslanie muoze byt v rezii lekara (napr. elektronicka posta s prislusnym navodom co robit - kde nakopirovat prislusny subor).

V pripade, ze by aplikacia zabezpecovala aj rozposielanie poziadavky, bolo by vhodne evidovat jednotlive pracoviska a lekarov.

B. MANAZMENT ZOZBIERANYCH DAT

=============================

tato cast by mala zahrnat minimalne

B1. prijatie a uchovanie zozbieranych dat z jednotlivych pracovisk (s tym suvisi pouzitie evidencie

jednotlivych pracovisk a lekarov),

B2. ich sumarizacie a prehladne zobrazovanie

B3. podporu vytvarania a evidovania "doplnujucich poziadaviek"

(doplnujuca poziadavka spociva v identifikacii hlavnej poziadavky

a ohraniceni v zmysle veku a/alebo pohlavia - predpokladame, ze

poziadavka sa muoze zmenit/doplnit, hoci snaha je, aby bola nemenna)

C. ZBER NAMERANYCH UDAJOV

=========================

tato cast zahrna funkcnost aplikacie NODAC minimalne s tymito zmenami a doplnkami:

C1. zabezpecit priame nacitanie hodnuot z pristroja (import)

(pri tejto ulohe treba analyzovat ake udaje pristroj poskytuje a snazit sa o uchovanie

maximalneho mnozstva udajov)

C2. aplikacia by sa nemala odvolavat na subory, mala by pracovat s "velkou poziadavkou" a

zobrazovat strom pozadovanych testov (zvazit, ci zobrazovanie stromu - poradie - by nemalo

zavisiet od doteraz zozbieranych udajov - toto ma zmysel vtedy, ak sa predpoklada, ze lekar na

jednom sedeni "nezmeria" vsetko a ked zacne vzdy zhora, tak bude velky rozdiel v mnozstve

zozbieranych udajov);

celkovo by sa v aplikacii mali pouzivat pojmy problemovej oblasti a nie informaticke pojmy (iba

v pripade nevyhnutnosti)

C3. namiesto filtra by bolo zrejme efektivnejsie urobit zoradovanie

C4. session by sa nemala tykat iba jedneho testu (struktura-technika-segment), ale celej velkej

poziadavky (NODAC vyzaduje pre kazdy test zadavat udaje o osobe) - da sa to dosiahnut

vyberom vsetkych testov, ale takto je to nepriehladne a zlozite

C5. zvazit uchovavanie udajov o osobe a tieto potom iba spristupnovat

Odporucam zvazit rozdelenie sil v ramci jednotlivych timov – vyzaduje to spolupracu v suvislosti s navrhom jednotnej struktury udajov. Otazkou je, ci aplikacia na zber nameranych udajov (bod C), ma pracovat iba s formatom XML alebo aj s databazou a XML pouzivat iba ako format import/export pri komunikacii s dalsimi aplikaciami.

Mne sa zda rozumne rozdelenie taketo:

- casti A. a B., ktore zahrnaju vlastne funkcnost NODAM

- cast C, ktora zahrna funkcnost NODAC obohatenu o priame nacitanie merania z pristroja

Jednotlive casti nemusia predstavovat oddelene aplikacie. Ak bude napr. cast A. a B. realizovat jeden tim, muoze (a zrejme aj bude) to jedna aplikacia.

Prioritou je vytvorenie pouzitelneho systemu, ktory by umoznil minimalne zber udajov podla vytvorenej (velkej) poziadavky, uchovavanie tychto udajov a aspon minimalne vyhodnocovanie (sumarizacie, prehlady).

Harmonogram prac v timoch:

==========================

- do konca januara: stretnutie a vyjasnenie zakladnych otazok a rozdelenia prac

Tim 1 sa stretne 19.1.2001 o 11.00

Tim 2 sa stretne 26.1.2001 o 13.00

- do 15.2.2000: prvy navrh spolocnej struktury udajov (ide o cast poziadavka, netreba sa zaoberat

napr. databazou lekarov, ci meranych osuob)

- do konca februara: dokonceny navrh struktury udajov (aj na zaklade konzultacii s MUDr. Kucerom,

predpoklada sa minimalne jedno stretnutie), vytvorenie priroritneho zoznamu funkcii, ktore treba realizovat

- marec: protoyp funkcii s najvyssou prioritou (vytvorenie poziadavky, zber udajov, "nejake" prehlady), predvedenie prototypu MUDr. Kucerovi (koniec marca)

- april: postupne doplnanie o dalsie funkcie, integracia, testovanie;

predvedenie aktualneho stavu MUDr. Kucerovi (koniec aprila)

- maj: dokoncenie implementacie, testovanie, zdokumentovanie, odovzdanie

- jun: obhajoba timoveho projektu

Predbezny harmonogram stretnuti s MUDr. Kucerom:

================================================

februar: vyjasnenie skupin struktur, povinnych nepovinnych parametrov a obsahu poziadavky

struktura udajov z pristroja Viking (muoze byt viac stretnuti)

marec: predvedenie prototypu, doladenie poziadavky, doplnenie udajov

april: predvedenie prototypu, diskusia

maj: posledne doplnky, nejasnosti

jun: obhajoba (predpoklada sa ucast MUDr. Kuceru)