Red Flags: Online procesy eZdravia

Red Flags Projekty
,
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