eHealth


#41

Cely backend v NCZI je v prostredi DOT NET , MS SQL a BizTalk Server. Takisto aj windowsove ovladace na karticky a ich autorizacne tooly so v nativnom windows, alebo .Net. Tam su chyby v koncepciach a td. (keby sa reallzoval projekt El. Preukazu Poistenca EPP, tak by cely potrebny HW bezal v datacentre nczi. Takto sa s tym ratalo aj na zdravotnictve aj na vnutre dlhe roky. Takze nikto neriesil pripajanie 70000 zdrav. pracovnikov a desaitok tisic pacientov a overovanie ich totoznosti niekoľko stokrat denne na HW ministerstva vnutra. Ale po zruseni EPP, Vnutru zrazu padol takyto balvan do klina, s ktorym tam nik neratal …)
Ten clanok ked si precitas 2 x , 3 x a zamyslis sa nad tym tak ti povie jedno, Keby sa realizovalo EPP, tak uz dnes by asi vsetko najskor fungovalo, a keby boli problemy, NCZI sa nemalo na koho vyhovarat, lebo cely HW mal bezat u nich. Rovnako ako v Nemecku, Turecku, Azerbajdzane a dalsich krajinach, v ktorych napriek tomu ze maju obcania eID karty, tak aj tak obstaravali zvlast Preukazy positencov. Uz sa mohlo setrit. Teraz je tam jedno velke neprehladne eldorado, a realne budeme s eID chodit k lekarovi najskor v 2025 (moj odhad). A to sa este musia vymyslat workarrondy pre starych ludi, deticky, zahraniciarov … a to nehovorim ze eID na obciandkom ma stale aktivovanych len asi 60k ludi z celeho obyvatelstva … V tomto zial nikdy nebudem suhlasit s akciou “zrusme EPP, lebo usetrime 20 milionov”. Sposobene problemy a z nich generovane skody su omnoho vyssie. Nehovoriac o oddialeni … a to mozno dovtedy sa zisti, ze uz kvantove pocitace hravo prelamuju aj elipticke krivky aj neviem ake dlhe kluce a ze vlasne cela koncepcia ePodpisovania a identifikacie je nepouzitelna v praxi a vratime sa k papierom. :smiley: sorry … taka melancholicka chvilka na mna prisla.


#42

.NET Core už máš od minulého roka aj na macOS, takze naozaj nerozumiem tomu úzkostlivému lipnutiu na JAVA :frowning:


#43

ja sa trosku stracam … backend javu nepouziva.
A Front Endom v eHealthe je komercna apka, typu ambulancia, lekaren, laboratorium, ktore vyraba par komercnych vyrobcov. Vobec netusim v com su napisane a ani ma to nezaujima. Lebo to robia 15-20 rokov a kym predavaju, menit to nebudu … Citam este raz … slovo java nevidim :wink:


#44

Len tak informačne, medzičasom podala SaS trestné oznámenie v súvislosti s eHealth:


#45

Sorry, ale toto považujem za dosť demagogické.
EPP ako také bol nezmysel duálnej elektronickej identifikácie, ktorú máme v štáte riešenú aj cez eID a tam to má viacero účelov. Je absolútne logické používať JEDEN identifikátor.

Čo sme urobili zle, je to, že sme zrušili celý projekt EPP komplet - a ako to už býva, všetko bez kontextu, bez znalostí a bez riešenia dôsledkov.
Budget na EPP projekt mal byť nahradený delta projektom na integráciu s eID overovaním a zároveň časť nákladov mala byť presunutá na dotáciu výmeny občianskych preukazov. Ktorý poistenec (okrem mňa) si dobrovoľne pôjde zaplatiť za nový občiansky len preto, aby sa prihlásil na Národný portál zdravia, aby následne zistil, že tam nič nenájde…?! Doslova NIČ!!!
Zároveň zrušenie EPP odignorovalo skupiny pacientov bez občianskeho preukazu (cudzinci, deti a podobne), takže namiesto toho, aby to niekto reálne riešil, tak sme sa len hrdili, akí sme fajn, že sme ušetrili milióny za EPP projekt.

Zdôraznil by som: samotná integrácia na eID nie je problém! Problém je, ako je navrhnutá architektúra okolo toho.
Problém je, že HW infraštruktúru riešia ako monolyt, teda reálne neškálujú, len vyhodia a míňajú ďalšie milióny za nové železo. To všetko v časoch, kedy žijeme v dobe cloudu a celý IT svet má plné ústa slov ako “škálovateľnosť”, “flexibilita”, “rastúca infraštruktúra”… Ale to len dovtedy, kým niektorí nemajú dodávať infraštruktúru pre štát, lebo tam sa zasa oháňajú tým, že musia odrazu dodávať ako celok, do ktorého sa nesmie miešať nikto iný…


#46

Škálovateľné, flexibilné riešenie kompatibilné s rastúcou infraštruktútou sa dá spraviť na softvérovej/architektonickej úrovni, potom môžeš pridávať HW mašiny a škáluješ horizontálne alebo pridávaš fyzicky RAMky a škáluješ vertikálne. Riešenie, ktoré popisuješ je možné dodať aj na samostatne dodávaný HW. Cloud ti zabezpečuje najmä flexibilitu vo využití prostriedkov a efektívnejšie využitie zdrojov pre údržbu HW infraštruktúry a redundancie na rôznych úrovniach. Štandardne je tam toho viac, ale napr. sk.cloud je aj tak aktuálne iba v štádiu IAAS. (nesnažím sa obhajovať ich postupovanie, snažím sa diskusiou a špekuláciami prísť k hlavnej príčine problémov)
Je možné dodať monolytické riešenie do cloudu, ale aj relatívne škálovateľné a flexibilné riešenie mimo cloudu. Hlavným problémom bude ako píšeš pravdepodobne architektúra, od biznisovej cez aplikačnú až po technickú.


#47

Java ekosystém je otvorenejší a je v ňom väčšie množstvo možností ako vyriešiť nejaký problém. Rovnako existuje množstvo nástrojov, frameworkov, libiek a technológií, ktoré sú vyvíjané s otvoreným zdrojom v javovom svete. Dáva zmysel vybrať vhodnú technológiu / jazyk na daný problém. Performance rozdiely pri správnej implementácii a vhodnej optimalizácii by mali byť malé. Cena HW je aj tak vo veľa prípadoch pomerne nízka v pomere s cenou, ktorá sa vynaloží na support, udržiavanie, zmeny, a vývoj softvéru. Preto je lepšie vybrať vhodnú technológiu a jazyk pre ten daný konkrétny problém a za daných okolností, lebo neexistuje najlepší jazyk a najlepší framework pre všetky prípady použitia.


#48

Neodignorovali. Teda aspoň my sme to s NCZI riešili, a s MV tiež. Z toho čo nám bolo prezentované sa nespravilo nič.

Súhlasím. A ak by sa spravilo EPP, tak by tam bolo rovnaké nič, ale všetkých by nás v peňaženke hriala super elektronická kartička.

Len by som pripomenul, problém je v IAM (v Nases). Riešenie o ktorom v článku píšu je, že obídu IAM a budú s AS eID (v MV) komunikovať napriamo. Pokiaľ viem časť na strane MV je (technicky) bez problémov škálovateľná, až po možnosť mať postavený samostatný AS pre konkrétnu aplikáciu.


#49

To je všetko samozrejme pravda, ale otázka znie inak… :slight_smile:
Prečo potom pri upgradoch štátnej infraštruktúry z dôvodu výkonu vždy hovoríme minimálne o stovkách tisícoch až miliónoch?

Páči sa mi to sa nespravilo… :wink:

A na to prišli teraz? A celkom sami? Pripadá mi to ako objaviť teplú vodu. Triezvo uvažujúcemu architektovi to malo trknúť hneď, ako sa začalo hovoriť o zrušení projektu EPP. Potom by snáď neurobili takú debilinu ako zrušiť EPP projekt bez náhrady. Ak ak áno, nech idú do … (minulosti) všetci, čo sa na tom podieľali.


#50

Ale akože “bez náhrady”? Veď spravili tú integráciu na IAM. Tak ako to majú oficiálne všetky OVM robiť.

Zmluva o SLA k tomuto sa dá ľahko nájsť: http://www.crz.gov.sk/index.php?ID=2659971&l=sk
Zrejme ide o službu “sluzba_is_158* / Poskytnutie autentifikačného rozhodnutia zo systému
Identity and Access Management / SLA_S3”.

Pre ňu sú v tejto zmluve definované parametre:

  • “garantovaná doba odozvy” = 10 sekúnd
  • “maximálny počet požiadaviek” = 100 za minútu
  • “maximálny počet simultánnych pripojení” = “Parameter nie je stanovený voči jednotlivým službám, ale je stanovený voči celému ÚPVS na úrovni max. 5000 simultánnych pripojení.”

Áno, súhlasím, pri lucídnom riadení projektu muselo byť okamžite jasné, že žiadny z týchto parametrov nebude pre eHealth stačiť.

V zmluve sa píše:

Tak reku že pozriem ako na tom je reálna prevádzka. Na stránke uvedenej v zmluve nie je však nič:

Pozrel som teda s nádejou do MetaIS:
https://metais.finance.gov.sk/monitoras?serviceUuid=59e809ec-b21e-434e-8b99-fd92510bd206

A tam - taktiež nič…
Ale určite pomôže investovať 10M do lepšieho MetaIS…


#51

nie celkom rozumiem problemu, mame tu system na MV ktory ma poskytnut identitu, ak ten nie je dost vykonny tak tu mame cloud pod MV ktory to snad dokaze doplnit.
Ak dobre chapem, tak NASES nema dost priepustne hrdlo ale to sa da obist priamym pripojenim. ( a uprimne mozno to nie je akadamicky pekne ale urcite je to lahsie ako cokolvek ine, )
projekt EPP bol z tohto pohladu aj tak zamerany na vydavanie karticiek a nebol by schopny takuto poziadavku splnit. Sice by sa nemohli vyhovarat na NCZI ale tento problem by zostal.
A len taka poznamka, neviem ako ale aj tak som zachytil ze sa vydavaju zdravotnicke preukazy, nevies o tom nieco ?

A prakticky, ak si myslis ze zdravotne preukazy by mali uspesnejsiu penetraciu ako EID, tak logicky ich spojenie by bolo este lepsie. Ale nieco nejde urychlit, techooptimisticke predpovede big bangov nepresli nikde na svete.


#52

mari sa mi zle to bol jeden z vasich argumentov ze sa predsa musia integrovat na IAM :slight_smile: ? A teda teraz to bude de iure porusenie schvalenie zavaznej koncepcie ?


#53

Pokiaľ si pamätám, nepresadzovali sme konkrétny spôsob realizácie (kto sa má kam integrovať), ale skrátka že sa má použiť eID.

Konkrétne sme napr. presadzovali, aby funkcia detekcie prítomnosti a identifikácie (karty) bola bez BOK a spravená v offline režime, t.j. nebolo by potrebné kontaktovať žiadne servery. Skrátka eID klient, alebo iný podobný lokálny softvér, by vedel spoľahlivo zistiť, že v čítačke je vložený eID a vrátil by jeho nejaký identifikátor, bez žiadnych osobných údajov.
Presne toto by malo u lekára pri bežnej práci s pacientom stačiť.


#54

tymto sposobom vies aj zistit ze v citacke neni len nejake barsjake eid, ale eid patriace pritomnemu pacientovi ?


#55

Dnes ako lekár zisťuje kto je “prítomný pacient”? Podľa kartičky poistenca, ktorá nemá PIN, ani čip - ba dokonca ani fotku držiteľa (nenápadne navádzam).


#56

Na to som sa nepytal :slight_smile: Len som neporozumel, ze ako eID splni svoju funkciu (potvrdit pritomnost pacienta) prostrednictvom scenara co navrhujes…


#57

A ja som odpovedal, že overením fotografie na kartičke.
Pritom režim “bez BOK” je teda v eHealth spravený aj teraz (tak si pamätám čo mi naposledy hovorili) - akurát že eID sa online overuje.


#58

EPP je (ak sa nemýlim) elektronický preukaz poistenca, teda kartička, ktorú sme pôvodne mali dostať všetci. Toto nebude.

Vydávajú sa EPZP, teda elektronické preukazy zdravotníckeho pracovníka, čo je úplne iný príbeh. EPZP karty sú pre zdravoťákov. Vyvstáva síce tiež otázka, na čo je potrebná extra identifikácia, keď môžu mať eID, ale tvárime sa, že je to tak správne, lebo je to podobne tak aj pri notároch a podobne. Pôvodne mala karta aj iný účel, než len identifikácia, podpis a šifrovanie/dešifrovanie (VPN), ale z toho našťastie zišlo.


#59

EPZP je limitovane pouzitelny. v nemocniciach ich lekari nemaju… su casovo obmedzene takze sa budu musiet prevydavat / predlzovat…


#60

áno, ale certifikáty sú platné celkom dlho (neviem z hlavy presne, ale čakal som kratšiu dobu popravde).
Tuším som niekde započul, že procesy okolo prevydávania certifikátov ešte nie sú úplne doriešené, tak verím, že to zasa raz nebudeme riešiť “v časovej tiesni”… Teda aktuálne to ide iba cez NCZI a to je na dlho. Pokazená karta alebo exspirovaný certifikát by mal dnes za následok de facto to, že lekár nebude môcť vykonávať svoju prax (aspoň z pohľadu eZdravie) po dobu niekoľko dní (rádovo aj týždne).
Lekári v nemocniciach (aj mimo) by ich už mali mať. Mali zákonnú povinnosť ešte minulý rok požiadať o jeho vydanie, potom na prelome rokov boli celkom veľké omeškania dodávok, ale reálne dnes by už mali mať všetci, čo si zažiadali v zákonnej lehote. Problém je, že im je to na nič, lebo viaceré systémy nie sú stále úplne pripravené na používanie… Tak to majú doma v šuplíku a čakajú, kým ich niekto vyzve, že “už to naozaj treba”. :smiley: