Aký má význam dať po 4 rokoch pokutu 
Aj keby chceli, tak to už nemajú komu zosobniť. Peniaze na pokutu dajú do budúcoročného rozpočtu… Služby na nefunkčné eZdravie “sato” bude fakturovať naďalej
1 Like
Vyriešenie majetkových práv umožní do budúcna okrem rozšírenia eslužieb aj postavenie novej verzie systému. Ezdravie 2.0 by postupne nahradilo zastarané procesy.
eZdravie nikdy v prevádzke nebolo. Tie akože zastarané procesy, ktoré poskytuje eZdravie boli len mokrý sen pôvodného vedenia NCZI aj s dodávateľmi, že eZdravie zázračne cez vypínač zmení niekoľko desiatok až stoviek rokov praxe v zdravotníctve.
Som zvedavý či aj zverejnia zdrojové kódy, vrátane histórie zmien. Nejaké štatistiky o počte zúčastnených vývojárov by sa z toho dali urobiť a porovnať ich s mesačnými výkazmi z faktúr.
alebo asseco a lynx ?
V tom clanku spominaju vybudovanie/prenajom vlastneho datoveho centra:
S akým objemom peňazí počítate?
Pôvodný projekt bol v rozsahu 45 až 60 miliónov eur. Zhodnotili sme východiskovú situáciu, potrebujeme zastabilizovať a vyriešiť prvú lokalitu dátového centra, to by malo byť rádovo niekoľko miliónov. Prepojenie s druhým datacentrom a dokončenie komunitného cloudu odhadujeme celkovo do 20 miliónov, čo je skoro o dve tretiny menej ako boli navrhované riešenia.
Nema nahodou stat uz jedno vlastne datove centrum (statny cloud), alebo sa mi to iba prisnilo?
Ma, neprisnilo. Ale ani cloud nemá neobmedzenu kapacitu. Tobôž nie slovenský.
A co takto za tych spominanych 20 milionov rozsirit statny cloud?
“Zdravotné údaje sú dáta vyžadujúce špeciálnu ochranu” a preto štátny cloud nevyhovuje.
Rovnaký SW od “správneho” dodávateľa však vyhovovať bude 
.
eZdravie používa ako úložisko DB Microsoft SQL. Dátový model je podľa mňa veľmi zlý, odozvy sú katastrofálne ( môžete si vyskúšať sami cez EZKO ). Nie je to pripravené na prevádzku Master-Master v dvoch rôznych lokalitách. Nový cloud to podľa mňa nezachráni. Žiadna SQL DB s koncepciou Consistency/Availability nie je vhodná pre dané objemy a typ údajov a požadovanú dostupnosť.
to radsej prenajat AWS … urcite nie tento statny cloud … ten uz v podstate nevyhovuje ziadnym novym projektom. IS UVZ napriklad ide na prenajatom cloude od Oracle, leb o statny cloud nevyhovuje.
3 Likes
Je teda v dnesnej dobe na nieco ten statny cloud vhodny/dostatocny?
vyrábali by sme štátne SÚV-čko ?
V živote nedobehne nielen že štát, ale ani nik iný (to by musela byť inak masívna investícia na úrovni Elona Muska) to čo iní frajeri denne vylepšujú už 15 rokov … myslieť si, že vezmem servareń, servery a sieťové prvky a spravím niečo podobné AWS je utópia. Češi už prenajímajú Azure, vláda USA podpísala zluvu s AWS a ten jej poskytuje svoje služby … atď …
4 Likes
Goldplating v praxi… 
Ale aký je dôvod spojiť prevádzku starého a vývoj nového systému do jedného tendra pre jedného dodávateľa?
Chceli sme zabezpečiť prevádzku už v jednom režime.
Som zvedavy ci sa najde aspon jedna firma/konzorcium, ktora sa odhodla dat ponuku proti sucasnemu dodavatelovi eZdravia. Nastudovat stovky tisic riadkov v starom .NET kode v roznych projektoch, mixnute s integracnym ESB nie je trivialita. Kazdy potencionalny zaujemca musi investovat nezanedbatelne peniaze do tejto oblasti. Povovodny dodavatel nemusi …
Basnicka otazka : Aky ma teda vyznam spojenie tych dvoch oblasti do jedneho projektu ?
Od oficialneho spustenia eHealth ( 21.12.2015 ) uplynulo 6 rokov. Do stareho systemu eZdravie sme investovali ako stat >100M eur. Sami pani z NCZI priznavaju ze funguje iba eRecept. To je vsak riesenie z Dovery.
Vdaka neexistujucim kontrolam kvality dat je ich hodnota otazna. Cenne su iba udaje, ktore prechadzaju cez zdravotne poistovne ( to tiez priznava NCZI ). Takze najjednoduchsim riesienim je to co som tvrdil uz pre troma rokmi => “Ako sa da pomoct eHealth ? Vypnut a vymazat.”
Zacat treba odznova na zelenej luke bez historickych nanosov. V spolupraci so ZP. S respektovanim tokov udajov a ciselnikov ktore su v tejto oblasti uz dlhodlbo pouzivane ( napr. 6/9-miestny kod lekara alebo 12-miestny kod PZS ).
V predchadzajucom prispevku NCZI hovori, ze od 2024 bude novy system eZdravie, v nasledujucom zas ze do stareho ideme investovat dalsich 11M
Dodávatelia sa tiež zaviazali najneskôr pri akceptácii alebo prebratí príslušného plnenia poskytnúť NCZI najaktuálnejšiu verziu komentovaných zdrojových kódov, a to aj každej čiastkovej úpravy alebo doplnenia systému.
Skoda ze nevypytali git-clone, mohli sme sa pozriet ci vykazy prac zodpovedaju commitom
Záväzok trvá ešte tri mesiace po zabezpečení nového poskytovateľa služieb. Pomoc ale nebude bezplatná. Spoločnosti si budú účtovať podľa zmluvných podmienok a rozsah predmetných služieb si odsúhlasia so štátom.
Vid predchadzajuci komentar ku nakladom na prevzatie diela. Ak by sa aj nasiel novy dodavatel, ktory by to bol ochotny prevziat, tak ma na to najviac tri mesiace.
1 Like
Tak defacto ono sa to môže udiať, nebol by to prvý projekt, ktorý sa pod rozšírením kompletne prepísal. Otázne je či také prepísanie niečo prinesie, pretože zrejme v tomto prípade je kód tým najmenším problémom (nech už je hocijaký).
NCZI priznáva, že to nie je rozšírenie, ale vytvorenie nového systému s migráciou dát zo starého systému.
Účelovo/úmyselne však spojili zmluvu na support starého eZdravie s obstaraním nového systému.
Hodnota tých údajov, ktoré sú v eZdravie je otázna. Najčistejšie sú údaje zo ZP, tie však nie sú kompletne (čo viem tak chýba celé DRG a data staršie ako X-rokov). Do tejto kategórie patria aj eRecepty. Načítanie 10riadkov trvá 20sekund, takouto rýchlosťou by migrácia dát trvala tri roky. Jednoduchšie je urobiť novú inicializaciu podľa dát ZP.
Potom sú tam nejaké eVysetrenia, nie sú však všetky. Nemali žiadnu kontrolu kvality dať a je otázne či ich nepomiešali medzi pacientami. ( aj také sa stalo ).
Ostatné evidencie (napr. eLab) sú viacmenej prázdne.
A prečo chyba práve toto?
Pretoze DRG vznikalo subezne s eHealth/eZdravie t.j. v case analyzy to neexistovalo ale v case zavedenia do prevadzky uz ano. Bolo potrebne aktualizovat datove rozhranie, co (pokial viem) nebolo zrealizovane.
Ak mam pravdu, tak v udajoch na ucte pacienta chybaju pre hospitalizacie nielen DRG-skupiny ale aj hlavna/vedlajsie diagnozy, zrealizovane vykony, pripocitatelne polozky, dovod/druh prijatia/prepustenia. Celkom dost strukturovanych udajov, pouzitelnych pre automatizovane kontroly.
Hmm tak toho teda nie je vela, resp. skoro nič, to je teda celkom fail celé. omg. a to chcu teraz opraviť cez onko asist? lebo na metais nevidim nejaky iny projekt, teda okrem ziskavanie dat
Nechcu.
V onkoasist chcu iba spristupnit vykazanu ZS pre osetrujucich lekarov. Kvoli tomu potrebuju upravit legislativu 153/2013 Z. z. Zákon o národnom zdravotníckom informačnom systéme | Aktuálne znenie paragraf 5 odsek 6 Kedze metody pre spristupnenie tych dat pre pacienta uz existuju, tak z pohladu kodovania by to nemalo byt vela roboty.
Zavedenie DRG bola legislativna zmena ( na urovni vyhlasky ), takze podla mojho nazoru to malo byt dopracovane uz davno ako sucast supportu, kedze v supporte je aj sledovanie legislativnych zmien.
Toto dopracovanie vsak bude mat dopad na datovy model / zmeny v rozhraniach na strane eZdravie aj vsetkych poistovni. Co je celkom dost roboty a asi sa do toho nikomu nechce.