2. rész

Az e-MedSolution és a feneketlen adattó - Strukturálatlan adatok, migrációs kockázatok és a kényszerű országosítás ára

Valamilyen konszolidáció kell - de miért éppen a legelavultabb technológiai ággal?

Az országos egészséginformatikai konszolidáció szükségességét nehéz vitatni: közös adatminőségi szabályok, biztonsági követelmények, szabványos kapcsolatok, központilag működtethető szolgáltatások és összehasonlítható teljesítménymutatók nélkül a rendszer széttartó marad. A konszolidációból azonban nem következik, hogy minden kórházban ugyanazt a teljes HIS-t, ugyanazzal a technológiai örökséggel és azonos politikai ütemezésben kell bevezetni.

Egy nyolcvanas évekbeli mag, amelyre webes felület került

Szakmai ismereteink szerint az eredeti MedSolution az 1980-as években, a ma már csak szűk körben alkalmazott Progress környezetben készült. Ennek nemcsak iparági emlékezete van: a Pécsi Tudományegyetem 2017-es közbeszerzési műszaki dokumentációja a MedSolution háttérkomponenseként Progress adatbázis-kezelőt, a licencek között pedig kifejezetten MedSolution Progress 4GL licenceket sorol fel, miközben ugyanebben a környezetben a webes alkalmazásszerver és a számos intézményi interfész külön komponensként jelenik meg.^[9] A Progress saját dokumentációja szerint az ABL korai változatai már az 1980-as évek elejének karakteres UNIX- és DOS-világában működtek, a régi alkalmazások továbbvihetősége pedig a technológia egyik alapvető sajátossága.^[10]

A visszafelé fenntartott kompatibilitás sokáig szolgálhatta az üzembiztonságot, közben azonban konzerválta az évtizedek alatt felhalmozódott adatmodellt, üzleti logikát és technológiai kötöttségeket is. A PTE dokumentumából az látszik, hogy az e-MedSolution webes működése mellett a MedSolution Progress-technológiája önálló, licencelt és üzemeltetett rendszerkomponensként maradt jelen.^[9]

Az e-MedSolution webes generációjának magyarországi bevezetéséről már 2007-ben beszámoltak; a korabeli ismertetés szerint több intézményben a korábbi MedSolution és az újabb e-MedSolution párhuzamosan működött.^[1] Szakmai értékelésünk szerint ez a webesítés nem jelentette a teljes intézményi adatállomány új rendszerbe migrálását, és nem hozott létre alapjaiban új klinikai adatmodellt vagy új működési logikát: a régi MedSol kapott korszerűbb hozzáférési felületet, miközben a magja és öröksége megmaradt. A ma is használt magyar HIS-ek között ez a legrégebbi technológiai ág; ezzel szemben az EHIK fejlesztői köre és a GlobeNet a kétezres évek fordulóján az akkori korszerű fejlesztési környezetekben hozta létre saját rendszereit.

A kórházi rendszerek életciklusa hosszú, ezért a kor önmagában nem használhatósági ítélet. Egy országos modernizáció technológiai alapját viszont nem a puszta fennmaradás, hanem a bizonyított fejleszthetőség, adatminőség, integrálhatóság, üzemeltetési modell és migrációs kockázat alapján szokás kiválasztani.

Ehhez képest egy, az ISH fejlesztési örökségét bemutató projektismertető az e-MedSolution bővítése mellett a MedSol Smartot már 'teljesen új alapokra épített' rendszerként írta le, kiemelve a korszerű szoftvereszközöket és a távoli üzemeltetést megkönnyítő logikai felépítést.^[2] Ha ugyanazon fejlesztési vonalon indokoltnak látták egy korszerűbb technológiai ág létrehozását, akkor különösen indokolt volna nyilvánosságra hozni: milyen összehasonlító vizsgálat alapján lett mégis a régebbi ág kötelező országos alap.

Független benchmark nélkül a 'legelavultabb' vagy 'legrosszabb' minősítés nem objektív rangsor, hanem kemény vélemény. A baj éppen az, hogy az állam sem mutatott be olyan összehasonlítást, amely ezt a vitát szakmai alapon eldönthetné. Nem ismerünk közzétett pontozást a technológiai adósságról, a válaszidőről, a rendelkezésre állásról, a fejlesztési ciklusokról, a felhasználói terhelésről, a strukturált adatok arányáról, az integrációs költségekről vagy az intézményi migráció kockázatáról.

A rendszer tárol adatot. De vajon használható adatot termel?

Az adatbázis technikai értelemben lehet rendezett és lekérdezhető úgy is, hogy a klinikai tartalom jelentős része szabadszövegben, intézményenként eltérő mezőkben, különböző kódolással vagy eltérő szakmai jelentéssel szerepel. A technikai struktúra és a szemantikai struktúra nem ugyanaz. Az első azt mondja meg, hol van az adat; a második azt, hogy minden rendszer és minden szakember ugyanazt érti-e alatta.

A Pécsi Tudományegyetem Transzlációs Idegtudományi Nemzeti Laboratóriumának informatikai leírása egyenesen kimondja, hogy a magyar beteginformatikai rendszerek adatbázisai nagyrészt szabadszövegesek, nem kellően strukturáltak, ezért közvetlen digitális feldolgozásra nem alkalmasak. A projektben kifejezetten az e-MedSolution rendszerben kellett kialakítani a strukturált adatgyűjtést, szakmaspecifikus űrlapokat fejleszteni és paraméterezni, majd külön adatstruktúrát, transzformációs eljárásokat és központi adatplatformot létrehozni.^[3]

Az e-MedSolution tartalmaz strukturált adatot, és a PTE leírása szerint HL7-formátumú adatkivételre is képes; a fejlesztett űrlapok több területen éles klinikai használatba kerültek.^[3] A dokumentum ennél szűkebb, de kellemetlenebb megállapítást támaszt alá: az elemzésre alkalmas, egységes klinikai adatot külön modellezéssel, űrlapfejlesztéssel, minőség-ellenőrzéssel és transzformációval kellett előállítani, mert az nem keletkezett automatikusan a HIS mindennapi használatából.

Vagyis a központba nem elég adatot küldeni. Közös jelentést kell küldeni.

Adattóba önteni nem ugyanaz, mint strukturált adatot teremteni

Pécsen 2018 és 2022 között 1,789 milliárd forint szerződött támogatással futott a 'Hálózatos analitikai és adathasznosítási lehetőségek az egészségügyben' projekt, amelynek célja a PTE egészségügyi adatainak gyűjtésére, tárolására és elemzésére alkalmas adattó-koncepció és prototípus létrehozása volt.^[4] A hozzá kapcsolódó későbbi fejlesztésekből jól látszik a központi tárhely korlátja: a forrásnál keletkező adat minőségét, jelentését és teljességét külön kell rendbe tenni.

Ha ugyanaz a klinikai esemény az egyik helyen kódolt mező, a másikon szabad szöveg, a harmadikon csatolt dokumentum, akkor a központi adattó nem adatvagyont, hanem megfeleltetési feladatot örököl. Ha ugyanaz a kód két intézményben mást jelent, az adat technikailag átérkezhet, szakmailag mégis félreérthető marad. Ha egy fontos körülmény csak narratív szövegben van jelen, automatizált döntéstámogatásra, minőségmérésre vagy kutatásra csak utólagos feldolgozással használható.

Az Európai Bizottság egészségügyi adatformátumra vonatkozó megközelítése sem áll meg a fájlátadásnál: harmonizált adatkészletekkel, egységes kódolási rendszerekkel és technikai interoperabilitási specifikációkkal számol.^[5] Ehhez képest félrevezető azt állítani, hogy az országos adatprobléma már attól megoldódik, ha minden kórházban ugyanaz az alkalmazás nyílik meg.

A feneketlen adattó nem attól lesz okos, hogy még több szabadszöveget öntünk bele. Attól lesz használható, hogy az adat már a betegellátás folyamatában egységes jelentéssel, ellenőrizhető minőségben születik meg.

Új rendszer adatok nélkül - a betegbiztonság nem lehet utólagos projektfázis

Egy több évtizedes kórházi rendszer kiváltása nem egyszerű fájlmásolás. A történeti betegadatok mellett tovább kell vinni a gyógyszerelési információkat, leleteket, dokumentumkapcsolatokat, helyi kódokat, intézményi paramétereket, jogosultságokat, diagnosztikai kapcsolatokat és az évek alatt kialakult működési logikát. Egy adat akkor migrált sikeresen, ha az új rendszerben ugyanahhoz a beteghez, ugyanabban a szakmai jelentésben és megfelelő időben visszakereshető.

A Népszava 2024. októberi cikkében idézett ágazati beszámoló szerint Sárváron az adatmigráció elmaradt, Farkasgyepűn pedig a korábbi szolgáltató közreműködésére volt szükség az adatok áthelyezéséhez.^[6] Az Economx ugyanebben az időszakban a Bajcsy-Zsilinszky Kórház kapcsán papíron lezárt átállásról, de nem ismert hatásvizsgálati eredményekről írt.^[7] Ezek sajtóban közölt szakmai állítások, nem teljes körű hatósági auditok, ezért nem általánosíthatók automatikusan minden intézményre. Arra azonban elegendők, hogy az állam intézményenkénti, nyilvános migrációs és betegbiztonsági bizonyítékokkal tartozzon.

Betegbiztonsági minimumként igazolni kellene a történeti adatok teljességét és visszakereshetőségét, a kritikus gyógyszerelési és diagnosztikai információk folytonosságát, a leletek és dokumentumok beteghez rendelését, a szakmai alrendszerek kapcsolatát, a terhelés alatti működést, a hibakezelést, a naplózhatóságot és a visszaállási lehetőséget. Az amerikai egészséginformatikai koordinációs hivatal, az ONC betegbiztonsági útmutatója is többlépcsős folyamatként kezeli az EHR-bevezetést, amelyben külön vizsgálni kell a konfigurációt, a rendszerkapcsolatokat, a betegazonosítást, az információ-visszakeresést, a klinikai folyamatokat és az üzemzavari terveket.^[12] Nem elég azt mérni, hogy az alkalmazás elindult. Azt kell bizonyítani, hogy az ellátás információvesztés nélkül folytatódott.

Félbehagyott átállások: két rendszer között maradt kórházak

A kötelező bevezetés mai állapota már nem elméleti technológiai vita. Sok kórház szakemberei, és rajtuk keresztül a betegek is, egy félbehagyott átmenet mindennapi következményeit viselik: a régi rendszer adatai és megszokott funkciói továbbra is szükségesek, az új rendszer használata közben pedig párhuzamos munkarend, kézi adatkeresés, újrarögzítés és többlettámogatás válik szükségessé. Egy 2025 decemberében ismertetett ágazati helyzetkép szerint akkor mindössze tizennyolc intézményben történt meg az átállás, miközben több mint hatvan kórház volt még hátra, és a szakmai beszámoló hiányzó modulokról, illetve a program eredménytelenségéről is szólt.^[11]

A hozzánk eljutó intézményi és felhasználói visszajelzésekben szinte minden esetben felmerül a korábbi működéshez való visszaállás igénye. Ennek nagyon is gyakorlati oka van: az átállás nem vitte tovább maradéktalanul azokat az adatokat, funkciókat és helyi munkafolyamatokat, amelyekre a kórház napi működése épült. A teljes és ellenőrzött adatmigrációnak a jelenlegi végrehajtási modellben alig látszik reális esélye, mert az intézményi adatvagyon nem egyetlen exportfájl, hanem több évtizednyi helyi logika, dokumentumkapcsolat és diagnosztikai összefüggés együttese.

Kisvárda korábbi esete már megmutatta, hogy az e-MedSolution politikai döntéssel, történeti migráció nélkül is elindítható, csak éppen az üres adatbázis nem szakmai siker, hanem az adatfolytonosság feladása. A mostani országos programban ugyanennek a megközelítésnek a sokszorosított változata fenyeget: a telepítést átadásnak, a bejelentkezést működésnek, a hiányzó előzményt pedig az intézmény gondjának tekintik.

A határidő csúszása nem kommunikációs hiba, hanem technikai tünet

2024 végén még 2025 végére várták az országos átállást a szakmai és sajtóközlések.^[7] A hatályos rendelet ma már 2027. január 1-jét jelöli meg a teljes körű használat időpontjaként.^[8] Egy ekkora állami program határideje módosulhat, a két évvel kitolt ütemezés azonban elég világosan jelzi, hogy a feladatot eredetileg jóval egyszerűbbnek gondolták a valóságosnál.

A kórházak nem üres szervertermek. Több száz szakmai munkafolyamat, több ezer felhasználó, helyi diagnosztikai rendszerek, pénzügyi és logisztikai kapcsolatok, évtizedes adatállomány és napi huszonnégy órás betegellátás találkozik bennük. Ha az ütemterv nem ezekből indul ki, akkor a határidő nem projektterv lesz, hanem politikai kívánságlista.

Egy HL7-kapcsolat még nem interoperabilitás

A technikai üzenetátadás szükséges, de nem elégséges. Attól, hogy két rendszer képes adatot küldeni egymásnak, még nem biztos, hogy az azonosítók, státuszok, kódok, időpontok, mértékegységek, jogosultságok és hibajelzések mindkét oldalon ugyanazt jelentik. A valódi interoperabilitás technikai, szemantikai és szervezeti szintből áll: az adatnak át kell érnie, meg kell őriznie a jelentését, és illeszkednie kell a betegellátási folyamatba.

Ezért téves az egyenlet, hogy egyetlen országos HIS automatikusan egységes adatot eredményez. Ugyanabban a rendszerben is lehet intézményenként eltérő paraméterezés, dokumentációs gyakorlat, kódkészlet és adatminőség. Fordítva pedig több különböző rendszer is képes egységes, szabványos és ellenőrzött adatot előállítani, ha a közös követelmények megfelelőek.

A HL7 FHIR szabvány hivatalos áttekintése kifejezetten rögzíti, hogy az automatikus klinikai feldolgozáshoz az adatnak nemcsak hozzáférhetőnek, hanem strukturáltnak és szabványosítottnak is kell lennie,^[13] az Európai Egészségügyi Adattérről szóló 2025/327/EU rendelet pedig az EHR-rendszerek interoperabilitását, adatportabilitását és megfelelőségét önálló követelményrendszerként kezeli.^[14] Egy 2022-es szisztematikus áttekintés a fejlett egészségügyi rendszerek tapasztalatai alapján ugyancsak arra jutott, hogy az interoperabilitás a betegbiztonság és az ellátás minőségének érdemi tényezője, nem pedig puszta technikai kényelmi szolgáltatás.^[15]

Az egységes adat nem igényel egységes képernyőt. Egységes jelentést, szabályt és ellenőrzést igényel.

Miért a legrosszabbat vették meg? A kérdésre nincs nyilvános szakmai válasz

Nem rendelkezünk olyan független összehasonlító vizsgálattal, amely alapján az e-MedSolution objektíven a magyar piac legrosszabb rendszere volna. De olyan nyilvános vizsgálat sincs, amely igazolná, hogy országos kötelező rendszerként a legjobb választás. A rendelkezésre álló tények ehelyett komoly figyelmeztetéseket adnak: régi technológiai ág; ugyanazon fejlesztési körben létrehozott, teljesen új alapú utódrendszer; külön fejlesztést igénylő strukturált klinikai adatgyűjtés; bonyolult migráció; elhúzódó országos határidő; és nyilvánosan nem ismert, intézményenkénti összehasonlító eredménymérés.

Egy ilyen rendszer lehet működőképes egyes intézményekben, ahol hosszú évek alatt hozzáigazították a helyi folyamatokhoz. Ebből nem következik, hogy más kórházakra gyorsan, az örökölt adatok és alrendszerek teljes ismerete nélkül ráteríthető. A helyi működőképesség és az országos alkalmasság két külön bizonyítási feladat.

Az e-MedSolutionban nyilvánvalóan lehet beteget felvenni és leletet készíteni; ez azonban nem bizonyítja, hogy országos kötelező rendszernek is ez a megfelelő választás. A teljes életciklus-költséget, az adatminőséget, a migrációt, a felhasználói terhelést, az integrációkat és a jövőbeni fejleszthetőséget együtt vizsgáló, mérhető és összehasonlítható szakmai válasz mindeddig nem került a nyilvánosság elé.

Sok ezer szakember szenved, hogy igazoljunk egy rossz és drága döntést

Ha egy országos döntés következményeit orvosoknak, ápolóknak, informatikusoknak, adminisztrátoroknak és intézményi vezetőknek kell évekig kézi kerülőutakkal, párhuzamos nyilvántartásokkal, újratanulással, adatpótlással és hibajavítással kezelniük, akkor a rendszer valódi ára nem áll meg az 5,5 milliárdos vételárnál. Hozzáadódik minden kieső munkaóra, minden elhúzódó vizsgálat, minden újra rögzített adat és minden olyan perc, amelyet nem a betegre, hanem a döntés utólagos igazolására fordítanak.

A felhasználói terhelést a szakirodalom is méri. Egy huszonkilenc vizsgálatot összegző, 2023-as szisztematikus áttekintés a kórházi EHR-használathoz kapcsolódó stressz és kiégés legfontosabb tényezői közé sorolta a rossz használhatóságot és a rendszerben eltöltött túlzott időt; a szerzők szakterületre szabott rendszereket, szigorú használhatósági tesztelést és megfelelő támogatást sürgettek.^[16] A rosszul végrehajtott átállás tartós szakmai terhelést épít be az ellátásba.

A központi program sikerét ezért nem a telepített példányok számával kellene mérni. Nyilvános intézményi mutatók kellenek: migrált és visszakereshető adatok aránya, kritikus integrációk hibaaránya, válaszidő, leállás, felhasználói többletmunka, támogatási igény, betegbiztonsági esemény, üzemeltetési költség és visszaállási képesség. Ami nem mérhető, az országosítás közben csak remény marad.

A határidőt rendelettel át lehet írni. A strukturálatlan adatot, az elveszett intézményi tudást és a hibás migráció következményeit nem.

Szükséges irányváltás

Indokolt a kötelező országos bevezetés független szakmai és betegbiztonsági felülvizsgálata, a migráció és a helyszíni támogatás elkülönített finanszírozása, valamint az átállás fokozatos, ellenőrzött végrehajtása. Tartós megoldást nyílt szabványokra, kötelező interoperabilitásra, független tanúsításra és több szolgáltató együttműködésére épülő modell adhat. A korábbi szolgáltatók közreműködésének jogi és pénzügyi feltételeit rendezni kell.

A harmadik rész a Debreceni Egyetem működő intézményi modelljét, a végrehajtott migrációt, a diagnosztikai integrációkat és az EHIK fokozatos, hibrid megoldási irányát mutatja be.

Források

1. Kórház, 2007/5.: az e-MedSolution webes generációjának bevezetése és a korábbi MedSolution párhuzamos használata - https://weborvos.hu/adat/korhaz/2007maj/36-37.pdf
2. RIK Zrt.: ISH Magtár projekt - az e-MedSolution bővítése és a teljesen új alapokra épített MedSol Smart - https://rikzrt.hu/tevekenysegek/projektek
3. Pécsi Tudományegyetem, Transzlációs Idegtudományi Nemzeti Laboratórium: Informatikai pillér - strukturált adatgyűjtés az e-MedSolutionban, adattranszformáció és központi adatplatform - https://tinl.pte.hu/hu/pillerek/informatikai-piller
4. Pécsi Tudományegyetem: Hálózatos analitikai és adathasznosítási lehetőségek az egészségügyben - projektadatok és célkitűzés - https://utazas.pte.hu/hu/akadalymentes-tartalmak/154
5. Európai Bizottság: az európai elektronikus egészségügyi nyilvántartási csereformátum - harmonizált adatkészletek, kódolás és technikai interoperabilitás - https://health.ec.europa.eu/ehealth-digital-health-and-care/certification-ehr-systems_en
6. Népszava, 2024. október 21.: Központosítják a kórházi informatikát, betegadatok válhatnak elérhetetlenné - https://nepszava.hu/3254686_informatikai-rendszer-korhaz-magyarorszag-mukodokepesseg
7. Economx, 2024. december 6.: Ebből baj lesz: tavaszra datálható egy krach az egészségügyben - https://www.economx.hu/magyar-gazdasag/2024/12/06/egeszsegugy-orvostechnikai-szovetseg-betegellatas-korhaz-informatikai-atallas-eeszt-neak-betegadatok-e-medsol-800714/
8. 29/2022. (I. 31.) Korm. rendelet a központi egészséginformatikai szolgáltatásokról - a teljes körű használat hatályos határideje - https://njt.hu/jogszabaly/2022-29-20-22
9. Pécsi Tudományegyetem Kancellária, Informatikai Igazgatóság: Műszaki dokumentáció az e-MedSolution és GLIMS rendszerek üzemeltetési támogatásához - Progress adatbázis, Progress 4GL licencek és interfészkörnyezet, 2017. - https://kozbeszerzes.pte.hu/sites/kozbeszerzes.pte.hu/files/kozbeszerzesi_dok/M%C5%B1szaki_Le%C3%ADr%C3%A1s_Medsolution_2017_07_28.pdf
10. Progress Software: Introducing ABL - az ABL korai, 1980-as évekbeli technológiai környezete és az alkalmazások továbbvihetősége - https://documentation.progress.com/output/ua/OpenEdge_latest/gsabl/introducing-abl.html
11. Economx, 2025. december 3.: kórházi informatikai átállások, hiányzó modulok és a végrehajtás ágazati értékelése - https://www.economx.hu/magyar-gazdasag/egeszsegugy-korhazak-adossag-intezmenyek-betegellatas-memt-konferencia-820302/
12. U.S. Office of the National Coordinator for Health Information Technology: Implementing Health IT - rendszerkonfiguráció, validáció, interfészek, betegazonosítás és betegbiztonság - https://healthit.gov/clinical-quality-and-safety/safer-guides/implementing-health-it/
13. HL7 International: FHIR Overview - strukturált és szabványosított egészségügyi adatok és interoperabilitás - https://hl7.org/fhir/overview.html
14. Az Európai Parlament és a Tanács (EU) 2025/327 rendelete az Európai Egészségügyi Adattérről - EHR-interoperabilitás és adatportabilitás - https://eur-lex.europa.eu/eli/reg/2025/327/oj/hun
15. Li E. és mtsai: The Impact of Electronic Health Record Interoperability on Safety and Quality of Care in High-Income Countries - szisztematikus áttekintés, Journal of Medical Internet Research, 2022 - https://pubmed.ncbi.nlm.nih.gov/36107486/
16. Alobayli F. és mtsai: Electronic Health Record Stress and Burnout Among Clinicians in Hospital Settings - szisztematikus áttekintés, Digital Health, 2023 - https://pubmed.ncbi.nlm.nih.gov/38130797/