Red Flags: Online procesy eZdravia

Red Flags Projekty
,
1

Názov:* Online procesy - ezdravie (pôvodný názov: Online procesy eZdravia)

Garant: Národné centrum zdravotníckych informácií (NCZI)

Stručný opis: Cieľom projektu je prostredníctvom elektronizácie vybraných procesov optimalizovať trvanie vybraných kritických procesov: vybavenie registrácie a ukončenie platnosti registrácie pre poskytovateľov zdravotnej starostlivosti, poskytovateľov sociálnej pomoci, zdravotníckym pracovníkom a prijímateľom zdravotnej starostlivosti, evidenciu pracovno-právnych vzťahov, kapitačných vzťahov, zastupovaní poskytovateľov zdravotnej starostlivosti, zmluvných vzťahov medzi Zdravotnou poisťovňou a Poskytovateľom zdravotnej starostlivosti a poistných vzťahov medzi Zdravotnou poisťovňou a Prijímateľom zdravotnej starostlivosti.

Náklady na projekt: 2M Eur (investície) + 1M Eur (prevádzka 10 rokov)

Aktuálny stav projektu: Obstarávanie

Čo sa práve deje:

  • Verejné obstarávanie

Zhrnutie hodnotenia Red Flags: Prepracovaný projekt rieši aktuálny problém neúmerne dlho trvajúcich procesov a zlého stavu správy údajov, ktorý pretrváva kvôli nesystémovému prístupu v doterajších projektoch súvisiacich s eHealthom.
V projekte absentuje komplexný pohľad na aktuálny stav riešenia eHealth, zrealizovaných a pripravovaných projektov rezortu MZ SR a preto nie je jasné aký bude mať projekt skutočný prínos pre eHealth.

Stanovisko Slovensko.Digital: Predložený projekt znamená pokračovanie nesystémového prístupu budovania eGovernmentu v rezorte MZ SR. Po prepracovaní projektu boli optimalizované náklady na realizáciu a sú riešené len akútne problémy neúmerne dlho trvajúcich procesov a zlého stavu správy údajov. Kľúčovými podmienkami pre budúcu integráciu výstupov projektu s ďalšími projektami eHealth a životnými situáciami realizovanými v rámci eGovernmentu je dôsledná realizácia funkcionality OpenAPI, MyData a OpenData. Realizácia projektu bude mať prínos v skrátení lehôt vybraných procesov a znížení pracovnej náročnosti na správu ich údajov.

:triangular_flag_on_post: HODNOTENIE RED FLAGS

I. Prípravná fáza

Reforma VS :star::grey_star::grey_star::grey_star:

Projekt rieši aktuálny problém neúmerne dlho trvajúcich vybraných procesov a zlého stavu správy ich údajov. Optimalizuje vybrané agendy a doby vybavenia registrácie, ukončenia platnosti registrácie. Optimalizované sú aj evidencie pracovno-právných, kapitačných, zmluvných a poistných vzťahov. V projekte sú definované a popísané vybrané procesy.

Projekt rieši optimalizáciu iba aktuánych procesov v NCZI a ďalších organizáciách: ÚDZS, PovOrg, ZP, Komory a ďalších zainteresovaných stranách. NCZI má s nimi podpísané memorandá o spolupráci pri realizácii projektu.

Cieľom projektu je postupne zrušiť nutnosť tlače, ktorá sa využíva v súčasnom stave aj pri elektronickom podaní, kde je celá dokumentácia aj v papierovej forme. Cieľom je postupné zrušenie papierových dokumentov v procese spracovania podania, ako aj na výstupe z úradu v horizonte 10 rokov.

Merateľné ciele (KPI) :star::star::star::grey_star:

Screenshot 2
Screenshot 21978×490 83.1 KB

Screenshot 3
Screenshot 31978×1090 309 KB

Screenshot 4
Screenshot 41978×764 123 KB

Pri stanovení cieľových merateľných ukazovateľov neboli zohľadnené možnosti zmeny súvisiacich procesov pri optimalizácii a realizácii prepracovaného projektu.

Dobrým príkladom je ukazovateľ “Registrácia PrZS (novorodenci)”, ktorý označuje dobu, ktorú trvá zavedenie dieťaťa do systému eHealth po jeho narodení. Bohužiaľ plánovaná cieľová hodnota “3 dni” je stále nedostatočná a naznačuje pokračovanie nekoncepčného prístupu.

Postup dosiahnutia cieľov :star::star::star::grey_star:

Screenshot 1
Screenshot 11976×1112 250 KB

Projekt bude realizovaný metódou waterfall v dvoch etapách. V 1. etape bude vytvorené a nasadené plne funkčné riešenie v NCZI. V 2. etape bude riešenie implementované a nasadené do ďalších dotknutých organizácií.

Súlad s KRIS :grey_star::grey_star::grey_star::grey_star:

Koncepcia rozvoja informačných technológií, resp. akákoľvek stratégia smerovania rozvoja a prevádzky IT systémov NCZI a celého rezortu zdravotníctva nie je aktualizovaná a nie je známa. KRIT NCZI nedefinuje/nepozná tento projekt. Úlohou KRITu je poskytnúť koncepčný pohľad na rôznych úrovniach na budovanie IT v danej organizácii/rezorte. Je potrebné minimalizovať stav, že sa schvaľujú IT investície, ktoré nie sú definované v KRITe. Ak sa taká IT investícia objaví, je potrebné KRIT aktualizovať.

Neaktualizovaný KRIT znamená, že nie je aktuálny pohľad na rezortnú architektúru, vzniká priestor na duplicity s inými projektami a pod., ktoré vnímame aj v tomto projekte. Projekt smeruje dodatočné zdroje do prostredia eZdravia. Okrem tohto projektu sú plánované ďalšie projekty rozširujúce projekt eZdravie, t.j. ide o dodatočné rádovo desiatky miliónov Eur do eZdravia. Absentuje úprimný a odborný pohľad na eZdravie, jeho funkčnosť a jednotlivé moduly a rozhodnutie, či má význam realizovať ďalšie investície do tohto projektu, ľudovo povedané, či “stavať dom na hnilých základoch”.

Biznis prínos :star::star::star::grey_star:

Projekt má riešiť centrálnym spôsobom skrátenie doby trvania vybraných procesov, konsolidáciu ich údajov, zasielanie údajov medzi organizáciami a zabezpečenie kvality údajov.

Tento cieľ je správny, avšak dotýka sa iba existujúcich procesov a konsolidovať bude súvisiace údaje.

Projekt rieši podporu optimalizácie prioritných životných situácií: Narodenie dieťaťa, Úmrtie a dedičské konanie, Som chorý, mám chorého člena rodiny, Začatie podnikania.

Dotknuté organizácie, ktoré spolupracujú na realizácii projektu majú s NCZI podpísané memorandá o spolupráci, kde deklarujú, že budú aktívne spolupracovať s NCZI za účelom riadnej realizácie projektu, dosiahnutí jeho účelu a cieľa a zachovaní výsledkov projektu v dobe následného monitorovania projektu.

Deklarované optimalizácie a integrácie sa majú dotknúť viacerých ďalších organizácií podieľajúcich sa na vybraných procesoch. Okrem NCZI sú to: Poskytovatelia zdravotnej starostlivosti, Prijímatelia zdravotnej starostlivosti, Zdravotnícki pracovníci, Úrad pre dohľad nad zdravotnou starostlivosťou, Vyšší územný celok, Zdravotné poisťovne, Stavovská organizácia v zdravotníctve, Ministerstvo Zdravotníctva SR, Štátny ústav pre kontrolu liečiv, Regionálny úrad verejného zdravotníctva, Ministerstvo vnútra SR, Sociálna poisťovňa.

Príspevok v informatizácii :star::grey_star::grey_star::grey_star:

Projekt bude realizovaný v rámci vládneho cloudu. Jednotlivé moduly budú budované ako cloud aplikácie, s maximálnym využitím softvérových produktov s open licenciami.

Vendor Lock-in a autorské práva - V projektových dokumentoch sú jednoznačne požadované/definované podmienky, aby bol vylúčený právny (licencia, vlastnícke práva), dátový a technologický lock-in. Autorské práva k SW sú definované tak, že je jasne oddelené čo sa dodáva ako produkt s vhodnou licenciou a čo sa dodáva ako vývoj na zákazku s tým, že objednávateľ má k tomu všetky majetkové práva, t.j. môže výstupy projektu použiť ako chce (meniť, dať ďalším, zverejniť atď.)

Protoyp GUI a navigácie - V projektových dokumentoch je požadované dodanie plne funkčného otestovaného riešenia v rámci 1. etapy realizácie projektu, ktoré v prípade potreby bude optimalizované na začiatku 2. etapy pred implementáciou do ďalších organizácií.

Elektronické služby/ funkcionalita/ formuláre - V projekte sú požadované/definované “oficiálne” služby a funkcionalita, ktoré sú skutočne potrebné.

1x a dosť - projekt má definované všetky potrebné integrácie na externé IS VS na zabezpečenie princípu 1x a dosť.

OpenAPI - Riešenie má byť predmetom analýzy.

Riadenie/migrácia údajov - V projekte je riešená migrácia dát vrátane kvality dát a ich prenosu.

MyData - V projekte je plánovaná elektronická služba, kde sa subjekt (FO/PO) dozvie aké údaje sú o ňom spracúvané v archívnych systémoch a služby pre bádateľov v archívoch.

OpenData - V projekte sa plánuje zverejňovanie datasetov na data.gov.sk. Presný rozsah bude vyšpecifikovaný v Realizačnej fáze projektu, ale minimálny plánovaný rozsah je definovaný už v dokumentácii iniciálnej fázy projektu.

Zdrojový kód/ OpenSource - V projekte nie je požadované/definované, že zdrojový kód s dokumentáciou bude samostatným výstupom projektu, bude zverejňovaný a dostupný a že dokumentácia zdrojového kódu bude zverejňovaná a dostupná. Požadované je len to, že zdrojový kód má mať licenciu EUPL.

Štúdia uskutočniteľnosti :star::star::grey_star::grey_star:

Projekt má vypracované a schválené projektové dokumenty Prípravnej fázy. Predmet projektu je definovaný dostatočne. V projektovej dokumentácii je slabo spracované porovnanie rizík.

V dokumentácii nie je popis a vyhodnotenie aktuálneho stavu eHealth a väzby projektu na ďalšie pripravované a realizované projekty v rezorte MZ SR.

Alternatívy :star::star::grey_star::grey_star:

Popísané sú 3 alternatívy, nie je však jasný logický postup, ktorým bola vybraná podpora procesov. Aletrnatívy 2 a 3 sa líšia iba počtom integrácií. Zdrojové údaje na preukázanie ekonomickej efektívnosti zvolenej varianty sú dostatočné.

Kalkulácia efektívnosti :star::star::grey_star::grey_star:

Prínosy projektu sú jasne formulované.

Za vážny nedostatok považujeme, že v analýze nie sú uvažované náklady na zmeny procesov a IS u iných správcov ako NCZI.

Participácia na príprave projektu :star::star::star::star:

Projektovú dokumentáciu prepracovaného projektu bolo možné pripomienkovať. Všetky pripomienky a zásadné otázky, ktoré boli diskutované na vyhodnotení verejného pripomienkovania projektu boli akceptované a zapracované.

II. Obstarávanie / nákup

Verejné obstarávanie na pôvodný projekt:
URL na vestník verejného obstarávania: https://www.uvo.gov.sk/vyhladavanie-zakaziek/detail/oznamenia/421278
Dátum vyhlásenia VO: 12.9.2019
PHZ: 15 604 708 EUR bez DPH
Dátum predloženia ponúk: 17.10.2019/24.10.2019/31.10.2019
Dĺžka trvania zákazky: 144 mesiacov
7.5.2020 bolo zrušené verejné obstarávanie na "Online procesy eZdravia a služby prevádzkovej podpory

Verejné obstarávanie prepracovaného projektu:

:file_folder: Dokumenty

Dokumenty pôvodného projektu:

Dokumenty prepracovaného projektu:

:clock2: Aktivity

V tomto projekte už prebehli nasledovné dôležité aktivity / míľniky:

  • Tento projekt nahrádza projekt KUZZ, ktorý bol zrušený.
  • 21.5.2018 Reformný zámer schválený HK OP EVS
  • 29.11.2018 Verejné prerokovanie štúdie uskutočniteľnosti
  • 17.12.2018 Schválená štúdia uskutočniteľnosti
  • 19.2.2019 Vvyhlásená výzva na predkladanie žiadosti o NFP
  • 20.5.2019 Predložená žiadosť o NFP
  • 16.8.2019 Schválená žiadosť o NFP
  • 16.10.2019 Podpísaná zmluva o NFP (1059/2019 | Centrálny register zmlúv)
  • 12.9.2019 Vyhlásené verejné obstarávanie na “Online procesy eZdravia a služby prevádzkovej podpory” (6 502 896 EUR)
  • 1.2.2020 Začiatok realizácie EŠIF projektu (23 mesiacov, t.j. do 31.1.2022)
  • 7.5.2020 Zrušené verejné obstarávanie na “Online procesy eZdravia a služby prevádzkovej podpory”
  • 21.10.2022 Ukoncenie výberového konania: JOSEPHINE - Online procesy eZdravia (VS)
  • 11.8.2023 Ukončenie verejného pripomienkového konania prepracovaného projektu
  • 22.9.2023 Schválenie projektu v OP Slovensko
2

Tak ideme znovu:

Online procesy eZdravia: https://www.uvo.gov.sk/vestnik/oznamenie/detail/503274
Celková odhadovaná hodnota : 14 962 850,00 EUR bez DPH

stalecelkom zaujimavy setup podmienok učasti:
referencie - kumulacia viacero projektov, demonstracie funkcionality
experti - napr Oracl expert aj ked nikde nieje zrejme preco a o oracle sa v podkladoch nic nepise :slight_smile:

3

Doteraz bolo cele eZdravie postavene na technologiach Microsoft. Teraz otocili o 180 a rozhodli sa ist smerom ku kontajnerizacii (Kubernetes) a pravdepodobne Java. V tejto suvislosti je spominany “Oracle Certified Professional Java SE 8 Programmer”. Pricom verzia 8 je uz dnes nepodporovana verzia Java SE.

Vyzera to, ze cele verejne obstaravanie je zas iba “pro-forma”.
Sumarizacia ( strana 135 sutaznych podkladov )
“”“Požadované verejným obstarávateľom v časti B.1 Opis predmetu zákazky – konkrétny produkt alebo
framework, prostredníctvom ktorého bude oblasť riešenᔓ”
Pricom B.1 neobsahuje zdovodnenie pre posudzovane technologie napr. Angular/WebComponents/Auth0/konghq/…

4

@Lubor , @jsuchal : Bude slovensko.digital pripomienkovat toto nove obstaravanie ?
T.j. ma zmysel sem pisat pripomienky ?

@jsuchal : nedavno sme mali diskusiu ci pre eZdravie pouzit SQL alebo noSQL. V tomto obstaravani uz idu smerom na noSQL, aj ked pre tento typ a mnozstvo udajov ho nepotrebuju.

Strucny sumar : Za necelych 15-milionov EUR, idu riesit nefunkcne casti eZdravie a aby sa nepovedalo, tak ku tomu pridaju funkcnosti, ktore nedomysleli v povodnych zadaniach.

5

Projekt u nas zastresuje @lubor, ale ked nieco spises, urcite to posunieme kam treba.

6

Studia uskutocnitelnosti je MetaIS
Pozn. Subory s priponou *.doc maju mat priponu *.mht, nasledne je mozne ich otvorit v Chrome

  • zdanlivo ide o samostatny novy informacny system a uplne nove biznis procesy.
  • zo zadania vsak vychadza, ze ide o odstranovanie analytickych/architektonickych chyb eZdravie

t.j. jedinymi moznymi dodavatelmi su firmy z konzorcia dodavajuceho povodne eZdravie.
V pripade, ze ide o analyticke/architektonicke chyby eZdravie, tak by mali byt odstranene v ramci platenej podpory a nie ako novy projekt.

Nepomenovane problemy eZdravie, ktore sa projekt snazi riesit

  • EZKO vznikne az na zaklade informacie o vzniku poistneho vztahu / prideleni rodneho cisla
    • Problem : Novorodenci dostanu rodne cislo pridelene az niekolko dni po narodeni ( lebo matrika ).
    • Problem : Cudzinci s povolenim na pobyt.
    • Problem : Cudzinci s europskym preukazom zdravotneho poistenia.
  • Pristup vseobecneho lekara na EZKO po zmene
    • Problem : Po zmene kapitacneho vztahu ( == zmena vseobecneho lekara ) je EZKO je viditelne az o dva mesiace.
  • Nedostatocny vykon eZdravie
    • Problem : Nacitanie 10 riadkov OUP trva 20 sekund.
  • Chybajuce nastroje pre statisticke spracovanie
    • Problem : Modul SARA nefunguje, bezpecnostny koncept ulozenia dat je prilis pomaly.
  • Prevadzka eZdravie iba v jednej lokalite.
    • Problem : Vypadok eZdravie by sposobil vypadok dostupnosti pre cele Slovensko

Dalsie nepomenovane ciele projetku :

  • Vymenit dodavatela JRUZ
  • Vymenit dodavatela CA

Uvedene problemy znemoznuju produkcne pouzivanie eZdravie.
(pozn. uvedene problemy su spomenute aj Studii uskutocnitelnosti, ale nie ako chyby/nedorobky eZdravie )

NCZI pozna uvedene problemy uz niekolko rokov a mohlo ich riesit

  • ako chybove hlasenie => kedze ide o chyby koncepcie eZdravie
  • alebo ako zmenove konanie => co by umoznilo rychlejsie nasadenie do prevadzky

Spojenim biznisovych procesov s technologickymi posunie realnu pouzitelnost celeho projektu eZdravie o dalsie 4 roky.
( 4 roky = start 31.5.2022 + 24 mesiacov vyvoj + 12 mesiacov integracia ambulantnych systemov )

Pripomienka ku "Certifikačná autorita (VP_7)"

  • chyba zdovodnenie preco je existujuca certfikacna autorita “uzavretý subsystém pre potreby NZIS-u”
  • prevadzka dvoch certifikacnych autorit povedie ku zvysenym prevadzkovym nakladom.
  • “uzavretie” povodnej certifikacnej autority odporuje zakonu 153/2013 paragraf 12 odsek 3 bod i.
    “plní úlohy poskytovateľa dôveryhodných služieb36) pre používanie zdokonaleného elektronického podpisu v zdravotníctve”
    t.j. pravdepodobne ide o vymenu dodavatela existujucej CA

Pripomienka ku "Úpravy NZIS (VP_13)"
System NCZI(=eZdravie) pozaduje od OPE garantovat dostupnost a odozvy (300ms).
t.j. pravdepodobne ide o vymenu JRUZ s cielom urychlit odozvy eZdravie.

Pripomienka ku "MDM (VP_14)"

  • NCZI pozaduje duplicitne riesenie s pouzitim Talend MDM aj bez pouzitia Talend MDM.
  • Pre ocakavane mnozstva udajov ( menej ako 20-milionov ) ide o “kanon na vrabce”
    t.j. pravdepodobne ide o snahu postavit platformu a nastroje pre chybajuce nastroje pre statisticke spracovanie celeho eZdravie.

Pripomienka ku "OPE - riešenie centrálneho repozitára údajov (VP_15)"

  • Pre ocakavane mnozstva udajov ( menej ako 20-milionov ) ide o “kanon na vrabce”
    t.j. pravdepodobne ide o snahu postavit distribuovane ulozisko pre cele eZdravie a teda zabezpecit vysoku dostupnost a zrychlit odozvy celeho eZdravie

Pripomienka ku "Rozhranie výmeny údajov (VP_17)"
Poziadavky na RVU v OPE su tvrdsie ako na samotne eZdravie.
Pricom ide iba o vymenu informacii v registroch v rozsahu tisicov externych volani denne.
Kritickou aplikaciou je eZdravie, cez ktore tecu miliony zaznamov denne a jeho nedostupnost sposobi problemy celemu zdravotnictvu na Slovensku.
t.j. pravdepodobne ide o snahu nahradit JRUZ za uplne novu implementaciu registrov.

Popis biznis procesov

  • prilohy obsahuju iba “to-be” stav, “as-is” stav sa nachadza v studii uskutocnitelnosti
  • porovnanim “as-is” → “to-be” je vidno, ze dochadza ku minimalnym upravam procesov, skracuju sa vsak lehoty pre odpoved jednotlivych akterov
  • skratenie lehoty na rozhodnutie je vsak zavisle od prislusneho aktera, ktory je castokrat mimo dosah NCZI

Proces "A. Registrácia a ukončenie platnosti poskytovateľa zdravotnej starostlivosti (to-be) (VP_21)"

  • Na obrazku chyba Zdravotna poistovna, ktora by mala na zaklade zrusneho povolenia pre poskytovanie ZS ukoncit prislusne zmluvy.
  • vzhladom na pocty za rok ( registracie 400 / ukoncenie 500 ) je ekonomicka navratnost pre automatizaciu tohto procesu otazna

Proces "B. Registrácia a ukončenie platnosti zdravotníckeho pracovníka (to-be) (VP_23)"

Proces "C. Registrácia a ukončenie platnosti prijímateľa zdravotnej starostlivosti (to-be) (VP_22)"

  • Koniec procesu je popisany zle. Vznikom/zanikom verejneho zdravotneho poistenia nesposobi “Vznik alebo zanik PrZS v NCZI” ako je uvedene.
  • priklad
    PrZS ( pacient ) sa odstahuje do zahranicia => zanika mu povinnost byt zdravotne poisteny na Slovensku.
    PrZS ( pacient ) sa zijuci v zahranici ( a tam aj poisteny ), moze vyuzit zdravotnu starostlivost na Slovensku, t.j. jeho EZKO nemoze byt zmazane,
    PrZS ( pacient ) po navrate zo zahranicia ( a opatovne poisteny na Slovensku ) => sa potrebuje vratit ku svojej povodnej dokumentacii
  • Zdravotnu dokumentaciu je mozne vymazat 20 rokov po smrti pacienta ( nie po ukonceni zdravotneho poistenia ako ukazuje obrazok )
  • Viazat konpcept vzniku PrZS v NCZI na narodenie resp. evidenciu cudzinca je zla implementacia.
  • priklad
    Cudzinec ( s europskym preukazom ZP ) potrebuje zdravotnu staroslivost ( cudzinec nema EZKO )
    Lekar A urobi odbery a potrebuje poslat ziadanku do laboratoria ( nemoze pretoze cudzine nema EZKO )
    Laboratorium urobi vysetrenie, ale nemoze ho zapisat do eZdravie ( pretoze cudzine nema EZKO )
    Lekar A odosle cudzina ku specialistovi Lekar-B ( nemoze vsak vydat elektronicky vymenny listok )
    Lekar B nevidi spravu od lekar-A …
    Cudzinec dostane povolenie na pobyt, vznikne mu prazdna EZKO.
  • Kvoli vyzsie uvedenym pripadom budu musiet vsetci poskytovatelia stale udrziavat aj sucastne komunikacne postupy ( papierove alebo elektronicke ).
    • Dvojkolajnost komunikacie, kde jedna (eZdravie) je podmnoziou druhej ( priama ), povedie iba ku pouzivaju tej komunikacie, ktora umoznuje viac.
  • Pre odstranenie tohto problemu je potrebne
    • umoznit vytvorit PrZP v NCZI pre lubovolneho lekara prveho kontaktu
      • cudzinci budu identifikovani cez cislo europskeho preukazu / cislo pasu
      • novorodenci budu identifikovani cez rodne cislo matky a poradove cislo novorodenca
        ( ^^^ takto je to pouzivane v sucastnych fakturacnych davkach )
  • Sparovanie PrZP s poistnym vztahom je mozne urobit aj dodatocne.

Proces "D. Registrácia a ukončenie platnosti pracovno-právnych vzťahov (vzťah medzi PZS a ZPr) (to-be) (VP_18)"

  • Na obrazku chyba Zdravotna poistovna, ktora uvedene udaje potrebuje pre kontrolu ci dany ZPr moze v mene PZS poskytovat ZS.
    napr. ci lekar moze predpisovat lieky v danej ambulancii
    Dnes poistovne dostavaju tieto informacie spatne cez fakturacne davky.
  • Rovnaky dovod pre evidenciu tychto udajov ma aj NCZI ( eZdravie ), je to tak uvedene aj v studii vykonatelnosti.
  • Rozpor :
    Studia vykonatelnosti v obrazku “as-is” hovori o 10dnoch ( 5 pre PZS a 5 pre NCZI )
    Studia vykonatelnosti v popise hovori o skrateni z 8 dni na dva ( 1 pre PZS a 1 pre NCZI )
    T.j skratili dobu v externej entite PZS na jeden den, ale zaroven si na strane NCZI ponechali jeden den, na realizaciu zapisu
  • Kedze PZS uzatvara pracovno-pravne vztahy v predstihu, tak dnesne zdrzanie vznika primarne na strane NCZI
  • Pretoze vymena informacii ISZI a JRUZ trva 5 dni, o tomto stave vsak museli vediet uz v case navrhu procesov eZdravie …

Proces E. "Registrácia a ukončenie platnosti kapitačných vzťahov (vzťah medzi PZS a PrZS) a zastupovania PZS (to-be) (VP_19)"

  • studia vykonatelnosti neobsahuje obrazky popisujuce “as-is”
  • studia vykonatelnosti obsahuje velmi nepresne informacie o tom ako sa dnes udrziava dany register a preco to trva 60 dni
    • odpoved je, ze tieto udaje tecu cez mesacne fakturacne davky (prirastok/ubytok) do poistovne ( t.j. 30 dni )
    • poistovna ich spracuje ( odstrani duplicity, vyriesi konflikty ) ( t.j. dalsich 30 dni )
    • poistovna vycistene udaje posiela do eZdravie
  • vyzsie popisovany stav je tam uz od navrhu eZdravie
  • skratenie doby chce NCZI dosiahnut elektronizaciou daneho procesu
  • toto je fatalna nefunkcnost eZdravie ( rocne sa to tyka 989 244 pripadov ),
    ktora uz davno mala byt riesena cez zmluvu na podporu ( ci uz ako chyba alebo nova poziadavka ).
  • ak bude tento proces realizovany az ako sucast projektu “Online procesy eZdravie”, tak budeme na implementaciu cakat dalsie 4 roky.
    • zaciatok projektu 31.5.2022
    • 24 mesiacov na dodavku projektu “Online procesy eZdravie”
    • 12 mesiacov, kym to implementuju dodavatelia ambulantnych systemov
  • dovtedy nebude mozne plnohodnotne vyuzivate vraj funkcne sluzby eZdravie
    • implementacia cez rozsirenie existujuceho API eZdravie je mozne nasadit za 18 mesiacov
      ( pri standardnej rychlosti implementacie )

Proces E. "Registrácia a ukončenie platnosti kapitačných vzťahov (vzťah medzi PZS a PrZS) a zastupovania PZS (to-be) (VP_19)"

  • Studia vykonatelnosti ani sutazne podklady neobsahuju obrazky ani popis pre proces “zastupovania PZS”
  • V procese “Zastupovanie PZS” vystupuju ini akteri ako pre kapitacne vztahy, je teda vyrazne odlisny.
    • priklad. Lekar (PZS-A) odchadza na (matersku) dovolenku / dlhodobu PN
      Lekar (PZS-A) ma povinnost najst za seba nahradu (Lekar PZS-B) a oznamit to na VUC
      Pocas doby zastupovania ma Lekat/PZS-B opravnenie na pristup ku zdravotnej dokumentacii k pacientom Lekara/PZS-A
  • zvladnutie tohto procesu je dalsia dolezita funkcnost, ktora znemoznuje pouzivanie eZdravie v praxi.
    • dnes lekar/PZS-B ma iba moznost pozriet do papierovej dokumentacie Lekar-A

Proces "F. Registrácia a ukončenie platnosti zmluvných vzťahov medzi ZP a PZS (to-be) (VP_24)"

  • dnes nema (komercna) ZP ani (komercny) PZS povinnost informovat o zmluvnych vztahoch iny statny organ
    • nemaju ani povinnost zverejnovat tieto zmluvy ( kedze ide o obchodne tajomstvo )
  • NCZI ide touto poziadavkou nad ramec existujucich zakonov.
  • V studii vykonatelnosti sa NCZI odvolava na pripravovanu zmenu sposobu vykazovania.
    • Zmena sposobu vykazovania cez eZdravie vsak bude vyzadovat dalsiu zmenu zakona.
      napr. zakon 153/2013 hovori : prekripcia/dispenzacie/laboratorne ziadanky idu cez system ZP
    • Dnes castokrat robi vykaznictvo do poistovne administrativny pracovnik.
    • Do eZdravie moze zapisovat iba lekar.
      Ak prejde uvedeny navrh, tak lekar bude musiet vykonat vyrazne viac administrativnych cinnosti
      t.j. pocas pracovnej doby vysetri menej pacientov.
    • Pri dnesnom nedostatku lekarov je pridavanie dalsich administrativnych povinnosti velmi zly napad.
    • Je otazke ci uvedena legislativna zmena prejde.

Proces "G. Registrácia a ukončenie platnosti poistných vzťahov (vzťah medzi ZP a PrZS) (to-be) (VP_20)"

  • proces je podmnozinou Proces-u “C. Registrácia a ukončenie platnosti prijímateľa zdravotnej starostlivosti (to-be) (VP_22)”
  • rozdiel medzi “as-is” a “to-be” je v sposobe zistovania prislusnosti pacienta ku zdravotnej poistovni
  • dnes poskytuje
    • kazda poistovna vlastnu sluzbu
    • centralny register poistencov na UDZS tiez vlastnu ( ak existuje )
    • (mozno aj) NCZI poskytuje tiez vlastnu
  • poistovne maju svoje sluzby vyladene na rychlost a okrem informacie “poisteny/nepouisteny”
    dokazu poslat aj informaciu, ze pacient je neplatic a teda ma narok iba na neodkladnu zdravotnu starostlivost
  • (pravdepodne) vsetci dodavatelia maju uz dnes vyladene toto zistovnie
    a je pre nich lahsie urobit tri rychle sietove volania ako jedno pomale voci NCZI alebo (aktualne) nefunkcnemu CRP UDZS
    Overenie poistného vzťahu v Centrálnom registri poistencov - Zdravotnícky pracovník - NPZ

Zaver:

  • Proces G => zrusit => je podmnozina C., poskytovatelia pouzivaju sluzby z poistovni
  • Proces F => zrusit => nema oporu v zakone
  • Procesy E. + C. => riesit ako chyby povodneho navrhu eZdravie
    • ide o kriticke chyby, ktore znemoznuju pouzivanie eZdravie v deklarovanom rozsahu
    • cakat 4 roky na nasadenie OPE je prilis dlho
    • technicky ide iba o zopar sluzieb, ktore je potrebne pridat do existujuceho API
  • Proces D => riesit cez zmenove konanie internych systemov NCZI ISZI a JRUZ
  • Proces B => najskor zrychlit proces vydavania elektronickeho preukazu zdravotneho pracovnika ( 10 dni )
  • Procesy A.+B => vzhladom na definovane pocty nie su kriticke

Technologicke upgrady eZdravie, je mozne dodavat ako samostatne projekty.

  • nova Certifikacna autorina a timestamp server ako nahrada za existujuce CA
  • nove MDM + Centralne ulozisko ako nahrada za nedodadne/chybajuce statisticke nastroje v eZdravie
  • orchestracia, system vymeny udajov, API management su uplne nove komponenty
2 Likes
7

RF pre tento projekt som robil ja

pozriem na info od @Vladimir_Kralik a urobime update

preletel som to rychlo, vyzera to na peknu pracu @Vladimir_Kralik

8

ale toto predsa ani nefunguje. Kedze NCZI nie je zapisana v EU trusted liste ( https://webgate.ec.europa.eu/tl-browser/#/tl/SK ) moze vydavat maximalne zdokonaleny podpis, založený na nekvalifikovanom certifikate…
Určite nie zdokonaleny ani kvalifikovaný.

9

To treba povedat na NCZI resp. LYNX-u, ktory tam robi support pre bezpecnost a navrhoval vsetky bezpecnostne zalezitosti v eZdravie.

10

tak VO je nakoniec zrusene
https://www.uvo.gov.sk/vyhladavanie-zakaziek/detail/dokumenty/431224