Tento text je řazen proti proudu času, nejnovější položky vpředu. Při čtení na retrospektivu nebo pro orientaci v houšti změn je nutno postupovat odzadu ...

20040330:
    Pár věcí k iniciálnímu naplnění daty:

        Reprezentativní výčet testů, markerů a speciálních vyšetření. Postačí lineární zápis,
        ze kterého by se dala databáze naplnit skriptem a pak už doplňovat manuálně.

        Předpokládaný styl práce - hlavně ve fázi vyplňování výsledků vyšetření citlivostí
        a testů obecně. Bude se to vyplňovat po jednom nebo spíš hromadně ? Pokud přebíráním
        z laboratorního systému, musíme mít nějaká pravidla, jak se zkratkovitá jména
        antibiotik z laboratorního systému přeloží na jména testů. Tedy AMP na D-AMP-10 apod.
        Dtto i pro další vlastnosti kmenů. Hromadným zápisem rozumím cosi jako razítko
        s mnohými antibiotiky, individuálním pak postupný výběr testů a jejich výsledků.

        Na úrovni implementace se předjímá tento rutinní scénář práce:

            Nejspíše v laboratorním systému řeknu "Tento pacient budiž zařazen do
            agendy rezistencí, pokud už tam není". Data přeskáčou a případně se doplní o náležitosti,
            které v laboratoři (zatím) neevidujeme.

            Opět v laboratorním systému rovnou naznačím, zda se to má brát jako nový
            případ / epizoda, prostě nová věc pro daného pacienta, který případně už jakási
            historická data má.

            Uvnitř laboratorního systému si mohu jako rovnocenný pohled vyvolat i
            náhled na agendu rezistencí tak, abych nemusel přepínat mezi dvěma různými
            aplikacemi. Až zkušenost ukáže, zda se všechny funkce vznikající aplikace na 
            rezistence narvou do laboratorní aplikace nebo ne. Zatím spíše ne, protože
            chceme, aby to mohli používat i tam, kde nemají náš laboratorní SW.

            V přehledu agendy rezistencí si vybírám posléze vhodné kombinace (Pacient,Případ)
            a k nim vyplňuju výsledky vyšetření. Zase by bylo vhodné, abych tak mohl činit
            zkratkovitě z laboratorní agendy. Tedy:

                Stojím na vzorku - implicitně je vybrán již odpovídající pacient a jeho
                poslední známý případ v agendě rezistencí. Možná je znám i poslední
                Kmen přiřazený k pacientovi a případu. Takže má smysl říci cosi jako
                "založit nový záznam o Kmenu v agendě rezistencí",
                "výsledky na citlivosti přeskákejte do agendy rezistencí" nebo "nechť
                marker X je zařazen do agendy rezistencí".

            Zatím se soustředíme prioritně na možnosti manuálního vkládání údajů, zase
            s ohledem na širší spektrum potenciálních uživatelů.

            Využívání dat pro analytické dotazy a přehledy bude mít smysl nějak ladit
            a vylepšovat až poté, co budeme mít nějaká data v systému.

            Kruciální je stanovit pár rutinních scénářů práce, ve kterých se bude
            uživatel pohybovat nejčastěji a nejdéle. V případě zadávání výsledků
            by měla být asi tato kaskáda:

                V přehledu toho, co již evidence obsahuje, se naskáče běžnými metodami
                (filtrování, přetřídění, manuální doskákání, ...) na žádoucí kontext.

                Kontextem je definován pacient, případ a kmen.

                Pak se do odvolání akce implicitně týkají kontextu a předpokládá se,
                že uživatel k danému kontextu dodává nebo upravuje výsledky, jakékoli.

            V tabulkách definujících Kmeny a i v tabulce případů jsou redundantně
            doplněny pro komfort identifikační položky pacienta, aby se v tom dalo
            lépe orientovat a abychom si nemuseli dělat starosti s různými změnami
            příjmení apod. Prostě Kmen si nese údaje o pacientovi takové, jaké byly
            známy při jeho zařazení do evidence. Pokud se třeba konkrétní pacientka
            provdá, nové příjmení se uplatní u zápisů učiněných až poté, co nové
            příjmení je v evidenci. Samozřejmě bude možné vynutit v přehledu
            unifikaci takovýchto údajů. Ale z dokumentačních důvodů není dobré mít
            u starých dat odkaz na (relativně) v budoucnosti změněné příjmení nebo
            jiný identifikační údaj.


20040322:
    Nově resturkturalizována databáze, většina tabulek má definitivní tvar. Rovněž i scénáře
    pro práci.

    Hlavní věci k vyřešení:

        Bezbřehost různého kódování testú, antibiotik, mikrobů atd. je potřeba nějak razantně
        rozseknout. Data totiž začínají být zbytečně "nafouklá" díky redundanci. Máme tyto
        možnosti:

            a) zavést jednotné kódování - podle všeho to je příliš ambiciózní
            b) spravovat a distribuovat všechny "dialekty" ze všech laboratoří a orientovat
               se důsledně vždy v řeči dané laboratoře - ale pak centrální nebo obecněji privilegované
               pracoviště bude potenciálně dostávat data, se kterými si nebude vědět rady
            c) výměnu údajů omezit důsledně jenom na ta data, která jsou v jednotném jazyce
               kódů NISSAR.

        Případ c) je tedy jakousi evoluční metodou, jak konvergovat k případu a).

        Rozlišování kategorií údajů až podle nějakého determinativu. Číselník testů jsme již
        konsolidovali do podoby, kdy vyšetření citlivosti (D i MIC), markery a speciální vyšetření
        tvoří homogenní tabulku a teprve podle příznaku typu testu Tp se rozhoduje, jaká že je
        vlastně kategorie daného údaje - prakticky tedy také jaké sloupce mají význam. Pro
        potřebu výsledků je vhodná podobná konsolidace. Prozatím máme navrženy kolonky odpovídající
        výsledku (CRI), jiné na průměr zóny, jiné na jméno a výsledek testu a zase jiné pro zápis
        přítomnosti markerů. Zase by bylo vhodné maličko abstrahovat a výsledky ukládat v homogenní
        tabulce, kde se kolonky budou jmenovat spíše:

            Krátká podoba - rozumí se pro C,R nebo I
            Číselná podoba - rozumí se pro průměr zóny
            Identifikace testu - podle číselníku
            Krátká podoba jména - typicky zkratka antibiotika nebo markeru
            ...
            ... rozumí se navíc vždy verze pro lokální výsledek a odpovídající sada sloupců pro centrální výsledek

        Vlastně jde o to, abychom data předem neházeli do různých škatulek, protože by se pak obtížněji
        kladly dotazy typu vyhledat všechny kmeny, kde vyšlo buď D-AMP-10 C a přitom byl stanoven marker MRSA ...
        Pokud budou data v jednom "chumlu", je možno je pak homogenně v jednom chumlu prezentovat. Jinak je
        to databázově obtížné.

        Ještě poznámka k omezení bezbřehosti kódování. Údržba různých analytických dotazů a algoritmů bude
        obtížná sama o sobě již zamýšleným cílem propojit mnoho laboratoří. Zesložitění přes lokální dialekty
        bude složitost i pracnost ještě násobit. Chce to tedy zkraje dořešit do perfekce výměnu informací
        v trianglu NNH-SZU-JLABS za použití STEJNÝCH číselníků (JLABS nemá navíc důvod mít svoje verze,
        jedná se tedy o iniciální soulad dvou verzí) a poněkud dogmaticky šířit pak směrem do ostatních
        laboratoří prioritně obsah našich číselníků. Všechny sql-dotazy, kaskádovitě řetězené dotazy atd.
        budou implementovány důsledně v řeči NISSAR. Lokální kódy by měly sloužit jenom pro dodržení
        místního kontextu nebo pro evidenci dat, která nejsou centrálně zpracovatelná.


20040311:
    Dotazy a poznámky:

        001.Nekonzistence používání názvosloví, viz Rod x Species apod. Chtělo by to sjednotit.
 
        002.Zdravotnická zařízení a jejich kategorie - neměl by to být centrálně spravovaná databáze ?

        003.Zavedena položka "Node", která znamená lokálně totéž co "my zde" a centrálně to je krátký
            identifikátor pracoviště, které kmen odeslalo do centrální laboratoře. Bude nějak platit,
            že existuje dobrá nebo dokonce dokonalá korelace mezi takto pojatým "my zde" a zdravotnickým
            zařízením ? Nebo bude možné, že nějaké pracoviště bude zadávat data i za jiné ?

        004.Jak to je s názvy a kódy testů, citlivostí apod. Není zahrnutí k´du antibiotika do primárního
            klíče zbytečné ? Chtělo by to příklady záznamů pro všechny čtyři uvažované kategorie testů.

        005.Výsledková tabulka je udělána jako polymorfní, pásnou tedy do ní výsledky čehokoli a pouze
            podle toho co je vyplněno se bude interpretovat, co má vlastně smysl a co ne. Nemělo by se
            totéž udělat i pro čtyři typy vyšetření ? bude existovat kolize v pojmenování například
            kódu testu diskové citlivosti s nějakým speciálním markerem ?

        006.Je potřeba prověřit rozsah všech položek, hlavně kódů apod. Často je rezervováno možná zbytečně
            moc míst.

        007.Mezi pojmy popisujícími lokalizaci a číselníky na odbornosti apod. není úplný soulad.
            Je možno to nějak sjednotit ?

        008.Pacienti tvoří samostatný registr. Pak máme Pripady, to je doplnění údajů k pacientovi o
            "kde přesně" a "kdy" a "proč = diagnózy". Pripady se jednoznačně vážou k pacientovi, pacient
            ale může mít více případů. Dále máme Kmeny, popisují blíže izolovaný Kmen a vážou se jednoznačně
            k případům. Je myslitelné, že jeden případ bude mít více kmenů, v praxi to ale asi tak nebude.
            Konečně máme VysledkyVsechVysetreni. To je amorfní čí spíše polymorfní tabulka, podle typu
            záznamu se databáze na něj bude tvářit tu jako na výsledek vyšetření citlivosti a jindy jako na
            výčet detekovaných markerů.

        009.U některých položek není ani při nejlepší vůli možno určit, jak velké a jakého typu by měly být.
            Například Závěr apod.

        010.Kdekoli je možno z číselníků jednoznačně možno odvodit různé kódy, názvy apod., je to z tabulek
            vyházeno a rozumí se, že systém si kdykoli tatkovéto "závislé" položky dohledá sám.

        011.Identifikace je vymyšlena takto. Každé účastnící se pracoviště je vlastně jeden "Node" informačního
            systému. U sebe má jednoznačnou a vesměs automaticky databází přiřazovanou identifikaci všeho.
            Buď to přiřazuje nějaká centrální databáze nemocnice nebo naše aplikace. Všechna data se posílají
            kamkoli včetně automatické číselné identifikace a kódu Node. Jsou tedy globálně jednoznačná.
            Centrální databáze a obecněji databáze privilegovaného uzlu bude dostávat od ostatních uzlů
            všechny záznamy, které budou určeny k odeslání (a možná že vůbec všechny - pak by proces odeslání
            vlastně jenom spočíval v "odmaskování" již tak jako tak odeslaného záznamu pro centrální databázi).

        012.Struktura centrální a lokální databáze se nijak neliší. Pouze na straně centrální databáze nepůjde
            vyplnit lokální položky a opačně na lékálním uzlu nepůjde trumfovat zápisy od centrální databáze.
            Podobně jenom technickým způsobem budou identifikační údaje nežádoucí pro centrální databázi
            jednoduše zamaskovány spíš než aby byly zničeny.

        013.Vynecháno z pověrčivosti.

        014.Položka Věk je dána formálně na roveň Datum odběru - je to spíše atribut případu než pacienta.
            Prostě se jedná o věk, který pacient tehdy měl a u jiného případu bude případně jiný věk. Věk jako
            takový se u pacientů evidovat nebude vůbec.

20040310:
    Dokončeny základní tabulky, struktura dat.
20040309:
    Na webových stránkách je vystavena rozdělaná dokumentace.

    Schéma číselníků je již stabilizováno, pro každý existují běžné scénáře pro práci. Tedy zavedení
    nového záznamu, úprava záznamu a storno.

20040305:
    Revidována schémata tabulek, číselníky prohlášeny za definitivní.

200402*:
    Řada schůzek a jednání o reálné náplni sledvaných dat.

    Vymyšlena metoda vytváření maticového zobrazení výsledků citlivostí i z lineárních dat.
    Odpadá tím zásahy do struktury tabulek při přidávání antibiotik, testů, markerů apod.

20031201:
    Zprovozněna generická podoba projektu.

2002*:
    Zprovozněn generický uzel VaxNt v SZÚ.