Ahojte, pripájam moju skúsenosť s eReceptom. Pani doktorka u ktorej som bol mi
predpísala jeden liek (necelá minúta čakania)
po diskussi sme predpis zrušili (to bolo rýchlo)
predpísala mi druhý liek (zase takmer minúta čakania)!
Uvedomujem si, že zdržanie môže byť spôsobené na ľubovoľnej vrstve eHealth architektúry, ale máme nejaké otvorené dáta o response-time pre porovnanie? Pomohlo by to miestnym IT ľuďom v tejto nemocnici, aby vedeli, či je zdržanie na strane ich integrácie, alebo na strane eHealth ako celku.
Myslim si, ze to je problem SW danej doktorky. Moja skusenost s predpisanim ereceptu je, ze sme necakali vobec… lekarka odoslala poziadavku na erecept a asi SW na pozadi asynchronne zrealizoval pozadovane volania. Lekarka pouziva WinAmb od Softprogresu.
Pokial viem, pri erecepte sa robi aj komunikacia so zdravotnou poistovnou, takze zdrzanie moze byt aj na strane IS poistovne.
Asi ano. Velmi zalezi od toho ako velmi sa tvorcovia toho SW drzia implementacnych predpisov.
Je to takto :
lekar vypise recept vo ambulatnom IS
ambulatny IS podpise recept pomocou elektronickeho podpisu na ePZP
ambulatny IS odosle recept do poistovne
poistovna vyhodnoti pravidla akceptuje/zamietne
lekar dostane informaciu ze zapis prebehol
pacient odchadza
… potialto ^^^ by to malo byt synchronne …
poistovna asynchronne odosiela recept do eZdravie
eZdravie overuje podpis
poistovna dostane informaciu, ci podpis je validny
Co som pred dvoma rokmi videl merania na strane poistovne, tak boli odpovede do 100milisekund ( merane na vstupe/vystupe z poistovne ).
Preco to moze byt pomale :
integracny manual hovori, ze este pred prvym krokom by mal lekar/ambulantny IS zavolat kontrolu liekovych interakcii
toto je samostatne volanie este pred samostatnym vystavenim receptu
ambulatny system posiela SOAP do poistovne
poistovna musi nacitat historiu pacienta ( pre lieky minimalne pol-roka )
poistovna vyhodnoti interakcie
poistovna vygeneruje niekolko stranove PDF ( tak to bolo pred dvoma rokmi ) a odosle do ambulatneho IS
ambulatny IS by mal toto PDF zobrazit lekarovi, ktory by si ho mal nastudovat a az potom vypisat recept
upchata siet <= s kazdym receptom tecie verejny kluc z ePZP ( +2kb ) + komunikacia bezi cez ukecany SOAP
( malo pravdepobne ) poistovne medzicasom pritvrdili/spomalili kontroly pri zapise
Ta kontrola liekovych interakcii v samostatnom kroku je viacmenej zbytocna. Resp. mala byt byt zrealizovana az v tom druhom volani pri zapise preskribcie do evidencie. Ak nie su liekove interakcie => tak to rovno zapise, ak by boli interakcie tak odmietne zapis. Dnesne riesenie prehana po sieti zbytocne volania a PDF-ka, ktore aj tak nemaju lekari cas citat.
Aké sú teda podľa Vás možnosti na preverenie. Mal by to v prvom rade preveriť IT personál nemocnice alebo skôr firma dodávajúca softvér pre lekára? Ako je to optimálne?
A teraz mi napadá, že rôzne poistovne zrejme majú rôzne rýchle/pomalé odpovede na tieto dopyty. Zrejme aj toto bude hrať rolu. Inak povedané, keď moja poisťovňa má výpadok, tak mi lekár eRecept nepredpíše?
Velmi zalezi od technologickych schopnosti IT-ckarov v nemocnici a ochote dodavatelov IS. Ako prve je potrebne identifikovat problem a to mozu urobit iba IT-ckari priamo v nemocnici. Ci uz odmerat priepustnost siete alebo identifikovat sietove volania priamo na danej stanici, pripadne z aplikacnych logov. Samozrejme v spolupraci s dodavatelom IS to pojde rychlejsie. Kedze ide o produkcne prostredie, tak potrebuju monitorovat standardnu pracu lekara ( lebo ePZP-karta, podpisovanie … ). Merania na testovacich prostrediach nemaju v tomto pripade ziadnu vypovednu hodnotu.
Riskovali by totiz ze pridu o certifikat, pripadne budu mat problemy pri ziskani certifikatu na dalsiu verziu rozhrania. Z pohladu eZdravie ide o velmi efektivny sposob ako umlcat nespokojnych dodavatelov
Tie rozdiely urcite existuju. Ale myslim, si ze rychlostne su na tom lepsie poistovne lepsie ako eZdravie. Napr. IS v lekarni pre zistenie zoznamu nevydanych preskripcii, radsej urobi dotaz do kazdej poistovne ( t.j. 3x request ) ako by malo urobit jeden request do eZdravie.
Dovera a VsZP pouzivali implementaciu eRecept postavenu nad objektovou databazou Cache. Postavit Master-Master replikaciu vo dvoch vzdialenych serverovniach pre tento typ DB je celkom draha zalezitost, takze to asi doteraz nebolo zrealizovane ( rozpravalo sa o Master-Slave ). Union pouzival Cassandra DB, tam by to bolo mozne zrealizovat Master-Master replikaciu jednoduchsie. Neviem vsak ci to aj bolo zrealizovane.
Master-Master replikacia na strane poistovni je iba polovica problemu. Druha polovica je vypadok siete medzi nemocnicou a poistovnou. t.j. ci maju nemocnica aj poistovne zdvojene sietove pripojenia od roznych dodavatelov.
Ako posledne prichadza do uvahy “asynchronny mod” na strane nemocnicneho/ambulatneho systemu. T.j. preskripcia/recept je ulozena do fronty a caka na obnovu spojenia. Aj toto by malo byt podla integracnych scenarov implementovane.
Otazne vsak bude spravne vyladenie konfiguracnych parametrov :
ako dlho ma system cakat kym povie, ze poistovna/eZdravie je nedostupna ?
ako casto ma kontrolovat ci spojenie znova nabehlo ?
ako rychlo ma po obnoveni spojenia posielat udaje z fronty ?
Zverejniť referenčné časy je dobrý nápad. Z pohľadu zákazníka (lekári, lekárnici, poistenci) určite. Uvidíme, či sa to podarí vytvoriť oficiálne.
Zatiaľ si môžme urobiť vlastný prieskum.
Informácie by mohli obsahovať čas dňa a deň týždňa (dátum kôli súkromiu neposielať, stačí kvartál - rýchlosti sa menia spolu s tým, ako sa mení SW a ten sa mení neustále), funkcia/operácia o ktorú ide a názov zdr. poisťovne v ktorej je poistenec poistený.
Príklad:
Piatok, 10:00, predpis lieku, VsZP
Pondelok, 8:00, výdaj lieku na el. predpis, VsZP
Vlado proces vybavenia predpisu lieku výborne popísal.
Zverejnit je ta lahsia cast. Ta tazsia je pozbierat tie udaje. Ludia to exaktne merat nebudu …
Ak su tie ambulantne systemy certifikovane ( mali by byt ), tak by mali vytvarat aj celkom podrobne logy.
NCZI na tych logoch bazirovalo viac ako nad tym, ci integracia je “user experience friendly”.
Extrakciou z logov by malo byt mozne ziskat presne casy.
